Re: idea: git "came from" tags
- From
- D Herring <dherring@tentpost.com>
- Date
- Jan 19, 2010, 05:02 UTC
- Message-ID
- <hj3ecj$836$1@ger.gmane.org>
- In-Reply-To
- <4B542EB2.5030407@drmicha.warpmail.net>
Michael J Gruber wrote:
Show 14 quoted lines
> D Herring venit, vidit, dixit 18.01.2010 05:22: >> Actors: >> - public "upstream" repository >> - public "local" repository >> - end users tracking both >> >> Situation: >> - local starts by tracking upstream >> - local makes changes, commits, and sends upstream >> - users now tracking local ahead of upstream > > Here I have to ask why. If users choose to track a volatile branch then > they have to live with rebasing or hard resets. If they want something > stable then they should track upstream.
I'm maintaining the "local" repository in a distribution of upstream libraries. I'm trying to avoid both volatile branches and unnecessary clutter. Here, both upstream and local are stable; they are just maintained by different teams. Upstream often accepts patches; but they may tweak things, use a different version control system, etc. and so the commit objects differ.
Show 10 quoted lines
>> - upstream makes modified commits >> - local satisfied, wants to reset master to upstream/master >> >> Problem: >> - A merge will perpetually leave two parallel branches. Even though >> there are no longer any diffs, local/master cannot use the same >> objects as upstream/master. > > If there are no diffs then, in fact, it can share most objects since > most trees will be the same, only a few commit objects will differ.
But once I have a local diff, the local tree must always use different git objects, even though the file contents are the same...
Show 21 quoted lines
>> - A hard reset lets local/master return to sharing objects with >> upstream/master; but this may break pulls or cause other problems for >> users. >> >> Proposed solution: >> - Local adds a "came from" tag to upstream/master, leaves a tag on the >> head of local/master, and does a hard reset from local/master to >> upstream/master. When a user tracking local/master does a pull, their >> client detects a non-fast-forward, finds the came-from tag, and treats >> it as a fast-forward. >> >> Basically, this is a protocol to glue a "strategy ours" merge onto an >> existing tree. This way local can cleanly track upstream, with no >> added complexity in the nominal (no local changes) case. > > But doesn't that mean that users completely trust you about what they > should consider a fast forward, i.e. when they should do a hard reset? > So, this is completely equivalent to following one of your branches with > +f, i.e. having a public a branch which they pull from no matter what, > and having a private branch which pushes to the public one in case of > fast-forwards as well as in the case when you would use your special tag.
This almost works, but it destroys some history preserved by a proper merge or this proposed extension. For example, suppose there are three commits between the user's last fetch and this merge/forced update; a proper merge will download them, but a forced update will not. This becomes important when a release tarball is based on one of these missing commits.
If local uses merge objects to track this properly, it creates a parallel branch that is simply nuisance clutter. Normally, the nuisance is limited to a visual distraction in gitk; but it can be significant if a user is trying to track both local and upstream. When there are and have been no local changes, local is following upstream; so the user can freely follow either until a local change is made. When there are no but have been local changes that were merged, the user must pick a branch even thought the contents are the same.
I could be obsessing over a minor detail; but the proposed change doesn't seem drastic.
To reiterate, Given A - C - E - ... - Z \ \ - B + D where A-Z are commit objects and the contents of merge D are identical to C, it would be nice to have a protocol that tags D for posterity and allows D->E to be a fast forward, without requiring cooperation from the source of E to Z.
Later, Daniel