On Tue, Apr 14, 2020 at 12:20:16PM -0300, Jason Gunthorpe wrote: > 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! I'd be interested in seeing it. > linux-next now automates complaining about them, but perhaps not > following the standard format defeats that.. It's managed before: https://lore.kernel.org/r/20190704074048.65556740@xxxxxxxxxxxxxxxx though admittedly I was breaking the rule in a different way. I can't even be consistently rebellious. > Use 'git merge-base --is-ancestor fixes_id linus/master' to check > them. Oh, yeah, that's better than what I was trying to do, thanks. --b.
