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

2012-08-10 Thread Thomas Gummerer 
On 08/09, Junio C Hamano wrote:
 Thomas Gummerer t.gumme...@gmail.com writes:
 
  On 08/09, Junio C Hamano wrote:
  Thomas Gummerer t.gumme...@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.
 
  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()?
 
 The code that reads from istate-resolve_undo is fine to do the v5
 specific conversion, but it does not belong to resolve-undo.c file
 which is about the resolve-undo extension.  Moving it to v5 specific
 file you added for this topic, read-cache-v5.c, and everything looks
 more logical.  When we taught ls-files to show the paths with
 resolve-undo data, we didn't add any function to resolve-undo.c that
 does ls-files's work for it.  Instead, ls-files just uses the public
 API (the data structure you find at the_index.resolve_undo is part
 of the API) to find what it needs to learn, and I think v5 code can
 do the same.
 
 then the story is different comment refers to a possibilty that
 v5 code might need something more than callers outside resolve-undo.c
 can find from its public interface, but I do not think it is the
 case.

Ok, thanks for the clarification, will change it for the re-roll.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-08-09 Thread Junio C Hamano 
Thomas Gummerer t.gumme...@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?

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.


 Helped-by: Thomas Rast tr...@student.ethz.ch
 Signed-off-by: Thomas Gummerer t.gumme...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-08-09 Thread Thomas Gummerer 
On 08/09, Junio C Hamano wrote:
 Thomas Gummerer t.gumme...@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.

 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 tr...@student.ethz.ch
  Signed-off-by: Thomas Gummerer t.gumme...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-08-09 Thread Junio C Hamano 
Thomas Gummerer t.gumme...@gmail.com writes:

 On 08/09, Junio C Hamano wrote:
 Thomas Gummerer t.gumme...@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.

 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()?

The code that reads from istate-resolve_undo is fine to do the v5
specific conversion, but it does not belong to resolve-undo.c file
which is about the resolve-undo extension.  Moving it to v5 specific
file you added for this topic, read-cache-v5.c, and everything looks
more logical.  When we taught ls-files to show the paths with
resolve-undo data, we didn't add any function to resolve-undo.c that
does ls-files's work for it.  Instead, ls-files just uses the public
API (the data structure you find at the_index.resolve_undo is part
of the API) to find what it needs to learn, and I think v5 code can
do the same.

then the story is different comment refers to a possibilty that
v5 code might need something more than callers outside resolve-undo.c
can find from its public interface, but I do not think it is the
case.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-08-08 Thread Thomas Gummerer 
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.

Helped-by: Thomas Rast tr...@student.ethz.ch
Signed-off-by: Thomas Gummerer t.gumme...@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
-- 
1.7.10.GIT

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html