git-subtree split O(N)

git-subtree split O(N)

[Vinnie Falco]

I'm using git-subtree split to extract changes to a directory
previously added with git-subtree add, in my local repository. The
split is going into its own branch, which I then push to the upstream.

The problem is that every time I split, git-subtree starts from the
very beginning of the commit log and works its way forward. I thought
that it was only supposed to do that once, and that subsequent splits
would start from the last commit in the destination branch (I keep the
split branch around).

What's going on?

-- 
Follow me on Github: https://github.com/vinniefalco

Re: git-subtree split O(N)

[Randal L. Schwartz]

>>>>> "Vinnie" == Vinnie Falco <vinnie.falco@gmail.com> writes:

Vinnie> I'm using git-subtree split to extract changes to a directory
Vinnie> previously added with git-subtree add, in my local repository. The
Vinnie> split is going into its own branch, which I then push to the upstream.

Vinnie> The problem is that every time I split, git-subtree starts from the
Vinnie> very beginning of the commit log and works its way forward. I thought
Vinnie> that it was only supposed to do that once, and that subsequent splits
Vinnie> would start from the last commit in the destination branch (I keep the
Vinnie> split branch around).

Are you using -rejoin?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: git-subtree split O(N)

[Vinnie Falco]

> Vinnie> I'm using git-subtree split to extract changes to a directory
>
> Are you using -rejoin?

I am not using --rejoin. Admittedly, the documentation is somewhat
opaque on its usage:

"--rejoin:: This option is only valid for the split command."

This is confusing. One would think that an option named "rejoin" has
more to do with merge or pull than split. Although I guess the meaning
is that you want your local changes to "rejoin" the upstream?

"...future splits can search only the part of history that has been
added since the most recent --rejoin."

This sounds exactly like my use-case, I want to avoid starting from
initial commit on a split, but...

"If you do all your merges with '--squash', don't use '--rejoin' when
you split, because you don't want the subproject's history to be part
of your project anyway."

I always use --squash with git-subtree pull, so I interpreted this to
mean I should never use --rejoin.

"Unfortunately, using this option results in 'git log' showing an
extra copy of every new commit that was created"

This is what discouraged me from ever touching "--rejoin"

I hope this helps

Thanks

Re: git-subtree split O(N)

[dag]

Vinnie Falco <vinnie.falco@gmail.com> writes:

> The problem is that every time I split, git-subtree starts from the
> very beginning of the commit log and works its way forward. I thought
> that it was only supposed to do that once, and that subsequent splits
> would start from the last commit in the destination branch (I keep the
> split branch around).
>
> What's going on?

This is an area I want to improve.

You have to use --rejoin so subtree will remember where you left off
last time.  I also always specify a branch name, like this:

git subtree split -P subproj --rejoin --branch=subproj-to-push

I think --rejoin should probably be default but I need to understand the
code better to make sure.

HTH.

                              -Dave