Strange cogito behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx

Attachment: weird-cogito.sh
Description: application/shellscript

Attachment: pgpy39jrzWz8D.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]