Chris's Wiki :: blog/tech/GitAddMatters Commentshttps://utcc.utoronto.ca/~cks/space/blog/tech/GitAddMatters?atomcommentsDWiki2012-05-30T17:31:21ZRecent comments in Chris's Wiki :: blog/tech/GitAddMatters.From 204.197.193.163 on /blog/tech/GitAddMatterstag:CSpace:blog/tech/GitAddMatters:dd62e41559ca0b6277b618f04dedcf6fc3e7407eFrom 204.197.193.163<div class="wikitext"><p>The very first thing anyone should learn about using git is to run <code>git status</code> early and often.
When learning git, the behavior of <code>git diff</code> initially struck me as a bit
odd but because I was in the habit of typing <code>git status</code> often, I never thought anything had disappeared.</p>
</div>2012-05-30T17:31:21ZFrom 31.101.48.219 on /blog/tech/GitAddMatterstag:CSpace:blog/tech/GitAddMatters:9c224e75b5c8537d1b49aa53e299f00430d57efbFrom 31.101.48.219<div class="wikitext"><p>I have to agree. It took me quite a while to grok the point of the index. I now think that it is a major feature of git and as you say quite a difference from other version control systems. I think that any tutorial about git should really start with trying to explain an index based workflow rather than trying to mimic other systems.</p>
</div>2012-05-30T10:23:23ZFrom 193.62.202.242 on /blog/tech/GitAddMatterstag:CSpace:blog/tech/GitAddMatters:1a3d12984ec7353e3fcf4b87b791180cafb8c9baFrom 193.62.202.242<div class="wikitext"><p>I still miss the way Perforce handled this. (I thought Perforce was very elegant in general, but I suppose I'll never use it again now that free software has caught up with it -- i.e., the DVCSes, I wouldn't say Subversion ever caught up.)</p>
<p>Edited files are added to the default changelist, but you can create additional pending changelists and move opened files between them. Then <code>p4 submit</code> commits the default changelist, while <code>p4 submit -c</code> <em>NUMBER</em> commits the specified changelist.</p>
<p>So by default you get the add-less Mercurial model; but if you are working on several things at once, you can have the equivalent of multiple indices, each with their description/commit message attached while you're working on them.</p>
<p>It's not as general as the git model (changed files as a whole are listed in changelists, so simultaneous disjoint works-in-progress have to involve disjoint sets of files), but it's a very simple and effective way of tracking multiple items of work in a single checked-out tree.</p>
<p>-- John</p>
</div>2012-05-30T08:55:43ZFrom 87.79.236.202 on /blog/tech/GitAddMatterstag:CSpace:blog/tech/GitAddMatters:e7679546568f0a3b4ce2ab461eb1fd8a8af45ddeFrom 87.79.236.202<div class="wikitext"><p>I’m trying to think of what I do and finding myself not being able to say, until I realise that what I do most often is to actually commit “blindly” and then use <code>git show</code> (aliased <code>git v</code>) to check if the commit was what I expected. That makes sense if you consider that how trivially easy Git makes it to throw away a mistaken commit and do it over.</p>
<p>If I am composing a very complex commit then I’ll use I use <code>git diff --cached</code> (which I’ve aliased as <code>git di</code>, to go with my <code>git d</code> alias for <code>git diff</code>).</p>
<p>Otherwise it really depends. Generally with the use of <code>git status</code> etc as part of the work in general, I’ll have an accurate gut feel for what I’ll be committing, so it feels natural not to be meticulously cautious up front but to just do a quick double-check after the fact.</p>
<p>It amuses me to realise that this is just another aspect of the same theme that for me permeates the use of Git at every level – that it frees me to cruise along instead of planning ahead, by letting me act first and decide later, and letting me back up a step or three when necessary.</p>
<p>The index, of course, is just another part of that.</p>
<p>So during the first paragraph of your article I was poised to argue, but then I quickly agreed as I read on. There absolutely is more to learn with Git than other VCSs due to the index. And as you predicted, I will argue that it is completely worth the cost. I wouldn’t want to work without it any more.</p>
<p>(Does Mercurial have a way to amend the last commit to add or remove bits, and a way to throw away the last commit without affecting the working copy? Together with <code>record</code> that would allow it to get very close to offering the functionality of the index, if with a more awkward interface.)</p>
<p>As for <code>git commit -a</code> – no, this sure won’t turn Git into an index-less system. One big reason is that there is no way whatsoever around using the index for resolving merge conflicts. It does often allows skipping an explicit step in practice, though.</p>
<p>More importantly, however: when it comes to an absolute novice, particularly someone who has never used any VCS before, the <code>-a</code> switch is a very useful didactic tool, as it allows the lessons in teaching Git to be staggered. The index and the extra steps it requires can be postponed until after the novice has a basic familiarity with the system. They <em>will</em> have to learn the index very soon, there is no way around that. But the <code>-a</code> switch can help reduce the amount of detail they have to learn all at once.</p>
<p>The other commenter’s suggestion to start with <code>git gui</code> is also great, though. I had not really thought of that. Making implicit invisible state explicit and visible is always a great way to make abstractions tractable for human brains. (We have an amazing aptitude for forming unconscious abstractions in order to manipulate concrete entities; we’re not near as capable at reasoning over abstractions consciously.)</p>
<p>—<a href="http://plasmasturm.org/">Aristotle Pagaltzis</a></p>
</div>2012-05-29T11:38:44ZBy Chris Siebenmann on /blog/tech/GitAddMatterstag:CSpace:blog/tech/GitAddMatters:bc2b16a90320cc39a621770f23fa2471d50ae32bChris Siebenmann<div class="wikitext"><p>It's probably worth being explicit about one reason why Mercurial-style
handling is easier at the start: in Mercurial, the diffs that '<code>hg
diff</code>' shows you are always exactly the changes that '<code>hg commit</code>' will
commit. This leads to a simple workflow:</p>
<pre>
; hg diff
[silent, so there's no uncommitted changes]
; vi file1 file2 file3
; hg diff
[test as necessary, possibly repeat]
; hg commit
</pre>
<p>It's not just that this workflow has a step or two less than the git
equivalent; it's also that this workflow is tolerant of interruptions
at any point without having to remember where you were in the various
steps and then potentially repair or complete index manipulations. The
git pre-commit check requires multiple commands and is more intricate
(especially if you get interrupted or have to change things partway
through).</p>
<p>(I think the thorough version would be '<code>git status; git diff; git add
...; git commit</code>' all as one logical action without interruptions,
assuming that you are starting with nothing added to the index. You
don't want to do <code>git add</code> until right before you commit so that you
can keep using the simple form of <code>git diff</code> to see what you'll commit.)</p>
</div>2012-05-29T10:35:19ZBy Chris Siebenmann on /blog/tech/GitAddMatterstag:CSpace:blog/tech/GitAddMatters:357f5399d185e5f42e0bb39e93de95e62b3a8e8fChris Siebenmann<div class="wikitext"><p>Mercurial does git-like partial commits through a (standard) extension,
the <a href="http://mercurial.selenic.com/wiki/RecordExtension">record extension</a>.
This seems to be roughly equivalent to '<code>git commit --interactive</code>', with
the same drawback that you have to do it on the fly and can't prepare and
check it in advance.</p>
<p>(I suppose the Mercurial way is to make the commit in a private repo,
possibly clone the repo to check out the state of everything, and then
roll the commit back if it wasn't good.)</p>
</div>2012-05-29T10:14:20ZFrom 195.26.247.141 on /blog/tech/GitAddMatterstag:CSpace:blog/tech/GitAddMatters:1b016b4226031fe6c4f2bb2356f39355d78c2290From 195.26.247.141<div class="wikitext"><blockquote><p>git diff shows no changes after add</p>
</blockquote>
<p>To be honest, I've never found this to be a problem, and you can always do "git status" to see what is/isn't going to be committed.</p>
<p>With Mercurial I assume that commit (by default) always says to commit all changes. So if you regularly want to commit only a subset of the changes then you'll need an extra step, or to stash them elsewhere? (I've not used it)</p>
</div>2012-05-29T08:15:04ZFrom 78.86.151.9 on /blog/tech/GitAddMatterstag:CSpace:blog/tech/GitAddMatters:bf5f0533479e1856a29f7a32fa7b7adc76b8d2b5From 78.86.151.9<div class="wikitext"><p>My advice for people new to git is always to do commits with 'git gui' for a while. The UI of 'git gui' makes the purpose of the index obvious, and its use trivial.</p>
<p>(There may be platforms where 'git gui' is a pain to install. That's not the case on Linux, although distros tend to package is separately from the main git package, so you need to know about it to install it.)</p>
</div>2012-05-29T07:18:53Z