Strange cogito behaviour

Strange cogito behaviour

[Andy Parkins]

[-- Attachment #1.1: Type: text/plain, Size: 4411 bytes --]

Hello,

Hope this is the correct list for this report.

Attached is a script that demonstrates (I think) strange cogito behaviour.  
Run it in a temporary directory.

It does the following:
 * Create a repository, repo1, add a file to it
 * Create a branch inside repo1 and change the file in it
 * Switches repo1 to master branch
 * Clones repo1 to repo2
 * Switches repo1 to alternate branch
 * Updates repo2

The odd behaviour is that repo2 changes in the update to show the branch 
contents in the working copy.  The only actions that has happened in repo1 is 
a switch of the working directory to a different branch.  It could easily be 
that I've misunderstood what switch is doing, but the same operations using 
git seem to work as I'd expect (script available if required).

The script then continues with
 * Switch repo1 back to master branch
 * Update repo2

This time repo2 doesn't change.  So I'm more confused :-)

In case you don't want to run the script, sample output follows:
--------------------------------------------------------------
--- Make a project
--- Turn it into a repository, repo1
defaulting to local storage area
Adding file file
Committing initial tree ef18611ce9f2693e47a1b2df5e76613f53a9173c
Committed as f59933a07af5f12618deae8d33335621184ccc7c
--- Create a branch and change it's content
Creating new branch branch: f59933a07af5f12618deae8d33335621184ccc7c
Switching to branch branch...
M file
Committed as 88bc51f62dfa3d71fbc0140fdd48aa150215a632
--- Switch repo1 back to master
Switching to branch master...
--- Clone repo1 to repo2: repo2 is now the repo1#master
defaulting to local storage area
Using hard links
Fetching head...
`/home/andyp/src/git-test/repo1/.git/HEAD' -> 
`.git/refs/heads/./.origin-fetching'
`/home/andyp/src/git-test/repo1/.git/refs/heads/master' -> 
`.git/refs/heads/./.origin-fetching'
Fetching objects...
progress: 3 objects, 239 bytes
Fetching tags...
New branch: f59933a07af5f12618deae8d33335621184ccc7c
Cloned to repo2/ (origin /home/andyp/src/git-test/repo1 available as 
branch "origin")
--- file now contains master contents
initial contents goes in master branch
--- Switch repo1 to branch again
Switching to branch branch...
--- Update repo2
Using hard links
Fetching head...
`/home/andyp/src/git-test/repo1/.git/HEAD' -> 
`.git/refs/heads/./.origin-fetching'
`/home/andyp/src/git-test/repo1/.git/refs/heads/branch' -> 
`.git/refs/heads/./.origin-fetching'
Fetching objects...
progress: 3 objects, 290 bytes
Fetching tags...
Tree change: 
f59933a07af5f12618deae8d33335621184ccc7c:88bc51f62dfa3d71fbc0140fdd48aa150215a632

Applying changes...
Fast-forwarding f59933a07af5f12618deae8d33335621184ccc7c -> 
88bc51f62dfa3d71fbc0140fdd48aa150215a632
        on top of f59933a07af5f12618deae8d33335621184ccc7c ...
--- Show contents of both repositories
repo1/file:initial contents goes in master branch
repo1/file:added in branch - not in master
repo2/file:initial contents goes in master branch
repo2/file:added in branch - not in master
---
Why has repo2 changed? repo1 had its working copy switched
repo2 shouldn't care about what's in the local copy of repo1.
What exactly is repo2#master tracking?  It's certainly not
repo1#master.
--- Switching repo1 back to master
Switching to branch master...
--- Updating repo2 again
Using hard links
Fetching head...
`/home/andyp/src/git-test/repo1/.git/HEAD' -> 
`.git/refs/heads/./.origin-fetching'
`/home/andyp/src/git-test/repo1/.git/refs/heads/master' -> 
`.git/refs/heads/./.origin-fetching'
Fetching objects...

Fetching tags...
Tree change: 
88bc51f62dfa3d71fbc0140fdd48aa150215a632:f59933a07af5f12618deae8d33335621184ccc7c

Applying changes...
Branch already fully merged.
--- Show contents of both repositories
repo1/file:initial contents goes in master branch
repo2/file:initial contents goes in master branch
repo2/file:added in branch - not in master
---
Even more strange, switching repo1 back to "master" and
updating repo2, hasn't changed repo2.  The first test showed that
repo2 is not tracking #master; but this test shows that repo2
is not tracking repo1 HEAD either.  What is repo2 tracking?
(it seems that it's repo1#branch)
--------------------------------------------------------------


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

[-- Attachment #1.2: weird-cogito.sh --]
[-- Type: application/x-shellscript, Size: 1518 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Strange cogito behaviour

[Jeff King]

On Tue, Aug 01, 2006 at 10:53:24AM +0100, Andy Parkins wrote:

> It does the following:
>  * Create a repository, repo1, add a file to it
>  * Create a branch inside repo1 and change the file in it
>  * Switches repo1 to master branch
>  * Clones repo1 to repo2
>  * Switches repo1 to alternate branch
>  * Updates repo2
> 
> The odd behaviour is that repo2 changes in the update to show the branch 
> contents in the working copy.  The only actions that has happened in repo1 is 

A cogito fetch without a branch specifier defaults to the remote HEAD,
not master.  This is the documented behavior (see cg-branch-add(1)). I
agree it is confusing (I also thought it was a bug until I looked it up
:) ). If you want to always fetch from the master, you must say so
explicitly:
  $ cg-clone repo1#master repo2

> The script then continues with
>  * Switch repo1 back to master branch
>  * Update repo2
> This time repo2 doesn't change.  So I'm more confused :-)

This is because repo2's master is already at the branch, and repo1 is a
subset of that history. There is no need to merge since repo2 already
contains all of the commits in repo1 (plus another one which is only on
the branch in repo1).

-Peff

Re: Strange cogito behaviour

[Andy Parkins]

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

On Tuesday 2006 August 01 16:12, Jeff King wrote:

> A cogito fetch without a branch specifier defaults to the remote HEAD,
> not master.  This is the documented behavior (see cg-branch-add(1)). I
> agree it is confusing (I also thought it was a bug until I looked it up

Fair enough.  If it is working as intended, then I have no complaint.


> > The script then continues with
> >  * Switch repo1 back to master branch
> >  * Update repo2
> > This time repo2 doesn't change.  So I'm more confused :-)
>
> This is because repo2's master is already at the branch, and repo1 is a
> subset of that history. There is no need to merge since repo2 already
> contains all of the commits in repo1 (plus another one which is only on
> the branch in repo1).

I think I see now.  repo2 is neither repo1#master nor repo1#branch because it 
actually went like this:
 * repo1 cloned to repo2, repo2#master is repo1#master
 * repo2 fetches repo1#branch and /merges/ those changes
 * repo1#HEAD switched to HEAD=master
 * repo2 fetch does nothing because repo2 is actually
   repo1#master + repo1#branch, hence is newer than both
   repo1#master and repo1#branch
That explanation seems to fit exactly with the observed results, so would seem 
to be plausible.

Thank you for your help; I of course withdraw my bug report and apologise for 
bothering you all :-)


Andy


-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]