Tom Miller writes:
>> But what should happen when we do not give --prune to "git fetch" in
>> such a situation? Should it fail, because we still have frotz/nitfol
>> and we cannot create frotz without losing it?
>
> You talk about this to some extent in an email from 2009. I have linked
> it bel
On Wed, Dec 18, 2013 at 07:48:59PM -0600, Tom Miller wrote:
> I did not intend to introduce new lingo. I did some searching through
> history to see if something like this had been worked on before and
> I found a commit by Jeff King that introduced me the the idea of
> "DF conflicts"
I take all
Tom Miller writes:
> The commit below should be the same patch he tested. The test was added
> by him, and I made it part of this commit. Did I do this wrong?
No, no, no. All my questions were true questions, not complaints
veiled as rhetorical questions. Thanks for many pointers for
clarifica
On Wed, Dec 18, 2013 at 3:54 PM, Junio C Hamano wrote:
> Tom Miller writes:
>
>> When a branchname DF conflict occurs during a fetch,
>
> You may have started with a specific case in which you want to
> change the behaviour of current Git, so it may be clear what you
> meant by "branchname DF con
Tom Miller writes:
> When a branchname DF conflict occurs during a fetch,
You may have started with a specific case in which you want to
change the behaviour of current Git, so it may be clear what you
meant by "branchname DF conflict", but that is true for nobody other
than you who will read th
When a branchname DF conflict occurs during a fetch, --prune should
be able to fix it. When fetching with --prune, the fetching process
happens before pruning causing the branchname DF conflict to persist
and report an error. This patch prunes before fetching, thus
correcting DF conflicts during a
6 matches
Mail list logo
