Fwd: LyX convention for squash vs. merge/rebase?

[Vincent van Ravesteijn]

-- Forwarded message --
From: Vincent van Ravesteijn v...@lyx.org
Date: Fri, May 17, 2013 at 7:47 AM
Subject: Re: LyX convention for squash vs. merge/rebase?
To: Scott Kostyshak skost...@lyx.org



On Fri, May 17, 2013 at 5:11 AM, Scott Kostyshak skost...@lyx.org wrote:

 On Thu, May 16, 2013 at 8:34 PM, Cyrille Artho c.ar...@aist.go.jp wrote:
  Hi Scott,
  IMHO many small commits are almost always a lot better.
 
  git bisect can be very useful in tracking down problems when you have
 many
  small commits. With a single huge commit, that feature is almost useless.
 
  This benefit alone outweighs the small drawback of having multiple commit
  messages. (If you used meaningful messages during your commits, they in
  themselves can also be helpful.)

 Thanks for your comments Cyrille. I committed the series here:
 0d434033..43d71022

 I'd still be interested in what others prefer for the future.

In general I like to split up things, especially if it reflects the thought
process of a change, or if things get added step-by-step, such that the
individual commits are much more comprehensible. But, I am not interested
in commits that indicate that someone changed his mind a few times, or that
he was forgotten to do something or did it wrong in the first place. For
example, a commit like English tweaks shouldn't be there in general, but
in this case it makes sense because you show what you changed in the
original patch of Yihui.

A separate thing is that we might want to merge in such a change. That
would cause the master branch to have much fewer commits (if you use
--first-parent-only).
Vincent

Fwd: LyX convention for squash vs. merge/rebase?

[Vincent van Ravesteijn]

-- Forwarded message --
From: Vincent van Ravesteijn 
Date: Fri, May 17, 2013 at 7:47 AM
Subject: Re: LyX convention for squash vs. merge/rebase?
To: Scott Kostyshak 



On Fri, May 17, 2013 at 5:11 AM, Scott Kostyshak  wrote:

> On Thu, May 16, 2013 at 8:34 PM, Cyrille Artho  wrote:
> > Hi Scott,
> > IMHO many small commits are almost always a lot better.
> >
> > "git bisect" can be very useful in tracking down problems when you have
> many
> > small commits. With a single huge commit, that feature is almost useless.
> >
> > This benefit alone outweighs the small drawback of having multiple commit
> > messages. (If you used meaningful messages during your commits, they in
> > themselves can also be helpful.)
>
> Thanks for your comments Cyrille. I committed the series here:
> 0d434033..43d71022
>
> I'd still be interested in what others prefer for the future.
>
In general I like to split up things, especially if it reflects the thought
process of a change, or if things get added step-by-step, such that the
individual commits are much more comprehensible. But, I am not interested
in commits that indicate that someone changed his mind a few times, or that
he was forgotten to do something or did it wrong in the first place. For
example, a commit like "English tweaks" shouldn't be there in general, but
in this case it makes sense because you show what you changed in the
original patch of Yihui.

A separate thing is that we might want to merge in such a change. That
would cause the master branch to have much fewer commits (if you use
--first-parent-only).
Vincent