threads / discuss / 14409

git cherry-pick before archive

Subject: git cherry-pick before archive

## tl;dr

11 messages between Jul 11, 2008 and Jul 11, 2008.

replies: 10people: 4as markdown or json

Denis Bueno· Jul 11, 2008, 15:46 UTC · lore
Hi all,

I'm trying to use git archive to create a kind of "release" tarball of my source. I've got a patch (a commit) that I'd like to apply to the tree before I call git archive on HEAD. Currently my command is:

    git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
If I were to actually modify my tree & history, I'd change the command to:
    git cherry-pick 97a1235ce674f7cf4df3129cd0ab1ae0793db392
    git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
    git reset --hard HEAD^

But I'd rather not modify my history, if it's possible. (This will create a bunch of dangling commit objects over time, no?)

-- 
 Denis
Johannes Schindelin· Jul 11, 2008, 15:51 UTC · re: Denis Bueno · lore

Re: git cherry-pick before archive

Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
Show 14 quoted lines
> I'm trying to use git archive to create a kind of "release" tarball of
> my source.  I've got a patch (a commit) that I'd like to apply to the
> tree before I call git archive on HEAD.  Currently my command is:
> 
>     git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
> 
> If I were to actually modify my tree & history, I'd change the command to:
> 
>     git cherry-pick 97a1235ce674f7cf4df3129cd0ab1ae0793db392
>     git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
>     git reset --hard HEAD^
> 
> But I'd rather not modify my history, if it's possible.  (This will
> create a bunch of dangling commit objects over time, no?)

$ git cherry-pick -n <bla> $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz $ git reset

Hth, Dscho

Denis Bueno· Jul 11, 2008, 16:09 UTC · re: Johannes Schindelin · lore

Re: git cherry-pick before archive

On Fri, Jul 11, 2008 at 11:51, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> $ git cherry-pick -n <bla>
> $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
> $ git reset

Thank you! This is much better. The only thing that could improve it is by some way to "un-cherry-pick" the applied change (so that after "git reset" there are no local modifications to the file(s) changed by cherry-picking <bla>).

Is there an easy way to invert a patch to undo the change the original patch introduced?

-- 
 Denis
Miklos Vajna· Jul 11, 2008, 16:11 UTC · re: Denis Bueno · lore

Re: git cherry-pick before archive

On Fri, Jul 11, 2008 at 12:09:02PM -0400, Denis Bueno <dbueno@gmail.com> wrote:
Show 5 quoted lines
> On Fri, Jul 11, 2008 at 11:51, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > $ git cherry-pick -n <bla>
> > $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
> > $ git reset
I guess he wanted to write 'git reset --hard' here ;-)
Show 8 quoted lines
> 
> Thank you!  This is much better.  The only thing that could improve it
> is by some way to "un-cherry-pick" the applied change (so that after
> "git reset" there are no local modifications to the file(s) changed by
> cherry-picking <bla>).
> 
> Is there an easy way to invert a patch to undo the change the original
> patch introduced?
git show <commit> | git apply -R?
Denis Bueno· Jul 11, 2008, 16:18 UTC · re: Miklos Vajna · lore

Re: git cherry-pick before archive

On Fri, Jul 11, 2008 at 12:11, Miklos Vajna <vmiklos@frugalware.org> wrote:
Show 8 quoted lines
> On Fri, Jul 11, 2008 at 12:09:02PM -0400, Denis Bueno <dbueno@gmail.com> wrote:
>> On Fri, Jul 11, 2008 at 11:51, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > $ git cherry-pick -n <bla>
>> > $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
>> > $ git reset
>
> I guess he wanted to write 'git reset --hard' here ;-)

But that will undo local modifications to any uncommitted files, not just those affected by the cherry-pick. I don't want to do that.

Show 9 quoted lines
>> Thank you!  This is much better.  The only thing that could improve it
>> is by some way to "un-cherry-pick" the applied change (so that after
>> "git reset" there are no local modifications to the file(s) changed by
>> cherry-picking <bla>).
>>
>> Is there an easy way to invert a patch to undo the change the original
>> patch introduced?
>
> git show <commit> | git apply -R?
Brilliant!  Thanks.  I didn't know about apply (or show for that matter ....).
-- 
 Denis
Johannes Schindelin· Jul 11, 2008, 18:25 UTC · re: Miklos Vajna · lore

Re: git cherry-pick before archive

Hi,
On Fri, 11 Jul 2008, Miklos Vajna wrote:
Show 8 quoted lines
> On Fri, Jul 11, 2008 at 12:09:02PM -0400, Denis Bueno <dbueno@gmail.com> wrote:
> > On Fri, Jul 11, 2008 at 11:51, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > > $ git cherry-pick -n <bla>
> > > $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
> > > $ git reset
> 
> I guess he wanted to write 'git reset --hard' here ;-)
He did not ;-)  "git reset" resets only the index, which is what I wanted.

