On Fri, Jan 22, 2016 at 12:53 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > This uses _all_ merge notes attached to _any_ commit in the history, > without even checking if the commit is involved in the current merge > being done? How would that be useful? > > I also suspect that the data structure to keep track renames by > using notes needs a better design. You seem to have a note per > commit and one note records a set of "this goes to that", and > that is the reason why you need to discriminately read everything > under the sun. > > I think the index into the notes tree for the purpose of this use > case should not be "which commit records this set of renames?", > but by "what is the destination blob of possible rename > operations?". IOW, if a path that held blob X was moved to > another path that holds blob Z in commit A, and if a path that > held blob Y was moved to another path that holds blob Z in commit > B, attach a note to blob Z that records "moved from X in A" and > "moved from Y in B". This is exactly the output after merge_rename_notes() is done. A bunch of "rename this blob to that blob" pairs. The problem with indexing notes tree by blob is how the user will manage it. From the user perspective, I think it's natural to think "I have made this commit that renames this path to that path. But Git does not recognize it. I need to correct it by adding a note to the commit". The notes tree saves exactly that. Reading and updating can be done with existing tools. Exchanging git notes is something we have been avoiding looking at, but per-commit notes would make it easier to exchange too, I think. The information in that form may not be the best way to be consumed by Git. But that is what cache is for. We can either generate a secondary notes tree, indexed by blob, or naively a big "blob to blob" rename file that I did in this patch. But it does not have to be visible to the user. If notes-indexed-by-blob is exposed to the user, I think we need some more helper tools to edit and view them because blob SHA-1 is not something the user deals with, normally. It feels not as easy as editing a simple text file, to me. -- Duy -- 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