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

41–50 of 201 posts

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

#41

Post by asdfaoeu »

ggchappell wrote: post #33

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

I can see your point but the fundamental problem is that unless you have a simple linear history a DVCS can't possibly know how to merge and apply patches without some heuristics. At best the DVCS can be a tool to assist you.

There is of course a lot of simple tasks which DVCS can and do apply near perfectly but I suppose managing a complex project you're at some point going to have to have a basic understanding of how the system works.

I've used IBM's RTC which is an excellent GUI VCS tool that I believe internally works similar to git/hg but it attempts to hide how its internals works so on a large merge 500+ changesets and then remerging more commits it refused to push despite saying no incoming changesets. We ended up fixing it by pulling to a different repository based of the branch we were trying to merge from based of advice from support. But I'd prefer a deterministic cli interface over a gui interface anyday.

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

#42

Post by tednaleid »

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…

That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more.

[1]: http://tednaleid.github.io/showoff-git-core-concepts/

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

#43

Post by MikeTLive »

Ive been using perforce/p4 since 97. the last 8 years have been coupled with P4V and the eclipse plugins. My workflow is virtually identical to the much offered Git branching model [0]. Turn it -90deg with time left to right. Rename "develop" to "trunk". and think of "master" as being the release labels. release and feature branches are created from the build label of the previous release needing special changes that can not just go into trunk or when we want to do a minimal patch-only release. a developer makes local copy of the portions of the trunk they want/need. the server knows who has what opened for edit/add which makes checkins fast. only the change must go in. same for regular update of my local workspace. we rarely have people editing the same exact file and if we do its a simple resolve in P4V during your commit or integrate activity.

So far, there are FEW benefits i see to using, or switching to, GIT: LOCAL REPOSITORY - I have the whole repo for what i am working on so can work remote easier LOCAL VERSIONING - I can create lightweight local branches that duplicate only what is required without resync of my local repo POPULARITY - all the cook kids are using it so lots of ops utilities now are built expecting it to be there under the covers.

I can live without the LOCAL benefits. I have for 8 years. I worry about the third - popularity vs. merit.

Where are the concrete comparisons showing all the features and functions of these solutions side by side and how they compare for a student, startup, or enterprise?

EDIT: found a newer perforce:git comparison on the perforce site[1]. The LOCAL REPO/VERSIONING is available with P4SANDBOXING.

I suppose modding me down is appropriate since i picked up on the POPULARITY aspect of the discussion and don't have any Hg experience. However, it seems these discussions just keep happening and there is no one-true-solution or approach. they each have merits and faults. it will be the careful consideration of these that leads to your own solution implementation. The popularity of GIT appears to be its strongest argument.

EDIT2: located a GIT-v-Perforce on SO.[2]

so many of the diffs, however, have been met with sandboxing

It really appears the strength is in popularity - everyone else uses GIT so you should too…

[0]: http://nvie.com/posts/a-successful-git-branching-model/ [1]: http://www.perforce.com/sites/default/files/pdf/perforce-git... [2]: http://stackoverflow.com/questions/222782/git-vs-perforce-tw...

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

#44

Post by sampo »

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…

> To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard.

Every version control system has a way to overwrite a dirty (modified) work directory, so git is hardly any more dangerous than any other tool.

It also won't help you get back uncommitted files that you destroy with `rm`. No other tool does, either.

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

#45

Post by jlgreco »

tednaleid wrote: post #42
jlgreco wrote: post #32

Earlier quoted context omitted.

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…

That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more. [1]: http://tednaleid.github.io/showoff-git-core-concepts/

My point is that git-reset --hard can remove data from the working tree filesystem that never hit the DAG in the first place:

  $ git init                                          
  Initialized empty Git repository in /home/john/tmp2/.git/                    
  $ echo "foo" > foo                                  
  $ git add foo                                       
  $ git commit -m 'init'                              
  [master (root-commit) 84fb5d1] init                                          
  ...                                                                          
  $ echo "bar" >>foo                                  
  $ cat foo                                           
  foo                                                                          
  bar                                                                          
  $ git reset --hard HEAD                             
  HEAD is now at 84fb5d1 init                                                  
  $ git reflog                                        
  84fb5d1 HEAD@{0}: commit (initial): init                                     
  $ git status                                        
  # On branch master                                                           
  nothing to commit (working directory clean)

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

#46

Post by jlgreco »

sampo wrote: post #44
jlgreco wrote: post #32

Earlier quoted context omitted.

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…

