Re: [PATCH] cherry-pick: do not error on non-merge commits when '-m 1' is specified

Junio C Hamano writes: > Sergey Organov writes: > >> When cherry-picking multiple commits, it's impossible to have both >> merge- and non-merge commits on the same command-line. Not specifying >> '-m 1' results in cherry-pick refusing to handle merge commits, while &g

[PATCH] cherry-pick: do not error on non-merge commits when '-m 1' is specified

commits. Besides, as mainline is always the only parent for a non-merge commit, it made little sense to disable it in the first place. Signed-off-by: Sergey Organov --- sequencer.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/sequencer.c b/sequencer.c index 1ce6326

Re: [PATCH v9 00/17] rebase -i: offer to recreate commit topology by rebasing merges

This has been sent by mistake, I'm sorry, please disregard. Sergey Organov <sorga...@gmail.com> writes: > Johannes Schindelin <johannes.schinde...@gmx.de> writes: > >> Junio, I think this is now ready for `next`. Thank you for your patience >> and help with this. [...]

Re: [PATCH v9 00/17] rebase -i: offer to recreate commit topology by rebasing merges

Johannes Schindelin writes: > Junio, I think this is now ready for `next`. Thank you for your patience > and help with this. > > Once upon a time, I dreamed of an interactive rebase that would not > linearize all patches and drop all merge commits, but instead

[PATCH] cherry-pick: do not error on non-merge commits when '-m 1' is specified

commits. Besides, as mainline is always the only parent for a non-merge commit, it made little sense to disable it in the first place. Signed-off-by: Sergey Organov <sorga...@gmail.com> --- sequencer.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/sequencer.c b/seque

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

Junio C Hamano writes: [...] > > * js/rebase-recreate-merge (2018-04-11) 15 commits [...] > "git rebase" learned "--rebase-merges" to transplant the whole > topology of commit graph elsewhere. > > This looked more or less ready for 'next'. Please stop me if there > are

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

Hi Jacob, Jacob Keller <jacob.kel...@gmail.com> writes: > On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov <sorga...@gmail.com> wrote: >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >>> Hi Phillip, >>> >>> On Fri,

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

Johannes Schindelin writes: > Hi Phillip, > > On Fri, 13 Apr 2018, Phillip Wood wrote: > >> On 12/04/18 23:02, Johannes Schindelin wrote: >> > >> > [...] >> > >> > So: the order of the 3-way merges does matter. >> > >> > [...] >> >> Those conflicts certainly look

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

Hi Jacob, Jacob Keller <jacob.kel...@gmail.com> writes: > On Wed, Apr 11, 2018 at 10:42 PM, Sergey Organov <sorga...@gmail.com> wrote: >> Hi Jacob, >> >> Jacob Keller <jacob.kel...@gmail.com> writes: >>> On Wed, Apr 11, 2018 at 6:

Re: Draft of Git Rev News edition 38

Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > Hi, > > On Monday 16 April 2018 08:33 PM, Sergey Organov wrote: >> Christian Couder <christian.cou...@gmail.com> writes: >>> Here "the above article" means the Jake's "branch -l: print

Re: Draft of Git Rev News edition 38

Christian Couder writes: > Hi Sergey, > [...] > Jake wrote the article below the above line. His article summarizes > the discussions that happened following your email that is linked to > in the above line. The above line is actually the title of Jake's > second

Re: Draft of Git Rev News edition 38

it cherry-pick -mN of the > merge onto each topic branch being merged, and then merging the result. The reference to: Rebasing merges: a jorney to the ultimate solution (Road Clear) (written by Sergey Organov) belongs here, if at all. In addition, I'd like to see a minor edition to the

[PATCH] glossary: substitute "ancestor" for "direct ancestor" in 'push' description.

cription, we should simply say "ancestor", as everywhere else. Signed-off-by: Sergey Organov <sorga...@gmail.com> --- Documentation/glossary-content.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glos

Re: [PATCH v6 15/15] rebase -i --rebase-merges: add a section to the man page

