Rebasing and merging in kernel repositories

Posted Jun 19, 2019 19:01 UTC (Wed) by mathstuf (subscriber, #69389)
In reply to: Rebasing and merging in kernel repositories by k8to
Parent article: Rebasing and merging in kernel repositories

Are you proposing that branch names be stored within commit objects (like Mercurial)? If so, I really don't want to see that because there are millions of branches named "patch-1" or PRs coming from "master" that really deserve better names. Or for long-lived branches, splitting out smaller stepping stones into its own branch for merging on a faster timeline is very valuable.

If you're proposing a new type of object, I could get behind that as long as the branch surgery operations are possible (but, e.g., then require a new name for the set of commits).

Rebasing and merging in kernel repositories

Posted Jun 19, 2019 19:08 UTC (Wed) by k8to (guest, #15413) [Link] (1 responses)

I would expect some kind of branch object to exist with a many-to-many relationship with commits which is used infrequently.

I would hope that this could be leveraged for goals like "What work has happened in this branch since it was created?" as well as the ability to set useful per-branch state on something smarter than the name.

As an aside, it's interesting that you refer to many poorly named branches. In my world I never create those. They're typically always something like <defectID>-<description> or <requirementID>-<description> Yeah, over the lifetime of the project they are, as an aggregate, noise, but I wouldn't ever "push" a branch with a stupid name. But it isn't hard to imagine that other projects are different.

Rebasing and merging in kernel repositories

Posted Jun 19, 2019 19:25 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

That sounds like a useful object. Not sure how often I'd use it, but it would be nice to associate stashes with branches as well instead of my standard "wipwipwip" commit message.

I work on projects mainly via with gitlab and github. Edits made via the web get those "patch-n" names and many people just commit directly to their fork's "master" and then open an MR. Once that's made, the branch name is locked in without closing it and opening a new one. We use a robot to do our merges (it does backporting to release branches and Acked-by/Reviewed-by trailer scraping for the merge commit message) and since we have that, we can tell it to merge it with a better branch name in the merge commit message too.

Rebasing and merging in kernel repositories

Posted Jun 22, 2019 6:02 UTC (Sat) by marcH (subscriber, #57642) [Link]

> Are you proposing that branch names be stored within commit objects (like Mercurial)? If so, I really don't want to see that because there are millions of branches named "patch-1" or PRs coming from "master" that really deserve better names.

There could be a distinction between private branch names versus branches names meant to published. In fact git tags already miss that.