Re: [hatari-devel] HDC code update patch

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 14.3.2022 20.44, Uwe Seimet wrote:
> Does it have to be this complicated? > I have been working with several
> projects using git, also in my job, but this is the most complicated
> approach I have seen so far ;-).

Um, if you are not using commits to handle your source changes, how 
you're actually using Git?

(Changes being commits in your repository clone is the only difference 
between "git diff  >  <file>" and "git format-patch <commit>" workflows.)


> Is there a git repository I can clone, so that I can raise a PR against my
> changes? This also retains the other and has other advantages.

Hatari's official Tuxfamily repo does not support extra stuff like PRs.

While Thomas' GitHub Hatari mirror repo does, it's Thomas personal one, 
not Hatari project one.    I.e. while we can review PRs there, we cannot 
merge them.


	- Eero

PS. I would not be opposed to Hatari moving to GitLab (if it still has 
free accounts) or GitHub.  If others feel the same, I guess we could 
consider migrating, but that's longer process.

> > On 14.3.2022 15.34, Uwe Seimet wrote:
> > > The attached patch contains some minor updates for hdc.c. Essentially
> > > comments were updated and the opcode evaluation uses existing constants
> > > instead of magic values in some places. I also removed unused opcode
> > > constants.
> >
> > Could you send these as commits generated with something like:
> > "git format-patch origin/master"
> >
> > or e.g. "git format-patch HEAD^" for the last patch in your tree.
> >
> >
> > That way the commit messages, author etc would automatically there when
> > patches are applied with something like "git am 0*.patch".
> >
> >
> > Then later, if commit was modified before it was applied, and you cannot
> > rebase on the upsteam version, you can remove your own versions with
> > something like "git reset hard HEAD^" (careful, that removes all traces
> > of your last commit), or do droping interactively with "git rebase -i
> > origin/master", before you pull upstream version.
> >
> >
> >
> > Main reason for this is that I'd like your commit message to tell reason
> > for the functional changes you did not mention:
> > -	else if (ctr->opcode == 0x05 || (ctr->opcode >= 0x20 && ctr->opcode <=
> > 0x7d)) {
> > +	else if (ctr->opcode >= 0x20 && ctr->opcode <= 0x7d) {
> > ...
> > -	else if (ctr->opcode >= 0x60)
> > +	else if (ctr->opcode >= 0x60 && ctr->opcode != HD_REPORT_LUNS)
> >
> > (If it e.g. fixes your earlier commit, it would be nice to give ID for
> > the fixed commit in the commit message.)
> >
> >
> > 	- Eero