| |||||||||||||
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control systemVernooij: Bazaar-NG: 7 years of hacking on a distributed version control systemPosted Dec 20, 2012 8:41 UTC (Thu) by dgm (subscriber, #49227)In reply to: Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system by Lukehasnoname Parent article: Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system
Many people complain that git naming and commands are inconsistent, and that it's somehow difficult to learn. Yet it's very successful, more than more consistent and "easier" dvcs. How is that possible?
I think there are some factors. One, of course, is the Torvalds factor. But there are more. The most important one is that, in fact, you only need a dozen commands and four or five concepts to make good use of git. From there on, you can grow organically.
But the most important factor is that git has reached the critical mass of help around faster. Should I have any problem doing anything with git, 99.99% of the time a bit of google-fu leads to the solution, and usually leads you to discover something new you didn't know was possible. That's very rewarding. It's very possible that this mass of help and workflows floating around in blogs and forums is caused by git's own "imperfections". Another case of worse-is-better, maybe?
Finally, there are always "easy git" (and the rest of alternative "porcelain") for those that like more consistent names and commands. It's nice and delivers as promised, but I personally gave up and went with the default. The added value of the forums and blogs is just to big to be ignored.
(Log in to post comments)
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 10:32 UTC (Thu) by jengelh (subscriber, #33263) [Link]
>How is that possible?
Maybe people started to realize it is not the UI "bling" (or lack thereof) that counts, but having the implementation Done Right, and all that _while_ retaining or increasing productivity (measurable; PHBs counting commits per time in the SCM).
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 14:34 UTC (Thu) by yarikoptic (subscriber, #36795) [Link]
It is like a Bible -- there was GIT and its UI was crap and then HG and Bzr came with a nice UI... People keep repeating that but either I was too early an adopted of GIT or that is just a matter of different personal preferences. Sure thing I do not remember my initial feelings about GIT cmline UI but I had no real difficulty starting to use it efficiently once I understood what staging area is, what is remote and then what branch is (former CVS experience helped to comprehend that); and 4 so "difficult" to remember commands: 'clone', 'commit', 'push', 'pull' which were sufficient for the basic use. But with adopting GIT mentality I got crippled in HG and Bzr -- any time I need to use them, I feel frustration since some things do not make sense to me, or things are just way too slow, and as a result I do not have work done. Then I come back again to git-hg/bzr helpers to just get things going.
So, for anyone who is asking me if that is indeed true that HG/Bzr is easier on the mortals' brains -- I am answering "Maybe, but not", giving them 5 minutes "tutorial", explaining them the meaning of RTFM, reference them Git foundations by M.Brett (http://matthew-brett.github.com/pydagogue/foundation.html) for a night fun reading, and people usually become happy GIT users down the road.
Is GIT perfect? nope -- indeed I wish GIT had similar got SVN and Bzr handling of remotes without needing local clones, but those usecases come rare enough. And hopefully land in some state in GIT in the future.
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 15:52 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Is GIT perfect? nope -- indeed I wish GIT had similar got SVN and Bzr handling of remotes without needing local clones, but those usecases come rare enough. And hopefully land in some state in GIT in the future.
Shallow clones work just fine.
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 16:11 UTC (Thu) by yarikoptic (subscriber, #36795) [Link]
really?
may be I have missed the bus -- how would I accomplish with a shallow clone something similar to
"svn log REMOTE/trunk" to get recent activity on the trunk (or a particular file of interest )
without fetching e.g. 100MB of the current content of the REMOTE's master treeish?
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 16:59 UTC (Thu) by hummassa (subscriber, #307) [Link] git clone --depth 20 server:git/repo will not get the whole tree, but just the info and files for the last 20 commits git log # will show the last 20 commits ls dir cat dir/file
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 17:09 UTC (Thu) by yarikoptic (subscriber, #36795) [Link]
exactly -- I need some intrinsic knowledge of how many commits I need to fetch and then fetch all files touched by those, but the point is that I do not know how many commits, and I do not want to fetch anything irrelevant. I just need to
1. see what files are there NOW (after all GIT is a content tracking, right? ;-) )
svn (and probably bzr, according to the blog -- I never used those features myself) provide such functionality. I did need it a few times too. That is why was my comment
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 17:20 UTC (Thu) by hummassa (subscriber, #307) [Link]
You are right, but I usually set up gitweb for those needs.
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 18:13 UTC (Thu) by tuna (guest, #44480) [Link]
I thought that git does not have files, only changes?
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 19:59 UTC (Thu) by jengelh (subscriber, #33263) [Link]
The other way around. Basically, Git stores complete objects rather than some delta thing. Creating some commit whose diff reads
diff --git a/net/ipv4/netfilter/ipt_ECN.c b/net/ipv4/netfilter/ipt_ECN.c
will get you a .git/objects/55/0811365ac655c3b2d4f9183112e15ad0ae17ba. It is compressed, but it is still standalone/complete/non-deltified. You can nuke all other objects, and git show 550811365 should still succeed.
Deltified packs are a strap-on option (one that's enabled by default because of its usefulness) to the base design.
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 19:30 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
umm, One of us is misunderstanding something
doing a
git clone --depth 20 server:git/repo
doesn't give you only the files that have changed in the last 20 commits, it gives you ALL the files in the project, as they existed (changed or not) for the last 20 commits
so if you only care about what the files are NOW you can do "--depth 1", no need to know when it changed.
If you want the last 20 changes of a file, and that file hasn't changed for the last 1000 commits, then you really do want the full history, because the file may not have changed 20 times since it was created
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 21, 2012 3:13 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Some more anecdata (I'm a heavy git user):
I was using Mercurial for < 1 hour and hit a (what I consider to be) data-loss bug[1]. Granted, I didn't really read a proper hg tutorial, but the bug is still basically untouched even with a testcase and is marked as a bug because I used hg "wrong". My biggest problems with it are[2]:
- no index (this is the real killer for me using it day-to-day); and
I understand git being a little steep at first (but so is Vim, emacs, etc.). Understanding how git views things is a core part of groking it enough to be proficient with it. Basically, I don't care as much about the learning curve of tools I use every day, I just require them to let me get my work done. "Intuitiveness" is useless to me. I'd rather it work and work well. If I used Mercurial every day, with the way I've gotten accustomed to working, I'd probably hit that bug at least once a week.
[1]http://bz.selenic.com/show_bug.cgi?id=3423
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 20, 2012 15:19 UTC (Thu) by nix (subscriber, #2304) [Link]
The irony here is that for me at least I found git nice and simple because it had a clear core model in which it was easy to build up -- yourself -- whatever workflow you preferred. Bazaar tried to make things simple by adding explicit support for lots of workflows, but unfortunately that means you need to understand them all before you can figure out how the tool works and how to use it.
The number of such workflows, many closely similar, and all accompanied by deep changes in the behaviour of lots of bzr commands, is frankly overwhelming. I still can't keep them separate in my head despite much trying. And I am not the only one (there was a comment in the recent bzr-development-stopped thread which said much the same, and that thread was mostly populated by longtime users and developers of bazaar).
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 21, 2012 5:28 UTC (Fri) by dpotapov (guest, #46495) [Link]
> Many people complain that git naming and commands are inconsistent, and that it's somehow difficult to learn.
Some complains about Git being difficult to learn comes from its early days. (Before Git 1.5.0, Git did not have any UI suitable for normal folk, and then the user documentation was somewhat scarce or confusing as it often referred to some low-level "plumbing" commands, but many issues got fixed over time.)
Now I think most complains come from people who try to use Git in a centralized workflow as if it were CVS or SVN. Git appears unnecessary complex for that workflow and does not follow CVS naming convention. While Mercurial and Bazaar has tried to make some things more CVS like, Git has focused more on better support of distributed workflows and general flexibility. (Linus Torvalds is known for his disdain to CVS: "I'm trying my best to be a humanitarian and rid the world of the scourge that is CVS, but I'm not sure I can undo the untold mental damage wrought by it over decades of quiet suffering.")
"Easy to use" is rather subjective, it often depends on past experience and your workflow. In simple cases, usually you can see one to one match between Git, Mercurial or Bazaar commands, though those names may be different. For example, "git pull" = "bzr update" = "hg pull --update".
Apparently, Bazaar uses "update" due to tradition going back to CVS, where developers periodically use "cvs update" to merge their own (not yet committed ) changes with the upstream. In the Linux kernel workflow, developers are discouraged from doing unnecessary merges their topic branch with the current 'master' branch. Typically, it is the upstream maintainer who pulls changes and resolves possible conflicts. Thus 'pull' makes more sense in this context: Linus Torvalds does not update his master branch, he pulls new changes from his lieutenants.
Another thing is that Mercurial and Bazaar tries to give you a nice set of basic commands but for anything else you need plugins (or extensions in Mercurial). If you install Git, you get a lot of power out-of-the-box, so naturally it comes with more commands, and Git does not try to hide useful things from you (like the staging area). So some people find it more difficult in the beginning, but once you understood the core model of Git, most things immediately start to make sense, and Git is more transparent in what it does.
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 23, 2012 12:09 UTC (Sun) by juliank (subscriber, #45896) [Link]
Please note that bzr pull exists as well, and bzr merge. The equivalent to git's pull is bzr merge, as far as I can tell.
Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system Posted Dec 27, 2012 13:10 UTC (Thu) by cstanhop (subscriber, #4740) [Link]
> How is that possible?
Github.
|
|||||||||||||