qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jean Delvare
Subject: Re: [Qemu-devel] dmidecode repository (Was: [ARM SMBIOS V1 PATCH 0/6] SMBIOS Support for ARM)
Date: Mon, 10 Aug 2015 14:26:44 +0200

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.

> - 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.

> - 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.

> > 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.

-- 
Jean Delvare
SUSE L3 Support



reply via email to

[Prev in Thread] Current Thread [Next in Thread]