Re: [RFC] git-svn: make git-svn commit-diff able to work without explicit arguments

Steve Frécinaux [off-list ref] writes:

When using git-svn to access a SVN repo, the commit policy may
vary. While git makes you commit small patches often, svn users tend
to prefer bigger patches that implement a functionnality at once.

So at the end you have a SVN commit which corresponds to several git ones.

I personally think this is solving a wrong problem.  Commit
granularity is a property of the project, the way in which
people involved in the project prefer working.  It is not about
"svn users" vs "git users", and it shouldn't be, especially if
the end result is still a single project.

Is git "making you commit small patches often"?  I honestly hope
we are not forcing you to do so, although we took pains to make
it easier because it tends to be easier to look at the history
later when commit boundaries match the logical steps of
evolution.

So my suggestion would be to educate people who tend to make too
large commits better separate their commits, and at the same
time coallesce the commits you create on the git side into a
presentable size, if you acquired a bad habit of making too
small commits, so that everybody follows the same commit
granularity guideline set by the project.

On Tue, Jan 02, 2007 at 12:30:16PM -0800, Junio C Hamano wrote:

Steve Frécinaux [off-list ref] writes:

quoted

When using git-svn to access a SVN repo, the commit policy may
vary. While git makes you commit small patches often, svn users tend
to prefer bigger patches that implement a functionnality at once.

So at the end you have a SVN commit which corresponds to several git ones.

I personally think this is solving a wrong problem.  Commit
granularity is a property of the project, the way in which
people involved in the project prefer working.  It is not about
"svn users" vs "git users", and it shouldn't be, especially if
the end result is still a single project.

Is git "making you commit small patches often"?  I honestly hope
we are not forcing you to do so, although we took pains to make
it easier because it tends to be easier to look at the history
later when commit boundaries match the logical steps of
evolution.

So my suggestion would be to educate people who tend to make too
large commits better separate their commits, and at the same
time coallesce the commits you create on the git side into a
presentable size, if you acquired a bad habit of making too
small commits, so that everybody follows the same commit
granularity guideline set by the project.

  Though an operation that I'd often like to do is to merge two (or
more) patches as one, and reedit its entry, preferably as a merge of the
two (or more) old logs.

  The reason is simple, I often use git commit as :wq in my editor, and
sometimes think that in a A--B--C--D and in fact, I'd prefer to have:

  {A,C}--B--D. how is it possible to do that in a not too cumbersome
way? because that would make sens to work in some scratch branch, and
then reorganize patches in a saner better way in the master branch.

  But I fail to see how to achieve that without using cumbersome
export-to-patch then git apply patch and edit logs which is painful and
not really using git.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

  The reason is simple, I often use git commit as :wq in my editor,  
and
sometimes think that in a A--B--C--D and in fact, I'd prefer to have:

  {A,C}--B--D. how is it possible to do that in a not too cumbersome
way? because that would make sens to work in some scratch branch, and
then reorganize patches in a saner better way in the master branch.

  But I fail to see how to achieve that without using cumbersome
export-to-patch then git apply patch and edit logs which is painful  
and
not really using git.

The command you seem to be looking for is git-cherry-pick.  To  
combine the two commits, I'd do something like:

$ git cherry-pick A
$ git cherry-pick C
$ git reset HEAD~2
$ git add <files>
$ git commit

And then you could rebase the work branch on top of the new master,  
which should catch that A and C were already committed with minimal  
effort.  Of course there may be a cleaner way to do it, but this is  
what I do.

~~ Brian Gernhardt

Brian Gernhardt wrote:

quoted

  The reason is simple, I often use git commit as :wq in my editor,  
and
sometimes think that in a A--B--C--D and in fact, I'd prefer to have:

  {A,C}--B--D. how is it possible to do that in a not too cumbersome
way? because that would make sens to work in some scratch branch, and
then reorganize patches in a saner better way in the master branch.

  But I fail to see how to achieve that without using cumbersome
export-to-patch then git apply patch and edit logs which is painful  
and
not really using git.

The command you seem to be looking for is git-cherry-pick.  To  
combine the two commits, I'd do something like:

$ git cherry-pick A
$ git cherry-pick C
$ git reset HEAD~2
$ git add <files>
$ git commit

Or better learn about --no-commit option of git-cherry-pick. Or if you
don't mind additional tools I think you can do this using StGIT.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Tue, Jan 02, 2007 at 10:58:14PM +0100, Jakub Narebski wrote:

Brian Gernhardt wrote:

quoted

quoted

  The reason is simple, I often use git commit as :wq in my editor,  
and
sometimes think that in a A--B--C--D and in fact, I'd prefer to have:

  {A,C}--B--D. how is it possible to do that in a not too cumbersome
way? because that would make sens to work in some scratch branch, and
then reorganize patches in a saner better way in the master branch.

  But I fail to see how to achieve that without using cumbersome
export-to-patch then git apply patch and edit logs which is painful  
and
not really using git.

The command you seem to be looking for is git-cherry-pick.  To  
combine the two commits, I'd do something like:

$ git cherry-pick A
$ git cherry-pick C
$ git reset HEAD~2
$ git add <files>
$ git commit

Or better learn about --no-commit option of git-cherry-pick. Or if you
don't mind additional tools I think you can do this using StGIT.

  oh those solutions look awsome and easily scriptable, which is
exactly what I need, and it feels simpler to use for my small brain than
the solution Junio proposed. thanks a lot !

  I wonder why I never got to that alone ...
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Pierre Habouzit wrote:

  Though an operation that I'd often like to do is to merge two (or
more) patches as one, and reedit its entry, preferably as a merge of the
two (or more) old logs.

Actually that's more or less what I wanted to achieve, just that it was 
less general.

Using the solutions that have been proposed in this thread (using 
git-cherry-pick -n and a work branch) looks satisfying for what I want 
to do. Then it's just a matter of cherry-picking the last "work" 
patches, commiting them as a whole in master and then using git-svn 
dcommit the regular way.