{"thread":{"id":"33631","subject":"git-icing: sugary wrapper around git-cherry","startedAt":"2013-04-27T13:21:19Z","lastAt":"2013-09-21T17:25:19Z","messageCount":8,"participants":["Adam Spiers","Junio C Hamano","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"215701","messageId":"20130427132118.GA25295@pacific.linksys.moosehall","threadId":"33631","inReplyTo":null,"subject":"git-icing: sugary wrapper around git-cherry","fromName":"Adam Spiers","fromEmail":"git@adamspiers.org","sentAt":"2013-04-27T13:21:19Z","receivedAt":"2013-04-27T13:21:19Z","isPatch":false,"sender":{"key":"git@adamspiers.org","avatar":"https://avatars.githubusercontent.com/u/100738?v=4"},"body":"Hi all,\n\nI just wrote a wrapper around git cherry which adds a splash of\ncolour, and facilitates exclusion of commits which should never be\nupstreamed, by using a git-notes(1) namespace as a blacklist.\n\nIt's just a quick hack and Ruby probably won't be to everyone's taste,\nbut I thought I'd mention it just in case it's of use / interest.\n\n    https://github.com/aspiers/git-config/blob/master/bin/git-icing\n\nI'm not sure whether it would make sense to move this functionality\ninto git cherry itself.  Adding (optional) colour support would bring\nit in line with some of the other porcelain, I suppose.\n\nThere are other git utilities in that repository which may also be of\ninterest:\n\n    https://github.com/aspiers/git-config/blob/master/README.md\n\n(I do not claim that any of them are beautiful code, but they work for\nme ;-)\n\nRegards,\nAdam\n"},{"id":"215849","messageId":"20130429133205.GA4672@pacific.linksys.moosehall","threadId":"33631","inReplyTo":"20130427132118.GA25295@pacific.linksys.moosehall","subject":"git-rnotes: git-notes wrapper for sharing notes between repositories","fromName":"Adam Spiers","fromEmail":"git@adamspiers.org","sentAt":"2013-04-29T13:32:05Z","receivedAt":"2013-04-29T13:32:05Z","isPatch":false,"sender":{"key":"git@adamspiers.org","avatar":"https://avatars.githubusercontent.com/u/100738?v=4"},"body":"On Sat, Apr 27, 2013 at 02:21:19PM +0100, Adam Spiers wrote:\n> Hi all,\n> \n> I just wrote a wrapper around git cherry which adds a splash of\n> colour, and facilitates exclusion of commits which should never be\n> upstreamed, by using a git-notes(1) namespace as a blacklist.\n> \n> It's just a quick hack and Ruby probably won't be to everyone's taste,\n> but I thought I'd mention it just in case it's of use / interest.\n> \n>     https://github.com/aspiers/git-config/blob/master/bin/git-icing\n\n[snipped]\n\nI've just written another quick wrapper around 'git notes' which makes\nit less painless to share notes to and from remote repositories:\n\n    https://github.com/aspiers/git-config/blob/master/bin/git-rnotes\n\nThis makes sharing of notes as easy as:\n\n    git rnotes $remote push\n    git rnotes $remote fetch\n    git rnotes $remote merge\n    git rnotes $remote pull\n\nand was born from this discussion:\n\n    http://stackoverflow.com/questions/12055303/merging-git-notes-when-there-are-merge-conflicts-in-them/\n\nOnce the Great Refs Namespace Debate is resolved[0], would this kind\nof UI would be a candidate for pushing into git-notes itself?\n\nCheers,\nAdam\n\n[0] Maybe it has been already; I haven't been following closely.\n"},{"id":"215867","messageId":"20130429163909.GA19014@pacific.linksys.moosehall","threadId":"33631","inReplyTo":"20130429133205.GA4672@pacific.linksys.moosehall","subject":"improvements to checks for core.notesRef / GIT_NOTES_REF / --ref","fromName":"Adam Spiers","fromEmail":"git@adamspiers.org","sentAt":"2013-04-29T16:39:09Z","receivedAt":"2013-04-29T16:39:09Z","isPatch":false,"sender":{"key":"git@adamspiers.org","avatar":"https://avatars.githubusercontent.com/u/100738?v=4"},"body":"On Mon, Apr 29, 2013 at 02:32:05PM +0100, Adam Spiers wrote:\n> I've just written another quick wrapper around 'git notes' which makes\n> it less painless to share notes to and from remote repositories:\n> \n>     https://github.com/aspiers/git-config/blob/master/bin/git-rnotes\n> \n> This makes sharing of notes as easy as:\n> \n>     git rnotes $remote push\n>     git rnotes $remote fetch\n>     git rnotes $remote merge\n>     git rnotes $remote pull\n> \n> and was born from this discussion:\n> \n>     http://stackoverflow.com/questions/12055303/merging-git-notes-when-there-are-merge-conflicts-in-them/\n> \n> Once the Great Refs Namespace Debate is resolved[0], would this kind\n> of UI would be a candidate for pushing into git-notes itself?\n\nI just had a discussion on #git IRC with Thomas about how the above\nwrapper uses refs/notes/$remote/commits or similar to simulate a\nremote tracking branch for notes, and we agreed that it's not ideal\ndue to potential collisions if --ref=$remote or refs/notes/* are ever\nused.  As has probably been discussed already in the Great Debate,\nsomething like refs/remote-notes/ might be a better namespace; however\nthe current implementation of git notes prevents this:\n\n    static struct notes_tree *init_notes_check(const char *subcommand)\n    {\n            struct notes_tree *t;\n            init_notes(NULL, NULL, NULL, 0);\n            t = &default_notes_tree;\n\n            if (prefixcmp(t->ref, \"refs/notes/\"))\n                    die(\"Refusing to %s notes in %s (outside of refs/notes/)\",\n                        subcommand, t->ref);\n            return t;\n    }\n\nCan we relax this to \"refs/\", to allow better isolation of namespaces\nfor remote notes?  Also, the check is applied for GIT_NOTES_REF and\ncore.notesRef, but not for values passed via --ref.  Therefore I would\npropose that init_notes_check() is not only relaxed but also moved\nfrom builtin/notes.c to notes.c, so that it can be consumed by\ndefault_notes_ref().  Thoughts?\n\nAlso, are there any plans in the future for making \"git notes merge\"\nprovide an index, so that a proper 3-way merge with ancestor can be\ndone using git mergetool?\n\nCheers,\nAdam\n"},{"id":"215870","messageId":"7vmwshjm4j.fsf@alter.siamese.dyndns.org","threadId":"33631","inReplyTo":"20130429163909.GA19014@pacific.linksys.moosehall","subject":"Re: improvements to checks for core.notesRef / GIT_NOTES_REF / --ref","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T17:13:32Z","receivedAt":"2013-04-29T17:13:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Adam Spiers <git@adamspiers.org> writes:\n\n>     static struct notes_tree *init_notes_check(const char *subcommand)\n>     ...\n> Can we relax this to \"refs/\", to allow better isolation of namespaces\n> for remote notes?  Also, the check is applied for GIT_NOTES_REF and\n> core.notesRef, but not for values passed via --ref.  Therefore I would\n> propose that init_notes_check() is not only relaxed but also moved\n> from builtin/notes.c to notes.c, so that it can be consumed by\n> default_notes_ref().  Thoughts?\n\nSuch a policy decision at the application level should be done in\nbuiltin/notes.c, and not notes.c, I think.  It is OK to have a\nsharable check routine in notes.c and help different notes\napplications to implement their own sanity checking, though.  \"git\nnotes\" that operates only on local notes might restrict its\noperation to refs/notes, while \"git notes-merge\" may allow it to\nread from other hierarchies but still write only into refs/notes,\nfor example.\n\nI am not sure if it is a good idea in general to have a separate\nremotes-notes/ hierarchy in the first place, though.  Wouldn't the\nnotes be less like branches (private view) and more like tags\n(common world view)?\n\n> Also, are there any plans in the future for making \"git notes merge\"\n> provide an index, so that a proper 3-way merge with ancestor can be\n> done using git mergetool?\n\nAre we committed that all notes leaves must be blobs (I do not\npersonally mind it)?\n\nI do think we need a way to call a custom low level 3-way merge\ndriver once we identify which notes blobs correspond to each other\nwith what common ancestor notes blob while merging two notes trees.\n\nBut I do not think that \"an index\" that we use for the usual working\ntree merge is necessarily a good representation for driving such a\nll-merge driver and recording its result.  Each side likely has a\nnote for the same object to be merged in a different fan-out layout,\nand fan-out is merely a performance hack to spread the objects in\nsmaller trees.  As mergetools only work with the usual working tree\nwith the usual index, they may be a poor substitute for ll-merge\ndrivers to handle merging notes trees.\n"},{"id":"215924","messageId":"20130429214051.GA1704@pacific.linksys.moosehall","threadId":"33631","inReplyTo":"7vmwshjm4j.fsf@alter.siamese.dyndns.org","subject":"Re: improvements to checks for core.notesRef / GIT_NOTES_REF / --ref","fromName":"Adam Spiers","fromEmail":"git@adamspiers.org","sentAt":"2013-04-29T21:40:51Z","receivedAt":"2013-04-29T21:40:51Z","isPatch":false,"sender":{"key":"git@adamspiers.org","avatar":"https://avatars.githubusercontent.com/u/100738?v=4"},"body":"On Mon, Apr 29, 2013 at 10:13:32AM -0700, Junio C Hamano wrote:\n> Adam Spiers <git@adamspiers.org> writes:\n> \n> >     static struct notes_tree *init_notes_check(const char *subcommand)\n> >     ...\n> > Can we relax this to \"refs/\", to allow better isolation of namespaces\n> > for remote notes?  Also, the check is applied for GIT_NOTES_REF and\n> > core.notesRef, but not for values passed via --ref.  Therefore I would\n> > propose that init_notes_check() is not only relaxed but also moved\n> > from builtin/notes.c to notes.c, so that it can be consumed by\n> > default_notes_ref().  Thoughts?\n> \n> Such a policy decision at the application level should be done in\n> builtin/notes.c, and not notes.c, I think.  It is OK to have a\n> sharable check routine in notes.c and help different notes\n> applications to implement their own sanity checking, though.  \"git\n> notes\" that operates only on local notes might restrict its\n> operation to refs/notes, while \"git notes-merge\" may allow it to\n> read from other hierarchies but still write only into refs/notes,\n> for example.\n\nOK, makes sense.\n\n> I am not sure if it is a good idea in general to have a separate\n> remotes-notes/ hierarchy in the first place, though.  Wouldn't the\n> notes be less like branches (private view) and more like tags\n> (common world view)?\n\nI didn't have anything to do with the design, but the existence of\ncertain \"git notes\" subcommands (in particular append, edit, and\nmerge) gave me the distinct impression that users are expected to edit\nnotes simultaneously, and handle any merge conflicts which may arise.\nThese actions are modelled by commits to refs/notes/$GIT_NOTES_REF,\nwhich as a result is used as a sort of inferior 3rd-class branch.  In\ncontrast, tags do not seem to be mutable (in the accumulative sense,\nat least), and have no history (not even in the reflog, AFAICS).\n\nAs stated earlier in the thread, my particular use case is to use\nnotes to mark commits which should be excluded from a long list of\ncommits which \"git cherry\" says need to be upstreamed.  In our\nproject, there are many commits for which it does not make sense to\nupstream them, and even for the ones which it does, cherry-picking can\nsometimes result in a different patch-id due to changed context.  In\nboth of these cases, git notes is a great mechanism for blacklisting\nthese commits from the upstreaming process, and I've already written\n\"git icing\" which wraps \"git cherry\" to support that.  However, the\nsubstantial size of the upstreaming work means that it needs to be\ndone by multiple people across multiple clones of the repository,\nhence the need for branch-like tracking of notes.\n\n> > Also, are there any plans in the future for making \"git notes merge\"\n> > provide an index, so that a proper 3-way merge with ancestor can be\n> > done using git mergetool?\n> \n> Are we committed that all notes leaves must be blobs (I do not\n> personally mind it)?\n\nNo idea - perhaps someone else can comment on this.  Sounds reasonable\nto me too.\n\n> I do think we need a way to call a custom low level 3-way merge\n> driver once we identify which notes blobs correspond to each other\n> with what common ancestor notes blob while merging two notes trees.\n\nRight.\n\n> But I do not think that \"an index\" that we use for the usual working\n> tree merge is necessarily a good representation for driving such a\n> ll-merge driver and recording its result.  Each side likely has a\n> note for the same object to be merged in a different fan-out layout,\n> and fan-out is merely a performance hack to spread the objects in\n> smaller trees.  As mergetools only work with the usual working tree\n> with the usual index, they may be a poor substitute for ll-merge\n> drivers to handle merging notes trees.\n\nI won't pretend to have fully understood that ;-) I'm certainly not\nreligious about how such a merge workflow would be implemented.  I\njust wanted to point out that the current mechanism doesn't readily\nexpose the common ancestor in a way which makes the merge convenient.\nIMHO the more similar the merge's user experience is to a standard\nmerge, the better, since that would minimise the number of merging\nworkflows the user needs to learn.\n\nOn this theme, I think ideally rebase should be supported too, and\nthat does make me wonder if there's a good reason why notes shouldn't\nbe stored in real branches, or at least something which looks more\nlike a branch (even if \"git branch\" doesn't list it).  In particular,\napplying the concept of remote tracking branches to notes would be\nmost useful.  Currently my \"git rnotes\" wrapper is faking remote\ntracking branches via refs/notes/$remote/$GIT_NOTES_REF, but that\nmeans that if I want to push a set of notes to a remote repository,\nit's not sufficient to do the following:\n\n    git push $remote refs/notes/$GIT_NOTES_REF:refs/notes/$GIT_NOTES_REF\n\nI also have to manually update the fake tracking \"branch\":\n\n    git update-ref refs/notes/$remote/$GIT_NOTES_REF refs/notes/$GIT_NOTES_REF\n\n    # or if I want to make really sure this only happens if the push worked\n    git fetch $remote refs/notes/$GIT_NOTES_REF:refs/notes/$remote/$GIT_NOTES_REF\n\nThat's pretty ugly.  Couldn't we instead just reuse the existing\nmechanisms?\n\n    remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\n    remote.origin.fetch=+refs/notes/*:refs/note-remotes/origin/*\n    branch.notes/commits.remote=origin\n    branch.notes/commits.merge=refs/notes/commits\n\nJust an idea ...\n\nAdam\n"},{"id":"215944","messageId":"CALKQrgdH_Oh122tGKeD+chk5f6PwUvsisXjRp68QD_KMQt-9Bg@mail.gmail.com","threadId":"33631","inReplyTo":"20130429214051.GA1704@pacific.linksys.moosehall","subject":"Re: improvements to checks for core.notesRef / GIT_NOTES_REF / --ref","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2013-04-30T00:32:33Z","receivedAt":"2013-04-30T00:32:33Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Mon, Apr 29, 2013 at 11:40 PM, Adam Spiers <git@adamspiers.org> wrote:\n> On Mon, Apr 29, 2013 at 10:13:32AM -0700, Junio C Hamano wrote:\n>> Adam Spiers <git@adamspiers.org> writes:\n>> >     static struct notes_tree *init_notes_check(const char *subcommand)\n>> >     ...\n>> > Can we relax this to \"refs/\", to allow better isolation of namespaces\n>> > for remote notes?  Also, the check is applied for GIT_NOTES_REF and\n>> > core.notesRef, but not for values passed via --ref.  Therefore I would\n>> > propose that init_notes_check() is not only relaxed but also moved\n>> > from builtin/notes.c to notes.c, so that it can be consumed by\n>> > default_notes_ref().  Thoughts?\n>>\n>> Such a policy decision at the application level should be done in\n>> builtin/notes.c, and not notes.c, I think.  It is OK to have a\n>> sharable check routine in notes.c and help different notes\n>> applications to implement their own sanity checking, though.  \"git\n>> notes\" that operates only on local notes might restrict its\n>> operation to refs/notes, while \"git notes-merge\" may allow it to\n>> read from other hierarchies but still write only into refs/notes,\n>> for example.\n>\n> OK, makes sense.\n\nI initially added this check with the intention of making it _really_\nhard for users to accidentally mix up notes trees and \"real\" trees.\nObviously, it also makes it unnecessarily hard for people that want to\nshare notes (e.g. you). According to the Great Refs Namespace Debate,\nI would probably want to limit note refs to refs/notes/* and\nrefs/remotes/$remote/notes/*, but since that debate I've regrettably\nneglected the whole issue, and the current implementation was left as\nit currently is... Re-thinking the issue now, I see how it might be\nmore useful to remove the check altogether, rather than\nunintentionally holding it \"hostage\" while we wait for the remote refs\nnamespaces to materialize.\n\nOtherwise, I agree with Junio's assessment that this code conceptually\nbelongs in builtin/notes.c and not notes.c.\n\n>> I am not sure if it is a good idea in general to have a separate\n>> remotes-notes/ hierarchy in the first place, though.  Wouldn't the\n>> notes be less like branches (private view) and more like tags\n>> (common world view)?\n>\n> I didn't have anything to do with the design, but the existence of\n> certain \"git notes\" subcommands (in particular append, edit, and\n> merge) gave me the distinct impression that users are expected to edit\n> notes simultaneously, and handle any merge conflicts which may arise.\n> These actions are modelled by commits to refs/notes/$GIT_NOTES_REF,\n> which as a result is used as a sort of inferior 3rd-class branch.  In\n> contrast, tags do not seem to be mutable (in the accumulative sense,\n> at least), and have no history (not even in the reflog, AFAICS).\n\nI definitely agree with Adam here. Notes are definitely to be\nconsidered mutable (in the general case), and hence are more like\nbranches than tags. Especially when notes are shared among repos, one\nmust assume that they will also be edited in multiple repos, and must\ntherefore be merged properly (or at least have the option of doing so)\nwhen shared from one repo to another. After all, that's the reason why\n\"git notes merge\" exists at all...\n\n> As stated earlier in the thread, my particular use case is to use\n> notes to mark commits which should be excluded from a long list of\n> commits which \"git cherry\" says need to be upstreamed.  In our\n> project, there are many commits for which it does not make sense to\n> upstream them, and even for the ones which it does, cherry-picking can\n> sometimes result in a different patch-id due to changed context.  In\n> both of these cases, git notes is a great mechanism for blacklisting\n> these commits from the upstreaming process, and I've already written\n> \"git icing\" which wraps \"git cherry\" to support that.  However, the\n> substantial size of the upstreaming work means that it needs to be\n> done by multiple people across multiple clones of the repository,\n> hence the need for branch-like tracking of notes.\n>\n>> > Also, are there any plans in the future for making \"git notes merge\"\n>> > provide an index, so that a proper 3-way merge with ancestor can be\n>> > done using git mergetool?\n>>\n>> Are we committed that all notes leaves must be blobs (I do not\n>> personally mind it)?\n>\n> No idea - perhaps someone else can comment on this.  Sounds reasonable\n> to me too.\n\nAFAICR, we've left that decision somewhat open. The notes code will in\ngeneral work with both notes and trees, although there are some\nfunctions that will obviously only work with blobs:\n\n - Any notes command that lets you edit the note in a text editor\n(add/append/edit, IINM) will obviously only produce blobs.\n\n - Certain notes merge strategies, such as \"union\" and \"cat_sort_uniq\"\nwill only work on blobs. The default \"manual\" strategy is also unable\nto checkout non-blobs in the notes merge worktree.\n\n - Displaying notes as part of the log (or any other call to\nnotes.c:format_note()) only works on blobs.\n\nSo, although the common use case for notes is definitely blobs\n(typically with text contents), we definitely allow other things to be\nstored as notes, but you must be prepared to create your own scripts\nto work with these, and you naturally cannot expect the text-centric\nparts of the notes API to deal with them usefully.\n\n>> I do think we need a way to call a custom low level 3-way merge\n>> driver once we identify which notes blobs correspond to each other\n>> with what common ancestor notes blob while merging two notes trees.\n>\n> Right.\n\nAll the information you need should be available in struct\nnotes_merge_pair passed to merge_one_change() in notes-merge.c. I\nbelieve it should be fairly straightforward to create another notes\nmerge strategy that uses a mergetool directly for resolving conflicts.\n\n>> But I do not think that \"an index\" that we use for the usual working\n>> tree merge is necessarily a good representation for driving such a\n>> ll-merge driver and recording its result.  Each side likely has a\n>> note for the same object to be merged in a different fan-out layout,\n>> and fan-out is merely a performance hack to spread the objects in\n>> smaller trees.  As mergetools only work with the usual working tree\n>> with the usual index, they may be a poor substitute for ll-merge\n>> drivers to handle merging notes trees.\n>\n> I won't pretend to have fully understood that ;-) I'm certainly not\n> religious about how such a merge workflow would be implemented.  I\n> just wanted to point out that the current mechanism doesn't readily\n> expose the common ancestor in a way which makes the merge convenient.\n\nThat common ancestor (if exists) is the \"base\" member of the struct\nnotes_merge_pair mentioned above.\n\n> IMHO the more similar the merge's user experience is to a standard\n> merge, the better, since that would minimise the number of merging\n> workflows the user needs to learn.\n>\n> On this theme, I think ideally rebase should be supported too, and\n\nIMHO the general discussion about rebase vs. merge is mostly about the\nshape of the resulting history. When it comes to notes, I have yet to\nsee a use case where anybody really cares about the shape of the notes\nhistory, and hence I don't yet see how rebase would be useful for\nnotes. In fact, it rather seems some people are more interested in\nstoring their notes trees without any history at all (ISTR a\ndiscussion regarding the notes-cache feature, where we did NOT want to\nkeep earlier versions of the cache alive).\n\n> that does make me wonder if there's a good reason why notes shouldn't\n> be stored in real branches, or at least something which looks more\n> like a branch (even if \"git branch\" doesn't list it).  In particular,\n> applying the concept of remote tracking branches to notes would be\n> most useful.  Currently my \"git rnotes\" wrapper is faking remote\n> tracking branches via refs/notes/$remote/$GIT_NOTES_REF, but that\n> means that if I want to push a set of notes to a remote repository,\n> it's not sufficient to do the following:\n>\n>     git push $remote refs/notes/$GIT_NOTES_REF:refs/notes/$GIT_NOTES_REF\n>\n> I also have to manually update the fake tracking \"branch\":\n>\n>     git update-ref refs/notes/$remote/$GIT_NOTES_REF refs/notes/$GIT_NOTES_REF\n>\n>     # or if I want to make really sure this only happens if the push worked\n>     git fetch $remote refs/notes/$GIT_NOTES_REF:refs/notes/$remote/$GIT_NOTES_REF\n>\n> That's pretty ugly.  Couldn't we instead just reuse the existing\n> mechanisms?\n>\n>     remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\n>     remote.origin.fetch=+refs/notes/*:refs/note-remotes/origin/*\n\nThe remote refs namespace idea aims to solve this by providing refspecs like\n\n    remote.origin.fetch=+refs/heads/*:refs/remotes/origin/heads/*\n    remote.origin.fetch=+refs/tags/*:refs/remotes/origin/tags/*\n    remote.origin.fetch=+refs/notes/*:refs/remotes/origin/notes/*\n    remote.origin.fetch=+refs/replace/*:refs/remotes/origin/replace/*\n    etc.\n\nI'm currently working on some patches to make git work well in repos\nwith those kinds of refspecs. I see that as the first step on the way\nto properly supporting remote ref namespaces.\n\n>     branch.notes/commits.remote=origin\n>     branch.notes/commits.merge=refs/notes/commits\n\nThis looks like an natural extension of the branch upstream mechanism\nfor notes. Personally, I'd rather have it look more like this:\n\n  [notes \"commits\"]\n        remote = origin\n        merge = refs/notes/commits\n\nor, in your notation:\n\n    notes.commits.remote=origin\n    notes.commits.merge=refs/notes/commits\n\n> Just an idea ...\n>\n> Adam\n\nThanks for your interest and insight. It's enlightening to see how\nothers approach and work with notes and notes sharing.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"215945","messageId":"20130430004006.GF8768@pacific.linksys.moosehall","threadId":"33631","inReplyTo":"CALKQrgdH_Oh122tGKeD+chk5f6PwUvsisXjRp68QD_KMQt-9Bg@mail.gmail.com","subject":"Re: improvements to checks for core.notesRef / GIT_NOTES_REF / --ref","fromName":"Adam Spiers","fromEmail":"git@adamspiers.org","sentAt":"2013-04-30T00:40:06Z","receivedAt":"2013-04-30T00:40:06Z","isPatch":false,"sender":{"key":"git@adamspiers.org","avatar":"https://avatars.githubusercontent.com/u/100738?v=4"},"body":"On Tue, Apr 30, 2013 at 02:32:33AM +0200, Johan Herland wrote:\n> On Mon, Apr 29, 2013 at 11:40 PM, Adam Spiers <git@adamspiers.org> wrote:\n\n[snipped]\n\n> > IMHO the more similar the merge's user experience is to a standard\n> > merge, the better, since that would minimise the number of merging\n> > workflows the user needs to learn.\n> >\n> > On this theme, I think ideally rebase should be supported too, and\n> \n> IMHO the general discussion about rebase vs. merge is mostly about the\n> shape of the resulting history. When it comes to notes, I have yet to\n> see a use case where anybody really cares about the shape of the notes\n> history, and hence I don't yet see how rebase would be useful for\n> notes. In fact, it rather seems some people are more interested in\n> storing their notes trees without any history at all (ISTR a\n> discussion regarding the notes-cache feature, where we did NOT want to\n> keep earlier versions of the cache alive).\n\nThat's a fair point; lack of rebase is certainly not a showstopper.\nIn contrast, in our use case, a total lack of history could be quite\nannoying.\n\n> > I also have to manually update the fake tracking \"branch\":\n> >\n> >     git update-ref refs/notes/$remote/$GIT_NOTES_REF refs/notes/$GIT_NOTES_REF\n> >\n> >     # or if I want to make really sure this only happens if the push worked\n> >     git fetch $remote refs/notes/$GIT_NOTES_REF:refs/notes/$remote/$GIT_NOTES_REF\n> >\n> > That's pretty ugly.  Couldn't we instead just reuse the existing\n> > mechanisms?\n> >\n> >     remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\n> >     remote.origin.fetch=+refs/notes/*:refs/note-remotes/origin/*\n> \n> The remote refs namespace idea aims to solve this by providing refspecs like\n> \n>     remote.origin.fetch=+refs/heads/*:refs/remotes/origin/heads/*\n>     remote.origin.fetch=+refs/tags/*:refs/remotes/origin/tags/*\n>     remote.origin.fetch=+refs/notes/*:refs/remotes/origin/notes/*\n>     remote.origin.fetch=+refs/replace/*:refs/remotes/origin/replace/*\n>     etc.\n> \n> I'm currently working on some patches to make git work well in repos\n> with those kinds of refspecs. I see that as the first step on the way\n> to properly supporting remote ref namespaces.\n> \n> >     branch.notes/commits.remote=origin\n> >     branch.notes/commits.merge=refs/notes/commits\n> \n> This looks like an natural extension of the branch upstream mechanism\n> for notes. Personally, I'd rather have it look more like this:\n> \n>   [notes \"commits\"]\n>         remote = origin\n>         merge = refs/notes/commits\n> \n> or, in your notation:\n> \n>     notes.commits.remote=origin\n>     notes.commits.merge=refs/notes/commits\n\nAhah yes, that's nicer.  Thanks for the reply!\n"},{"id":"227999","messageId":"20130921172519.GB20610@pacific.linksys.moosehall","threadId":"33631","inReplyTo":"20130429133205.GA4672@pacific.linksys.moosehall","subject":"tools for making upstreaming / backporting easier in git","fromName":"Adam Spiers","fromEmail":"git@adamspiers.org","sentAt":"2013-09-21T17:25:19Z","receivedAt":"2013-09-21T17:25:19Z","isPatch":false,"sender":{"key":"git@adamspiers.org","avatar":"https://avatars.githubusercontent.com/u/100738?v=4"},"body":"Hi all,\n\nBack in April, I announced a couple of scripts I'd written to wrap\naround git-cherry and git-notes, which help when you have more than a\ntrivial number of commits to upstream / backport from one branch to\nanother.  Since then I've improved these scripts, and also written a\nhigher-level CLI which should make the whole process pretty easy.\n\nYesterday I finally finished a blog post with all the details:\n\n  http://blog.adamspiers.org/2013/09/19/easier-upstreaming-with-git/\n\nThese tools worked pretty well for me and my team, but no doubt some\npeople will have ideas how to improve them, or have different\ntechniques for tackling the problem.  Either way, I hope this is of\ninterest, and I'd be very interested to hear what people think!\n\nCheers,\nAdam\n"}]}