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

From: Pierre Habouzit <madcoder@debian.org>
Date: Jan 2, 2007, 21:13 UTC
Message-ID: <20070102211339.GF17898@hades.madism.org>
In-Reply-To: <7vr6udtbmv.fsf@assigned-by-dhcp.cox.net>

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

Show 26 quoted lines

> Steve Frécinaux <nudrema@gmail.com> 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.

  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