Convert the index file reading/writing to use network byte order.
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).
[PATCH] Simplify date handling and make it more reliable
This make all dates be stores as seconds since UTC epoch, with the
author's or committer's timezone as auxiliary data so that dates can be
pretty-printed in the original timezone later if anyone cares. I left
the date parsing in rev-tree.c for backward compatibility but it can be
dropped when we change to base64 :)
commit-tree now eats RFC2822 dates as AUTHOR_DATE because that's
what you're going to want to feed it.
Yes, glibc sucks and strptime is a pile of crap. We have to parse it
ourselves.
This adds '-r' (recursive) option and '-z' (NUL terminated)
option to ls-tree. I need it so that the merge-trees (formerly
known as git-merge.perl) script does not need to create any
temporary dircache while merging. It used to use show-files on
a temporary dircache to get the list of files in the ancestor
tree, and also used the dircache to store the result of its
automerge. I probably still need it for the latter reason, but
with this patch not for the former reason anymore.
Use common "revision.h" header for both fsck and rev-tree.
It's really a very generic thing: the notion of one sha1 revision
referring to another one. "fsck" uses it for all nodes, and "rev-tree"
only tracks commit-node relationships, but the code was already
the same - now we just make that explicit by moving it to a common
header file.
Make 'fsck' able to take an arbitrary number of parents on the
command line.
"arbitrary" is a bit wrong, since it is limited by the argument
size limit (128kB or so), but let's see if anybody ever cares.
Arguably you should prune your tree before you have a few thousand
dangling heads in your archive.
We can fix it by passing in a file listing if we ever care.
Changes diff-tree output format so that fields are separated by tabs instead of
spaces (readibility, parseability), and tree entry type is listed along the
entry (avoids having to figure that out from the mode in the scripts).
It seems like the nsec portability is limited; in particular, older
glibcs (<=2.2.4 at least) don't seem to like it. So access the nsec
fields in struct stat only when -DNSEC.
Ancient cat-file command used to leave temp_git_file_* and there
was support to remove them in the clean target of Makefile. I
do not think it is needed anymore.
From: Junio C Hamano <junkio@cox.net> Signed-off-by: Petr Baudis <pasky@ucw.cz>
The nsec field of ctime/mtime is now checked only with -DNSEC defined during
compilation. nsec acts broken since it is stored in the icache but apparently
just gets to zero when flushed to filesystem not supporting it (e.g. ext3),
creating illusions of false changes. At least that's my impression.
ls-tree tool provides just a way to export the binary tree objects
to a usable text format. This is bound to be useful in variety
of scripts, although none of those I have currently uses it.
But e.g. the simple script I've sent to HPA for purging the object
database uses it.
This patch adds a -s flag for show-diff, which will surpress the
actual diffing. This is useful for my scripts when they just want
to see what needs to be updated in the cache.
To do the automated commit-mailing I need to be able to answer the
question "which commits are here today but weren't yesterday"... i.e.
given two commit-ids $HEAD and $YESTERDAY I want to be able to do:
rev-tree $HEAD ^$YESTERDAY
to list those commits which are in the tree now but weren't
ancestors of yesterday's head.
Yes, I could probably do this with
rev-tree $HEAD $YESTERDAY | egrep -v ^[a-z0-9]*:3
but I prefer not to.
[PATCH] show-diff show deleted files as diff as well.
The ideas is that using the show-diff to generate the
patch including deleted and new file (in the next patch).
So we don't have to do the temp new file diff dance on the
script.
The cache index now contain enough information to generate
the whole patch. So the GIT SCM don't need separate command
for check out file to edit or delete. Just do the edit and
remove and GIT will generate the correct patch.
Make the rev-tree output more regular. This is the last
change. Promise.
It now always outputs all the revisions as <sha1>:<reachability>, where the
reachability is the bitmask of how that revision was reachable from the
commits in the argument list.
Trivially, if there is only one commit, the reachability will always be
(1 << 0) == 1 for all reachable revisions, and there won't be any edges
(so the "--edges" flag only makes sense with multiple commit keys).
Add a "rev-tree" helper, which calculates the revision
tree graph.
It's quite fast when the commit-objects are cached, but since
it has to walk every single commit-object, it also allows you
to cache an old state and just add on top of that.
After all, if you want to not allow others to read your
stuff, set your "umask" appropriately or make sure the
parent directories aren't readable/executable.
Make "update-cache --refresh" do what it really should do: just
refresh the "stat" information.
We need this after having done a "read-tree", for example, when the
stat information does not match the checked-out tree, and we want to
start getting efficient cache matching against the parts of the tree
that are already up-to-date.
Fix up commit-tree/diff-tree user interface issues.
No, this doesn't make them easy to use, but makes diff-tree use
the "-r" flag for "recursive" (not "-R") and makes commit-tree
use AUTHOR_xxx environment flags (not COMMITTER_xxx) to match what
it actually does.
Oops. Fix bad initialization of the "seen" array, causing us to not
properly clear the reference count at init time. It happened to work
for me by pure luck.
Until it broke, and my unreferenced commit suddenly looked referenced
again. Fixed.
Oops, the actual 'printf' for missing objects was missing.
Which made fsck very quiet about objects it hadn't found. So add
it.
We'll need to make things like these optional, because it's
perfectly ok to have partial history if you don't want it,
and don't want to go backwards. But for development, it's best
to always complain about missing sha1 object files that are
referenced from somewhere else.
This shows that I've lost track of one commit already. Most likely
because I forgot to update the .dircache/HEAD file when doing a
commit, so that the next commit referenced not the top-of-tree, but
the one older commit.
Having dangling commits is fine (in fact, you should always have
at least _one_ dangling commit in the top-of-tree). But it's
good to know about them.
Also make the return value of "cache_name_pos()" be sane: positive
or zero if we found it (it's the index into the cache array), and
"-pos-1" to indicate where it should go if we didn't.
And, perhaps more importantly, fix the fact that if a filename changed from a
directory to a file (or vice versa), we must consider it a delete and an add,
not a "filechange".
Simplify "diff-tree" output, and only keep track of one single name-base.
During original development I had different name-bases for source and
destination, so that I could make the output show how it got removed
from "tree a" and added to "tree b", but we don't want that. We only
do recursive diffs on anything where the bases are exactly the same,
so we might as well just work with a single base.
Also, make the output for "changed" be a single line, since people
hated the separate '<' / '>' format. They were right. It sucked.
Make "update-cache" a bit friendlier to use (and harder to mis-use).
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 implements the new "recursive tree" write-tree.
It's got some debugging printouts etc still in it, but testing on the
kernel seems to show that it does indeed fix the issue with huge tree
files for each commit.
Teach "fsck" and "read-tree" about recursive tree-nodes.
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.
It finds the cache entry position for a given name, and is
generally useful. Sure, everybody can just scan the active
cache array, but since it's sorted, you actually want to
search it with a binary search, so let's not duplicate that
logic all over the place.
Fix missing return values and some error tests for empty index files
Patches from Dave Jones and Ingo Molnar, but since I don't have any
infrastructure in place to use the old patch applicator scripts I
am trying to build up, I ended up fixing the thing by hand instead.
Credit where credit is due, though. Nice to see that people are
taking a look at the project even in this early stage.
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.