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