* Re: Revert option for git add --patch
From: Nguyen Thai Ngoc Duy @ 2012-11-08 12:00 UTC (permalink / raw)
To: Jonathon Mah; +Cc: git@vger.kernel.org, Nathan Broadbent
In-Reply-To: <EE89F0A1-1C07-4597-B654-035F657AD09F@me.com>
On Thu, Nov 8, 2012 at 3:57 PM, Jonathon Mah <jmah@me.com> wrote:
> Nathan,
>
> I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p).
I agree. I'd be really nice to have an interactive command about hunk
manipulation between HEAD (or some other ref), index and worktree in
both directions (except writing to HEAD, of course). This reminds me
of the "git put" discussion a while ago, which also moves code between
different locations..
--
Duy
^ permalink raw reply
* Re: [RFC] Add a new email notification script to "contrib"
From: Ævar Arnfjörð Bjarmason @ 2012-11-08 11:39 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Andy Parkins, Sitaram Chamarty, Stefan Näwe,
Junio C Hamano, Marc Branchaud, Matthieu Moy
In-Reply-To: <509B7E6B.1030407@alum.mit.edu>
On Thu, Nov 8, 2012 at 10:42 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
>> I'm curious as to whether you got around to this? I'd be interested in
>> updates on this script.
>
> Thanks for asking. I have made many of the changes that were requested
> and/or I had planned:
I was playing around with it for some work repos last night.
> * Tentatively renamed the system to git-multimail
>
> * Store the configuration in namespace "multimailhook.*" instead of
> "hooks.*".
Great, I had made this change locally myself, makes it much easier to
keep the configuration separate, and I think doing and having a
migration script is better than using the original config variables.
> * Reinstated (optional) support for including shortlogs since the last
> tag in announce emails.
>
> * Script to migrate post-receive-email configuration to the equivalent
> git-multimail config.
>
> * Better documentation (including of the migration process).
>
> * Made it easier to use Python code to customize the script's behavior
> (by allowing it to be imported as a Python module), plus a demo script
> showing this usage.
That's very nice, I was monkeypatching the script to overwrite some
templates. This makes that easy.
> * Some primitive testing tools to generate a test git repository and
> generate many kinds of notification emails (though the emails still have
> to be checked manually for correctness).
>
> Nevertheless I think that the script is quite usable as it is and it
> would be great if other people could try it out, give feedback, and even
> submit patches.
I'll test it out some more, the issues I've had with it so far in
migrating from the existing script + some custom hacks we have to it
have been:
* Overly verbose default templates, easy to overwrite now. Might send
patches for some of them.
* No ability to link to a custom gitweb, probably easy now.
* If someone only pushes one commit I'd like to only have one e-mail
with the diff, but if they push multiple commits I'd like to have a
summary e-mail and replies to that which have the patches.
It only seemed to support the latter mode, so you send out two
e-mails for pushing one commit.
* Ability to limit the number of lines, but not line length, that's
handy for some template repositories. Should be easy to add
* I wanted a hook to override the options passed to sendmail in some
cases, looks easier now with the modular design.
But in addition to that we have our own custom E-Mail notification
scripts for:
* People can subscribe to changes to certain files. I.e. if you
modify very_important.c we'll send an E-Mail to a more widely seen
review list.
* Invididuals can also edit a config file to watch individual files /
glob patterns of files, e.g. src/main.c or src/crypto*
I think a good way to support that would be to have either a path to a
config file with those watch specs, or a command so you could run "git
show ..." on some repo users can push to.
But overall it's very nice. I'll make some time to test it in my
organization (with lots of commits and people reading commit e-mails).
^ permalink raw reply
* bare vs non-bare <1.7 then >=1.7 ?
From: Mihamina Rakotomandimby @ 2012-11-08 10:11 UTC (permalink / raw)
To: Git Issues
Hi all,
We're on the way to have our first project using Git.
We're currently mostly using Hg (90%) & SVN (10%).
When experimenting in order to train some colleagues, I saw that If I
clone a repository, I couldn't push to it because it was a non-bare one.
Searchin for some explanations, I found this ressource:
http://www.bitflop.com/document/111
It's told to be reliable information for Git < v1.7.
What would be different for Git > 1.7 so that I could be up to date with
the facts?
Thank you.
--
RMA.
^ permalink raw reply
* Re: [RFC] Add a new email notification script to "contrib"
From: Michael Haggerty @ 2012-11-08 9:42 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Andy Parkins, Sitaram Chamarty, Stefan Näwe,
Junio C Hamano, Marc Branchaud, Matthieu Moy
In-Reply-To: <CACBZZX6=e6_qO=wMcxLdUAc6XxYpdiP-9RPRsCXrVC_iuJ11Jg@mail.gmail.com>
On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 07/14/2012 08:59 AM, mhagger@alum.mit.edu wrote:
>>>
>>> Add a new Python script, contrib/hooks/post-receive-multimail.py, that
>>> can be used to send notification emails describing pushes into a git
>>> repository. [...]
>>
>>
>> Thanks to everybody for your feedback. I will try to incorporate it in a
>> new version of the script, which I will put forward as a replacement for
>> contrib/hooks/post-receive-email rather than as an alternative. But I have
>> very little open-sourcing time these days, and will be on vacation next
>> week, so please be patient (or feel free to lend a hand if you are so
>> inclined).
>
> I'm curious as to whether you got around to this? I'd be interested in
> updates on this script.
Thanks for asking. I have made many of the changes that were requested
and/or I had planned:
* Tentatively renamed the system to git-multimail
* Store the configuration in namespace "multimailhook.*" instead of
"hooks.*".
* Reinstated (optional) support for including shortlogs since the last
tag in announce emails.
* Script to migrate post-receive-email configuration to the equivalent
git-multimail config.
* Better documentation (including of the migration process).
* Made it easier to use Python code to customize the script's behavior
(by allowing it to be imported as a Python module), plus a demo script
showing this usage.
* Some primitive testing tools to generate a test git repository and
generate many kinds of notification emails (though the emails still have
to be checked manually for correctness).
But I haven't submitted the new version because I just haven't had a
good block of time to really wrap it up and call it a "final" version.
One remaining question is how to fit it into the git source tree along
with its supporting materials (or even whether to maintain it as a
separate project).
Nevertheless I think that the script is quite usable as it is and it
would be great if other people could try it out, give feedback, and even
submit patches.
So I just created a github repository containing my current version:
https://github.com/mhagger/git-multimail
Enjoy!
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Revert option for git add --patch
From: Jonathon Mah @ 2012-11-08 8:57 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Nathan Broadbent
Nathan,
I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p).
The interactive staging-and-editing tool could be improved, but I'm not sure that tool should be called 'git add -p'. git add doesn't touch the working tree — at least I hope not, because I wouldn't expect it.
But I eagerly support more discussion. If someone does want to add this feature to "git add -p" (or named differently), I'll add a request for another letter (perhaps '!') to edit the hunk in the working tree.
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply
* Re: Revert option for git add --patch
From: Michal Kiedrowicz @ 2012-11-08 8:46 UTC (permalink / raw)
To: git
In-Reply-To: <CAPXHQbN0x-o_4rQO-Lq_gDTqs=beBE5XrrzJ1Th+7G2Lq7Dh_Q@mail.gmail.com>
Nathan Broadbent <nathan.f77 <at> gmail.com> writes:
> I would like to propose a revert option for 'git add --patch', that
> reverts the hunk. I often use `git add -p` to skip whitespace changes
> when preparing a patch, and a 'revert' option would save me from
> running 'git checkout <file>' after I've staged the desired changes.
Doesn't `git checkout -p` do what you describe?
Kind regards,
Michal Kiedrowicz
^ permalink raw reply
* Re: Revert option for git add --patch
From: Simon Rozet @ 2012-11-08 1:00 UTC (permalink / raw)
To: git
In-Reply-To: <CAPXHQbN0x-o_4rQO-Lq_gDTqs=beBE5XrrzJ1Th+7G2Lq7Dh_Q@mail.gmail.com>
help
On Wed, Nov 7, 2012 at 3:54 PM, Nathan Broadbent <nathan.f77@gmail.com> wrote:
> Hi,
>
> I would like to propose a revert option for 'git add --patch', that
> reverts the hunk. I often use `git add -p` to skip whitespace changes
> when preparing a patch, and a 'revert' option would save me from
> running 'git checkout <file>' after I've staged the desired changes.
>
> I would propose adding r and R options for the 'Stage this hunk' menu,
> with the following actions:
>
> r: Revert this hunk
> R: Revert this hunk and all other remaining hunks
>
> e.g. Stage this hunk [y/n/a/d/K/j/J/e/r/R?]?
>
>
> Please let me know if you think this is a good idea.
>
>
> Best,
> Nathan
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Revert option for git add --patch
From: Nathan Broadbent @ 2012-11-07 23:54 UTC (permalink / raw)
To: git
In-Reply-To: <CAPXHQbOxNG0XN80rH6mM6iSVtCtU26Yio_XQ=5ofBHBpZN3VyQ@mail.gmail.com>
Hi,
I would like to propose a revert option for 'git add --patch', that
reverts the hunk. I often use `git add -p` to skip whitespace changes
when preparing a patch, and a 'revert' option would save me from
running 'git checkout <file>' after I've staged the desired changes.
I would propose adding r and R options for the 'Stage this hunk' menu,
with the following actions:
r: Revert this hunk
R: Revert this hunk and all other remaining hunks
e.g. Stage this hunk [y/n/a/d/K/j/J/e/r/R?]?
Please let me know if you think this is a good idea.
Best,
Nathan
^ permalink raw reply
* Re: What about SHA-1 collisions?
From: Andrew Ardill @ 2012-11-07 23:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Josef Wolf, git
In-Reply-To: <CAJo=hJtF2+Z1BDQnysB7hk2MM336iEUMHd3zSLCm14yvw1_-wg@mail.gmail.com>
A recent article [1] did an analysis on the number of items needed
from a given range to have a 50% chance of a collision. The famous
birthday paradox scenario was used, where you only need 23 people
before the chance of two of them having the same birthday is over 50%.
In this scenario there are ~366 options available to be picked from,
and 23 is significantly small in comparison.
The mathematics behind these statistics was extended to account for
any sized range (call it N) and it turns out that the number of items
(k) that can be picked before you have exceeded a given percentage
chance (T) of _not_ having a collision is roughly
k ~= sqrt(-2N.ln(T))
As pedrocr pointed out on Hacker News [2]
"Applying the formula for 160bit SHA-1 you need 1.7e23 objects to get
a 1% chance of collision. The current Linus kernel repository has 2.7
million objects. So to get a collision you'd need a repository that's
6e16 times larger. That should be plenty.
For some wacky perspective that's 10 million kernel sized
contributions for every man woman and child on earth together in a
single repository. It would seem git will reach plenty of other
bottlenecks before SHA-1 becomes a problem..."
An interesting analysis, even given that the OP presumes a collision
in their question.
Regards,
Andrew Ardill
[1] http://www.solipsys.co.uk/new/TheBirthdayParadox.html
[2] http://news.ycombinator.com/item?id=4753198
^ permalink raw reply
* Re: [PATCH/RFC] launch_editor: ignore SIGINT while the editor has control
From: Paul Fox @ 2012-11-07 23:35 UTC (permalink / raw)
To: git; +Cc: Krzysztof Mazur, gitster
In-Reply-To: <20121107220027.GA17463@shrek.podlesie.net>
the user's editor likely catches SIGINT (ctrl-C). but if the user
spawns a command from the editor and uses ctrl-C to kill that command,
the SIGINT will likely also kill git itself. (depending on the
editor, this can leave the terminal in an unusable state.)
Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
---
krzysztof wrote:
...
> editor.c: In function 'launch_editor':
> editor.c:42:3: warning: implicit declaration of function 'sigchain_push' [-Wimplicit-function-declaration]
> editor.c:44:3: warning: implicit declaration of function 'sigchain_pop' [-Wimplicit-function-declaration]
sigh. i had that initially, lost the patch, and then recreated
without it. but i'm surprised my build (i did rebuild! :-) doesn't
emit those errors. in any case, here's the fixed patch.
editor.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/editor.c b/editor.c
index d834003..3ca361b 100644
--- a/editor.c
+++ b/editor.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "strbuf.h"
#include "run-command.h"
+#include "sigchain.h"
#ifndef DEFAULT_EDITOR
#define DEFAULT_EDITOR "vi"
@@ -37,8 +38,12 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
+ int ret;
- if (run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env))
+ sigchain_push(SIGINT, SIG_IGN);
+ ret = run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env);
+ sigchain_pop(SIGINT);
+ if (ret)
return error("There was a problem with the editor '%s'.",
editor);
}
--
1.7.5.4
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 26.6 degrees)
^ permalink raw reply related
* Re: [PATCH/RFC] launch_editor: ignore SIGINT while the editor has control
From: Krzysztof Mazur @ 2012-11-07 22:00 UTC (permalink / raw)
To: Paul Fox; +Cc: git, gitster
In-Reply-To: <20121107191652.842C52E8089@grass.foxharp.boston.ma.us>
On Wed, Nov 07, 2012 at 02:16:52PM -0500, Paul Fox wrote:
> the user's editor likely catches SIGINT (ctrl-C). but if the user
> spawns a command from the editor and uses ctrl-C to kill that command,
> the SIGINT will likely also kill git itself. (depending on the
> editor, this can leave the terminal in an unusable state.)
>
> Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
>
> editor.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/editor.c b/editor.c
> index d834003..775f22d 100644
> --- a/editor.c
> +++ b/editor.c
> @@ -37,8 +37,12 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
>
> if (strcmp(editor, ":")) {
> const char *args[] = { editor, path, NULL };
> + int ret;
>
> - if (run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env))
> + sigchain_push(SIGINT, SIG_IGN);
> + ret = run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env);
> + sigchain_pop(SIGINT);
> + if (ret)
> return error("There was a problem with the editor '%s'.",
> editor);
> }
Looks and works good, except for warnings:
editor.c: In function 'launch_editor':
editor.c:42:3: warning: implicit declaration of function 'sigchain_push' [-Wimplicit-function-declaration]
editor.c:44:3: warning: implicit declaration of function 'sigchain_pop' [-Wimplicit-function-declaration]
"sigchain.h" should be included, something like:
diff --git a/editor.c b/editor.c
index 775f22d..3ca361b 100644
--- a/editor.c
+++ b/editor.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "strbuf.h"
#include "run-command.h"
+#include "sigchain.h"
#ifndef DEFAULT_EDITOR
#define DEFAULT_EDITOR "vi"
Krzysiek
^ permalink raw reply related
* Re: [RFC] Add a new email notification script to "contrib"
From: Ævar Arnfjörð Bjarmason @ 2012-11-07 21:47 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Andy Parkins, Sitaram Chamarty, Stefan Näwe,
Junio C Hamano, Marc Branchaud, Matthieu Moy
In-Reply-To: <50092C8C.3000305@alum.mit.edu>
On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 07/14/2012 08:59 AM, mhagger@alum.mit.edu wrote:
>>
>> Add a new Python script, contrib/hooks/post-receive-multimail.py, that
>> can be used to send notification emails describing pushes into a git
>> repository. [...]
>
>
> Thanks to everybody for your feedback. I will try to incorporate it in a
> new version of the script, which I will put forward as a replacement for
> contrib/hooks/post-receive-email rather than as an alternative. But I have
> very little open-sourcing time these days, and will be on vacation next
> week, so please be patient (or feel free to lend a hand if you are so
> inclined).
I'm curious as to whether you got around to this? I'd be interested in
updates on this script.
^ permalink raw reply
* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Jeff King @ 2012-11-07 21:13 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: git, Junio C Hamano
In-Reply-To: <509ACE63.9070007@arcor.de>
On Wed, Nov 07, 2012 at 10:10:59PM +0100, Peter Oberndorfer wrote:
> >> For me the key to reproduce the problem was to have 2 commits.
> >> Adding the file in the root commit it did not work. [1]
> > You probably would need to pass "--root" for it to do the diff of the
> > initial commit.
> >
> > The patch below fixes it, but it's terribly inefficient (it just detects
> > the situation and reallocates). It would be much better to disable the
> > reuse_worktree_file mmap when we populate the filespec, but it is too
> > late to pass an option; we may have already populated from an earlier
> > diffcore stage.
> Hi,
> I tested your patch, and i can confirm it fixes the problem for me.
> (also on my real world test in msysgit)
Thanks for the report. I'd still like to pursue using a regex library
that does not require NUL-termination, but I've been distracted by other
things. I'm going to hold back my copy-to-a-NUL-buffer patch for now and
see if I can get to the regex thing this week.
-Peff
^ permalink raw reply
* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Peter Oberndorfer @ 2012-11-07 21:10 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20121029223521.GJ20513@sigill.intra.peff.net>
On 2012-10-29 23:35, Jeff King wrote:
> On Mon, Oct 29, 2012 at 09:19:48PM +0100, Peter Oberndorfer wrote:
>
>> I could reproduce with my 0x3000 bytes file on linux. The buffer is not
>> read with a trailing null byte it is mapped by mmap in
>> diff_populate_filespec...
>> So i think we will not get away with expecting a trailing null :-/
> Thanks for the reproduction recipe. I was testing with "git log", which
> does not use the mmap optimization.
>
>> For me the key to reproduce the problem was to have 2 commits.
>> Adding the file in the root commit it did not work. [1]
> You probably would need to pass "--root" for it to do the diff of the
> initial commit.
>
> The patch below fixes it, but it's terribly inefficient (it just detects
> the situation and reallocates). It would be much better to disable the
> reuse_worktree_file mmap when we populate the filespec, but it is too
> late to pass an option; we may have already populated from an earlier
> diffcore stage.
Hi,
I tested your patch, and i can confirm it fixes the problem for me.
(also on my real world test in msysgit)
Again, thanks a lot!
Greetings Peter
> I guess if we teach the whole diff code that "-G" (and --pickaxe-regex)
> is brittle, we can disable the optimization from the beginning based on
> the diff options. I'll take a look.
>
> <snip patch>
^ permalink raw reply
* Re: [PATCHv2 2/2] git p4: add support for 'p4 move' in P4Submit
From: Vitor Antunes @ 2012-11-07 21:06 UTC (permalink / raw)
To: Pete Wyckoff, ggibons; +Cc: Git Mailing List
In-Reply-To: <20121105175724.GB889@padd.com>
On Mon, Nov 5, 2012 at 5:57 PM, Pete Wyckoff <pw@padd.com> wrote:
> vitor.hda@gmail.com wrote on Mon, 05 Nov 2012 17:37 +0000:
>> Hi Pete,
>>
>> I've just been hit by a situation where this command is available but is
>> disabled in the server. I don't know what is the best approach to avoid
>> this issue.
>
> Really? The command exists in the server because it returns the
> text output for "p4 help move". But "p4 move" itself fails
> because it is somehow disabled in the server?
>
> I didn't even know it was possible to administratively disable
> commands.
>
> What's the actual error message? And versions of your client and
> server (p4 -V, p4d -V, p4 info).
>
> Any ideas Gary?
I don't feel comfortable in testing this again because I'm working in a
production server. Can Gary provide any details on this type of
configuration on the server side?
Vitor
^ permalink raw reply
* Re: [PATCH 14/13] wildmatch: fix tests that fail on Windows due to path mangling
From: Johannes Sixt @ 2012-11-07 19:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <CACsJy8DEH53mA4fDyZwbVsbyGcNY8b54Sn1p5-rto6r_h48dkA@mail.gmail.com>
Am 06.11.2012 13:47, schrieb Nguyen Thai Ngoc Duy:
> On Mon, Nov 5, 2012 at 4:00 AM, Johannes Sixt <j6t@kdbg.org> wrote:
>> Patterns beginning with a slash are converted to Windows paths before
>> test-wildmatch gets to see them. Use a different first character.
>
> Or we could prepend the paths with something, which is then cut out by
> test-wildmatch. Not sure if it's intuitive to look at the tests
> though.
That would be a possibility, too.
>> After this change, there are still 3 failing tests that are in connection
>> with [[:xdigit:]]. Don't know, yet, what's going on there.
>
> the wildmatch tests or fnmatch ones?
fnmatch ones:
ok 147 - wildmatch: match '5' '[[:xdigit:]]'
not ok 148 - fnmatch: match '5' '[[:xdigit:]]'
#
# test-wildmatch fnmatch '5' '[[:xdigit:]]'
#
ok 149 - wildmatch: match 'f' '[[:xdigit:]]'
not ok 150 - fnmatch: match 'f' '[[:xdigit:]]'
#
# test-wildmatch fnmatch 'f' '[[:xdigit:]]'
#
ok 151 - wildmatch: match 'D' '[[:xdigit:]]'
not ok 152 - fnmatch: match 'D' '[[:xdigit:]]'
#
# test-wildmatch fnmatch 'D' '[[:xdigit:]]'
#
She same tests fail on Linux, BTW, when built with NO_FNMATCH=1 and the
"#if defined _LIBC || !defined __GNU_LIBRARY__" brackets removed.
-- Hannes
^ permalink raw reply
* [PATCH/RFC] launch_editor: ignore SIGINT while the editor has control
From: Paul Fox @ 2012-11-07 19:16 UTC (permalink / raw)
To: git; +Cc: gitster
the user's editor likely catches SIGINT (ctrl-C). but if the user
spawns a command from the editor and uses ctrl-C to kill that command,
the SIGINT will likely also kill git itself. (depending on the
editor, this can leave the terminal in an unusable state.)
Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
---
i often shell out of my editor while composing a git commit message,
in order to recheck the diffs or the log, do a final test build, etc.
when i interrupt one of these operations, the spawned program gets
killed. in addition git itself gets killed, which in turn kills my
editor. this is never what i intended. :-)
the problem is easy to demonstrate with vim, vile, or em. in a vi-like
editor:
git commit foo
:!sleep 10
^C
both CVS and my usual mailer (MH) protect against this behavior when
spawning editors by using code similar to the patch below, which
causes the spawning process to ignore SIGINT while the editor is
running.
i looked at the other invocations of run_command_v_opt_xxx() in git,
but couldn't convince myself that any of the others needed similar
protection. i also couldn't convince myself that i wouldn't cause
collateral damage if i tried moving the sigchain_push/pop into
run-command.c. (but perhaps it's simple -- maybe the RUN_USING_SHELL
flag should always imply this behavior.)
the patch is against current master.
paul
editor.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/editor.c b/editor.c
index d834003..775f22d 100644
--- a/editor.c
+++ b/editor.c
@@ -37,8 +37,12 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
+ int ret;
- if (run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env))
+ sigchain_push(SIGINT, SIG_IGN);
+ ret = run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env);
+ sigchain_pop(SIGINT);
+ if (ret)
return error("There was a problem with the editor '%s'.",
editor);
}
--
1.7.5.4
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 31.8 degrees)
^ permalink raw reply related
* Re: Long clone time after "done."
From: Uri Moszkowicz @ 2012-11-07 17:32 UTC (permalink / raw)
To: git
In-Reply-To: <CAMJd5AQBbnFqT5xrFuPOEsJevwDE=jUgBVFZ5KqTZk5zv5+NOw@mail.gmail.com>
To elaborate from before, my repository is about 2GB and has about 7k
branches and tags with 15 years of history imported from CVS. I
created a toy repository attempting to replicate the problem but
haven't had any luck so instead I launched Git in a debugger to see
what operation is taking so long in "git clone". I stopped randomly in
the middle and stepped to the line which seems to be contributing the
most:
#0 read_packed_sha1 (sha1=0xb0ee98
"\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D",
type=0x7fbfffe7a4, size=0x7fbfffe798) at sha1_file.c:2237
#1 0x00000000004d366e in read_object (sha1=0xb0ee98
"\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D",
type=0x7fbfffe7a4, size=0x7fbfffe798) at sha1_file.c:2277
#2 0x00000000004d3839 in read_sha1_file_extended (sha1=0xb0ee98
"\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D",
type=0x7fbfffe7a4, size=0x7fbfffe798, flag=<optimized out>) at
sha1_file.c:2307
#3 0x00000000004ae000 in read_sha1_file (sha1=0x7fbfffc5e0 "",
type=0x6be000, size=0x2b039b9010) at cache.h:730
#4 parse_object (sha1=0xb0ee98
"\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D") at
object.c:212
#5 0x00000000004ae9ec in handle_one_ref (path=0xb0eec0
"refs/tags/<removed>", sha1=0xb0ee98
"\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D", flags=2,
cb_data=<optimized out>) at pack-refs.
#6 0x00000000004bc402 in do_one_ref (base=<optimized out>,
fn=0x4ae8f0 <handle_one_ref>, trim=<optimized out>, flags=0,
cb_data=0x7fbfffe9c0, entry=0xb0ee90) at refs.c:527
#7 0x00000000004bd38b in do_for_each_ref_in_dir (dir=0xb09be8,
offset=<optimized out>, base=0x4fd9b0 "", fn=0x4ae8f0
<handle_one_ref>, trim=0, flags=0, cb_data=0x7fbfffe9c0) at refs.c:553
#8 0x00000000004bd6cb in do_for_each_ref_in_dirs (dir1=0x6a8588,
dir2=0xb0ab18, base=0x4fd9b0 "", fn=0x4ae8f0 <handle_one_ref>, trim=0,
flags=0, cb_data=0x7fbfffe9c0) at refs.c:599
#9 0x00000000004bd6cb in do_for_each_ref_in_dirs (dir1=0x6a3118,
dir2=0xb038b8, base=0x4fd9b0 "", fn=0x4ae8f0 <handle_one_ref>, trim=0,
flags=0, cb_data=0x7fbfffe9c0) at refs.c:599
#10 0x00000000004bdb3f in do_for_each_ref (submodule=<optimized
out>, base=0x4fd9b0 "", fn=0x4ae8f0 <handle_one_ref>, trim=0, flags=0,
cb_data=0x7fbfffe9c0) at refs.c:1288
#11 0x00000000004aeaba in pack_refs (flags=<optimized out>) at pack-refs.c:133
#12 0x000000000041da30 in write_remote_refs (local_refs=<optimized
out>) at builtin/clone.c:470
#13 update_remote_refs (refs=<optimized out>, mapped_refs=<optimized
out>, remote_head_points_at=<optimized out>, branch_top=0x6a4210
"refs/remotes/origin/", msg=0x6a1160 "clone: from
/z/umoszkow/git/clone/../merged/merged.git") at bu
#14 cmd_clone (argc=<optimized out>, argv=0x7fbffff1b0,
prefix=<optimized out>) at builtin/clone.c:898
#15 0x0000000000404eef in handle_internal_command (argc=3,
argv=0x7fbffff1b0) at git.c:306
#16 0x0000000000405347 in run_argv (argcp=<optimized out>,
argv=<optimized out>) at git.c:513
#17 main (argc=3, argv=0x7fbffff1b0) at git.c:588
It looks like handle_one_ref() is called for each ref and most result
in a call to read_sha1_file(). It only takes a second or so for each
call but when you have thousands of them (one for each ref) it adds
up. Adding --single-branch --branch <branch> doesn't appear to help as
it is implemented afterwards. I would like to debug this problem
further but am not familiar enough with the implementation to know
what the next step is. Can anyone offer some suggestions? I don't see
why a clone should be dependent on an O(#refs) operations.
On Tue, Oct 23, 2012 at 1:30 PM, Uri Moszkowicz <uri@4refs.com> wrote:
> I have a large repository which I ran "git gc --aggressive" on that
> I'm trying to clone on a local file system. I would expect it to
> complete very quickly with hard links but it's taking about 6min to
> complete with no checkout (git clone -n). I see the message "Clining
> into 'repos'... done." appear after a few seconds but then Git just
> hangs there for another 6min. Any idea what it's doing at this point
> and how I can speed it up?
^ permalink raw reply
* Re: Workflow for templates?
From: Holger Hellmuth (IKS) @ 2012-11-07 16:03 UTC (permalink / raw)
To: Josef Wolf, git@vger.kernel.org
In-Reply-To: <20121106210719.GG28437@raven.wolf.lan>
Am 06.11.2012 22:07, schrieb Josef Wolf:
> On Tue, Nov 06, 2012 at 08:21:25PM +0000, Pyeron, Jason J CTR (US) wrote:
>> Maybe I lost sight of your problem. Can you give a specific example of where "it" does not work?
>
> I guess it's _me_ who's lost. I can't figure how this is supposed to
> work. Maybe you have an example?
Let me ask a different question: What is wrong with cherry-picking
downstream changes to your upstream branch? Without rebasing it to
downstream.
That might mean there is a rather useless merge downstream later on, but
that's the price you pay for not doing the change in a development branch.
^ permalink raw reply
* Re: git-clone and unreliable links?
From: Shawn Pearce @ 2012-11-07 15:54 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20121107153519.GI28437@raven.wolf.lan>
On Wed, Nov 7, 2012 at 7:35 AM, Josef Wolf <jw@raven.inka.de> wrote:
> When using git-clone over an unreliable link (say, UMTS) and the network goes
> down, git-clone deletes everything what was downloaded. When the network goes
> up again and you restart git-clone, it has to start over from the
> beginning. Then, eventually, the network goes down again, and everything is
> deleted again.
>
> Is there a way to omit the deleting step, so the second invocation would start
> where the first invocation was interrupted?
No, because a clone is not resumable.
The best way to obtain a repository over an unstable link is to ask
the repository owner to make a bundle file with `git bundle create
--heads --tags` and serve the file using standard HTTP or rsync, which
are resumable protocols. After you download the file, you can clone or
fetch from the bundle to initialize your local repository, and then
run git fetch to incrementally update to anything that is more recent
than the bundle's creation.
^ permalink raw reply
* Re: What about SHA-1 collisions?
From: Shawn Pearce @ 2012-11-07 15:42 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20121106220938.GH28437@raven.wolf.lan>
On Tue, Nov 6, 2012 at 2:09 PM, Josef Wolf <jw@raven.inka.de> wrote:
>
> On Tue, Nov 06, 2012 at 09:41:29PM +0000, John McKown wrote:
> > Josef Wolf <jw <at> raven.inka.de> writes:
> > > Just for curiosity: what would happen if such a collision would occur within
> > > one repository?
>
> > In a sense, this cannot happen.
>
> In the scenario you described, contents of this version of file "b" are lost
> and replaced by the contents of file "a". So file "b" is broken.
>
> What happens when files "a" and "b" are added into different repositories?
> File "a" is added to repos "A", and file "b" is added to repos "B". Now it
> depends from which repository you fetch the collided blob first. If you fetch
> it from "A", file "b" will be broken. If you fetch first from "B", your "a"
> will be broken.
>
> It becomes even more interesting, if some commit or tree object would have
> the same SHA1 as some other object. I guess, in such a case the repository
> would be completely hosed?
When exchanging objects over the network, Git compares byte-for-byte
any object that one side sent that the other side already has, and
complains loudly when there is a collision detected. This only works
if the sender includes the "wrong" content for the named object. Git
also does assume the SHA-1 is unique and that it is not always
necessary to transmit the object. In these cases you would not be able
to detect the collision, because there isn't one. Your repository
would simply be using the wrong content for a file. Presumably one
would notice your build doesn't work anymore and investigate why.
^ permalink raw reply
* git-clone and unreliable links?
From: Josef Wolf @ 2012-11-07 15:35 UTC (permalink / raw)
To: git
Hello,
When using git-clone over an unreliable link (say, UMTS) and the network goes
down, git-clone deletes everything what was downloaded. When the network goes
up again and you restart git-clone, it has to start over from the
beginning. Then, eventually, the network goes down again, and everything is
deleted again.
Is there a way to omit the deleting step, so the second invocation would start
where the first invocation was interrupted?
^ permalink raw reply
* Re: [PATCH] push/pull: adjust missing upstream help text to changed interface
From: Jeff King @ 2012-11-07 10:44 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git, Jeroen van der Ham
In-Reply-To: <509A1A4E.5060805@drmicha.warpmail.net>
On Wed, Nov 07, 2012 at 09:22:38AM +0100, Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 06.11.2012 15:45:
> >
> >
> > Michael J Gruber <git@drmicha.warpmail.net> wrote:
> >
> >> Yes, I'm in low hanging fruits mood.
> >>
> >> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> >
> > It is called tying loose ends, and is very important. Very much appreciated.
>
> ;)
>
> By the way: The gotcha with the signed-off-by after the note is due to
> my old format-patch-notes being tripped up by the recent restructuring;
> your version in next get's it right. I've dumped my old branch, and I
> hope the maintainer in chief will shuffle around the s-o-b where it belongs.
Yes, will do. Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH] push/pull: adjust missing upstream help text to changed interface
From: Michael J Gruber @ 2012-11-07 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeroen van der Ham, Jeff King
In-Reply-To: <03ff9252-71dc-4c28-a542-d65d16ba6549@email.android.com>
Junio C Hamano venit, vidit, dixit 06.11.2012 15:45:
>
>
> Michael J Gruber <git@drmicha.warpmail.net> wrote:
>
>> Yes, I'm in low hanging fruits mood.
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>
> It is called tying loose ends, and is very important. Very much appreciated.
;)
By the way: The gotcha with the signed-off-by after the note is due to
my old format-patch-notes being tripped up by the recent restructuring;
your version in next get's it right. I've dumped my old branch, and I
hope the maintainer in chief will shuffle around the s-o-b where it belongs.
Michael
^ permalink raw reply
* Re: why '--init' in git-submodule update
From: Francis Moreau @ 2012-11-07 7:10 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20121105213004.GA2797@book.hvoigt.net>
Hi,
On Mon, Nov 5, 2012 at 10:30 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> Hi,
>
> On Mon, Nov 05, 2012 at 05:30:51PM +0100, Francis Moreau wrote:
>> I'm wondering why the --init option from git-submodule-update is not
>> at least the defaut. Or even wilder, why this option exists at all and
>> git-submodule-update always behave like --init was always passed.
>
> That was a design decision. People may not be interested in all
> submodules but just a subset they are working with. E.g. think of a
> large media directory as a submodule the developers might not be
> interested in having it around all the time because only the designers
> are heavily working with it.
>
Thanks for explaining.
Another possible solution was to check if one or several submodules
are already checkout. If so then update only them. If none of them is
checkout then assume --init is passed and init all of them. Same if a
path is passed and this path corresponds to a submodule not checkout
yet.
--
Francis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox