On Wed, Jul 29, 2015 at 7:01 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > >> I believe it is a bad compromise. It complicates the code, and it >> provides a concurrent notes merges that is unnecessarily tied to (and >> dependent on) worktrees. For example, if I wanted to perform N >> concurrent notes merges in a project that happens to have a huge >> worktree, I would now have to create N copies of the huge worktree... > > Who said worktree has to be populated? You should be able to have > an absolutely empty checkout just like "clone --no-checkout". IMHO that's an insane workaround that only serves to highlight the conceptual problems of binding notes merges (as they are implemented today) to worktrees. I'm much more excited about Michael's idea of formalising the concept of a notes tree checkout (although as already discussed, checking out a notes tree is different from checking out a "regular" tree). Then, a notes merge (as you already suggested) should be implemented by creating a linked worktree whose HEAD is the notes ref being merged into. I believe there are potential complications here as well (where a notes-merge might behave differently from a regular merge), but those should be solvable. But, whatever. This is unrelated to David's current effort, and I don't want to hold that up, so please move along, nothing to see here. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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