Martin Ågren writes:
> Hiya,
This one was new to me :-)
>
> On Wed, 28 Aug 2019 at 21:15, Sergey Organov wrote:
>> > I was sort of expecting these to be listed in the order "--ff, --no-ff,
>> > --ff-only", and I see Sergey suggested the same ordering.
Elijah Newren writes:
> On Wed, Aug 28, 2019 at 12:15 PM Sergey Organov wrote:
>>
>> Hi,
>>
> [...]
>> Dunno if it helps, but here is what I came up with somewhere in previous
>> discussions:
>>
>> --ff::
>> --no-ff::
>> --ff-only:
Hi,
Martin Ågren writes:
[...]
>> ++
>> +With --ff-only, resolve the merge as a fast-forward when possible
>> +(when the merged branch contains the current branch in its history).
>> +When not possible, refuse to merge and exit with a non-zero status.
>> ++
>> +With --no-ff, create a merge com
Hi Elijah,
Elijah Newren writes:
> Hi Sergey,
>
> On Wed, Aug 28, 2019 at 1:52 AM Sergey Organov wrote:
>>
>> Elijah Newren writes:
>>
>> > On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
>> >>
>> >> Eric Wong writes:
>>
Elijah Newren writes:
> As discovered on the mailing list, some of the descriptions of the
> ff-related options were unclear. Try to be more precise with what these
> options do.
>
> Signed-off-by: Elijah Newren
> ---
> I noticed this patch sitting around in one of my branches, and noticed it
>
Elijah Newren writes:
> On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
>>
>> Eric Wong writes:
>>
>>
>> [...]
>>
>> > AFAIK, filter-branch is not causing support headaches for any
>> > git developers today. With so many command
Eric Wong writes:
[...]
> AFAIK, filter-branch is not causing support headaches for any
> git developers today. With so many commands in git, it's
> unlikely newbies will ever get around to discover it :)
> So I think think we should be in any rush to remove it.
Nah, discovering it is simple.
Junio C Hamano writes:
> Sergey Organov writes:
>
>> Junio C Hamano writes:
>>
>>> Sergey Organov writes:
>>>
>>> But the point is, if M and N are equally well tested before
>>> publication, they may still have bugs resulting from
Junio C Hamano writes:
> Sergey Organov writes:
>
>>> If we have a project like this:
>>>
>>> A topic that is slightly stale
>>>/
>>> o---F---o---o---X mainline
>>>
>>> M, A', and N sho
Elijah Newren writes:
> On Fri, Jul 12, 2019 at 6:50 AM Sergey Organov wrote:
>>
>> That said, even if we rather all do agree rebase workflow is always
>> inferior to merge one, is it satisfactory excuse to actively resist
>> otherwise logical behavior of 'git m
Junio C Hamano writes:
> Sergey Organov writes:
>
>> Junio C Hamano writes:
>>
>> [...]
>>
>>> The "the tip being merged into the mainline must always be
>>> fast-forwardable",
>>
>> It's rather "the tip being merg
Junio C Hamano writes:
[...]
> The "the tip being merged into the mainline must always be
> fast-forwardable",
It's rather "the tip being merged into the mainline must be fast-forwardable the
first time it is merged".
> however, is not consistent with the topic branch workflow, and I do
> not
Hi Elijah,
Elijah Newren writes:
> Hi Roland,
>
> On Tue, Jul 9, 2019 at 9:17 AM Roland Jäger wrote:
>>
>> Thanks for answering Junio.
>>
>> I get what git does. But I believe that either the documentation ist
>> wrong/ambiguous or --no-ff and --ff-only should be able to be
>> combined and eith
Jeff King writes:
> On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
>
>> How about changing "git show -p M" to output "diff -p M^ M" rather than
>> "diff-tree --cc M" for merge commits? It's really surprising specifying
&g
Junio C Hamano writes:
> Sergey Organov writes:
>
>> I think that "first-parent is special" is the way to go indeed for
>> porcelain, as it does make many thing easier and more convenient[*].
>
> Perhaps. However ...
>
>> [*] One example that imme
Junio C Hamano writes:
> Sergey Organov writes:
>
>>> With it reverted, "[alias] cp = cherry-pick -m1" can be used to train
>>> the user to blindly pick a range that has a merge without thinking,
>>> which is what I meant by "ship has already sai
Junio C Hamano writes:
> Sergey Organov writes:
>
>>> The same effect can be had by just reverting "let's allow -m1 for
>>> single-parent commit", can't it? That is a far simpler solution, I
>>> would say.
>>
>> Those one didn&#x
Junio C Hamano writes:
> Sergey Organov writes:
>
>>> To put it a bit differently, I share with you that picking merges
>>> should be deliberate and it is safer to make sure allowing it only
>>> when the told us that s/he knows the commit being picked is a m
Junio C Hamano writes:
> Sergey Organov writes:
>
>>> To put it a bit differently, I share with you that picking merges
>>> should be deliberate and it is safer to make sure allowing it only
>>> when the told us that s/he knows the commit being picked is a m
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Elijah Newren writes:
>>
>>> This worries me that it'll lead to bad surprises. Perhaps some folks
>>> cherry-pick merges around intentionally, but I would want that to be a
>>> rare occurrence at most.
>>
>> We can just reject this RFC patch
Elijah Newren writes:
> On Wed, Mar 20, 2019 at 8:09 AM Sergey Organov wrote:
>>
>> Junio C Hamano writes:
>>
>> [...]
>>
>> > But I do have a very strong opinion against adding yet another
>> > option that takes an optional argument. If
Junio C Hamano writes:
[...]
> But I do have a very strong opinion against adding yet another
> option that takes an optional argument. If we want to allow
> cherry-picking a merge commit just as easy as cherrry-picking a
> single-parent commit, "git cherry-pick -m merge" (assuming 'merge'
> is
Hi Junio,
[It's been a while since this discussion, and recently I've got some
thoughts and questions about "first-parent" issues in general, below.]
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible
Duy Nguyen writes:
> On Thu, Feb 28, 2019 at 08:54:23AM +0300, Sergey Organov wrote:
>> Hello,
>>
>> How do I configure git to handle tags from remotes in a manner similar
>> to branches?
>>
>> Specifically, I want tag 'tag_name' from remote
Hello,
How do I configure git to handle tags from remotes in a manner similar
to branches?
Specifically, I want tag 'tag_name' from remote 'origin' to have local
name 'origin/tag_name', not 'tag_name', as it is by default. For a repo
with a lot of remotes[*] it would allow to keep track of what t
Signed-off-by: Sergey Organov
---
t/t3502-cherry-pick-merge.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t3502-cherry-pick-merge.sh b/t/t3502-cherry-pick-merge.sh
index b160271..8b635a1 100755
--- a/t/t3502-cherry-pick-merge.sh
+++ b/t/t3502-cherry-pick
Signed-off-by: Sergey Organov
---
t/t3506-cherry-pick-ff.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3506-cherry-pick-ff.sh b/t/t3506-cherry-pick-ff.sh
index fb889ac..127dd00 100755
--- a/t/t3506-cherry-pick-ff.sh
+++ b/t/t3506-cherry-pick-ff.sh
@@ -64,10
ssume first parent to be the mainline in
most workflows.
Sergey Organov (4):
t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
cherry-pick: do not error on non-merge commits when '-m 1' is
specified
t3502: validate '-m 1' argument is now acce
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
this method to force failure will stop to work.
Use '-m 4' instead as it's very unlikely we will ever have such an
octopus in this test setup.
Signed-off-by: Sergey Organov
---
t/t3510-ch
lows '-m 1' for non-merge commits. As mainline is always
the only parent for a non-merge commit, it makes little sense to
disable it.
Signed-off-by: Sergey Organov
---
sequencer.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/sequencer.c b/sequencer.c
SZEDER Gábor writes:
> On Fri, Dec 14, 2018 at 07:53:51AM +0300, Sergey Organov wrote:
>> Signed-off-by: Sergey Organov
[...]
>>
>> @@ -84,12 +84,12 @@ test_expect_success 'cherry pick a merge relative to
>> nonexistent parent should f
>>
>>
Junio C Hamano writes:
> Sergey Organov , Sergey Organov
> writes:
>
>> Hi Junio,
>>
>> What's the status of these patches?
>
> The status of these patches is "Just updated on the list", as far as
> I am concerned, and its cover letter wou
Hi Junio,
What's the status of these patches?
Thanks,
-- Sergey
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 ref
lows '-m 1' for non-merge commits. As mainline is always
the only parent for a non-merge commit, it makes little sense to
disable it.
Signed-off-by: Sergey Organov
---
sequencer.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/sequencer.c b/sequencer.c
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
this method to force failure will stop to work.
Use '-m 4' instead as it's very unlikely we will ever have such an
octopus in this test setup.
Signed-off-by: Sergey Organov
---
t/t3510-ch
llow '-m 1' for non-merge commits as well as fixes
relevant tests in accordance.
It also opens the way to making '-m 1' the default, that would be
inline with the trends to assume first parent to be the mainline in
most workflows.
Sergey Organov (4):
t3510: stop using '-
Signed-off-by: Sergey Organov
---
t/t3502-cherry-pick-merge.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t3502-cherry-pick-merge.sh b/t/t3502-cherry-pick-merge.sh
index b160271..3259bd5 100755
--- a/t/t3502-cherry-pick-merge.sh
+++ b/t/t3502-cherry-pick
Signed-off-by: Sergey Organov
---
t/t3506-cherry-pick-ff.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3506-cherry-pick-ff.sh b/t/t3506-cherry-pick-ff.sh
index fb889ac..127dd00 100755
--- a/t/t3506-cherry-pick-ff.sh
+++ b/t/t3506-cherry-pick-ff.sh
@@ -64,10
Sergey Organov writes:
> Junio C Hamano writes:
>
>> Sergey Organov writes:
>>
[...]
>>
>> The change to the code itself looks sane, but applying this patch
>> alone will break existing tests whose expectations must be updated,
>> and this new beh
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 commi
Junio C Hamano writes:
> Sergey Organov writes:
>
>> So, finally, it's 'branch.linux.pushremote' that is the "offender".
>>
>> Looks like both 'git status' and 'git branch -vv' should somehow learn
>> about '
Hello,
I've got confusing behavior and the cause was somewhat hard to discover:
-- 8< --
$ git status
On branch linux
Your branch is ahead of 'vendor/jps2rin_arm' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
$ git push
Everything up-to-date
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 commi
biswaranjan panda writes:
> I have the following scenario:
>
> On a branch A, I deleted a file foo.txt and committed the change. Then
> I did a bunch of other changes.
> Now I want to undelete foo.txt.
[...]
> I would appreciate if anyone knows how to preserve git blame history.
Provided you d
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 commi
lows '-m 1' for non-merge 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/sequ
This has been sent by mistake, I'm sorry, please disregard.
Sergey Organov writes:
> Johannes Schindelin writes:
>
>> Junio, I think this is now ready for `next`. Thank you for your patience
>> and help with this.
[...]
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 recreate
> the commit topology fait
lows '-m 1' for non-merge 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/sequ
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 remaining issues I fo
Hi Jacob,
Jacob Keller writes:
> On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov wrote:
>> Johannes Schindelin writes:
>>
>>> Hi Phillip,
>>>
>>> On Fri, 13 Apr 2018, Phillip Wood wrote:
>>>
>>>> On 12/04/18 23:02, Johannes Schin
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 intimidating (and the ones in
Hi Jacob,
Jacob Keller writes:
> On Wed, Apr 11, 2018 at 10:42 PM, Sergey Organov wrote:
>> Hi Jacob,
>>
>> Jacob Keller writes:
>>> On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov wrote:
>>>> It was rather --recreate-merges just a few weeks ago, an
Kaartic Sivaraam writes:
> Hi,
>
> On Monday 16 April 2018 08:33 PM, Sergey Organov wrote:
>> Christian Couder writes:
>>> Here "the above article" means the Jake's "branch -l: print useful
>>> info whilst rebasing a non-local branch"
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 article.
>
[...]
> Here "the abov
ng 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 following:
> Sergey replied that he thinks the solution
cription, we
should simply say "ancestor", as everywhere else.
Signed-off-by: Sergey Organov
---
Documentation/glossary-content.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 6bd..6c2
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 DownloadButton one
> +
C
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 the `rebase-cousins` mode is t
Hi Johannes,
Johannes Schindelin 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, both theoretically and by testing.
>
> No, they ar
Hi Jacob,
Jacob Keller writes:
> On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov wrote:
>> It was rather --recreate-merges just a few weeks ago, and I've seen
>> nobody actually commented either in favor or against the
>> --rebase-merges.
>>
>> git reba
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 11 Apr 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> [...]
>>
>> > We disallow '#' as label because that character will be used as
>> > sepa
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 11 Apr 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > On Tue, 10 Apr 2018, Sergey Organov wrote:
>> >
>> >> Johannes Schindelin writes:
>> >>
>>
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 this new syntax. I.e., right
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Tue, 10 Apr 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > Once upon a time, I dreamt of an interactive rebase that would not
>> > flatten branch structure
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".
Both option names seem to miss t
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 rebases, which you apparently
>
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 28 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > I use rebase every day. I use the Git garden shears every week. If you
>> > do not trust my experienc
Hi Johannes,
Johannes Schindelin 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 feature?
>
> No.
>
> The exp
Hi Johannes,
Johannes Schindelin writes:
> Hi,
>
> On Thu, 29 Mar 2018, Sergey Organov wrote:
>
>> Jacob Keller writes:
>>
>> > I care about the general compatibility of the rebase todo list
>> > regardless of which options you enabled on the comma
Jacob Keller writes:
> On Wed, Mar 28, 2018 at 4:29 AM, Sergey Organov wrote:
>
>> Jacob Keller writes:
>>
>> > On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov
>> wrote:
>> >>
>> >> Hi Johannes,
&
Jacob Keller writes:
> On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov wrote:
>>
>> Hi Johannes,
>>
>> Johannes Schindelin writes:
[...]
> I'm pretty sure the fact has already been accepted, as he did indeed
> implement and develop a strategy for reb
Jacob Keller writes:
> On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov wrote:
>>
>> Hi Johannes,
>>
>> Johannes Schindelin writes:
>> > Hi Sergey,
>> >
>>
>> [...]
>>
>> >> >> Reusing existing concepts where po
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 *not* fit the requirement
>> >
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 existing* changes)
> seems to fl
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Tue, 27 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > On Mon, 12 Mar 2018, Sergey Organov wrote:
>> >
>> >> Johannes Schindelin writes:
&g
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 complicated, but just something we didn
Hi Johannes,
Johannes Schindelin 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 is a purely academic specu
Dear Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Mon, 12 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > [...]
>> >
>> > Where "easy" meant that I had to spend 1h still to figure
Johannes Schindelin writes:
> Hi Sergey,
>
> On Mon, 12 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>> >
>> > On Wed, 7 Mar 2018, Sergey Organov wrote:
>> >
>> >> Johannes Schindelin writes:
>> >>
&g
Hi Johannes,
Johannes Schindelin 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
>> > > > (not to
Igor Djordjevic 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 keep that behavior with -R,
Hi Buga,
Igor Djordjevic 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, exactly as written, with
>> >
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 somewhat lost in the discussion,
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 with non-merge
>> commits. I'm u
Hi Buga,
Igor Djordjevic 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 the second merge compared to RF
Hi Buga,
Igor Djordjevic 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
>> stop flattening history, and
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 in the discussion, but are yo
Hi Buga,
Igor Djordjevic 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 in this thread in
>> &
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 changes in the parents due to
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 implementation detail). In that conte
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-merges
> them later, and why it sh
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
> specific one), where Phillip came up
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 mentioned explicit old:new m
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 that we cannot use it unchange
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 7 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > How can your approach -- which relies *very much* on having the
>> > original parent commits -- not *requi
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 interactive vs. non-interactive spl
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 7 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > On Tue, 6 Mar 2018, Sergey Organov wrote:
>> >
>> >> This is v2 of my "Rebasing merges&
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 7 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > On Tue, 6 Mar 2018, Phillip Wood wrote:
>> >
>> >> On 03/03/18 00:29, Igor Djordjevic wrote:
&g
Hi Johannes,
Johannes Schindelin 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-way merges between
> the origina
1 - 100 of 198 matches
Mail list logo
