Junio C Hamano wrote: > Brandon Casey <drafnel@xxxxxxxxx> writes: > >>> Having said that, I do not particularly think the new behaviour >>> is bad per-se. If you are storing what you fetched locally in >>> tracking branches, you are interested in their work enough to >>> want to auto-follow their tags. >> How is "tracking" defined? Is this a term that implies some configuration >> to link a local branch to a remote branch? Or is any local branch created >> from a remote branch considered "tracking"? > > I probably should have said "Instead of just letting fetch > temporarily store the result in FETCH_HEAD and using it from > there, you saved it away; that's a good indication of you care > about it deeply enough". > > It's really about what's convenient. I was somewhat upset that > the behaviour change was not I was very aware of (perhaps I said > it was a good idea and I then forgot), I didn't think the > earlier behaviour was broken, but if I have to choose, I think > the new behaviour is probably slightly nicer than the old one. It feels a little inconsistent to me. With this behavior adopted as standard, then all forms of fetch will fetch tags except for 'git-fetch <repo> <branch>'. I think this is probably the least used form for porcelain. What I understand you to be saying is that creating a branch during fetch indicates "I care deeply enough, so I want tags". At the moment, I don't know why I would fetch if I didn't want to make a branch. Even if I just wanted to cherry-pick one patch, or one source file, or (some other contrived example), I think I would create a branch to give it some anchor point, and why not create the branch during the fetch. And, if I fetch now with the colon notation implying I want tags, later, if I 'git pull <repo> <branch>' from within that branch, why does that imply that I do not still want tags just because I'm not creating a 'new' branch. I think the current metric for indicating "caring deeply enough" is the remote tracking configuration. Tracking implies "I care deeply enough, I want tags", lack of tracking does not imply this. But I said this already in another email. I am not sure if this feels right because it is documented or because it is right. An alternative to this is to make fetch completely consistent so it either "always" gets tags, or "never" gets tags, and requires an option to reverse its behavior. It seems to me that "never" gets tags is the safer choice. This is because accidentally fetching tags is a pain to clean up, but if I forget to ask for tags, I just run the same command again and ask this time. If I fetch or pull and use the --tags (the current --tags should be changed to --all-tags) then I know what I am doing. The documented behavior for tracking branches and fetching tags could be retained by requiring a fetch option in the branch configuration and modifying git-remote and commands that use --track, to add the option by default. The big downside is that this would require existing repositories to update their config file which would also cause confusion. -brandon - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
