Fetching from peer's public repo

Fetching from peer's public repo

[Bill Lear]

My fetch from a peer's public repo seems to be failing:

% git --bare fetch git://source/public/project topic:topic
remote: Generating pack...
remote: Done counting 48 objects.
remote: Result has 34 objects.
remote: Deltifying 34 objects.
remote:  100% (34/34) done
remote: Total 34, written 34 (delta 22), reused 24 (delta 12)
Unpacking 34 objects
 100% (34/34) done
* refs/heads/topic: not updating to non-fast forward branch 'topic' of git://source/public/project
  old...new: 1c332f5...f3b18ff

I assume that is because his public repo does not contain changes I
have pushed into my public repo.  So, I asked him to pull from
my public repo into his.  He did, and said that git blathered that
there were 12 changed files, etc.

I then tried the fetch again and it failed in the same way.  If I
look at the log output for the "old...new: 1c332f5...f3b18ff" line
above, I see the changes that he has that I want to get, but apparently
cannot (I tried to pull from my public to my private and it said
"Already up-to-date."):

% git log 1c332f5..f3b18ff
[... output looks reasonable ...]

Any ideas on how I can resolve this?

Also, what is the difference between:

% git log 1c332f5..f3b18ff

and

% git log 1c332f5...f3b18ff

with the latter having three dots instead of two?  It seems to show
much more output, but I don't know what the intent is.


Bill

Re: Fetching from peer's public repo

[Bill Lear]

On Thursday, February 1, 2007 at 09:24:34 (-0600) Bill Lear writes:
>My fetch from a peer's public repo seems to be failing:
>
>% git --bare fetch git://source/public/project topic:topic
>remote: Generating pack...
>remote: Done counting 48 objects.
>remote: Result has 34 objects.
>remote: Deltifying 34 objects.
>remote:  100% (34/34) done
>remote: Total 34, written 34 (delta 22), reused 24 (delta 12)
>Unpacking 34 objects
> 100% (34/34) done
>* refs/heads/topic: not updating to non-fast forward branch 'topic' of git://source/public/project
>  old...new: 1c332f5...f3b18ff
>
>I assume that is because his public repo does not contain changes I
>have pushed into my public repo.  So, I asked him to pull from
>my public repo into his.  He did, and said that git blathered that
>there were 12 changed files, etc.

Ok, I think I have discovered the cause...  Sorry for wasting time.
My pal did a git pull from my public repo's topic branch into his
master branch by mistake.  My fetch of his topic branch of course
failed, as he did not update it.

You know, some training wheels for git might be nice...

Such as a git config variable:

[newbies]
	please.god.save.me.if.I.try.to.merge = true

Which would cause git-pull, git-fetch, git-merge (whatever) to prompt
you:

  Hey Nimrod, you're about to MERGE something from one branch to
  another --- are you sure you really want to do this? (y/n)

I myself have shot several repos in the head by doing this by mistake.
Once this is done, and you pull it into your private repos, the infection
spreads, and you have to go back to each and repair them...

We'll get this right soon...


Bill

Re: Fetching from peer's public repo

[Jakub Narebski]

Bill Lear wrote:

> My fetch from a peer's public repo seems to be failing:
> 
> % git --bare fetch git://source/public/project topic:topic
> remote: Generating pack...
> remote: Done counting 48 objects.
> remote: Result has 34 objects.
> remote: Deltifying 34 objects.
> remote:  100% (34/34) done
> remote: Total 34, written 34 (delta 22), reused 24 (delta 12)
> Unpacking 34 objects
>  100% (34/34) done
> * refs/heads/topic: not updating to non-fast forward branch 'topic' of git://source/public/project
>   old...new: 1c332f5...f3b18ff
> 
> I assume that is because his public repo does not contain changes I
> have pushed into my public repo.  So, I asked him to pull from
> my public repo into his.  He did, and said that git blathered that
> there were 12 changed files, etc.

First, git did good and protected you from losing your changes which
were in "your public repo" but not in "his public repo" (well, not exacly
lose, as you can very easy revert fetch thanks to ORIG_HEAD and reflog
if you have it enabled).

Second, if you know what you are doing, for example if you know that
topic branch was rebased (has it's history changed), so you know that
non-fast forward case is not an error, you can use euther "+topic:topic"
refspec, or use --force option to git-fetch.

Third, you do not pull into bare repo: you fetch into bare repository.
But, fourth, it looks like he has some changes and you have some changes;
unless you want to have those changes in separate branches, you have to
merge your and his changes; or he has to merge your and his changes
(but in working repo, i.e. with working directory, not a bare one, as
merge might result in conflicts) using git-pull.

Fifth, this situation is what tracking branches are for: you fetch
his from his working branch changes into tracking branch and merge
into your working branch when you want; he fetches your changes
from your working branch into tracking branch and merge your changes
into his working branch when he wants.

[...]
> Also, what is the difference between:
> 
> % git log 1c332f5..f3b18ff
> 
> and
> 
> % git log 1c332f5...f3b18ff
> 
> with the latter having three dots instead of two?  It seems to show
> much more output, but I don't know what the intent is.

"git log 1c332f5..f3b18ff" is equivalent to "git log f3b18ff --not 1c332f5"
which means whowing all changes reachable from f3b18ff but which are not
reachable from 1c332f5, which result in all changes from 1c332f5 (non
inclusive) to f3b18ff (inclusive).

"git log 1c332f5...f3b18ff" is equivalent to
  git log 1c332f5 f3b18ff --not $(git merge-base --all 1c332f5 f3b18ff)
which result in all changes which are either in 1c332f5 xor in f3b18ff,
but not in both.

git 1.5.0 would have --left-right option to mark which side (1c332f5 or
f3b18ff) revisions in 1c332f5...f3b18ff belong to.


P.S. RTFM.

git-log(1):
       The command takes options applicable to the git-rev-list(1) command to con-
       trol what is shown and how

git-rev-list(1):
       Another  special  notation  is  "<commit1>...<commit2>" which is useful for
       merges. The resulting set of commits is the  symmetric  difference  between
       the two operands. The following two commands are equivalent:

               $ git-rev-list A B --not $(git-merge-base --all A B)
               $ git-rev-list A...B
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git