This allows the programs to use various simplified versions of
the SHA1 names, eg just say "HEAD" for the SHA1 pointed to by
the .git/HEAD file etc.
For example, this commit has been done with
git-commit-tree $(git-write-tree) -p HEAD
instead of the traditional "$(cat .git/HEAD)" syntax.
This patch renames read_tree_with_tree_or_commit_sha1() to
read_object_with_reference() and extends it to automatically
dereference not just "commit" objects but "tag" objects. With
this patch, you can say e.g.:
ls-tree $tag
read-tree -m $(merge-base $tag $HEAD) $tag $HEAD
diff-cache $tag
diff-tree $tag $HEAD
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We use that to specify alternative index files, which can be useful
if you want to (for example) generate a temporary index file to do
some specific operation that you don't want to mess with your main
one with.
It defaults to the regular ".git/index" if it hasn't been specified.
Usage string fixes to make maintenance easier (only one instance
of a string to update not multiple copies). I've spotted and
corrected inconsistent usage text in diff-tree while doing this.
Also diff-cache and read-tree usage text have been corrected to
match their up-to-date features. Earlier, neither "--cached"
form of diff-cache nor "-m single-merge" form of read-tree were
described.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Updates read-tree to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with
this patch.
The change involves a slight modification of how it recurses down
the tree. Earlier the caller only supplied SHA1 and the recurser
read the object using it, but now it is the caller's responsibility
to read the object and give it to the recurser. This matches the
way recursive behaviour is done in other tree- related commands.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This cuts down the work for the "real merge" to stuff where
people might actually disagree on the algorithm. The trivial
cases would seem to be totally independent of any policy.
Normally you'd use state 0 for the "merged" state, and start out with
state 1 being "origin", state 2 being "first tree" and state 3 being
"second tree".
Once all the index entries are back in state 0, we have a successful
merge and can write the result tree back.
This allows using a git tree over NFS with different byte order, and
makes it possible to just copy a fully populated repository and have
the end result immediately usable (needing just a refresh to update
the stat information).
Now there is error() for "library" errors and die() for fatal "application"
errors. usage() is now used strictly only for usage errors.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
It now requires the "--add" flag before you add any new files, and
a "--remove" file if you want to mark files for removal. And giving
it the "--refresh" flag makes it just update all the files that it
already knows about.
This is totally untested, since we can't actually _write_ things that
way yet, but I'll get to that next, I hope. That should fix the
huge wasted space for kernel-sized tree objects.
I needed this to make a "sparse" archive conversion from my old
BitKeeper tree data. The scripts to do the conversion are just
incredibly ugly, but they seem to validate the notion that you
can actually use this silly 'git' thing to save your history in.
The tool interface sucks (especially "committing" information, which is just
me doing everything by hand from the command line), but I think this is in
theory actually a viable way of describing the world. So copyright it.
