On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote: > On Thu, 19 Jul 2012 18:21:21 +0200 > Alexey Muranov <alexey.muranov@xxxxxxxxx> wrote: > > [...] >> I do not still understand very well some aspects of Git, like the >> exact purpose of "remote tracking branches" (are they for pull or for >> push?), so i may be wrong. > This is wery well explained in the Pro Git book, for instance. > And in numerous blog posts etc. I have read the Pro Gut book and numerous blog posts, but i keep forgetting the explanation because it does not make much sense to me: "Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type git push, Git automatically knows which server and branch to push to. Also, running git pull while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch." etc. Why the same "direct relationship" for push and pull? What happens if one of the branches was reset (yes, i know, "push -f"). Most importantly, what is the purpose of it? It is natural to expect that you might be pushing to and pulling from different remotes, i can even imagine pulling from more than one. >> However, i thought that a user was not >> expected to follow the moves of a remote branch of which the user is >> not an owner: if the user needs to follow the brach and not lose its >> commits, he/she should create a remote tracking branch. > This would present another namespacing issue: how would you name the > branches you're interested in so that they don't clash with your own > personal local branches? You'd have to invent a scheme which would > encode the remote's name in a branch name. But remote branches already > do just this. So you create a remote tracking branch when you intend > to actually *develop* something on that branch with the final intention > to push that work back. But i am not interested in remote branches, they are just fetched automatically when i do "git fetch". You cannot commit to a remote branch, and i think it is not common to checkout them without a "-b" option. If i am interested in them, i name them somehow. I think this is the only practical way if i do not want to chase reflogs, because the owner of the branch can reset or rebase it anytime. I do not develop on tracking branches. In fact, i am not even using "git pull". >>> So I think it would be a lot more palatable if we kept reflogs on >>> deleted branches. That, in turn, has a few open issues, such as how >>> to manage namespace conflicts (e.g., the fact that a deleted "foo" >>> branch can conflict with a new "foo/bar" branch). >> >> I prefer to think of a remote branch and its local copy as the same >> thing, which are physically different only because of current real >> world/hardware/software limitations, which make it necessary to keep >> a local cache of remote data. With this approach, reflogs should be >> deleted with the branch, and there will be no namespace conflicts. > It appears, the distributed nature of a DVCS did not fully sink into > your mindset yet. ;-) > Looks like you mentally treat a Git remote as a thing being used to > access a centralized "reference" server which maintains a master copy > of a repository, of which you happen to also have a local copy. > Then it's quite logically to think that if someone deleted a branch in > the master copy, everyone "downstream" should have the same > remote branch deleted to be in sync with that master copy. > But this is not the only way to organize your work. > You could fetch from someone else's repository and be interested in > their branch "foo", but think what happens when you fetch next time from > that repo and see Git happily deleting your local branch thatremote/foo > simply because someone with push access deleted that branch from the > repo. This might *not* be what you really want or expect. But this is true that the object store of Git can be viewed as a single centralized repository. The fact that not everybody has access to every object in Git is a limitation and not a benefit. These are the branches which are individual, and i do not think it is a good habit to treat every reference that was ever fetched with "git fetch" as your own, and put reflogs of all fetched remote branches under Git version control :D. If i care about "thatremote/foo" branch, i "track" it, i do not plan to go through reflogs if it is rebased. Alexey.-- 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