On Wed, Aug 27, 2014 at 11:11 PM, Junio C Hamano wrote:
> I was asking for an answer more from what you know about the code.
> For example, would read_index_unmerged() choke if the index has two
> or more stage #1 (or stage #3) entries for the same path (provided
> that the index is otherwise norm
Jaime Soriano Pastor writes:
> On Tue, Aug 26, 2014 at 7:43 PM, Junio C Hamano wrote:
>> Does the current codebase choke with such entries in the index file,
>> like you saw in your index file with both stage #0 and stage #1
>> entries?
>
> Not sure, I couldn't reproduce an scenario with an inde
On Tue, Aug 26, 2014 at 7:43 PM, Junio C Hamano wrote:
> Does the current codebase choke with such entries in the index file,
> like you saw in your index file with both stage #0 and stage #1
> entries?
Not sure, I couldn't reproduce an scenario with an index with multiple
entries in the same sta
Jaime Soriano Pastor writes:
> On Tue, Aug 26, 2014 at 6:53 PM, Junio C Hamano wrote:
>>
>> Yes---that is what I meant by the "virtual stuff". Unlike resolve
>> work by Daniel (around Sep 2005 $gmane/8088) that tried to use
>> multiple ancestors directly in a single merge, recursive limits
>> i
On Tue, Aug 26, 2014 at 6:53 PM, Junio C Hamano wrote:
>
> Yes---that is what I meant by the "virtual stuff". Unlike resolve
> work by Daniel (around Sep 2005 $gmane/8088) that tried to use
> multiple ancestors directly in a single merge, recursive limits
> itself to repeated use of pairwise merg
Jeff King writes:
>> With "natively" do you mean some internal state that is never written
>> into the index? If this were the case then there wouldn't be any
>> problem with the restriction when reading the index file.
>
> FWIW, that was my question on reading Junio's response, too.
The current
On Tue, Aug 26, 2014 at 02:08:35PM +0200, Jaime Soriano Pastor wrote:
> > That is how we natively (read: not with the funky "virtual" stuff
> > merge-recursive does) express a merge with multiple merge bases.
> > You also should be able to read this in the way how "git merge" invokes
> > merge str
On Mon, Aug 25, 2014 at 10:52 PM, Junio C Hamano wrote:
> On Mon, Aug 25, 2014 at 12:44 PM, Jeff King wrote:
>> For my own curiosity, how do you get into this situation, and what does
>> it mean to have multiple stage#1 entries for the same path? What would
>> "git cat-file :1:path" output?
>
> T
On Mon, Aug 25, 2014 at 12:44 PM, Jeff King wrote:
> For my own curiosity, how do you get into this situation, and what does
> it mean to have multiple stage#1 entries for the same path? What would
> "git cat-file :1:path" output?
That is how we natively (read: not with the funky "virtual" stuff
On Mon, Aug 25, 2014 at 7:21 PM, Junio C Hamano wrote:
> Jaime Soriano Pastor writes:
>
>> Subject: Re: [PATCH 1/2] Check order when reading index
>
> Please be careful when crafting the commit title. This single line
> will be the only one that readers will have to identi
On Mon, Aug 25, 2014 at 10:21:58AM -0700, Junio C Hamano wrote:
> > + if (ce_stage(ce) >= ce_stage(next_ce))
> > + die("Unordered stage entries for '%s'",
> > + ce->name);
>
> Not quite. We do allow multiple higher stage entries; having two o
Jaime Soriano Pastor writes:
> Subject: Re: [PATCH 1/2] Check order when reading index
Please be careful when crafting the commit title. This single line
will be the only one that readers will have to identify the change
among hundreds of entries in "git shortlog" output when
Signed-off-by: Jaime Soriano Pastor
---
read-cache.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index 7f5645e..c1a9619 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1438,6 +1438,21 @@ static struct cache_entry *create_from_disk(struct
o
13 matches
Mail list logo
