On Wed, Dec 05, 2007 at 10:30:45PM -0800, Junio C Hamano wrote:
> 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.
Ah, I thought his argument was "we have to send back a bit, so why not
just send the hash we made for informational purposes? It doesn't hurt,
and maybe we can make use of it later."
I was assuming that we were interested _only_ in fixing the send-pack
issues at this time, and that the rebasing or merging part of the
workflow would be figured out later. But it is probably sensible to
consider the whole workflow to see what is necessary at each step.
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
