Main Area and Open Discussion > General Software Discussion
DVCS ? (All about Git, Mercurial-Hg and the like...)
Armando:
Cool then! I just wish I had more time to play with Git myself these days. I use it minimally, but I did a few merges etc. successfully. I mainly use git's GUI (the one that comes with Git by default) and tortoise Git these days.
=====
C- Some Detail about Git’s Index and "Content based" structure
(This is approximately where I left imy thoughts last time, when I answered Shades' question... So I might as well continue from there.)
so... What's the Git index?
Scott Chacon in Pro Git (an excellent manual, which can be read online) explains :
The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
--- End quote ---
John Wiegley, in "Git From the bottom Up", writes :
Unlike other, similar tools you may have used, Git does not commit changes directly from the working tree into the repository. Instead, changes are first registered in something called the index. Think of it as a way of “confirming” your changes, one by one, before doing a commit (which records all your approved changes at once). Some find it helpful to call it instead as the “staging area”, instead of the index.
--- End quote ---
While I personally love the concept of staging area and the way Git uses it (I'll tell you why after), not everybody does. Steve Losh Writes :
One of the features that git users talk about often is git’s index. Mercurial has the record extension, but it’s not really the same thing.
I personally don’t like the index. I feel that git encourages people to check in changesets that contain code which they’ve never tested (or even built) because the index is such a prominent part of git’s workflow.
Yes, one can argue that you don’t actually push changes until you’ve got a working state. The problem is that when you then try to run git bisect later to find a bug you’ll have to waste time skipping over changesets that don’t build. You could use git rebase --interactive to fold partial changesets into one big one, but again, my gut feeling is that few people actually bother testing the results.-http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/
--- End quote ---
I'm not an experienced programmer, but I think that the staging area (index) is very useful. I use it all the time as it's very convenient when you need to group similar changes together. I.e. : if you worked a while without committing anything, you can decide to commit your work in parts using the staging area. Of course you run the risk of having a few commits that won't compile, but then, as M. Losh says, you can just do a "git rebase --interactive to fold partial changesets".
What's telling is what Losh says afterward:
With all that said, I’ve considered creating a Mercurial extension that adds git’s index functionality to Mercurial, because I think it would make the transition to Mercurial easier for git users. I’ve had enough experience with Mercurial’s internals to know that such a thing is possible, but I simply don’t have the time to do it all myself. If you’re interested in helping out please let me know!
-http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/
--- End quote ---
... So maybe this index isn't that useless after all. :)
Not all GUIs out there allow to granularly add parts of file changes to the index. The “vanilla” Git GUI allows it very easily (select part of the code you want to “stage” and add them to the index; when you’re finished, commit the whole thing).
While I now realise it's probably not as related as I first thought it was, Git's use of an index is still coherent with the way it keeps track of files changes by storing content, not files.
In "Git Internals", Scott Chacon writes :
It is important to note that it is the contents that are stored, not the files. The names and modes of the files are not stored with the blob, just the contents.
This means that if you have two files anywhere in your project that are exactly the same, even if they have different names, Git will only store the blob once. This also means that during repository transfers, such as clones or fetches, Git will only transfer the blob once, then expand it out into multiple files upon checkout.
--- End quote ---
This "content driven" structure (if I may say so) has 2 implications I'll try to write about next time -- I'm already late for my next meeting !
ewemoa:
Thanks Armando, for your continued efforts :Thmbsup:
As the topic of the index / staging area in Git is being touched upon, perhaps the following two extensions in Mercurial might be of interest:
http://mercurial.selenic.com/wiki/RecordExtension
http://mercurial.selenic.com/wiki/CrecordExtension (demo video)
The record extension provides the record command, which may be used in lieu of commit. This command lets you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks.
--- End quote ---
The crecord extension is a curses (i.e. text-based GUI) interface which provides the crecord and qcrecord commands that may be used in lieu of commit or qnew -f. These commands let you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks or lines.
--- End quote ---
I've used both and much preferred the crecord extension experience (see video link above for a sample). There were a few times when crecord didn't seem to take note of some things I wanted committed -- but perhaps this has been fixed by now as it has been over half a year since I used Mercurial.
At:
http://kevin-berridge.blogspot.com/2011/04/mercurial-record.html
I encountered the following:
sometimes you forget to be proactive about separating your changes and then you want to untangle them after the fact. You can do this using the Record extension. This is another extension that ships with Mercurial, but you have to enable it to use it.
The Record extension is invoked with "hg record" and will go through the files you've changed (or just the ones you tell it to look at) and will iterative over each change "hunk" in the file. A change hunk is a set of sequentially changed lines. For each hunk it asks you if you want to record the change or not. You simply say "y" if you want it, and "n" if you don't.
The result is a new commit that contains the changes you recorded. It's a surprisingly easy process.
However, there's a flaw with this approach. The resulting commit might be broken: it might not compile, or the tests might not pass. And since it turns directly into a commit, you don't really get the chance to test it...
--- End quote ---
Armando:
Thanks ewemoa :up: .
the Record and Crecord Mercurial extensions definitely allow a similar workflow.
There's also the MQ extension (Mercurial Queue). I remember liking MQ a lot.
I don't have the time to discuss that in depth, but I also remember that I found it easier to work with the "index" like features in Git using the GUI (Git GUI), than with Mercurial (Tortoise Hg). Things are changing fast though and I'll revisit tortoise Hg in a while to see how it does this whole "partial commit" thing.
ewemoa:
There's also the MQ extension (Mercurial Queue). I remember liking MQ a lot.
-Armando (May 10, 2011, 10:01 AM)
--- End quote ---
This looked interesting to me, but I never tried it out. Perhaps some day...
I don't have the time to discuss that in depth, but I also remember that I found it easier to work with the "index" like features in Git using the GUI (Git GUI), than with Mercurial (Tortoise Hg). Things are changing fast though and I'll revisit tortoise Hg in a while to see how it does this whole "partial commit" thing.
--- End quote ---
Looking forward to nicer UIs :)
Perhaps I'll try out gitsum for Emacs in the mean time:
http://chneukirchen.org/blog/archive/2008/02/introducing-gitsum.html
BTW, any thoughts on the likes of:
http://nvie.com/posts/a-successful-git-branching-model/
Armando:
I haven't forgotten this discussion... :)
I'm just lacking time these days !... But I plan to continue to contribute to this thread with reflections about Git and Mercurial's various aspects -- although I'm more focused on Git, since this is the tool I chose. (Did I mention earlier that I not only decided to use Git because I like it but also because is my various tests it was easier to convert a Git repo to Mercurial than the reverse ? :-[)
=====
Perhaps I'll try out gitsum for Emacs in the mean time:
http://chneukirchen.org/blog/archive/2008/02/introducing-gitsum.html
--- End quote ---
Cool stuff. I'll have to check that out.
BTW, any thoughts on the likes of:
http://nvie.com/posts/a-successful-git-branching-model/
--- End quote ---
Branching is an interesting topic. It's good to see the different strategies used among developers. I saw the article you're referring to a few weeks ago.
The problem is that in my own current project, I don't really need to "branch" that much. It's just not worth it. So I haven't explored that area a whole lot. I've read about it though.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version