More help with "pull" please

More help with "pull" please

[John Dlugosz]

I've actually given up on using "git pull" at all, preferring to fetch
first, examine in gitk, and then decide whether to merge or whatever.

The problem I have is that it seems to always want to merge "something"
with the current checked-out branch.  It always throws the remote HEAD
into the mix, or if fetch lines are set up in the configuration file,
takes the first thing on there regardless of which branch I'm currently
checked out.  Maybe I'm wrong, but I just re-read the man page, forward
and backwards, and am more bewildered than ever.

Anyway, I want to help out a co-worker who has a more specialized
situation that may be right for a pull.  Also, I'll talk him through
cloning the remote from the beginning, so the config files won't be all
strange or not setup from the previous users.

The only remaining issue is the remote in question:  it is not a bare
repository, and may be in use locally as well, at least for maintenance.
So I can't trust its HEAD to be anything reasonable at any given time.

This person wants to track a remote branch tip.  When that advances or
otherwise changes on the remote, update the working tree to match.  It
will always use the same branch, let's call it ReleaseCandidate for this
discussion.

My question is:  What is the easiest way to create this local repository
and operate it so that he can just keep it following that branch on the
remote?

Thanks,
--John
(excuse the footer; it's not my idea)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: More help with "pull" please

[Tomas Carnecky]

On Apr 1, 2009, at 9:28 PM, John Dlugosz wrote:

> I've actually given up on using "git pull" at all, preferring to fetch
> first, examine in gitk, and then decide whether to merge or whatever.
>
> The problem I have is that it seems to always want to merge  
> "something"
> with the current checked-out branch.  It always throws the remote HEAD
> into the mix, or if fetch lines are set up in the configuration file,
> takes the first thing on there regardless of which branch I'm  
> currently
> checked out.  Maybe I'm wrong, but I just re-read the man page,  
> forward
> and backwards, and am more bewildered than ever.

When you create a branch, you can tell git which remote branch it  
tracks, like this:

$ git branch --track mynext origin/next

So whenever you are on brach 'mynext' and do a git-pull, it will fetch  
and merge origin/next.

You can do the same with the git-checkout command:

$ git checkout --track origin/next

This will create a local branch 'next' which tracks 'origin/next'

> Anyway, I want to help out a co-worker who has a more specialized
> situation that may be right for a pull.  Also, I'll talk him through
> cloning the remote from the beginning, so the config files won't be  
> all
> strange or not setup from the previous users.
>
> The only remaining issue is the remote in question:  it is not a bare
> repository, and may be in use locally as well, at least for  
> maintenance.
> So I can't trust its HEAD to be anything reasonable at any given time.
>
> This person wants to track a remote branch tip.  When that advances or
> otherwise changes on the remote, update the working tree to match.  It
> will always use the same branch, let's call it ReleaseCandidate for  
> this
> discussion.
>
> My question is:  What is the easiest way to create this local  
> repository
> and operate it so that he can just keep it following that branch on  
> the
> remote?

$ git clone $url XXX
$ cd XXX
$ git checkout --trach origin/ReleaseCandidate
...
$ git pull # will automatically fetch and merge origin/ReleaseCandidate

tom

RE: More help with "pull" please

[John Dlugosz]

> When you create a branch, you can tell git which remote branch it
> tracks, like this:
> 
> $ git branch --track mynext origin/next
> 
> So whenever you are on brach 'mynext' and do a git-pull, it will fetch
> and merge origin/next.
> 
> You can do the same with the git-checkout command:
> 
> $ git checkout --track origin/next
> 
> This will create a local branch 'next' which tracks 'origin/next'
> 

OK, that works by adding something to the config file, right?  The docs
don't say, but does mention "having Pull: <refspec> lines for a
<repository>".  Does tracking add Pull: lines, or is that another
feature?

> 
> $ git clone $url XXX
> $ cd XXX
> $ git checkout --track origin/ReleaseCandidate
> ...
> $ git pull # will automatically fetch and merge
origin/ReleaseCandidate

According to the manpage on pull, "While git-pull run without any
explicit <refspec> parameter takes default <refspec>s from Pull: lines,
it merges only the first <refspec> found into the current branch, after
fetching all the remote refs."

Also, "When no refspec was given on the command line ... If
branch.<name>.merge configuration for the current branch <name> exists,
that is the name of the branch at the remote site that is merged."  So
is that yet again different from having Pull: lines?  If so, I'm fine if
no "Pull:" lines exist, or it would merge the first refspec found there.

Also, "Normally the branch merged in is the HEAD of the remote
repository, but the choice is determined by the branch.<name>.remote and
branch.<name>.merge options; see git-config(1) for details."  That
agrees with the previous.  If branch.<name>.merge configuration exists,
I don't need to worry about the remote HEAD.


> $ git checkout --track origin/ReleaseCandidate

That command does not work.  It compains that --track can only be used
with -b, etc.

I think 
	git checkout -b origin/ReleaseCandidate

is the correct shortcut?  

	git checkout -b ReleaseCandidate origin/ReleaseCandidate

did work.  I know that --track is automatic if the second argument is
remote.

--John




TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: More help with "pull" please

[Tomas Carnecky]

On Apr 2, 2009, at 12:53 AM, John Dlugosz wrote:

>> When you create a branch, you can tell git which remote branch it
>> tracks, like this:
>>
>> $ git branch --track mynext origin/next
>>
>> So whenever you are on brach 'mynext' and do a git-pull, it will  
>> fetch
>> and merge origin/next.
>>
>> You can do the same with the git-checkout command:
>>
>> $ git checkout --track origin/next
>>
>> This will create a local branch 'next' which tracks 'origin/next'
>>
>
> OK, that works by adding something to the config file, right?  The  
> docs
> don't say, but does mention "having Pull: <refspec> lines for a
> <repository>".  Does tracking add Pull: lines, or is that another
> feature?

I think Pull: lines are not used anymore in newer repositories.  
Tracking is done through the 'branch.<name>.remote' and  
'branch.<name>.merge' config options (which are automatically set by  
git-branch/git-checkout when you use --track).

>>
>> $ git clone $url XXX
>> $ cd XXX
>> $ git checkout --track origin/ReleaseCandidate
>> ...
>> $ git pull # will automatically fetch and merge
> origin/ReleaseCandidate
>
> According to the manpage on pull, "While git-pull run without any
> explicit <refspec> parameter takes default <refspec>s from Pull:  
> lines,
> it merges only the first <refspec> found into the current branch,  
> after
> fetching all the remote refs."
>
> Also, "When no refspec was given on the command line ... If
> branch.<name>.merge configuration for the current branch <name>  
> exists,
> that is the name of the branch at the remote site that is merged."  So
> is that yet again different from having Pull: lines?  If so, I'm  
> fine if
> no "Pull:" lines exist, or it would merge the first refspec found  
> there.
>
> Also, "Normally the branch merged in is the HEAD of the remote
> repository, but the choice is determined by the branch.<name>.remote  
> and
> branch.<name>.merge options; see git-config(1) for details."  That
> agrees with the previous.  If branch.<name>.merge configuration  
> exists,
> I don't need to worry about the remote HEAD.

I'd say forget about Pull: because you won't see any of that in newer  
repositories. Instead, just use --track when checking out a branch you  
intend to follow. And, more as an implementation detail than anything  
else, remember that the tracking is done through the above mentioned  
config options (which you can set/change using git-config or directly  
by editing the .git/config file).

>
>> $ git checkout --track origin/ReleaseCandidate
>
> That command does not work.  It compains that --track can only be used
> with -b, etc.
>
> I think
> 	git checkout -b origin/ReleaseCandidate
>
> is the correct shortcut?
>
> 	git checkout -b ReleaseCandidate origin/ReleaseCandidate
>
> did work.  I know that --track is automatic if the second argument is
> remote.

Maybe it's because I'm using a fairly recent version  
(1.6.2.1.307.g91408).

tom

RE: More help with "pull" please

[John Dlugosz]

> I think Pull: lines are not used anymore in newer repositories.
...
> I'd say forget about Pull: because you won't see any of that in newer
> repositories. Instead, just use --track when checking out a branch you
> intend to follow. And, more as an implementation detail than anything
> else, remember that the tracking is done through the above mentioned
> config options (which you can set/change using git-config or directly
> by editing the .git/config file).

OK, the documentation is clear if I ignore that.
I expect it to be "well behaved" if I'm on a tracking branch and give it
no arguments, or if the single refspec argument is the correct remote
for the branch I'm on.  Otherwise (not a tracking branch) the docs just
say "It's complicated, backward compatibility" and presumably involves
those non-existent Pull: lines and the state of the remote's HEAD.



> Maybe it's because I'm using a fairly recent version
> (1.6.2.1.307.g91408).

I'm running git version (1.6.2.msysgit.0.186.gf7512), and I assume my
coworker's was a bit older.

--John


TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: More help with "pull" please

[Junio C Hamano]

Tomas Carnecky <tom@dbservice.com> writes:

>> OK, that works by adding something to the config file, right?  The
>> docs
>> don't say, but does mention "having Pull: <refspec> lines for a
>> <repository>".  Does tracking add Pull: lines, or is that another
>> feature?
>
> I think Pull: lines are not used anymore in newer
> repositories.

If your repository is using .git/remotes/origin to name the "origin"
remote, they are still honored.  But you are correct to point out that
branch.<name>.remote and with the remote.<name>.* variables in .git/config
are used to control these more recent features.  So in that sense the
documentation is still correct.

RE: More help with "pull" please

[John Dlugosz]

> If your repository is using .git/remotes/origin to name the "origin"

I don't have a directory under .git called remotes.  A new repository
made using clone describes origin in the config file.  Is that an old
way of doing things?

> remote, they are still honored.  But you are correct to point out that
> branch.<name>.remote and with the remote.<name>.* variables in
> .git/config
> are used to control these more recent features.  So in that sense the
> documentation is still correct.

A related question:  is the name "origin" hard-coded as the default, or
does each repository remember specifically which is the upstream
repository regardless of what you named it?  From what I see in the
config file, it would have to be per-branch.  I suppose in other cases
it's implicit in where the label was found under remotes.

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: More help with "pull" please

[Tomas Carnecky]

On Apr 2, 2009, at 4:45 PM, John Dlugosz wrote:

>> If your repository is using .git/remotes/origin to name the "origin"
>
> I don't have a directory under .git called remotes.  A new repository
> made using clone describes origin in the config file.  Is that an old
> way of doing things?

Yep. Earlier git versions used one config file per remote. Newer git  
versions use the .git/config file.

>> remote, they are still honored.  But you are correct to point out  
>> that
>> branch.<name>.remote and with the remote.<name>.* variables in
>> .git/config
>> are used to control these more recent features.  So in that sense the
>> documentation is still correct.
>
> A related question:  is the name "origin" hard-coded as the default,  
> or
> does each repository remember specifically which is the upstream
> repository regardless of what you named it?  From what I see in the
> config file, it would have to be per-branch.  I suppose in other cases
> it's implicit in where the label was found under remotes.

'origin' is the default name for the remote you cloned from. But there  
is nothing special to it other than being a default name used  
throughout git. You can manually add remotes under a different name if  
you like.

$ git clone $url ./xyz

is roughly the same as:

$ mkdir ./xyz && cd ./xyz
$ git init
$ git remote add origin $url
$ git fetch origin
$ git checkout -b master origin/master

tom