Anyway, back to Denis' question: I could imagine (haven't tested, thought), that "git revert -n <the-same-commit>" would undo the "git cherry-pick -n".

Please test and report back, Dscho

Denis Bueno· Jul 11, 2008, 18:28 UTC · re: Johannes Schindelin · lore

Re: git cherry-pick before archive

On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> Anyway, back to Denis' question: I could imagine (haven't tested,
> thought), that "git revert -n <the-same-commit>" would undo the "git
> cherry-pick -n".

So I need to be able to maintain the patch that is applied to the tree before archiving, so instead of a commit ID, I'm now using a patch file, and the sequence of actions is like so:

    $ <assume index is clean>
    $ git apply --cached patchfile || exit 1
    $ git archive --format=tar --prefix=pfx/ $(git write-tree) \
          | gzip > prj.tgz
    $ git reset

This way I don't even need to reverse-apply the patch, because I never touch the working copy. Of course, this can't be done in this way in any other revision control system, because they don't have an index.

-- 
 Denis
Johannes Schindelin· Jul 11, 2008, 18:46 UTC · re: Denis Bueno · lore

Re: git cherry-pick before archive

Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
Show 19 quoted lines
> On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Anyway, back to Denis' question: I could imagine (haven't tested,
> > thought), that "git revert -n <the-same-commit>" would undo the "git
> > cherry-pick -n".
> 
> So I need to be able to maintain the patch that is applied to the tree
> before archiving, so instead of a commit ID, I'm now using a patch
> file, and the sequence of actions is like so:
> 
>     $ <assume index is clean>
>     $ git apply --cached patchfile || exit 1
>     $ git archive --format=tar --prefix=pfx/ $(git write-tree) \
>           | gzip > prj.tgz
>     $ git reset
> 
> This way I don't even need to reverse-apply the patch, because I never
> touch the working copy.  Of course, this can't be done in this way in
> any other revision control system, because they don't have an index.
Well, they have.  They just do not expose it.
BTW in your case, I would suggest this:
	INDEX_FILE=.git/bla git read-tree HEAD &&
	INDEX_FILE=.git/bla git apply --cached patchfile &&
	INDEX_FILE=.git/bla git archive [...] &&
	rm .git/bla
IOW: Just use a temporary index for your work.

Ciao, Dscho

Denis Bueno· Jul 11, 2008, 18:49 UTC · re: Johannes Schindelin · lore

Re: git cherry-pick before archive

On Fri, Jul 11, 2008 at 14:46, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 8 quoted lines
> BTW in your case, I would suggest this:
>
>        INDEX_FILE=.git/bla git read-tree HEAD &&
>        INDEX_FILE=.git/bla git apply --cached patchfile &&
>        INDEX_FILE=.git/bla git archive [...] &&
>        rm .git/bla
>
> IOW: Just use a temporary index for your work.
What is the rationale?  So I can relieve the assumption that the index is clean?
-- 
 Denis
Johannes Schindelin· Jul 11, 2008, 18:53 UTC · re: Denis Bueno · lore

Re: git cherry-pick before archive

Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
Show 13 quoted lines
> On Fri, Jul 11, 2008 at 14:46, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > BTW in your case, I would suggest this:
> >
> >        INDEX_FILE=.git/bla git read-tree HEAD &&
> >        INDEX_FILE=.git/bla git apply --cached patchfile &&
> >        INDEX_FILE=.git/bla git archive [...] &&
> >        rm .git/bla
> >
> > IOW: Just use a temporary index for your work.
> 
> What is the rationale?  So I can relieve the assumption that the index 
> is clean?
Not completely.

It will just leave the current index alone, ignoring the changes within it. It will also avoid having to update the index several times.

IMO it is just the thing you should do here: you do not want to stage anything for commit, so keep .git/index as-is, and use a temporary staging area instead.

It also avoids the need to "undo" things that might not be easily undone: if your patch contains stuff that was partly in the index, but uncommitted, neither "git reset" nor "git revert -n" will do what you want.

Ciao, Dscho

Junio C Hamano· Jul 11, 2008, 22:18 UTC · re: Johannes Schindelin · lore

Re: git cherry-pick before archive

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 22 quoted lines
> Hi,
>
> On Fri, 11 Jul 2008, Denis Bueno wrote:
>
>> I'm trying to use git archive to create a kind of "release" tarball of
>> my source.  I've got a patch (a commit) that I'd like to apply to the
>> tree before I call git archive on HEAD.  Currently my command is:
>> 
>>     git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
>> 
>> If I were to actually modify my tree & history, I'd change the command to:
>> 
>>     git cherry-pick 97a1235ce674f7cf4df3129cd0ab1ae0793db392
>>     git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
>>     git reset --hard HEAD^
>> 
>> But I'd rather not modify my history, if it's possible.  (This will
>> create a bunch of dangling commit objects over time, no?)
>
> $ git cherry-pick -n <bla>
> $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
> $ git reset
That will create a bunch of dangling tree objects over time, yes.

← back to recent threads