Re: [PATCH] New option (-H) for rpush/rpull to update HEAD

On Sun, 24 Apr 2005, Andreas Gal wrote:

> Why? Updating HEAD right after writing the commit id and all its children 
> to the object directory seems reasonable and prevents race conditions when 
> the remote repository is shared via HTTP etc.

Come to think of it, the option I was thinking of is orthogonal to your
option; I was thinking of an option to read the head from the sending
side's file, rather than from the command line.

In any case, if you're sharing the repository by HTTP, there's no hurry to
update the HEAD right after, since the old head doesn't stop being valid
(although it's obviously not going to be current in a moment).

> rpull, in contrast, should  never touch HEAD, because conflicts might
> force a merge that will set HEAD to something else. For the pull case we
> should let the script(tm) do that.

For the rpull case, what you want is to just say "HEAD" (or something),
and the remote server will send you the HEAD and you pull down that
commit. You're probably right that you don't want to automatically write
it to the local HEAD, though, although the future format should give us
somewhere good to put the result.

> Its local anyway. rpush is different because the script(tm) has to do
> some SSH magic to update HEAD. I will gladly supply a patch to fix what
> to read/write once you have figured out the final layout, but I really
> need a working rpush _NOW_ ;). 

That was actually my motice in getting rpush/rpull/http-pull in, too.

If you're going to do much serious with this, you should probably remove
the if (has_sha1_file()) continue;" bit in process_commit(), so that it
will make sure that the repository gets pulled completely with -a, even if
some commits have already been pulled. (This will make things less
efficient, but less error-prone, and we'll fix the inefficiency later.)

	-Daniel
*This .sig left intentionally blank*

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html