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

["Sverre Hvammen Johansen" <hvammen@gmail.com>]

On Wed, Mar 19, 2008 at 12:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > ...
>  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.

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

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

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