To rerwite history or not - that's the question

[Isaac Jurado]

On Thu, Feb 21, 2013 at 5:27 PM, Kevin Bullock
<kbullock+mercurial at ringworld.org> wrote:
> On 21 Feb 2013, at 10:14 AM, Isaac Jurado wrote:
>
>>  - In Git there are quite a few ways to rewrite history, as part of
>>    its massive combinations of commands and options, which could also
>>    induce you to think that history rewriting is allright.
>
> Minor nit: Git mostly has just one command that hides a number of
> different ways of rewriting history: git-rebase. Pretty sure we
> actually have more -bundled extensions- in Hg that provide different
> rewriting methods than Git has built in.

Yes, you're right about Mercurial extensions.  Still, Git can rewrite
history by means of multiple commands.  I don't know Git very deeply,
but I do know that there are at least two commands that can perform
rebase (git rebase and git pull --rebase) and at least two commands that
can squash commits (git merge --squash and git pull --squash).

Sometimes, while I'm looking through the Git man pages I remember a
famous flame [1] and find some irony after applying some of those
thoughts on the infinite combinations of git commands and options.

>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>
> Good point, I'd forgotten about this. IIRC, the model referenced
> actually recommends merging with ancestors just to avoid
> "fast-forward" merges -- so that you can always see when a sync
> between repos happened. Hg prevents you from merging with an ancestor
> in most cases.

Simplicity wins, at least for me.

Cheers.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci