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