Re: [PATCH v2] Add -ftabstop=WIDTH

Re: [PATCH v2] Add -ftabstop=WIDTH

[Junio C Hamano]

"Christopher Li" <sparse@chrisli.org> writes:

> So here is my understanding of what you described. The 'pu' branch is
> for highly experiment changes. The 'pu' branch can rewind and rewrite
> the history. Once the patch merge to 'next', the history will not change
> any more.  All update will stay as incremental changes.
>
> One question, does user suffer from conflict when then pull from the 'pu'
> branch?

[jc: I think this is going to the tangent for "sparse" list;
 redirecting to git@vger.kernel.org] 

I think they will, if they "pull", but:

 (1) They are upfront strongly discouraged from doing so by the way 'pu'
     is advertised.  "It is a collection of not yet even testable series,
     and any patch in it can be dropped and replaced".

 (2) They can instead 'fetch + rebase' the changes they made on top of
     previous round of 'pu', instead of 'pull' (= 'fetch + merge') to
     mitigate the pain.

Suppose I have two un-ready topics A and B in pu, and you base your work
X, Y, and Z on what was done by A (in other words, you are not interested
in topic B at all).  Then suppose one of A or B is replaced by wildly
different versions, and 'pu' is rebuilt:

                    X---Y---Z (private changes)
                   /
             A----B pu (old)
            /
           /              A'---B' pu (new)
          /              /  
     ----o----o----o----o

        Fig. 1

If you pull, even if A was not the one that was replaced, the merge will
have severe conflicts from the changes involved in the other series
(i.e. B).

But if A and A' did not change drastically in the meantime, rebasing X, Y,
Z on top of the updated pu (i.e. B') would not conflict:


                    X---Y---Z (private changes)
                   /
             A----B pu (old)     X'--Y'--Z' (private changes rebased)
            /                   / 
           /              A'---B' pu (new)
          /              /  
     ----o----o----o----o

        Fig. 2

In either case, if A (i.e. the work X, Y, Z were made on top of) was
rewritten drastically to become A', neither rebase nor merge will be of
help anyway, and it would not help if the new A' were recorded as an
incremental change from A without rebasing/rewinding 'pu' itself, either.

But at least 'fetch + rebase' would avoid the issue when it is only the
other topics in 'pu' that you are not interested in that were replaced or
rewritten drastically.

By the way, I drew A and B as if they are single patches made _directly_
on pu, only for simplicity's sake.  In reality, all topics fork from more
stable branches (maint or master), and the only commits you see on 'next'
or 'pu' are merges.

Which means, even if we assume that you never rewind 'pu':

> Here is an idea, I am just thinking it out loud.
>
> Given 'pu' branch like this, (each [ ] is a commit, A1 is a follow up
> change for A0).
>
> 'pu' branch: [A0] - [B0] - [A1] - [C0] -[B1] -[A2]

... the history of 'pu' won't look like this.

It would be more like this:

           .-----[B0]----[B1]  ...  topic branch for B
          /         \       \
         /  ...--*---*---*---* ...  pu
        /       /       /
       /       [A0]---[A1]     ...  topic branch for A
      /       /
     o-------o----o master

        Fig. 3

    Side note: my 'next' never rewinds except for once every major
    release, so the above "repeated merge from topics into the branch"
    depicts how 'next' works pretty closely.

Or, if you rebuild 'pu' every day, it would be more like
this one day, and;

           .-----[B0]          ...  topic branch for B
          /         \        
         /  ...--*---*         ...  pu
        /       /        
       /       [A0]            ...  topic branch for A
      /       /
     o-------o----o master

        Fig. 4

the next day it would look like this:

           .-----[B0]----[B1]  ...  topic branch for B
          /                 \
         /          ...--*---* ...  pu
        /               /
       /       [A0]---[A1]     ...  topic branch for A
      /       /
     o-------o----o master

        Fig. 5

In either case, unless a topic began with too many early issues and
mistakes that requires a wholesale replacement, you can expect the
accumulation of A0,A1,...,An to end up in a good shape eventually and then
you have a good incremental history you would want to preserve.

At that point, you can merge the tip of the branch (i.e. An) to master and
declare victory.  'pu' or 'next' may have a messy history that would make
anybody who looks at gitk output barf, but that is Ok.

> We can have a temporary clean up branch fork from 'pu' looks like this:
>
> 'tmp_clean' branch: [A0 + A1 + A2] - [B0 + B1] - [C0]
>
>  'tmp_clean' and 'pu' will generate exactly the same tree. The
> only different is the history path it take to get there.
>
> Then we can have 'pu' merge from 'tmp_clean', with zero text
> changes. The only change is the change log and we tell git
> that the merge is for history clean up. So when we launch
> "git log", by default it will follow the "tmp_clean" path rather
> than the original "pu" path.
>
> So it just provide "alternative" view of the history without introduce
> real changes. When user pull from 'pu', it can automatically get the
> cleanup version of the history without introduce conflicts.
>
> It seems it can have the best of both worlds. I am not sure weather
> it is doable or worth while to do though.

I do not think it is worth it, for two reasons:

 (1) That won't help the case where others based on their work on un-ready
     changes in 'pu', as I described earlier, anyway.

 (2) If you do not have any work on top of the un-ready 'pu', in other
     words, if you are just following along, then "git checkout origin/pu"
     won't care if yesterday's pu and today's pu are not fast-forward
     anyway.

If you rebuild 'pu' from scratch every day, without keeping many repeated
merges so far, it will give a pleasant read in "gitk master..pu" than
'next' that never rewinds whose "gitk master..next" output is a disaster
;-).


There is one trick my experienced users use, knowing how 'pu' is managed.

If today's 'pu' looked like Fig. 4 above, and you are interested in the
topic A, you can find the tip of that topic by looking at:

        git log --first-parent master..pu

It is what was merged to the merge that is at the second from the tip of
'pu' branch, i.e. "pu^^2 == A0".

And you fork your own enhancement to that topic by forking from A0,
creating "my-A" branch.  Your own commits go to that branch.

Next day you will find a history that is depicted in Fig. 5 and find the
tip of topic A the same way.  It is at A1.

Then you rebase "my-A" on top of A1 (or merge A1 to "my-A" branch).  You
really do not care about other uncooked garbage in 'pu', and you can
ignore them this way.

If you are working on more than one such "topics started by others", you
will have many my-A, my-B, ... branches.  You treat your 'master' branch
as if it is my 'next', i.e. fork from the last major release, merging all
of my-X branches, and employ the aggregated result for your own use.