On Wednesday 26 February 2014 12:48:22 Matthew Woehlke wrote:
> On 2014-02-26 02:19, K=E5re S=E4rs wrote:
> > On Tuesday 25 February 2014 17:27:45 Matthew Woehlke wrote:
> >> As I'm getting mixed responses via RB, I thought I'd ask here... What =
is
> >> the preferred VCS work flow for kate.git these days, especially for lo=
ng
> >> commit chains covered by a single review request? Rebase or merge?
> >> =

> >> Some arguments for each:
> >> =

> >> - Rebase preserves linear history, which may be simpler to look at.
> >> =

> >> - Merging makes it clear what commits are covered by a review request
> >> and preserves the commit where a commit chain was started.
> > =

> > _I_ definitely prefer rebase as the new feature/bugfix is in one chunk =
in
> > the history. How the feature was developed and in what time frame has
> > usually no relevance. It was added to the public repository at one
> > specific time and the change in that specific time is what is interesti=
ng
> > to me :)
> =

> That sounds to me like an argument for merge :-).
> =

> To be clear: I *don't* like squashing a series of well-formed changes
> into a single large commit. In which case, a merge allows following
> first-parents to show you "this feature was added at this point" as a
> single commit.

Just clarification: I did not mean to squash the commits to one large commi=
t.

Merges can spreads the commit messages over time so that the individual =

messages are spread out in the history and thus a tiny bit harder to find =

without a qgit or similar UI. But As Christoph said this is not a big deal =
:)


/K=E5re
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel