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

-- 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

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

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). OK, I would like to start doing this because it is the most informative of how the development happened. In addition to

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

On Fri, May 17, 2013 at 3:42 AM, Vincent van Ravesteijn v...@lyx.org wrote: 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). OK, I would like to start doing this because it is

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

-- 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...

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

> > 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). > > OK, I would like to start doing this because it is the most > informative of how the development happened. In addition

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

On Fri, May 17, 2013 at 3:42 AM, Vincent van Ravesteijn wrote: >> > 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). >> >> OK, I would like to start doing

LyX convention for squash vs. merge/rebase?

I'm about to commit a layout and template for the R Journal. I'm not sure whether I should make one commit or a series of commits. On the one hand, a series of commits gives more information about how the layout and template were developed and the commits document the decisions that were made. My

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

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

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

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.

LyX convention for squash vs. merge/rebase?

I'm about to commit a layout and template for the R Journal. I'm not sure whether I should make one commit or a series of commits. On the one hand, a series of commits gives more information about how the layout and template were developed and the commits document the decisions that were made. My

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

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

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

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