User: Password:
|
|
Subscribe / Log in / New account

Vernooij: Bazaar-NG: 7 years of hacking on a distributed version control system

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)
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 )
"svn ls REMOTE/trunk/dir" to list all files under dir
"svn cat REMOTE/trunk/dir/file" to actually see the interesting one for me

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? ;-) )
2. what is the content of the file NOW, regardless when was it modified -- 1 commit back, or 1000 commits back

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
index 4bf3dc4..5508113 100644
[...]

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 (subscriber, #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
- there wasn't anything that did git rebase -i nearly as easy last time I tried (which I use often, but could probably be get used to missing if there was painless merge resolution (see git mergetool) and something like git rerere).

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
[2]Technically, "were" since I'll be using something to convert any Mercurial repository I use over to git first. The verbiage change just doesn't work well with me.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds