Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
We really need that ^M (\r), not a ^J (\n) if we want the status message to
overwrite itself nicely.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We should implement it as
git fetch ...
git subtree merge ...
But we were instead just calling
git pull -s subtree ...
because 'git subtree merge' used to be just an alias for 'git merge -s
subtree', but it no longer is.
|
|
This didn't seem to have any noticeable side effects other than
suspicious-looking log messages when you used -d.
|
|
Prefixes that differ only in the trailing slash should be considered
identical.
Also update the test to check that this works.
|
|
seems to sometimes become when eg. a submodule has existed in the same position previously.
|
|
We were trying to 'git checkout $prefix', which is ambiguous if $prefix
names a directory *and* a branch. Do 'git checkout -- $prefix' instead.
The main place this appeared was in 'git subtree add'.
Reported by several people.
|
|
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.
|
|
As pointed out by documentation, the correct use of 'git-sh-setup' is
using $(git --exec-path) to avoid problems with not standard
installations.
Signed-off-by: gianluca.pacchiella <pacchiel@studenti.ph.unito.it>
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
This is just a handy way to create a new branch from the newly-split subtree.
|
|
|
|
Thanks to Eduardo Kienetz for noticing this.
|
|
Instead of debug messages, we print a progress counter to stderr.
|
|
If any one of the parents is the same as the current one, then clearly the
other parent branch isn't important, so throw it away entirely.
Can't remember why I didn't do this before, but if I rediscover it, it
definitely needs a unit test.
|
|
This is a simplification of the previous logic. I don't *think* it'll break
anything.
Results in far fewer useless merge commmits when playing with gitweb in the
git project:
git subtree split --prefix=gitweb --annotate='(split) ' 0a8f4f0^^..f2e7330
--onto=1130ef3
...and it doesn't *seem* to eliminate anything important.
|
|
...and update test.sh to test for this.
|
|
|
|
|
|
|
|
|
|
These are simple shortcuts for 'git merge -s subtree' and 'git pull -s
subtree', but it makes sense to have it all in one command.
|
|
|
|
I like this better. It's more like git-read-tree and some other commands.
|
|
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...
|
|
|
|
|
|
But we still need to get rid of unnecessary merge commits somehow...
|
|
Otherwise we can't keep track of parent relationships. Argh.
This change makes it "work", but we get a bunch of empty commits.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|