Linus wrote it to replace BitKeeper for the express purpose of collaborating on the maintenance & development of the Linux kernel. When I train developers on `git` in combination with GitHub, I emphasize that `git` the tool was written for a specific goal. That it is the responsibility of the person doing the merge to provide that information, and that GitHub does a bad job of providing tools to do that. Linus' argument is that the correct place to store that is in the merge commit's message. To solve this in any real way there needs to be a way that when a project is forked it carries information about issues and merges with it, and when commits from that fork are merged back into the main project, or merges from a fork of a fork are merged all the way back to the original project, all metadata about those merges are carried to the original project. Using any form of shortened sequential identifiers will fail when referenced in commits merged in from forks of the project that have their own conflicting identifiers. If a project is renamed or relocated from one name to another it might (and should) preserve issue and merge related information and discussion, but any full URLs will have changed, making full URLs fail in specific cases. Any offered standard is just a bandaid on the problem. If the data is not stored in the git repo itself there is no workable solution. Preferable with users using interactive rebases to create nice commit histories, alternatively squashing works to but git is just _bad_ at squashing and so are tools based ontop of it (e.g. Projects like Linux are a bit special due to the size, number of contributers and sizes of contribution.īut for most projects I can just strongly recommend to only allow FF merges and locally rebase branches on master if it doesn't work. I had more then one time where a "no conflict" git merge introduced bugs. Through IMHO the problem are non-ff git merges in general, not only do they motivate bad commit messages but also does "not having merge conflicts" in no way mean there is no problem. But you can always write them the way you want to filling in all the details needed. But it can't really know your style of using git so it can't do much more then just prefilling the hints. Most project are just hosted in one place so the shorthand is always clear, and has the benefit of not being "broken" if a project is renamed/moved.įurthermore GitHub always allows the user to specify the commit message, it just prefills some hint. Having a number short-form is a de-facto standard across most "version control+issue tracker" services.įor nearly all cases it's good enough, projects like the Linux kernel are in the end an exception wrt.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |