'git pull' inconsistent messages.

Hello, $ git pull --rebase=false Already up-to-date. $ git pull --rebase=true Current branch v3.5 is up to date. $ git pull --rebase=preserve Successfully rebased and updated refs/heads/v3.5. The last one being particularly misleading as nothing was actually changed. git version 1.9.3 --

[PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Previous description of -f option was wrong as git rebase does not require -f to perform rebase when current branch is a descendant of the commit you are rebasing onto, provided commit(s) to be rebased contain merge(s). Signed-off-by: Sergey Organov sorga...@gmail.com --- Documentation/git

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: So I think the reasoning (i.e. is a descendant is not quite right) is correct, but the updated text is not quite right. Changing it further to only the committer timestamps and identities would change is

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

is not helping the reader in this description very much. I wonder if we should keep it if we are rewriting this paragraph. How about doing it this way, perhaps? -- 8 -- From: Sergey Organov sorga...@gmail.com Date: Tue, 12 Aug 2014 00:22:48 +0400 Subject: [PATCH] Documentation/git-rebase.txt: -f

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: ... diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 2a93c64..f14100a 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -316,11 +316,8 @@ which

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: A sentence --force has no effect under --preserve-merges mode does not tell the readers very much, either and leaves them wondering if it means --preserve-merges mode always rebases every time it is asked

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: ... I.e., git must not rebase anything when Current branch is a descendant of the commit you are rebasing onto, unless -f is given. Simple, reasonable, straightforward. It may be simple and straightforward

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: A sentence --force has no effect under --preserve-merges mode does not tell the readers very much, either and leaves them wondering if it means --preserve-merges mode always rebases every time it is asked

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: [...] How about doing it this way, perhaps? Could you please apply this your suggestion, as we seem not to agree on anything better? -- 8 -- From: Sergey Organov sorga...@gmail.com Date: Tue, 12 Aug 2014 00:22

git rebase: yet another newbie quest.

Hello, Caveat: this is somewhat long, sorry. Recently I've run into yet another rather tricky trouble with pull/rebase. No, neither of my troubles is in the usual rewriting published history group. (The first trouble I ran earlier was caused by the fact that git pull breaks local merges when

Re: git rebase: yet another newbie quest.

John Keeping j...@keeping.me.uk writes: On Fri, Sep 05, 2014 at 02:28:46PM +0400, Sergey Organov wrote: ... # Then I realize I need more changes and it gets complex enough to # warrant a topic branch. I create the 'topic' branch that will track # 'master' branch and reset 'master' back

Re: git rebase: yet another newbie quest.

Theodore Ts'o ty...@mit.edu writes: I'm not going to say what you *should* have done, since it's not clear whether anything close to what you were doing is a supported workflow. But I can tell you what I *do* myself. Personally, I vastly distrust git pull --rebase. Thank you for sharing your

Re: git rebase: yet another newbie quest.

Theodore Ts'o ty...@mit.edu writes: On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote: I didn't intend to make topic branch from the very beginning, and already made a commit or two on the remote tracking branch bofore I realized I'd better use topic branch. It'd create

Re: git rebase: yet another newbie quest.

Theodore Ts'o ty...@mit.edu writes: On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote: except that I wanted to configure upstream as well for the topic-branch, that looks like pretty legit desire. If I didn't, I'd need to specify upstream explicitly in the git rebase, and I'd

[PATCH] Documentation/git-rebase.txt: make it explicit in the syntax there is no way to specify branch without upstream.

Current syntax description makes one wonder if there is any syntactic way to distinguish between branch and upstream so that one can specify branch but not upstream. The change makes it explicit that these arguments are in fact positional. Signed-off-by: Sergey Organov sorga...@gmail.com

[PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.

. That in turn made actual behavior of vanilla git rebase hardly discoverable. While we are at it, clarify the --fork-point description itself as well. Signed-off-by: Sergey Organov sorga...@gmail.com --- Documentation/git-rebase.txt | 18 +- 1 file changed, 9 insertions(+), 9 deletions

Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: Vanilla git rebase defaults to --fork-point that in some cases makes behavior very different from git rebase upstream, where --no-fork-point is assumed. This fact was not mentioned in the DESCRIPTION section

Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: I think you meant to say that we may find a better source to calculate the exact set of commits to rebase,... Yes. It is debatable if we should do the same when the user tells us to rebase with respect

[PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.

. That in turn made actual behavior of vanilla git rebase hardly discoverable. While we are at it, clarify the --fork-point description itself as well. Signed-off-by: Sergey Organov sorga...@gmail.com --- As asked by Junio C Hamano gits...@pobox.com, the newly introduced 'fork_point' term has been

Re: [PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: [...] As asked by Junio C Hamano gits...@pobox.com, the newly introduced 'fork_point' term has been described. I suspect will be used as a fallback might be easier to understand what is going on instead

[PATCH] git-merge: mutually match SYNOPSIS and usage.

SYNOPSIS section of the git-merge manual page had outdated explicit list of options. usage returned by 'git merge -h' didn't have -m msg that is one of essential distinctions between obsolete invocation form and the recent one. Signed-off-by: Sergey Organov sorga...@gmail.com --- Documentation

[RFC/PATCH] git-merge: implement --ff-only-merge option.

that the command without --no-ff would indeed result in fast-forward. Useful to incorporate topic branch as single merge commit, ensuring the left-side of the merge has no changes (our-diff-empty-merge). Signed-off-by: Sergey Organov sorga...@gmail.com --- builtin/merge.c | 39

Re: [RFC/PATCH] git-merge: implement --ff-only-merge option.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: This option allows to create merge commit when fast-forward is possible, and abort otherwise. I.e. it's equivalent to --ff-only, except that it finally creates merge commit instead of fast-forwarding. One

Re: [PATCH] git-merge: mutually match SYNOPSIS and usage.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: SYNOPSIS section of the git-merge manual page had outdated explicit list of options. usage returned by 'git merge -h' didn't have -m msg that is one of essential distinctions between obsolete invocation form

Re: [RFC/PATCH] git-merge: implement --ff-only-merge option.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: Why would it be useful to limit the history to a shape where all merges are the ones that could have been fast-forwarded? Except by true merge, how else can I express with git that 'n' consequitive commits

Re: [RFC/PATCH] git-merge: implement --ff-only-merge option.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: Because rebasing immediately before is considered a bad manner, i.e. encouraging a wrong workflow? Why? What is wrong about it? Searching the kernel archive for messages that talks about rebase and pull

Re: [PATCH] git-merge: mutually match SYNOPSIS and usage.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: Junio C Hamano gits...@pobox.com writes: ... I was looking at the merge.c code, and that's how it seems to work. You can get new semantics without -m, and you can't get old semantics with -m, isn't

Re: Vendor-Branch setup

Adrian Stern adrian.st...@unchained.ch writes: Hi I have a Vendro-Branch setup where i store the official code in my own repository. Next to that i have a Delta-Branch where i store only the changed files different to the Vendor-Branch. This Delta-Branch is the cause of your problems, I

[PATCH] Documentation/config.txt: change pull.rebase description in favor of safer 'preserve' option.

is doing. Signed-off-by: Sergey Organov sorga...@gmail.com --- Documentation/config.txt | 26 -- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c55c22a..30f28d9 100644 --- a/Documentation/config.txt

Re: [PATCH] Documentation/config.txt: change pull.rebase description in favor of safer 'preserve' option.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: Previous description implicitly favored 'true' value for pull.rebase and pull.branch.rebase options, I do not share that impression. It is true that 'true' is described first before 'preserve', which can

Re: rebase flattens history when it shouldn't?

Jonathan Nieder jrnie...@gmail.com writes: Hi Sergei, Sergei Organov wrote: --C-- / \ / M topic,HEAD / / A---B master shouldn't $ git rebase master be a no-op here? [...] I'd expect --force-rebase to be required for this to happen: -f, --force-rebase

[BUG] Documentation: git log: --exit-code undocumented?

Hello, $ git help log | grep exit-code problems are found. Not compatible with --exit-code. $ What --exit-code does in git log? -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [BUG] Documentation: git log: --exit-code undocumented?

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: Hello, $ git help log | grep exit-code problems are found. Not compatible with --exit-code. $ What --exit-code does in git log? It doesn't. That is why it is not listed. Then, how can

Re: [BUG] Documentation: git log: --exit-code undocumented?

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: Hello, $ git help log | grep exit-code problems are found. Not compatible with --exit-code. $ What --exit

Re: [BUG] Documentation: git log: --exit-code undocumented?

Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: I disagree that --exit-code does nothing: it indicates whether the listed log is empty. So for example git log -1 --exit-code a..b /dev/null can be used to figure out whether a is a proper ancestor of b or not.

'git rebase' silently drops changes?

Hello, I recently ran into an annoying problem: 'git rebase' apparently silently drops changes in non-conflicting paths of merge commits (git version 1.9.3). Is it a bug or feature? Is there a way to flatten history using rebase, yet preserve manual changes found in merge commits? Here is

Re: 'git rebase' silently drops changes?

Johannes Sixt j...@kdbg.org writes: Am 09.02.2015 um 13:53 schrieb Sergey Organov: [...] If you want a version of --preserve-merges that does what *you* need, consider this commit: git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent Use it like this: git rebase -i -p --first

Re: 'git rebase' silently drops changes?

Johannes Sixt j...@kdbg.org writes: Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth: On 06.02.2015 22:28, Sergey Organov wrote: # Now rebase my work. git rebase -f HEAD~1 # What? Where is my Precious change in a??? cat a /SCRIPT I.e., the modification marked [!] was silently lost

Re: [PATCH] docs: Clarify what git-rebase's --preserve-merges does

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:

Re: [PATCH] docs: Clarify what git-rebase's --preserve-merges does

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

Re: [PATCH] docs: Clarify what git-rebase's --preserve-merges does

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

Re: [PATCH] docs: Clarify what git-rebase's --preserve-merges does

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

Re: [PATCH] docs: Clarify what git-rebase's --preserve-merges does

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

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: > >> So I believe this change is inline with the rest of the patch. The >> reference to git-pull (if it remains) should be a side-note, not part of >> explanation of o

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

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: > >> OK, I see. So, what is the best way to handle this? Immediately follow >> content change patch with another patch that only re-flows? > > Or no reflowing at all

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

Jakub Narębski <jna...@gmail.com> writes: > W dniu 05.10.2016 o 16:46, sorga...@gmail.com pisze: >> From: Sergey Organov <sorga...@gmail.com> >> >> Old description had a few problems: >> >> - sounded as if commits have changes >> >> - s

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 1/6] git-merge: clarify "usage" by adding "-m "

Junio C Hamano <gits...@pobox.com> writes: > sorga...@gmail.com writes: > >> From: Sergey Organov <sorga...@gmail.com> >> >> "-m " is one of essential distinctions between obsolete >> invocation form and the recent one. Add it to the &q

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

Jeff King writes: > On Wed, Oct 05, 2016 at 05:46:22PM +0300, sorga...@gmail.com wrote: > >> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt >> index 216d2f4..cc0329d 100644 >> --- a/Documentation/git-merge.txt >> +++ b/Documentation/git-merge.txt >> @@ -3,7

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

Junio C Hamano <gits...@pobox.com> writes: > sorga...@gmail.com writes: > >> From: Sergey Organov <sorga...@gmail.com> >> >> Old description not only raised the question of why the tool is called >> git-merge rather than git-join, but "join histo

Re: [PATCH 2/6] Documentation/git-merge.txt: remove list of options from SYNOPSIS

Junio C Hamano <gits...@pobox.com> writes: > sorga...@gmail.com writes: > >> From: Sergey Organov <sorga...@gmail.com> >> >> This partial list of option is confusing as it lacks a lot of >> available options. It also clutters the SYNOPSIS making diffe

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

Junio C Hamano <gits...@pobox.com> writes: > sorga...@gmail.com writes: > >> From: Sergey Organov <sorga...@gmail.com> >> >> Old description had a few problems: >> >> - sounded as if commits have changes >> >> - stated that changes are t

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

Jakub Narębski <jna...@gmail.com> writes: > W dniu 05.10.2016 o 16:46, sorga...@gmail.com pisze: >> From: Sergey Organov <sorga...@gmail.com> >> >> Old description had a few problems: >> >> - sounded as if commits have changes >> >> - s

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

Junio C Hamano writes: > sorga...@gmail.com writes: [...] >> @@ -138,14 +133,15 @@ will exit early with the message "Already up-to-date." >> FAST-FORWARD MERGE >> -- >> >> -Often the current branch head is an ancestor of the named commit. >> +Often the

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

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: 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

[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: [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

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. [...]

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'. --

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: [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: 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

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: [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

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

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 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 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

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

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: 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: [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

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

[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: [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

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: 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 >>

[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] 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

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

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: > 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 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 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(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: [...] > 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] 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 <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)

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(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] 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 (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 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(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 (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

  1   2   >