thanks! and a tiny comment

[Sam Vilain]

Yaroslav Halchenko wrote:

> He just confirms to me the lack of 'unmerge' relationship in git, which
> (in my wild thoughts) should be similar to merge, only with opposite
> effect 
> 
> 1. it  should remove the changes brought in by the merge (or
> a retrospectively consecutive list of merges from the specified branch).
> 
> 2. provide 'Unmerge' relationship and point out to the latest commit
> from merged branch which remains merged into current branch (or common
> ancestor if any if all merges were unmerged).
> 
> Due to 2, consecutive merges into working branch can properly account
> for the "common ancestor" if git merge cares about Unmerge relationship

Or, make a new branch at the point that the unwanted feature branch was
merged in, and then rebase all of the changes that you do want on top of
that.  This represents what happened perfectly.  You archive the removed
history somewhere like refs/Attic/remove-feature.

Sure, everyone tracking has to rebase what they're doing off the old branch.

If people are unable to harden up sufficiently to handle history changes
like this, another option is to make a single ("squashed") revert commit
that undoes the changes, and make sure that the *new* feature
development branch is rebased on top of *that*.  ie, the revert commit
is then reverted again and development on the feature branch continues.

Both of these provide the functionality required.

People new to git (meaning, I was suggesting enhancements like this when
I started too ;)) frequently talk about adding this feature or that
feature, without realising that git really is very very simple.  It has
files, directories, commits, tags and /that's it/.  It's power over
centralised solutions is the *lack* of surrogate identifiers such as a
branch path, server assigned sequence number, etc.  It's merging power
comes from commits *not* being limited to a single parent.  A constraint
removed, in database language.

This extends to the interface, too.  Complex situations like this can
eventually have front-ends written for them, when people reach consensus
on how it should be done.  But the sharper tools you are given - git
rev-parse, git update-ref, git hash-object, git cat-file, git read-tree,
git commit-tree - can be used as a fall-back to construct custom
arrangements until the tools exist.  When you find a practice which is
useful, you write support in the tools, and post the suggestion to the list.

If you haven't done so already - find yourself a git repository, then
use 'git cat-file -t REVISION', it should say something like "commit".
Then you can 'git cat-file commit REVISION' and see the *raw* object.
You can reconstruct the SHA1 by prepending the basic header (eg,
"blob 1234\0" for a 1234-byte object) as an IV for the SHA1 checksummer.
  You can then take the "tree" values, and run cat-file on those, too
(git ls-tree decodes the binary tree format).  And within the trees, you
will see "blob" entries that you can cat-file as well.

Yes, there could be more relationships and metadata to represent a whole
lot of things.  Per-file history and merging, directory renaming, cherry
picking, reverting.  But these all add complications to the basic model,
which has already shown itself to be capable of dealing with these
things - with caveats.  But the pay-off - simplicity - is well worth
those caveats.

Sam.