On 5/2/07, Panagiotis Issaris <takis.issaris@xxxxxxxxxxx> wrote:
The questions are stated in this e-mail [1]. One of the things that are being
discussed is the following action on a publicly mirrored repository:
git branch -m master dead_end
git branch -m last_good master
I'd think this would fail as people could have pulled from the repository while
the "dead_end" commit was already available, right?
Yes - that's something you shouldn't do on a normal branch... but
that's a feature ;-) -- we call it re-winding a branch.
A good workaround if you expect to go down some dead_ends is to have
an experimental branch that you pre-announce that will be rewound
regularly. On the git repo, Junio does exactly that with "pu"
("proposed updates"), and several feature-development branches have
been dropped or rewound at times.
Now, for your main dev and various maintenance branches, just do a
revert. If something made it into the main dev branch it means it's
not so experimental anymore and all the developers are building
further development on top. At that stage, the potential mistake has
made it "quite far" so you can't rewind it and pretend it didn't exist
;-)
So the good practice is to never rewind the long-term branches people
base their work on. Branches in your repo, and public branches clearly
marked as experimental, anything goes.
cheers,
martin
-
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