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.
