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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
