Re: [Qemu-devel] dmidecode repository (Was: [ARM SMBIOS V1 PATCH 0/6] SMBIOS Support for ARM)

[Laszlo Ersek]

On 08/10/15 14:26, Jean Delvare wrote:
> Hi Laszlo,
> 
> On Mon, 10 Aug 2015 13:58:31 +0200, Laszlo Ersek wrote:
>> On 08/10/15 09:43, Jean Delvare wrote:
>>> OK, I think I came up with something that looks reasonably good:
>>>
>>> http://git.savannah.gnu.org/cgit/dmidecode.git
>>>
>>> Can anyone please check it out and verify that it looks sane and can be
>>> worked with?
>>
>> I cloned it and built it with "make". (That's all the "testing" I did. :))
> 
> Thanks for testing and reporting.
> 
>> Ideas:
>> - please consider tagging commits that correspond to releases
> 
> The conversion already did exactly that as far as I can see:
> 
> dmidecode$ git tag
> dmidecode-1-8
> dmidecode-2-0
> dmidecode-2-1
> dmidecode-2-10
> dmidecode-2-11
> dmidecode-2-12
> dmidecode-2-2
> dmidecode-2-3
> dmidecode-2-4
> dmidecode-2-5
> dmidecode-2-6
> dmidecode-2-7
> dmidecode-2-8
> dmidecode-2-9
> 
> And the tags appear in the web frontend too so my attempt to push them
> there must have worked.

Interesting. I didn't specify --no-tags (and it also wasn't in effect in
my global ~/.gitconfig). "git tag" doesn't print anything in my clone.

> 
>> - probably useful to tag the git commit somehow that marks the switch
>>   from CVS to git (eg. "last_patch_from_cvs").
> 
> The conversion guide suggested tagging the cvs repository and I intend
> to do so. But tagging the git repository seems like adding noise to me,
> I can't see why anybody should care about the migration point.

I have no experience here, it was just an idea. Tagging the CVS repo is
probably a good idea (could work as a "stop sign"). Tagging the git repo
would be nice because one could easily list "patches from before, and
in, the git era". Maybe it's not useful for end users (and you could
just make a note about the git hash somewhere else).

> 
>> - after building, "git status" lists the *.o files and the built
>>   binaries as untracked files. For the former, please add a .gitignore
>>   file. For the latter, please list them individually in .gitignore too,
>>   or else build things in a separate directory, and ignore everything
>>   inside that directory.
> 
> I had noticed too and that was on my to-do list. Now this is done,
> thanks for the reminder. Please pull again and "git status" should be
> quiet now.

Looks good, thanks!

> 
>>> If it's OK then I'll tag the CVS repository as deprecated.
>>
>> If you can ascertain that the latest tree in git (at
>> "last_patch_from_cvs") matches the latest tree in CVS (with a recursive
>> diff excluding the SCM meta-dirs), there's no reason to delay switching
> 
> I already did that comparison and the result is positive.
> 
>> to git. If you realize later that something's "wrong", you can format
>> the new patches from git and reapply them to CVS. (But I don't expect
>> anything to go wrong.)
> 
> I am more worried about the history being incorrect, due to incorrect
> or missing options during the conversion. That being said, the history
> of dmidecode is very simple (which is why I did not bother switching to
> git so far) so hopefully the basic settings were good enough.

Thank you for migrating to git!
Laszlo