git cherry-pick before archive

git cherry-pick before archive

[Denis Bueno]

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

Re: git cherry-pick before archive

[Johannes Schindelin]

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

Hth,
Dscho

Re: git cherry-pick before archive

[Denis Bueno]

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

Re: git cherry-pick before archive

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

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 ;-)

> 
> 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?

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git cherry-pick before archive

[Denis Bueno]

On Fri, Jul 11, 2008 at 12:11, Miklos Vajna <vmiklos@frugalware.org> wrote:
> 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.

>> 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

Re: git cherry-pick before archive

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Miklos Vajna wrote:

> 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

Re: git cherry-pick before archive

[Denis Bueno]

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

Re: git cherry-pick before archive

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Denis Bueno wrote:

> 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

Re: git cherry-pick before archive

[Denis Bueno]

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?

-- 
 Denis

Re: git cherry-pick before archive

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Denis Bueno wrote:

> 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

Re: git cherry-pick before archive

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> 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.