Johannes Schindelin writes: > + > +* Merge branch 'report-a-bug' > +|\ > +| * Add the feedback button > +* | Merge branch 'refactor-button' > +|\ \ > +| |/ > +| * Use the Button class for all buttons > +| * Extract a generic Button class from the

Re: [PATCH v6 14/15] rebase -i: introduce --rebase-merges=[no-]rebase-cousins

Johannes Schindelin writes: [...] > ++ > +By default, or when `no-rebase-cousins` was specified, commits which do not > +have `` as direct ancestor will keep their original branch point. sans quotes, <...> are used without them throughout the manual page. > +If

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Wed, 11 Apr 2018, Sergey Organov wrote: > >> The RFC v2 and Phillip's strategy are essentially the same, as has been >> already shown multiple times, bot

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

Hi Jacob, Jacob Keller <jacob.kel...@gmail.com> writes: > On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov <sorga...@gmail.com> wrote: >> It was rather --recreate-merges just a few weeks ago, and I've seen >> nobody actually commented either in favor or against the &g

Re: [PATCH v6 04/15] sequencer: introduce new commands to reset the revision

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Wed, 11 Apr 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> [...] >> >> > We disallow '#' as la

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Wed, 11 Apr 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > On Tue, 10 Apr 2018, Sergey Organov wrote: >> > >>

Re: [PATCH v6 04/15] sequencer: introduce new commands to reset the revision

Hi Johannes, Johannes Schindelin writes: [...] > We disallow '#' as label because that character will be used as separator > in the upcoming `merge` command. Please consider to use # not only in `merge` and `reset`, but in the rest of the commands as well, to unify

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Tue, 10 Apr 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > Once upon a time, I dreamt of an interact

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

