Re: [hatari-devel] SCSI Driver logging improvement

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 28.11.2024 18.36, Uwe Seimet wrote:
> > -> is sets status=io_hdr.status when ioctl fails and leaves if to 0 when
> > it succeeds.
>
> Indeed. This patch and git format-patch is causing me headaches ;-). I will
> try again, please see the attachment.

Logged messages should state from which subsystem they come from.  E.g. 
consistent subsystem prefix makes things easier to filter & read.


> @Eero You recommended to use git format last time. I did, but I don't see
> any advantage. Neither my name nor my comment are part of the patch. Can you
> please be more precise on the options I should use, and how I can create the
> required format without having to locally commit my changes first?

You need to do commit(s) first.

If your name/email are missing from ~/.gitconfig, git tells (command) to 
add those first.

You can commit all changes:
$ git commit -a

Or if there are lot of them, commit each self-contained change separately:
$ git commit <file(s)>

(Commit message should have reasonable description of the changes.)


After you've done all the commits, generate patches for the commits 
you've added on top of "master", and send them to list:
$ git format-patch main


You can then undo the commits ('1' below is number of commits):
$ git reset HEAD~1

Above command removes the commits from Git history, but leaves the 
changes they did to the files.  If you'd like those changes gone too, 
you can use:
$ git checkout <dirs/files>

Or add "--hard" option to the above "git reset" command.


To apply those changes as commits again, do:
$ git am <generated patches>


	- Eero

PS. Another alternative is working on a separate throwaway development 
branches, e.g. one per features; doing rebasing, cherry-picking etc.

It's more complex to use, but nowadays I prefer working like that for 
better flexibility, and so that if I mess things, I can throw that 
branch away.

If one is not sure which way to go, temporary branch is nice thing to 
test stuff.  If that development turns out to be a dead-end, but one has 
kept commits small & discrete, and some of them are useful although end 
result is not, one can cherry-pick just the useful changes...