[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Messing with the VC history
From: |
Eli Zaretskii |
Subject: |
Re: Messing with the VC history |
Date: |
Sun, 16 Nov 2014 20:13:02 +0200 |
> From: Achim Gratz <address@hidden>
> Date: Sun, 16 Nov 2014 17:33:32 +0100
>
> > What about "pull --rebase=preserve"? It sounds like a less radical
> > option, did I miss something?
>
> For the usual "let's fix this thing and get it upstream" type of
> work it shouldn't matter. Otherwise you'll have to remember to
> configure your feature branches differently if they contain merges
> (local merges that is, because merges with upstream wouldn't enter
> into the branch if you rebase by default).
Sorry, I'm not sure I follow: the pull.rebase = preserve setting is
only for the "pull" command, right? It doesn't affect "merge" and
commands that invoke "merge", like "cherry-pick", right?
If so, why would I need to configure my feature branches differently,
if I don't intend to pull into them from upstream?
My workflow with feature branches is create the branch; do the work;
when it's almost done, merge from master and test; then merge back
into master and push. There's no pulling here except from upstream to
master.
> For longer term work that's kept in feature branches I prefer to
> rebase on top of upstream rather than merge and usually do a full
> rewrite before pushing it upstream as well.
Well, I prefer merging instead, see above.
Re: Messing with the VC history, Eli Zaretskii, 2014/11/16
- Re: Messing with the VC history, Óscar Fuentes, 2014/11/16
- Re: Messing with the VC history, Eli Zaretskii, 2014/11/16
- Re: Messing with the VC history, Stephen J. Turnbull, 2014/11/16
- Re: Messing with the VC history, John Yates, 2014/11/16
- Re: Messing with the VC history, Stephen J. Turnbull, 2014/11/16
- Re: Messing with the VC history, Lars Brinkhoff, 2014/11/18
- Re: Messing with the VC history, David Kastrup, 2014/11/18
- Re: Messing with the VC history, Stephen J. Turnbull, 2014/11/18