Re: Feature request: fetch --prune by default
I would use the config feature to turn on --prune for fetch, and was surprised that it wasn't available - I hit this thread because I figured I somehow missed it in the config docs. Having both global and local settings seems nice. -- View this message in context: http://git.661346.n2.nabble.com/Feature-request-fetch-prune-by-default-tp7563241p7590048.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, Aug 16, 2012 at 04:22:54PM -0700, Junio C Hamano wrote: In the meantime, would it make sense to introduce a configuration variable to request this behavior? If so, should it be global? fetch.prune = always or per-remote? remote.name.prune = always The global option seems to be more in line with what Alexey is looking for, but the per-remote one is similar to the tagopt option, which is a similar idea. Of course, this might be just a waste of time to introduce a feature no one would use, in which case we obviously should not introduce such options. I was reading through the backlog today and noticed that this topic veered into the reflog graveyard tangent. I wasn't involved in the main topic, but I think having both configuration variables, remote.remote.prune taking precedence over fetch.prune, as long as we make sure fetch --no-prune will override any configured default, is not a bad thing per-se. As long as the users who elect to use this feature are aware of the pruning of the refs and logs, that is, but branch [-r] -d has been the way to lose both the branch and its log for a long time, so I do not see a big issue there, either. The log graveyard is an independently interesting idea, which I may ping separately, but I consider it pretty much orthogonal to this particular topic. Yeah, I think that is sensible. As long as the _default_ is not to prune, and people are making a conscious choice to prune, I don't see a problem at all. The log graveyard is orthogonal to the proposed option, but I think it would be a necessary step before flipping the default for that option to true. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
Dan Johnson computerdr...@gmail.com writes: On Thu, Jul 19, 2012 at 7:55 AM, Jeff King p...@peff.net wrote: ... 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). In the meantime, would it make sense to introduce a configuration variable to request this behavior? If so, should it be global? fetch.prune = always or per-remote? remote.name.prune = always The global option seems to be more in line with what Alexey is looking for, but the per-remote one is similar to the tagopt option, which is a similar idea. Of course, this might be just a waste of time to introduce a feature no one would use, in which case we obviously should not introduce such options. I was reading through the backlog today and noticed that this topic veered into the reflog graveyard tangent. I wasn't involved in the main topic, but I think having both configuration variables, remote.remote.prune taking precedence over fetch.prune, as long as we make sure fetch --no-prune will override any configured default, is not a bad thing per-se. As long as the users who elect to use this feature are aware of the pruning of the refs and logs, that is, but branch [-r] -d has been the way to lose both the branch and its log for a long time, so I do not see a big issue there, either. The log graveyard is an independently interesting idea, which I may ping separately, but I consider it pretty much orthogonal to this particular topic. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
Alexey Muranov alexey.mura...@gmail.com writes: On 20 Jul 2012, at 09:11, Johannes Sixt wrote: ... Note the difference between tracking branch and remote tracking branch! The remote tracking branches are the refs in the refs/remotes/ hierarchy. The tracking branches are your own local branches that you have created with 'git branch topic thatremote/topic' (or perhaps 'git checkout -b'). The paragraph talks about the latter. Hannes, thanks for the explanation, so i was confused once again. Various blog posts do not make the terminology clear, for example http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html sais that there are only two types of branches: local, and remote-tracking... ... I think i was also misguided by Konstantin, who wrote that you create a remote tracking branch when you intend to actually *develop* something on that branch :). I was re-reading the backlog today, and saw this topic fizzled out. We obviously cannot fix third-party documentation that teach lies to people, but is there something we can do to improve our own documentation with respect to this confusion? As I wrote it elsewhere, I try to avoid the bareword tracking in general, and call the local branch you build on something like your 'next' branch that forked from origin/next remote tracking branch myself. Perhaps we can start from checking the documentation with such a phrasing discipline? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
Am 7/19/2012 23:20, schrieb Alexey Muranov: On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote: On Thu, 19 Jul 2012 18:21:21 +0200 Alexey Muranov alexey.mura...@gmail.com 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. Note the difference between tracking branch and remote tracking branch! The remote tracking branches are the refs in the refs/remotes/ hierarchy. The tracking branches are your own local branches that you have created with 'git branch topic thatremote/topic' (or perhaps 'git checkout -b'). The paragraph talks about the latter. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote: i would like `git fetch --prune remote` to be the default behavior of `git fetch remote` In fact, i think this is the only reasonable behavior. Keeping copies of deleted remote branches after `fetch` is more confusing than useful. I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. 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). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, Jul 19, 2012 at 7:55 AM, Jeff King p...@peff.net wrote: On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote: i would like `git fetch --prune remote` to be the default behavior of `git fetch remote` In fact, i think this is the only reasonable behavior. Keeping copies of deleted remote branches after `fetch` is more confusing than useful. I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. 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). In the meantime, would it make sense to introduce a configuration variable to request this behavior? If so, should it be global? fetch.prune = always or per-remote? remote.name.prune = always The global option seems to be more in line with what Alexey is looking for, but the per-remote one is similar to the tagopt option, which is a similar idea. Of course, this might be just a waste of time to introduce a feature no one would use, in which case we obviously should not introduce such options. -- -Dan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
Dan Johnson computerdr...@gmail.com wrote: In the meantime, would it make sense to introduce a configuration variable to request this behavior? fetch.prune = always Of course, this might be just a waste of time to introduce a feature no one would use, in which case we obviously should not introduce such options. I would use it. -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On 19 Jul 2012, at 13:55, Jeff King wrote: On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote: i would like `git fetch --prune remote` to be the default behavior of `git fetch remote` In fact, i think this is the only reasonable behavior. Keeping copies of deleted remote branches after `fetch` is more confusing than useful. I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. 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. 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. 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. Alexey.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On 19 Jul 2012, at 13:55, Jeff King wrote: I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. If i understand correctly, existence of a reflog entry will not stop gc from removing a commit, will it? In this case, if a remote branch was rebased or reset, commits can be lost anyway, right? Alexey.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, Jul 19, 2012 at 12:40 PM, Alexey Muranov alexey.mura...@gmail.com wrote: On 19 Jul 2012, at 13:55, Jeff King wrote: I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. If i understand correctly, existence of a reflog entry will not stop gc from removing a commit, will it? In this case, if a remote branch was rebased or reset, commits can be lost anyway, right? From the git-gc man page: git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound). So yes, a reflog entry does stop gc from removing objects, including commits. It will expire old reflog entries (90 days by default) though, so it's not like they will stay around forever. -- -Dan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On 19 Jul 2012, at 18:48, Dan Johnson wrote: From the git-gc man page: git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound). So yes, a reflog entry does stop gc from removing objects, including commits. It will expire old reflog entries (90 days by default) though, so it's not like they will stay around forever. Dan, thanks for the explanation. Alexey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, 19 Jul 2012 18:21:21 +0200 Alexey Muranov alexey.mura...@gmail.com 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. 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. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote: On Thu, 19 Jul 2012 18:21:21 +0200 Alexey Muranov alexey.mura...@gmail.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
I just want to correct my mistake in what i've just sent: On 19 Jul 2012, at 23:20, Alexey Muranov wrote: 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. I do not develop on tracking branches. Of course i develop on tracking branches, i just got confused once again by pull/push thing: i develop on branches that track origin, not upstream. I think they should be called remotely tracked branches, so there would be remote tracking branches for pull and remotely tracked branches for push. Alexey.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
