Jesse Greenwald [Wed, 10 Nov 2010 04:18:36 +0000 (22:18 -0600)]
Added check to order of processed commits.
With debug messages enabled, "incorrect order" will be output whenever a
commit is processed before its parents have been processed. This can be
determined by checking to see if a parent isn't mapped to a new commit, but
it has been processed.
Jesse Greenwald [Tue, 9 Nov 2010 14:34:49 +0000 (08:34 -0600)]
Split cmd now processes commits in topo order.
Added the "--topo-order" option to git rev-list. Without this, it seems that
the revision list is coming back in reverse order but it is sorted
chronologically. This does not gurantee that parent commits are handled
before child commits.
Avery Pennarun [Thu, 24 Jun 2010 20:57:58 +0000 (16:57 -0400)]
Another fix for PATH and msysgit.
Evan Shaw tells me the previous fix didn't work. Let's use this one
instead, which he says does work.
This fix is kind of wrong because it will run the "correct" git-sh-setup
*after* the one in /usr/bin, if there is one, which could be weird if you
have multiple versions of git installed. But it works on my Linux and his
msysgit, so it's obviously better than what we had before.
Avery Pennarun [Thu, 24 Jun 2010 05:53:05 +0000 (01:53 -0400)]
(Hopefully) fix PATH setting for msysgit.
Reported by Evan Shaw. The problem is that $(git --exec-path) includes a
'git' binary which is incompatible with the one in /usr/bin; if you run it,
it gives you an error about libiconv2.dll.
You might think we could just add $(git --exec-path) at the *end* of PATH,
but then if there are multiple versions of git installed, we could end up
with the wrong one; earlier versions used to put git-sh-setup in /usr/bin,
so we'd pick up that one before the new one.
So now we just set PATH back to its original value right after running
git-sh-setup, and we should be okay.
Avery Pennarun [Sat, 6 Feb 2010 20:05:17 +0000 (15:05 -0500)]
Make tests pass with recent git (1.7.0 and up).
It seems that in older versions, --message="" was interpreted as "use the
default commit message" instead of "use an empty commit message", and
git-subtree was depending on this behaviour. Now we don't, so tests pass
again.
Avery Pennarun [Tue, 2 Feb 2010 15:25:58 +0000 (10:25 -0500)]
Merge branch 'master' of git://github.com/psionides/git-subtree
* 'master' of git://github.com/psionides/git-subtree:
improved rev_is_descendant_of_branch() function
added temporary test dirs to gitignore
added tests for recent changes
fixed bug in commit message for split
changed alias for --prefix from -p to -P
fix for subtree split not finding proper base for new commits
allow using --branch with existing branches if it makes sense
added -m/--message option for setting merge commit message
added -p alias for --prefix
Avery Pennarun [Fri, 2 Oct 2009 18:53:35 +0000 (14:53 -0400)]
Merge branch 'master' of git://github.com/voxpelli/git-subtree
* 'master' of git://github.com/voxpelli/git-subtree:
Check that the type of the tree really is a tree and not a commit as it seems to sometimes become when eg. a submodule has existed in the same position previously.
Pelle Wessman [Wed, 30 Sep 2009 12:29:42 +0000 (14:29 +0200)]
Check that the type of the tree really is a tree and not a commit as it seems to sometimes become when eg. a submodule has existed in the same position previously.
Avery Pennarun [Wed, 26 Aug 2009 14:41:03 +0000 (10:41 -0400)]
Improve patch to use git --exec-path: add to PATH instead.
If you (like me) are using a modified git straight out of its source
directory (ie. without installing), then --exec-path isn't actually correct.
Add it to the PATH instead, so if it is correct, it'll work, but if it's
not, we fall back to the previous behaviour.
Avery Pennarun [Sat, 30 May 2009 07:18:27 +0000 (03:18 -0400)]
Basic "subtree merge --squash" support.
Instead of merging in the history of the entire subproject, just squash it
all into one commit, but try to at least track which commits we used so that
we can do future merges correctly.
Bonus feature: we can actually switch branches of the subproject this way,
just by "squash merging" back and forth from one tag to another.
Now we only prune out a commit if it has exactly one remaining parent and
that parent's tree is identical to ours.
But I also changed the test to create the initial "-s ours" merge in one
step instead of two, and that merge can be eliminated since one of its
parents doesn't affect the subdir at all, and is thus deleted.
Now we cut out a commit if any of its parents had the same tree; just use
that parent in its place. This makes the history look nice, but I don't
think it's quite right...
The idea is to join the new split branch back into this one, so future
splits can append themselves to the old split branch. We mark the split
branch's history in our merge commit, so we can pull it back out later.