Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mercurial developer responds to "Switch to git?"

groups.google.com

Post reply on HN
Print view View original

191–200 of 201 posts

Re: Mercurial developer responds to "Switch to git?"

#191

Post by mrtngslr »

oleganza wrote: post #172

"The local revision numbers play no role here -- btw, they're just an (arbitrary) ordering of the commits in your local repository. No magic there." I disagree. Mercurial is famous for its "simple" revision numbers that differ between repositories. These revision number are magical as they can suddenly change when you merge some branches and older commits get pulled into your history. Since mercurial and git are most…

Revision numbers are stable within a given repository. The revision number for a commit is simply the index of the commit in the changelog — nothing more. Since a changeset must come after its parent in the changelog, the revision numbers give you a topological ordering of the changesets. A topological ordering is often not unique — this is why revision numbers can differ between repositories, even if they contain exactly the same commits.

Because the changelog is append-only, new commits you pull in get higher revision numbers than the existing commits. Your existing revision numbers will thus not change when you do 'hg pull' and 'hg merge'. We don't actually guarantee that revision numbers cannot change when you pull, but it's been the case until now.

In any case, the stability of the revision numbers isn't why we like them — we like them since it's often easier to type 'hg histedit 12345' than 'hg histedit c38c3fdc8b93' when you've looked up a particular changeset in your (local!) repository.

Hosting sites like Bitbucket and Kiln will wisely not show you revision numbers since the concept is meaningless when talking about more than one repository.

Re: Mercurial developer responds to "Switch to git?"

#192

Post by yread »

naitbit wrote: post #167
gbog wrote: post #135

Earlier quoted context omitted.

Maybe you could let git influence and hopefully improve the way you work. For instance, when refactoring something quite complex with good test coverage, you want each commit to be the smallest atomic commit that can pass all tests. But you also want to very quickly and "carelessly" add debug logs, assertions, changes in many files. For this kind of task I have found the following workflow to be very helpful and fast…

I'm sure that git with it's very powerfull backend has way for improving way someone works, but I'm not convinced by this example. IMO it shows again that usability of git is far from perfect. For example in bzr to accomplish this task you can: 1. (same) 2. (same) 3. put all changes that you are not interested in on shelve: `bzr shelve` (or qshelve if you want QT gui) 4. Run full test suite 5. If 4. fails keep editin…

I feel like a complete idiot coming from bzr to git, it just seems so much better designed.

Re: Mercurial developer responds to "Switch to git?"

#193

Post by jammycakes »

steveklabnik wrote: post #94
jammycakes wrote: post #68

Earlier quoted context omitted.

I'd just like to respond to all the people who are saying "Use the reflog" here. Yes, you can recover lost commits using the reflog. But it is not well publicised that you can do this. Most tutorials do not mention it and most Git GUIs do not expose it. It is also not functionality that you expect to exist, so you are not likely to think to Google it. Unless you are an advanced Git user, your commits are indeed, to a…

Doesn't the large number of people saying "use the reflog" indicate that amongst git users, they know that it exists?

Probably. It's one of those things you learn as a Git user sooner or later -- though in most cases, not before a few heart-stopping moments and probably a bit of an injection of FUD into your team.

Rather more worrying is the possibility of deleting history remotely with an injudicious git push --force. Some such remotes (coughGitHubcough) don't give you any access to the reflog on their end to sort things out.

Git really needs to set receive.denyNonFastForwards and receive.denyDeletes to true by default.

Re: Mercurial developer responds to "Switch to git?"

#194

Post by gbog »

naitbit wrote: post #167
gbog wrote: post #135

Earlier quoted context omitted.

Maybe you could let git influence and hopefully improve the way you work. For instance, when refactoring something quite complex with good test coverage, you want each commit to be the smallest atomic commit that can pass all tests. But you also want to very quickly and "carelessly" add debug logs, assertions, changes in many files. For this kind of task I have found the following workflow to be very helpful and fast…

I'm sure that git with it's very powerfull backend has way for improving way someone works, but I'm not convinced by this example. IMO it shows again that usability of git is far from perfect. For example in bzr to accomplish this task you can: 1. (same) 2. (same) 3. put all changes that you are not interested in on shelve: `bzr shelve` (or qshelve if you want QT gui) 4. Run full test suite 5. If 4. fails keep editin…

> 3. put all changes that you are not interested in on shelve

Usually what I want is the opposite: cherry pick a few changes, increasingly adding them to the staging area (or index in gitspeak), because oftentimes I have a change that I am not sure is required for this patch.

I was very unconvinced by the staging area thing when starting using git and tried to avoid it, but in fact it is very powerful and not that complex. I do not know bzr and only used hg for a few months so maybe they have similar tools, but my main point is not git against the other, it is learn power uses of the tools to help improve workflow, against the claim that dcvs should be not our concern.

Re: Mercurial developer responds to "Switch to git?"

#195

Post by Dylan16807 »

TylerE wrote: post #97
rocky1138 wrote: post #82

Earlier quoted context omitted.

You can actually get back files that you rm. I've seen it done. Apparently it has something to do with unmounting the drive, restarting in single-user mode, then finding/knowing where it is on the drive before the OS overwrites it (hence the unmount).

Doesn't generally work with modern FS's that use more "clever" allocation schemes.

