Mercurial's changeset evolution sounds really powerful and seems to address the 'git rebase and force push' problems that can occur.
Mercurial developer responds to "Switch to git?"
71–80 of 201 posts
Re: Mercurial developer responds to "Switch to git?"
#72i 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'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…
Good point, the reflog should be mentioned earlier in tutorials.
Re: Mercurial developer responds to "Switch to git?"
#73Articles 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…
A filesystem is a tool we use to track and store data related to a project.
A DVCS is a tool we use to track and store data related to a project, collections of that data, changes in that data over time, changes in that data made by others, pointers to certain states, and the relationship of all of those things.
What you're really saying is that the filesystem API/UI is simpler than a DVCS API/UI.
My argument is that, a filesystem can be reduced to a simpler UI because it does fewer things.
We may not have found the simplest possible DVCS API yet, but it by nature is going to have to be more complicated.
Re: Mercurial developer responds to "Switch to git?"
#74Having used both extensively, Git at one job, HG at the next, now Git again, I mostly have this to say:
Both tools lack polish.
The biggest piece of mis-information I'd like to clear up is that often times a user new to either of these makes a few mistakes and then the cold hand of death grabs them and they're certain they lost work. You never really do. In Mercurial, the permanent nature of named branches and in Git the reflog both serve you well. Seek help in such a case, because if you think you lost work, you almost certainly didn't.
Edit:
Also, if you're using HG and not using patch queues, you're doing it wrong. Just sayin'
Re: Mercurial developer responds to "Switch to git?"
#75Earlier quoted context omitted.
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 (i…
Ok, yes, I agree with that clarification (and I missed that you specified in your original comment "uncommitted work", my mistake). If you git reset --hard and you have a dirty working directory, you can absolutely blow work away. That's one of the main reasons to use git reset --hard, but I agree that it needs to be used with intention. The easiest way to protect against it is to never use it if you have a dirty wor…
I guess maybe the counterargument is that perhaps this should happen invisibly and automatically.
Re: Mercurial developer responds to "Switch to git?"
#76i 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,…
False.
If you ever thought you lost work in Git, it's POSSIBLY because you overwrote your working copy. That is, code that hasn't been committed yet. But once you commit -- hell, once you just "git add" to the index -- your work is safe and won't be garbage collected off the disk for at least 30-45 days.
Re: Mercurial developer responds to "Switch to git?"
#77Author/thread starter here: Really didn't think this post would have generated as much interest as it did when I created it... :D
It's a fairly enlightening thread though. Mad props to Martin for a fantastically thoughtful reply!
Re: Mercurial developer responds to "Switch to git?"
#78Ive 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…
I'll mention that a number of the answers covered in this StackOverflow post [1] (note, that post is old, so it is entirely possible that perforce has improved since then) cover a number of the reasons I prefer git over perforce, but, for me, cheap branching and speed (due to everything being local) are probably the two biggest. Cheap branching, especially, completely changed my workflow. When a branch is effectively…
you found the same one that i did while editing.
if git is great, is it worth changing an enterprise to use it?
when the auditors come, I need to list the changes on a server. when its an app, the changes to that app. who, what, when, where, why - reviewer, requestor, approver, author, deployer, etc.etc.etc.
how granular and how far back can i get this with GIT?
how solid is the nonrepudiation factor with GIT?
for commits - can i see who else might be looking at code?
for security - can i protect others from getting the code?
Re: Mercurial developer responds to "Switch to git?"
#79Articles 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…
DVCS's solve a hard problem where there isn't a single obvious way of thinking about it. There's no easy solution to managing multiple concurrent streams of development. And everyone has their own different ideas about what's the best way to solve it.
I've used tools that are "simpler" than git: subversion for one. My experience has been that this simply means that they don't handle more difficult version control scenarios that do occur in practice. Subversion, in particular, just has a tendency to throw up it's hands and leave you to manually merge changes in any non-trivial merge scenarios.
Re: Mercurial developer responds to "Switch to git?"
#80i 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,…
> (...) 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. It's almost impossible to leave git in "an unrecoverable state", short of actually deleting your ".git" directory. If you do wind up in a bad spot, that's what the ref-log is for [0]. If you've made an error that is difficult or complicated to unwind, no sweat: hit…
I will concede that it might be safe in this sense - unrecoverable is too strong a word.
My real world experience of this is that twice I've seen people frantically trying to work out this same problem of reverting a change and finding it difficult even to get a copy of the repo that matches the desired state. Granted it works easily in the most common case, but I've never seen thus problem arise with cvs, svn, hg or p4...
Its sensible to use simpler tools if they are more practical, ie I have to learn less to get what I want from those tools.
This seems to be a general problem with git currently - many commands need lots of switches or background knowledge to become useful and its really not necessary IMO. It would be nice to see that improve...