From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Subject: Strange cogito behaviour
Date: Tue, 1 Aug 2006 10:53:24 +0100 [thread overview]
Message-ID: <200608011053.25112.andyparkins@gmail.com> (raw)
[-- 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 --]
next reply other threads:[~2006-08-01 9:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-01 9:53 Andy Parkins [this message]
2006-08-01 15:12 ` Strange cogito behaviour Jeff King
2006-08-01 15:41 ` Andy Parkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200608011053.25112.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).