Hi Zenaan, The upstream repo (GitHub) is used by the upstream to develop the program (detox). The upstream will commit change-by-change in this repo.
The Debian repo is used to control the packaging and will commit the whole last tarball from upstream (not change-by-change). As maintainer, I can commit change-by-change of the packaging only or not. I committed the final packaging only. So, there is no direct relation between Debian/upstream repositories. Note that 1.3.0 version is in experimental release in Debian (not in unstable/testing/stable yet)[1]. [1] https://tracker.debian.org/pkg/detox Regards, Eriberto 2017-05-01 2:27 GMT-03:00 Zenaan Harkness <z...@freedbms.net>: > Hello Eriberto and Doug, I just added github as an "upstream" remote > to my local detox git repo, which was cloned from Debian's. > > > 1) > git had to download the entire upstream repo, saying specifically: > $ git fetch upstream > warning: no common commits > remote: Counting objects: 310, done. > remote: Total 310 (delta 0), reused 1 (delta 0), pack-reused 309 > Receiving objects: 100% (310/310), 268.73 KiB | 7.00 KiB/s, done. > Resolving deltas: 100% (201/201), done. > From https://github.com/dharple/detox > * [new branch] develop -> upstream/develop > * [new branch] master -> upstream/master > * [new tag] v1.3.0 -> v1.3.0 > * [new tag] v1.2.0 -> v1.2.0 > * [new tag] v1.2.1 -> v1.2.1 > > > So, is there a way to connect the repos so that when one clones from > one repo, then fetches from the other, the shared objects are not > re-downloaded? > > (detox is a great repo to figure out how to solve this problem on, > because it's so small) > > > > 2) > Having included both repos in my local repo, I am wondering about > these two tags, which ought be the same git ID, but are not!: > > 1.3.0 according to upstream: > > d23cd12f7ff3730f4be9643fdcabe2fe0f3ebd74 refs/tags/upstream/1.3.0 > > > 1.3.0 according to debian: > > de8750555a2ae79dc138d5433879de0bd5d76f62 refs/tags/v1.3.0 > > > Now, if Debian's repo is older, then of course that's the obvious > "reason". > > Not that there's any "should"s, but is it appropriate to say for > example that one repo "should" clone the other? > > Or, for another example, "should" the upstream repo import all the > Debian tags and objects? > > Or "should" the Debian repo import the upstream now that it's in git? > > Or, finally, "should" each import the other? I.e. Debian import > upstream, and upstream import Debian? > > > > I'm actually not the knowledgeable about git sorry, so my questions > might be stupid - I'm trying to figure out how to create "the ideal > situation" if that makes sense... > > > > I have set up my local clone repos, and backups, to have "remotes" > that point to each other. > > I.e. e.g.: > - I've cloned the antlr and stringtemplate projects onto my local > workstation > - I backup all my cloned repos to an external hdd > - but sometimes I've "accidentally" worked in a clone repo on the > external hdd, and then needed to pull that across to my internal > hdd! > - so, I set up remotes on each hdd, pointing to the other hdd, as > well as to the (sometimes more than one) upstream/external/public > repos, > - then when I do a git fetch --all, the priority/sequencing > in my .git/config file is such that: > - git will always first try to grab any updates locally, from the > other hdd > > This is important to me, because some repos are large and have lots > of public updates (e.g. the linux kernel) and my remote rural > wireless internet link is not particularly "abundant" and so I > DEFINITELY don't want to download all the changes twice > (accidentally), so I always try to get changes first from my backup, > and my backup repo always tries to get changes first from my > workstation, and I am happy and calm :) > > > Hope you don't mind my rambling.. > > > Kind regards, > Zenaan
