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
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 this options is not specified.
Instead, what happens is that the separate commits a merge commit
introduces are replaye
19 matches
Mail list logo
