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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html