.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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
15 matches
Mail list logo
