On 08/09, Junio C Hamano wrote:
> Thomas Gummerer <t.gummerer@xxxxxxxxx> writes:
>
> > Make git read the resolve-undo data from the index.
> >
> > Since the resolve-undo data is joined with the conflicts in
> > the ondisk format of the index file version 5, conflicts and
> > resolved data is read at the same time, and the resolve-undo
> > data is then converted to the in-memory format.
>
> This, and the next one, are both about reading extension data from
> the v2 formatted index, no?
Yes, exactly.
> Again, mild NAK.
>
> I think it is a lot more logical for the v5 code to read data stored
> in the resolve-undo and cache-tree extensions using the public API
> just like other users of these data do, and write out whatever in a
> way that is specific to the v5 index format.
>
> If the v5 codepath needs some information that is not exposed to
> other users of istate->resolve_undo and istate->cache_tree, then the
> story is different, but I do not think that is the case.
Sorry it's not clear to me what you mean with using the public API here.
Do you mean using resolve_undo_write() and resolve_undo_read()? I
wouldn't think those two methods would be really useful, as they expect
the data mangled in to a char* or return it as struct strbuf*. And I
don't see the other methods doing something more useful. Or I could
use the resolve-undo string_list directly, and just move the function
to read-cache-v5.c, or am I missing something here?
> >
> > Helped-by: Thomas Rast <trast@xxxxxxxxxxxxxxx>
> > Signed-off-by: Thomas Gummerer <t.gummerer@xxxxxxxxx>
> > ---
> > read-cache-v5.c | 1 +
> > resolve-undo.c | 36 ++++++++++++++++++++++++++++++++++++
> > resolve-undo.h | 2 ++
> > 3 files changed, 39 insertions(+)
> >
> > diff --git a/read-cache-v5.c b/read-cache-v5.c
> > index ec1201d..b47398d 100644
> > --- a/read-cache-v5.c
> > +++ b/read-cache-v5.c
> > @@ -494,6 +494,7 @@ static struct directory_entry *read_entries(struct index_state *istate,
> > int i;
> >
> > conflict_queue = read_conflicts(de, mmap, mmap_size, fd);
> > + resolve_undo_convert_v5(istate, conflict_queue);
> > for (i = 0; i < de->de_nfiles; i++) {
> > ce = read_entry(de,
> > entry_offset,
> > diff --git a/resolve-undo.c b/resolve-undo.c
> > index 72b4612..f96c6ba 100644
> > --- a/resolve-undo.c
> > +++ b/resolve-undo.c
> > @@ -170,3 +170,39 @@ void unmerge_index(struct index_state *istate, const char **pathspec)
> > i = unmerge_index_entry_at(istate, i);
> > }
> > }
> > +
> > +void resolve_undo_convert_v5(struct index_state *istate,
> > + struct conflict_entry *ce)
> > +{
> > + int i;
> > +
> > + while (ce) {
> > + struct string_list_item *lost;
> > + struct resolve_undo_info *ui;
> > + struct conflict_part *cp;
> > +
> > + if (ce->entries && (ce->entries->flags & CONFLICT_CONFLICTED) != 0) {
> > + ce = ce->next;
> > + continue;
> > + }
> > + if (!istate->resolve_undo) {
> > + istate->resolve_undo = xcalloc(1, sizeof(struct string_list));
> > + istate->resolve_undo->strdup_strings = 1;
> > + }
> > +
> > + lost = string_list_insert(istate->resolve_undo, ce->name);
> > + if (!lost->util)
> > + lost->util = xcalloc(1, sizeof(*ui));
> > + ui = lost->util;
> > +
> > + cp = ce->entries;
> > + for (i = 0; i < 3; i++)
> > + ui->mode[i] = 0;
> > + while (cp) {
> > + ui->mode[conflict_stage(cp) - 1] = cp->entry_mode;
> > + hashcpy(ui->sha1[conflict_stage(cp) - 1], cp->sha1);
> > + cp = cp->next;
> > + }
> > + ce = ce->next;
> > + }
> > +}
> > diff --git a/resolve-undo.h b/resolve-undo.h
> > index 8458769..ab660a6 100644
> > --- a/resolve-undo.h
> > +++ b/resolve-undo.h
> > @@ -13,4 +13,6 @@ extern void resolve_undo_clear_index(struct index_state *);
> > extern int unmerge_index_entry_at(struct index_state *, int);
> > extern void unmerge_index(struct index_state *, const char **);
> >
> > +extern void resolve_undo_convert_v5(struct index_state *, struct conflict_entry *);
> > +
> > #endif
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html