Hi, On Fri, 11 Jul 2008, Denis Bueno wrote: > On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
