Re: RFC: rebase without pain

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Jun 14, 2008, 11:17 UTC
Message-ID: <20080614111758.GB5737@dpotapov.dyndns.org>
In-Reply-To: <5B4BD573-8C89-4E27-8ADB-F870EA503D00@vicaya.com>

On Fri, Jun 13, 2008 at 06:38:44PM -0700, Luke Lu wrote:

> This may have been discussed before, but I could not find it. If so, I  
> apologize for the noise and hope somebody is working on the issue.

I think we have had a somewhat similar discussion not so long ago. It was called "inexplicable failure to merge recursively across cherry-picks". I think you can find it here: http://kerneltrap.org/mailarchive/git/2007/10/9/333729

Please, read carefully this Linus' posts: http://kerneltrap.org/mailarchive/git/2007/10/10/334129 http://kerneltrap.org/mailarchive/git/2007/10/11/335451

Show 5 quoted lines

> 
> Based on my observation, rebase is the single most interesting and  
> misunderstood feature in git compared with other VCS. Once I  
> discovered rebase -i, I can't stop using it, because I'd like to keep  
> my history clean for readability and maintenance purpose.

The downside of rebase is that you are *re-writing* branch history. It is okay when you do that in your private branch, but when you publish something there is no way back. It is like when you prepare on some article, you can make a lot of drafts but when you publish it then it is published. Any attempt to falsify history will cause a lot of confusion. Also, please, notice that even if a branch was rebased without a single conflict, it does not mean that it will work. So, you can break things just by rebasing and it will be impossible to find later who caused the breakage. Sometimes, even if the final state after rebase is working, the intermediate commits may not work or even not compile.

So, I don't think that rebasing published history is a good idea.

Dmitry