Can’t find the 1.11.10 tag
Moderator: Forum Moderators
Re: Can’t find the 1.11.10 tag
"Being on a branch" means tracking its HEAD. If you check out a tag, you obviously don't want the HEAD of the branch. That's just what it means.
Re: Can’t find the 1.11.10 tag
Ok, that makes sense. But I can't figure out if that relates to the problem I was having. How does the checkout directory effect merges? When I first tried to switch from 1.10.7 to 1.11.10, I did 'git pull origin master', so git should have had the information it needed without looking at the checkout.
Re: Can’t find the 1.11.10 tag
Luther wrote: Yes. Git had tried to do a merge, but failed. The output was too complex for me to understand. A 'git diff' showed very large chunks from many files. A hard reset (as mentioned earlier in this thread) mostly fixed this problem.
Also, my checkout of 1.11.11 has again left me in a detached HEAD state. It's frustrating that git does not automatically put me on a branch. It's hard to believe that git has such an obvious bug, but it's equally hard to believe that no one can explain why git does this.
Luther:Luther wrote:Ok, that makes sense. But I can't figure out if that relates to the problem I was having. How does the checkout directory effect merges? When I first tried to switch from 1.10.7 to 1.11.10, I did 'git pull origin master', so git should have had the information it needed without looking at the checkout.
You shouldn't do "git pull origin master" except right after "git checkout master". In other words, "git status" should tell you that you (your HEAD) is on master just before you pull. Otherwise, if you "git pull origin master", git will try to merge the entire master branch into your whatever weird location you are at.
http://gitref.org/remotes/#fetch
In fact I'm not sure why you are using "git pull" at all? It seems to me that "git fetch"/"git clone" to get the upstream content, followed by "git checkout" to get the tag you want, should be enough for you.
Checkout will not affect any of the snapshots in the repository, it only updates your head and constructs the desired snapshot in your file system for you to use and modify. However, if you modify files, e.g. by some other git command which doesn't completely work (like "git pull origin master" in a weird location), and then try to leave by checking out somewhere else, git will not discard your changes and will give you a chance to fix things before discarding your work (since it can't know what else you are doing there). That's not a bug, that's a safety feature.
When that is the case, you will be in a detached head state, because nothing else makes sense -- you are basically in between operations, because an operation from before only went halfway through.
Edit:
I tried to actually go through the steps myself, here's what I got:
Code: Select all
chris@chris-KLR650 ~/wesnoth-src $ mkdir clone2
chris@chris-KLR650 ~/wesnoth-src $ cd clone2
chris@chris-KLR650 ~/wesnoth-src/clone2 $ git clone git://github.com/wesnoth/wesnoth.git
Cloning into 'wesnoth'...
remote: Reusing existing pack: 802544, done.
remote: Counting objects: 677, done.
remote: Compressing objects: 100% (669/669), done.
Receiving objects: 100% (803221/803221), 1.77 GiB | 246 KiB/s, done.
remote: Total 803221 (delta 237), reused 1 (delta 0)
Resolving deltas: 100% (633287/633287), done.
Checking out files: 100% (18669/18669), done.
chris@chris-KLR650 ~/wesnoth-src/clone2 $ ls
wesnoth
chris@chris-KLR650 ~/wesnoth-src/clone2 $ cd wesnoth
chris@chris-KLR650 ~/wesnoth-src/clone2/wesnoth $ git status
# On branch master
nothing to commit, working directory clean
chris@chris-KLR650 ~/wesnoth-src/clone2/wesnoth $ git tag -l
1.0
1.0.1
1.0.2
1.0rc2
1.1
1.1.1
1.1.1-rc1
1.1.1-rc2
...
v1_0_rc1rc1
v1_0rc1
chris@chris-KLR650 ~/wesnoth-src/clone2/wesnoth $ git checkout tags/1.11.11
Note: checking out 'tags/1.11.11'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at c2d2785... pot-update and regenerated doc files
chris@chris-KLR650 ~/wesnoth-src/clone2/wesnoth $ scons
scons: Reading SConscript files ...
Building Wesnoth version 1.11.11
Mkdir("build")
Checking for C header file poll.h... yes
Checking for C header file sys/poll.h... yes
Checking for C header file sys/select.h... yes
Checking for C header file sys/sendfile.h... yes
Checking for C function sendfile()... yes
Checking for C library m... yes
Checking for C function round()... yes
Checking whether C++ compiler works (g++ version >= 3.3 required)... yes
Checking for Gettext's libintl... libc built-in
Checking for Boost iostreams library version >= 1.34.1... yes
Checking for gzip support in Boost Iostreams... yes
...
Re: Can’t find the 1.11.10 tag
This is actually on purpose — a tag is a static ref that never changes, unlike the HEAD of a branch, and you aren’t supposed to make any further modifications to an existing tag. You can, however, create a new branch with the tag as a starting point if you wish:Luther wrote:Also, my checkout of 1.11.11 has again left me in a detached HEAD state. It's frustrating that git does not automatically put me on a branch. It's hard to believe that git has such an obvious bug, but it's equally hard to believe that no one can explain why git does this.
Code: Select all
$ git checkout -b local-1.11.11 1.11.11 # different names required to avoid “refname ‘foo’ is ambiguous” errors
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Can’t find the 1.11.10 tag
Thanks for the help. This thread does help clear my mind about how branches work.