git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] Reorganize read-tree
@ 2005-08-31  3:48 Daniel Barkalow
  2005-08-31  3:49 ` [PATCH 1/2] Object model additions for read-tree Daniel Barkalow
                   ` (6 more replies)
  0 siblings, 7 replies; 11+ messages in thread
From: Daniel Barkalow @ 2005-08-31  3:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Linus Torvalds

I got mostly done with this before Linus mentioned the possibility of
having multiple index entries in the same stage for a single path. I
finished it anyway, but I'm not sure that we won't want to know which of
the common ancestors contributed which, and, if some of them don't have a
path, we wouldn't be able to tell. The other advantages I see to this
approach are:

 - it uses the more common parser of tree objects, moving toward having
   only one (diff-cache still uses read_tree(), however).
 - it doesn't need to do very complicated things with the index; the
   original read-tree does a bunch of stuff with an index with a gap in
   the middle containing obsolete entries.
 - it uses a much simpler method of finding directory/file conflicts,
   which is possible because the struct trees represent directories as
   well as files.
 - it deals with each path completely before going on to the next one,
   instead of first dealing with each input tree and then dealing with
   each path.
 - it removes a lot of intimate knowledge of the index structure from the
   program.

The general idea is that it figures out what trees you want, and then
iterates through the entry lists together, recursing into directories, and
calls the merge function with an array of the index entries (not yet
added) for the path in each tree; the merge function adds the appropriate
things to the index.

Note that this set doesn't include calling merge functions with multiple
ancestors or remotes; that can be done when we've decided on whether my
version of read-tree is worth using.

There are various potential refinements, plus removing a bunch of memory
leaks, still to do, but I think this is sufficiently close to review.

(Refinements: it ought to have two indices in memory, the old and the new,
and never modify the old and only append to the new, to simplify things
further; it ought to use a sentinal value for the index entry to indicate
that there is something in the tree to conflict with there being a file at
the given path; the --emu23 logic could be clearer)

The first patch adds a few functions to the object library.
The second patch changes read-tree around; It is essentially a rewrite,
except for the merge functions and main().

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2005-09-05  2:52 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-31  3:48 [PATCH 0/2] Reorganize read-tree Daniel Barkalow
2005-08-31  3:49 ` [PATCH 1/2] Object model additions for read-tree Daniel Barkalow
2005-08-31  3:49 ` [PATCH] Change read-tree to merge before using the index Daniel Barkalow
2005-08-31  6:28 ` [PATCH 0/2] Reorganize read-tree Junio C Hamano
2005-08-31 16:56   ` Daniel Barkalow
2005-08-31 14:15 ` Catalin Marinas
2005-08-31 17:04   ` Daniel Barkalow
2005-08-31 16:57 ` [PATCH 1/2 (resend)] Object model additions for read-tree Daniel Barkalow
2005-08-31 16:57 ` [PATCH 2/2 (resend)] Change read-tree to merge before using the index Daniel Barkalow
2005-09-05  2:04 ` [PATCH 0/2] Reorganize read-tree Junio C Hamano
2005-09-05  2:55   ` Daniel Barkalow

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).