Re: [RFC/PATCH Second draft] Fast forward strategies allow, never, and only

From: Sverre Hvammen Johansen <hvammen@gmail.com>
Date: Mar 20, 2008, 06:47 UTC
Message-ID: <402c10cd0803192347q7b4a3fb0s35737f361d53a86a@mail.gmail.com>
In-Reply-To: <7vskym310l.fsf@gitster.siamese.dyndns.org>

On Wed, Mar 19, 2008 at 12:35 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

> > ...
>  This might be easier to review if split into two parts.  Code suffling to
>  do --ff/--no-ff => ff={allow,never} and documentation updates to improve
>  the description of these two options in the first patch, and addition of
>  "only" to code and the updated docuemntation in the second.

What I would like to do is to split it in three like this:

1. Head reduction

2. --ff/--no-ff => ff={allow,never} and documentation updates.

3. --ff=only

If you would like me to do this please tell me.

Show 5 quoted lines

> ...
>  might even be a worthy addition to the current documentation.  However it
>  lacks a crucial bit of information: it is _not enough_ to just use --no-ff
>  to maintain the "special status" of "master".  You also need to prevent
>  direct committing to it.

True, but the special case where you have a topic that only consists of one commit you might as well apply it directly on master. In any case, when you commit something directly on the special branch master you usually know what you are doing. It is perfectly OK to combine the two. I am not sure we need to explain this.

Show 5 quoted lines

>  > +You may therefor need to use this policy on the topic branches as
>  > +well.
>
>  combined with the above, would make "only" an incomplete implementation of
>  the goal you stated earlier, i.e. "to force a completely linear history",

Actually that is not my goal for this implementation, I just tried to describe a useful use case, but failed. Let me try again.

I actually need this for the integration between accurev and git I am using/maintaining/developing (at some point I intend to release it). At work I am forced to use accurev, but the user interface for accurev is horrible and it is slow. I therefor have complete history of accurev streams in git and are doing all my work in git with branches and everything. The git-accurev integrator creates one merge commit object in git for each time i check something into accurev, . This merge commit object ties the content in accurev that was committed into accurev with the corresponding content in git. It is important that further work I do is based on this special merge commit object. It works if I don't, but the history gets really messy, and for this I need the --ff=only so I don't forget to pull or rebase before the next commit I make into accurev.

>  but I think you can trivially fix this by making sure that there is no
>  merge commit in ORIG_HEAD..MERGE_HEAD and refusing if you find one.  And
>  by fixing the implementation, you do not have to make excuses like the
>  above two and half paragraphs.

I don't intend to do that, simply because I don't need it and it would actually not work for my workflow.

>  So if that is what you are trying to achieve, you need to update your
>  description.  If you aim for "Totally linear", I think many people will
>  find it is practically useless, but if you are aiming for something
>  different, you should advertise it as such.

You are right, I will try to come up with something better.

Show 8 quoted lines

>  > @@ -153,8 +153,6 @@ parse_config () {
>  >                 --summary)
>  >                         show_diffstat=t ;;
>  >                 --squash)
>  > -                       test "$allow_fast_forward" = t ||
>  > -                               die "You cannot combine --squash with --no-ff."
>
>  I do not think you defended why it is good idea to drop this sanity check.

I don't see any good idea for having this check. Nothing bad happens by allowing to combine these options the way I currently implement it.

-- 
Sverre Hvammen Johansen