[Qemu-devel] [PATCH] .gitignore: remove vscclient

Marc-André Lureau posted 1 patch 6 years, 5 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20171106185411.19551-1-marcandre.lureau@redhat.com
Test checkpatch passed
Test docker passed
Test ppc passed
Test s390x passed
.gitignore | 1 -
1 file changed, 1 deletion(-)
[Qemu-devel] [PATCH] .gitignore: remove vscclient
Posted by Marc-André Lureau 6 years, 5 months ago
It was removed with libcacard.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 .gitignore | 1 -
 1 file changed, 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 588769b250..433f64f429 100644
--- a/.gitignore
+++ b/.gitignore
@@ -53,7 +53,6 @@
 /qemu-version.h.tmp
 /module_block.h
 /scsi/qemu-pr-helper
-/vscclient
 /vhost-user-scsi
 /fsdev/virtfs-proxy-helper
 *.tmp
-- 
2.15.0.rc0.40.gaefcc5f6f


Re: [Qemu-devel] [PATCH] .gitignore: remove vscclient
Posted by Eric Blake 6 years, 5 months ago
On 11/06/2017 12:54 PM, Marc-André Lureau wrote:
> It was removed with libcacard.

which was back in which commit?  I'm trying to get an idea of how long
this entry has been stale.

I'm not opposed to this patch, but I personally like to leave .gitignore
entries in place for several releases after they are last useful, to
make incremental builds easier when jumping around between old and new
branches across the point where the file was removed (as long as the new
branch still ignores the file, then building the file in the old branch
doesn't hurt the new branch).  Of course, if I'm that involved in
backporting madness across branches, I'm also fine updating my own
.git/info/exclude for cruft that is built in only one of two branches,
rather than relying on per-branch .gitignore to do it for me.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH] .gitignore: remove vscclient
Posted by Marc-André Lureau 6 years, 5 months ago

----- Original Message -----
> On 11/06/2017 12:54 PM, Marc-André Lureau wrote:
> > It was removed with libcacard.
> 
> which was back in which commit?  I'm trying to get an idea of how long
> this entry has been stale.

Since:

commit 7b02f5447c64d1854468f758398c9f6fe9e5721f
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date:   Sun Aug 30 11:48:40 2015 +0200

    libcacard: use the standalone project

> 
> I'm not opposed to this patch, but I personally like to leave .gitignore
> entries in place for several releases after they are last useful, to
> make incremental builds easier when jumping around between old and new
> branches across the point where the file was removed (as long as the new
> branch still ignores the file, then building the file in the old branch
> doesn't hurt the new branch).  Of course, if I'm that involved in
> backporting madness across branches, I'm also fine updating my own
> .git/info/exclude for cruft that is built in only one of two branches,
> rather than relying on per-branch .gitignore to do it for me.
> 
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 
> 

Re: [Qemu-devel] [PATCH] .gitignore: remove vscclient
Posted by Eric Blake 6 years, 5 months ago
On 11/06/2017 01:30 PM, Marc-André Lureau wrote:
> 
> 
> ----- Original Message -----
>> On 11/06/2017 12:54 PM, Marc-André Lureau wrote:
>>> It was removed with libcacard.
>>
>> which was back in which commit?  I'm trying to get an idea of how long
>> this entry has been stale.
> 
> Since:
> 
> commit 7b02f5447c64d1854468f758398c9f6fe9e5721f
> Author: Marc-André Lureau <marcandre.lureau@redhat.com>
> Date:   Sun Aug 30 11:48:40 2015 +0200
> 
>     libcacard: use the standalone project
> 
>>
>> I'm not opposed to this patch, but I personally like to leave .gitignore
>> entries in place for several releases after they are last useful, to
>> make incremental builds easier when jumping around between old and new
>> branches across the point where the file was removed (as long as the new
>> branch still ignores the file, then building the file in the old branch
>> doesn't hurt the new branch).  Of course, if I'm that involved in
>> backporting madness across branches, I'm also fine updating my own
>> .git/info/exclude for cruft that is built in only one of two branches,
>> rather than relying on per-branch .gitignore to do it for me.

Then this particular cleanup is definitely beyond the realm of any
backporting efforts I care about, and makes sense to me; but I'm still
leaving it weak enough that I won't add R-b (especially not without a
more verbose commit body), but I'm also okay if someone else wants to
add R-b to the patch as presented rather than waiting for a respin.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org