Re: Separating "add path to index" from "update content in index"

[Nicolas Pitre <nico@cam.org>]

On Thu, 21 Dec 2006, Carl Worth wrote:

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

Strangely enough I think this separation is unnecessary and redundent.

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

And it is still there.

> 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 you can do just that with git-update-index.

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

The problem lies with the git-diff interface then, not git-add.

> [*] 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 .".

There is no consistency needed between git-add and git-update-index.  
The first is for users while the second is more suited for scripting 
your own interface.

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

I think you are trying to solve the wrong problem, or at least solve a 
problem the wrong way.  The problem is that git-diff doesn't give you 
the output you expect because of the index interfering in your work 
flow.  And I understand that.

But the best solution is really for git-diff to have a mode where you 
could display a diff between the work tree and the index, _or_ the index 
and HEAD, for each file listed in the index while giving priority to the 
former.

This would let you see a diff of everything that would be committed, 
including new files, if you were to do commit -a.  Maybe -a/--all should 
be used with git-diff for such a mode by symetry with git-commit -a. (OK 
-a is already taken but I doubt it is really used and it already has a 
longer equivalent so changing it would not do real harm).

With this, for users acustomed to "commit -a", the natural and pretty 
consistent way to see a diff for such a commit before actually 
performing it would bi "diff -a".  Isn't it logical?


Nicolas