git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Question] Fetching a new branch from remote
@ 2005-11-28 16:33 Carl Baldwin
  2005-12-01 20:09 ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Carl Baldwin @ 2005-11-28 16:33 UTC (permalink / raw)
  To: git

Greetings,

I have a short question about git fetch.  Say there is a new branch,
call it 'new-branch' in a remote repository.  I am interested in this
branch and want to fetch it to 'new-branch' in my local to track its
progress.

I would expect this to do it:

% git fetch -f <url> new-branch

But, it doesn't.

Actually, I just noticed that this accomplishes the desired result...

% git fetch <url> new-branch:new-branch

I also just noticed that the man pages only says that '-f' works on
tags.  Should it work on branches?  Either way, it wasn't clear to me
how to fetch a new branch from a remote and store it under the same name
locally.  In my opinion, git fetch -f should do this if given a
branchname from the remote.

Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Question] Fetching a new branch from remote
  2005-11-28 16:33 [Question] Fetching a new branch from remote Carl Baldwin
@ 2005-12-01 20:09 ` Junio C Hamano
  2005-12-01 20:40   ` Jon Loeliger
  2005-12-02 15:50   ` Carl Baldwin
  0 siblings, 2 replies; 4+ messages in thread
From: Junio C Hamano @ 2005-12-01 20:09 UTC (permalink / raw)
  To: Carl Baldwin; +Cc: git

Carl Baldwin <cnb@fc.hp.com> writes:

> I would expect this to do it:
>
> % git fetch -f <url> new-branch
>
> But, it doesn't.
>
> Actually, I just noticed that this accomplishes the desired result...
>
> % git fetch <url> new-branch:new-branch

First, '-f' means "allow overriding the fast-forward check when
updating an existing branch".  This can be done per refspec by
saying "+rbranch:lbranch" but if you are fetching more than one
remote branches at once (especially through "remotes" shorthand)
the option can be used to allow override of all of them.

A single token <refspec> defaults to "<refspec>:" (meaning,
"fetch but do not muck with our branches") is deliberate.  When
I get a pull request "please pull from git://u/r/l/ send2junio branch",
I do not "git pull git://u/r/l/ send2junio" right away, but do
"git fetch git://u/r/l/ send2junio" and inspect FETCH_HEAD with
various combinations of "git diff master..FETCH_HEAD" and
friends.  I do _not_ want it to create send2junio branch in my
repository with that.  Also "git pull git://u/r/l/ send2junio"
would internally run "git fetch git://u/r/l/ send2junio" and
then runs merge, and I do not want that to create send2junio
branch in my repository either.  The latter could be prevented by
adding an extra flag to git-fetch to tell it not to default
a single token <refspec> to "<refspec>:<refspec>" and pass that
flag from git-pull, though.

I just found out that the documentation for '-f' flag is simply
missing.  I'd propose to add the following.  Thanks for noticing.

-- >8 --
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index a25d04a..200c9b2 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -4,6 +4,11 @@
 	option old data in `.git/FETCH_HEAD` will be overwritten.
 
 -f, \--force::
+	When `git-fetch` is used with `<rbranch>:<lbranch>`
+	refspec, it refuses to update the local branch
+	`<lbranch>` unless the remote branch `<rbranch>` it
+	fetches is a descendant of `<lbranch>`.  This option
+	overrides that check.
 
 -t, \--tags::
 	By default, the git core utilities will not fetch and store

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [Question] Fetching a new branch from remote
  2005-12-01 20:09 ` Junio C Hamano
@ 2005-12-01 20:40   ` Jon Loeliger
  2005-12-02 15:50   ` Carl Baldwin
  1 sibling, 0 replies; 4+ messages in thread
From: Jon Loeliger @ 2005-12-01 20:40 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carl Baldwin, Git List

On Thu, 2005-12-01 at 14:09, Junio C Hamano wrote:

> 
> I just found out that the documentation for '-f' flag is simply
> missing.  I'd propose to add the following.  Thanks for noticing.

Hmm.  Apologies.  I had mentioned it back here, but
didn't know what it did and so didn't document it:

        
    From: 	Jon Loeliger <jdl@freescale.com>
    To: 	git@vger.kernel.org
    Subject: 	[PATCH] Add --tags documentation, scraped from JC mail.
    Date: 	Mon, 7 Nov 2005 07:03:30 -0700 	

    Signed-off-by: Jon Loeliger <jdl@freescale.com>

    ---

    Thin territory here for me.  Feel free to alter if not right! :-)
    Also notice the lonely --force option still...

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Question] Fetching a new branch from remote
  2005-12-01 20:09 ` Junio C Hamano
  2005-12-01 20:40   ` Jon Loeliger
@ 2005-12-02 15:50   ` Carl Baldwin
  1 sibling, 0 replies; 4+ messages in thread
From: Carl Baldwin @ 2005-12-02 15:50 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

The documentation below does make this more clear.  Now that you've
explained it I can see it useful to fetch a remote head without creating
a local one.  I simply hadn't thought of this scenerio.

Thank you for the explanation.

Cheers,
Carl

On Thu, Dec 01, 2005 at 12:09:01PM -0800, Junio C Hamano wrote:
> Carl Baldwin <cnb@fc.hp.com> writes:
> 
> > I would expect this to do it:
> >
> > % git fetch -f <url> new-branch
> >
> > But, it doesn't.
> >
> > Actually, I just noticed that this accomplishes the desired result...
> >
> > % git fetch <url> new-branch:new-branch
> 
> First, '-f' means "allow overriding the fast-forward check when
> updating an existing branch".  This can be done per refspec by
> saying "+rbranch:lbranch" but if you are fetching more than one
> remote branches at once (especially through "remotes" shorthand)
> the option can be used to allow override of all of them.
> 
> A single token <refspec> defaults to "<refspec>:" (meaning,
> "fetch but do not muck with our branches") is deliberate.  When
> I get a pull request "please pull from git://u/r/l/ send2junio branch",
> I do not "git pull git://u/r/l/ send2junio" right away, but do
> "git fetch git://u/r/l/ send2junio" and inspect FETCH_HEAD with
> various combinations of "git diff master..FETCH_HEAD" and
> friends.  I do _not_ want it to create send2junio branch in my
> repository with that.  Also "git pull git://u/r/l/ send2junio"
> would internally run "git fetch git://u/r/l/ send2junio" and
> then runs merge, and I do not want that to create send2junio
> branch in my repository either.  The latter could be prevented by
> adding an extra flag to git-fetch to tell it not to default
> a single token <refspec> to "<refspec>:<refspec>" and pass that
> flag from git-pull, though.
> 
> I just found out that the documentation for '-f' flag is simply
> missing.  I'd propose to add the following.  Thanks for noticing.
> 
> -- >8 --
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index a25d04a..200c9b2 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -4,6 +4,11 @@
>  	option old data in `.git/FETCH_HEAD` will be overwritten.
>  
>  -f, \--force::
> +	When `git-fetch` is used with `<rbranch>:<lbranch>`
> +	refspec, it refuses to update the local branch
> +	`<lbranch>` unless the remote branch `<rbranch>` it
> +	fetches is a descendant of `<lbranch>`.  This option
> +	overrides that check.
>  
>  -t, \--tags::
>  	By default, the git core utilities will not fetch and store
> 
> 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-12-02 15:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-28 16:33 [Question] Fetching a new branch from remote Carl Baldwin
2005-12-01 20:09 ` Junio C Hamano
2005-12-01 20:40   ` Jon Loeliger
2005-12-02 15:50   ` Carl Baldwin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).