[reminder: this thread is still probably mostly interesting only to SUSE folk, although the described toolchain could be applied to any upstreaming work on any project which uses git]
Adam Spiers (aspi...@suse.com) wrote: > Adam Spiers (aspi...@suse.com) wrote: > > You can also see from the git-icing comments that blacklisting of > > commits which should never be upstreamed is now supported, e.g. > > > > git notes --ref=upstreaming add -m'skip: all' $sha > > > > Sharing git notes across repositories isn't the most convenient thing > > in the world, but it shouldn't be hard. I think we can push notes > > via: > > > > git push crowbar 'refs/notes/*:refs/notes/*' > > > > and then pull / merge via: > > > > http://vmiklos.hu/blog/git-notes-merge.html > > > > but I'm still trying to wrap my head around that bit. > > I figured it out and documented it here: > > http://stackoverflow.com/questions/12055303/merging-git-notes-when-there-are-merge-conflicts-in-them/ I've just been through this with Ralf and it turns out there are quite a few gotchas to bear in mind. So we wrote a wrapper to make it easy for everyone to collaborate on upstreaming blacklists: https://github.com/aspiers/git-config/blob/master/bin/git-rnotes Download the raw version to somewhere on your $PATH and chmod +x. We decided to store the notes in the https://github.com/SUSE-Cloud repositories, since the commit objects for essex-hack-suse are not present in https://github.com/crowbar. So if your local Crowbar tree doesn't yet have this remote, you should first add it: ./dev remote add suse https://github.com/SUSE-Cloud Firstly you need to tell git notes to use the 'upstreaming' refs namespace: export GIT_NOTES_REF=refs/notes/upstreaming or git config [--global] core.notesRef refs/notes/upstreaming according to your personal tastes. The first time you want to blacklist commits in a repository, you should first fetch the existing blacklist: git rnotes fetch suse Then you can add new commits to the blacklist, e.g.: git notes add -m"skip: all <<< insert explanation for why we don't want to upstream this commit here >>>" $sha [N.B. Occasionally you have to blacklist a commit even after you've upstreamed it, because the process of cherry-picking a commit into the upstream branch results in a different git patch-id due to changes in the unified diff context. If you cherry-pick a change and it doesn't go grey in the output from "git icing" or compare-crowbar-upstream.sh, you can see why via: diff -u <(git show $sha1) <(git show) ] Now push the updated blacklist back to SUSE-Cloud: git rnotes push suse During future work, you can also do git rnotes pull suse which is equivalent to git rnotes fetch suse && git rnotes merge suse Here's another useful trick for seeing the history of a given blacklist entry: git log -p notes/[suse/]upstreaming -- `git rev-parse $sha1` _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
