Avoiding merge bubbles
Eric S. Raymond
esr at thyrsus.com
Sun Jul 3 01:10:01 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
> Where should that be documented? I think I set that when you sent out a
> similar message a long time ago but I lost it when making a new clone.
I'll add a section on merging and rebasing to the Hacking Guide.
Since Mark hasn't responded, I also have a bit set to try to write a crisp set
of project goals for the website. Probably easier to get hin to edit them
than to write them.
> Are there other git quirks that should be documented?
Doubtless a semi-infinite number. The problem is knowing in advance which ones
we're likely to trip over.
> >> Is there any way to recover after I forget?
> > Not short of repository surgery. Remember the hash chain - git is actually
> > designed to make it difficult to modify old commits.
>
> If the crap is in my local copy, I can move the whole directory to the side,
> get a new clone, and merge my edits back in. Recovering my edits could be
> ugly, but in the no-collision case it's not that hard. Diff the directories
> to find the files you have edited, copy them over and commit...
Ah, well, if it's still in your local clone repository surgery becone practical.
I wrote a tool for this. Google for git-debubble.
> >> Can we fix the push process to reject pushes if they have that
> >> type of comment?
> > Theoretically possible, but probably a bad idea. We will probably have to
> > do real branch merges occasionally.
>
> I was thinking of looking for an exact match on the default commit message.
> If there was a real collision the message should say something interesting.
Hm. Possible. I'll stare at some hook scripts and contemplate it.
BTW, I think I've knocked the mlockall/threads/async bug on the
head. I swiped some code from chrony that does memlocking after
telling ntpd it can have as much memory as it wants - ntpd's
worst-case memory requirement ain't much. I've had that version
running continuously for about 14 hours merrily swapping pool
servers in and out with no crash.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel
mailing list