On Tue, Apr 14, 2020 at 11:13:03AM -0400, J. Bruce Fields wrote: > On Tue, Apr 14, 2020 at 09:19:31AM -0300, Jason Gunthorpe wrote: > > On Mon, Apr 13, 2020 at 03:29:07PM -0400, J. Bruce Fields wrote: > > > On Thu, Apr 09, 2020 at 02:47:50PM -0300, Jason Gunthorpe wrote: > > > > On Thu, Apr 09, 2020 at 10:33:32AM -0400, Chuck Lever wrote: > > > > > The commit ID is what automation should key off of. The short > > > > > description is only for human consumption. > > > > > > > > Right, so if the actual commit message isn't included so humans can > > > > read it then what was the point of including anything? > > > > > > Personally as a human reading commits in a terminal window I prefer the > > > abbreviated form. > > > > Frankly, I think they are useless, picking one of yours at random: > > > > Fixes: 4e48f1cccab3 "NFSD: allow inter server COPY to have... " > > > > And sadly the '4e48f1cccab3' commit doesn't appear in Linus's tree so > > Ow, apologies. Looks like I rebased after writing that Fixes tag. > > I wonder if it's possible to make git warn.... > > Looks like a pre-rebase hook could check the branch being rebased for > "Fixes:" lines referencing commits on the rebased branch. I have some silly stuff to check patches before pushing them and it includes checking the fixes lines because they are very often wrong, both with wrong commit IDs and wrong subjects! linux-next now automates complaining about them, but perhaps not following the standard format defeats that.. Use 'git merge-base --is-ancestor fixes_id linus/master' to check them. > > now we are just totally lost, with a bad commit ID and a mangled > > subject line. > > For what it's worth, that part of the subject line is enough to find the > original commit (even to uniquely specify it). Lucky, but I wouldn't count on this as the general rule.. The point of the full subject line is to be informative to the reader and serve as a backup key in case the hash got mangled, as happens surprisingly often.. Jason
