Mercurial: Onward and upward

Re:Mercurial: Onward and upward by Skinney on Friday May 01, 2015 @03:27AM (#9469977)

Hey, if you don't use the index then don't use the index. Use git commit -a. If you wan't something like the index in Mercurial you have to specify which files you want to commit, or which to exclude, which IMHO is a lot more tedious and error prone. Then again I haven't used Hg in a couple of years, could be they have something like the index now.

Rebase is a hack? Rebase copies a series of commits on top of an immutable history at a certain point in time. This allows you to deal with merges a single conflict at a time, instead of dealing with all the conflicts at once with a merge. It also allows you to avoid cluttering your history with useless merge-commits when just syncing with another repo.

Merges have their place. I use them whenever I merge branches, using --no-ff so I can attach a "Fixes issue #77" in the merge commit message. Of course, before I do that, I sync the branch I'm merging into, then rebase on top of that (to have a clean merge). I might also rebase --interactive to clean up the commits of my branch, so that the history is as easy to read as possible.

Comparing rebase to rollback is wrong. Git has rollback (or revert) as well, and it's used for other usecases, like when reverting changes on a public branch (where rebase would fuck it up for everyone).

I'm sorry, but your comments make it sound like you don't really understand Git.

[ Parent | on HN ]

Re:Mercurial: Onward and upward by imakesnowflakes on Friday May 01, 2015 @10:03AM (#9471299)

>Rebase allows you to deal with merges a single conflict at a time, instead of dealing with all the conflicts at once with a merge...

Not sure what you mean by 'deal with a single conflict at a time'. To rebase or merge, you will have to resolve all conflicts that merge/rebase produce, right?

[ Parent | on HN ]

Re:Mercurial: Onward and upward by Skinney on Friday May 01, 2015 @06:53PM (#9475012)

Yes, but a rebase re-applies every commit to the new base. So you solve conflicts one commit at a time, instead of solving every conflict in a single merge commit.

It's easier to remember the intended behaviour when the code changes are as small as possible, and when you have a (hopefully) good commit message to look at.

[ Parent | on HN ]

Re:Mercurial: Onward and upward by imakesnowflakes on Friday May 01, 2015 @09:44PM (#9475540)

I am not sure it make any difference to the user at all. If you use a merge tool, it will present the conflicts one at a time for merging and re-basing.

If you are concerned about reading history, then a merge can give you more context regarding the commits. With re base, commits will jump between features. For example, You are looking at commit for feature 1, but the next series of commits are for a bug fix in feature 2. Next series of commits belong to minor tweaks in feature 3..

[ Parent | on HN ]

Re:Mercurial: Onward and upward by Skinney on Sunday May 03, 2015 @12:39AM (#9479949)

A merge will provide you with a single commit-message, rebasing will provide you a commit-message for every commit, making it easier to remember what the intent of a change was. Sometimes that isn't clear.

Regarding the "rebase, commits will jump between features" part: that really depends on how you do things. On my projects, we use git flow. In such a scheme, every branch you would rebase, belongs to the same feature or bugfix.

[ Parent | on HN ]

Re:Mercurial: Onward and upward by imakesnowflakes on Sunday May 03, 2015 @12:57AM (#9480003)

>In such a scheme, every branch you would rebase, belongs to the same feature or bugfix..

Not sure if I made that clear. But I was talking about the result of the rebase. Once you rebase, all the commits that were in different branch ends up being back to back, and hence become interleaved...

[ Parent | on HN ]