[prev in list] [next in list] [prev in thread] [next in thread]
List: git
Subject: Re: Prepare "git-merge-tree" for future work
From: Junio C Hamano <junkio () cox ! net>
Date: 2006-06-30 20:52:27
Message-ID: 7vbqsagyd0.fsf () assigned-by-dhcp ! cox ! net
[Download RAW message or body]
Linus Torvalds <torvalds@osdl.org> writes:
> In contrast, the ones to diff_filespec I've never really used, and I did
> not want to compare blob objects, I very much wanted to compare in-memory
> buffers (_and_ potentially blobs).
>
> So if you can show an easy example of how to populate a set of filespec
> pairs (not with blobs - with in-memory generated data) and insert them
> onto the lists, that would be good.
Ah, I see. Your origin() function always returns a in-core
buffer from an existing blob (or NULL if it is a new file) but
result() returns either an existing blob resulting from the
tree-level merge, or a 3-way content merge result that does not
have an existing blob, and it is not obvious how to express the
latter as a filespec (all other cases you can stuff the blob
object name in the sha1[] member and if you choose to do the
read_sha1_file() yourself store the result in data member or you
can let diff_populate_filespec() read the data when diff
machinery needs it).
I think a filespec that has 0{40} sha1, with data already
populated and should_free/should_munmap members both set to
false might work for the in-memory data but I haven't tried.
I'd take the hint, and I will (eventually) take a look at it
if nobody beats me to it, but most likely not now, sorry.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic