Junio C Hamano gits...@pobox.com writes:
Sergey Organov s.orga...@javad.com 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
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com 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
Sergey Organov s.orga...@javad.com 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
Johannes Sixt j...@kdbg.org writes:
Junio C Hamano gits...@pobox.com 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:
Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com writes:
Sergey Organov sorga...@gmail.com 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
Sergey Organov sorga...@gmail.com 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
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 flatten
I
Sebastian Schuberth sschube...@gmail.com 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
Sebastian Schuberth sschube...@gmail.com 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
Junio C Hamano gits...@pobox.com 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
On Mon, Mar 30, 2015 at 7:23 PM, Junio C Hamano gits...@pobox.com 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
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
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
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
Sebastian Schuberth sschube...@gmail.com 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 sschube...@gmail.com
---
Sebastian Schuberth sschube...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
[...]
I think the current preserve-merges considers everything between
upstream and branch as commits to be rebased, and recreate
merges across these rebased tips of branches that are merged.
There however were repeated wishes (or wishful
Am 26.03.2015 um 22:17 schrieb Sergey Organov:
Junio C Hamano gits...@pobox.com 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
19 matches
Mail list logo
