[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: VCS work flow?
From:       Michal Humpula <michal.humpula () seznam ! cz>
Date:       2014-02-26 16:19:53
Message-ID: 5039285.8huMSnCDsY () amonsul
[Download RAW message or body]

On Wednesday 26 of February 2014 15:07:34 Dominik Haumann wrote:
> On Tuesday, February 25, 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 long
> > 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.
> 
> If it's a single commit, imo a rebase makes more sense.
> Otherwise, if you develop a feature that changes quite a huge amount of code
> over multiple commits, a merge commit makes sense.

You can still rebase in that case too;-)

As many people are failing to understand the beauty of rebase, I on the other 
hand fail to understand the beauty of merge. It seems there is a lot of 
bikeshed on the internet about rebase vs. merge. So please don't mind me:)

I'm more annoyed with commit messages summaries consisting of several 
sentences. Apparently those people do exists:)

Cheers

Michal

> Greetings,
> Dominik
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel

_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]