> Have you decided whether we need to commit the generated files > (Cargo.toml, Cargo.lock)? It looks like in this series those files > are still included and not added to .gitignore.I'm sorry I forgot adding Cargo.lock to .gitignore. I'll add it to .gitignore. However, I think Cargo.toml should be staged. This is because this is a file managed by hands. It contains dependencies, versions, editions, crate name. It can be generated by shellscript which dumps such information. However, I think it may be not preferable. Regards, Hiroyuki 2019年7月4日(木) 19:39 Richard W.M. Jones <rjones@redhat.com>:> On Tue, Jul 02, 2019 at 10:09:00PM +0900, Hiroyuki Katsura wrote: > > I fixed the patch I submitted before based on comments, and there are > some > > commits which are merged or divided. So, I will re-send all the patches. > > I looked at the v2 patches and I think they're in reasonable > shape. > > There's been a lot of discussion of using ’git rebase --interactive’. > I think that's a good thing, and also good practice if you're going to > become a more frequent open source contributor. It helps people when > they're reviewing patches. > > For this particular case I think we'd probably squash all the patches > into a single commit when pushing them upstream. > > Have you decided whether we need to commit the generated files > (Cargo.toml, Cargo.lock)? It looks like in this series those files > are still included and not added to .gitignore. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html >
On Fri, Jul 05, 2019 at 01:28:12PM +0900, Hiroyuki Katsura wrote:> > Have you decided whether we need to commit the generated files > > (Cargo.toml, Cargo.lock)? It looks like in this series those files > > are still included and not added to .gitignore. > > I'm sorry I forgot adding Cargo.lock to .gitignore. I'll add it to > .gitignore. However, I think Cargo.toml should be staged. This is because > this is a file managed by hands. It contains dependencies, versions, > editions, crate name. It can be generated by shellscript which dumps such > information. However, I think it may be not preferable.OK, no problem. Rich.> Regards, > Hiroyuki > > 2019年7月4日(木) 19:39 Richard W.M. Jones <rjones@redhat.com>: > > > On Tue, Jul 02, 2019 at 10:09:00PM +0900, Hiroyuki Katsura wrote: > > > I fixed the patch I submitted before based on comments, and there are > > some > > > commits which are merged or divided. So, I will re-send all the patches. > > > > I looked at the v2 patches and I think they're in reasonable > > shape. > > > > There's been a lot of discussion of using ’git rebase --interactive’. > > I think that's a good thing, and also good practice if you're going to > > become a more frequent open source contributor. It helps people when > > they're reviewing patches. > > > > For this particular case I think we'd probably squash all the patches > > into a single commit when pushing them upstream. > > > > Have you decided whether we need to commit the generated files > > (Cargo.toml, Cargo.lock)? It looks like in this series those files > > are still included and not added to .gitignore. > > > > Rich. > > > > -- > > Richard Jones, Virtualization Group, Red Hat > > http://people.redhat.com/~rjones > > Read my programming and virtualization blog: http://rwmj.wordpress.com > > virt-builder quickly builds VMs from scratch > > http://libguestfs.org/virt-builder.1.html > >-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On Fri, Jul 05, 2019 at 08:37:20AM +0100, Richard W.M. Jones wrote:>On Fri, Jul 05, 2019 at 01:28:12PM +0900, Hiroyuki Katsura wrote: >> > Have you decided whether we need to commit the generated files >> > (Cargo.toml, Cargo.lock)? It looks like in this series those files >> > are still included and not added to .gitignore. >> >> I'm sorry I forgot adding Cargo.lock to .gitignore. I'll add it to >> .gitignore. However, I think Cargo.toml should be staged. This is because >> this is a file managed by hands. It contains dependencies, versions, >> editions, crate name. It can be generated by shellscript which dumps such >> information. However, I think it may be not preferable. > >OK, no problem. >Just one thing, the Cargo.toml includes a version under which the crate would be published. I presume the version would be the same as the one of the project itself, i.e. when releasing libguestfs-x.y.z, we publish guestfs-rs-x.y.z to crates.io. To make them in sync, it might be better to do it the same way nbdkit does it, having Cargo.toml.in which is taken and the version placeholder is replaced by the actual version.>Rich. > >> Regards, >> Hiroyuki >> >> 2019年7月4日(木) 19:39 Richard W.M. Jones <rjones@redhat.com>: >> >> > On Tue, Jul 02, 2019 at 10:09:00PM +0900, Hiroyuki Katsura wrote: >> > > I fixed the patch I submitted before based on comments, and there are >> > some >> > > commits which are merged or divided. So, I will re-send all the patches. >> > >> > I looked at the v2 patches and I think they're in reasonable >> > shape. >> > >> > There's been a lot of discussion of using ’git rebase --interactive’. >> > I think that's a good thing, and also good practice if you're going to >> > become a more frequent open source contributor. It helps people when >> > they're reviewing patches. >> > >> > For this particular case I think we'd probably squash all the patches >> > into a single commit when pushing them upstream. >> > >> > Have you decided whether we need to commit the generated files >> > (Cargo.toml, Cargo.lock)? It looks like in this series those files >> > are still included and not added to .gitignore. >> > >> > Rich. >> > >> > -- >> > Richard Jones, Virtualization Group, Red Hat >> > http://people.redhat.com/~rjones >> > Read my programming and virtualization blog: http://rwmj.wordpress.com >> > virt-builder quickly builds VMs from scratch >> > http://libguestfs.org/virt-builder.1.html >> > > >-- >Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones >Read my programming and virtualization blog: http://rwmj.wordpress.com >Fedora Windows cross-compiler. Compile Windows programs, test, and >build Windows installers. Over 100 libraries supported. >http://fedoraproject.org/wiki/MinGW
On Friday, 5 July 2019 06:28:12 CEST Hiroyuki Katsura wrote:> > Have you decided whether we need to commit the generated files > > (Cargo.toml, Cargo.lock)? It looks like in this series those files > > are still included and not added to .gitignore. > > I'm sorry I forgot adding Cargo.lock to .gitignore. I'll add it to > .gitignore. However, I think Cargo.toml should be staged. This is because > this is a file managed by hands. It contains dependencies, versions, > editions, crate name. It can be generated by shellscript which dumps such > information. However, I think it may be not preferable.Hmm, according to this official FAQ https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries the Cargo.lock file ought to be shipped only for binaries, and not for libraries (like the libguestfs binding). -- Pino Toscano