Re: [PATCH v4] Allow update hooks to update refs on their own.

Jeff King <peff@peff.net> writes:

What I meant in response to what I thought Steven was talking about was this.

 * With Steven's patch, the sending side needs to expect what it pushes
   to be rewritten.  If it starts with this history:

    ---o---o---o---Y---o---o---X

   where Y is what its remote tracking branch points at for the
   corresponding branch, three commits were built locally since the last
   fetch, and the sender pushes X.

 * Then the receiving end rewrites the history, making the history into
   this:

		     o'--o'--X'
                    /
    ---o---o---o---Y---o---o---X

 * Before the next fetch, the sending side can continue building on top
   of X, leading to this:

		     o'--o'--X'
                    /
    ---o---o---o---Y---o---o---X---o---Z

 * Similarly other people push into the same remote, get their commits
   rewritten and remote side's history becomes like this (but the
   original sender does not know about the upper history at all yet).

		     o'--o'--X'--o'--o'--W'
                    /
    ---o---o---o---Y---o---o---X---o---Z

 * Then the original sender fetches from the remote, now the tracking
   branch points at W' (it previously pointed at Y).  You would want to
   rebase your work since the last push on top of that tracking branch.

The rebase would be "rebase --onto W' X Z", so it is not strictly necessary to keep the fact that X corresponds to X', but somehow I thought it was necessary, and Steven's message was hinting about that:

  > If we want that status in principle, I'd argue that sending down the
  > updated commit SHA1 is actually the right way to indicate it, because
  > it gives the client all the information it needs to make an
  > intelligent choice about what to do next. If you don't transmit the
  > modified SHA1, the client will have to do another fetch to find out
  > what rewriting was done by the server, and if another push happened in
  > the meantime, the client will have to basically guess about which
  > commits correspond to the ones it pushed.

(notice the last part).

So if we want to transmit minimum amount of information, we can just send a bit ("the ref was rewritten") back to send-pack without telling it what X' is (but it would not hurt to send it back either). With that one bit of information, send-pack can refrain from updating tracking ref from Y to X.

In the above scenario I illustrated, it turns out that getting correspondence between X and X' is not strictly necessary to perform a rebase later, but maybe there is some other scenario that keeping track of that information would be helpful. In such a case, a hook on the send-pack end (which currently we do not have) can be called with X and X' as parameters (and perhaps the name of the ref and the corresponding tracking ref) to do whatever it wants to do with that information.

Even if we do not send X' back but just one bit, having that hook would probably be needed so that sender can record "I've pushed up to X" and perhaps "now I cannot push out Z until I rebase" after receiving "push was accepted but rewritten" bit.

This is all handwaving --- I suspect for this to really work, send-pack might need a pre-send-pack hook that pays attention to such "now I cannot push out Z until I rebase" information the previous round of push may have left and declines to push. Of course, the receiving end would would probably refuse such a push because it is not a fast-forward.