Re: Announcing git-reparent
Hello, On Mon, Jan 14, 2013 at 8:16 AM, Jonathan Nieder jrnie...@gmail.com wrote: Hi Mark, Mark Lodato wrote: Create a new commit object that has the same tree and commit message as HEAD but with a different set of parents. If ``--no-reset`` is given, the full object id of this commit is printed and the program exits I've been wishing for something like this for a long time. I used to fake it using cat-file commit, sed, and hash-object -w when stitching together poorly imported history using git replace. Just wondering, is the result different than something like git checkout commit_to_reparent cp -r * ../snapshot/ git reset --hard new_parent rm -r * cp -r ../snapshot/* . git add -A (assumes 1 parent, does not cope with .dot files, and has probably other small problems) -- Piotr Krukowiecki -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing git-reparent
Jonathan Nieder jrnie...@gmail.com writes: Hi Mark, Mark Lodato wrote: Create a new commit object that has the same tree and commit message as HEAD but with a different set of parents. If ``--no-reset`` is given, the full object id of this commit is printed and the program exits I've been wishing for something like this for a long time. I used to fake it using cat-file commit, sed, and hash-object -w when stitching together poorly imported history using git replace. Thanks for writing it. Ciao, Jonathan The scriptq is simple enough, and from a cursory look, it may be fine to throw it in contrib/ after some minor style fixes and such, if many find it useful. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing git-reparent
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Just wondering, is the result different than something like git checkout commit_to_reparent cp -r * ../snapshot/ git reset --hard new_parent rm -r * cp -r ../snapshot/* . git add -A I think you are looking for git reset --soft new_parent, which keeps both the index and the working tree intact. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing git-reparent
On Mon, Jan 14, 2013 at 3:03 AM, Piotr Krukowiecki piotr.krukowie...@gmail.com wrote: Just wondering, is the result different than something like git checkout commit_to_reparent cp -r * ../snapshot/ git reset --hard new_parent rm -r * cp -r ../snapshot/* . git add -A (assumes 1 parent, does not cope with .dot files, and has probably other small problems) The result is similar, but your script would also lose the commit message and author. I think the following would do exactly as my script does (untested): git checkout commit_to_reparent git branch tmp git reset --soft new_parent git commit -C tmp git branch -D tmp I actually contemplated using the above method in my script, rather than git-commit-tree and git-reset. In the end, I decided to stick with my original approach because it does not create any intermediate state; either an early command fails and nothing changes, or the git reset works and everything is done. Using the above might be cleaner for the --edit flag since it allows the git-commit cleanup of the commit message, but this would require much more careful error handling, and might make the reflog uglier. I'd be interested to hear a git expert's opinion on the choice. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing git-reparent
Hi Mark, Mark Lodato wrote: Create a new commit object that has the same tree and commit message as HEAD but with a different set of parents. If ``--no-reset`` is given, the full object id of this commit is printed and the program exits I've been wishing for something like this for a long time. I used to fake it using cat-file commit, sed, and hash-object -w when stitching together poorly imported history using git replace. Thanks for writing it. Ciao, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
