Re: git and bzr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> 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.

When I wrote that paragraph, I said:

        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).

But ignoring the index was not because of that command sequence,
as you reminded me in your message I am replying to.  It was to
allow this sequence, which is natural with CVS:

	$ git-checkout  ;# existing project that did not have Makefile
	$ edit hello.c  ;# to fix wording of the message
        $ edit Makefile ;# anybody who is self respecting should have one
	$ git-add Makefile ;# do not forget to add it
        $ git-commit hello.c ;# the fix is important independent of Makefile
	... then maybe the next commit is to add Makefile ...

If you view this sequence with CVS mindset, there is nothing
surprising about the commit _not_ committing Makefile in this
example.

But if you come from the school that "git-add" is about adding
"the contents (and the path, but only because content cannot be
added without the path)", and if you already understood that
"git-commit" without parameters nor options is a way to make a
commit out of the index, it certainly is counterintuitive.  

Granted, parameters and options are ways to affect what the
command does, but usually it does so by modifying and enhancing
what the command does without breaking the basic premise.  What
the --only does is quite different -- it bypasses the index
completely.

In fact, what it does is _so_ counterintuitive that I did not
even remember what the real motivation behind it was, and sent
my message with a much more implausible sequence which had an
explicit update-index (no sane person would do that).  That
should tell you something.

Remember, new peole will not stay "newbies" forever.  The
original "inclusive" semantics is a lot easier to explain once
you get what index does.  The way to introduce "index" to people
Nico proposed would not have to talk about "Ah, but there are
these two twists" if we did not make the --only the default
semantics.  What I find a big mistake is not the --only option;
the mistake is that it is the default.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]