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