Hi all,
I just wrote a wrapper around git cherry which adds a splash of
colour, and facilitates exclusion of commits which should never be
upstreamed, by using a git-notes(1) namespace as a blacklist.
It's just a quick hack and Ruby probably won't be to everyone's taste,
but I thought I'd mention it just in case it's of use / interest.
https://github.com/aspiers/git-config/blob/master/bin/git-icing
I'm not sure whether it would make sense to move this functionality
into git cherry itself. Adding (optional) colour support would bring
it in line with some of the other porcelain, I suppose.
There are other git utilities in that repository which may also be of
interest:
https://github.com/aspiers/git-config/blob/master/README.md
(I do not claim that any of them are beautiful code, but they work for
me ;-)
Regards,
Adam
On Sat, Apr 27, 2013 at 02:21:19PM +0100, Adam Spiers wrote:
Hi all,
I just wrote a wrapper around git cherry which adds a splash of
colour, and facilitates exclusion of commits which should never be
upstreamed, by using a git-notes(1) namespace as a blacklist.
It's just a quick hack and Ruby probably won't be to everyone's taste,
but I thought I'd mention it just in case it's of use / interest.
https://github.com/aspiers/git-config/blob/master/bin/git-icing
[snipped]
I've just written another quick wrapper around 'git notes' which makes
it less painless to share notes to and from remote repositories:
https://github.com/aspiers/git-config/blob/master/bin/git-rnotes
This makes sharing of notes as easy as:
git rnotes $remote push
git rnotes $remote fetch
git rnotes $remote merge
git rnotes $remote pull
and was born from this discussion:
http://stackoverflow.com/questions/12055303/merging-git-notes-when-there-are-merge-conflicts-in-them/
Once the Great Refs Namespace Debate is resolved[0], would this kind
of UI would be a candidate for pushing into git-notes itself?
Cheers,
Adam
[0] Maybe it has been already; I haven't been following closely.
On Mon, Apr 29, 2013 at 02:32:05PM +0100, Adam Spiers wrote:
I've just written another quick wrapper around 'git notes' which makes
it less painless to share notes to and from remote repositories:
https://github.com/aspiers/git-config/blob/master/bin/git-rnotes
This makes sharing of notes as easy as:
git rnotes $remote push
git rnotes $remote fetch
git rnotes $remote merge
git rnotes $remote pull
and was born from this discussion:
http://stackoverflow.com/questions/12055303/merging-git-notes-when-there-are-merge-conflicts-in-them/
Once the Great Refs Namespace Debate is resolved[0], would this kind
of UI would be a candidate for pushing into git-notes itself?
I just had a discussion on #git IRC with Thomas about how the above
wrapper uses refs/notes/$remote/commits or similar to simulate a
remote tracking branch for notes, and we agreed that it's not ideal
due to potential collisions if --ref=$remote or refs/notes/* are ever
used. As has probably been discussed already in the Great Debate,
something like refs/remote-notes/ might be a better namespace; however
the current implementation of git notes prevents this:
static struct notes_tree *init_notes_check(const char *subcommand)
{
struct notes_tree *t;
init_notes(NULL, NULL, NULL, 0);
t = &default_notes_tree;
if (prefixcmp(t->ref, "refs/notes/"))
die("Refusing to %s notes in %s (outside of refs/notes/)",
subcommand, t->ref);
return t;
}
Can we relax this to "refs/", to allow better isolation of namespaces
for remote notes? Also, the check is applied for GIT_NOTES_REF and
core.notesRef, but not for values passed via --ref. Therefore I would
propose that init_notes_check() is not only relaxed but also moved
from builtin/notes.c to notes.c, so that it can be consumed by
default_notes_ref(). Thoughts?
Also, are there any plans in the future for making "git notes merge"
provide an index, so that a proper 3-way merge with ancestor can be
done using git mergetool?
Cheers,
Adam
Hi all,
Back in April, I announced a couple of scripts I'd written to wrap
around git-cherry and git-notes, which help when you have more than a
trivial number of commits to upstream / backport from one branch to
another. Since then I've improved these scripts, and also written a
higher-level CLI which should make the whole process pretty easy.
Yesterday I finally finished a blog post with all the details:
http://blog.adamspiers.org/2013/09/19/easier-upstreaming-with-git/
These tools worked pretty well for me and my team, but no doubt some
people will have ideas how to improve them, or have different
techniques for tackling the problem. Either way, I hope this is of
interest, and I'd be very interested to hear what people think!
Cheers,
Adam