asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Merging vs. squashing
Date Thu, 24 Sep 2015 01:29:41 GMT
My experience or knowledge is hardly comprehensive, but merging branches
has most of the benefit of squash commits while retaining history.

Cherry picking (in my experience) works very much as desired. The fact that
a commit exists on two branches doesn't seem to cause any trouble at all at
merge time.  The flexibility is fairly awesome.  I would imagine that there
are counter examples where subsequent changes make the merge complex and I
have no idea what the limits are. All I can say is that in the few years I
have been working with git, I have been astounded at how well the complex
fringes work.

Rebasing interactively is another case.  I routinely use this to make my
local history more sensible. Within reason, it allows me to squash and
re-order my own commits so that there appears to be more order in the
historical record than was in my head at the time I did the work.






On Wed, Sep 23, 2015 at 6:01 PM, Till Westmann <tillw@apache.org> wrote:

> I’m certainly not an expert on git as I never took the time (or needed) to
> dive deeply into it.
>
> Reading this thread it seems to me that we have a number of reasonable
> wishes what we would like to do (e.g. squash commits to get a readable
> history for the master branch, cherry-pick between branches to avoid
> duplicate work, …) but it seems that there’s no obvious way to achieve all
> of them.
>
> If that’s indeed the case, we’d have to decide which wish is more
> important and I think that different people will have different opinions on
> this. Since I’m a big fan of readable history (and seeing the result of a
> code review in the master history as opposed to a number of intermediate
> steps), I’m pretty happy with the current state of the world.
>
> Given the problem of having a subset of code that could benefit 2 branches
> I would try to separate it out, review and merge it to master, and to merge
> master back into the 2 branches. However, I see that this could be a lot of
> work and there could be reasons why is is not feasible.
>
> Just my 2c (to have more people chiming in :) )
> Till
>
> On 23 Sep 2015, at 15:38, Chris Hillery wrote:
>
> P.S. I'd love it if anyone else with opinions or experience would chime in
>> here... I'm pretty sure I don't have all the answers, so I don't want to
>> seem like I'm trying to dictate the discussion.
>>
>> Ceej
>> aka Chris Hillery
>>
>> On Wed, Sep 23, 2015 at 3:38 PM, Chris Hillery <chillery@hillery.land>
>> wrote:
>>
>> On Wed, Sep 23, 2015 at 10:40 AM, Jianfeng Jia <jianfeng.jia@gmail.com>
>>> wrote:
>>>
>>> I hit another similar scenario that squash may make things harder.
>>>>
>>>> Now I’m working the UTF8 encoding task. Some part of work has been done
>>>> in Taewoo’s branch. But his branch is a bigger change that won’t get
>>>> into
>>>> master
>>>> soon. I’d like to cherry-pick several commits from his branch and then
>>>> continue
>>>> on my task. Then both of us won’t hit the merging conflict in future.
>>>>
>>>>
>>> That is, I believe, already not true. Cherry-pick and squashed merge have
>>> basically the same effect - they create a new commit with no lineage to
>>> the
>>> original. If you cherry-pick from his branch, then even if you merged
>>> yours
>>> to the trunk (rather than squashing), he'd still get conflicts the next
>>> time he updated.
>>>
>>> I will admit I'm not 100% sure I'm correct about this. I've seen some
>>> evidence that git can handle a rebase when the two branches each have a
>>> *single* commit which happens to contain precisely the same diffs, as
>>> would
>>> happen with a cherry-pick that didn't require any conflict resolution of
>>> its own. I'm not confident this always works, and I've never experimented
>>> to see if it works on a merge rather than a rebase. I wouldn't want to
>>> make
>>> any sweeping process decisions until at least we were sure we understood
>>> what works and what doesn't.
>>>
>>> If we did merges all the time instead of squashes and cherry-picks, then
>>> you would be able to share some of Taewoo's work if you could *merge* it
>>> to
>>> your branch. But as you might guess, merging a couple of changes from the
>>> middle of a foreign branch is quite challenging at best.
>>>
>>> Ceej
>>> aka Chris Hillery
>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message