> To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Every version control system has a way to overwrite a dirty (modified) work directory, so git is hardly any more dangerous than any other tool. It also won't help you get back uncommitted files that you destroy with `rm`. No other tool does, either.

To be clear, I think that the behaviour of git-reset --hard is absolutely appropriate. I am just correcting the overly strong statement: "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."

There are situations that reflog won't get you back from, but those situations are perfectly logical and appropriate exceptions.

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

#47

Post by w0rd-driven »

tracker1 wrote: post #2

I really appreciated that this response was not overbearing, or just raw opinion, and rather compared many of the similarities and differences from mercurial to git, and how they approach similar issues differently. Honestly, I've struggled in moving from SVN/TFS to GIT, but it's been worthwhile.. having local branching, and being able to work locally is great. I can't really compare this to hg, as I haven't worked w…

SourceTree is good if you can handle the .NET 4.5 requirement. At work, we can't risk the breakage 4.5 can possibly do to 4.0 apps and can't force customers to upgrade for 2/x applications so I don't bother.

My first foray into DVCS was Mercurial through Kiln and subsequently TortoiseHg. It's always been great but the introduction of the workbench made everything gel. Having all of the UI in one spot made the experience that much easier. It makes discovery pretty simple compared to TortoiseGit/SVN where you have to know what each menu item maps to.

I've since moved to GIT for work and personal use. GIT flow sold me as hg flow really didn't feel equivalent. I also like submodules as they make proper segregation that much easier. Hg has patch queues which made working on items that weren't commit ready easy. At the time, I didn't understand feature branches so I should likely revisit Hg earnestly. Hg has always had a better user experience where error messages aren't cryptic but there's a wealth of knowledge online to solve any problem in either DVCS at this point. There's some spots in git where you still need the command line where TortoiseHg seemed to cover every need I had.

TFS finally supporting git as a repository, despite its caveats (convert once, only vs2012+) will likely push git pretty far. Having used Ankh, I was never impressed. I'd rather use tortoise + git source control plugin or git extensions as the experience is definitely sufficient. I actually prefer the tortoise workflow over doing it all in vs though but there's a bulk of what we do outside of vs anyway so being proficient there helps tremendously.

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

#48

Post by rallison »

driverdan wrote: post #25
jheriko wrote: post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

I'm guessing the reason you're getting downvoted is because it sounds like you don't know how to use git. That may not be true, it just sounds that way. > the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. Please explain. How is it dangerous? How can it leave you in an unrecoverable state? > why can't i roll back a merge in…

I think this gets to one of the issues people who have previous source control experience have with git. They apply the concepts from, say, subversion to git, and then have trouble.

Take branches for example. In subversion, branches were heavyweight, scary things. In git, they are extremely lightweight, in that they are really nothing more than a pointer to a specific commit. They almost shouldn't even share the same name, they are so different.

Basically, I found that I got much better once I stopped trying to apply my old understanding of subversion to git, and especially once I just started playing around with git commands on a dummy repo, to fully understand what was going on. Now that I've done that, I would never switch back to subversion. Perforce, maybe, but only for certain very specific scenarios.

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

#49

Post by voltagex_ »

taspeotis wrote: post #34
rallison wrote: post #10

Earlier quoted context omitted.

Even better, one can specify a mergetool in their config, and use a standard diff tool to resolve conflicts.

At work, my Git repos are exclusively C# and I've been using SemanticMerge [1] for resolving conflicts to good effect. [1] https://www.semanticmerge.com/

It's a pity they're a subscription and also they want me to log in to view the pricing.

Edit: There is a once-off price and also somewhere to apply if you're working on open source.

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

#50

Post by voltagex_ »

w0rd-driven wrote: post #47
tracker1 wrote: post #2

I really appreciated that this response was not overbearing, or just raw opinion, and rather compared many of the similarities and differences from mercurial to git, and how they approach similar issues differently. Honestly, I've struggled in moving from SVN/TFS to GIT, but it's been worthwhile.. having local branching, and being able to work locally is great. I can't really compare this to hg, as I haven't worked w…

SourceTree is good if you can handle the .NET 4.5 requirement. At work, we can't risk the breakage 4.5 can possibly do to 4.0 apps and can't force customers to upgrade for 2/x applications so I don't bother. My first foray into DVCS was Mercurial through Kiln and subsequently TortoiseHg. It's always been great but the introduction of the workbench made everything gel. Having all of the UI in one spot made the experie…

Have you tested 4.5? What breaks?
Post reply on HN