On Tue, Apr 30, 2013 at 02:32:33AM +0200, Johan Herland wrote: > On Mon, Apr 29, 2013 at 11:40 PM, Adam Spiers <g...@adamspiers.org> wrote:
[snipped] > > IMHO the more similar the merge's user experience is to a standard > > merge, the better, since that would minimise the number of merging > > workflows the user needs to learn. > > > > On this theme, I think ideally rebase should be supported too, and > > IMHO the general discussion about rebase vs. merge is mostly about the > shape of the resulting history. When it comes to notes, I have yet to > see a use case where anybody really cares about the shape of the notes > history, and hence I don't yet see how rebase would be useful for > notes. In fact, it rather seems some people are more interested in > storing their notes trees without any history at all (ISTR a > discussion regarding the notes-cache feature, where we did NOT want to > keep earlier versions of the cache alive). That's a fair point; lack of rebase is certainly not a showstopper. In contrast, in our use case, a total lack of history could be quite annoying. > > I also have to manually update the fake tracking "branch": > > > > git update-ref refs/notes/$remote/$GIT_NOTES_REF > > refs/notes/$GIT_NOTES_REF > > > > # or if I want to make really sure this only happens if the push worked > > git fetch $remote > > refs/notes/$GIT_NOTES_REF:refs/notes/$remote/$GIT_NOTES_REF > > > > That's pretty ugly. Couldn't we instead just reuse the existing > > mechanisms? > > > > remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* > > remote.origin.fetch=+refs/notes/*:refs/note-remotes/origin/* > > The remote refs namespace idea aims to solve this by providing refspecs like > > remote.origin.fetch=+refs/heads/*:refs/remotes/origin/heads/* > remote.origin.fetch=+refs/tags/*:refs/remotes/origin/tags/* > remote.origin.fetch=+refs/notes/*:refs/remotes/origin/notes/* > remote.origin.fetch=+refs/replace/*:refs/remotes/origin/replace/* > etc. > > I'm currently working on some patches to make git work well in repos > with those kinds of refspecs. I see that as the first step on the way > to properly supporting remote ref namespaces. > > > branch.notes/commits.remote=origin > > branch.notes/commits.merge=refs/notes/commits > > This looks like an natural extension of the branch upstream mechanism > for notes. Personally, I'd rather have it look more like this: > > [notes "commits"] > remote = origin > merge = refs/notes/commits > > or, in your notation: > > notes.commits.remote=origin > notes.commits.merge=refs/notes/commits Ahah yes, that's nicer. Thanks for the reply! -- 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
