{"thread":{"id":"6196","subject":"[RFC] git-svn: make git-svn commit-diff able to work without explicit arguments","startedAt":"2007-01-02T18:23:26Z","lastAt":"2007-01-02T23:09:26Z","messageCount":10,"participants":["Steve Frécinaux","Pierre Habouzit","Eric Wong","Junio C Hamano","Brian Gernhardt","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30676","messageId":"459AA31E.5070705@gmail.com","threadId":"6196","inReplyTo":null,"subject":"[RFC] git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Steve Frécinaux","fromEmail":"nudrema@gmail.com","sentAt":"2007-01-02T18:23:26Z","receivedAt":"2007-01-02T18:23:26Z","isPatch":false,"sender":{"key":"nudrema@gmail.com","avatar":null},"body":"Hello,\n\nWhen using git-svn to access a SVN repo, the commit policy may vary. \nWhile git makes you commit small patches often, svn users tend to prefer \nbigger patches that implement a functionnality at once.\n\nSo at the end you have a SVN commit which corresponds to several git ones.\n\nWhat you can do in this case is :\n\n   git-svn commit-diff --edit -r$REV remotes/git-svn HEAD\n\nWhich effect is that it commits (at once) all the commits between the \nlatest svn fetch and HEAD.\n\nWhat I'm proposing here is this:\n\n  - use the latest fetched rev the default for the -r argument.\n  - use remotes/git-svn and HEAD the defaults for the treeish objects.\n\nA smarter way to take these defaults would be to take the last revision \nin the current branch (which can be something else than git-svn if it \nwasn't rebased/merged recently) and the relevant commit in the current \nbranch.\n\nAdditionnaly, --edit could be enabled by default if -m is not set and it \nis used interactively, eventually using an option in repo-config.\n\nAny comment ?\n"},{"id":"30679","messageId":"20070102184007.GB17898@hades.madism.org","threadId":"6196","inReplyTo":"459AA31E.5070705@gmail.com","subject":"[RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-01-02T18:40:07Z","receivedAt":"2007-01-02T18:40:07Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Jan 02, 2007 at 07:23:26PM +0100, Steve Frécinaux wrote:\n> Hello,\n> \n> When using git-svn to access a SVN repo, the commit policy may vary. \n> While git makes you commit small patches often, svn users tend to prefer \n> bigger patches that implement a functionnality at once.\n> \n> So at the end you have a SVN commit which corresponds to several git \n> ones.\n> \n> What you can do in this case is :\n> \n>   git-svn commit-diff --edit -r$REV remotes/git-svn HEAD\n> \n> Which effect is that it commits (at once) all the commits between the \n> latest svn fetch and HEAD.\n> \n> What I'm proposing here is this:\n> \n>  - use the latest fetched rev the default for the -r argument.\n>  - use remotes/git-svn and HEAD the defaults for the treeish objects.\n> \n> A smarter way to take these defaults would be to take the last revision \n> in the current branch (which can be something else than git-svn if it \n> wasn't rebased/merged recently) and the relevant commit in the current \n> branch.\n> \n> Additionnaly, --edit could be enabled by default if -m is not set and it \n> is used interactively, eventually using an option in repo-config.\n> \n> Any comment ?\n\n  of course a git svn subcommand that in fact allow you to cherry pick\npatches from `git rev-list remotes/git-svn` would be *really* good, but\nhere is what I do:\n\n  1. be up2date:\n    $ git svn fetch\n    $ git rebase remotes/git-svn\n\n  2. create a local branch to cherry pick the hunk you want to combine:\n    $ git branch -f svn-tmp remotes/git-svn\n    # cherry pick the commits you want using any method you like, eg:\n    $ git cherry-pick <....>\n     or\n    $ git am [some previously built mailbox of changes]\n\n    I happen to prefer the later since I do git format-patch\n    remotes/git-svn from my master branch, and use my MUA as a\n    poor-man's interactive way to select patches I want. Though\n    sometimes you miss some dependant patches, and I suppose git\n    cherry-pick would be better at that game, YMMV.\n\n  3. git svn commit HEAD (not dcommit) to force merging of all your\n     local patches in one svn changeset.\n\n     note that you may need a step (1) update if anything changed since,\n     if you don't want to see git-svn undo the commits other user may\n     have done since your last (1) update, commit your change, and\n     commit the previously undone commits back. I did that once when I\n     was a beginner with git-svn, and it generated a huge pile of\n     globally indempotend commits, and flooded the commit mail list,\n     that was kind of funny ;)\n\n  4. go back to your branch as usual, and resync to the new svn state:\n     git checkout master\n     git svn fetch\n     git rebase remotes/git-svn # should merge things happily\n\n     you can then go back to (2) and iterate until your\n     `git rev-list remotes/git-svn` is empty.\n\n  This is highly unpretty, and relies in the fact that nobody commited\ninto the svn between your set 2 and 3. I suppose you can achieve the\nsame by creating combined changeset from git, instead of a cherry\npicking, in some kind of \"combining\" branch, and then just use\n`git svn dcommit` from there, but I've found no convenient (I mean no\nway *I* find convenient) way to do that. Maybe someone here has a better\nidea :)\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"30680","messageId":"20070102191810.GA18856@localdomain","threadId":"6196","inReplyTo":"459AA31E.5070705@gmail.com","subject":"Re: [RFC] git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-01-02T19:18:10Z","receivedAt":"2007-01-02T19:18:10Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Steve Fr?cinaux <nudrema@gmail.com> wrote:\n> Hello,\n> \n> When using git-svn to access a SVN repo, the commit policy may vary. \n> While git makes you commit small patches often, svn users tend to prefer \n> bigger patches that implement a functionnality at once.\n> \n> So at the end you have a SVN commit which corresponds to several git ones.\n> \n> What you can do in this case is :\n> \n>   git-svn commit-diff --edit -r$REV remotes/git-svn HEAD\n> \n> Which effect is that it commits (at once) all the commits between the \n> latest svn fetch and HEAD.\n> \n> What I'm proposing here is this:\n> \n>  - use the latest fetched rev the default for the -r argument.\n\nYes, this is very important.\n\n>  - use remotes/git-svn and HEAD the defaults for the treeish objects.\n> \n> A smarter way to take these defaults would be to take the last revision \n> in the current branch (which can be something else than git-svn if it \n> wasn't rebased/merged recently) and the relevant commit in the current \n> branch.\n> \n> Additionnaly, --edit could be enabled by default if -m is not set and it \n> is used interactively, eventually using an option in repo-config.\n\nThis sounds useful.  This is basically what 'set-tree' (the command\nformerly known as 'commit') was meant to do originally.  Unlike \nset-tree (or perhaps with modifying set-tree), this should\nrebase or reset afterwards to linearize history like 'dcommit'.\n\n-- \nEric Wong\n"},{"id":"30696","messageId":"7vr6udtbmv.fsf@assigned-by-dhcp.cox.net","threadId":"6196","inReplyTo":"459AA31E.5070705@gmail.com","subject":"Re: [RFC] git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T20:30:16Z","receivedAt":"2007-01-02T20:30:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steve Frécinaux <nudrema@gmail.com> writes:\n\n> When using git-svn to access a SVN repo, the commit policy may\n> vary. While git makes you commit small patches often, svn users tend\n> to prefer bigger patches that implement a functionnality at once.\n>\n> So at the end you have a SVN commit which corresponds to several git ones.\n\nI personally think this is solving a wrong problem.  Commit\ngranularity is a property of the project, the way in which\npeople involved in the project prefer working.  It is not about\n\"svn users\" vs \"git users\", and it shouldn't be, especially if\nthe end result is still a single project.\n\nIs git \"making you commit small patches often\"?  I honestly hope\nwe are not forcing you to do so, although we took pains to make\nit easier because it tends to be easier to look at the history\nlater when commit boundaries match the logical steps of\nevolution.\n\nSo my suggestion would be to educate people who tend to make too\nlarge commits better separate their commits, and at the same\ntime coallesce the commits you create on the git side into a\npresentable size, if you acquired a bad habit of making too\nsmall commits, so that everybody follows the same commit\ngranularity guideline set by the project.\n"},{"id":"30700","messageId":"20070102211339.GF17898@hades.madism.org","threadId":"6196","inReplyTo":"7vr6udtbmv.fsf@assigned-by-dhcp.cox.net","subject":"[RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-01-02T21:13:39Z","receivedAt":"2007-01-02T21:13:39Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Jan 02, 2007 at 12:30:16PM -0800, Junio C Hamano wrote:\n> Steve Frécinaux <nudrema@gmail.com> writes:\n> \n> > When using git-svn to access a SVN repo, the commit policy may\n> > vary. While git makes you commit small patches often, svn users tend\n> > to prefer bigger patches that implement a functionnality at once.\n> >\n> > So at the end you have a SVN commit which corresponds to several git ones.\n> \n> I personally think this is solving a wrong problem.  Commit\n> granularity is a property of the project, the way in which\n> people involved in the project prefer working.  It is not about\n> \"svn users\" vs \"git users\", and it shouldn't be, especially if\n> the end result is still a single project.\n> \n> Is git \"making you commit small patches often\"?  I honestly hope\n> we are not forcing you to do so, although we took pains to make\n> it easier because it tends to be easier to look at the history\n> later when commit boundaries match the logical steps of\n> evolution.\n> \n> So my suggestion would be to educate people who tend to make too\n> large commits better separate their commits, and at the same\n> time coallesce the commits you create on the git side into a\n> presentable size, if you acquired a bad habit of making too\n> small commits, so that everybody follows the same commit\n> granularity guideline set by the project.\n\n  Though an operation that I'd often like to do is to merge two (or\nmore) patches as one, and reedit its entry, preferably as a merge of the\ntwo (or more) old logs.\n\n  The reason is simple, I often use git commit as :wq in my editor, and\nsometimes think that in a A--B--C--D and in fact, I'd prefer to have:\n\n  {A,C}--B--D. how is it possible to do that in a not too cumbersome\nway? because that would make sens to work in some scratch branch, and\nthen reorganize patches in a saner better way in the master branch.\n\n  But I fail to see how to achieve that without using cumbersome\nexport-to-patch then git apply patch and edit logs which is painful and\nnot really using git.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"30702","messageId":"052E1601-5422-48A0-81B3-9A454467CE5F@silverinsanity.com","threadId":"6196","inReplyTo":"20070102211339.GF17898@hades.madism.org","subject":"Re: [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-02T21:26:46Z","receivedAt":"2007-01-02T21:26:46Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":">   The reason is simple, I often use git commit as :wq in my editor,  \n> and\n> sometimes think that in a A--B--C--D and in fact, I'd prefer to have:\n>\n>   {A,C}--B--D. how is it possible to do that in a not too cumbersome\n> way? because that would make sens to work in some scratch branch, and\n> then reorganize patches in a saner better way in the master branch.\n>\n>   But I fail to see how to achieve that without using cumbersome\n> export-to-patch then git apply patch and edit logs which is painful  \n> and\n> not really using git.\n\nThe command you seem to be looking for is git-cherry-pick.  To  \ncombine the two commits, I'd do something like:\n\n$ git cherry-pick A\n$ git cherry-pick C\n$ git reset HEAD~2\n$ git add <files>\n$ git commit\n\nAnd then you could rebase the work branch on top of the new master,  \nwhich should catch that A and C were already committed with minimal  \neffort.  Of course there may be a cleaner way to do it, but this is  \nwhat I do.\n\n~~ Brian Gernhardt\n"},{"id":"30707","messageId":"enekbs$n8g$1@sea.gmane.org","threadId":"6196","inReplyTo":"052E1601-5422-48A0-81B3-9A454467CE5F@silverinsanity.com","subject":"Re: [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-02T21:58:14Z","receivedAt":"2007-01-02T21:58:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Brian Gernhardt wrote:\n\n>>   The reason is simple, I often use git commit as :wq in my editor,  \n>> and\n>> sometimes think that in a A--B--C--D and in fact, I'd prefer to have:\n>>\n>>   {A,C}--B--D. how is it possible to do that in a not too cumbersome\n>> way? because that would make sens to work in some scratch branch, and\n>> then reorganize patches in a saner better way in the master branch.\n>>\n>>   But I fail to see how to achieve that without using cumbersome\n>> export-to-patch then git apply patch and edit logs which is painful  \n>> and\n>> not really using git.\n> \n> The command you seem to be looking for is git-cherry-pick.  To  \n> combine the two commits, I'd do something like:\n> \n> $ git cherry-pick A\n> $ git cherry-pick C\n> $ git reset HEAD~2\n> $ git add <files>\n> $ git commit\n\nOr better learn about --no-commit option of git-cherry-pick. Or if you\ndon't mind additional tools I think you can do this using StGIT.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30709","messageId":"7vwt45rsuw.fsf@assigned-by-dhcp.cox.net","threadId":"6196","inReplyTo":"20070102211339.GF17898@hades.madism.org","subject":"Re: [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T22:01:11Z","receivedAt":"2007-01-02T22:01:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit <madcoder@debian.org> writes:\n\n> ... and\n> sometimes think that in a A--B--C--D and in fact, I'd prefer to have:\n>\n>   {A,C}--B--D. how is it possible to do that in a not too cumbersome\n> way? because that would make sens to work in some scratch branch, and\n> then reorganize patches in a saner better way in the master branch.\n>\n>   But I fail to see how to achieve that without using cumbersome\n> export-to-patch then git apply patch and edit logs which is painful and\n> not really using git.\n\nFirst of all, \"format-patch and then edit\" is a perfectly sane\nway to use git.  Any workflow that takes advantage of cheap\nbranch creatin and cheap resetting of the tip of a branch _is_\n\"really using git\".  It depends on the size of the series you\nare redoing, but I do that all the time.\n\nAlso cherry-pick, rebase, squash merge are your friends.\n\nIf you are on $original branch (which may be your 'master') with\ncommits A--B--C--D:\n\n\tgit checkout -b temp HEAD~3 ;# that's A\n        git cherry-pick $original~1 ;# that's C\n\tgit checkout $original\n        git rebase temp\n\nwould make the $original A--C'-B'-D'.  Then:\n\n\tgit checkout temp ; git reset --hard $original~4 ;# parent of A\n\tgit merge -s squash $original~2 ;# squash A and C'\n\nwould prepare you to make a squashed commit out of the two to\nthe temp branch.  Then:\n\n\tgit checkout $original\n        git rebase --onto temp HEAD~2 ;# that's C'\n\tgit branch -d temp\n\nwould give you (A+C)--B'-D' on $original branch.\n\nStGIT would make life even easier for you.  It is designed to\nmake things like the above simpler.\n"},{"id":"30714","messageId":"20070102222708.GG17898@hades.madism.org","threadId":"6196","inReplyTo":"enekbs$n8g$1@sea.gmane.org","subject":"[RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-01-02T22:27:08Z","receivedAt":"2007-01-02T22:27:08Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Jan 02, 2007 at 10:58:14PM +0100, Jakub Narebski wrote:\n> Brian Gernhardt wrote:\n> \n> >>   The reason is simple, I often use git commit as :wq in my editor,  \n> >> and\n> >> sometimes think that in a A--B--C--D and in fact, I'd prefer to have:\n> >>\n> >>   {A,C}--B--D. how is it possible to do that in a not too cumbersome\n> >> way? because that would make sens to work in some scratch branch, and\n> >> then reorganize patches in a saner better way in the master branch.\n> >>\n> >>   But I fail to see how to achieve that without using cumbersome\n> >> export-to-patch then git apply patch and edit logs which is painful  \n> >> and\n> >> not really using git.\n> > \n> > The command you seem to be looking for is git-cherry-pick.  To  \n> > combine the two commits, I'd do something like:\n> > \n> > $ git cherry-pick A\n> > $ git cherry-pick C\n> > $ git reset HEAD~2\n> > $ git add <files>\n> > $ git commit\n> \n> Or better learn about --no-commit option of git-cherry-pick. Or if you\n> don't mind additional tools I think you can do this using StGIT.\n\n  oh those solutions look awsome and easily scriptable, which is\nexactly what I need, and it feels simpler to use for my small brain than\nthe solution Junio proposed. thanks a lot !\n\n  I wonder why I never got to that alone ...\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"30718","messageId":"459AE626.9040001@gmail.com","threadId":"6196","inReplyTo":"20070102211339.GF17898@hades.madism.org","subject":"Re: [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments","fromName":"Steve Frécinaux","fromEmail":"nudrema@gmail.com","sentAt":"2007-01-02T23:09:26Z","receivedAt":"2007-01-02T23:09:26Z","isPatch":false,"sender":{"key":"nudrema@gmail.com","avatar":null},"body":"Pierre Habouzit wrote:\n\n>   Though an operation that I'd often like to do is to merge two (or\n> more) patches as one, and reedit its entry, preferably as a merge of the\n> two (or more) old logs.\n\nActually that's more or less what I wanted to achieve, just that it was \nless general.\n\nUsing the solutions that have been proposed in this thread (using \ngit-cherry-pick -n and a work branch) looks satisfying for what I want \nto do. Then it's just a matter of cherry-picking the last \"work\" \npatches, commiting them as a whole in master and then using git-svn \ndcommit the regular way.\n"}]}