#Git tortoisehg ssh how to#

> Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts. If you commit a changeset originating from a merge conflict, you have to explicitly state that the conflict was resolved and your changes are good.

In git, users determine whether a conflict is resolved or not. > tfs: can't commit unresolved merge conflicts git: commits just fineĪgain, this doesn't make sense. You use local branches to track independent work. Git stash is a way to quickly get to a clean local workspace that can be reversed as you see fit. I don't think your comparison makes sense. > 1) tfs: shelves are named and can be worked with independently git: stashes (.)

#Git tortoisehg ssh how to#

Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.Ħ) tfs: all commits in a branch are visible, it's not obvious how to delete them, you can only create rollback commits git: if something happens to the branch label, the commits are gone. Maybe it's ide integration quality, but FWIW:ġ) tfs: shelves are named and can be worked with independently git: stashes are numbered in a sort of a stack and only the top stash is unpacked and deleted destroying your data, infuriating, also local edits are moved into the stash, not copied.Ģ) tfs: branches are mapped to different folders and can be worked on simultaneously git: branches are mapped to single folder and switching branches deletes local edits.ģ) tfs: pulling from server merges new text preserving local changes git: pull and checkout deletes local changes.Ĥ) tfs: can't commit unresolved merge conflicts git: commits just fine, it's also not obvious if you have merge conflicts to commit or not.ĥ) tfs: handles concurrent edits as merge conflicts and handles them as they occur git: you create feature branches and in case of concurrent branches you have merge conflicts when you merge to master, then you have p.4. If you're interested, can compare tfs to git. I want to see more ideas be spread and that people can see that there can be a world beyond git. I really hope that git is not the final word in version control. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. HipHop VM for PHP, Apache Hive, MyRock these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it. I figured they would emerge a few years later with their fork of it. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless.Įventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. I was wondering when this would happen.įacebook used to be involved with the Mercurial community, but it was difficult to work with them.