libata-dev git question:

libata-dev git question:

[Mark Lord]

I am below "novice" when it comes to git:

> $ git-pull --update-head-ok --tags git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> Warning: No merge candidate found because value of config option
>         "branch.master.merge" does not match any remote branch fetched.
> No changes.
..

Is that "normal" ?
Is that even the correct command to update my entire local existing copy of Jeff's git tree?

git version 1.5.2.5

??

Re: libata-dev git question:

[Jeff Garzik]

Mark Lord wrote:
> I am below "novice" when it comes to git:
> 
>> $ git-pull --update-head-ok --tags 
>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>> Warning: No merge candidate found because value of config option
>>         "branch.master.merge" does not match any remote branch fetched.
>> No changes.
> ..
> 
> Is that "normal" ?

Yes.


> Is that even the correct command to update my entire local existing copy 
> of Jeff's git tree?

No.

Generally I would use

	cd $repo
	git-checkout master	# if not already there
	git pull		# fetches new objects, updates 'master'
	git-fetch -f $URL upstream:upstream	# fetch updated branch
	git-fetch -f $URL mv-ncq:mv-ncq
	git-fetch -f $URL upstream-fixes:upstream-fixes
	git-fetch -f $URL upstream:upstream
	... continue for each branch you like...

There is probably an easier way to get it to download all branches, even 
if they have been rebased.

	Jeff

Re: libata-dev git question:

[Mark Lord]

Jeff Garzik wrote:
> Mark Lord wrote:
>> I am below "novice" when it comes to git:
>>
>>> $ git-pull --update-head-ok --tags 
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>>> Warning: No merge candidate found because value of config option
>>>         "branch.master.merge" does not match any remote branch fetched.
>>> No changes.
>> ..
>>
>> Is that "normal" ?
> 
> Yes.
> 
> 
>> Is that even the correct command to update my entire local existing 
>> copy of Jeff's git tree?
> 
> No.
> 
> Generally I would use
> 
>     cd $repo
>     git-checkout master    # if not already there
>     git pull        # fetches new objects, updates 'master'
>     git-fetch -f $URL upstream:upstream    # fetch updated branch
>     git-fetch -f $URL mv-ncq:mv-ncq
>     git-fetch -f $URL upstream-fixes:upstream-fixes
>     git-fetch -f $URL upstream:upstream
>     ... continue for each branch you like...
> 
> There is probably an easier way to get it to download all branches, even 
> if they have been rebased.
..

Thanks.  I was just going by your KHGTG page until now.

Re: libata-dev git question:

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

Attached is the script I use to keep a tree synced with upstream tree.
.git/origin points to upstream repo like the following.

  master.kernel.org /pub/scm/linux/kernel/git/jgarzik/libata-dev.git ssh

If you have ssh access to the origin, specify ssh as above, everything
will go over a ssh channel.  If you don't, you need rsync and git access
to the machine.

The script keeps the tree heads identical to the upstream tree so don't
create custom branches in the tree.  They'll go away when you run
git-sync.sh the next time.  I have ~/os/linux-2.6 and
~/os/ata/work/libata-dev trees to track upstream and ~/os/work and
~/os/ata/work trees where I work on and fetches / pulls necessary heads
from the two upstream clones.

If you make your work trees' alternates files to point to the upstream
clones, having separate upstream and work trees don't waste much space
and it's easy to check what's going on upstream that way.

-- 
tejun

[-- Attachment #2: git-sync.sh --]
[-- Type: application/x-shellscript, Size: 726 bytes --]