[BUG?] git-subtree behavior when the -P tree is removed and recreated

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello folks,

I think I might've found a bug in git-subtree: I have a repository
containing a directory "foo". I'd like to use its code in other
projects, so I want to split it off into its own repository with
git-subtree. But it doesn't work as it should. I found out that long
ago, my repository contained an unrelated directory also called "foo"
which has since been deleted.

Steps to reproduce (after installing git-subtree from contrib):
git init repo
cd repo
mkdir foo; touch foo/v1
git add -A .; git commit -m v1
rm -rf foo; touch v2
git add -A .; git commit -m v2
mkdir foo; touch foo/v3
git add -A .; git commit -m v3
git subtree split -P foo -b splitfoo --annotate="split "

What should happen: Either (A) splitfoo only contains "split v3", or
(B) splitfoo contains "split v1" and "split v3"

What happens instead: The parent of "split v3" is "v2", so splitfoo's
full history is: "v1" -> "v2" -> "split v3".

Git version: 1.7.12.2

Bonus questions:
- which is the intended behavior, (A) or (B)?
- if it's (B), how do I convince git-subtree to do (A) once this bug
gets fixed? (I might be getting too far ahead of myself here...)

Tomi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]