| |||||||||||||
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 14:34 UTC (Thu) by yarikoptic (subscriber, #36795)In reply to: Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system by jengelh Parent article: Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system
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.
(Log in to post comments)
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
|
|||||||||||||