46.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.kerne
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..prune = always
> >
>
Alexey Muranov 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 y
Dan Johnson writes:
> On Thu, Jul 19, 2012 at 7:55 AM, Jeff King 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
>
On 20 Jul 2012, at 09:11, Johannes Sixt wrote:
> 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
>>> wrote:
>>>
>>> [...]
I do not still understand very well some aspects of Git,
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
>> wrote:
>>
>> [...]
>>> I do not still understand very well some aspects of Git, like the
>>> exact purpose of "remote tracking branches"
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
On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote:
> On Thu, 19 Jul 2012 18:21:21 +0200
> Alexey Muranov 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.
On Thu, 19 Jul 2012 18:21:21 +0200
Alexey Muranov 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.
An
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-track
On Thu, Jul 19, 2012 at 12:40 PM, Alexey Muranov
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
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 destructi
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 `
>>
>> to be the default behavior of
>>
>> `git fetch `
>>
>> In fact, i think this is the only reasonable behavior.
>> Keeping copies of de
Dan Johnson 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
On Thu, Jul 19, 2012 at 7:55 AM, Jeff King wrote:
> On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
>
>> i would like
>>
>> `git fetch --prune `
>>
>> to be the default behavior of
>>
>> `git fetch `
>>
>> In fact, i think this is the only reasonable behavior.
>> Keeping copies of
On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
> i would like
>
> `git fetch --prune `
>
> to be the default behavior of
>
> `git fetch `
>
> In fact, i think this is the only reasonable behavior.
> Keeping copies of deleted remote branches after `fetch` is more confusing
> t
Hello,
i would like
`git fetch --prune `
to be the default behavior of
`git fetch `
In fact, i think this is the only reasonable behavior.
Keeping copies of deleted remote branches after `fetch` is more confusing than
useful.
(Excuse me if this question has already been discussed.)
Thank yo
17 matches
Mail list logo
