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

List:       kwrite-devel
Subject:    Re: VCS work flow?
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2014-02-26 17:48:22
Message-ID: lel9co$u1j$1 () ger ! gmane ! org
[Download RAW message or body]

On 2014-02-26 02:19, Kåre Särs 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 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.
>
> _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 interesting 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.

To Dominik's point, I'm personally on the fence w.r.t. single commit 
merges; at that point the only real value is that it preserves the 
original parent commit. (For kate I normally do rebase single commits.)

-- 
Matthew

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