User: Password:
|
|
Subscribe / Log in / New account

Bazaar on the slow track

Bazaar on the slow track

Posted Sep 12, 2012 15:03 UTC (Wed) by robert_s (subscriber, #42402)
In reply to: Bazaar on the slow track by danpb
Parent article: Bazaar on the slow track

"Once you've learnt GIT, its breadth of features means there is no compelling reason to carry on using things like Mercurial"

I too am am Mercurial user who's been "forced" to learn git, but The compelling reason that causes me to still manage _my_ projects in mercurial is the fact that it's _much_ harder to shoot yourself in the foot in mercurial.

Even once you've got past git's steep and puzzling learning curve, working with branches in git feels a bit like doing a difficult juggling act with HEADs, and if you accidentally drop one of them (or even just accidentally specify the targets the wrong way round in a git rebase) you can spend an entire afternoon looking for the remains in git fsck.

And then of course there are the nice things like commit phases that mercurial have been adding lately.


(Log in to post comments)

Bazaar on the slow track

Posted Sep 12, 2012 15:54 UTC (Wed) by mgedmin (subscriber, #34497) [Link]

It's easier to recover from a bad rebase with git reflog than with git fsck.

Bazaar on the slow track

Posted Sep 13, 2012 0:06 UTC (Thu) by nix (subscriber, #2304) [Link]

Quite. I'd venture to say that if you're using git fsck, you haven't had a hardware failure, and you're not hacking git, you're probably doing something unnecessary. It's *that* reliable. (I'd actually almost forgotten that git fsck existed: I haven't run it in anger in years.)

I concur that it is nearly impossible to lose work in git: making a new branch before doing something you're scared about suffices in basically all cases, and if you forget that there is the reflog. I've done massive history rewrites and routinely do partial history rewrites and tree partitions and have never lost a byte. (Having said that, I'm sure something horrible will happen now and I'll lose the last year's work or something. Not even git is immune to Murphy's Law.)

Bazaar on the slow track

Posted Sep 12, 2012 19:20 UTC (Wed) by price (guest, #59790) [Link]

> if you accidentally drop one of them [...] you can spend
> an entire afternoon looking for the remains in git fsck.

You want to use the reflog. Take two minutes and read about it right now:
http://gitfu.wordpress.com/2008/04/06/git-reflog-no-commi...
http://www.kernel.org/pub/software/scm/git/docs/git-reflo...

You will be much, much happier as a result the next time you drop something. Once you know about the reflog, it's virtually impossible to lose anything in a Git repo that you ever put into an actual commit, no matter what you do subsequently.

(The main exception is if you only realize you wanted it weeks after discarding it. By default Git does eventually garbage-collect commits that no refs point to.)

Bazaar on the slow track

Posted Sep 12, 2012 21:03 UTC (Wed) by robert_s (subscriber, #42402) [Link]

Thanks for this - will probably save me a lot of time.

Bazaar on the slow track

Posted Sep 12, 2012 23:43 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> Once you know about the reflog, it's virtually impossible to lose anything in a Git repo that you ever put into an actual commit, no matter what you do subsequently.

AFAIK, the reflog is deleted when the branch is deleted. So if it happened on a branch you later deleted, you just lost the reference and it is git fsck time.

I would prefer if it left the reflogs for deleted branches around, and garbage-collected them later.

Bazaar on the slow track

Posted Sep 12, 2012 23:55 UTC (Wed) by price (guest, #59790) [Link]

Even when you delete a branch, the old commits will all still be in the reflog for HEAD (unless they're past the expiration time anyway -- or you delete HEAD itself, which is beyond the ken of normal Git commands.) So they'll still show up in 'git reflog show' (which refers to HEAD by default), and you can still recover them just fine.

I do agree that it would be better if Git kept the reflogs around. A case where this does matter is if you want to keep an archival record of changes to the repository, e.g. in a organization's central repository that everybody pushes to. It's simple to configure Git never to expire old reflog entries (see gc.reflogexpire and gc.reflogexpireunreachable in git-config(1)), but AFAIK there's no way to configure it to keep reflogs of deleted refs.

Bazaar on the slow track

Posted Sep 16, 2012 12:44 UTC (Sun) by kleptog (subscriber, #1183) [Link]

I'm a git user "forced" to learn Mercurial. While I agree that Mercurial has many of the same features as git, I feel git works much better for my workflow. The index, "git add/remove -p" and "git rebase -i" are my very close friends.

The first thing I noticed is Mercurial's rigid adherence to "committed is unchangeable". For me a commit is more a checkpoint, but it's not necessarily something finished. Usually I develop something as a series of patches, commit various bug fixes and use rebase to fold the bugfixes into the appropriate patch.

I was relieved to find the MQ extension which gives you much the functionality but with a very obtuse UI. The phases you point to seem to be a further step in the right direction. Though I feel their painting themselves into a corner since now a review tool like Gerrit becomes impossible: you push to the review tool which would make your patch immutable, while the whole point of the review is to be able to fix the patch!

Other rough edges: that the "pager" extension is not standard, there is no justification for "hg log" on the terminal filling your scrollback buffer with the entire history of your project. The "color" extension could also be better advertised.

My feeling is that git is a tool for people who deal with large numbers of branches and patches daily, and Mercurial is for people push a few patches around occasionally.

Bazaar on the slow track

Posted Sep 16, 2012 13:04 UTC (Sun) by dlang (subscriber, #313) [Link]

I ran across this post some time back, it seems to fit what I know on the subject quite well

http://xentac.net/2012/01/19/the-real-difference-between-...

Bazaar on the slow track

Posted Sep 17, 2012 18:31 UTC (Mon) by luto (subscriber, #39314) [Link]

I used to agree, except that I've shot myself in the foot numerous times using Mercurial in ways that would be impossible in git. Git never throws away commits until you ask it to. Mercurial throws them away in the process of rebasing, and it even requires you to strip things before you rebase their ancestors. This means that, if the rebase screws up [1] [2], then you lose data.

[1] Mercurial also seems to screw up more often. When it finishes embracing the three-way merge, it'll work better. The Mercurial tools certainly are prettier, though.

[2] Mercurial is worse at doing bizarre merges than git. At some point I'll dig up the example that broke Mercurial and file a bug. At least this failure mode doesn't eat my data. (Basically, the git "recursive" algorithm, while imperfect, is better than Mercurial's approach of choosing an arbitrary base from the set of bases with no possibility of overriding the choice.)

Bazaar on the slow track

Posted Sep 26, 2012 9:34 UTC (Wed) by makomk (guest, #51493) [Link]

git rebase should always save the previous state of the branch being rebased in ORIG_HEAD, so if you screw it up and get the branch names the wrong way around you should just be able to do "git reset --hard ORIG_HEAD" so long as you realise immediately (or "git rebase --abort" if the rebase failed partway through).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds