On 19/07/2022 00:10, Dan Rosen wrote: > Is there no board of directors to discuss improvements to Git?
Git is Open Source, so anyone can propose patches that may improve Git's capability (mailing list https://lore.kernel.org/git/). There is a maintainer who makes a final judgement, after reviews on the git mailing list. So, no, there are no directors.. It's important to realise that the core essence of Git is to provide source code management for the Linux project, so it does need to be compatible with the wide variation in styles of the diverse contributors, along with maintaining backwards compatibility for those on older versions. > Modern common practice organizes branches with slashes "/'. > "feature/new-feature, bug/bug-fix, etc" That's an artefact of the original scripts that stored branch refs as file paths. Formally, a ref is just a character string, though old habits die hard. > but this is a limited way to add meta data to a branch. As a _distributed control_ system, it's the user that gets to name their local branch and any metadata. Yes, commonly we lazy humans just reuse the upstream name (as passed down on tablets of stone from the directors ;-), but that's not always the case, especially if you are looking at multiple 'upstream' forks, each thinking they have their own 'master' and 'main' and 'feature1' branches, so when that happens I have to rename them, despite the upstream naming (Git and Git-for-Windows had that issue for a while). > Tags can have annotations so why can't branches? Tags have the opposite problem. You can't easily rename them when you have multiple upstreams, each thinking they can tag their v1.2.3 release - confusing! > > Why not have a way to say that branches XYZ and ABC are part of > release 3.2.1? Why not have a way to say branch XYZ is a feature > (story) and ABC is a bugfix? The above is not to say it can't be done, rather that there are more stakeholders to be considered. It will depend on how users upstream remotes are managed and who can push to them, and their interrelationship. If every dev has their own push/publish fork, then they should be able to add their own metadata to their branches, and push them to their publish remote. However the projects golden remote will have different rules, and the branch metadata there would be set by it's 'owner' and may not match the meta data that the local dev has created / amended for the same 'branch'. At some point there needs to be a separation of control so that a dev could fetch, and maybe merge, the upstream branch metadata, but that needs to be in the user's control. Likewise the user needs (should be able) to store their branch metadata in their publish remote (they have control!). All that would need some extensions to the transport and permissions protocols, which may be a more detailed project. > > branch-per-task is a very common git workflow. And branch naming is > getting ugly because there are things in the name that shouldn't be. Why not have a careful review of the various workflows to see how others break up these Catch 22 issues to see where the implicit conflicts are, such as the longevity of branch names vs the expectation that they are ephemeral, etc. Maybe also look at the way Git itself manages contributions - contributor branch names rarely match those allocated by the maintainer. The "A note from the maintainer" is at https://lore.kernel.org/git/xmqqbktufedk.fsf@gitster.g/ e.g. see the "How various branches are used" section. > > Do what you will with my thoughts... Maybe consider having a dev have a look at the code as a side `10% project` to see what the options could be? Contributions are always welcome. > > On Monday, July 18, 2022 at 4:34:05 PM UTC-6 philip...@iee.email wrote: > > I believe this has been discussed a few times. However branches > are meant to be local and ephemeral, which goes against that > 'organise' view that, in a sense, sees branches as tasks to be > controlled. > > Git, being distributed, looks to the code content, along with the > DAG, to get it's perspective on the code. Once a branch has been > merged, where would the meta data go (and who decides)? > > On Monday, July 18, 2022 at 10:34:44 PM UTC+1 dro...@ucar.edu > <imap://iee%2eem...@imap.hosts.co.uk:993/fetch%3EUID%3E.GfW%3E22054> > wrote: > > Adding metadata to branches would be helpful for third party > APIs to organize and tag branches without putting them in the > branch name. For example, project management software will use > an issue key to search the branch name but it would be better > to search branch metadata. I know branches have descriptions > but I believe these are part of the local configuration? > > - Dan Rosen > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/9e29d044-70f1-e578-bc20-b4ab52c7ca54%40iee.email.
