Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-03-07 Thread Junio C Hamano
Torsten Bögershausen writes: > The major question, at least on my side, is where to hook in > "can_clobber()" ? There are different ways the existing commands ensure that they do not lose local modifications. * Some (like unpack-trees code that is used by "merge") do refresh_cache() upfront

Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-03-07 Thread Torsten Bögershausen
On 03/07/2016 09:51 AM, Junio C Hamano wrote: Junio C Hamano writes: Perhaps we can introduce a new function can_clobber() that has the same function signature as ce_uptodate() and update the callers in apply and unpack-trees (there may be others) to call it instead when they want to see if th

Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-03-07 Thread Junio C Hamano
Junio C Hamano writes: > Perhaps we can introduce a new function can_clobber() that has the > same function signature as ce_uptodate() and update the callers in > apply and unpack-trees (there may be others) to call it instead when > they want to see if they can clobber the working tree file that

Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-03-07 Thread Junio C Hamano
Junio C Hamano writes: > Besides, it is OK if your status and diff says your worktree is > dirty immediately after cloning in such a broken situation, I would > think. In fact, it may even be preferable to do so, in order to > indicate that there is something unusual going on. The above needs a

Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-03-05 Thread Junio C Hamano
Torsten Bögershausen writes: >> When the user has CRLF data in the index and the user tell the >> attribute system so that the next "add" would result in "fixing" the >> indexed lines to be terminated with LF, "diff-files" _should_ show >> that correction as a change, I think. > Fair enough. > Th

Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-03-05 Thread Torsten Bögershausen
> I do not think I can endorse this approach, as I cannot explain why > it could possibly make sense to treat as if CRLF conversion is > somehow special among all the convert_to_git()/convert_to_worktree() > conversions, which your patch does to the diff code. > > Comparisons between contents from

Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-03-05 Thread Junio C Hamano
Torsten Bögershausen writes: > On 11.02.16 19:49, Junio C Hamano wrote: > >> I did not continue the approach I illustrated because I realized and >> finally convinced myself that touching ce_compare_data() is a wrong >> solution--it breaks "diff-files". >> >> Imagine if you have contents in the i

Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-03-04 Thread Torsten Bögershausen
On 11.02.16 19:49, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen >> >> We define the working tree file is clean if either: >> >> * the result of running convert_to_git() on the working tree >> contents matches what is in the index (because that would mean >>

Re: [PATCH 1/3] git reset --hard gives clean working tree

2016-02-11 Thread Junio C Hamano
tbo...@web.de writes: > From: Torsten Bögershausen > > We define the working tree file is clean if either: > > * the result of running convert_to_git() on the working tree > contents matches what is in the index (because that would mean > doing another "git add" on the path is a no-op);

[PATCH 1/3] git reset --hard gives clean working tree

2016-02-11 Thread tboegi
From: Torsten Bögershausen We define the working tree file is clean if either: * the result of running convert_to_git() on the working tree contents matches what is in the index (because that would mean doing another "git add" on the path is a no-op); OR * the result of running conv