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 subtle
>>> interactions between A and F..X that is not discover
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 subtle
>> interactions between A and F..X that is not discovered during that
>> testing. And N l
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 should end up with identical trees:
>>>
>>>
>>> A---M topic
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 merge' that is even documented? I
>
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 should end up with identical trees:
>>
>>
>> A---M topic that is slightly stale, merged into ma
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 merge' that is even documented? I
> don't think so.
>
> Thus, one
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 merged into the mainline must be fast-forwardable
>> the
>> first time it is merged"
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 merged into the mainline must be fast-forwardable
> the
> first time it is merged".
>
>> however, is not consistent with
On 2019-07-09 at 20:51:39, Bryan Turner wrote:
> I think this is something I've seen come up on the list before[1]
> (Roland can correct me if I'm wrong). What I've seen asked for before
> is the ability to pass the combination "--ff-only --no-ff" and have
> that:
> * Ensure the branch to be merged
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
Bryan Turner writes:
> I think this is something I've seen come up on the list before[1]
> (Roland can correct me if I'm wrong). What I've seen asked for before
> is the ability to pass the combination "--ff-only --no-ff" and have
> that:
> * Ensure the branch to be merged is fast-forward from th
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
> On 09 July 2019 at 22:51 Bryan Turner wrote:
>
> On Tue, Jul 9, 2019 at 1:33 PM Elijah Newren wrote:
> >
> > On Tue, Jul 9, 2019 at 10:00 AM wrote:
> > >
> > > Additionally I would also want to change the wording for --ff-only, as it
> > > currently reads as if it only performs a check (whic
On Tue, Jul 9, 2019 at 1:33 PM Elijah Newren wrote:
>
> On Tue, Jul 9, 2019 at 10:00 AM wrote:
> >
> > Additionally I would also want to change the wording for --ff-only, as it
> > currently reads as if it only performs a check (which would lead to the
> > expected behaviour) but does more than
On Tue, Jul 9, 2019 at 10:00 AM wrote:
>
> > On 09 July 2019 at 18:35 Elijah Newren wrote:
> >
...
> > Hope that helps,
> > Elijah
>
> I hope this is not-top-posting? I'm new to this and know nothing apparently.
Yep, you're doing good.
> If I were to write a patch then I would very much prefer
> On 09 July 2019 at 18:35 Elijah Newren wrote:
>
>
> 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
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
> either should be fixed - preferably the later. Wh
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
either should be fixed - preferably the later. What I want to say to git is "I
never accept a real merge; please make a me
usbu...@mailbox.org writes:
> I'm rather confused about --ff, --no-ff and --ff-only. They seam
> to be all mutual exclusive...
A clean result left by "git merge" can be either a fast-forward, or
a real merge (i.e. 2 possible outcomes).
The --ff option lets you say "If the other history I am atte
Hello,
I'm rather confused about --ff, --no-ff and --ff-only. They seam to be all
mutual exclusive while the man page documentation and help reads as if only the
first two are mutual exclusive, while the later is a check that can be enabled
additionally to the former ones. I'm not sure why I co
20 matches
Mail list logo
