[libvirt] [PATCH] util: add rebase fix that was accidentally omitted from previous patch
I had made the change locally, so make check and make syntax-check were successful, but forgot to add/commit. Unfortunately, git allows a push when the local directory is dirty, so it didn't catch my mistake. --- Pushed under the build breaker rule. git *was* very informative when I tried to switch branches - *then* it complained about the uncommitted local changes. No problem to push with outstanding local changes though. That seems like a bug to me; is there any situation where that would be a desired thing? src/util/virpci.c | 2 +- src/util/virusb.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/virpci.c b/src/util/virpci.c index ed55b80..3fa4a35 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -1669,7 +1669,7 @@ virPCIDeviceListAdd(virPCIDeviceListPtr list, _("Device %s is already in use"), dev->name); return -1; } - return VIR_APPEND_ELEMENT(list->devs, list->count, dev, true); + return VIR_APPEND_ELEMENT(list->devs, list->count, dev); } diff --git a/src/util/virusb.c b/src/util/virusb.c index 60222f4..e901618 100644 --- a/src/util/virusb.c +++ b/src/util/virusb.c @@ -450,7 +450,7 @@ virUSBDeviceListAdd(virUSBDeviceListPtr list, dev->name); return -1; } - return VIR_APPEND_ELEMENT(list->devs, list->count, dev, true); + return VIR_APPEND_ELEMENT(list->devs, list->count, dev); } virUSBDevicePtr -- 1.7.11.7
On 07/10/2013 09:11 PM, Laine Stump wrote:
I had made the change locally, so make check and make syntax-check were successful, but forgot to add/commit. Unfortunately, git allows a push when the local directory is dirty, so it didn't catch my mistake.
I also got bit by a similar situation yesterday, on another list - but with send-email instead of push.
--- Pushed under the build breaker rule.
git *was* very informative when I tried to switch branches - *then* it complained about the uncommitted local changes. No problem to push with outstanding local changes though. That seems like a bug to me; is there any situation where that would be a desired thing?
Yes, it can be reasonable to push a patch while the tree is still dirty for unrelated reasons. But I agree that it seems like an advanced option, and that most users would much rather be informed any time 'send-email' or 'push' is attempted while changes are still pending, especially if the changes being emailed or pushed touch the same files. There's probably a way to set up git hooks to forbid push actions if the tree is dirty, but that would be a question for the git lists or irc channel. If either one of us finds a solution for such a hook, be sure to post it back here. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 07/11/2013 07:12 AM, Eric Blake wrote:
Yes, it can be reasonable to push a patch while the tree is still dirty for unrelated reasons. But I agree that it seems like an advanced option, and that most users would much rather be informed any time 'send-email' or 'push' is attempted while changes are still pending, especially if the changes being emailed or pushed touch the same files. There's probably a way to set up git hooks to forbid push actions if the tree is dirty, but that would be a question for the git lists or irc channel.
If either one of us finds a solution for such a hook, be sure to post it back here.
The git IRC channel suggested setting your shell prompt to call the various bash functions made available by git, so that you at least have a designation in your prompt of what branch you are on and whether it is clean or dirty. Of course, that assumes you look at your prompt before sending/pushing, but with blatant enough coloring differences between clean and dirty states, a prompt is at least a visual clue, even if not a hard rule. I'm still trying to figure out if a hard rule is enforceable, though... -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 07/11/2013 09:22 AM, Eric Blake wrote:
On 07/11/2013 07:12 AM, Eric Blake wrote:
Yes, it can be reasonable to push a patch while the tree is still dirty for unrelated reasons. But I agree that it seems like an advanced option, and that most users would much rather be informed any time 'send-email' or 'push' is attempted while changes are still pending, especially if the changes being emailed or pushed touch the same files. There's probably a way to set up git hooks to forbid push actions if the tree is dirty, but that would be a question for the git lists or irc channel.
If either one of us finds a solution for such a hook, be sure to post it back here. The git IRC channel suggested setting your shell prompt to call the various bash functions made available by git, so that you at least have a designation in your prompt of what branch you are on and whether it is clean or dirty. Of course, that assumes you look at your prompt before sending/pushing,
Yeah, I already do that, but it's not colorized, which is a good idea. I tend to miss visual clues when I'm in a hurry though, so definitely a solution that actually *prevents* the dangerous operation would be better.
participants (2)
-
Eric Blake -
Laine Stump