[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dealing with local patches - mercurial queues over bzr/git checkout
From: |
Eli Zaretskii |
Subject: |
Re: dealing with local patches - mercurial queues over bzr/git checkout |
Date: |
Tue, 07 Jan 2014 05:42:49 +0200 |
> From: Achim Gratz <address@hidden>
> Date: Mon, 06 Jan 2014 22:51:47 +0100
>
> I find that in Git simply rebasing the local branch on top of upstream
> (which can be configured to be done instead of a merge when you "pull")
> keeps that history inside the local branch intact while producing a nice
> linear history when you finally push it upstream (with or without
> rewriting it before the push), without the messiness of many superfluous
> merges.
But then if I need to bisect the merge done by you, I see a single
large commit, instead of the series of small ones. And that makes it
hard both to bisect and, if needed, revert a small part of the merge.
Anyway, this is an age-old argument. I don't want to start another
one; if you like your workflow, and we decide that it is OK to do that
in Emacs development, so be it. I just wanted to point out that what
Jarek does is not without price.
> It's a slightly different workflow than what you will find in most
> tutorials, but I feel it actually works better than patch stacks
I find that patch stacks are unnecessary most of the time. Just
firing up another branch solves most of the problems that stacks are
supposed to solve.