10:11 p.m.
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
8:12 a.m.
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
8:22 a.m.
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
12:09 p.m.
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.
4153
days inactive
4153
days old
3 comments
2 participants
participants (2)
-
Eric Blake -
Laine Stump