From: Junio C Hamano <gitster@pobox.com>
To: "Sverre Hvammen Johansen" <hvammen@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Merging using only fast-forward
Date: Wed, 16 Jan 2008 14:49:52 -0800 [thread overview]
Message-ID: <7v3asxo06n.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <402c10cd0801161438u7443ebf2xdf1d6f3040ceb1a9@mail.gmail.com> (Sverre Hvammen Johansen's message of "Wed, 16 Jan 2008 14:38:20 -0800")
"Sverre Hvammen Johansen" <hvammen@gmail.com> writes:
> On Jan 16, 2008 12:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> A sane integration is a different story.
>>
>> We have --ff and --no-ff options to merge. How should this new
>> option --ff-only mesh with them? Perhaps we would want to have
>> an option --ff that takes three values?
>>
>> --ff=never
>> --ff=normal
>> --ff=only
>>
>> and have the first one be synonym for existing --no-ff, the second
>> one to be a synonym for not giving anything (or giving --ff
>> explicitly), and the third one to be this new mode of operation?
>
> Thanks for the patch. I can probably look into it tonight and do the
> suggested integration and test it out, I keep you posted.
Well, no, I did not _suggest_ that particular integration. I do
not even know what the right answer is to these questions. The
UI that pastebin patch implements, which uses totally separate
flags, may turn out to be the right approach. If you want to
carry the torch forward on this topic, that's great. It is very
much appreciated. But one of the things included in that work
includes thinking and deciding which UI is better between the
patch in the pastebin and the one that tries to introduce a
unified --ff=<value> option. I simply do not know the answer,
and prefer not having to think about it during a pre-release
feature freeze.
Coming up with a 7-liner quick-and-dirty solution is one thing.
It was easy (although I haven't tested it, so it may not work at
all!). But if we want to mainline it, we need to think
carefully how the new feature integrates well with what we
already have. That's all I wanted to say.
next prev parent reply other threads:[~2008-01-16 22:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-16 15:54 Merging using only fast-forward Sverre Hvammen Johansen
2008-01-16 16:27 ` Randal L. Schwartz
2008-01-16 20:31 ` Junio C Hamano
2008-01-16 22:38 ` Sverre Hvammen Johansen
2008-01-16 22:49 ` Junio C Hamano [this message]
2008-01-17 6:53 ` Sverre Hvammen Johansen
2008-01-18 6:58 ` Sverre Hvammen Johansen
2008-01-18 21:25 ` Junio C Hamano
2008-01-19 10:28 ` Sverre Hvammen Johansen
2008-01-19 10:38 ` Sverre Hvammen Johansen
2008-01-19 10:43 ` Junio C Hamano
[not found] ` <402c10cd0801190427o62493073s408959aa5701ca86@mail.gmail.com>
2008-01-19 12:30 ` Sverre Hvammen Johansen
2008-01-19 12:58 ` Please don't reply to this thread Sverre Hvammen Johansen
2008-01-19 12:39 ` Merging using only fast-forward Sverre Hvammen Johansen
2008-01-21 6:26 ` Sverre Hvammen Johansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v3asxo06n.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=hvammen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).