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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:55
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?)
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
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?
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.
quoted
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
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
On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin
[off-list ref] 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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:55
Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin
[off-list ref] wrote:
quoted
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
On Fri, Jul 11, 2008 at 14:46, Johannes Schindelin
[off-list ref] 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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:55
Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
On Fri, Jul 11, 2008 at 14:46, Johannes Schindelin
[off-list ref] wrote:
quoted
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