Yes, --index-info worked for this purpouse, thanks!
https://github.com/jsoriano/git/blob/remove-unmerged-index-entry/t/t9904-unmerged-file-with-merged-entry.sh#L25
I'll try to send the patches to the mailing lists later today or tomorrow.
On Mon, Aug 18, 2014 at 6:34 PM, Junio C Hamano wrote:
>
Jaime Soriano Pastor writes:
> I'd like to add some tests too for this, but I don't know how to
> reproduce this state with git commands only, is there any way to add
> entries to the index without checkings?
Perhaps feeding "update-index --index-info" four input lines would work?
--
To unsubscr
I'd like to add some tests too for this, but I don't know how to
reproduce this state with git commands only, is there any way to add
entries to the index without checkings?
Or maybe it could be done by creating a "test-" command that adds the
entries to an index?
Thanks.
On Fri, Aug 15, 2014 at
Jaime Soriano Pastor writes:
> On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano wrote:
>> Being a conservative, I'd rather avoid doing any magic during
>> read_cache() time. "ls-files -s" for example should show the four
>> stages so that the "broken" state can be inspected.
>>
> Well, only read_
On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano wrote:
> Being a conservative, I'd rather avoid doing any magic during
> read_cache() time. "ls-files -s" for example should show the four
> stages so that the "broken" state can be inspected.
>
Well, only read_cache_unmerged() is modified in the sen
Jaime Soriano Pastor writes:
> In the problematic cases I've seen (specially git add and git reset
> --hard) the final state of both, merged and unmerged files, is that
> only an entry in stage 0 exists.
> Also, the current implementation of git checkout -f silently removes
> higher stage entries
On Tue, Aug 12, 2014 at 8:39 PM, Junio C Hamano wrote:
>
> Jaime Soriano Pastor writes:
>
> > Wrong implementations of tools that modify the index can left
> > some files as merged and unmerged at the same time. Avoid undesiderable
> > behaviours by handling this situation.
>
> It is understandab
On Tue, Aug 12, 2014 at 8:31 PM, Junio C Hamano wrote:
>
> Jaime Soriano Pastor writes:
>
> > A file in the index can be left as merged and unmerged at the same time
> > by some tools as libgit2, this causes some undesiderable behaviours in git.
>
> Well, doesn't it mean that libgit2 is broken?
Jaime Soriano Pastor writes:
> Wrong implementations of tools that modify the index can left
> some files as merged and unmerged at the same time. Avoid undesiderable
> behaviours by handling this situation.
It is understandable that the way _you_ decided to "handle the
situation" is so obvious
Jaime Soriano Pastor writes:
> A file in the index can be left as merged and unmerged at the same time
> by some tools as libgit2, this causes some undesiderable behaviours in git.
Well, doesn't it mean that libgit2 is broken? Have you filed a bug
over there yet?
Having said that, protecting o
A file in the index can be left as merged and unmerged at the same time
by some tools as libgit2, this causes some undesiderable behaviours in git.
I have seen, at least, these behaviours:
- git reset --hard consuming 100% CPU and never ending
- git reset --hard consuming all memory in git < 2.0
-
Wrong implementations of tools that modify the index can left
some files as merged and unmerged at the same time. Avoid undesiderable
behaviours by handling this situation.
Signed-off-by: Jaime Soriano Pastor
---
read-cache.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff
12 matches
Mail list logo
