RE: [PATCH 1/2] Support for setitimer() on platforms lacking it
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Sunday, September 02, 2012 10:44 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org; Johannes Sixt
Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
Joachim Schmitz j...@schmitz-digital.de writes:
Should we leave tv_usec untouched then? That was we round up on
the next (and subsequent?) round(s). Or just set to ENOTSUP in
setitimer if ovalue is !NULL?
I was alluding to the latter.
OK, will do that then.
Thanks.
Unless I screwed up the operator precedence?
I think you did, but not in the version we see below.
int git_setitimer(int which, const struct itimerval *value,
struct itimerval *ovalue)
{
int ret = 0;
if (!value ) {
Style: space before ')'?
Will fix.
errno = EFAULT;
return -1;
EFAULT is good ;-)
That's what 'man setitimer()' on Linux says to happen if invalid value is found.
The emulation in mingw.c 6072fc3 (Windows: Implement setitimer() and
sigaction()., 2007-11-13) may want to be tightened in a similar way.
Hmm, I see that there the errors are handled differently, like this:
if (ovalue != NULL)
return errno = EINVAL,
error(setitimer param 3 != NULL not implemented);
Should this be done in my setitimer() too? Or rather be left to the caller?
I tend to the later.
}
if ( value-it_value.tv_sec 0
Style: space after ')'?
After '(', I guess? Will fix.
|| value-it_value.tv_usec 100
|| value-it_value.tv_usec 0) {
errno = EINVAL;
return -1;
}
if ((ovalue) (git_getitimer(which, ovalue) == -1))
return -1; /* errno set in git_getitimer() */
As nobody passes non-NULL ovalue to setitimer(), I think we should
instead get rid of git_getitmier() implemenation, and change this to
True.
if (ovalue) {
errno = ENOTSUP;
return -1;
}
which is how I understood what the latter in the paragraph I
quoted from you above meant.
OK, will do this and then I'll rename the entire file into getitimer.c.
switch (which) {
case ITIMER_REAL:
/* If tv_usec is 0, round up to next full sec */
alarm(value-it_value.tv_sec + (value-it_value.tv_usec 0));
OK.
ret = 0; /* if alarm() fails, we get a SIGLIMIT */
break;
case ITIMER_VIRTUAL:
case ITIMER_PROF:
errno = ENOTSUP;
ret = -1;
break;
default:
errno = EINVAL;
ret = -1;
break;
}
return ret;
}
Other than that, looks good.
Thanks.
I had a closer look at the places in git where setitimer() is used. It is in 2
files, progress.c and builtin/log.c.
In progress.c :
static void set_progress_signal(void)
{
struct sigaction sa;
struct itimerval v;
progress_update = 0;
memset(sa, 0, sizeof(sa));
sa.sa_handler = progress_interval;
sigemptyset(sa.sa_mask);
sa.sa_flags = SA_RESTART;
sigaction(SIGALRM, sa, NULL);
v.it_interval.tv_sec = 1;
v.it_interval.tv_usec = 0;
v.it_value = v.it_interval;
setitimer(ITIMER_REAL, v, NULL);
}
static void clear_progress_signal(void)
{
struct itimerval v = {{0,},};
setitimer(ITIMER_REAL, v, NULL);
signal(SIGALRM, SIG_IGN);
progress_update = 0;
}
So it uses a 1 sec timeout, which is a good match to my implementation, but
also uses it_interval, meant to 're-arm' the timer after
it expired.
My implementation doesn't do that at all, and I also don't see how it possibly
could (short of installing a signal handler, which
then conflicts with the one use in progress.c).
On top here SA_RESTART is used, which is not available in HP NonStop (so I have
a -DSA_RESTART=0 in COMPAT_CFLAGS).
In builtin/log.c it doesn't use it_interval, which is a good match to my
implementation, but uses 1/2 a sec and 1/10 sec, so here
would be a victim of a 1 sec upgrade. This is probably acceptable.
...
* NOTE! We don't use it_interval, because if the
* reader isn't listening, we want our output to be
* throttled by the writing, and not have the timer
* trigger every second even if we're blocked on a
* reader!
*/
early_output_timer.it_value.tv_sec = 0;
early_output_timer.it_value.tv_usec = 50;
setitimer(ITIMER_REAL, early_output_timer, NULL);
...
static void setup_early_output(struct rev_info *rev)
{
struct sigaction sa;
/*
* Set up the signal handler, minimally intrusively:
* we only set a single volatile integer word (not
* using sigatomic_t - trying to avoid unnecessary
* system dependencies and headers), and
Re: [PATCH v4] Thunderbird: fix appp.sh format problems
2012/9/2 Junio C Hamano gits...@pobox.com:
Marco Stornelli marco.storne...@gmail.com writes:
Il 01/09/2012 15:59, Johannes Sixt ha scritto:
Look how you write:
perl -e '... $ENV{'PATCHTMP'} ...'
That is, perl actually sees this script:
... $ENV{PATCHTMP} ...
(no quotes around PATCHTMP). That my be perfectly valid perl, but is not
what you intended.
I don't understand what you mean when you say is not what you
intended...
When you wrote this:
CCS=`perl -e 'local $/=undef; open FILE, $ENV{'PATCHTMP'};...
which one of the following did you mean to feed Perl?
(1) open FILE, $ENV{'PATCHTMP'};
(2) open FILE, $ENV{PATCHTMP};
The patch text makes it look as if you wanted to do (1), but what is
fed to perl is (2), as Johannes points out.
Saying:
CCS=`perl -e 'local $/=undef; open FILE, $ENV{PATCHTMP};...
would have been more natural if you really meant to do (2), don't
you think? So what you wrote is at least misleading.
But I think I agree with Johannes's rewrite of the loop, so this may
be a moot point.
Ok, I'll try to rewrite it as Johannes has suggested.
Regards,
Marco
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Clone to an SSH destination
How do I clone a repo _to_ a new repo over SSH? I tried: cd xx git clone --bare . gitserver:/scm/xx.git git clone --bare . ssh://gitserver/scm/xx.git This does not have the expected result, and instead a local path of the given name is created (eg. a 'gitserver:' directory) This seems to be a FAQ, but the only answer I can find (Google) is to login to the server and create the repo, setup a remote and push to it. This is quite cumbersome; we have a large team of devs who use a simple 'git clone' to an NFS directory, but we wish to retire NFS access. Is there a technical limiation preventing clone-to-ssh, or just something waiting to be implemented? (Please keep me CC'd; I am currently reading the web archives) Many thanks -- Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fetch: align new ref summary printout in UTF-8 locales
fetch does printf(%-*s, width, foo) where foo can be an utf-8
string, but width is bytes, not letters. This results in misaligned
ref summary table.
Introduce gettext_length() function that returns the string length in
letters. Make the code use TRANSPORT_SUMMARY(x) where the length is
compensated properly in utf-8 locales.
---
gettext_length() can be made to support other charsets too. But I'm
on utf-8, it's not my itch.
Grepping through '%-*s' does not reveal any other places that obviously
need adjustment like this (apply and remote might, but pathnames and
remote names are usually in ascii)
builtin/fetch.c | 22 ++
gettext.c | 14 --
gettext.h | 5 +
transport.c | 2 +-
transport.h | 1 +
5 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index bb9a074..d7406d2 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -255,9 +255,8 @@ static int update_local_ref(struct ref *ref,
if (!hashcmp(ref-old_sha1, ref-new_sha1)) {
if (verbosity 0)
strbuf_addf(display, = %-*s %-*s - %s,
- TRANSPORT_SUMMARY_WIDTH,
- _([up to date]), REFCOL_WIDTH,
- remote, pretty_ref);
+ TRANSPORT_SUMMARY(_([up to date])),
+ REFCOL_WIDTH, remote, pretty_ref);
return 0;
}
@@ -271,7 +270,7 @@ static int update_local_ref(struct ref *ref,
*/
strbuf_addf(display,
_(! %-*s %-*s - %s (can't fetch in current
branch)),
- TRANSPORT_SUMMARY_WIDTH, _([rejected]),
+ TRANSPORT_SUMMARY(_([rejected])),
REFCOL_WIDTH, remote, pretty_ref);
return 1;
}
@@ -282,7 +281,7 @@ static int update_local_ref(struct ref *ref,
r = s_update_ref(updating tag, ref, 0);
strbuf_addf(display, %c %-*s %-*s - %s%s,
r ? '!' : '-',
- TRANSPORT_SUMMARY_WIDTH, _([tag update]),
+ TRANSPORT_SUMMARY(_([tag update])),
REFCOL_WIDTH, remote, pretty_ref,
r ? _( (unable to update local ref)) : );
return r;
@@ -317,7 +316,7 @@ static int update_local_ref(struct ref *ref,
r = s_update_ref(msg, ref, 0);
strbuf_addf(display, %c %-*s %-*s - %s%s,
r ? '!' : '*',
- TRANSPORT_SUMMARY_WIDTH, what,
+ TRANSPORT_SUMMARY(what),
REFCOL_WIDTH, remote, pretty_ref,
r ? _( (unable to update local ref)) : );
return r;
@@ -335,7 +334,7 @@ static int update_local_ref(struct ref *ref,
r = s_update_ref(fast-forward, ref, 1);
strbuf_addf(display, %c %-*s %-*s - %s%s,
r ? '!' : ' ',
- TRANSPORT_SUMMARY_WIDTH, quickref,
+ TRANSPORT_SUMMARY(quickref),
REFCOL_WIDTH, remote, pretty_ref,
r ? _( (unable to update local ref)) : );
return r;
@@ -351,13 +350,13 @@ static int update_local_ref(struct ref *ref,
r = s_update_ref(forced-update, ref, 1);
strbuf_addf(display, %c %-*s %-*s - %s (%s),
r ? '!' : '+',
- TRANSPORT_SUMMARY_WIDTH, quickref,
+ TRANSPORT_SUMMARY(quickref),
REFCOL_WIDTH, remote, pretty_ref,
r ? _(unable to update local ref) : _(forced
update));
return r;
} else {
strbuf_addf(display, ! %-*s %-*s - %s %s,
- TRANSPORT_SUMMARY_WIDTH, _([rejected]),
+ TRANSPORT_SUMMARY(_([rejected])),
REFCOL_WIDTH, remote, pretty_ref,
_((non-fast-forward)));
return 1;
@@ -479,8 +478,7 @@ static int store_updated_refs(const char *raw_url, const
char *remote_name,
free(ref);
} else
strbuf_addf(note, * %-*s %-*s - FETCH_HEAD,
- TRANSPORT_SUMMARY_WIDTH,
- *kind ? kind : branch,
+ TRANSPORT_SUMMARY(*kind ? kind :
branch),
REFCOL_WIDTH,
*what ? what : HEAD);
if (note.len) {
@@ -554,7 +552,7 @@ static int
Re: Clone to an SSH destination
On Mon, 3 Sep 2012 11:21:43 +0100 (BST) Mark Hills mark.hi...@framestore.com wrote: How do I clone a repo _to_ a new repo over SSH? I tried: cd xx git clone --bare . gitserver:/scm/xx.git git clone --bare . ssh://gitserver/scm/xx.git This does not have the expected result, and instead a local path of the given name is created (eg. a 'gitserver:' directory) No, `git clone` is intended to work with your local machine. And I can't really imagine how it would work in a way you want. This seems to be a FAQ, but the only answer I can find (Google) is to login to the server and create the repo, setup a remote and push to it. This is quite cumbersome; we have a large team of devs who use a simple 'git clone' to an NFS directory, but we wish to retire NFS access. Is there a technical limiation preventing clone-to-ssh, or just something waiting to be implemented? I think this is more a conceptual issue: such a remote cloning would mean *creation* of a repository as part of the process. I'm not aware of any [D]VCS system which would routinely allow such a thing: usually the creation of a repository is an administrative act, which is distinct from regular (push/fetch) access to that repository. gitolite kind of implements this (wild repos) [1], you could look if it suits your needs. Now back to your problem. If you have NFS access, you can probably do proper cloning using NFS: 1) Export via NFS the directory in which you want your resulting bare repository located. 2) Do simple *local* clone (using paths accessed by NFS): git clone --bare /path/to/source/repo /path/to/destination/repo 3) Do certain fixups in the destination repo, if needed, then access it normally via SSH (or whatever protocol you prefer). If you don't want to do this, then revert to a normal two-step procedure: 1) Log into the server, create a repo by hand: git init --bare /path/to/repo 2) Push everything relevant from a source repo there: cd /path/to/local/repo git remote add origin ssh://gitserver/scm/xx.git git push origin refs/*:refs/* Step (1) may depends on what server-side solution your need; for instance, in gitolite you would be configuring a new repo in the configuration file in your local clone of the gitolite admin repo and pushing your changes to the server. 1. http://sitaramc.github.com/gitolite/wild.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone to an SSH destination
On Mon, 3 Sep 2012, Sitaram Chamarty wrote: On Mon, Sep 3, 2012 at 5:17 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Mon, 3 Sep 2012 11:21:43 +0100 (BST) Mark Hills mark.hi...@framestore.com wrote: [snip] This is quite cumbersome; we have a large team of devs who use a simple 'git clone' to an NFS directory, but we wish to retire NFS access. [snip] gitolite kind of implements this (wild repos) [1], you could look if it suits your needs. The simplest conf to do what you want in gitolite is something like this: repo [a-zA-Z0-9]..* C = @all RW+ = @all But of course your *user* authentication will probably change quite a bit, since gitolite runs as one Unix user and merely simulates many gitolite users, while in the NFS method each of your devs probably has a full login to the server. I'll check out gitolite, thanks. We use unix users extensively (groups, permissions etc.) with YP, and this works well; a separate permissions scheme is not very desireable. The ssh method works very well right now, and nicely transparent. It's only the initial clone/creation that is harder than it was over NFS. And it prevents the use of git-shell too. Thanks -- Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone to an SSH destination
On Mon, Sep 3, 2012 at 6:45 PM, Mark Hills mark.hi...@framestore.com wrote: On Mon, 3 Sep 2012, Sitaram Chamarty wrote: On Mon, Sep 3, 2012 at 5:17 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Mon, 3 Sep 2012 11:21:43 +0100 (BST) Mark Hills mark.hi...@framestore.com wrote: [snip] This is quite cumbersome; we have a large team of devs who use a simple 'git clone' to an NFS directory, but we wish to retire NFS access. [snip] gitolite kind of implements this (wild repos) [1], you could look if it suits your needs. The simplest conf to do what you want in gitolite is something like this: repo [a-zA-Z0-9]..* C = @all RW+ = @all But of course your *user* authentication will probably change quite a bit, since gitolite runs as one Unix user and merely simulates many gitolite users, while in the NFS method each of your devs probably has a full login to the server. I'll check out gitolite, thanks. We use unix users extensively (groups, permissions etc.) with YP, and this works well; a separate permissions scheme is not very desireable. The ssh method works very well right now, and nicely transparent. It's only the initial clone/creation that is harder than it was over NFS. And it prevents the use of git-shell too. If I had to do this, and didn't want to use gitolite or something like it, I'd just make a script that will create the repo using an ssh call then do a 'git push --mirror' to it. Call it git-new or something and train people to use that instead of clone when the repo doesn't even exist yet. Bound to be easier than the administrative hassle you spoke of in your other email... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: checkout extra files
Angelo Borsotti angelo.borso...@gmail.com writes: Hello, the man page of git checkout states: git checkout [-p|--patch] [tree-ish] [--] pathspec... It updates the named paths in the working tree from the index file or from a named tree-ish ... This means that for each file denoted by pathspec, git tries to restore it from the tree-ish. However, it seems that git does more than this: it restores also files that are not denoted by pathspec. This sequence of commands shows it: $ mkdir gittest $ cd gittest $ git init Initialized empty Git repository in d:/gittest/.git/ $ touch f1 $ git add f1 $ git commit commit -m first commit [master (root-commit) 94d882a] first commit 0 files changed create mode 100644 f1 $ rm f1 $ git checkout 94d8 -- * $ ls f1 Note that the work directory is empty when the checkout is done, and that the checkout restores f1 in it, a file that is not denoted by the * pathspec. The '*' pathspec refers to every file. There are no files in the current directory, so your shell can't expand the glob and passes it to git, which then looks and sees that the glob expands to f1 in the given commit which it then checks out. cmn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: checkout extra files
On Mon, Sep 3, 2012 at 8:42 PM, Angelo Borsotti angelo.borso...@gmail.com wrote: $ git checkout 94d8 -- * $ ls f1 Note that the work directory is empty when the checkout is done, and that the checkout restores f1 in it, a file that is not denoted by the * pathspec. I think in this case '*' remains unexpanded by the shell. Which means it is still a pathspec to checkout (iow equivalent to git checkout 94d8 -- '*'). Checkout in turns matches the pathspec '*' against the tree and decides to restore 'fl'. It's confusing but I don't think there's much we can do about it. I guess that this is the intended behaviour, and that the man page should be updated to tell exactly what files git restores. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone to an SSH destination
On Mon, 3 Sep 2012 14:07:48 +0100 (BST) Mark Hills mark.hi...@framestore.com wrote: [...] But I'm actually more curious about why you need this in the first place, there's a bunch of devs where I work as well, but they never have the need to create new repos on some NFS drive in this manner. Without a command-line onto the filesystem (either local or NFS), how do you create a new repository for a new project? We have a fairly large team on a diverse set of projects. Projects come and go, so it's a burden if the administrator is needed just to create repos. Likewise, it's a step backwards for the developer to need to login themselves over SSH -- whereas 'git clone' is so easy to NFS. What are your devs doing when they do clone their current working directory to some NFS location, maybe there's a better way to do it. Most projects start as a small test at some point; eg. mkdir xx cd xx git init write some code git commit ... When a project becomes more official, the developer clones to a central location; eg. git clone --bare . /net/git/xx.git This is the step that is inconvenient if only SSH access is available. Well, then it looks you want something like github. In this case look at some more integrated solution such as Gitlab [1] -- I did not try it, but it looks like you import your users there and then they can log in, add their SSH keys and create their projects. I also think gitolite has some way to actually use regular SSH users (or even users coming from a web server which is a front-end for Smart HTTP Git transport, doing its own authentication). This is explained in [2], and I hope Sitaram could provide more insight on setting things up this way, if needed (I did not use this feature). 1. http://gitlabhq.com/ 2. http://sitaramc.github.com/gitolite/g2/auth.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone to an SSH destination
On Mon, Sep 3, 2012 at 7:38 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Mon, 3 Sep 2012 14:07:48 +0100 (BST) Mark Hills mark.hi...@framestore.com wrote: [...] But I'm actually more curious about why you need this in the first place, there's a bunch of devs where I work as well, but they never have the need to create new repos on some NFS drive in this manner. Without a command-line onto the filesystem (either local or NFS), how do you create a new repository for a new project? We have a fairly large team on a diverse set of projects. Projects come and go, so it's a burden if the administrator is needed just to create repos. Likewise, it's a step backwards for the developer to need to login themselves over SSH -- whereas 'git clone' is so easy to NFS. What are your devs doing when they do clone their current working directory to some NFS location, maybe there's a better way to do it. Most projects start as a small test at some point; eg. mkdir xx cd xx git init write some code git commit ... When a project becomes more official, the developer clones to a central location; eg. git clone --bare . /net/git/xx.git This is the step that is inconvenient if only SSH access is available. Well, then it looks you want something like github. In this case look at some more integrated solution such as Gitlab [1] -- I did not try it, but it looks like you import your users there and then they can log in, add their SSH keys and create their projects. Anything web based would be even more overhead than a simple: ssh server git init --bare foo/bar.git git push --mirror ssh://git/~/foo/bar.git Gitolite of course is even closer, as we discussed earlier. I also think gitolite has some way to actually use regular SSH users (or even users coming from a web server which is a front-end for Smart HTTP Git transport, doing its own authentication). This is explained in [2], and I hope Sitaram could provide more insight on setting things up this way, if needed (I did not use this feature). As I said earlier, regardless of how he does it, authentication will change, since he is no longer using a local (well, locally mounted) file system as the server. That may be get everyone to send us a pub key or give everyone an http password and use smart http. In addition, if they choose smart http, they *have to* use gitolite. Unlike ssh, where that two command sequence above would do it all for them, there is no eqvt if your git server is behind http. 1. http://gitlabhq.com/ 2. http://sitaramc.github.com/gitolite/g2/auth.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sitaram -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: checkout extra files
Angelo Borsotti angelo.borso...@gmail.com writes: [please keep it in the list] Hi Carlos, the behavior is quite clear, but the man pages do not describe it properly. The man pages state: It updates the named paths in the working tree from the index file or from a named tree-ish In my example, the named paths in the working tree is '*', which denotes That grouping is not what it's saying. It doesn't update the files that exist in the working tree matching some glob. It updates the files in the working tree from either the index or a treeish. The pathspec refers, as always, to the data source, and '*' matches all files. It puts the named paths on to the working tree. Is that clearer? no files. So, the man pages are telling that the command updates nothing. The man pages should state that it copies from the index file of the names tree-ish the files that match the names paths and that are not present in the working tree. Whether they are missing doesn't make any difference. It updates the files you tell it from the index/tree. You told it to update all of them. cmn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Thunderbird: fix appp.sh format problems
Il 02/09/2012 22:42, Junio C Hamano ha scritto:
Marco Stornelli marco.storne...@gmail.com writes:
Il 01/09/2012 15:59, Johannes Sixt ha scritto:
Look how you write:
perl -e '... $ENV{'PATCHTMP'} ...'
That is, perl actually sees this script:
... $ENV{PATCHTMP} ...
(no quotes around PATCHTMP). That my be perfectly valid perl, but is not
what you intended.
I don't understand what you mean when you say is not what you
intended...
When you wrote this:
CCS=`perl -e 'local $/=undef; open FILE, $ENV{'PATCHTMP'};...
which one of the following did you mean to feed Perl?
(1) open FILE, $ENV{'PATCHTMP'};
(2) open FILE, $ENV{PATCHTMP};
The patch text makes it look as if you wanted to do (1), but what is
fed to perl is (2), as Johannes points out.
Saying:
CCS=`perl -e 'local $/=undef; open FILE, $ENV{PATCHTMP};...
would have been more natural if you really meant to do (2), don't
you think? So what you wrote is at least misleading.
But I think I agree with Johannes's rewrite of the loop, so this may
be a moot point.
I tried the Johannes's script, but it seems it doesn't work well with
the pattern of format-patch (To: mail1,\n mail2,\nmailN).
The multilines are not well managed. I can change my script to double
quotas (I think perl and regexp are much more powerful rather than the
while loop though it can be less readable), if it's not ok, I let other
git shell expert to adjust the script. I hope this thread it will be
useful for others.
Marco
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] Thunderbird: fix appp.sh format problems
The current script has got the following problems:
1) It doesn't work if the language used by Thunderbird is not English;
2) The field To: filled by format-patch is not evaluated;
3) The field Cc: is loaded from Cc used in the commit message
instead of using the Cc field filled by format-patch in the email
header.
Added comments for point 1), added parsing of To: for point 2) and
added parsing of Cc: in the email header for point 3), removing the
Cc: parsing from commit message.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
v6: replaced single quotas with double quotas in perl embedded script
v5: fixed comments by Junio C Hamano
v4: create a tmp file to allow correct perl parsing
v3: parse only To: and Cc: in the email header, fix some comments
v2: changed the commit message to reflect better the script implementation
v1: first draft
contrib/thunderbird-patch-inline/appp.sh | 25 +
1 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/contrib/thunderbird-patch-inline/appp.sh
b/contrib/thunderbird-patch-inline/appp.sh
index 5eb4a51..5e4e892 100755
--- a/contrib/thunderbird-patch-inline/appp.sh
+++ b/contrib/thunderbird-patch-inline/appp.sh
@@ -6,6 +6,9 @@
# ExternalEditor can be downloaded at http://globs.org/articles.php?lng=enpg=2
+# NOTE: You must change some words in this script according to the language
+# used by Mozilla Thunderbird, as Subject, To, Don't remove this line.
+
CONFFILE=~/.appprc
SEP=-=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-
@@ -26,17 +29,31 @@ fi
cd - /dev/null
SUBJECT=`sed -n -e '/^Subject: /p' ${PATCH}`
-HEADERS=`sed -e '/^'${SEP}'$/,$d' $1`
BODY=`sed -e 1,/${SEP}/d $1`
CMT_MSG=`sed -e '1,/^$/d' -e '/^---$/,$d' ${PATCH}`
DIFF=`sed -e '1,/^---$/d' ${PATCH}`
+PATCHTMP=${PATCH}.tmp
+
+sed '/^$/q' ${PATCH} ${PATCHTMP}
+
+export PATCHTMP
+CCS=`perl -e 'local $/=undef; open FILE, $ENV{PATCHTMP}; $text=FILE;
+close FILE; $addr = $1 if $text =~ /Cc: (.*?(,\n .*?)*)\n/s; $addr =~ s/\n//g;
+print $addr;'`
+
+TO=`perl -e 'local $/=undef; open FILE, $ENV{PATCHTMP}; $text=FILE;
+close FILE; $addr = $1 if $text =~ /To: (.*?(,\n .*?)*)\n/s; $addr =~ s/\n//g;
+print $addr;'`
-CCS=`echo -e $CMT_MSG\n$HEADERS | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \
- -e 's/^Signed-off-by: \(.*\)/\1,/gp'`
+rm -f ${PATCHTMP}
+# Change Subject: before next line according to Thunderbird language
+# for example to translate in Italian:
+# SUBJECT=`echo $SUBJECT | sed -e 's/^Subject:/Oggetto:/g'`
echo $SUBJECT $1
+# Change To: according to Thunderbird language
+echo To: $TO $1
echo Cc: $CCS $1
-echo $HEADERS | sed -e '/^Subject: /d' -e '/^Cc: /d' $1
echo $SEP $1
echo $CMT_MSG $1
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: warning: There are too many unreachable loose objects; run 'git prune' to remove them.
On 29/08/2012 22:16, Dun Peal wrote: Hi, I am getting this error every time I pull. All the following have been executed, but failed to remove this warning: git prune git prune --expire now git gc git gc --aggressive What should I do? Was the error prefixed by 'remote:' (i.e. was it an error generated by the remote, or locally)? If it was, did you execute your prune commands in the remote repository? Antony -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
Johannes Sixt j...@kdbg.org writes:
Am 03.09.2012 11:31, schrieb Joachim Schmitz:
Hmm, I see that there the errors are handled differently, like this:
if (ovalue != NULL)
return errno = EINVAL,
error(setitimer param 3 != NULL not implemented);
Should this be done in my setitimer() too? Or rather be left to the caller?
I tend to the later.
The error message is really just a reminder that the implementation is
not complete. Writing it here has the advantage that it is much more
accurate than a generic invalid argument or operation not supported
error that the caller would be able to write.
Joachim quoted irrelevant (to you) part and made comments on it, but
the issue I raised by Ccing you was about diagnosing NULL passed in
newvalue parameter, which Joachim's code did like this:
int git_setitimer(int which, const struct itimerval *value,
struct itimerval *ovalue)
{
int ret = 0;
if (!value ) {
errno = EFAULT;
return -1;
EFAULT is good ;-)
The emulation in mingw.c 6072fc3 (Windows: Implement setitimer() and
sigaction()., 2007-11-13) may want to be tightened in a similar way.
but mingw.c doesn't seem to.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
Joachim Schmitz j...@schmitz-digital.de writes:
if (!value ) {
Style: space before ')'?
Will fix.
errno = EFAULT;
return -1;
EFAULT is good ;-)
That's what 'man setitimer()' on Linux says to happen if invalid value is
found.
The emulation in mingw.c 6072fc3 (Windows: Implement setitimer() and
sigaction()., 2007-11-13) may want to be tightened in a similar way.
Hmm, I see that there the errors are handled differently, like this:
if (ovalue != NULL)
return errno = EINVAL,
error(setitimer param 3 != NULL not implemented);
Should this be done in my setitimer() too? Or rather be left to the caller?
I tend to the later.
I don't care too deeply either way. The above was not a comment
meant for you, but was to point out the error checking when the
newvalue is NULL---it is missing in mingw.c and I think the
condition should be checked.
On top here SA_RESTART is used, which is not available in HP
NonStop (so I have a -DSA_RESTART=0 in COMPAT_CFLAGS).
If you cannot re-trigger the timer, then you will see 20% shown
after one second, silence for 4 seconds and then done, for an
operation that takes 5 seconds. Which is not the end of the world,
though. It does not affect correctness.
The other use of itimer in our codebase is the early-output timer,
but that also is about perceived latency, and not about correctness,
so it is possible that you do not have to support anything (i.e. not
even setting an alarm) at all.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: align new ref summary printout in UTF-8 locales
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: fetch does printf(%-*s, width, foo) where foo can be an utf-8 string, but width is bytes, not letters. This results in misaligned ref summary table. but width is bytes, not letters is a misleading statement. Be careful about three different quantities when talking about aligning on terminal output with monospaced fonts: - How many bytes does the string occupy in memory? - How many unicode codepoints are in the string? - How many display columns does the string occupy on terminal? Note that some letters (e.g. Han) occupy two display columns, and you want to measure the width and compensate that for bytes. Letter count do not come into the picture for the purpose of aligning the terminal output. Introduce gettext_length() function that returns the string length in letters. Make the code use TRANSPORT_SUMMARY(x) where the length is Again, are you measuring string length in letters? Or are you trying to measure in terms of git_wcwidth()? If the latter, please name this after width, not length to make it more clear. compensated properly in utf-8 locales. --- Is it in vogue to omit Signed-off-by line these days or something? gettext_length() can be made to support other charsets too. But I'm on utf-8, it's not my itch. Grepping through '%-*s' does not reveal any other places that obviously need adjustment like this (apply and remote might, but pathnames and remote names are usually in ascii) Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: checkout extra files
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Mon, Sep 3, 2012 at 8:42 PM, Angelo Borsotti angelo.borso...@gmail.com wrote: $ git checkout 94d8 -- * $ ls f1 Note that the work directory is empty when the checkout is done, and that the checkout restores f1 in it, a file that is not denoted by the * pathspec. I think in this case '*' remains unexpanded by the shell. Which means it is still a pathspec to checkout (iow equivalent to git checkout 94d8 -- '*'). Checkout in turns matches the pathspec '*' against the tree and decides to restore 'fl'. It's confusing but I don't think there's much we can do about it. The user can, by telling the shell to expand '*' that does not match to nothing, though. Is there anything that is confusing in our documentation? I am not looking for a change to the documentation that protects it from getting misunderstood by deliberately twisted interpretations (such a change would make the resulting text would harder to read), but I do want to make sure it is not prone to confusion even to a casual and careless reader. For this particular scenario, I do not see anything offhand that is unclear about the behaviour of Git in the documentation, even though as you pointed out, if the user is unaware that the shell passes globs unmodified when they do not match, it may lead to a confusion like this. I certainly do not want to do a full introduction to shell in our documentation, but if adding a short sentence or two helps to avoid confusion like this, I do not strongly object to it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: align new ref summary printout in UTF-8 locales
Am 03.09.2012 21:26, schrieb Junio C Hamano: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: fetch does printf(%-*s, width, foo) where foo can be an utf-8 string, but width is bytes, not letters. This results in misaligned ref summary table. but width is bytes, not letters is a misleading statement. Be careful about three different quantities when talking about aligning on terminal output with monospaced fonts: - How many bytes does the string occupy in memory? - How many unicode codepoints are in the string? - How many display columns does the string occupy on terminal? Note that some letters (e.g. Han) occupy two display columns, and you want to measure the width and compensate that for bytes. Letter count do not come into the picture for the purpose of aligning the terminal output. If I'm reading POSIX correctly, printf measures the width in %*s in bytes. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Support for setitimer() on platforms lacking it
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Monday, September 03, 2012 9:03 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org; 'Johannes Sixt'
Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
Joachim Schmitz j...@schmitz-digital.de writes:
if (!value ) {
Style: space before ')'?
Will fix.
errno = EFAULT;
return -1;
EFAULT is good ;-)
That's what 'man setitimer()' on Linux says to happen if invalid value is
found.
The emulation in mingw.c 6072fc3 (Windows: Implement setitimer() and
sigaction()., 2007-11-13) may want to be tightened in a similar way.
Hmm, I see that there the errors are handled differently, like this:
if (ovalue != NULL)
return errno = EINVAL,
error(setitimer param 3 != NULL not implemented);
Should this be done in my setitimer() too? Or rather be left to the caller?
I tend to the later.
I don't care too deeply either way. The above was not a comment
meant for you, but was to point out the error checking when the
newvalue is NULL---it is missing in mingw.c and I think the
condition should be checked.
Ah, OK. Guess Johannes and I misunderstood ;-)
On top here SA_RESTART is used, which is not available in HP
NonStop (so I have a -DSA_RESTART=0 in COMPAT_CFLAGS).
If you cannot re-trigger the timer, then you will see 20% shown
after one second, silence for 4 seconds and then done, for an
operation that takes 5 seconds. Which is not the end of the world,
though. It does not affect correctness.
That does seem to work, if I do e.g. a git clone on git itself (being a
fairly large repository), I see it updating the % values
about once per second.
The other use of itimer in our codebase is the early-output timer,
but that also is about perceived latency, and not about correctness,
so it is possible that you do not have to support anything (i.e. not
even setting an alarm) at all.
OK, I'll go for that one-liner in git-compat-utils.h then
#ifdef NO_SETITIMER /* poor man's setitimer() */
#define setitimer(w,v,o) alarm((v)-it_value.tv_sec+((v)-it_value.tv_usec0))
#endif
It certainly seems to work just fine for me.
Could as well be #ifdef __TANDEM, I won't mind.
Bye, Jojo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Thunderbird: fix appp.sh format problems
Marco Stornelli marco.storne...@gmail.com writes:
I tried the Johannes's script, but it seems it doesn't work well with
the pattern of format-patch (To: mail1,\n mail2,\n
mailN). The multilines are not well managed.
I am guessing that the reason why Jonahhes's copy our headers out
with continuation lines intact approach does not work is because
Thunderbird does not want to see its own header part (i.e. that
which comes before that $SEP) contain RFC-2822 style continuation
lines.
Can you grab a typical input (i.e. the contents of what is passed as
$1 to the appp.sh script) and show us how it looks like here so that
we can take a look? It would be fine to paste the contents, but we
might want to protect it from MUA by doing an attachment or a
pastebin URL.
It appears that the original script tries very hard to keep the
Subject: line at the beginning, but I am not sure if that is because
Thunderbird wants to read its $1 that way, or it is just that
original appp.sh script happened to be written that way without real
reason. If I were updating this script, what I would do would be
more like:
0. Open a temporary output file $OUT, input filehandle $IN from
${PATCH}, and another input filehandle $TEMPLATE from $1
1. Read from $IN starting from the second line (i.e. skip the
first line From [0-9a-f] Mon Sep 17 00:00:00 2001 magic
marker) upto the empty line, coalescing the RFC-2822 style
continuation lines into one long line each.
2. Output the above into $OUT, while applying your header field
name translation (e.g. Oggetto) and remembering what
header you wrote out.
3. Read from $TEMPLATE up to a line that matches the following
pattern:
/^-=-=-=-=-=-=-=-=-=#.*#=-=-=-=-=-=-=-=-=-$/
reject headers that step 2. already emitted, and emit other
headers to $OUT. Also emit that line that matched the above
SEP pattern to $OUT (by doing so, you do not have to care how
Don't remove this line is spelled in the user's language).
4. Resume reading from $IN and copy to $OUT, including the patch
separator ---, and stop copying.
5. Read the remainder of $TEMPLATE and copy to $OUT.
6. Read the remainder of $IN and copy to $OUT.
7. Rename the temporary file that was connected to $OUT to $1.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: align new ref summary printout in UTF-8 locales
Johannes Sixt j...@kdbg.org writes: Am 03.09.2012 21:26, schrieb Junio C Hamano: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: fetch does printf(%-*s, width, foo) where foo can be an utf-8 string, but width is bytes, not letters. This results in misaligned ref summary table. but width is bytes, not letters is a misleading statement. Be careful about three different quantities when talking about aligning on terminal output with monospaced fonts: - How many bytes does the string occupy in memory? - How many unicode codepoints are in the string? - How many display columns does the string occupy on terminal? Note that some letters (e.g. Han) occupy two display columns, and you want to measure the width and compensate that for bytes. Letter count do not come into the picture for the purpose of aligning the terminal output. If I'm reading POSIX correctly, printf measures the width in %*s in bytes. Yes, that is the problem. When we give allocated_width columns to display str, and call printf(%.*s, allocated_width, str) we end up getting (allocated_width - strlen(str)) SPs as filler. If the str occupies less than strlen(str) columns (and it often is the case for a string with non-ascii characters), insufficient number of filler SPs will be given, and an item on the same line that comes after this printf() will appear too close to str. By measuring the required number of columns to display str, you can compensate. i.e. printf(%.*s, allocated_width + (strlen(str) - display_width(str)), str) to give it enough filler. I think the patch uses utf8_strwidth() which measures the display columns needed for the string, not number of unicode codepoints in the string. I was merely pointing out that the wording of the proposed log message bytes, not letters and the function name foo_length was misleading, when we mean width. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: diff/merge tool that ignores whitespace changes
On Sun, Sep 2, 2012 at 5:07 PM, Enrico Weigelt enrico.weig...@vnc.biz wrote: Hi, Would that help ? git help diff [snip] --ignore-space-at-eol Ignore changes in whitespace at EOL. -b, --ignore-space-change Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent. -w, --ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none. Now I yet need to find out how to configure tig for it. Try: echo set ignore-space = all ~/.tigrc And use 'W' to toggle between the different modes. -- Jonas Fonseca -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Automatic repacking when cloning - Only seems to work via file but not ssh or git
Hi all, I already posted this question in the git users groups (https://groups.google.com/forum/?fromgroups=#!topic/git-users/dguTJFrw5MI) but was advised to better ask the experts in this list. So here we go: The question is regarding the packs and the repacking of those during cloning. I'm migrating a big repository which after initial commit of all files contains only one pack file of 120MB in size (about 800 extracted). On this big repo I created various subtree branches (using git subtree split) so I can clone some of the folders individually (without getting the whole big thing). The problem is, however, that all my subtree branch clones seem to get a copy of the big 120MB pack (where often only 2MB will be extracted from it). After testing a little bit I figured that this only happens if I use ssh or the git protocol to clone the repo. When using file:// to specify the remote repository some repacking seems to happen automatically and I end up with a new pack file for my clone that only contains the stuff that is really needed for my branch (which obviously results in much smaller size). Running the following commands on the clone created via ssh or git helps removing the unnecessary overhead and repacks my repo creating a small pack, discarding the unneded stuff: git pack-refs --prune git reflog expire --all git repack -a -d -f -l So although that helps me getting a small clone via ssh I have some questions / doubts: 1. Is it as designed that the repacking only happens automatically when cloning using the file url or could it be a bug that it is not supported for ssh and git native protocol? 2. Is there already a way to achieve the repacking when cloning using ssh or git protocol (as obviously I'd prefer to use those over file:// )? 3. Can I provide multiple pre-made packs for my different subtree branches already on server side to make the cloning even faster and avoid always having to repack when someone clones a subtree branch? Thanks a lot, Haasip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: checkout extra files
On Tue, Sep 4, 2012 at 2:36 AM, Junio C Hamano gits...@pobox.com wrote: It's confusing but I don't think there's much we can do about it. The user can, by telling the shell to expand '*' that does not match to nothing, though. It works 99% the time, I don't think any users would bother setting that or studying the shell at that detail, until they are surprised. Is there anything that is confusing in our documentation? I am not looking for a change to the documentation that protects it from getting misunderstood by deliberately twisted interpretations (such a change would make the resulting text would harder to read), but I do want to make sure it is not prone to confusion even to a casual and careless reader. For this particular scenario, I do not see anything offhand that is unclear about the behaviour of Git in the documentation, even though as you pointed out, if the user is unaware that the shell passes globs unmodified when they do not match, it may lead to a confusion like this. I certainly do not want to do a full introduction to shell in our documentation, but if adding a short sentence or two helps to avoid confusion like this, I do not strongly object to it. Yeah, one or two sentences about two level expansion might help new users. I'll check that. Maybe in the pathspec definition, then split that part of out glossary-content.txt to be included in pathspec-using commands as a separate pathspec section. Too much? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: checkout extra files
Keep it in the list. Angelo Borsotti angelo.borso...@gmail.com writes: Hi Carlos, That grouping is not what it's saying. It doesn't update the files that exist in the working tree matching some glob. It updates the files in the working tree from either the index or a treeish. The pathspec refers, as always, to the data source, and '*' matches all files. It puts the named paths on to the working tree. Is that clearer? This was mi first understanding, until one day I had in the working directory a file that matched the path (the path was '*') and that was NOT in the index or a treeish. The git checkout command tried to copy it and complained that there was no such file to restore. So you're saying that you ran git checkout tree-ish -- * and git complained that there was no such file? This is because the shell expanded the glob and gave git a list of files. Then I thought that it visited the working directory and tried to restore each file it matched and at the end restored also the ones that were not there. I can't quite parse this. Git will restore whichever files you tell it to. If you use an asterisk, then your shell will usually expand it. In the case you posted to the list there were no files, so there was nothing to expand it to. Some shells complain in this case by default, some don't and just pass the asterisk to the program and let it figure out what to do with it. This was the case in your example. You told git to expand all the files it found in that tree-ish. cmn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: checkout extra files
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: For this particular scenario, I do not see anything offhand that is unclear about the behaviour of Git in the documentation, even though as you pointed out, if the user is unaware that the shell passes globs unmodified when they do not match, it may lead to a confusion like this. I certainly do not want to do a full introduction to shell in our documentation, but if adding a short sentence or two helps to avoid confusion like this, I do not strongly object to it. Perhaps like this? Documentation/git-checkout.txt | 12 1 file changed, 12 insertions(+) diff --git i/Documentation/git-checkout.txt w/Documentation/git-checkout.txt index 63a2516..e7272b6 100644 --- i/Documentation/git-checkout.txt +++ w/Documentation/git-checkout.txt @@ -360,20 +360,32 @@ mistake, and gets it back from the index. $ git checkout master 1 $ git checkout master~2 Makefile 2 $ rm -f hello.c $ git checkout hello.c3 + 1 switch branch 2 take a file out of another commit 3 restore hello.c from the index + +If you want to check out _all_ C source files out of the index, +you can say ++ + +$ git checkout -- '*.c' + ++ +Note the quotes around '*.c'. 'hello.c' will also be checked +out, even though it is no longer in the working tree, because +the pathspec is used to match entries in the index (not in the +working tree by your shell). ++ If you have an unfortunate branch that is named `hello.c`, this step would be confused as an instruction to switch to that branch. You should instead write: + $ git checkout -- hello.c . After working in the wrong branch, switching to the correct branch would be done using: -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