I'm not sure what you mean. The 'clever' filesystems I'm aware of are copy-on-write, which makes it much easier to recover deleted files. Unclever filesystems, like NTFS, are also quite easy to recover files on. I've had to do so multiple times.

Re: Mercurial developer responds to "Switch to git?"

#196

Post by mrtngslr »

jlgreco wrote: post #112
functional_test wrote: post #106

Earlier quoted context omitted.

Exactly. Although rebasing is convenient, it does involve taking destructive actions on a repository which is ostensibly a tool to make sure your data isn't lost. The feeling in the Mercurial community is that this is potentially dangerous and not necessary. Really, it would be best if there was some way to retain the original commits while rebasing to clean the history. Time for a new DVCS?

> Really, it would be best if there was some way to retain the original commits while rebasing to clean the history. Time for a new DVCS? When you rebase, commits are not lost. If there is a ref pointing at them then they will continue to stick around. If there isn't then the next time that gc is run they would be removed. The solution to what you are looking for is to precede each rebase with a command to 'anchor' t…

> I think people hear "rewrites history" and let their imaginations run wild with sci-fi tales of wonder, only then to think of the grave horrors such power would enable... but forget to look at what actually is happening when you "rewrite history" in git. There is no reason to fear it.

Yeah, I very much agree with this. Rewriting history is a tool, a very powerful tool. It's something you can use if you want to.

It reminds me a little of a discussion I had recently with a developer who mostly used statically typed languages. I'm using to dynamically typed languages like Python and JavaScript, so it was puzzling for me to hear him talk about the horrors of dynamic types. He said things like "I pass a Person object to a function and the function might do anything with it -- like adding new methods and fields to it!". Yes, it is true that you can add a new method to an object in most dynamically typed languages. No, adding methods and fields by accident is not really a problem in real life.

Just because you have the option of doing something, doesn't mean that you must do it.

Re: Mercurial developer responds to "Switch to git?"

#197

Post by jeltz »

jheriko wrote: post #125
jeltz wrote: post #72

Earlier quoted context omitted.

Good point, the reflog should be mentioned earlier in tutorials.

i don't think thats a fix at all. i still think it should be possible to revert a merge with a single command and no flags. the volume of questions about this on stack overflow and co. and the variety of answers, some of which i'm sure i tried and found not suitable, suggests that this is a real user experience problem. alternatively their should be a decent ui solution to hide this stuff and it should be packaged wi…

You do not use the reflog to revert a merge. You do it to undo a messed up rebase, and I am not sure if that is something which you want to fix automatically. I think using the reflog here might be better, maybe with a shortcut to make it easier to reset to a point in it.

Re: Mercurial developer responds to "Switch to git?"

#198

Post by nbouscal »

jheriko wrote: post #148
nbouscal wrote: post #29

Earlier quoted context omitted.

If your comment gets downvoted, it's much more likely to be because it is simply inaccurate. Git is remarkably safe out of the box. Git makes it damn near impossible to lose anything other than intentionally. No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog. Even if you start doing the really dangerous…

I appreciate the effort you have made in trying to educate me here. I have recreated the problem I originally had and documented precisely why I think it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh. http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

It looks like your troubles came purely from not understanding the concept of fast-forward merges. I completely agree with you that the documentation does not make this as clear as it ought to. However, the standard book on git (Pro Git, available free online) covers this (and most other git concepts) very well. This is simply a case of not understanding your tools (which you did acknowledge in the post). This is a widespread and deeply problematic situation, not just for version control systems but for almost all software, and it seems to only be getting worse. Takeaway lesson isn't that there's anything wrong with git, but rather that there's something wrong with an industry that seems to think we should be able to use tools without first learning how they work.

Re: Mercurial developer responds to "Switch to git?"

#199

Post by nbouscal »

jlgreco wrote: post #32
nbouscal wrote: post #29

Earlier quoted context omitted.

If your comment gets downvoted, it's much more likely to be because it is simply inaccurate. Git is remarkably safe out of the box. Git makes it damn near impossible to lose anything other than intentionally. No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog. Even if you start doing the really dangerous…

To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Of course --hard is not on by default so... there is no issue here with git's default behaviour. > "Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex." Yup, exactly. The simplicity of git's model is hugely important. It allows me to…

You're completely right, I should have clarified that I was only talking about committed data. My mistake.

Re: Mercurial developer responds to "Switch to git?"

#200

Post by nbouscal »

jheriko wrote: post #86
nbouscal wrote: post #29

Earlier quoted context omitted.

If your comment gets downvoted, it's much more likely to be because it is simply inaccurate. Git is remarkably safe out of the box. Git makes it damn near impossible to lose anything other than intentionally. No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog. Even if you start doing the really dangerous…

Your definition of safe is not mine. I have no doubt the data is preserved - 'unrecoverable state' is too strong. Its not safe in the sense that if i make a change on submission day and need to revert it then its more complicated than it needs to be. Granted I should not be using something I don't have sufficient mastery of in that kind of scenario, but its not always so simple. My data being 'safe' is worthless if t…

The learning curve is not that steep. Compare it to learning vim or emacs, for example, and it's no contest. The learning curve is basically: 1) read Pro Git, 2) play with git for a little while. That's about it. If you can't afford that learning curve for something that is a core part of your workflow, you're doing something wrong.
Post reply on HN