"Etienne Vallette d'Osia" <dohzya@xxxxxxxxx> writes: > > You described your motivation and use case very clearly! > > > > Maybe "label" would be an appropriate name for "non-unique tags". I > > assume they should be local and non-versioned. It sounds as if a file > > storing a list of sha1s could be the simplest approach (one file per > > label in a new subdir of .git), although this may not scale well. A > > first step could be implementing a command "git label" in shell which > > sets and displays labels. Later on, various builtins would need to be > > taught about it if you want labels displayed in log etc. > > Thanks a lot > > "label" is perfect ! > > In fact, I was thinking about non-local labels. > But keeping information in a separate file and not in commit directly > is a very nice idea (and closer than the current tag implementation). > I love your approach, you have just make this idea realizable This is a bit argument for (abandoned / dropped) 'notes' commit header idea... But only a tiny bit. More seriously: take a look at 'notes' idea; I'm not sure what state they are currently, but they are in active (more or less) development. They are extension of tags, allowing post-fact annotation of commits. -- Jakub Narebski Poland ShadeHawk on #git -- 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
