On Thu, 21 Dec 2006 16:52:51 -0800, Junio C Hamano wrote:
> Peter Baumann <Peter.B.Baumann@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> > I'm also not so confident about mixing "add NEW files" with "updating
> > the contents of already known files".
>
> File boundaries do not matter ;-) You are adding contents.
I don't follow.
There's more than just content here. The index contains a list of
paths as well, and a command like "commit -a" iterates over that
list. The addition or removal of a path from that list is a conceptual
notion that's very important to the user and the kinds of thing a user
does on a regular basis.
> But that is a phylosophical answer, not a practical one, since
> majority of the time (unless you are talking about the first few
> weeks of a new project) you will be adding contents that happen
> to be in the files git knows about.
I don't think it's practical to write off addition of new paths as
unimportant or uncommon except in the beginning of projects. Projects
grow new functionality and files get added. Code gets refactored and
files get renamed. The addition or removal of paths from the index is
just as important an operation as changing content of existing paths.
And I still think there are remaining interface problems that git has
in this area. For example, my most common sequence of operations when
hacking code is as follows:
# edit files
git diff # to review what I've done
git commit -a # to record it
Recently, I did some edits and also added some new files. I did:
# edit files and make new ones
git diff # only edits appear here
Hmm... did I forget to add those new files?
git add new-file.c
git diff # still only shows the edits
At this point I can exercise my git mental muscles and know that "add"
shoves stuff into the index so what I really want is:
git diff HEAD # shows edits and new file contents
Regardless of how hard those git muscles may be to come by---I still
don't like having to exercise them here.
I complained about this when I first encountered git, and back then I
said what I thought I wanted was "git diff HEAD" by default. I was
totally wrong, since diff from the index is so obviously correct for
resolving a conflict. Junio even responded to my complaints by
providing a new "git status -v -a" but frankly I've never used
it. That's awful awkward to use when "git diff" is so easy to type and
_most_ of the time is exactly what I want.
I'd really like "git diff" to be what I want more often. So what I'd
like is to be able to get the index in such a state that typing "git
diff" like I always do would show me everything I just typed,
(regardless of whether it was in files that git had seen before or
not).
So, I think what I really want here is a complete separation in the
interface between adding a path to the index and updating content into
the index.
We've long had a command that updates content to the index, and it
takes a command-line option (--add) to allow it to first do the
necessary path addition as well. The symmetry I would like is if we
had a command, ("git add", say), that just did the path addition and
could accept a command-line option (--update, say) to get it to the
the updating of the content as well.
And I think that any talk about "git cannot accept a file name without
content" is misplaced. The proposal here does not change any internal
models of git. I'm talking about an interface issue, and if the
interface isn't helping the user then it's wrong. That "git diff"
usually shows me what I've just typed but I can't (easily[*]) get it
to do that when I'm adding a new file is really annoying.
[*] Well, I could get it to do that by carefully creating the file,
running "git add" immediately, and only _then_ going on to type
content into the file. But that's not how I work. I do a bunch of file
manipulations without thinking about git at all, and then when I'm
happy with that, only then do I want to turn to git and use "git add",
"git diff", and "git commit" to get the results I want.
So I suppose I could implement the "add path without updating content"
I want by doing something like:
mv file file.tmp
touch file
git update-index --add file
mv file.tmp file
There. That gives me the result I want without breaking any git
internals, (since I'm just building a new operation on top of existing
git primitives).
> Carl talks about would be useful in practice. I do not know
> what the option should be called.
>
> "git add --modified"?
> "git add --tracked"?
> "git add --updated"?
>
> It would work in the same way as the pre-commit step of "git
> commit -a".
I think the best would be:
git update-index --all
which would still allow room for:
git add --all
as a consistent way to get at the current behavior of "git add .".
So here I'm arguing against "git add" being a more convenient synonym
for "git update-index". I still think it would be nice to have a more
convenient synonym. I've proposed "stage" before but that wasn't well
accepted. Just shortening "update-index" to "update" would be
problematic as many other RCSs use "update" as a way of picking up new
content that has become available on the remote end. So, the best
suggestion I have at this point is "refresh". So I'd be happy if
either:
git refresh --add
or:
git add --refresh
would provide the behavior that currently is provided by "git add",
(that is, add a new path to the index and update the content of that
path in the index from the content of the named file in the working
tree). But it would be great if "git add" without the --refresh would
add the path without updating the content.
-Carl
Attachment:
pgp5h5t9bCEzr.pgp
Description: PGP signature