Can’t find the 1.11.10 tag

[AI]

"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.

[Luther]

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.

[iceiceice]

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.

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.

Luther:

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
...

I'm not sure why it calls 1.11.11 a "detached head state", I thought that checking out a tag isn't considered a detached head. IIRC it doesn't do that in other situations where I've checked out a tag. But anyways it seems to checkout and build correctly.

[Iris]

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.

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:

Code: Select all

$ git checkout -b local-1.11.11 1.11.11 # different names required to avoid “refname ‘foo’ is ambiguous” errors

But you really don’t need to do this unless you are going to commit your own changes on top. If you wanted to contribute you would be required to rebase your work on top of master rather than a release tag, anyway.

[Luther]

Thanks for the help. This thread does help clear my mind about how branches work.