[Feature request] Give non-unique names to commits for grouping

Dear Git users,

I suggest that we should have the option to mark each commit with a category name, that is not necessarily unique (like 'tags') so we could have commit groups. For example we could: git mark {commit_id} {name}

Then we could give special functionality to some commands based on those "marks". For example if we had marked a few commits with the name 'fix_typo' git log --mark fix_typo. Show all the commits marked with 'fix_typo' git blame --mark fix_typo Run git blame but ignore commits with 'fix_typo'

Christos

11.03.2020, 02:16, "Christos Pappas" <chrispappas99@gmail.com>:

Why not use git log --grep? It can give better results if someone accidentally forgets to use mark properly, but mentions keyword in the topic.

That said, it would be great if there was an easy way to use git log --grep with commit topics only (i.e., search only in the first line)

On Wednesday, March 11, 2020 1:16:09 AM MDT Christos Pappas wrote:

Perhaps git notes could be used to do something like this?

-Martin

Thank you for your answers.

From what I can deduce, both of your suggestions require that the commit messages(or notes) must have some special text for which we can search for, which is hacky and would be different on every repository.

What I am suggesting is something like, labels on GitHub, hashtags on Social-Media, or Tags in News sites. It's a well known concept so it will be easy to understand and use.

We could initially create the concept of marks/labels/{another name} ('tags' is already in use by another git command) and then incrementally enhance the git commands to use this functionality (like the example I gave above, with git blame).

Στις Τετ, 11 Μαρ 2020 στις 6:00 μ.μ., ο/η Martin Fick <mfick@codeaurora.org> έγραψε:

On Wednesday, March 11, 2020 8:56:44 PM MDT Christos Pappas wrote:

FYI: the list preference is inline instead of top-posting.
 

By "different", do you mean the mechanism, or the content of the "hashtag" itself? I would imagine that you would expect the hashtags to be different, and that you are concerned that they might be stored differently on each site, maybe on one site as a note like

 hashtag: awesome

and on another:

 label: awesome

Is that correct?

If so, then it seems like a reasonable suggestion that some tooling be built to potentially enforce something like that using git notes and/or commit messages?

Right, maybe git notes is just the storage mechanism for such a feature?

-Martin

Yes, I think that every project would end up having a different convention.

Maybe some code could be shared behind the scenes(I don't know the code architecture), but the interface should be different.

I would expect a commit log to look like this:

commit {commit_hash} (HEAD -> master, tag: maybe_a_tag_here, labels:
bug_fix front_end, origin/master, origin/HEAD)
Author: ...
Date: ...

Commit Message

This also requires at least one command to create a label (git label create {name}), and a different command to assign one of the available labels (git label assign {label} {commit}), to avoid mistakes (The levenshtein algorithm could also be used when the user makes a typo and tries to assign a label that doesn't exist)

Στις Τετ, 11 Μαρ 2020 στις 9:31 μ.μ., ο/η Martin Fick <mfick@codeaurora.org> έγραψε:

Christos Pappas <chrispappas99@gmail.com> writes:

By "hashtags", do you mean #hashtags, i.e. you must add some special text for which you can search for? That does sound just as hacky as any other embedded text in the messages of commit objects.

One large downside of embedding text (or #hashtags) in the message of a commit object is that you need to plan ahead and know what group the commit belongs to before you make it, but in general, it is unreasonable to expect perfect foresight. Often you do not know what group the commit belongs to (e.g. you may want to label the set of commits that broke the latest release for feature 'frotz' with hashtag "#broke-frotz", but most likely you didn't know you were breaking the feature when you were creating these commits). Adding these offending commit objects some comments in the form of notes objects can be done retroactively, and as long as the set of "tag-worthy" commits is minority among all commits, grepping for "#hashtag" in the notes to find the notes that contain the tags you wanted should be cheaper than "git log --grep" which must read all the commits in the history.

Another way may be "git notes --ref broke-frotz add X -m . X" (and similarly for Y and Z that also belong to "#broke-frotz" set of commits) to mark them with an almost empty note in refs/notes/broke-frotz hierarchy. Then "git notes --ref broke-frotz list" should be able to list these commits that have any notes in refs/notes/broke-frotz and there is no need for grepping. Of course you can make it richer by describing why each of X, Y, and Z are in the "broke-frotz" set when you give the notes text to them.