for "prior knowledge" (expectations) from using other systems?because its command-line interface is incoherent and confusing at best,
See my initial post as one example for lots of technical advantageswith no overall technical advantage over most other VCSs.
Even for those who started their journey into VCSs with Git.for "prior knowledge" (expectations) from using other systems?
You mean the "lots" as in "one, i.e. rebase"?See my initial post as one example for lots of technical advantages
Lots of people disagree. Just sayingEven for those who started their journey into VCSs with Git.
Interesting straw after stating you'd prefer svn. Now argumenting with a different distributed(!) system is clearly moving the goalposts. Still, automatic reordering sounds nice, but can't solve all the problems. "rebase" (with manual reordering) is explicit and works, and the OP is about how well git detects stuff that can be automated with this explicit strategy.Well, git rebase is a good example for things which exist in Git as a workaround for a conceptual disadvantage. It would not even need a "rebase" command if it adopted Darcs's patch strategy.
FWIW, people reading this thread might try to find that claim. Spoiler: that's futilePeople who disagree with your claim that Git was better than every other VCS in even one single aspect
Thanks a lot!I think I'll end this discussion here.
Reaction score: 31
y'know, just about all software is like that - 20 solutions on SO and in other places. This is partly why we have FreeBSD forums - a community of users who can help you think things through, and make sense of what you see on the Internet. FWIW, I recently had the same experience with Apache setup - 20 different partial solutions on the Internet, and then the forum users right here helped me with commentary and examples. I was able to decide on what to do pretty quickly - much quicker than if I had to comb through SO and other partial solutions on the Internet.I use Mercurial for everything personal, and have it mirrored to git where needed.
I don't find git to be very user friendly, my gitconfig is set up with aliases to make my life easier but often I will force push through any issues because my time is not worthless and I've got better things to do than read 20 minutes of the genius of stackoverflow offering up 20 different solutions of which almost all are outdated, broken or just don't work at all. I'd certainly pick git over SVN or CVS though *shudders*
Reaction score: 1,746
Yes, but there's no other single SCM system that has all the features of Git. I hear great things about Perforce, and many very successful companies started out using it, but it's closed source. Heck, Linus probably got a lot of the ideas for the design of Git from using Bitkeeper in the kernel for years - also closed-source. Mercurial has a very nice command-line interface, but its Web interface is ass, and it's in the maw of the Python 2 -> 3 monster at the moment.
I switched to Git the very first time for very good reasons. Svn simply could not handle having the master branch merged back to a feature branch repeatedly. It would think every previous merge was a conflict. One of us had to spend sometimes days disentangling the BS conflicts from the real ones. We switched to Git, and that problem simply went away. It was one of those things that doesn't happen, but it did, and now I'm a confirmed Git fanboi for life.I have to say that git might be a bit of jumping on the bandwagon. Using git because Linux did and no other reason. There are still detractors who have a point. The only reason I started using it, years ago, is cause I had a project that required it and they only started using it because...because....errrr...uh...they don't know.
Wrong.Yes, but there's no other single SCM system that has all the features of Git.
We considered both Mercurial and Git, and chose the latter because it already had wider adoption.
Bitkeeper does not support signed revisions and it's no longer developed. I've already explained why I'm glad I didn't choose Mercurial, but according to the chart you linked, it does not support Unicode file names in Windows. Seems like a big deal to me.
Not always a bad thing.