Nicolas Pitre <nico@xxxxxxx> writes: > What is the point of hiding tracking branches? Why just not making them > easier to use instead? There are currently so many ways to specify > remote branches that even I get confused. Ok, I think in essence we are saying the same thing except I went overboard by suggsting to extend sha1_name to also look at .git/remotes/$name which is not necessary, because we already have the .git/refs/remotes/%s/HEAD magic there. Consider the suggestion of "upstream#next" syntax retracted, please. > 1) make "git init" an alias for "git init-db". Or even better, have "gh init". > 2) "pull" and "push" should be symmetrical operations I think that makes a lot of sense to have "gh pull" and "gh push" as symmetric operations, and make "gh merge" do the fast-forward and 3-way merge magic done in the current "git pull". These three words would have a lot saner meaning. > 3) remote branch handling should become more straight forward. > > OK! Now that we've solved the pull issue and that everybody agrees with > me (how can't you all agree with me anyway) let's have a look at remote > branches. I would probably prefer making the default namespace under .git/refs/remotes/remote-name for the tracking branches this proposal creates, but other than that I agree with the general direction this proposal is taking us, including branch groups. We have .git/refs/remotes/%s/HEAD magic so I do not think we even need to treat one branch repository any specially as you suggsted. The reason I am suggsting "gh" instead of "git" is primarily to deal with stale documentation people would find googling. I can easily see people get confused by reading "pull = fetch + merge" from either mailing list archive or Git cheat sheet various projects seem to have developed. It does not mean we need to redo _all_ UI. I think most of the archaeology commands have sane UI so during the transition period (git 1.99) we can have "git log" and "gh log" which are one and the same program, and perhaps git 2.0 can be shipped with clear distinction between plumbing (i.e. git-update-index and friends) and porcelain (e.g. "gh pull" that only fetches but with the user friendliness you outlined here), with backward compatibility wart to help old timers (e.g. "git pull" that still does "git fetch" followed by "git merge"). - 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