Re: [PATCH] GIT commit statistics.

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 12, 2005, 19:04 UTC
Message-ID: <Pine.LNX.4.63.0511121947050.31652@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <46a038f90511120419v70166c60t93d58b7544e03e3b@mail.gmail.com>

Hi,

On Sun, 13 Nov 2005, Martin Langhoff wrote:

Show 7 quoted lines

> [...] I've been wondering whether it'd be possible to teach git to 
> rebase local patches, even if that means rewriting local history. When 
> you are dealing with team shared repo, the sequences of pull/push end up 
> being quite messy, full of little meaningless merges. Similarly, when 
> dealing with an upstream, my tree gets slowly out of sync and slightly 
> messy. Eventually I get a new checkout, and rebase any pending patches 
> with git-format-patch and git-am.

I thought about this problem for a while. You described a typical use case (in a small team with one central repo), where pushes are done only from a cleaned up branch, but the work branches stay.

If the tree corresponding to the central HEAD matches the tree corresponding of your private merge branch at a given stage, a simple graft should be your solution.

Example: You pull and push from/to origin on a central server. Your 
(dirty) work branch is master. Now, at a given time, 
origin^{tree}==master~15^{tree}. You could then generate a graft which 
tells git that all parents of origin are also parents of master~15.

If at a given stage, origin^{tree}==master^{tree}, that graft would make your next merge a fast forward, effectively cleaning up your branch without loosing your history.

The graft could be generated by a simple script.

Would this help you?

Ciao, Dscho