Hal Murray <hmur...@megapathdsl.net>:
> If nothing else, we should document the issues. A reference to this
> discussion might be appropriate. Do we have a FAQ type place to collect
> things like this?
No. This is general git knowledge, not a project-specific issue.
> How messy is it for people who have cloned/pulled to recover? I think that's
> the key issue. Is this a good time for a trial run?
Next time they pull they'll get a conflict message and request for merge that
they may not understand. Recovery is relatively easy if they have no local
commits of their own; if they do it gets nasty.
It goes like this. They have to
1. locate the point at which thir local tree diverged from the pre-surgery
public tree (we'kll call this point A),
2. use git format-patch to turn all their private commits after A to a
patch sequence,
3. locate the point of surgery where the new public tree diverges from the
old public tree (we'll call tihis point B).
4. git reset -hard at the parent of B,
5. git pull to resync withthe new public tree,
6. Reapply their local patches to the new gead, dealing with any merge
conflicts.
> Are there any alternatives? This seems like an interesting enough case that
> I expect there should be a reasonable way to recover. (Only the text in the
> commit comment needs to change.) What do other projects do?
Other projects suck up the damage and move on. The only reason trying to undo
this is even a discussion topic is that I am unusually skilled at stupid
git tricks and have actually run this process a handful of times. But
custom is very strongly against it.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
