git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH/RFC v3 07/13] Read resolve-undo data

From
Thomas Gummerer <t.gummerer@gmail.com>
Date
Aug 9, 2012, 23:23 UTC
Message-ID
<20120809232320.GD5127@tommy-fedora.scientificnet.net>
In-Reply-To
<7vk3x7n0fl.fsf@alter.siamese.dyndns.org>
On 08/09, Junio C Hamano wrote:
Show 11 quoted lines
> Thomas Gummerer <t.gummerer@gmail.com> 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.
Show 10 quoted lines
> 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?

Show 76 quoted lines
> >
> > Helped-by: Thomas Rast <trast@student.ethz.ch>
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> > ---
> >  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
Previous: Junio C HamanoNext: Junio C Hamano
Message 26 of 34 in “Introduce index file format version 5”
  1. 0/13 Introduce index file format version 5Thomas Gummerer, Aug 8, 2012
  2. 01/13 Move index v2 specific functions to their own fileThomas Gummerer, Aug 8, 2012
  3. Nguyen Thai Ngoc DuyAug 8, 2012
  4. Thomas GummererAug 8, 2012
  5. Junio C HamanoAug 9, 2012
  6. Thomas GummererAug 9, 2012
  7. Junio C HamanoAug 10, 2012
  8. Nguyen Thai Ngoc DuyAug 10, 2012
  9. Thomas RastAug 10, 2012
  10. Junio C HamanoAug 10, 2012
  11. Thomas GummererAug 10, 2012
  12. 02/13 t2104: Don't fail for index versions other than [23]Thomas Gummerer, Aug 8, 2012
  13. 03/13 t3700: Avoid interfering with the racy codeThomas Gummerer, Aug 8, 2012
  14. 04/13 Add documentation of the index-v5 file formatThomas Gummerer, Aug 8, 2012
  15. Junio C HamanoAug 9, 2012
  16. Thomas GummererAug 9, 2012
  17. Junio C HamanoAug 9, 2012
  18. 05/13 Make in-memory format aware of stat_crcThomas Gummerer, Aug 8, 2012
  19. 06/13 Read index-v5Thomas Gummerer, Aug 8, 2012
  20. Nguyen Thai Ngoc DuyAug 8, 2012
  21. Johannes SixtAug 8, 2012
  22. Junio C HamanoAug 8, 2012
  23. Thomas GummererAug 8, 2012
  24. 07/13 Read resolve-undo dataThomas Gummerer, Aug 8, 2012
  25. Junio C HamanoAug 9, 2012
  26. Thomas GummererAug 9, 2012
  27. Junio C HamanoAug 10, 2012
  28. Thomas GummererAug 10, 2012
  29. 08/13 Read cache-tree in index-v5Thomas Gummerer, Aug 8, 2012
  30. 09/13 Write index-v5Thomas Gummerer, Aug 8, 2012
  31. 10/13 Write index-v5 cache-tree dataThomas Gummerer, Aug 8, 2012
  32. 11/13 Write resolve-undo data for index-v5Thomas Gummerer, Aug 8, 2012
  33. 12/13 update-index.c: always rewrite the index when index-version is givenThomas Gummerer, Aug 8, 2012
  34. 13/13 p0002-index.sh: add perf test for the index formatsThomas Gummerer, Aug 8, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.