Hi,

On Sun, 13 Nov 2005, Martin Langhoff wrote:

quoted text
> [...] 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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html