idea: git "came from" tags

idea: git "came from" tags

[D Herring]

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
- 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.
- 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.


Example:
Without this addition, local/master looks something like
u1 - u2 - u3 - u4 - u5 - u6 ...
   \- l1 - l2\+ m1 -   \+ m2\+ m3 ...

With this addition, local/master looks like
u1 - u2 - u3(tcf) - u4 - u5 - u6 ...
   \- l1 - l2 - t0
where
* u# = upstream changes
* l# = local changes
* m# = local merges (m1=u3, m2=u5, m3=u6, ...)
* the tcf tag points to t0, and t0 tags the end of the local mods


Pseudo-shell-code addition to git-pull:
fetch local/master
fast_forward=usual test whether local/master contains user/master
if test $fast_forward = no
then
   for tag in $fetched_tags # something like this or git-describe
   do
     if is_came_from($tag) && (came_from($tag) contains user/master)
     then
       fast_forward=yes
       break
     fi
   done
fi

Comments?  I think this is completely implementable (though I'm not
well-versed in git internals).  Since it only triggers during
non-fast-forward operations, it should have negligible performance impact.

Of course, it would be even better if somebody shows me how to do this
with the current tools.  Maybe I'm just doing it all wrong.

Thanks,
Daniel

Re: idea: git "came from" tags

[Michael J Gruber]

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.

> - 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.

> - 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.

Michael

Re: idea: git "came from" tags

[D Herring]

Michael J Gruber wrote:
> 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.


>> - 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...


>> - 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