Re: [PATCH] Added --mirror-all to git-fetch.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Shawn Pearce <spearce@xxxxxxxxxxx> writes:

> I started this change with '--all' and realized that ideally you
> want '--all' to copy all available refs/heads/* from the remote to
> refs/remotes/<name>/* here.  You want to create any new branches
> which the remote has introduced since your last fetch.
>
> You probably don't want to force a non-fast forward unless there's a
> '+' in the corresponding Pull line of remotes/<name> or if --force is
> used.  However you probably also want to delete any removed branches.

I think we are in agreement here.

> Which I think is quite different from a mirror.  A mirror wants to
> replace the entire ref namespace with what's on the remote as it
> has no need for a local namespace of its own.

If you have remotes/origin that does not use the refs/remotes
hierarchy, does not copy master->origin (iow, the assumption
that "origin" branch is to be merged into local "master") but
copies remote master to local master, and forces all refs by
default, then your local ref namespace is effectively a mirror
of the remote, so it is very tempting to think --mirror is a
logical extension of "fetch --all".

Except that new refs are not created and old refs are not
deleted.  And these two are rather big exceptions.

If we are to have another command (git-mirror which is a thin
wrapper around git-fetch as you propose later), these two
exceptions would be cleanly handled there.  Otherwise, we would
need to give the command a hint (git-mirror.permitted) to allow
them to be done in addition to the usual "fetch --all", but then
we would end up doing the equivalent of your one-liner anyway,
so there is not much point having it in git-fetch.  So I am in
favor of your thin-wrapper idea.

> Originally I gave Pasky a one-liner on #git:
>
>   git fetch --force origin $(git ls-remote origin \
>       | awk '{if(!/\^{}$/){print $2":"$2}}')

Which sounds a very sane thing to do, especially given git is
designed to be scripted this way.

> And I think this mirror thing may make more sense as a small wrapper
> around git-fetch.  A wrapper that checks for:
>
> 	- its running in a bare repository;

Ok.

> 	- it has a single remote named origin;

Do you mean ".git/remotes must have only one file 'origin' and
nothing else", or do you mean "There must be .git/remotes/foobla
for 'git-mirror foobla' to work"?

> 	- HEAD isn't a symlink or a symref (its a normal ref in its
> 	  own right);

Why?  Usually HEAD is a pointer to the active branch.  I
consider it is a bug in the upload-pack protocol not to convey
that information (but that is a separate topic).

> 	- git-mirror.permitted is true in the config file.

Ok.

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]