On Fri, 22 Dec 2006, Carl Worth wrote:
> On Fri, 22 Dec 2006 00:06:32 -0500 (EST), Nicolas Pitre wrote:
> > 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.
>
> One argument I would make in favor of the separation is that the two
> operations are conceptually distinct from the user point-of-view. But
> that's really hard to nail down since all users have different points
> of view and different conceptual models,
... and if we want to break the CVS model and give people a better
chance of ever grasping the git index concept I think they should not be
different.
> (though I think the recent
> post about similar file names and accidentally adding a file meant to
> be untracked is evidence in favor of this argument).
This could be used as evidence for anything. "Oh I wanted to delete
this file but that file had a similar name and I deleted the wrong
one."
> There's a much less fuzzy, and strictly technical argument that can be
> made. Right now, we document "git add" as being useful for two
> purposes, ("adding new files" and adding "modified files...to the set
> of changes").
[...]
> The technical argument for separating the notions of "add path" and
> "update content" comes from looking at how to specify path names to
> these operations, (and recursive names in particular).
Sometimes pure _technical_ arguments don't make good _user_ interfaces.
The "git add" changes are about _usability_, not _technicality_. It is
much easier to learn about one concept which is "you add stuff to your
commit" with no other distinction to make.
> Yes, update-index still exists. But we're relegating that to
> plumbing.
But plumbing is there for you to use with your own enhancements when
they are sophisticated enough like your workflow description seem to
imply.
> > The problem lies with the git-diff interface then, not git-add.
>
> I don't think so. I'm quite convinced that the fact that "git diff"
> shows the difference from the index to the working tree is correct and
> can't really be changed.
I'm not proposing to change existing output either.
> > 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.
>
> But it's not actually update-index that I want. I agree that it's a
> plumbing thing that users shouldn't use. What I want is two different
> pieces of porcelain here, each focusing one one simple task. One to
> add the path to the index, and one to update content in the index for
> a path that exists.
>
> Much better would be for "git add" and "git refresh" to each just
> stick to a single task and to do it well, (git has UNIX philosophy,
> right?). So "git add" should just add paths to the index, "git
> refresh" should just update content for existing paths in the index,
> and we don't need a lot of options for either command for users to
> have to wade through.
I'm still unconvinced this is useful distinction to make in the majority
of all cases for the majority of people.
> With those simple commands, we could have nice, separate behavior for:
>
> git add some-dir
> and:
> git refresh some-dir
>
> and if someone wants the existing "add path and update content"
> behavior of git add then it should be a simple matter of aliasing to
> the combination of "git add" followed by "git refresh".
I think that if you want that behavior it might be a better idea for you
to alias those behaviors with a combination of git-ls-files and
git-update-index.
> > 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.
>
> I don't understand what you are proposing here. What would this mode
> display? How would it decide?
This is something that you might not need after all. but for people
using git-commit -a they might benefit from a git-diff -a that would
output the equivalent of what will be committed, including newly added
files (already in the index) and modified files (not yet in the index).
It is easy to do: for each index entry, generate a diff against the
corresponding file in the work tree, but if there is no difference then
generate the diff against HEAD. Modified files will be in the first
case while added files will be in the second case.
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