Re: git and bzr

Jakub Narebski [off-list ref] writes:

By the way, short option -i is not --index but --include (i.e. commit
both changes in index and files mentioned on command line). Perhaps -I?

Just in case nobody noticed after looking at the first part of
my patch a few nights ago, --include happens to mean exactly
what --index would mean anyway.

By default, "git commit" without parameter does "make a commit
out of the index".  With paths, it used to mean "oh, by the way,
I forgot to run update-index on these paths, so could you please
do that for me now before you make the commit", and has been
that way for a long time.

Much later, people from CVS background wanted to say "edit foo
bar; git update-index bar; git commit foo" to mean "I might have
done something to the index, but I do not want to care about it
now -- please make a commit that includes only the changes to
bar and I do not want the changes to foo included in the
commit".  Somehow we ended up introducing that twisted semantics
and that was where --only came from, which unfortunately later
became the default (and I already said that I realize this was a
big mistake).

While we transitioned to switch the default, we first came up
with a name to ask for the traditional semantics (--include),
warned people who gave paths without either -i nor -o that the
--include semantics is still the default but would change soon
(which meant that -i was a no-op back then), then switched the
default and we now warn that the default is now -o (so now -o is
a no-op) when people give only paths without -i nor -o.

Currently (that is, without the first part of my two patches),
"git commit -i" and "git commit -o" without paths refuse to
work, saying that these modes of operation do not make sense
without any path.

However, you can think of the simplest "commit the current
index" semantics as a degenerated case of saying "oh, by the
way, please run update-index on these paths I forgot to do
earlier before you make the commit" and giving no paths.

So "git commit -i" without paths _could_ mean "commit the index
as is" very naturally without introducing an independent switch
with different name.  That is what the first part of my two
patches to Carl does.

Hi,

On Thu, 30 Nov 2006, Junio C Hamano wrote:

Somehow we ended up introducing that twisted semantics and that was 
where --only came from, which unfortunately later became the default 
(and I already said that I realize this was a big mistake).

If you are talking about "git commit file1 file2" ignoring the current 
index, and building a new index just updating file1 and file2 from the 
working directory, I disagree that it was a big mistake.

Actually, I was very happy to get that change (IIRC it was me requesting 
it, so blame me), because I now can say: just specify exactly what you 
want to commit *1*.

If you want to commit just file2 (even if you added file1, but did not 
commit it yet) do "git commit file2". If you want to commit all changes, 
either pass the names of all modified files, or "-a". IMHO this satisfies 
the principle of least surprise.

Ciao,
Dscho

Footnote 1: Of course, you can use commit in more ways. But this is 
sufficient to get people started.