Hi Johannes, Johannes Schindelin writes: > Once upon a time, I dreamt of an interactive rebase that would not > flatten branch structure, but instead recreate the commit topology > faithfully. [...] > Think of --rebase-merges as "--preserve-merges done right".

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, > [...] > In the parlance of your RFC v2, where you start with this history (which I > translated into the left-to-right notation that is used in pretty much all > of Git's own documentation about interactive

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Wed, 28 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > I use rebase every day. I use the Git garden s

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Fri, 30 Mar 2018, Sergey Organov wrote: > >> Could we please agree to stop using backward compatibility as an >> objection in the discussion of the --recreate-merges featur

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi, > > On Thu, 29 Mar 2018, Sergey Organov wrote: > >> Jacob Keller <jacob.kel...@gmail.com> writes: >> >> > I care about the general compatibility of the rebase todo list

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Jacob Keller <jacob.kel...@gmail.com> writes: > On Wed, Mar 28, 2018 at 4:29 AM, Sergey Organov <sorga...@gmail.com> wrote: > >> Jacob Keller <jacob.kel...@gmail.com> writes: >> >> > On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov <sorga

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Jacob Keller <jacob.kel...@gmail.com> writes: > On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov <sorga...@gmail.com> wrote: >> >> Hi Johannes, >> >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: [...] > I'm pretty sure the fact has alr

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Jacob Keller <jacob.kel...@gmail.com> writes: > On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov <sorga...@gmail.com> wrote: >> >> Hi Johannes, >> >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> > Hi Sergey, >> > &

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, > [...] >> >> Reusing existing concepts where possible doesn`t have this problem. >> > >> > Existing concepts are great. As long as they fit the requirements of >> > the new scenarios. In this case, `pick` does

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, [...] > But I'll stop here. Even my account how there are conceptual differences > between the changes in merge vs non-merge commits (the non-merge commit > *introduces* changes, the merge commit *reconciles

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Tue, 27 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > On Mon, 12 Mar 2018, Sergey Organov wrote: >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin writes: > Hi Buga, > > On Tue, 13 Mar 2018, Igor Djordjevic wrote: > >> On 12/03/2018 11:46, Johannes Schindelin wrote: >> > >> > > Sometimes one just needs to read the manual, and I don`t really >> > > think this is a ton

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Mon, 12 Mar 2018, Sergey Organov wrote: > >> [...] >> >> Yet another consequence is that my approach will likely result in better >> code reuse. > > This

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Dear Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Mon, 12 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > [...] >> > >> > Where "e

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Mon, 12 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> > >> > On Wed, 7 Mar 2018, Sergey Organov wrote: >> > >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Buga, > > On Tue, 13 Mar 2018, Igor Djordjevic wrote: > >> On 12/03/2018 13:56, Sergey Organov wrote: >> > >> > > > I agree with both of you that `pick ` is inflexible >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > Hi Sergey, > > On 19/03/2018 06:44, Sergey Organov wrote: >> >> > > > > > Second side note: if we can fast-forward, currently we prefer >> > > > > > that, and I think we should

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga, Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > Hi Sergey, > > On 16/03/2018 08:31, Sergey Organov wrote: >> >> > > As I said, putting myself on the user side, I'd prefer entirely >> > > separate first step of the algorithm, exa

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Igor Djordjevic writes: > On 15/03/2018 00:11, Igor Djordjevic wrote: >> >> > > > Second side note: if we can fast-forward, currently we prefer >> > > > that, and I think we should keep that behavior with -R, too. >> > > >> > > I agree. >> > >> > I'm admittedly

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga, Igor Djordjevic writes: > Hi Sergey, [...] >> As I said, putting myself on the user side, I'd prefer entirely separate >> first step of the algorithm, exactly as written, with its own conflict >> resolution, all running entirely the same way as it does

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga, Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > Hi Sergey, > > On 14/03/2018 08:21, Sergey Organov wrote: >> >> There are still 2 issues about the implementation that need to be >> discussed though: >> >> 1. Still inverted order of

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Buga, Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > On 14/03/2018 15:24, Sergey Organov wrote: [...] >> Thinking about it I've got an idea that what we actually need is >> --no-flatten flag that, when used alone, will just tell "git rebase" to >&g

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Igor Djordjevic writes: > Hi Dscho, > > On 07/03/2018 08:26, Johannes Schindelin wrote: [...] >> Second side note: if we can fast-forward, currently we prefer that, and I >> think we should keep that behavior with -R, too. > > I agree. I'm admittedly somewhat lost

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga, Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > Hi Sergey, > > On 13/03/2018 17:10, Sergey Organov wrote: >> >> > Hi Sergey, I've been following this discussion from the sidelines, >> > though I haven't had time to study all the posts

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Phillip, Phillip Wood writes: [...] > Hi Sergey, I've been following this discussion from the sidelines, > though I haven't had time to study all the posts in this thread in > detail. I wonder if it would be helpful to think of rebasing a merge as > merging the

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Buga, Igor Djordjevic writes: [...] > I don`t know, I`m thinking if we are looking at todo list from > different perspectives - to you, it seems to be a sequence of > commands to create something new (yes, from something that already > exists, but that`s

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin writes: [...] > The biggest difference is that it is easy for me to see the motivation > behind Phillip's strategy, whereas I am still puzzled why one would come > up with a complicated strategy that splits merge commits and

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga, Igor Djordjevic writes: > Hi Dscho, [...] > I think the root of misunderstanding might be coming from the fact > that Sergey was mainly describing a general concept (without a > strictly defined implementation strategy, not being restricted to a >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin writes: > Hi Buga, > > On Sun, 11 Mar 2018, Igor Djordjevic wrote: > >> I agree with both of you that `pick ` is inflexible >> (not to say just plain wrong), but I never thought about it like that. >> >> If we are to extract further

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, [...] > That is misrepresenting what happened. No, it's you who are spreading misinformation, probably unintentional, but still. > First, you came up with a strategy. I pointed out shortcomings that > implied

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Wed, 7 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > How can your approach -- which relies *very muc

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga, Igor Djordjevic writes: [...] > That said, *if* we decide we like temporary commit U1' == U2' consistency > check (especially for non-interactive rebase, maybe), we can produce > these after the fact for the sake of the check only. I don't believe

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Wed, 7 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > On Tue, 6 Mar 2018, Sergey Organov wrote: >>

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Wed, 7 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > On Tue, 6 Mar 2018, Phillip Wood wrote: >&g

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Tue, 6 Mar 2018, Sergey Organov wrote: > >> This is v2 of my "Rebasing merges" proposal. > > Didn't we settle on Phillip's "perform successive three-w

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin writes: > Hi Phillip, > > On Tue, 6 Mar 2018, Phillip Wood wrote: > >> On 03/03/18 00:29, Igor Djordjevic wrote: >> > >> > On 02/03/2018 12:31, Phillip Wood wrote: >> >> >> >>> Thinking about it overnight, I now suspect that original

[RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi, This is v2 of my "Rebasing merges" proposal. Significant changes are: 1. Fixed mistake in the final merge step in the original proposal: wrong merge base was used. Thanks everybody who provided test-cases, and special thanks to Igor Djordjevic for

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Phillip, Phillip Wood writes: > On 03/03/18 00:29, Igor Djordjevic wrote: >> Hi Phillip, [...] >> >> The only thing I wonder of here is how would we check if the >> "rebased" merge M' was "clean", or should we stop for user amendment? >> With that other

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Igor, Igor Djordjevic writes: [...] > Now, not to get misinterpreted to pick sides in "(re)create" vs > "rebase" merge commit discussion, I just think these two (should) have > a different purpose, and actually having both inside interactive rebase > is what

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Plillip and Igor, Igor Djordjevic writes: > Hi Phillip, > > On 02/03/2018 12:31, Phillip Wood wrote: >> >> > Thinking about it overnight, I now suspect that original proposal had a >> > mistake in the final merge step. I think that what you did is a way to >> >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Igor, Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > Hi Sergey, > > On 01/03/2018 06:39, Sergey Organov wrote: [...] >> >> Yeah, I now see it myself. I'm sorry for being lazy and not inspecting >> this more carefully in the first place. > >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Igor, Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > Hi Sergey, > > On 28/02/2018 06:19, Sergey Organov wrote: >> >> > > (3) ---X1---o---o---o---o---o---X2 >> > >|\ |\ >> >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Igor Djordjevic writes: [...] >> > Hmm, still rushing it, but what about adding an additional step, >> > something like this: >> >> I think it's unneeded, as it should work fine without it, see another >> reply. > > Unfortunately, I have a broken test case saying

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Igor, Igor Djordjevic writes: > On 28/02/2018 21:25, Igor Djordjevic wrote: >> >> But U1' and U2' are really to be expected to stay the same in >> non-interactive rebase case only... > > Just to rephrase to "could be expected" here, meaning still not >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Igor Djordjevic writes: > On 28/02/2018 03:12, Igor Djordjevic wrote: >> >> Would additional step as suggested in [1] (using R1 and R2 to "catch" >> interactive rebase additions/amendments/drops, on top of U1' and >> U2'), make more sense (or provide an additional

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Jacob Keller <jacob.kel...@gmail.com> writes: > On Tue, Feb 27, 2018 at 10:14 AM, Junio C Hamano <gits...@pobox.com> wrote: >> Sergey Organov <sorga...@gmail.com> writes: >> >>> You've already bit this poor thingy to death. Please rather try your &

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin writes: > Hi Buga, > > thank you for making this a lot more understandable to this thick > developer. > > On Tue, 27 Feb 2018, Igor Djordjevic wrote: > >> On 27/02/2018 19:55, Igor Djordjevic wrote: >> > >> > It would be more along

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Junio C Hamano writes: > Igor Djordjevic writes: > >> On 27/02/2018 20:59, Igor Djordjevic wrote: >>> >>> (3) ---X1---o---o---o---o---o---X2 >>>|\ |\ >>>| A1---A2---A3---U1 | A1'--A2'--A3'--U1' >>>

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Igor Djordjevic writes: > On 28/02/2018 01:36, Jacob Keller wrote: >> >> > > (3) ---X1---o---o---o---o---o---X2 >> > >|\ |\ >> > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' >> > >| \ | >> > >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Igor Djordjevic writes: > On 27/02/2018 20:59, Igor Djordjevic wrote: >> >> (3) ---X1---o---o---o---o---o---X2 >>|\ |\ >>| A1---A2---A3---U1 | A1'--A2'--A3'--U1' >>| \ | >>|

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Junio C Hamano <gits...@pobox.com> writes: > Sergey Organov <sorga...@gmail.com> writes: > >> You've already bit this poor thingy to death. Please rather try your >> teeth on the proposed Trivial Merge (TM) method. > > Whatever you do, do *NOT* call any pa

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin writes: > Hi Buga, > > On Tue, 20 Feb 2018, Igor Djordjevic wrote: > >> I`m really interested in this topic, which seems to (try to) address the >> only "bad feeling" I had with rebasing merges - being afraid of silently >> losing

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, Johannes Schindelin writes: > Hi Buga, > > On Tue, 20 Feb 2018, Igor Djordjevic wrote: > >> I`m really interested in this topic, which seems to (try to) address the >> only "bad feeling" I had with rebasing merges - being afraid of silently >> losing

Re: cherry-pick '-m' curiosity

"G. Sylvie Davies" <syl...@bit-booster.com> writes: > On Mon, Feb 5, 2018 at 3:46 AM, Sergey Organov <sorga...@gmail.com> wrote: >> Hello, >> >> $ git help cherry-pick >> >> -m parent-number, --mainline parent-number >>

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Igor, Igor Djordjevic writes: > Hi Sergey, > [...] > > Even though this behavior is known and documented, it still left some > to be desired. > > Might be I`m missing something, but so far I like how described > approach just "feels right" (to me, for now),

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Jake, Jacob Keller <jacob.kel...@gmail.com> writes: > On Fri, Feb 16, 2018 at 5:08 AM, Sergey Organov <sorga...@gmail.com> wrote: >> Hi, >> >> By accepting the challenges raised in recent discussion of advanced >> support for history rebasing and

[RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi, By accepting the challenges raised in recent discussion of advanced support for history rebasing and editing in Git, I hopefully figured out a clean and elegant method of rebasing merges that I think is "The Right Way (TM)" to perform this so far troublesome operation. ["(TM)" here has second

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Johannes, Johannes Schindelin writes: [...] >> > I'd not argue this way myself. If there are out-of-git-tree non-human >> > users that accept and tweak todo _generated_ by current "git rebase -p" >> > _command_, I also vote for a new option. >> > >> >> To be

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi, > > On Tue, 13 Feb 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> > The wording is poor either way, but you are also not a native speaker

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Johannes Schindelin writes: [...] > Just to give you one concrete example: when I recently rebased some > patches (no reording or dropping involved here!) and one of the picks > failed with merge conflicts, I realized that that particular commit > introduced incorrect

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Jake, Jacob Keller <jacob.kel...@gmail.com> writes: > On Mon, Feb 12, 2018 at 12:39 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: >> Hi Sergey, >> >> On Mon, 12 Feb 2018, Sergey Organov wrote: >>> > Have a look at

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Mon, 12 Feb 2018, Sergey Organov wrote: > >> Thanks for explanations, and could you please answer this one: >> >> [...] >> >> >> I also have t

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Mon, 12 Feb 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> > >> > On Fri, 9 Feb 2018, Sergey Organov wrote:

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Johannes Sixt <j...@kdbg.org> writes: > Am 09.02.2018 um 07:11 schrieb Sergey Organov: >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >>> Let me explain the scenario which comes up plenty of times in my work with >>> Git for Windows. We ha

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Fri, 9 Feb 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> [...] >> >> > With this patch, the goodn

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Johannes, Thanks for explanations, and could you please answer this one: [...] >> I also have trouble making sense of "Recreate merge commits instead of >> flattening the history by replaying merges." Is it "> commits by replaying merges> instead of " or is it >> rather " instead of >

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Johannes Schindelin writes: [...] > With this patch, the goodness of the Git garden shears comes to `git > rebase -i` itself. Passing the `--recreate-merges` option will generate > a todo list that can be understood readily, and where it is obvious > how to reorder

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > On Wed, 7 Feb 2018, Sergey Organov wrote: >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> > +--recreate-merges:: >> > + Recreate merge commits instead of flattening the his

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Jacob Keller <jacob.kel...@gmail.com> writes: > On Tue, Feb 6, 2018 at 10:16 PM, Sergey Organov <sorga...@gmail.com> wrote: >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> [...] >> >>> +--recreate-merges:: >>>

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Johannes Schindelin writes: [...] > +--recreate-merges:: > + Recreate merge commits instead of flattening the history by replaying > + merges. Merge conflict resolutions or manual amendments to merge > + commits are not preserved. I wonder why you guys

Re: cherry-pick '-m' curiosity

Junio C Hamano <gits...@pobox.com> writes: > Sergey Organov <sorga...@gmail.com> writes: > >> Isn't it always the case that "mainline" is the first parent, as that's >> how "git merge" happens to work? > > You may not be merging into th

Re: cherry-pick '-m' curiosity

Stefan Beller <sbel...@google.com> writes: > On Mon, Feb 5, 2018 at 3:46 AM, Sergey Organov <sorga...@gmail.com> wrote: >> Hello, >> >> $ git help cherry-pick >> >> -m parent-number, --mainline parent-number >>Us

cherry-pick '-m' curiosity

Hello, $ git help cherry-pick -m parent-number, --mainline parent-number Usually you cannot cherry-pick a merge because you do not know which side of the merge should be considered the mainline. Isn't it always the case that "mainline" is the first parent, as

Re: How to re-merge paths differently?

"Philip Oakley" <philipoak...@iee.org> writes: > From: "Sergey Organov" <sorga...@gmail.com> >> Is there anything like this: >> >> $ git merge b >> [... lot of conflicts ...] >> $ git re-merge -X ours -- x/ # Leaves 0 conflicts

How to re-merge paths differently?

Hello, Is there anything like this: $ git merge b [... lot of conflicts ...] $ git re-merge -X ours -- x/ # Leaves 0 conflicts in x/ $ git re-merge -X theirs -- y/ # Leaves 0 conflicts in y/ [... resolve the rest of conflicts manually ...] $ git commit [*] I do mean '-X' above, not '-s'. --

git revert --continue refuses to, help!

Hi! What do I do next, to finish reverting multiple commits? I'd use '--skip' in 'git rebase', but 'revert' doesn't have one? [skeleton (tmp|REVERTING)]$ git revert --continue On branch tmp You are currently reverting commit d8a30d3. nothing to commit, working tree clean [skeleton

Re: [PATCH] reset: --unmerge

Junio C Hamano writes: > The procedure to resolve a merge conflict typically goes like this: > > - first open the file in the editor, and with the help of conflict >markers come up with a resolution. > > - save the file. > > - look at the output from "git diff" to see

Re: [PATCH 5/6] Documentation/git-merge.txt: improve short description in DESCRIPTION

Junio C Hamano <gits...@pobox.com> writes: > Sergey Organov <sorga...@gmail.com> writes: > >>>> Last, if "reference" is not good enough and we get to internals anyway, >>>> why not say SHA1 then? >>> >>> Because that is

Re: [PATCH 6/6] Documentation/git-merge.txt: get rid of irrelevant references to git-pull

Junio C Hamano <gits...@pobox.com> writes: > Sergey Organov <sorga...@gmail.com> writes: > >> Ah, I now see. I tried to keep the text intact as much as possible, and >> only split it into description and a note. Well, how about this then: > > Much better than y

  1   2   >