Hi Junio,
I started this thread with a very long post that rejoins the NEXT /
WTREE debate with more ammunition. (A theory to back it up and
explain what happens during merge conflict.)
I also proposed that git treat snapshots, the working tree, and next
commit like unix file systems and support the commands from them such
as: cat, ls, find, etc. These follow-up emails were focused on the
small problem of whether or not xargs could work. (I'm now convince
it can't - you want to just to a checkout and then run it.)
I excepted the proposals below.
Mike
PROPOSAL 3: Add aliases NEXT and WTREE that work in place of a
snapshot in any commands.
e.g., "git diff HEAD NEXT"
e.g., "git ls NEXT etc/"
During a conflicted merge state, we _may_ want commands to treat WTREE
differently.
PROPOSAL 1: git should imitate the Unix file system commands for
accessing the snapshot of a commit.
For these commands to work, the git command will have to include an
argument that specifies which commit it operates on. So some basic
ones might be:
"git ls <commit> -- <path>"
"git cat <commit> -- <path>"
(There exists "git ls-files", "git ls-tree", and "git cat-file" but
they are not quite the same.)
"git find <commit> -- ..."
"git grep <commit> -- <path>" (Exists)
The Unix command "diff" compares two files/directories. So, the "git"
version requires two commits to be specified.
"git diff <commit> <commit> -- <path>" (Exists)
I'd love to see something to apply a command to every file in a commit
or every file found by "git find".
"git xargs <commit> ..." (Is this possible?)
Since snapshots are a read-only version of a file system, git can't
implement the commands "rm", "mv", or "cp" for them.
NEXT and WTREE are writeable file
systems, the Unix filesystem commands that write should be implemented
as part of git to work with them.
"git cp <snapshot> <writeable_filesys> -- <src_path> <dest_file>"
"git mv <snapshot> <writeable_filesys> -- <src_path> <dest_file>"
"git rm <writeable_filesys> -- <file>"
I believe "git cp" would be similar to the proposed "git put". The current
"git mv" and "git rm" does operation on both NEXT and WTREE by default.
(Which I think is a sensible default in those cases.)
We may want to consider "mkdir", "rmdir", "chmod".
PROPOSAL 2: adopt a term like edit and rigorous terms
like split, join, and reorder to describe the operations of git
commands.
We should also use exacting vocabulary to describe git commands. It's
not unusual to use the word "commit" when referring to:
* a snapshot (stored in the commit's tree object)
* an edit (the difference between this commit's snapshot and its
parent's (if it has only one parent...))
* a complete history of edits going back to the initial snapshot
* the commit object itself (e.g., when tagged)
While often the appropriate definition can be picked up from context,
we should be precise if possible.
It would be good to define a term like "snapshot tree" that refers to
a tree object that is the root of a snapshot, to differentiate it from
other tree objects that store subdirectories.
--
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