Re: git rebase -i

From: Jeff King <peff@peff.net>
Date: Feb 19, 2009, 10:07 UTC
Message-ID: <20090219100743.GA16119@coredump.intra.peff.net>
In-Reply-To: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com>

On Thu, Feb 19, 2009 at 09:21:49AM +0000, John Tapsell wrote:

>   I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
> doesn't matter if you go back 'too far' I just always use HEAD~10 even
> if it's just for the last or so commit.

Here are some reasons not to go back too far:

  1. The commits are displayed in order, so the ones that are
     interesting to the user are at the bottom. And HEAD~10 may display
     more than 10 commits in the face of non-linear history.

  2. rebase -i does not preserve merges by default. Which means that if
     HEAD~10 is not a linear history, then you are flattening the graph
     structure.

>   Would there be any objections to making  'git rebase -i' default to
> HEAD~10  or maybe 16 or 20.  Having sensible defaults for commands
> helps a bit with making it easier to use.

If you wanted to do something like this, a much more sensible cutoff would be the location of an upstream tracking branch (e.g., as defined by branch.*.rebase). Then you are literally asking for commits which have not been published in your upstream, which means it is OK to rewrite history (assuming they were not published elsewhere).

-Peff