* [PATCH RFC 6/6] Docs: send-email: --chain_reply_to -> --[no-]chain-reply-to
From: Michael Witten @ 2008-09-25 20:44 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1222375476-32911-5-git-send-email-mfwitten@mit.edu>
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index fe53e9b..76a525a 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -228,7 +228,7 @@ sendemail.bcc::
Email address (or alias) to always bcc.
sendemail.chainreplyto::
- Boolean value specifying the default to the '--chain_reply_to'
+ Boolean value specifying the default to the '--[no-]chain-reply-to'
parameter.
sendemail.smtpserver::
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 1/6] Docs: send-email's usage text and man page mention same options
From: Michael Witten @ 2008-09-25 20:44 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1222099095-50360-1-git-send-email-mfwitten@mit.edu>
Specifically, boolean options are now listed in the form
--[no-]option
and both forms of documentation now consistently use
--[no-]signed-off-by-cc
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 21 +++++++++++++--------
git-send-email.perl | 8 ++++----
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 3c3e1b0..9b31626 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -40,8 +40,7 @@ The --cc option must be repeated for each user you want on the cc list.
Output of this command must be single email address per line.
Default is the value of 'sendemail.cccmd' configuration value.
---chain-reply-to::
---no-chain-reply-to::
+--[no-]chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
the first will be sent as replies to the first email sent. When using
@@ -66,8 +65,7 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---signed-off-by-cc::
---no-signed-off-by-cc::
+--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
@@ -146,8 +144,7 @@ user is prompted for a password while the input is masked for privacy.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---suppress-from::
---no-suppress-from::
+--[no-]suppress-from::
If this is set, do not add the From: address to the cc: list.
Default is the value of 'sendemail.suppressfrom' configuration value;
if that is unspecified, default to --no-suppress-from.
@@ -163,8 +160,7 @@ user is prompted for a password while the input is masked for privacy.
if that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'sob' if --no-signed-off-cc is specified.
---thread::
---no-thread::
+--[no-]thread::
If this is set, the In-Reply-To header will be set on each email sent.
If disabled with "--no-thread", no emails will have the In-Reply-To
header set.
@@ -183,6 +179,15 @@ user is prompted for a password while the input is masked for privacy.
variable; if that is unspecified, choosing the envelope sender is left
to your MTA.
+--no-validate::
+ Don't perform any sanity checks on patches.
+ Currently, validation means the following:
++
+--
+ * Warn of patches that contain lines longer than 998 characters; this
+ is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
+--
+
--to::
Specify the primary recipient of the emails generated.
Generally, this will be the upstream maintainer of the
diff --git a/git-send-email.perl b/git-send-email.perl
index d2fd899..9f56162 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -64,11 +64,11 @@ Options:
Only used if --compose is also set. If --compose is not
set, this will be prompted for.
- --chain-reply-to If set, the replies will all be to the previous
+ --[no-]chain-reply-to If set, the replies will all be to the previous
email sent, rather than to the first email sent.
Defaults to on.
- --signed-off-cc Automatically add email addresses that appear in
+ --[no-]signed-off-by-cc Automatically add email addresses that appear in
Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
--identity The configuration identity, a subsection to prioritise over
@@ -95,9 +95,9 @@ Options:
'cccmd' for the output of the cccmd, or 'all' to suppress
all of these.
- --suppress-from Suppress sending emails to yourself. Defaults to off.
+ --[no-]suppress-from Suppress sending emails to yourself. Defaults to off.
- --thread Specify that the "In-Reply-To:" header should be set on all
+ --[no-]thread Specify that the "In-Reply-To:" header should be set on all
emails. Defaults to on.
--quiet Make git-send-email less verbose. One line per email
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 5/6] Docs: send-email: change --no-validate to boolean --[no-]validate
From: Michael Witten @ 2008-09-25 20:44 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1222375476-32911-4-git-send-email-mfwitten@mit.edu>
There is also now a configuration variable:
sendemail[.<identity>].validate
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 9 +++++++--
git-send-email.perl | 10 ++++++----
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 6031eb7..fe53e9b 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -189,14 +189,16 @@ user is prompted for a password while the input is masked for privacy.
variable; if that is unspecified, choosing the envelope sender is left
to your MTA.
---no-validate::
- Don't perform any sanity checks on patches.
+--[no-]validate::
+ Perform sanity checks on patches.
Currently, validation means the following:
+
--
* Warn of patches that contain lines longer than 998 characters; this
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
++
+This option can be set with sendemail[.<identity>].validate; default to --validate
CONFIGURATION
@@ -249,6 +251,9 @@ sendemail.smtpencryption::
sendemail.smtpssl::
Legacy boolean that sets 'smtpencryption=ssl' if enabled.
+sendemail.validate::
+ Boolean override for --[no-]validate.
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
diff --git a/git-send-email.perl b/git-send-email.perl
index b86a3f3..8bc204f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -113,7 +113,8 @@ Options:
--envelope-sender Specify the envelope sender used to send the
emails.
- --no-validate Don't perform any sanity checks on patches.
+ --[no-]validate Perform any sanity checks on patches.
+ Default to on.
EOT
exit(1);
@@ -195,7 +196,7 @@ my ($quiet, $dry_run) = (0, 0);
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
-my ($no_validate);
+my ($validate);
my (@suppress_cc);
my %config_bool_settings = (
@@ -203,6 +204,7 @@ my %config_bool_settings = (
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
"signedoffcc" => [\$signed_off_cc, undef],
+ "validate" => [\$validate, 1],
);
my %config_settings = (
@@ -269,7 +271,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
- "no-validate" => \$no_validate,
+ "validate!" => \$validate,
);
unless ($rc) {
@@ -422,7 +424,7 @@ for my $f (@ARGV) {
}
}
-if (!$no_validate) {
+if ($validate) {
foreach my $f (@files) {
unless (-p $f) {
my $error = validate_patch($f);
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 4/6] Docs: send-email: Option order the same in man page and usage text
From: Michael Witten @ 2008-09-25 20:44 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1222375476-32911-3-git-send-email-mfwitten@mit.edu>
The man page seems to have listed the options in alphabetical order,
while the usage text used what I would consider an `intuitive' order
that groups related items and presents them in the order peopl think
when writing an email.
The manual page has been updated to mirror this order.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 77 +++++++++++++++++++-------------------
1 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 9b31626..6031eb7 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -24,10 +24,19 @@ OPTIONS
-------
The options available are:
---bcc::
- Specify a "Bcc:" value for each email.
+--from::
+ Specify the sender of the emails. This will default to
+ the value GIT_COMMITTER_IDENT, as returned by "git var -l".
+ The user will still be prompted to confirm this entry.
+
+--to::
+ Specify the primary recipient of the emails generated.
+ Generally, this will be the upstream maintainer of the
+ project involved.
+ Default is the value of the 'sendemail.to' configuration value;
+ if that is unspecified, this will be prompted for.
+
-The --bcc option must be repeated for each user you want on the bcc list.
+The --to option must be repeated for each user you want on the to list.
--cc::
Specify a starting "Cc:" value for each email.
@@ -40,23 +49,19 @@ The --cc option must be repeated for each user you want on the cc list.
Output of this command must be single email address per line.
Default is the value of 'sendemail.cccmd' configuration value.
---[no-]chain-reply-to::
- If this is set, each email will be sent as a reply to the previous
- email sent. If disabled with "--no-chain-reply-to", all emails after
- the first will be sent as replies to the first email sent. When using
- this, it is recommended that the first file given be an overview of the
- entire patch series.
- Default is the value of the 'sendemail.chainreplyto' configuration
- value; if that is unspecified, default to --chain-reply-to.
+--bcc::
+ Specify a "Bcc:" value for each email.
++
+The --bcc option must be repeated for each user you want on the bcc list.
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
---from::
- Specify the sender of the emails. This will default to
- the value GIT_COMMITTER_IDENT, as returned by "git var -l".
- The user will still be prompted to confirm this entry.
+--subject::
+ Specify the initial subject of the email thread.
+ Only necessary if --compose is also set. If --compose
+ is not set, this will be prompted for.
--in-reply-to::
Specify the contents of the first In-Reply-To header.
@@ -65,16 +70,21 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
+--[no-]chain-reply-to::
+ If this is set, each email will be sent as a reply to the previous
+ email sent. If disabled with "--no-chain-reply-to", all emails after
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series.
+ Default is the value of the 'sendemail.chainreplyto' configuration
+ value; if that is unspecified, default to --chain-reply-to.
+
--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
if that is unspecified, default to --signed-off-by-cc.
---quiet::
- Make git-send-email less verbose. One line per email should be
- all that is output.
-
--identity::
A configuration identity. When given, causes values in the
'sendemail.<identity>' subsection to take precedence over
@@ -139,16 +149,6 @@ user is prompted for a password while the input is masked for privacy.
--smtp-ssl::
Legacy alias for '--smtp-encryption=ssl'.
---subject::
- Specify the initial subject of the email thread.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
-
---[no-]suppress-from::
- If this is set, do not add the From: address to the cc: list.
- Default is the value of 'sendemail.suppressfrom' configuration value;
- if that is unspecified, default to --no-suppress-from.
-
--suppress-cc::
Specify an additional category of recipients to suppress the
auto-cc of. 'self' will avoid including the sender, 'author' will
@@ -159,6 +159,12 @@ user is prompted for a password while the input is masked for privacy.
Default is the value of 'sendemail.suppresscc' configuration value;
if that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'sob' if --no-signed-off-cc is specified.
+ (Note: Linus uses 'self' and 'sob' interchangeably).
+
+--[no-]suppress-from::
+ If this is set, do not add the From: address to the cc: list.
+ Default is the value of 'sendemail.suppressfrom' configuration value;
+ if that is unspecified, default to --no-suppress-from.
--[no-]thread::
If this is set, the In-Reply-To header will be set on each email sent.
@@ -167,6 +173,10 @@ user is prompted for a password while the input is masked for privacy.
Default is the value of the 'sendemail.thread' configuration value;
if that is unspecified, default to --thread.
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
+
--dry-run::
Do everything except actually send the emails.
@@ -188,15 +198,6 @@ user is prompted for a password while the input is masked for privacy.
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
---to::
- Specify the primary recipient of the emails generated.
- Generally, this will be the upstream maintainer of the
- project involved.
- Default is the value of the 'sendemail.to' configuration value;
- if that is unspecified, this will be prompted for.
-+
-The --to option must be repeated for each user you want on the to list.
-
CONFIGURATION
-------------
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* Re: [PATCH] usage.c: remove unused functions
From: Jonas Fonseca @ 2008-09-25 20:43 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Lars Hjemli, Thomas Rast, Nanako Shiraishi,
Junio C Hamano, git
In-Reply-To: <20080925145134.GL3669@spearce.org>
Shawn O. Pearce <spearce@spearce.org> wrote Thu, Sep 25, 2008:
> IMHO these are useless for a "libgit". However both tig and
> cgit link to the non-existant libgit.a, so they may be using
> these routines. I've CC'd their authors and am not applying this
> particular change without an ACK from them.
This is not a problem for tig since it doesn't use libgit at all.
--
Jonas Fonseca
^ permalink raw reply
* git apply --directory broken for new files
From: H. Peter Anvin @ 2008-09-25 20:41 UTC (permalink / raw)
To: Git Mailing List
Trying with git 1.6.0.1:
: tazenda 124 ; git apply --directory=gpxe/ < /tmp/diff
fatal: git-apply: bad git-diff - inconsistent new filename on line 105
Line 105 in the diff is:
101 diff --git a/src/arch/i386/firmware/pcbios/fakee820.c
b/src/arch/i386/firmware/pcbios/fakee820.c
102 new file mode 100644
103 index 0000000..e171edf
104 --- /dev/null
105 +++ b/src/arch/i386/firmware/pcbios/fakee820.c
What I'm trying to do here is to apply a diff created via "git diff" to
a subdirectory of another git repository.
-hpa
^ permalink raw reply
* Re: [PATCH] Remove empty directories in recursive merge
From: Alex Riesen @ 2008-09-25 20:33 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20080925201245.GB3959@blimp.localhost>
Alex Riesen, Thu, Sep 25, 2008 22:12:45 +0200:
> The code was actually supposed to do that, but was accidentally broken.
> Noticed by Anders Melchiorsen.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Shawn, the change is intentionally based on Junios master,
so people can just apply it. But if you wish, I can rebase it on top
of Miklos' patches.
^ permalink raw reply
* [PATCH] Fix memleak and the implementation of remove_file in builtin-rm.c
From: Alex Riesen @ 2008-09-25 20:22 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20080925201734.GA18315@blimp.localhost>
Actually, just replace it with the one from builtin-merge-recursive.c,
except for ignoring ENOENT error.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
It is the same as in merge-recursive, but they're so small so unless
we get a special file with such random routines there is no much point
exporting it. Actually, we do seem to have such a file: dir.c. It is
already plagued by file_exists kind of things, why not remove_path...
builtin-rm.c | 24 ++++++++++--------------
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index fdac34f..910a34d 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -31,22 +31,18 @@ static void add_list(const char *name)
static int remove_file(const char *name)
{
- int ret;
- char *slash;
-
- ret = unlink(name);
- if (ret && errno == ENOENT)
- /* The user has removed it from the filesystem by hand */
- ret = errno = 0;
-
- if (!ret && (slash = strrchr(name, '/'))) {
- char *n = xstrdup(name);
- do {
- n[slash - name] = 0;
- name = n;
- } while (!rmdir(name) && (slash = strrchr(name, '/')));
+ char *slash, *dirs;
+
+ if (unlink(name) && errno != ENOENT)
+ return -1;
+ dirs = xstrdup(name);
+ while ((slash = strrchr(name, '/'))) {
+ *slash = '\0';
+ if (rmdir(name) != 0)
+ break;
}
- return ret;
+ free(dirs);
+ return 0;
}
static int check_local_mod(unsigned char *head, int index_only)
--
1.6.0.2.328.g14651
^ permalink raw reply related
* [PATCH] Cleanup remove_path
From: Alex Riesen @ 2008-09-25 20:17 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20080925201245.GB3959@blimp.localhost>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
While at it, could we cleanup the remove_file routines a little?
builtin-merge-recursive.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index a29b47f..dc9652d 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -418,12 +418,10 @@ static int update_stages(const char *path, struct diff_filespec *o,
static int remove_path(const char *name)
{
- int ret;
char *slash, *dirs;
- ret = unlink(name);
- if (ret)
- return ret;
+ if (unlink(name))
+ return -1;
dirs = xstrdup(name);
while ((slash = strrchr(name, '/'))) {
*slash = '\0';
@@ -431,7 +429,7 @@ static int remove_path(const char *name)
break;
}
free(dirs);
- return ret;
+ return 0;
}
static int remove_file(int clean, const char *path, int no_wd)
--
1.6.0.2.328.g14651
^ permalink raw reply related
* [PATCH] Remove empty directories in recursive merge
From: Alex Riesen @ 2008-09-25 20:12 UTC (permalink / raw)
To: git; +Cc: Anders Melchiorsen, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <87k5d1v71l.fsf@cup.kalibalik.dk>
The code was actually supposed to do that, but was accidentally broken.
Noticed by Anders Melchiorsen.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Anders Melchiorsen, Wed, Sep 24, 2008 18:32:22 +0200:
> I got an empty directory left over today, and have reduced the problem
> to this sequence. If I leave out the second add (so the merge is a
> fast forward), the directory is removed as I would expect.
Ach, an old bug. Thanks for reminding!
builtin-merge-recursive.c | 4 +---
t/t3030-merge-recursive.sh | 11 +++++++++++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index dfb363e..a29b47f 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -444,10 +444,8 @@ static int remove_file(int clean, const char *path, int no_wd)
return -1;
}
if (update_working_directory) {
- unlink(path);
- if (errno != ENOENT || errno != EISDIR)
+ if (remove_path(path) && errno != ENOENT)
return -1;
- remove_path(path);
}
return 0;
}
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index de0cdb1..0de613d 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -535,4 +535,15 @@ test_expect_success 'reset and bind merge' '
'
+test_expect_success 'merge removes empty directories' '
+
+ git reset --hard master &&
+ git checkout -b rm &&
+ git rm d/e &&
+ git commit -mremoved-d/e &&
+ git checkout master &&
+ git merge -s recursive rm &&
+ test_must_fail test -d d
+'
+
test_done
--
1.6.0.2.328.g14651
^ permalink raw reply related
* Re: stg 0.14.3 breakage on push after moving hunk
From: Yann Dirson @ 2008-09-25 18:54 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, GIT list
In-Reply-To: <20080925083747.GC27632@diana.vm.bytemark.co.uk>
On Thu, Sep 25, 2008 at 10:37:47AM +0200, Karl Hasselström wrote:
> On 2008-09-25 09:57:32 +0200, Yann Dirson wrote:
>
> > Thanks, it does fix the exception - I feel a bit ashamed of not
> > having looked at the code myself ;)
>
> :-)
>
> > Nevertheless, that error was only hiding another more annoying
> > problem:
> >
> > $ ../stgit/stg push
> > Checking for changes in the working directory ... done
> > Pushing patch "factorize" ...
> > Error: File "t/t4030-diff-rename-factorize.sh" added in both, permissions conflict
> > Error: The merge failed during "push".
> > Use "refresh" after fixing the conflicts or revert the operation with "push --undo".
> > stg push: GIT index merging failed (possible conflicts)
> > $ md5sum t/t4030-diff-rename-factorize.sh*
> > cc313acd2824036556128b3e0879dd07 t/t4030-diff-rename-factorize.sh
> > cc313acd2824036556128b3e0879dd07 t/t4030-diff-rename-factorize.sh.current
> > cc313acd2824036556128b3e0879dd07 t/t4030-diff-rename-factorize.sh.patched
> >
> > AFAICT, adding the same file in 2 branches used not to produce a
> > conflict at all. Is that intended ?
>
> "permissions conflict" sounds like it was added with the exec bit in
> one branch, and without in the other. Is that right? And
> 1. Does it work if there's no permissions conflict?
Doh. Sure, it does work, and as expected. Some days really deserve to
be spent sleeping :}
> 2. Did it work before if there was a permissions conflict?
>
> Just a guess, but it's entirely plausible that this case never worked,
> and you're the first to hit it.
I is also entirely plausible that I lacked sleep enough not to read
correctly what was printed, and that the behaviour was indeed correct :>
The problem is mostly a limitation of the way stg-fold-files-from works,
relying on patchutils which do not know about git extensions to the diff
format. And since I mostly used it in the past on a git-cvsimport'ed
tree, permissions never bothered me.
Best regards,
--
Yann
^ permalink raw reply
* Re: having to pull twice
From: Alex Riesen @ 2008-09-25 18:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: Shawn O. Pearce, Miklos Vajna, Michael P. Soulier, git
In-Reply-To: <200809250905.09646.trast@student.ethz.ch>
Thomas Rast, Thu, Sep 25, 2008 09:05:02 +0200:
> Shawn O. Pearce wrote:
> > "Michael P. Soulier" <msoulier@digitaltorque.ca> wrote:
> > > I'm finding this happening from time to time.
> > >
> > > soulierm@espresso:~/work/mitel-msl-tug$ git pull
> > ...
> > > error: Entry 'mitel-msl-tug.spec' not uptodate. Cannot merge.
> [fixed by 'git status's index refresh]
> >
> > Time or dev/ino skew in the index file vs. what we read from stat.
> >
> > Running git-status rematched the index file to the working directory,
> > and during that rematch it noticed the file wasn't actually modified.
>
> This keeps coming up every week or so... maybe git-merge should
> attempt to refresh the index automatically? Of course it's an
> expensive operation, but if you really want to do the merge you have
> to bite that bullet anyway.
Maybe set "core.trustctime" for this repo to false?
^ permalink raw reply
* Re: re-licensing pkt-line.c code
From: Shawn O. Pearce @ 2008-09-25 18:01 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list, Andreas Ericsson
In-Reply-To: <48DBD114.80805@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Scott Chacon wrote:
>>
>> There are about 20-25 lines of code from pkt-line.c that I think were
>> originally written back in 2005 that I would like to use [...]
>>
>> I have to relicense this, since I can't legally distribute my source
>> code for the iphone app due to Apples f**king NDA. I would like to
>> release my ObjectiveGit project under the MIT (or, alternately, LGPL).
>
>> I could come up with an alternate way to
>> accomplish the same thing, but it seems like a waste of time to do so,
>> and helpful to nobody.
>
> Well, tracking down the original author(s) could turn out to be harder.
Its already cost more time to ask for permission to reuse these
20-25 lines of code than it would take to figure out how to write
it yourself, and code it. And Linus still hasn't had a chance to
chime in on this thread.
My guess is you aren't going to get approval from him to relicense
his code. But he doesn't hold a monopoly on int->hex conversion
algorithms so you should be able to implement something that produces
the same results, given the same inputs, and not have him sue you
in some Utah court.
--
Shawn.
^ permalink raw reply
* Re: re-licensing pkt-line.c code
From: Andreas Ericsson @ 2008-09-25 17:57 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0809251017h5509bbdmaef935c61cc0929@mail.gmail.com>
Scott Chacon wrote:
> Hey all,
>
> I am writing a partial implementation of git in Objective-C so I can
> get a git server running on an iphone, and hopefully it could
> eventually be used in a mac desktop app that could be distributed
> without the git binary. If anyone is interested in the project, you
> can get it here:
>
> http://github.com/schacon/objective-git
>
> There are about 20-25 lines of code from pkt-line.c that I think were
> originally written back in 2005 that I would like to use so I don't
> have to re-implement them. It is pretty generic - it is just the code
> that converts an int into a 4 char hex and back that is placed at the
> beginning of several of the network protocol lines.
>
> http://github.com/schacon/objective-git/tree/master/ObjGitServerHandler.m#L554
>
> I have to relicense this, since I can't legally distribute my source
> code for the iphone app due to Apples f**king NDA. I would like to
> release my ObjectiveGit project under the MIT (or, alternately, LGPL).
> Is Linus the right person to ask for this permission? What is the
> best way to do so?
Linus wrote nearly all of pkt-line.c, so yes, he'd be the right person
to ask. If the lines you need were co-authored by someone else, you'll
need to ask that co-author too.
> I could come up with an alternate way to
> accomplish the same thing, but it seems like a waste of time to do so,
> and helpful to nobody.
>
Well, tracking down the original author(s) could turn out to be harder.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Implementations of Git (was: re-licensing pkt-line.c code)
From: Jakub Narebski @ 2008-09-25 17:49 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0809251017h5509bbdmaef935c61cc0929@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
> I am writing a partial implementation of git in Objective-C so I can
> get a git server running on an iphone, and hopefully it could
> eventually be used in a mac desktop app that could be distributed
> without the git binary. If anyone is interested in the project, you
> can get it here:
>
> http://github.com/schacon/objective-git
Could you add it to "Interfaces to other programming languages"
section[1] at http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
if you feel it is quite ready?
[1] Perhaps it should be renamed to "Interfaces to and implementations
in other programming languages"...
P.S. Do you know what is the status of git#, implementation of Git in
C#, which was one of this year Google Summer of Code projects?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* re-licensing pkt-line.c code
From: Scott Chacon @ 2008-09-25 17:17 UTC (permalink / raw)
To: git list
Hey all,
I am writing a partial implementation of git in Objective-C so I can
get a git server running on an iphone, and hopefully it could
eventually be used in a mac desktop app that could be distributed
without the git binary. If anyone is interested in the project, you
can get it here:
http://github.com/schacon/objective-git
There are about 20-25 lines of code from pkt-line.c that I think were
originally written back in 2005 that I would like to use so I don't
have to re-implement them. It is pretty generic - it is just the code
that converts an int into a 4 char hex and back that is placed at the
beginning of several of the network protocol lines.
http://github.com/schacon/objective-git/tree/master/ObjGitServerHandler.m#L554
I have to relicense this, since I can't legally distribute my source
code for the iphone app due to Apples f**king NDA. I would like to
release my ObjectiveGit project under the MIT (or, alternately, LGPL).
Is Linus the right person to ask for this permission? What is the
best way to do so? I could come up with an alternate way to
accomplish the same thing, but it seems like a waste of time to do so,
and helpful to nobody.
Thanks,
Scott
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list (templating)
From: Petr Baudis @ 2008-09-25 17:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Wincent Colaiuta, git
In-Reply-To: <200809251852.23315.jnareb@gmail.com>
On Thu, Sep 25, 2008 at 06:52:22PM +0200, Jakub Narebski wrote:
> I think that making gitweb use something like Gitweb::Template, where
> action appearance is governed by templates, be it something like
> git-for-each-ref --format or StGit *.tmpl files, or XSLT / XSL,
> could be a good idea. But I think _that_ would require almost writing
> from scratch, certainly making it long-term gitweb fork, perhaps even
> with different name (and not residing inside git.git repository).
>
> We can discuss this idea here in this subthread. For example: do
> create Gitweb::Template like HTML::Template or use Template Toolkit;
> which parts put in template and which in "gitweb" driver, etc.
Actually, my implementation works quite differently - the idea of the
templates is that you just specify data from which files to show and
whether to take them right away or tabulate them in some way - so it is
something very abstract, and agnostic to _presentation_ layer, which is
still provided by gitweb. An example of made-up template configuration
file would look something like:
[action "summary"]
sections = metadata overview README shortlog forks
[section "overview"]
type = csv
row = Project Title,(info.txt:title)
row = Project Authors,(info.txt:authors)
row = Bussiness Impact,(info.txt:bizimpact)
row = Base Equation,[formula.png]
[section "README"]
type = html
content = (README.html)
(where info.txt is another gitconfig-ish file in tree root, one that
the user actually touches).
When I post the patch, I will probably apply it to repo.or.cz too so
that I can show-case this in practice.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* [PATCH] gitweb: Clean-up sorting of project list
From: Petr Baudis @ 2008-09-25 16:48 UTC (permalink / raw)
To: git, git; +Cc: Mike Ralphson
In-Reply-To: <e2b179460807231010m44ff446auc054ead9178c711b@mail.gmail.com>
This decouples the sorting of project list and printing the column
headers, so that the project list can be easily sorted even when
the headers are not shown.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 45 ++++++++++++++++++++-------------------------
1 files changed, 20 insertions(+), 25 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index da474d0..bd81e14 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3605,19 +3605,13 @@ sub fill_project_list_info {
return @projects;
}
-# print 'sort by' <th> element, either sorting by $key if $name eq $order
-# (changing $list), or generating 'sort by $name' replay link otherwise
+# print 'sort by' <th> element, generating 'sort by $name' replay link
+# if that order is not selected
sub print_sort_th {
- my ($str_sort, $name, $order, $key, $header, $list) = @_;
- $key ||= $name;
+ my ($name, $order, $header) = @_;
$header ||= ucfirst($name);
if ($order eq $name) {
- if ($str_sort) {
- @$list = sort {$a->{$key} cmp $b->{$key}} @$list;
- } else {
- @$list = sort {$a->{$key} <=> $b->{$key}} @$list;
- }
print "<th>$header</th>\n";
} else {
print "<th>" .
@@ -3627,14 +3621,6 @@ sub print_sort_th {
}
}
-sub print_sort_th_str {
- print_sort_th(1, @_);
-}
-
-sub print_sort_th_num {
- print_sort_th(0, @_);
-}
-
sub git_project_list_body {
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
@@ -3645,20 +3631,29 @@ sub git_project_list_body {
$from = 0 unless defined $from;
$to = $#projects if (!defined $to || $#projects < $to);
+ my %order_info = (
+ project => { key => 'path', type => 'str' },
+ descr => { key => 'descr_long', type => 'str' },
+ owner => { key => 'owner', type => 'str' },
+ age => { key => 'age', type => 'num' }
+ );
+ my $oi = $order_info{$order};
+ if ($oi->{'type'} eq 'str') {
+ @projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
+ } else {
+ @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
+ }
+
print "<table class=\"project_list\">\n";
unless ($no_header) {
print "<tr>\n";
if ($check_forks) {
print "<th></th>\n";
}
- print_sort_th_str('project', $order, 'path',
- 'Project', \@projects);
- print_sort_th_str('descr', $order, 'descr_long',
- 'Description', \@projects);
- print_sort_th_str('owner', $order, 'owner',
- 'Owner', \@projects);
- print_sort_th_num('age', $order, 'age',
- 'Last Change', \@projects);
+ print_sort_th('project', $order, 'Project');
+ print_sort_th('descr', $order, 'Description');
+ print_sort_th('owner', $order, 'Owner');
+ print_sort_th('age', $order, 'Last Change');
print "<th></th>\n" . # for links
"</tr>\n";
}
--
tg: (c427559..) t/forks/sort-refactor (depends on: vanilla/master)
^ permalink raw reply related
* [PATCH] gitweb: Sort the list of forks on the summary page by age
From: Petr Baudis @ 2008-09-25 16:48 UTC (permalink / raw)
To: git, git; +Cc: Petr Baudis, Mike Ralphson
In-Reply-To: <1222361317-17275-1-git-send-email-pasky@suse.cz>
From: Petr Baudis <pasky@suse.cz>
From: Mike Ralphson <mike@abacus.co.uk>
The list of forks on the summary page was unsorted, this just makes
them sorted by age, which seems a fair way to decide which forks are
shown before the list size cut-off (15) kicks in.
s/noheader/no_header was just to make it obvious what the parameter
affects, so all the code can be found with one grep.
pb: As suggested by Mike, I have augmented this by an additional patch
that refactors the sorting logic so that it is not tied to printing
the headers.
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bd81e14..0f8a564 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4119,10 +4119,10 @@ sub git_summary {
if (@forklist) {
git_print_header_div('forks');
- git_project_list_body(\@forklist, undef, 0, 15,
+ git_project_list_body(\@forklist, 'age', 0, 15,
$#forklist <= 15 ? undef :
$cgi->a({-href => href(action=>"forks")}, "..."),
- 'noheader');
+ 'no_header');
}
git_footer_html();
--
tg: (513dad1..) t/forks/sort-by-age (depends on: t/forks/sort-refactor)
^ permalink raw reply related
* Re: [RFC] gitweb wishlist and TODO list (templating)
From: Jakub Narebski @ 2008-09-25 16:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Wincent Colaiuta, git
In-Reply-To: <20080925133320.GK10360@machine.or.cz>
Petr Baudis wrote:
> On Thu, Sep 25, 2008 at 03:19:09PM +0200, Wincent Colaiuta wrote:
> >
> > One which I'm looking at doing is supporting reading the "README.html" from
> > the tree indicated by the current HEAD instead of reading it from a file in
> > the .git directory.
[...]
> > Obviously, will have to make this optional and configurable. I'm thinking
> > of providing a means of specifying the filename to look for (no filename,
> > the default, means don't look), and also a setting to indicate the content
> > type of the file (either plain text, which would be wrapped in a
> > <pre></pre> block with HTML entities used where appropriate, or HTML which
> > would be included verbatim).
>
> In my queue and something I will hopefully get to submit tomorrow or at
> the beginning of next week is actually support for full-blown templating
> of gitweb pages (customization of the summary page, even adding extra
> project actions) based on gitconfig-style specification within the
> project HEAD. In its simplest variant, this could be used for including
> a README from the HEAD tree as well, I think. But it's in the same class
> as the git-gui support for the 'publish' dialog, something potentially
> useful for others, but not *universally* useful and in this case,
> unfortunately somewhat invasive.
I think that making gitweb use something like Gitweb::Template, where
action appearance is governed by templates, be it something like
git-for-each-ref --format or StGit *.tmpl files, or XSLT / XSL,
could be a good idea. But I think _that_ would require almost writing
from scratch, certainly making it long-term gitweb fork, perhaps even
with different name (and not residing inside git.git repository).
We can discuss this idea here in this subthread. For example: do
create Gitweb::Template like HTML::Template or use Template Toolkit;
which parts put in template and which in "gitweb" driver, etc.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [QGit] Some suggestion
From: Marco Costalba @ 2008-09-25 16:34 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE96079FBB@zch01exm23.fsl.freescale.net>
On Thu, Sep 25, 2008 at 4:20 PM, Li Frank-B20596 <Frank.Li@freescale.com> wrote:
> Marco:
>
> Ctrl +/- change font size, but how to change source code view
> font size.
>
Edit->Settings->Fixed width font
You can choose size, font family, bolding, etc...
File view and diff view are optimized for source code viewing so use
fixed pitch fonts, not system default one that normally it is not
fixed pitch.
^ permalink raw reply
* Re: [PATCH] gitweb: shortlog now also obeys $hash_parent
From: Petr Baudis @ 2008-09-25 15:44 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <1218204731-9931-1-git-send-email-giuseppe.bilotta@gmail.com>
On Fri, Aug 08, 2008 at 04:12:11PM +0200, Giuseppe Bilotta wrote:
> If $hash_parent is defined, shortlog now limits the list of commits at
> those between $hash_parent (exclusive) and $hash (inclusive).
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
That sounds like a useful feature.
Acked-by: Petr Baudis <pasky@suse.cz>
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2008-09-25 15:41 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, Petr Baudis
In-Reply-To: <B3B6996F-EC51-49DC-8ECE-DBA25E8F61DE@wincent.com>
On Thu, 25 Sep 2008, Wincent Colaiuta wrote:
> El 25/9/2008, a las 12:30, Jakub Narebski escribió:
>
> > This is yet another series of planned gitweb features. It expands more
> > on new user-visible features than on improving gitweb code (therefore
> > for example using Git.pm/Git::Repo, gitweb caching, and list form of
> > open for pipelines are not mentioned here).
> >
> > Which tasks / features are most requested? Which tasks should be done
> > first? What do you have on your gitweb TODO list?
>
> One which I'm looking at doing is supporting reading the "README.html"
> from the tree indicated by the current HEAD instead of reading it from
> a file in the .git directory.
One problem is with the concept of using "current HEAD" for that.
I have nothing against for example showing README or README.html (in
some order of preference), or initial fragment of it with link to full
version ('blob' view), either below or above 'tree' view, like
GitHub and Gitorious does. When you are on 'tree' view you are on
some branch, even implicitly[1]. But for 'summary' view, which is
currently the only view that shows $GIT_DIR/README.html, you are not.
It might happen that you push to git hosting site while on some side
unrelated branch like 'todo', 'html' or 'man' pages in git.git, or
are on branch spawned off subtree-merged subproject like git-gui;
or your gitweb shows state of live non-bare repo and you happen to be
on such branch. What then? Repository description vanishing by
accident is not a good solution...
[1] And you can have different READMEs shown for different subprojects,
like there is README, and gitweb/README, and contrib/README, etc.
> This should make tracking and updating such READMEs a little easier as
> all that'll be required is a "push" to advance the HEAD and the new
> README goes live.
>
> Obviously, will have to make this optional and configurable. I'm
> thinking of providing a means of specifying the filename to look for
> (no filename, the default, means don't look), and also a setting to
> indicate the content type of the file (either plain text, which would
> be wrapped in a <pre></pre> block with HTML entities used where
> appropriate, or HTML which would be included verbatim).
Well, $GIT_DIR/README.html was meant as extension of simple project
description ($GIT_DIR/description or gitweb.description in config).
One paragraph of concise short description; something like projects
description on software hosting site like SourceForge or Savannah,
or software metric site like Ohloh, or software catalog/directory
like Freshmeat. It is meant as short introduction to project, or
to be more exact to given repository (see below).
In-tree README has different purpose. Besides describing project
in detail, it usually has some instructions on how to install it
(even if it is referring to INSTALL file), how to configure it,
how to use it; should have all the things required by GNU Coding
Standards and/or Gnits Standards. It is usually therefore much
longer than $GIT_DIR/README.html (and usually does not use HTML,
but [almost] plain text); so I think gitweb should display around
some given number of lines, ending at break between paragraph if
possible.
Besides $GIT_DIR/README.html can describe specific _repository_,
either some fork of a project (like who created it, what is purpose
of this fork, even if in-tree README remains the same; an example
would be git.git repository forks for git GSoC projects), or
specific mirror (for example describing difference between git.git
and alt-git.git on repo.or.cz).
But I would be not against having in-tree (with the mentioned caveat
of using top-tree HEAD version) README or README.html as fallback
if $GIT_DIR/README.html does not exists, taking into account some
order of preference among README* files if there exists more than one
such file, and displaying it not in full if in-tree README is large.
Alternate solution would be add some kind of _gitweb-admin_ script,
which would allow to set parameters of gitweb or of repository
displayed in gitweb on-line, which would include one-line plain-text
description of a project, and short README.html. Although I'm
not sure if it should be not left for higher level of hosting site
(Gitorious, repo/Girocco, GitHub, Savane-clean, GForge,...).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [JGIT PATCH] Test and fix handling of quotes in ~/.ssh/config
From: Robin Rosenberg @ 2008-09-25 6:26 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Shawn O. Pearce, sverre, git
In-Reply-To: <20080924232519.GA15318@diku.dk>
torsdagen den 25 september 2008 01.25.19 skrev Jonas Fonseca:
> Using exceptions seems a bit harsh, since the quote is not really fatal
> in anyway. Also, for badly formatted Port values the value is simply ignored.
For this case OpenSSH complains about a missing parameter. It does not
even attempt to look up the host. For malformed port numbers I get "Bad number"
(and no attempt to connect. I think an exception is the right way to solve the
problem si nce the caller doesn't have to do the error checking. and the error
is more obvious to the user. OpenSSH also gives the line number. Maybe we
should too.
The OpenSSH i'm referencing is openssh-5.1p1-1mdv2009.0
-- robin
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Petr Baudis @ 2008-09-25 15:31 UTC (permalink / raw)
To: Julian Phillips; +Cc: Jordi Bunster, git, gitster
In-Reply-To: <Pine.LNX.4.64.0807241600190.7093@reaper.quantumfyre.co.uk>
On Thu, Jul 24, 2008 at 04:04:03PM +0100, Julian Phillips wrote:
> On Thu, 24 Jul 2008, Petr Baudis wrote:
>> On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>>> I've been following the git mailing list to stay on top of new releases,
>>> but the traffic got too high.
>>>
>>> Any way that a git-announce list could be created for security fixes and
>>> new releases? Or maybe an RSS feed on the website?
>
> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
Thanks, I have added the RSS feeds to the git.or.cz homepage.
> ---
> Peter's hungry, time to eat lunch.
Mmm...
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ 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