[cairo] Changes in web commits

[Baz]

On 05/07/07, Baz <brian.ewins at gmail.com> wrote:
> Hmm... this whole rcs backend stuff looks fundamentally wrong, and not
> just for git.

Ok, I read the rest of the code and I get it - there's an exclusive
lock taken when any edits happen. Still, the code looks overly
complex, and this is what rcs_commit/merge_past should do:

preconditions:
 - <rcstoken> is the value returned by rcs_prep - and is the tree SHA
not the file SHA
 - user intends <file> as update to <rcstoken>, but we are at HEAD instead.
 - git-add <file> was already called in rcs_add
 - there may be other tracked modified files, but they've not been
git-add'ed. Apparently.

# this is merge_past {
# make a dummy commit, pop it
git-commit -m dummy
git-reset ^HEAD #not --hard, leave other modified files alone
# after reset, ORIG_HEAD contains a tree with the changed file.
# revert <file> to the state before latest submit overwrote it.
git-checkout HEAD <file>
# generate the intended patch and apply it. may conflict.
# the pipe is unfortunate...
git-diff-tree -p <rcstoken> ORIG_HEAD <file>|git-apply
# } end merge_past

# Success! commit this one file.
git-commit -m <comment> -i <file>

You can do this without a pipe or dummy commit, but it needs a temp
file instead; to do the same thing with branches needs git-stash and
is more complex. I've wandered off-topic for this list, I guess I'll
just try to write a patch for this.

-Baz