* Elegant subdirectory checkout of remote-tracking branch?
@ 2013-03-01 15:22 W. Trevor King
2013-03-01 18:05 ` Junio C Hamano
2013-03-02 8:04 ` Jeff King
0 siblings, 2 replies; 3+ messages in thread
From: W. Trevor King @ 2013-03-01 15:22 UTC (permalink / raw)
To: Git
[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]
I'm trying to figure out the most efficient way to keep an up to
date `todo` branch checked out in Meta [1]. I've tried a few
things like:
$ git submodule add -b refs/remotes/origin/todo --reference ./ -- ./ Meta
and:
$ git clone --single-branch --branch refs/remotes/origin/todo ./ Meta
These fail because I can't use a remote tracking branch as a
source for the clone. It should be possible to do:
$ git clone --reference . --single-branch --branch todo git://git.kernel.org/pub/scm/git/git.git Meta
but that will require (I think) network access during a fetch.
Since I'm already fetching `origin` from the superproject, I
don't want to have to refetch them for the submodule (or whatever
Meta ends up being). Here's what I think happens with a
submodule fetch:
1. Query the remote URL to dereference its current `todo` branch.
2. Check if we have that object in our local object share (which
we should, due to --reference and a recent superproject
fetch).
3. Fetch any missing objects from the remote URL.
I want to replace step 1 with:
1b. Query the superproject to dereference its current
`origin/todo` branch.
and step 3 with:
3b. Access objects from the superproject directly (as with
--reference / --shared).
Do I need to setup something like:
[remote "origin"]
url = ../.git
fetch = +refs/remotes/origin/todo:refs/remotes/origin/todo
by hand, or is there an easier way?
I can, of course, clone a local `todo` branch if I've set one up in my
superproject. However, then I'd have to update-ref that branch to
sync with origin/todo after every fetch (that updates origin/todo).
This could be handled with a `git fetch` wrapper, but… yuck :p.
Any suggestions for an elegant solution would be appreciated :).
Once we figure something out, I can write it up and stick it in
howto/maintain-git.txt.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/144748
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Elegant subdirectory checkout of remote-tracking branch?
2013-03-01 15:22 Elegant subdirectory checkout of remote-tracking branch? W. Trevor King
@ 2013-03-01 18:05 ` Junio C Hamano
2013-03-02 8:04 ` Jeff King
1 sibling, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2013-03-01 18:05 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
"W. Trevor King" <wking@tremily.us> writes:
> Any suggestions for an elegant solution would be appreciated :).
My Meta checkout is not a submodule of anything. It is a totally
independent repository and is not linked with git.git in any way.
It started as an independent repository, and it still is.
That it has been pushed to the same repository at k.org was a mere
historical accident (I only had that repository writable there when
I started); it not even a recommended practice to publish unrelated
histories in a single repository. You are seeing 'todo' in some of
my public mirrors only due to historical inertia.
Just treat the git.git primary directory and the Meta directory as
what they are: two checkouts of two totally independent projects,
one of which happens to be designed to be checked out at a fixed
location relative to the other. When running "pull --ff-only", do
so in both independently.
That is what I do in my secondary repositories.
> Once we figure something out, I can write it up and stick it in
> howto/maintain-git.txt.
You are free to write and do whatever suites yourself, but a
description of a workflow that is not what I use does not belong to
the howto/maintain-git.txt document ;-)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Elegant subdirectory checkout of remote-tracking branch?
2013-03-01 15:22 Elegant subdirectory checkout of remote-tracking branch? W. Trevor King
2013-03-01 18:05 ` Junio C Hamano
@ 2013-03-02 8:04 ` Jeff King
1 sibling, 0 replies; 3+ messages in thread
From: Jeff King @ 2013-03-02 8:04 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
On Fri, Mar 01, 2013 at 10:22:53AM -0500, W. Trevor King wrote:
> These fail because I can't use a remote tracking branch as a
> source for the clone. It should be possible to do:
>
> $ git clone --reference . --single-branch --branch todo git://git.kernel.org/pub/scm/git/git.git Meta
>
> but that will require (I think) network access during a fetch.
Yes, it will. Junio mentioned already that for him, "Meta" is really a
separate repository, and I think the simplest thing is to just treat it
that way (that's how I handle my personal "meta" branch).
But if you really want to save the extra network round trip during a
fetch, you can either:
1. Just fetch from the surrounding repository using a custom refspec,
like:
git init Meta
cd Meta
git config add remote.origin.url ..
git config add remote.origin.fetch \
refs/remotes/origin/todo:refs/remotes/origin/todo
git fetch
git checkout todo
or
2. Look into the git-new-workdir script in contrib/workdir, which lets
you check out an alternate branch in a separate directory.
The latter would probably be the most seamless, but it's also the most
likely to have bugs. :)
-Peff
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-03-02 8:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-01 15:22 Elegant subdirectory checkout of remote-tracking branch? W. Trevor King
2013-03-01 18:05 ` Junio C Hamano
2013-03-02 8:04 ` Jeff King
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.