Re: [hatari-devel] Git commits (was: HDC code update patch)

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

I just noticed that for squashed commits "git log" displays the comments of
the individual commits. I usually use a customized log output, so I did not
notice that before.
git simply has too many options ;-).

> Hi,
> 
> > Sorry, but I think you're confusing something. The statistic you posted
> > above refers to the length of the *summary* line [1], i.e., the first
> > line of the commit message.
> 
> Yes, you are right. I was not aware of the distinction between the summary
> line and the body. I usually place the details in the PR, and keep the PR
> (initially a draft) up to date. github automatically adds a reference to
> the respective PR to the final commit message, so that you have the full
> context, including any discussions in the PR. Of course, anything that is in
> the PR is not available in your local repository, because the commit message
> just contains the PR ID. So there is a dependency on github if you want to
> know the whole story.
> When you edit the PR subject, you effectively edit the summary of the
> squashed commit, but there is no means to edit the commit body as far as I
> can tell, probably because the PR description is a replacement. But maybe
> this is a github configuration issue.
> 
> > Then again, it's not very maintainer-friendly if they have to do a lot
> > of routine work such as writing commit messages for contributor's diffs.
> > 
> > I assume that your git workflow contains commits; as you would need
> > those for a Github PR, too. Then, like Eero says, imho it's not much of
> > a difference whether you do "git diff" or "git format-patch origin".
> 
> Of course I don't expect anybody else to write my commit messages. The fact
> that we have this discussion may already indicate that the Hatari workflow
> has flaws. Compared to what I am used to the effort to provide patches is
> higher than with any other project. You have to follow rules on how to
> prepare your diffs, then you have to send them by email, then the maintainers
> have to check whether they are in the right format, if not they need to get
> back to you  etc. On all sides more manual work is required than you would
> expect nowadays.
> 
> Using github or gitlab would help with this, and it would also make the
> current status, the road to the next release, and the PRs involved more
> transparent. And you can create tickets and follow their progress, which is
> much more convenient than reporting bugs by email.
> The more I write, the more I notice how many useful features I am missing ;-).
> 
> Best regards
> 
> Uwe
> 
>