Junio C Hamano writes:
> Sergey Organov writes:
>
>> Nope. It seems like cherry-pick takes care of that:
>> ...
>> What do I miss?
>
> The fact that cherry-pick did not flag it as a potential conflict
> situation where a manual verification is required
> (the cherry-pick process can be fooled by
Sergey Organov writes:
> Nope. It seems like cherry-pick takes care of that:
> ...
> What do I miss?
The fact that cherry-pick did not flag it as a potential conflict
situation where a manual verification is required (the cherry-pick
process can be fooled by textual similarity and either add the
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> I wonder if it will be the right way to get a correct result to
>> apply the difference to go from B to Z on top of an old commit when
>> you are side-porting.
>>
>> Imagine you want to backport the same X-Y history by redoing the
>> merge Z o
Junio C Hamano writes:
> I wonder if it will be the right way to get a correct result to
> apply the difference to go from B to Z on top of an old commit when
> you are side-porting.
>
> Imagine you want to backport the same X-Y history by redoing the
> merge Z on top of another child of O (i.e.
Junio C Hamano writes:
> Sergey Organov writes:
>
>> 1. How to calculate the set of commits to rebase.
>>
>> 2. How to rebase merge commits.
>>
>> Can we leave (1) for a while at its current state and focus on (2)?
>
> Perhaps. You would have to be careful though, so let me think aloud
> a bit.
Sergey Organov writes:
> 1. How to calculate the set of commits to rebase.
>
> 2. How to rebase merge commits.
>
> Can we leave (1) for a while at its current state and focus on (2)?
Perhaps. You would have to be careful though, so let me think aloud
a bit...
Suppose you started from an upstre
Johannes Sixt writes:
>> Junio C Hamano writes:
[...]
> The patch was discussed here:
> http://thread.gmane.org/gmane.comp.version-control.git/198125
>
> The reason that this has not progressed any further is this response
> in the thread:
>
> http://thread.gmane.org/gmane.comp.version-control
On 30.03.2015 22:23, Junio C Hamano wrote:
Ignoring a merge can be read as ignoring the changes a merge commit
introduces altogether, as if the entire side branch the merge commit
merged was removed from the history. But that is not what happens
Sounds good to me. Thanks.
--
Sebastian Schube
Junio C Hamano writes:
>> Ignoring a merge sounds like dropping the merge commit and all side
>> branches it merges from history.
>
> ... Yes to _some_ people (including you, but not me). And that is
> why we are trying to improve the text in the documentation, no?
Let's try this again as I do
Sebastian Schuberth writes:
>> That is, at least to me,
>>
>> D---E---F
>> / \
>> ---A---B---C---G---H
>>
>> the former, i.e. "the changes the merge G introdues", is "diff C G",
>
> To me, too. In other words, this is the combined diff of all commits
> reachable from
On Mon, Mar 30, 2015 at 7:23 PM, Junio C Hamano wrote:
>> Ignoring a merge sounds like ignoring the changes a merge commit
>> introduces altogether, as if the merge commit was skipped or dropped from
>> history. But that is not what happens if "-p" is not specified.
>
> Every time I read the abov
Sebastian Schuberth writes:
> So how about:
>
> [PATCH] docs: Clarify what git-rebase's "-p" / "--preserve-merges" does
>
> Ignoring a merge sounds like ignoring the changes a merge commit
> introduces altogether, as if the merge commit was skipped or dropped from
> history. But that is not what
On 3/26/2015 19:18, Junio C Hamano wrote:
> Although I fully agree that the new text is better than the original,
> I think the new text fails to point out one major aspect by not
> mentioning "linear" or "flatten" anywhere. The point of "git rebase"
> without "-p" is not just to replay but to fl
Am 26.03.2015 um 22:17 schrieb Sergey Organov:
Junio C Hamano writes:
There however were repeated wishes (or wishful misunderstandings ;-)
that there were a mode to rebuild the trunk, considering only the
commits on the first-parent chain as "commits to be rebased",
recreating the history by re
Junio C Hamano writes:
[...]
> I think the current preserve-merges considers everything between
> and as "commits to be rebased", and recreate
> merges across these rebased tips of branches that are merged.
>
> There however were repeated wishes (or wishful misunderstandings ;-)
> that there w
Sebastian Schuberth writes:
>> Instead of flattening the history by replaying each
>> non-merge commit to be rebased, preserve the shape of the
>> rebased history by recreating merge commits as well.
>>
>> or something along that line, perhaps?
>
> Hm, I'm not sure about the "as we
On 26.03.2015 19:18, Junio C Hamano wrote:
Also, do not say that merge commits are *tried* to be recreated.
Good point. "We will try but it might fail" is better left unsaid
as that is true almost everywhere.
Exactly.
-p::
--preserve-merges::
-Instead of ignoring merges, try to re
Sebastian Schuberth writes:
> Also, do not say that merge commits are *tried* to be recreated.
Good point. "We will try but it might fail" is better left unsaid
as that is true almost everywhere.
> Signed-off-by: Sebastian Schuberth
> ---
> Documentation/git-rebase.txt | 2 +-
> 1 file chan
18 matches
Mail list logo
