From: Johannes Schindelin Date: Sat, 12 Nov 2005 19:04:24 GMT Subject: Re: [PATCH] GIT commit statistics. Message-ID: In-Reply-To: <46a038f90511120419v70166c60t93d58b7544e03e3b@mail.gmail.com> Hi, On Sun, 13 Nov 2005, Martin Langhoff wrote: > [...] 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