extracting commits from Elpa to original repo

extracting commits from Elpa to original repo

[Eric Abrahamsen]

Here's another addressed-to-stefan-but-probably-of-general-interest
question:

I first put my "Gnorb" package into Elpa using the git subtree approach.
Stefan made a commit into it, fixing up some compilation issues and code
style stuff. When I went to pull my latest changes into Elpa I got
conflicts (I wasn't expecting anyone else to be committing into that
package!), assumed I'd screwed something up, backed out about half the
changes, and didn't figure out what had happened until after I'd pushed
again.

I keep Gnorb in a separate repo which I consider its home. I have added
that repo to my local Elpa repo as a remote, and have been pulling
changes from there into the Elpa repo.

Stefan you made another similar commit a month or so ago (which I
appreciate!), which I'd like to have in my main repo, but now I'm not
sure how to handle it.

Here's what I do in Elpa to get my changes:

git fetch gnorb
git subtree pull --prefix=packages/gnorb gnorb master --squash

(I've been using the instructions found here[1])

I also used the "subtree split" command to create a separate branch
within Elpa containing only the commits made on "packages/gnorb".

I'd like to get Stefan's patch into my general Gnorb repo, in such a way
that it doesn't create any conflicts or confusion the next time I pull
into Elpa. I created a patch for his commit, but it doesn't apply
cleanly to my other repo, and I suspect that fixing it up so that it
does will simply defer the mess. I'll admit I've reached the limit of my
git abilities.

Can anyone provide some advice on what to do in this situation? Besides
"develop your next package directly in the Elpa tree"?

Thanks in advance,

Eric

[1]: https://hpc.uni.lu/blog/2014/understanding-git-subtree/

Re: extracting commits from Elpa to original repo

[Stefan Monnier]

> I'd like to get Stefan's patch into my general Gnorb repo, in such a way
> that it doesn't create any conflicts or confusion the next time I pull
> into Elpa.

Better ask this to Git people.


        Stefan

Re: extracting commits from Elpa to original repo

[Dmitry Gutov]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I also used the "subtree split" command to create a separate branch
> within Elpa containing only the commits made on "packages/gnorb".
>
> I'd like to get Stefan's patch into my general Gnorb repo, in such a way
> that it doesn't create any conflicts or confusion the next time I pull
> into Elpa. I created a patch for his commit, but it doesn't apply
> cleanly to my other repo, and I suspect that fixing it up so that it
> does will simply defer the mess.

Why doesn't it? But anyway, you should fix it up and push, and then
solve any conflicts that might arise in the next merge.

The 'git subtree push' workflow described in the article you've linked
to can work too, in certain cases, but IIUC it only works well if the
separate repo was originally made from a split (otherwise you risk
pushing the whole elpa history into the external repo).

Re: extracting commits from Elpa to original repo

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I also used the "subtree split" command to create a separate branch
>> within Elpa containing only the commits made on "packages/gnorb".
>>
>> I'd like to get Stefan's patch into my general Gnorb repo, in such a way
>> that it doesn't create any conflicts or confusion the next time I pull
>> into Elpa. I created a patch for his commit, but it doesn't apply
>> cleanly to my other repo, and I suspect that fixing it up so that it
>> does will simply defer the mess.
>
> Why doesn't it? But anyway, you should fix it up and push, and then
> solve any conflicts that might arise in the next merge.

Because his patch was from a month ago, and many things have changed
since then. Maybe a regular merge and push would end up okay. I just
don't have that much confidence in my command of git.

> The 'git subtree push' workflow described in the article you've linked
> to can work too, in certain cases, but IIUC it only works well if the
> separate repo was originally made from a split (otherwise you risk
> pushing the whole elpa history into the external repo).

Which I nearly did yesterday! This seems like more work than it's worth
-- I'll look into de-subtree-ing this package.

Thanks,
Eric

Re: extracting commits from Elpa to original repo

[Dmitry Gutov]

On 12/22/2014 03:41 AM, Eric Abrahamsen wrote:

 > Because his patch was from a month ago, and many things have changed
 > since then. Maybe a regular merge and push would end up okay. I just
 > don't have that much confidence in my command of git.

You should try it. As long as not many changes originate from GNU ELPA, 
it works well enough for me.

Re: extracting commits from Elpa to original repo

[Ted Zlatanov]

On Sun, 21 Dec 2014 13:20:46 +0800 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 

EA> I'd like to get Stefan's patch into my general Gnorb repo, in such a way
EA> that it doesn't create any conflicts or confusion the next time I pull
EA> into Elpa. I created a patch for his commit, but it doesn't apply
EA> cleanly to my other repo, and I suspect that fixing it up so that it
EA> does will simply defer the mess. I'll admit I've reached the limit of my
EA> git abilities.

EA> Can anyone provide some advice on what to do in this situation? Besides
EA> "develop your next package directly in the Elpa tree"?

So you basically want Stefan's patch to end up on your side with the
same commit ID, so you can merge back and forth (preserving a 1-to-1
relationship between the two sides). From the `git subtree' docs for the
"split" sub-operation:

        Repeated splits of exactly the same history are
	guaranteed to be identical (i.e. to produce the same
	commit ids).  Because of this, if you add new commits
	and then re-split, the new commits will be attached as
	commits on top of the history you generated last time,
	so 'git merge' and friends will work as expected.

IOW, don't import the commit as a patch, but use `git subtree' to
synchronize.  I hope that helps.

Ted