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: Laszlo Ersek
Subject: Re: [Qemu-devel] dmidecode repository (Was: [ARM SMBIOS V1 PATCH 0/6] SMBIOS Support for ARM)
Date: Mon, 10 Aug 2015 13:58:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 08/10/15 09:43, Jean Delvare wrote:
> On Thu, 6 Aug 2015 10:07:40 +0200, Laszlo Ersek wrote:
>> On 08/06/15 00:03, Jean Delvare wrote:
>>> On Wed, 05 Aug 2015 22:39:57 +0300, Ivan Khoronzhuk wrote:
>>>> There is no git repo for dmidecode.
>>>> Only CVS: http://savannah.nongnu.org/cvs/?group=dmidecode
>>>
>>> Correct. Savannah support git now so it should be possible to convert
>>> the CVS repository to git, and I'm all for it if it makes users and
>>> potential contributors happy.
>>
>> Yes, please do that, if you can find the time.
>>
>>> Just I don't know how this is done and
>>> did not have the time to look into it so far.
>>
>> I've never done it myself, so the only thing I could do to help is
>> google it for you, which would be useless. :)
> 
> 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. :))

Ideas:
- please consider tagging commits that correspond to releases

- probably useful to tag the git commit somehow that marks the switch
  from CVS to git (eg. "last_patch_from_cvs").

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

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

Thanks
Laszlo



reply via email to

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