Re: Suggestions for "What's cooking"
On 09/13/2012 12:49 AM, Philip Oakley wrote: > My comment, as a simple reader, is that I misread the order of the > items, in that I miss-associate the description paragraph with the * > title _below_. That is, I see the description first and then read on... > > Thinking about it, if the description paragraph was indented by one > space then the * title would create that obvious content indent that (I > am) would be expected. +1. When I started reading the "What's cooking", I found it hard to tell/remember whether text comments apply to the list of patches above them or below them. If you don't want to make bigger changes to the format, then even an extra blank line between the section about each patch series would remove the ambiguity. Otherwise, I think that "What's cooking" emails are a great service that you provide to the community. They help mitigate the inconvenience of using emails rather than pull requests for exchanging and managing patches :-) Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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 v5 4/4] make poll() work on platforms that can't recv() on a non-socket
This way it just got added to gnulib too. Signed-off-by: Joachim Schmitz --- compat/poll/poll.c | 5 + 1 file changed, 4 insertions(+) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index e4b8319..10a204e 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -306,6 +306,10 @@ compute_revents (int fd, int sought, fd_set *rfds, fd_set *wfds, fd_set *efds) || socket_errno == ECONNABORTED || socket_errno == ENETRESET) happened |= POLLHUP; + /* some systems can't use recv() on non-socket, including HP NonStop */ + else if (socket_errno == ENOTSOCK) + happened |= (POLLIN | POLLRDNORM) & sought; + else happened |= POLLERR; } -- 1.7.12 -- 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 v3 1/4] poll() exits too early with EFAULT if 1st arg is NULL
Joachim Schmitz wrote:
Joachim Schmitz wrote:
If poll() is used as a milli-second sleep, like in help.c, by passing
a NULL in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be
fixed like in this commit, which is not to exit if the 2nd arg is 0.
Signed-off-by: Joachim Schmitz
---
compat/win32/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/win32/poll.c b/compat/win32/poll.c
index 403eaa7..9e7a25c 100644
--- a/compat/win32/poll.c
+++ b/compat/win32/poll.c
@@ -349,7 +349,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int
timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd && nfd)
{
errno = EFAULT;
return -1;
Actually this one is not needed for win32 (nor does win32 suffer from
a similar bug), so should probably better get added after patch 2/2
(or as part of it), the move to compat/poll/.
It just got added that was to gnulib, with a commit message of:
don't exit early if NULL is the 1st arg to poll(),
but nfd is 0. In that case poll should behave like select.
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: Suggestions for "What's cooking"
From: "Philip Oakley" Sent: Wednesday, September 12, 2012 11:49 PM From: "Jens Lehmann" Sent: Wednesday, September 12, 2012 8:21 PM Am 11.09.2012 21:41, schrieb Junio C Hamano: Thanks. I wish all others paid attention to "What's cooking" like you did here. And if it is hard to do so for whatever reason, suggest a better way for me to publish "What's cooking" or an equivalent (I am interested in finding the least bureaucratic way to help people and keep the balls rolling). I think "What's cooking" makes lots of sense in its current form as one gets a very good overview over current development tracks. Maybe in addition it would be nice to email the author(s) of a series when the state changes or new comments are added (and to only include the relevant part from "What's cooking" there). For me it's not a big problem as I just have to grep for "submodule" to get the bits I care about, but I suspect others might have to invest much more time to check the current state of their series and may appreciate being mailed directly when something happens. Opinions? My comment, as a simple reader, is that I misread the order of the items, in that I miss-associate the description paragraph with the * title _below_. That is, I see the description first and then read on... Thinking about it, if the description paragraph was indented by one space then the * title would create that obvious content indent that (I am) would be expected. Obviously only a useful suggestion if it's easy to implement... Philip Thinking overnight. One very simple option is to just add a double line spacing between items to give a clearer break. i.e. previous item ends.LF LF LF * Next Item -- 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] rev-list/log: document logic with several limiting options
Junio C Hamano venit, vidit, dixit 12.09.2012 19:25:
> Michael J Gruber writes:
>
>> It was introduced in 0ab7befa with a clear meaning (AND everything),
>> then the general logic (without --all-match) was modified in 80235ba7
>> (to take headermatch AND (all greps ORed)), and 5aaeb733 finally made
>> multiple authors resp. committers get ORed among each other. All of this
>> in an attempt to make the standard usage most useful, of course. As a
>> consequence, --all-match does not influence multiple --author options at
>> all (contrary to the doc), e.g.
>>
>> I don't see any of this reflected in the doc, though. I noticed only by
>> reading t/t7810-grep.sh. Before that, I had only gone by my own testing
>> which didn't reveal the multiple author multiple special casing effect.
>>
>> I guess I'll have to wrap my head around the current implementation a
>> few more times before trying to describe the status quo in the
>> documentation...
>
> This is what I used to use when adding these generalized grep
> boolean expressions.
>
> With this applied, you can try things like these:
>
> $ git log --grep=regexp --grep=nosuch --all-match >/dev/null
> $ git log --grep=regexp --grep=nosuch --author=Michael >/dev/null
>
> For example, "--all-match --grep=regexp --author=Michael --author=Linus" turns
> into
>
> [all-match]
> (or
> pattern_bodyregexp
> (or
> (or
>pattern_headLinus
>pattern_headMichael
> )
> true
> )
> )
>
> that says "body must have 'regexp' in it, and authored by either
> Linus or Michael".
>
> The semantics of "--all-match" is different from "--and" (which,
> together with "--or", ")", and "(", is not availble to rev-list
> command line parser primarily because "--not" is not available).
> After applying all the "or"-ed terms, it checks the top-level nodes
> that are "or"-ed and makes sure all of them fired (possibly and
> usually on different lines).
Thanks for "this" ;)
I'll recheck my understanding and update the doc then. Maybe even
putting the above in-tree with a "--debug" option seems inline with
things such as "git describe --debug" (and maybe a preparation for
exposing a richer interface).
Michael
--
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 v2] cherry-pick: don't forget -s on failure
In case 'git cherry-pick -s ' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Also update 'git commit -s', so that in case there is already a relevant
Signed-off-by line before the Conflicts: line, it won't add one more at
the end of the message.
Signed-off-by: Miklos Vajna
---
On Wed, Sep 12, 2012 at 03:45:10PM -0700, Junio C Hamano
wrote:
> - The additional S-o-b should come immediately after the existing
>block of footers.
This was trivial to fix.
> - And the last entry in the existing footer block is already mine,
>so there shouldn't have been a new and duplicated one added.
>
>
> I am not sure how reusable the moved function is without
> enhancements for your purpose. The logic to identify the footer
> needs to be enhanced so that an "end" pointer to point at the byte
> before the caller added "Conflicts: " can be given, and pretend as
> if it is the end of the buffer, unlike in the fresh commit case
> where it can consider the real end of the buffer as such.
Below is what I came up with. It simply ignores anything after the
Conclicts: line, when checking for the last Signed-off-by line.
An other thing: I forgot to run 'make test' for the initial patch, it
seems t3510-cherry-pick-sequence.sh has 3 tests that basically ensures
the opposite of what my patch does. Given that there are already
testcases for the new behaviour, can they be just removed? For now, I
just disabled them.
builtin/commit.c| 79 +++---
sequencer.c | 65
sequencer.h |4 ++
t/t3507-cherry-pick-conflict.sh | 14 +++
t/t3510-cherry-pick-sequence.sh |6 +-
t/test-lib-functions.sh |8 +++-
6 files changed, 116 insertions(+), 60 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 778cf16..4d50484 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -28,6 +28,7 @@
#include "submodule.h"
#include "gpg-interface.h"
#include "column.h"
+#include "sequencer.h"
static const char * const builtin_commit_usage[] = {
N_("git commit [options] [--] ..."),
@@ -466,8 +467,6 @@ static int is_a_merge(const struct commit *current_head)
return !!(current_head->parents && current_head->parents->next);
}
-static const char sign_off_header[] = "Signed-off-by: ";
-
static void export_one(const char *var, const char *s, const char *e, int hack)
{
struct strbuf buf = STRBUF_INIT;
@@ -552,47 +551,6 @@ static void determine_author_info(struct strbuf
*author_ident)
}
}
-static int ends_rfc2822_footer(struct strbuf *sb)
-{
- int ch;
- int hit = 0;
- int i, j, k;
- int len = sb->len;
- int first = 1;
- const char *buf = sb->buf;
-
- for (i = len - 1; i > 0; i--) {
- if (hit && buf[i] == '\n')
- break;
- hit = (buf[i] == '\n');
- }
-
- while (i < len - 1 && buf[i] == '\n')
- i++;
-
- for (; i < len; i = k) {
- for (k = i; k < len && buf[k] != '\n'; k++)
- ; /* do nothing */
- k++;
-
- if ((buf[k] == ' ' || buf[k] == '\t') && !first)
- continue;
-
- first = 0;
-
- for (j = 0; i + j < len; j++) {
- ch = buf[i + j];
- if (ch == ':')
- break;
- if (isalnum(ch) ||
- (ch == '-'))
- continue;
- return 0;
- }
- }
- return 1;
-}
-
static char *cut_ident_timestamp_part(char *string)
{
char *ket = strrchr(string, '>');
@@ -717,21 +675,30 @@ static int prepare_to_commit(const char *index_file,
const char *prefix,
stripspace(&sb, 0);
if (signoff) {
- struct strbuf sob = STRBUF_INIT;
- int i;
+ /*
+* See if we have a Conflicts: block at the end. If yes, count
+* its size, so we can ignore it.
+*/
+ int ignore_footer = 0;
+ int i, eol, previous = 0;
+ const char *nl;
- strbuf_addstr(&sob, sign_off_header);
- strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
-getenv("GIT_COMMITTER_EMAIL")));
- strbuf_addch(&sob, '\n');
- for (i = sb.len - 1; i > 0 && sb.buf[i - 1] != '\n'; i--)
- ; /* do nothing */
- if (prefixcmp(sb.buf + i, sob.buf)) {
- if (!i || !ends_rfc2822_footer(&sb))
- strbuf_addch(&sb,
[PATCH/RFC] remote-helper: allow fetch to discover sha1 later
From: "Devin J. Pohly"
Allow a fetch-style remote helper to issue the notification
ref
to specify a ref's value during the fetch operation.
Currently, a remote helper with the "fetch" capability cannot fetch a
ref unless its sha1 was known when the "list" command was executed.
This limitation is arbitrary, as the helper may eventually be able to
determine the correct sha1 as it fetches objects.
Signed-off-by: Devin J. Pohly
---
Soliciting general opinions - first git patch. :)
The fetch command can be a lot more convenient than import if you're working
with a remote that doesn't give you a commit and the associated objects at the
same time. And there's no apparent reason that something like this isn't
possible.
How it works: the old_sha1 field is currently set when the output from "list"
is parsed, then not used again until after the "fetch" command completes, just
before updating refs. Changing it during the fetch only affects the final
value of the ref. (Forgetting to resolve a ref will result in exactly the
same behavior as before: an error from check_everything_connected.)
Not sure if either or both of the warning()s should be a die() instead.
Documentation/git-remote-helpers.txt | 8 ++--
transport-helper.c | 24
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git-remote-helpers.txt
index f5836e4..fb4240f 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -229,8 +229,12 @@ Supported if the helper has the "option" capability.
to the database. Fetch commands are sent in a batch, one
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
- same batch are complete. Only objects which were reported
- in the ref list with a sha1 may be fetched this way.
+ same batch are complete.
++
+If the named ref was reported in the ref list without a sha1, must
+output a 'ref ' line once the sha1 is known. This is
+also required for a symref if its target did not have a sha1 in the
+list.
+
Optionally may output a 'lock ' line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
diff --git a/transport-helper.c b/transport-helper.c
index cfe0988..6fce419 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -363,6 +363,30 @@ static int fetch_with_fetch(struct transport *transport,
warning("%s also locked %s", data->name, name);
else
transport->pack_lockfile = xstrdup(name);
+ } else if (!prefixcmp(buf.buf, "ref ")) {
+ const char *rest = buf.buf + 4;
+ char *eov, *eon;
+ struct ref *posn;
+
+ eov = strchr(rest, ' ');
+ if (!eov)
+ die("Malformed ref command: %s", buf.buf);
+ eon = strchr(eov + 1, ' ');
+ *eov = '\0';
+ if (eon)
+ *eon = '\0';
+ for (i = 0; i < nr_heads; i++) {
+ posn = to_fetch[i];
+ if (!strcmp(eov + 1, posn->name))
+ break;
+ }
+ if (i == nr_heads || (posn->status &
REF_STATUS_UPTODATE)) {
+ warning("Ref %s is not being fetched", eov + 1);
+ continue;
+ }
+ if (!is_null_sha1(posn->old_sha1))
+ warning("Ref %s is being overwritten", eov + 1);
+ get_sha1_hex(rest, posn->old_sha1);
}
else if (!buf.len)
break;
--
1.7.12
--
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: [GIT PULL] sound fixes for 3.6-rc6
On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote: > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus *PLEASE* don't do this. You point to a branch, but then the pull request clearly implies there is a tag with extra information in it. And indeed, the actual thing I should pull is not at all "for-linus", it seems to be your "tags/sound-3.6" tag. I don't know if this is the old "git pull-request" breakage where it stupidly "corrects" the remote branch when it verifies the branch name, or whether it's some other scripting problem. I think current git versions should not mess up the tag information, if that's the cause, but please verify. Linus -- 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: [GIT PULL] sound fixes for 3.6-rc6
At Thu, 13 Sep 2012 19:51:14 +0800, Linus Torvalds wrote: > > On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote: > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus > > *PLEASE* don't do this. > > You point to a branch, but then the pull request clearly implies there > is a tag with extra information in it. > > And indeed, the actual thing I should pull is not at all "for-linus", > it seems to be your "tags/sound-3.6" tag. > > I don't know if this is the old "git pull-request" breakage where it > stupidly "corrects" the remote branch when it verifies the branch > name, or whether it's some other scripting problem. I think current > git versions should not mess up the tag information, if that's the > cause, but please verify. Oops, yes, it's indeed intended to be tags/sound-3.6. So please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.6 FWIW, it was an output from git-pull-request, which fell back to the equivalent branch. Usually I check it manually but I forgot it at this time just before going to a meeting. This was with git 1.7.11.5. I'll check whether this still happens with 1.7.12. Takashi -- 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: [GIT PULL] sound fixes for 3.6-rc6
At Thu, 13 Sep 2012 14:03:16 +0200, Takashi Iwai wrote: > > At Thu, 13 Sep 2012 19:51:14 +0800, > Linus Torvalds wrote: > > > > On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote: > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus > > > > *PLEASE* don't do this. > > > > You point to a branch, but then the pull request clearly implies there > > is a tag with extra information in it. > > > > And indeed, the actual thing I should pull is not at all "for-linus", > > it seems to be your "tags/sound-3.6" tag. > > > > I don't know if this is the old "git pull-request" breakage where it > > stupidly "corrects" the remote branch when it verifies the branch > > name, or whether it's some other scripting problem. I think current > > git versions should not mess up the tag information, if that's the > > cause, but please verify. > > Oops, yes, it's indeed intended to be tags/sound-3.6. > So please pull from: > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.6 > > > FWIW, it was an output from git-pull-request, which fell back to the > equivalent branch. Usually I check it manually but I forgot it at > this time just before going to a meeting. > > This was with git 1.7.11.5. I'll check whether this still happens > with 1.7.12. The same problem still happens with git 1.7.12. This is rather annoying than useful. Takashi -- 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: {bug} warning: unable to access 'RelNotes/.gitattributes'
On Wed, Sep 12, 2012 at 11:32:22PM -0700, Junio C Hamano wrote: > "git repack" started giving the above warning, and I am guessing > that the recent 11e50b2 (attr: warn on inaccessible attribute files, > 2012-08-21) exposed a bug where we ask stat(2) not lstat(2) by > mistake before deciding to append .gitattributes to see if that > directory has a per-directory attributes file. Interesting. I don't get any such warning on repack. And RelNotes points to a file, so I'm not sure why stat() would make us think it was a dir. > We simply used to notice and ignore any failure from open() and moved > on, but we started distinguishing between ENOENT and others (in this > case, we get ENOTDIR), and added a warning for non-ENOENT cases and I > think that is what I am seeing. I can provoke such a warning by doing: git check-attr -a RelNotes/foo I haven't decided whether that's a good or bad thing. It makes sense, since the file you are asking for would get ENOTDIR, but maybe somebody is feeding junk to check-attr. -Peff -- 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] Documentation: Use 'First Paragraph' instead of 'First Line'.
The discussion of email subject throughout the documentation is misleading; it indicates that the first line will become the subject. In fact, the first and second and third lines will become the subject, up until the first full blank line. Describing it as the first paragraph is more accurate. Signed-off-by: Jeremy White --- Documentation/git-commit.txt |2 +- Documentation/git-for-each-ref.txt |2 +- Documentation/git-format-patch.txt |8 +--- Documentation/git-shortlog.txt |2 +- Documentation/gitcore-tutorial.txt |2 +- Documentation/gittutorial.txt |2 +- Documentation/user-manual.txt |2 +- 7 files changed, 11 insertions(+), 9 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index e99bb14..a61bca9 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -349,7 +349,7 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line +Tools that turn commits into email, for example, use the first paragraph on the Subject: line and the rest of the commit in the body. include::i18n.txt[] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 7e83288..499c26a 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -100,7 +100,7 @@ Fields that have name-email-date tuple as its value (`author`, `committer`, and `tagger`) can be suffixed with `name`, `email`, and `date` to extract the named component. -The first line of the message in a commit and tag object is +The first paragraph of the message in a commit and tag object is `subject`, the remaining lines are `body`. The whole message is `contents`. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 9674f9d..e6f6d0e 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -57,10 +57,12 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in . Otherwise they are created in the current working directory. -By default, the subject of a single patch is "[PATCH] First Line" and +By default, the subject of a single patch is "[PATCH] First Paragraph" and the subject when multiple patches are output is "[PATCH n/m] First -Line". To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +Paragraph". Note that "First Paragraph" consists of text in the commit message +prior to the first completely blank line (see the DISCUSSION section +in linkgit:git-commit[1]). To force 1/1 to be added for a single patch, +use `-n`. To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index dfd4d0c..9464932 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -15,7 +15,7 @@ DESCRIPTION --- Summarizes 'git log' output in a format suitable for inclusion in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +the first paragraph of the commit message will be shown. Additionally, "[PATCH]" will be stripped from the commit description. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index f7815e9..92f97e6 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their +and the first paragraph of the commit log message from their top-of-the-tree commits, you are currently on `master` branch (notice the asterisk `\*` character), and the first column for the later output lines is used to show commits contained in the diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 1c16066..a1bc56c 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -139,7 +139,7 @@ A note on commit messages: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for -example, use the first line on the Subject: line and the rest of the +example, use the first paragraph on the Subject: line and the rest of the commit in the body. Git trac
Re: [GIT PULL] sound fixes for 3.6-rc6
On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote: > > FWIW, it was an output from git-pull-request, which fell back to the > > equivalent branch. Usually I check it manually but I forgot it at > > this time just before going to a meeting. > > > > This was with git 1.7.11.5. I'll check whether this still happens > > with 1.7.12. > > The same problem still happens with git 1.7.12. > This is rather annoying than useful. I can't reproduce here. What is your exact request-pull invocation? Is request-pull showing a warning like: warn: You locally have sound-3.6 but it does not (yet) warn: appear to be at git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git warn: Do you want to push it there, perhaps? (it should do so since v1.7.11.2). Maybe we need to make it possible to bump that warning to a fatal error? -Peff -- 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: [GIT PULL] sound fixes for 3.6-rc6
At Thu, 13 Sep 2012 09:03:44 -0400, Jeff King wrote: > > On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote: > > > > FWIW, it was an output from git-pull-request, which fell back to the > > > equivalent branch. Usually I check it manually but I forgot it at > > > this time just before going to a meeting. > > > > > > This was with git 1.7.11.5. I'll check whether this still happens > > > with 1.7.12. > > > > The same problem still happens with git 1.7.12. > > This is rather annoying than useful. > > I can't reproduce here. What is your exact request-pull invocation? Is > request-pull showing a warning like: > > warn: You locally have sound-3.6 but it does not (yet) > warn: appear to be at > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > warn: Do you want to push it there, perhaps? Hm, it looks like the check is performed only for tag objects. In the example below, no warning appears: % git tag mytest for-next % git request-pull mytest~ git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git mytest With an annotated or a signed tag, git seems giving a warning like above, indeed. So my test seemed wrong. Sorry for the noise. In the previous case, I don't know what really screwed up, since it was against a signed tag. Maybe I overlooked the warning as I'm redirecting the output to a file. > (it should do so since v1.7.11.2). Maybe we need to make it possible to > bump that warning to a fatal error? Yes, please! It's easily overlooked. Better to be "strict but correct" than "friendly but wrong". Just give an option to ignore the error if people really want to ignore it. thanks, Takashi -- 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 RFC 0/2] Mixing English and a local language
On Wed, Sep 12, 2012 at 11:18:06AM -0700, Junio C Hamano wrote: > I am so far taking the silence in the thread to mean they do not mind > seeing the diffstat summary untranslated and they do not mind seeing > it in Klingon, as long as the three numbers are there with (+) and (-) > markings. Actually, I have found the "Klingon" appearing in the diffstat of recent messages to the list to be mildly annoying. I can decipher it, of course, but in some cases I do not even have the glyphs in my font to render the string, and it is quite ugly. I think in an ideal world each repo could specify a "project language" and, and diffstat, Signed-off-by, and [PATCH] would all be in that language. Practically speaking, I'm not sure how much effort that is worth; it seems like non-English speakers adapt to a few English phrases (for example, email headers and date formats are all in English; I imagine many clients localize them behind the scenes, but certainly the "git format-patch && $EDITOR && git send-email" workflow does not and should not). I think I'd prefer: 1. Revert diffstat to always be in English/C locale for now. For all commands. People too frequently end up showing the output of things besides format-patch. It means they will have to read the English when they are just running locally, but since format-patch is generating it, it is something that they would need to understand anyway. 2. If people on non-English projects find that too cumbersome, then we can switch the "English/C" above for `i18n.projectlang` or something. But it should not be per-command, but per-message, and should include all output that is not diagnostic and is not machine-parseable (e.g., what I mentioned above, request-pull output, etc). If it is the project's language, then the team members will need to know it anyway, so it should not be too big a burden to have a potentially different language there than in the diagnostic messages. But take my opinion with a grain of salt. English is my first language, so I have zero first-hand experience with these issues. For most open source projects that operate in English, I think just (1) will be fine. The real test for needing (2) would not be a project like git, but a project conducted solely in another language, where some of the participants do not speak English at all. -Peff -- 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
Failing svn imports from apache.org
Hi folks, I'm currently trying to import apache.org svn server, without success. See: git@moonshine:~/projects/common/libs$ git svn clone --stdlayout http://svn.apache.org/repos/asf/commons/proper/discovery/ Initialized empty Git repository in /home/git/projects/common/libs/discovery/.git/ W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: '/repos/asf/!svn/bc/100/commons/proper/discovery' path not found W: Do not be alarmed at the above message git-svn is just searching aggressively for old history. This may take a while on large repositories mkdir .git: No such file or directory at /usr/lib/git-core/git-svn line 3669 Does anyone have an idea, what might be wrong here / how to fix it ? thx -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: Interactive rebase with pre-built script?
Andrew Wong: Instead of rebasing to "HEAD~", you should be able to do: git rebase -i HEAD Would you look at that, that actually works. So much for not testing that. Thanks, that makes it a lot easier. Instead of appending your own recipe, you could also abuse the EDITOR environment variable. Say your recipe is stored in a file called "my_recipe". Then, you could do this: env EDITOR="cp my_recipe" git rebase -i HEAD But this could potentially be dangerous because if "rebase" fires up a editor for any other reason (e.g. having a "reword" or "squash" in your recipe), then the commit message will be messed up. So you need to make sure your recipe won't trigger any editor except for the recipe. Indeed, that's why I don't want to do that. Perhaps I should add some switch that would append the contents of a specific file to the prebuild recipe, I guess that should be fairly easy. The question is what to call the switch. -- \\// Peter - http://www.softwolves.pp.se/ -- 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
[PATCHv2 0/6] rev-list/log: document logic with several limiting options
So, this turned out to be a bit longer. I decided not to implement "--debug" for "git log --grep" and such because the current code does a lot of special casing, so that the existing debug code happily outputs OR nodes in cases where the code in grep.c effectively does AND (without changing the expression nodes). So, this series sets up a few more tests to prove to myself that I'm not completely off in my understanding of the limiting options, and to make me confident enough for the documentation patch 6/6 (v2 of the old 1/1). 5/6 documents (by a test) an issue which I consider a (now) known failure: 'git log --all-match --author=me --grep=foo --grep=bar' does not AND the greps (whereas it does without --author). I don't describe this corner case in the doc patch. Michael J Gruber (6): t7810-grep: bring log --grep tests in common form t7810-grep: test multiple --grep with and without --all-match t7810-grep: test multiple --author with --all-match t7810-grep: test interaction of multiple --grep and --author options t7810-grep: test --all-match with multiple --grep and --author options rev-list/log: document logic with several limiting options Documentation/rev-list-options.txt | 15 ++- t/t7810-grep.sh| 90 -- 2 files changed, 90 insertions(+), 15 deletions(-) -- 1.7.12.463.gbd9d638 -- 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
[PATCHv2 1/6] t7810-grep: bring log --grep tests in common form
The log --grep tests generate the expected out in different ways.
Make them all use command blocks so that subshells are avoided and the
expected output is easier to grasp visually.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 35d357d..9b683ac 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -502,31 +502,41 @@ test_expect_success 'log grep setup' '
test_expect_success 'log grep (1)' '
git log --author=author --pretty=tformat:%s >actual &&
- ( echo third ; echo initial ) >expect &&
+ {
+ echo third && echo initial
+ } >expect &&
test_cmp expect actual
'
test_expect_success 'log grep (2)' '
git log --author=" * " -F --pretty=tformat:%s >actual &&
- ( echo second ) >expect &&
+ {
+ echo second
+ } >expect &&
test_cmp expect actual
'
test_expect_success 'log grep (3)' '
git log --author="^A U" --pretty=tformat:%s >actual &&
- ( echo third ; echo initial ) >expect &&
+ {
+ echo third && echo initial
+ } >expect &&
test_cmp expect actual
'
test_expect_success 'log grep (4)' '
git log --author="frotz\.com>$" --pretty=tformat:%s >actual &&
- ( echo second ) >expect &&
+ {
+ echo second
+ } >expect &&
test_cmp expect actual
'
test_expect_success 'log grep (5)' '
git log --author=Thor -F --pretty=tformat:%s >actual &&
- ( echo third ; echo initial ) >expect &&
+ {
+ echo third && echo initial
+ } >expect &&
test_cmp expect actual
'
@@ -540,7 +550,9 @@ test_expect_success 'log --grep --author implicitly uses
all-match' '
# grep matches initial and second but not third
# author matches only initial and third
git log --author="A U Thor" --grep=s --grep=l --format=%s >actual &&
- echo initial >expect &&
+ {
+ echo initial
+ } >expect &&
test_cmp expect actual
'
--
1.7.12.463.gbd9d638
--
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
[PATCHv2 3/6] t7810-grep: test multiple --author with --all-match
--all-match is ignored for author matching on purpose.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 1db3dcb..9bc63a3 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -580,6 +580,14 @@ test_expect_success 'log with multiple --author uses
union' '
test_cmp expect actual
'
+test_expect_success 'log --all-match with multiple --author still uses union' '
+ git log --all-match --author="Thor" --author="Aster" --format=%s
>actual &&
+ {
+ echo third && echo second && echo initial
+ } >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'log with --grep and multiple --author uses all-match' '
git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
{
--
1.7.12.463.gbd9d638
--
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
[PATCHv2 2/6] t7810-grep: test multiple --grep with and without --all-match
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 9b683ac..1db3dcb 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -546,6 +546,22 @@ test_expect_success 'log grep (6)' '
test_cmp expect actual
'
+test_expect_success 'log with multiple --grep uses union' '
+ git log --grep=i --grep=r --format=%s >actual &&
+ {
+ echo fourth && echo third && echo initial
+ } >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --all-match with multiple --grep uses intersection' '
+ git log --all-match --grep=i --grep=r --format=%s >actual &&
+ {
+ echo third
+ } >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'log --grep --author implicitly uses all-match' '
# grep matches initial and second but not third
# author matches only initial and third
--
1.7.12.463.gbd9d638
--
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
[PATCHv2 5/6] t7810-grep: test --all-match with multiple --grep and --author options
--all-match is ignored with multiple author options on purpose.
It is also ignored with multiple --grep options when an --author option
is present. Mark this as known failure.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 20
1 file changed, 20 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index f98f3f6..fa2845f 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -598,6 +598,16 @@ test_expect_success 'log --grep --grep --author takes
union of greps and interse
test_cmp expect actual
'
+test_expect_success 'log ---all-match -grep --author --author still takes
union of authors and intersects with grep' '
+ # grep matches only initial and third
+ # author matches all but second
+ git log --all-match --author="Thor" --author="Night" --grep=i
--format=%s >actual &&
+ {
+ echo third && echo initial
+ } >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'log --grep --author --author takes union of authors and
intersects with grep' '
# grep matches only initial and third
# author matches all but second
@@ -608,6 +618,16 @@ test_expect_success 'log --grep --author --author takes
union of authors and int
test_cmp expect actual
'
+test_expect_failure 'log --all-match --grep --grep --author takes
intersection' '
+ # grep matches only third
+ # author matches only initial and third
+ git log --all-match --author="A U Thor" --grep=i --grep=r --format=%s
>actual &&
+ {
+ echo third
+ } >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'grep with CE_VALID file' '
git update-index --assume-unchanged t/t &&
rm t/t &&
--
1.7.12.463.gbd9d638
--
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
[PATCHv2 6/6] rev-list/log: document logic with several limiting options
The current behavior is probably as useful as it is confusing. In any case it is going to stay. So, document it. This does not take into account the issue of 'log --all-match --author=me --grep=foo --grep=bar' not honoring '--all-match' because it is hopefully a corner case (and, even more hopefully, fixed some time soon). Signed-off-by: Michael J Gruber --- Documentation/rev-list-options.txt | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 5436eba..b2dbfb5 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -6,6 +6,19 @@ special notations explained in the description, additional commit limiting may be applied. Note that they are applied before commit ordering and formatting options, such as '--reverse'. +Different options are ANDed: '--author=bar --grep=foo' +limits to commits which match both conditions. + +Several occurences of the '--grep' option are ORed: '--grep=foo --grep=bar' +limits to commits matching any of these conditions. +(If '--all-match' is given, the conditions are ANDed.) + +Several occurences of the '--author' and '--committer' options are ORed +(because there can be only one each per commit). + +For all other options, only the last occurence of the same option is +taken into account: '-n 5 -3' is '-3' and '-n 3 -n 5' is '-n 5'. + -- -n 'number':: @@ -47,7 +60,7 @@ endif::git-rev-list[] --all-match:: Limit the commits output to ones that match all given --grep, - --author and --committer instead of ones that match at least one. + instead of ones that match at least one. -i:: --regexp-ignore-case:: -- 1.7.12.463.gbd9d638 -- 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
[PATCHv2 4/6] t7810-grep: test interaction of multiple --grep and --author options
There are tests for this interaction already. Restructure slightly and
avoid any claims about --all-match.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 9bc63a3..f98f3f6 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -562,16 +562,6 @@ test_expect_success 'log --all-match with multiple --grep
uses intersection' '
test_cmp expect actual
'
-test_expect_success 'log --grep --author implicitly uses all-match' '
- # grep matches initial and second but not third
- # author matches only initial and third
- git log --author="A U Thor" --grep=s --grep=l --format=%s >actual &&
- {
- echo initial
- } >expect &&
- test_cmp expect actual
-'
-
test_expect_success 'log with multiple --author uses union' '
git log --author="Thor" --author="Aster" --format=%s >actual &&
{
@@ -588,17 +578,33 @@ test_expect_success 'log --all-match with multiple
--author still uses union' '
test_cmp expect actual
'
-test_expect_success 'log with --grep and multiple --author uses all-match' '
- git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
+test_expect_success 'log --grep --author uses intersection' '
+ # grep matches only third and fourth
+ # author matches only initial and third
+ git log --author="A U Thor" --grep=r --format=%s >actual &&
{
- echo third && echo initial
+ echo third
} >expect &&
test_cmp expect actual
'
-test_expect_success 'log with --grep and multiple --author uses all-match' '
- git log --author="Thor" --author="Night" --grep=q --format=%s >actual &&
- >expect &&
+test_expect_success 'log --grep --grep --author takes union of greps and
intersects with author' '
+ # grep matches initial and second but not third
+ # author matches only initial and third
+ git log --author="A U Thor" --grep=s --grep=l --format=%s >actual &&
+ {
+ echo initial
+ } >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --grep --author --author takes union of authors and
intersects with grep' '
+ # grep matches only initial and third
+ # author matches all but second
+ git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
+ {
+ echo third && echo initial
+ } >expect &&
test_cmp expect actual
'
--
1.7.12.463.gbd9d638
--
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] Revert diffstat back to English
This reverts the i18n part of 7f81463 (Use correct grammar in diffstat
summary line - 2012-02-01) but still keeps the grammar correctness for
English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on
diffstat - 2012-08-27). The result is diffstat always in English
for all commands.
This helps stop users from accidentally sending localized
format-patch'd patches.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On Thu, Sep 13, 2012 at 8:28 PM, Jeff King wrote:
> 1. Revert diffstat to always be in English/C locale for now. For all
> commands. People too frequently end up showing the output of things
> besides format-patch. It means they will have to read the English
> when they are just running locally, but since format-patch is
> generating it, it is something that they would need to
> understand anyway.
The "for now" sounds reasonable. Minimum annoyance is always good
especially in a (largely?) volunteer-driven development environment
like git. So I revert the i18n effect. Note that I don't optimize the
changes for English only. The i18n might come back some day if we
find a good way to do it.
Git is still partly i18n-ized, turning a few strings back does not
seem a big regression.
> 2. If people on non-English projects find that too cumbersome, then we
> can switch the "English/C" above for `i18n.projectlang` or
> something. But it should not be per-command, but per-message, and
> should include all output that is not diagnostic and is not
> machine-parseable (e.g., what I mentioned above, request-pull
> output, etc). If it is the project's language, then the team
> members will need to know it anyway, so it should not be too big a
> burden to have a potentially different language there than in the
> diagnostic messages.
If you mean projectlang vs a local language, I looked into that and I
don't think we could support two non-C languages using standard
gettext interface. So it's either "C vs another", or make use of
unofficial gettext features, or roll your own.
diff.c| 10 --
t/t4006-diff-mode.sh | 8
t/t4202-log.sh| 2 +-
t/t4205-log-pretty-formats.sh | 4 ++--
t/t7508-status.sh | 2 +-
5 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/diff.c b/diff.c
index e6846ca..8c23b9c 100644
--- a/diff.c
+++ b/diff.c
@@ -1398,11 +1398,11 @@ int print_stat_summary(FILE *fp, int files, int
insertions, int deletions)
if (!files) {
assert(insertions == 0 && deletions == 0);
- return fprintf(fp, "%s\n", _(" 0 files changed"));
+ return fprintf(fp, "%s\n", " 0 files changed");
}
strbuf_addf(&sb,
- Q_(" %d file changed", " %d files changed", files),
+ files ? " %d files changed" : " %d file changed",
files);
/*
@@ -1419,8 +1419,7 @@ int print_stat_summary(FILE *fp, int files, int
insertions, int deletions)
* do not translate it.
*/
strbuf_addf(&sb,
- Q_(", %d insertion(+)", ", %d insertions(+)",
- insertions),
+ insertions ? ", %d insertions(+)" : ", %d
insertion(+)",
insertions);
}
@@ -1430,8 +1429,7 @@ int print_stat_summary(FILE *fp, int files, int
insertions, int deletions)
* do not translate it.
*/
strbuf_addf(&sb,
- Q_(", %d deletion(-)", ", %d deletions(-)",
- deletions),
+ deletions ? ", %d deletions(-)" : ", %d
deletion(-)",
deletions);
}
strbuf_addch(&sb, '\n');
diff --git a/t/t4006-diff-mode.sh b/t/t4006-diff-mode.sh
index 3d4b1ba..7a3e1f9 100755
--- a/t/t4006-diff-mode.sh
+++ b/t/t4006-diff-mode.sh
@@ -36,24 +36,24 @@ test_expect_success '--stat output after text chmod' '
test_chmod -x rezrov &&
echo " 0 files changed" >expect &&
git diff HEAD --stat >actual &&
- test_i18ncmp expect actual
+ test_cmp expect actual
'
test_expect_success '--shortstat output after text chmod' '
git diff HEAD --shortstat >actual &&
- test_i18ncmp expect actual
+ test_cmp expect actual
'
test_expect_success '--stat output after binary chmod' '
test_chmod +x binbin &&
echo " 0 files changed" >expect &&
git diff HEAD --stat >actual &&
- test_i18ncmp expect actual
+ test_cmp expect actual
'
test_expect_success '--shortstat output after binary chmod' '
git diff HEAD --shortstat >actual &&
- test_i18ncmp expect actual
+ test_cmp expect actual
'
test_done
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 924ba53..b3ac6be 100755
---
Re: [PATCH] Revert diffstat back to English
On Thu, Sep 13, 2012 at 09:16:26PM +0700, Nguyen Thai Ngoc Duy wrote: > This reverts the i18n part of 7f81463 (Use correct grammar in diffstat > summary line - 2012-02-01) but still keeps the grammar correctness for > English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on > diffstat - 2012-08-27). The result is diffstat always in English > for all commands. > > This helps stop users from accidentally sending localized > format-patch'd patches. Yeah, this is exactly what I had in mind for now. Thanks. > The "for now" sounds reasonable. Minimum annoyance is always good > especially in a (largely?) volunteer-driven development environment > like git. So I revert the i18n effect. Note that I don't optimize the > changes for English only. The i18n might come back some day if we > find a good way to do it. > > Git is still partly i18n-ized, turning a few strings back does not > seem a big regression. I wonder if it would ever be fully so. Diffs will always have "diff" in them. Git-checkout will always be called "checkout". It seems like learning a little bit of the original language is always necessary for command-line tools and machine-readable formats. > > 2. If people on non-English projects find that too cumbersome, then we > > can switch the "English/C" above for `i18n.projectlang` or > > something. But it should not be per-command, but per-message, and > > should include all output that is not diagnostic and is not > > machine-parseable (e.g., what I mentioned above, request-pull > > output, etc). If it is the project's language, then the team > > members will need to know it anyway, so it should not be too big a > > burden to have a potentially different language there than in the > > diagnostic messages. > > If you mean projectlang vs a local language, I looked into that and I > don't think we could support two non-C languages using standard > gettext interface. So it's either "C vs another", or make use of > unofficial gettext features, or roll your own. Yeah, I saw in your original message that it gets hairy. My statement was more about what we would want if there were no implementation obstacles. I'd leave it to later to decide the details. -Peff -- 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: Suggestions for "What's cooking"
"Philip Oakley" writes: >> Thinking about it, if the description paragraph was indented by one >> space then the * title would create that obvious content indent >> that (I am) would be expected. >> >> Obviously only a useful suggestion if it's easy to implement... >> >> Philip > Thinking overnight. One very simple option is to just add a double > line spacing between items to give a clearer break. I've played with both and have prepared patches to Reintegrate and cook (both in the 'todo' branch). Will play with the changes a bit more and then decide. 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: [GIT PULL] sound fixes for 3.6-rc6
Takashi Iwai writes: >> I can't reproduce here. What is your exact request-pull invocation? This question was not answerd. Did you ask request-pull to ask for a branch to be pulled, or did you ask it to ask for the tag to be pulled? If the former, I would have say it is a pebcak. Linus asked you to ask a signed tag to be pulled, and you want to have the tag to be pulled, but if you do not give "git request-pull" the tag but a branch that the tag points at, the command does not have a good reason to countermand your (apparent) wish that the branch is what is to be pulled. >> Is request-pull showing a warning like: >> >> warn: You locally have sound-3.6 but it does not (yet) >> warn: appear to be at >> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git >> warn: Do you want to push it there, perhaps? > > Hm, it looks like the check is performed only for tag objects. > In the example below, no warning appears: > % git tag mytest for-next > % git request-pull mytest~ > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git mytest > > With an annotated or a signed tag, git seems giving a warning like > above, indeed. So my test seemed wrong. Sorry for the noise. OK. -- 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
CRLF, LF ... CR ?
Hi everyone. I'm quite fond of git, and have used it for a while. Recently, I've started making printed circuit boards (PCBs) using an application called OsmondPCB (for Mac), and I'd like to use git to track changes on these. This application was originally written for the old Mac OS (Mac OS 6 to Mac OS 9.2). The old Mac OS does not use LF, nor CRLF for line endings, but only CR. I've read that git supports two different line endings; either CRLF or LF, but it does not support CR. Would it make sense to add support for CR (if so, I hereby request it as a new feature) ? The alternative is to ask the developer if he would change the file format, so that new versions of his software would change the files to end in LF, but he'd have to be careful not to break compatibility. If the software is to be changed, this would not fix similar issues that other people might have. Love Jens -- 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: [GIT PULL] sound fixes for 3.6-rc6
At Thu, 13 Sep 2012 08:14:27 -0700, Junio C Hamano wrote: > > Takashi Iwai writes: > > >> I can't reproduce here. What is your exact request-pull invocation? > > This question was not answerd. It was (a sort of), but let me clarify again. In my original pull request, I did git-request-pull for a signed tag, but I apparently overlooked the warning. Then the next test with git 1.7.12, I did it using no annotated/signed tag, so git-request-pull didn't complain it. When I do it with a signed tag, it starts warning. > Did you ask request-pull to ask for > a branch to be pulled, or did you ask it to ask for the tag to be > pulled? > > If the former, I would have say it is a pebcak. Linus asked you to > ask a signed tag to be pulled, and you want to have the tag to be > pulled, but if you do not give "git request-pull" the tag but a > branch that the tag points at, the command does not have a good > reason to countermand your (apparent) wish that the branch is what > is to be pulled. Yeah I can understand that. But the problem is that a warning is moderate so it can be so easily overlooked. It'd be user- (or subsystem-maintainer-) friendly if this automatic conversion can be suppressed. Takashi > >> Is request-pull showing a warning like: > >> > >> warn: You locally have sound-3.6 but it does not (yet) > >> warn: appear to be at > >> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > >> warn: Do you want to push it there, perhaps? > > > > Hm, it looks like the check is performed only for tag objects. > > In the example below, no warning appears: > > % git tag mytest for-next > > % git request-pull mytest~ > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git mytest > > > > With an annotated or a signed tag, git seems giving a warning like > > above, indeed. So my test seemed wrong. Sorry for the noise. > > OK. > -- 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: CRLF, LF ... CR ?
On Thu, 2012-09-13 at 17:09 +0200, Jens Bauer wrote: > Hi everyone. > > I'm quite fond of git, and have used it for a while. > Recently, I've started making printed circuit boards (PCBs) using an > application called OsmondPCB (for Mac), and I'd like to use git to track > changes on these. > This application was originally written for the old Mac OS (Mac OS 6 to Mac > OS 9.2). > The old Mac OS does not use LF, nor CRLF for line endings, but only CR. > > I've read that git supports two different line endings; either CRLF or LF, > but it does not support CR. > Would it make sense to add support for CR (if so, I hereby request it as a > new feature) ? Jens, Even if Git can't do CRLF/LF translation on a file it will still store and track the content of it it just fine. In fact you probably want translation completely disabled in this case. (Given that you seem to be working on a Mac I suspect that "disabled" is likely the default setting for that configuration item.) -- -Drew Northup "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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: CRLF, LF ... CR ?
On Thu, Sep 13, 2012 at 11:34:50AM -0400, Drew Northup wrote: > > I've read that git supports two different line endings; either CRLF or LF, > > but it does not support CR. > > Would it make sense to add support for CR (if so, I hereby request it as a > > new feature) ? > > Even if Git can't do CRLF/LF translation on a file it will still store > and track the content of it it just fine. In fact you probably want > translation completely disabled in this case. Yeah. If the files always should just have CR, then just don't ask git to do any translation (by not setting the "text" attribute, or even setting "-text" if you have something like autocrlf turned on globally), and it will preserve the bytes exactly. I suspect diffs will look nasty because we won't interpret CR as a line-ending, though. Do the files actually need line-by-line diffing and merging? If not, then you are fine. If so, then it would probably be nice to store them with a canonical LF in the repository, but convert to CR on checkout. Git can't do that internally, but you could define clean/smudge filters to do so (see the section in "git help attributes" on "Checking-out and checking-in"; specifically the "filter" subsection). -Peff -- 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: CRLF, LF ... CR ?
On Thu, Sep 13, 2012 at 5:34 PM, Drew Northup wrote: > On Thu, 2012-09-13 at 17:09 +0200, Jens Bauer wrote: >> Hi everyone. >> >> I'm quite fond of git, and have used it for a while. >> Recently, I've started making printed circuit boards (PCBs) using an >> application called OsmondPCB (for Mac), and I'd like to use git to track >> changes on these. >> This application was originally written for the old Mac OS (Mac OS 6 to Mac >> OS 9.2). >> The old Mac OS does not use LF, nor CRLF for line endings, but only CR. >> >> I've read that git supports two different line endings; either CRLF or LF, >> but it does not support CR. >> Would it make sense to add support for CR (if so, I hereby request it as a >> new feature) ? > > Jens, > Even if Git can't do CRLF/LF translation on a file it will still store > and track the content of it it just fine. In fact you probably want > translation completely disabled in this case. > > (Given that you seem to be working on a Mac I suspect that "disabled" is > likely the default setting for that configuration item.) This might be less than ideal, because diffing and merging will break. Perhaps clean/smudge filters can be used instead? That way you can have CR on disk and LF in the repo. -- 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: CRLF, LF ... CR ?
Hi Jeff and Drew. Thank you for your quick replies! :) The diffs look nasty yes; that's my main issue. It can be worked around in many ways; eg a simple (but time consuming) way: $ git diff mypcb.osm >mypcb.diff && nano mypcb.diff -It'd be better to just pipe it into a regex, which changes CR to LF on the fly. OsmondPCB is able to read files that has mixed LF and CR. (By mixed, I do not talk about CRLF) The files do not need line-by-line diffing, but I think it would make it more readable. Thank you very much for the hint on the clean/smudge filters. I'll have a look at it. =) Love Jens On Thu, 13 Sep 2012 11:43:10 -0400, Jeff King wrote: > On Thu, Sep 13, 2012 at 11:34:50AM -0400, Drew Northup wrote: > >>> I've read that git supports two different line endings; either CRLF >>> or LF, but it does not support CR. >>> Would it make sense to add support for CR (if so, I hereby request >>> it as a new feature) ? >> >> Even if Git can't do CRLF/LF translation on a file it will still store >> and track the content of it it just fine. In fact you probably want >> translation completely disabled in this case. > > Yeah. If the files always should just have CR, then just don't ask git > to do any translation (by not setting the "text" attribute, or even > setting "-text" if you have something like autocrlf turned on globally), > and it will preserve the bytes exactly. I suspect diffs will look nasty > because we won't interpret CR as a line-ending, though. > > Do the files actually need line-by-line diffing and merging? If not, > then you are fine. > > If so, then it would probably be nice to store them with a canonical LF > in the repository, but convert to CR on checkout. Git can't do that > internally, but you could define clean/smudge filters to do so (see the > section in "git help attributes" on "Checking-out and checking-in"; > specifically the "filter" subsection). > > -Peff -- 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] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
2012/9/12 Junio C Hamano : > > Interesting, but it bothers me to make it enabled unconditionally. > At least, this shouldn't be enabled under GIT_TEST_OPTS=--valgrind, no? Sorry for the late response and thanks. No, setting MALLOC_CHECK don't require valgrind and it considered a best QA to have the test suite with it defined always. If the test suite fail with MALLOC_CHECK, well, there is some problem, no ? Some distro do it already in building packages (fedora for example) http://emacs.1067599.n5.nabble.com/please-set-both-MALLOC-PERTURB-and-MALLOC-CHECK-envvars-td150144.html At @rpm5.org we do the same for popt, for example, from years http://rpm5.org/community/rpm-devel/4156.html > > By the way, "export VAR=VAL" all on the same line, even though it is > in POSIX.1, is reported to be unsupported by some shells people care > about, and needs to be corrected to "VAR=VAL" and "export VAR" as > separate commands. I think we saw a patch to fix an instance or two > that snuck in recently. Yes, right, my bad. I will reroll. Thank you -- 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
[PATCHv2] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x) include a malloc() implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_ is set to 3, a diagnostic message is printed on stderr and the program is aborted. Setting the MALLOC_PERTURB_ environment variable causes the malloc functions in libc to return memory which has been wiped and clear memory when it is returned. Of course this does not affect calloc which always does clear the memory. The reason for this exercise is, of course, to find code which uses memory returned by malloc without initializing it and code which uses code after it is freed. valgrind can do this but it's costly to run. The MALLOC_PERTURB_ exchanges the ability to detect problems in 100% of the cases with speed. The byte value used to initialize values returned by malloc is the byte value of the environment value. The value used to clear memory is the bitwise inverse. Setting MALLOC_PERTURB_ to zero disables the feature. This technique can find hard to detect bugs. It is therefore suggested to always use this flag (at least temporarily) when testing out code or a new distribution. Signed-off-by: Elia Pinto --- This the second reroll of the original patch. I redid the patch correcting the export command in a more portable way thanks to the Junio observation. t/test-lib.sh |8 1 file changed, 8 insertions(+) diff --git a/t/test-lib.sh b/t/test-lib.sh index 78c4286..6317ffc 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -93,6 +93,14 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME export EDITOR +# Add libc malloc_check and MALLOC_PERTURB test +MALLOC_CHECK_=3 +export MALLOC_CHECK_ +MALLOC_PERTURB_="$( expr \( $$ % 255 \) + 1)" +export MALLOC_PERTURB_ +# + + # Protect ourselves from common misconfiguration to export # CDPATH into the environment unset CDPATH -- 1.7.10.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: [PATCH v2] cherry-pick: don't forget -s on failure
Miklos Vajna writes:
> In case 'git cherry-pick -s ' failed, the user had to use 'git
> commit -s' (i.e. state the -s option again), which is easy to forget
> about. Instead, write the signed-off-by line early, so plain 'git
> commit' will have the same result.
>
> Also update 'git commit -s', so that in case there is already a relevant
> Signed-off-by line before the Conflicts: line, it won't add one more at
> the end of the message.
>
> Signed-off-by: Miklos Vajna
> ---
>
> On Wed, Sep 12, 2012 at 03:45:10PM -0700, Junio C Hamano
> wrote:
>> - The additional S-o-b should come immediately after the existing
>>block of footers.
>
> This was trivial to fix.
Indeed. Just inserting before starting to add "Oh, there were
conflicts, and add the info on them" before doing it at the end is
all it takes. Simple and straightforward---I like it.
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -149,6 +149,12 @@ test_commit () {
> notick=yes
> shift
> fi &&
> + signoff= &&
> + if test "z$1" = "z--signoff"
> + then
> + signoff="$1"
> + shift
> + fi &&
> file=${2:-"$1.t"} &&
> echo "${3-$1}" > "$file" &&
> git add "$file" &&
This is somewhat iffy. Shouldn't "test_commit --signoff --notick" work?
> @@ -156,7 +162,7 @@ test_commit () {
> then
> test_tick
> fi &&
> - git commit -m "$1" &&
> + git commit $signoff -m "$1" &&
> git tag "$1"
> }
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: [PATCH v2] cherry-pick: don't forget -s on failure
Miklos Vajna writes:
> +void append_signoff(struct strbuf *msgbuf, int ignore_footer)
> +{
> + struct strbuf sob = STRBUF_INIT;
> + int i;
> +
> + strbuf_addstr(&sob, sign_off_header);
> + strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
> + getenv("GIT_COMMITTER_EMAIL")));
> + strbuf_addch(&sob, '\n');
> + for (i = msgbuf->len - 1 - ignore_footer; i > 0 && msgbuf->buf[i - 1]
> != '\n'; i--)
> + ; /* do nothing */
> + if (prefixcmp(msgbuf->buf + i, sob.buf)) {
> + if (!i || !ends_rfc2822_footer(msgbuf))
> + strbuf_addch(msgbuf, '\n');
> + strbuf_addbuf(msgbuf, &sob);
> + }
> + strbuf_release(&sob);
> +}
Hrm, what is this thing trying to do? It does start scanning from
the end (ignoring the "Conflicts:" thing) to see who the last person
that signed it off was, but once it decides that it needs to add a
new sign-off, it still adds it at the very end anyway.
--
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 RFC 0/2] Mixing English and a local language
Jeff King writes: > I think I'd prefer: > > 1. Revert diffstat to always be in English/C locale for now. For all > commands. People too frequently end up showing the output of things > besides format-patch. It means they will have to read the English > when they are just running locally, but since format-patch is > generating it, it is something that they would need to > understand anyway. > > 2. If people on non-English projects find that too cumbersome, then we > can switch the "English/C" above for `i18n.projectlang` or > something. That part I sort-of understand. > But it should not be per-command, but per-message, and > should include all output that is not diagnostic and is not > machine-parseable (e.g., what I mentioned above, request-pull > output, etc). If it is the project's language, then the team > members will need to know it anyway, so it should not be too big a > burden to have a potentially different language there than in the > diagnostic messages. No matter what the project languages is, machine parseable part will not be localized but fixed to "C" anyway, so I do not think it comes into the picture. My take on this is, if there is the project language, it should apply to _everything_. Please do not introduce any per-command, per-message, per-anything mess. Just set LANG/LC_ALL up and be done with it. And I think you justified why that is the right thing to do very well in the second sentence in the above paragraph I quoted from you. -- 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] Revert diffstat back to English
Nguyễn Thái Ngọc Duy writes: > Git is still partly i18n-ized, turning a few strings back does not > seem a big regression. More than one people explicitly said that they do not want to see this in Klingon. Even if the system is fully internationalized, these "... (+), ... (-)" should never be localized, just like we will never localize "diff --git", "index f00f..abcd", etc. In other words, it is not a "regression" to begin with. Turning this back to "C" is a bugfix. We shouldn't have had marked it with _() in the first place. > If you mean projectlang vs a local language, I looked into that and I > don't think we could support two non-C languages using standard > gettext interface. So it's either "C vs another", or make use of > unofficial gettext features, or roll your own. Yeah, that is true, too. -- 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] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Elia Pinto writes: > 2012/9/12 Junio C Hamano : >> >> Interesting, but it bothers me to make it enabled unconditionally. >> At least, this shouldn't be enabled under GIT_TEST_OPTS=--valgrind, no? > Sorry for the late response and thanks. > > No, setting MALLOC_CHECK don't require > valgrind ... You never said anything like that, and I didn't question it. > and it considered a best QA to have the test suite with it > defined always. If the test suite fail with MALLOC_CHECK, well, there > is some problem, no ? I never said using MALLOC_CHECK_ is a bad idea. Let me ask the same question in a different way, as I seem to have failed in the previous message. If you are using valgrind to run tests, is it sane to also enable MALLOC_CHECK? If you were testing "cat", would it make sense to do: $ MALLOC_CHECK_=3 valgrind cat README Because we are not interested in testing how valgrind (not cat) uses malloc, we may be better off running $ valgrind cat README without MALLOC_CHECK_; it will reduce the risk of MALLOC_CHECK_ potentially disturbing what we really want to check (i.e. cat) by triggering for something whose problems we are not trying to see (i.e. valgrind), no? That was my question. -- 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 RFC 0/2] Mixing English and a local language
Junio C Hamano writes: >> But it should not be per-command, but per-message, and >> should include all output that is not diagnostic and is not >> machine-parseable (e.g., what I mentioned above, request-pull >> output, etc). If it is the project's language, then the team >> members will need to know it anyway, so it should not be too big a >> burden to have a potentially different language there than in the >> diagnostic messages. > > No matter what the project languages is, machine parseable part will > not be localized but fixed to "C" anyway, so I do not think it comes > into the picture. > > My take on this is, if there is the project language, it should > apply to _everything_. Please do not introduce any per-command, > per-message, per-anything mess. Just set LANG/LC_ALL up and be done > with it. > > And I think you justified why that is the right thing to do very > well in the second sentence in the above paragraph I quoted from > you. You seem to be saying that diagnostic does not have to be in project language, but I do not think it is the right thing to do. The first response to "Frotz does not work" is often "What do you exactly mean? How did you run Frotz? What error message are you getting from it?", and you do not want to get back the diagnostics in Klingon. -- 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 RFC 0/2] Mixing English and a local language
On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote: > > But it should not be per-command, but per-message, and > > should include all output that is not diagnostic and is not > > machine-parseable (e.g., what I mentioned above, request-pull > > output, etc). If it is the project's language, then the team > > members will need to know it anyway, so it should not be too big a > > burden to have a potentially different language there than in the > > diagnostic messages. > > No matter what the project languages is, machine parseable part will > not be localized but fixed to "C" anyway, so I do not think it comes > into the picture. But there are parts that are neither machine-parseable nor diagnostics. The diffstat is one, but I mentioned others. Are those going to be forever fixed to LANG=C? That does not bother me, but for a project whose team works entirely in Japanese (both individually, and when sharing code), they will still be stuck with these English-language snippets, and no way to localize them. Even though they may not speak a word of it. I have no idea if such a team is a strawman or not; that is why I separated points 1 and 2. We can wait on point 2 until such a team shows up and complains (of course, they would have to come here and complain in English, so...). > My take on this is, if there is the project language, it should > apply to _everything_. Please do not introduce any per-command, > per-message, per-anything mess. Just set LANG/LC_ALL up and be done > with it. But isn't that arguing for localizing diffstat? It is not machine-parseable, so an all-Japanese team would want to localize it along with their diagnostics. -Peff -- 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 RFC 0/2] Mixing English and a local language
On Thu, Sep 13, 2012 at 10:52:08AM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > >> But it should not be per-command, but per-message, and > >> should include all output that is not diagnostic and is not > >> machine-parseable (e.g., what I mentioned above, request-pull > >> output, etc). If it is the project's language, then the team > >> members will need to know it anyway, so it should not be too big a > >> burden to have a potentially different language there than in the > >> diagnostic messages. > > > > No matter what the project languages is, machine parseable part will > > not be localized but fixed to "C" anyway, so I do not think it comes > > into the picture. > > > > My take on this is, if there is the project language, it should > > apply to _everything_. Please do not introduce any per-command, > > per-message, per-anything mess. Just set LANG/LC_ALL up and be done > > with it. > > > > And I think you justified why that is the right thing to do very > > well in the second sentence in the above paragraph I quoted from > > you. > > You seem to be saying that diagnostic does not have to be in project > language, but I do not think it is the right thing to do. The first > response to "Frotz does not work" is often "What do you exactly > mean? How did you run Frotz? What error message are you getting > from it?", and you do not want to get back the diagnostics in > Klingon. By that line of reasoning, wouldn't all git developers be required to set LANG=C? Fine by me as an English speaker, but I get the impression that other developers are using the localization. I don't think there is anything wrong with primarily working in your native language, but making the effort to switch for communicating with teammates (either when writing them emails, or using LANG=C when showing them output from your terminal). If the "switch to LANG=C" thing is a relatively rare thing, I don't see a problem. The issue with the diffstat is that it is too easy to accidentally send out a localized one. -Peff -- 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: Suggestions for "What's cooking"
Andrew Ardill writes: > Currently, the output for each branch looks something like: > * () > () > [list-of-commits] > () > > > > > and these are grouped by current integration status (new, graduated, > stalled etc) Yes. Thanks for a concise summary. > A format that would make this information easier for me to parse would > be something like: > > > > > > * () > () >[list-of-commits] > () I do not see how it makes any sense to have the "This is where the section begins with, and its name is this" line in the middle of a block indented in such a way. Care to explain? I can see some people may care more about the description than the list of commits [*1*], though. [Footnote] *1* It however is an indication that the title of each commit needs to be improved to convey enough information so that I do not have to write the branch description myself for them. -- 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: CRLF, LF ... CR ?
Hi Jeff and Drew. I've been messing a little with clean/smudge filters; I think I understand them partly. Let's call the file I have on the server that have line endings, "mypcb.osm". If I clone the project, and do the following... $ cat mypcb.osm | tr '\r' '\n' I can read the file in the terminal window, otherwise it's just a "one-line-file". So far, so good. In my home directory, I have a .gitconfig file, here's the interesting part: [core] editor = nano excludesfile = /Users/jens/.gitexcludes attributesfile = /Users/jens/.gitattributes [filter "cr"] clean = tr '\\r' '\\n' smudge = tr '\\n' '\\r' In my home directory I added .gitattributes: *.osm filter=cr I've verified that .gitattributes is read; because if I add two spaces, like "*.osm filter = cr", I get an 'invalid filter name' error. I've also verified that the clean/smudge lines are read; if I only have '\n' for instance, I get an error. Now, when I clone the project, make a change and then issue this command... $ git diff mypcb.osm ...I get a strange diff. On line 3, one of the files shows a lot of control-m () lines. After that, I see lines, all prefixed with a '+', as if they were added. I think I might be nearly there, just missing some obvious detail somewhere. Any hints ? Love Jens On Thu, 13 Sep 2012 17:53:00 +0200, Jens Bauer wrote: > Hi Jeff and Drew. > > Thank you for your quick replies! :) > > The diffs look nasty yes; that's my main issue. > It can be worked around in many ways; eg a simple (but time consuming) way: > $ git diff mypcb.osm >mypcb.diff && nano mypcb.diff > > -It'd be better to just pipe it into a regex, which changes CR to LF > on the fly. > > OsmondPCB is able to read files that has mixed LF and CR. (By mixed, > I do not talk about CRLF) > > The files do not need line-by-line diffing, but I think it would make > it more readable. > Thank you very much for the hint on the clean/smudge filters. I'll > have a look at it. =) > > > Love > Jens > > On Thu, 13 Sep 2012 11:43:10 -0400, Jeff King wrote: >> On Thu, Sep 13, 2012 at 11:34:50AM -0400, Drew Northup wrote: >> I've read that git supports two different line endings; either CRLF or LF, but it does not support CR. Would it make sense to add support for CR (if so, I hereby request it as a new feature) ? >>> >>> Even if Git can't do CRLF/LF translation on a file it will still store >>> and track the content of it it just fine. In fact you probably want >>> translation completely disabled in this case. >> >> Yeah. If the files always should just have CR, then just don't ask git >> to do any translation (by not setting the "text" attribute, or even >> setting "-text" if you have something like autocrlf turned on globally), >> and it will preserve the bytes exactly. I suspect diffs will look nasty >> because we won't interpret CR as a line-ending, though. >> >> Do the files actually need line-by-line diffing and merging? If not, >> then you are fine. >> >> If so, then it would probably be nice to store them with a canonical LF >> in the repository, but convert to CR on checkout. Git can't do that >> internally, but you could define clean/smudge filters to do so (see the >> section in "git help attributes" on "Checking-out and checking-in"; >> specifically the "filter" subsection). >> >> -Peff > -- > 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 -- 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: CRLF, LF ... CR ?
On Thu, Sep 13, 2012 at 08:17:20PM +0200, Jens Bauer wrote: > In my home directory, I have a .gitconfig file, here's the interesting part: > [core] > editor = nano > excludesfile = /Users/jens/.gitexcludes > attributesfile = /Users/jens/.gitattributes > > [filter "cr"] > clean = tr '\\r' '\\n' > smudge = tr '\\n' '\\r' > > > In my home directory I added .gitattributes: > *.osm filter=cr Looks right. > Now, when I clone the project, make a change and then issue this command... > $ git diff mypcb.osm > > ...I get a strange diff. On line 3, one of the files shows a lot of control-m > () lines. > After that, I see lines, all prefixed with a '+', as if they were added. > > I think I might be nearly there, just missing some obvious detail somewhere. Yes, that's expected. The point of the "clean" filter is to convert your working tree file into a canonical (lf-only) representation inside the repository. But you've already made commits with the cr form in the repository. So you can choose one of: 1. Make a new commit with these settings, which will have the canonical format. Accept that the old history will be funny, but you will be OK from here on out. 2. Rewrite the old history to pretend that it was always LF. This gives you a nice clean history, but if you are collaborating with other people, they will need to rebase their work on the new history. See "git help filter-branch" for details. -Peff -- 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] Documentation: Use 'First Paragraph' instead of 'First Line'.
Jeremy White writes: > The discussion of email subject throughout the documentation is > misleading; it indicates that the first line will become the subject. > In fact, the first and second and third lines will become the subject, > up until the first full blank line. Describing it as the first paragraph > is more accurate. > > Signed-off-by: Jeremy White > --- > Documentation/git-commit.txt |2 +- > Documentation/git-for-each-ref.txt |2 +- > Documentation/git-format-patch.txt |8 +--- > Documentation/git-shortlog.txt |2 +- > Documentation/gitcore-tutorial.txt |2 +- > Documentation/gittutorial.txt |2 +- > Documentation/user-manual.txt |2 +- > 7 files changed, 11 insertions(+), 9 deletions(-) > > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt > index e99bb14..a61bca9 100644 > --- a/Documentation/git-commit.txt > +++ b/Documentation/git-commit.txt > @@ -349,7 +349,7 @@ DISCUSSION > Though not required, it's a good idea to begin the commit message > with a single short (less than 50 character) line summarizing the > change, followed by a blank line and then a more thorough description. > -Tools that turn commits into email, for example, use the first line > +Tools that turn commits into email, for example, use the first paragraph > on the Subject: line and the rest of the commit in the body. This is a good change, as the previous sentence says the norm for the first paragraph is a single line. > diff --git a/Documentation/git-for-each-ref.txt > b/Documentation/git-for-each-ref.txt > index 7e83288..499c26a 100644 > --- a/Documentation/git-for-each-ref.txt > +++ b/Documentation/git-for-each-ref.txt > @@ -100,7 +100,7 @@ Fields that have name-email-date tuple as its value > (`author`, > `committer`, and `tagger`) can be suffixed with `name`, `email`, > and `date` to extract the named component. > > -The first line of the message in a commit and tag object is > +The first paragraph of the message in a commit and tag object is > `subject`, the remaining lines are `body`. The whole message > is `contents`. This may need a bit more explanation. Just saying "First Paragraph" without saying that for all commits in a sane project it is the same as "First Line" will make the reader wonder "What happens to the second and subsequent lines?" (the answer is that the first paragraph is made into a single looong line). > diff --git a/Documentation/git-format-patch.txt > b/Documentation/git-format-patch.txt > index 9674f9d..e6f6d0e 100644 > --- a/Documentation/git-format-patch.txt > +++ b/Documentation/git-format-patch.txt > @@ -57,10 +57,12 @@ output, unless the `--stdout` option is specified. > If `-o` is specified, output files are created in . Otherwise > they are created in the current working directory. > > -By default, the subject of a single patch is "[PATCH] First Line" and > +By default, the subject of a single patch is "[PATCH] First Paragraph" and > the subject when multiple patches are output is "[PATCH n/m] First > +Paragraph". Note that "First Paragraph" consists of text in the commit > message > +prior to the first completely blank line (see the DISCUSSION section > +in linkgit:git-commit[1]). To force 1/1 to be added for a single patch, > +use `-n`. To omit patch numbers from the subject, use `-N`. Ditto. > diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt > index dfd4d0c..9464932 100644 > --- a/Documentation/git-shortlog.txt > +++ b/Documentation/git-shortlog.txt > @@ -15,7 +15,7 @@ DESCRIPTION > --- > Summarizes 'git log' output in a format suitable for inclusion > in release announcements. Each commit will be grouped by author and > -the first line of the commit message will be shown. > +the first paragraph of the commit message will be shown. Ditto. > diff --git a/Documentation/gitcore-tutorial.txt > b/Documentation/gitcore-tutorial.txt > index f7815e9..92f97e6 100644 > --- a/Documentation/gitcore-tutorial.txt > +++ b/Documentation/gitcore-tutorial.txt > @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch > > > The first two lines indicate that it is showing the two branches > -and the first line of the commit log message from their > +and the first paragraph of the commit log message from their > top-of-the-tree commits, you are currently on `master` branch > (notice the asterisk `\*` character), and the first column for > the later output lines is used to show commits contained in the Ditto. > diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt > index 1c16066..a1bc56c 100644 > --- a/Documentation/gittutorial.txt > +++ b/Documentation/gittutorial.txt > @@ -139,7 +139,7 @@ A note on commit messages: Though not required, it's a > good idea to > begin the commit message with a single short (less than 50 character) > line summarizing the ch
Re: Interactive rebase with pre-built script?
On 09/13/2012 09:33 AM, Peter Krefting wrote: But this could potentially be dangerous because if "rebase" fires up a editor for any other reason (e.g. having a "reword" or "squash" in your recipe), then the commit message will be messed up. So you need to make sure your recipe won't trigger any editor except for the recipe. Indeed, that's why I don't want to do that. Are you expecting to have "reword" or "squash" in your recipe? If not, I think you should be safe. If there's a conflict, then rebase will stop, and next time you run "git rebase --continue", your normal editor will be back. From your original description, it sounded like you are only doing "pick". On 09/13/2012 09:33 AM, Peter Krefting wrote: Perhaps I should add some switch that would append the contents of a specific file to the prebuild recipe, I guess that should be fairly easy. The question is what to call the switch. How about calling the switch "--todo"? i.e. "rebase -i --todo my_recipe" Can we also get some inputs from others on whether adding this switch to "rebase -i" is desirable? On 09/11/2012 11:35 AM, Junio C Hamano wrote: Using "git cherry-pick $(git rev-list --reverse .)" ought to work. And I assume what Junio suggested doesn't help with your problem? Because of the time skewed behavior? -- 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: CRLF, LF ... CR ?
Am 13.09.2012 17:53, schrieb Jens Bauer: > Hi Jeff and Drew. > > Thank you for your quick replies! :) > > The diffs look nasty yes; that's my main issue. > It can be worked around in many ways; eg a simple (but time consuming) way: > $ git diff mypcb.osm >mypcb.diff && nano mypcb.diff > > -It'd be better to just pipe it into a regex, which changes CR to LF on the > fly. > > OsmondPCB is able to read files that has mixed LF and CR. (By mixed, I do not > talk about CRLF) That is good news. Just write a 'clean' filter that amounts to tr '\015' '\012' You don't need a 'smudge' filter that reverts this conversion. -- 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
Git Perl module not installed to --prefix
Hi, I have trouble installing the Git Perl module to the correct installation prefix, which is required for git send-email. The problem is reproducible with the following commands: ./configure --prefix=/home/peter/usr/rhel6-x86_64/git-1.7.12 make make install While git is installed to --prefix, the Git Perl module is not: … make -C templates DESTDIR='' install make[2]: Entering directory `/tmp/git/git-1.7.12/templates' install -d -m 755 '/home/peter/usr/rhel6-x86_64/git-1.7.12/share/git-core/templates' (cd blt && gtar cf - .) | \ (cd '/home/peter/usr/rhel6-x86_64/git-1.7.12/share/git-core/templates' && umask 022 && gtar xof -) make[2]: Leaving directory `/tmp/git/git-1.7.12/templates' install -d -m 755 '/home/peter/usr/rhel6-x86_64/git-1.7.12/libexec/git-core/mergetools' install -m 644 mergetools/* '/home/peter/usr/rhel6-x86_64/git-1.7.12/libexec/git-core/mergetools' install -d -m 755 '/home/peter/usr/rhel6-x86_64/git-1.7.12/share/locale' (cd po/build/locale && gtar cf - .) | \ (cd '/home/peter/usr/rhel6-x86_64/git-1.7.12/share/locale' && umask 022 && gtar xof -) make -C perl prefix='/home/peter/usr/rhel6-x86_64/git-1.7.12' DESTDIR='' install make[2]: Entering directory `/tmp/git/git-1.7.12/perl' make[3]: Entering directory `/tmp/git/git-1.7.12/perl' Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/I18N.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/IndexInfo.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/Log.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/Fetcher.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/Ra.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/Prompt.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/Migration.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/Utils.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/Editor.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/GlobSpec.pm Installing /home/peter/usr/rhel6-x86_64/share/perl5/Git/SVN/Memoize/YAML.pm Installing /home/peter/usr/rhel6-x86_64/share/man/man3/Git::SVN::Prompt.3pm Installing /home/peter/usr/rhel6-x86_64/share/man/man3/Git::SVN::Fetcher.3pm Installing /home/peter/usr/rhel6-x86_64/share/man/man3/Git::SVN::Editor.3pm Installing /home/peter/usr/rhel6-x86_64/share/man/man3/Git::I18N.3pm Installing /home/peter/usr/rhel6-x86_64/share/man/man3/Git::SVN::Memoize::YAML.3pm Installing /home/peter/usr/rhel6-x86_64/share/man/man3/Git::SVN::Ra.3pm Installing /home/peter/usr/rhel6-x86_64/share/man/man3/Git.3pm Installing /home/peter/usr/rhel6-x86_64/share/man/man3/Git::SVN::Utils.3pm Appending installation info to /home/peter/usr/rhel6-x86_64/lib64/perl5/perllocal.pod make[3]: Leaving directory `/tmp/git/git-1.7.12/perl' make[2]: Leaving directory `/tmp/git/git-1.7.12/perl' … As seen above, the perl module is installed to the parent directory. Strangely, if perl/Makefile is invoked manually, it works: make -C perl prefix='/home/peter/usr/rhel6-x86_64/git-1.7.12' DESTDIR='' install make: Entering directory `/tmp/git/git-1.7.12/perl' make[1]: Entering directory `/tmp/git/git-1.7.12/perl' Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/I18N.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/IndexInfo.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/Log.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/Fetcher.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/Ra.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/Prompt.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/Migration.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/Utils.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/Editor.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/GlobSpec.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/perl5/Git/SVN/Memoize/YAML.pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/man/man3/Git::SVN::Prompt.3pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/man/man3/Git::SVN::Fetcher.3pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/man/man3/Git::SVN::Editor.3pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/man/man3/Git::I18N.3pm Installing /home/peter/usr/rhel6-x86_64/git-1.7.12/share/
is this behaviour expected for "git clone --single-branch"?
Hi, I know people which have a separate directory for every branch. In this case it doesn't make sense to download the whole repo with all branches. So I guess the "--single-branch" option is the solution in that case!?! But I'm wondering about it's behaviour. # first clone the branch of the repo $git clone --single-branch --branch master myrepo ./master $cd master # now calling "git branch -a" to see what I have $git branch -a *master remotes/origin/HEAD -> origin/master remotes/origin/master # fine, now pulling from origin $git pull >From myrepo * [new branch] foo -> origin/foo * [new branch] bar -> origin/bar ... Hm? # looking again to my branches $git branch -a *master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/bar remotes/origin/foo ... After cloning (or fetching), I now have all branches which is not what I want, because I'm only interested in the one I've cloned. I think it's not very useful for the use-case of having one directory for one branch. $git version git version 1.7.12.395.g6b149ce 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: [PATCH] Revert diffstat back to English
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> Git is still partly i18n-ized, turning a few strings back does not
>> seem a big regression.
>
> More than one people explicitly said that they do not want to see
> this in Klingon. Even if the system is fully internationalized,
> these "... (+), ... (-)" should never be localized, just like we
> will never localize "diff --git", "index f00f..abcd", etc.
Nah, I was being silly. People complaining on Klingon on _this_
list does not argue for this to be in "C"; it just means the
i18n.projectlang for this project is "C".
How about _not_ reverting it and doing something like this instead?
I suspect that we may need to delay the call to git_setup_gettext()
in a similar way that we delay the call to commit_pager_choice(),
but that is a minor detail people smarter than I can surely figure
out ;-)
git.c | 10 ++
1 file changed, 10 insertions(+)
diff --git i/git.c w/git.c
index 8788b32..a2cb9c8 100644
--- i/git.c
+++ w/git.c
@@ -51,6 +51,15 @@ int check_pager_config(const char *cmd)
return c.want;
}
+static int project_lang_config(const char *var, const char *value, void
*cb_data)
+{
+ if (!strcmp(var, "i18n.projectlang")) {
+ setenv("LANG", val, 1);
+ setenv("LC_ALL", val, 1);
+ }
+ return 0;
+}
+
static void commit_pager_choice(void) {
switch (use_pager) {
case 0:
@@ -538,6 +547,7 @@ int main(int argc, const char **argv)
if (!cmd)
cmd = "git-help";
+ git_config(project_lang_config, NULL);
git_setup_gettext();
/*
--
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: Git Perl module not installed to --prefix
On Thu, Sep 13, 2012 at 02:30:19PM -0400, Peter Colberg wrote: > I have trouble installing the Git Perl module to the correct > installation prefix, which is required for git send-email. > > The problem is reproducible with the following commands: > > ./configure --prefix=/home/peter/usr/rhel6-x86_64/git-1.7.12 > make > make install > > While git is installed to --prefix, the Git Perl module is not: Sorry, I have figured out the reason: The above commands are in fact invoked from an installation makefile, which uses PREFIX as the package installation prefix. Apparently this PREFIX variable was inherited by make install, but only for the perl module. make -f packages.mk PREFIX=/home/peter/usr/rhel6-x86_64 CONCURRENCY_LEVEL=16 install-git If I run configure/make/make install manually, it works fine. Please excuse the false report. Peter -- 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: is this behaviour expected for "git clone --single-branch"?
Ralf Thielow writes: > # looking again to my branches Don't look at your branches, but look at how the refspecs are configured by "git clone" in .git/config; I suspect we just write the default 'refs/heads/*:refs/remotes/origin/*' pattern. -- 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] Documentation: Use 'First Paragraph' instead of 'First Line'.
From: "Jeremy White" Sent: Thursday, September 13, 2012 1:42 PM The discussion of email subject throughout the documentation is misleading; it indicates that the first line will become the subject. In fact, the first and second and third lines will become the subject, up until the first full blank line. Describing it as the first paragraph This "up until the first full blank line" part should also be in the documentation itself to clarify how a 'paragraph' is delineated. I've shown one place it could go below. is more accurate. Signed-off-by: Jeremy White --- Documentation/git-commit.txt |2 +- Documentation/git-for-each-ref.txt |2 +- Documentation/git-format-patch.txt |8 +--- Documentation/git-shortlog.txt |2 +- Documentation/gitcore-tutorial.txt |2 +- Documentation/gittutorial.txt |2 +- Documentation/user-manual.txt |2 +- 7 files changed, 11 insertions(+), 9 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index e99bb14..a61bca9 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -349,7 +349,7 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line +Tools that turn commits into email, for example, use the first paragraph on the Subject: line "up until the first full blank line" and the rest of the commit in the body. include::i18n.txt[] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 7e83288..499c26a 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -100,7 +100,7 @@ Fields that have name-email-date tuple as its value (`author`, `committer`, and `tagger`) can be suffixed with `name`, `email`, and `date` to extract the named component. -The first line of the message in a commit and tag object is +The first paragraph of the message in a commit and tag object is `subject`, the remaining lines are `body`. The whole message is `contents`. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 9674f9d..e6f6d0e 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -57,10 +57,12 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in . Otherwise they are created in the current working directory. -By default, the subject of a single patch is "[PATCH] First Line" and +By default, the subject of a single patch is "[PATCH] First Paragraph" and the subject when multiple patches are output is "[PATCH n/m] First -Line". To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +Paragraph". Note that "First Paragraph" consists of text in the commit message +prior to the first completely blank line (see the DISCUSSION section +in linkgit:git-commit[1]). To force 1/1 to be added for a single patch, +use `-n`. To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index dfd4d0c..9464932 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -15,7 +15,7 @@ DESCRIPTION --- Summarizes 'git log' output in a format suitable for inclusion in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +the first paragraph of the commit message will be shown. Additionally, "[PATCH]" will be stripped from the commit description. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index f7815e9..92f97e6 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their +and the first paragraph of the commit log message from their top-of-the-tree commits, you are currently on `master` branch (notice the asterisk `\*` character), and the first column for the later output lines is used to show commits contained in the diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 1c16066..a1bc56c 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -139,7 +139,7 @@ A note on commit messages: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) lin
Re: is this behaviour expected for "git clone --single-branch"?
On Thu, Sep 13, 2012 at 8:45 PM, Junio C Hamano wrote: > Ralf Thielow writes: > >> # looking again to my branches > > Don't look at your branches, but look at how the refspecs are > configured by "git clone" in .git/config; I suspect we just write > the default 'refs/heads/*:refs/remotes/origin/*' pattern. Indeed. $ cat .git/config [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* -- 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: CRLF, LF ... CR ?
Hi Jeff and Drew. Excellent. I now removed the repository from the server, removed it from my gitolite.conf, added it to gitolite.conf, re-initialized and it works. git diff shows what I wanted. Thank you *very* much for making my dream come true. :) -And thank you all for all the hard work you're doing. -Git is how all other open-source projects should be: Well-written and well-defined (oh - and fast!). :) Love Jens On Thu, 13 Sep 2012 14:23:44 -0400, Jeff King wrote: > On Thu, Sep 13, 2012 at 08:17:20PM +0200, Jens Bauer wrote: > >> In my home directory, I have a .gitconfig file, here's the >> interesting part: >> [core] >> editor = nano >> excludesfile = /Users/jens/.gitexcludes >> attributesfile = /Users/jens/.gitattributes >> >> [filter "cr"] >> clean = tr '\\r' '\\n' >> smudge = tr '\\n' '\\r' >> >> >> In my home directory I added .gitattributes: >> *.osm filter=cr > > Looks right. > >> Now, when I clone the project, make a change and then issue this command... >> $ git diff mypcb.osm >> >> ...I get a strange diff. On line 3, one of the files shows a lot of >> control-m () lines. >> After that, I see lines, all prefixed with a '+', as if they >> were added. >> >> I think I might be nearly there, just missing some obvious detail >> somewhere. > > Yes, that's expected. The point of the "clean" filter is to convert > your working tree file into a canonical (lf-only) representation inside > the repository. But you've already made commits with the cr form in the > repository. So you can choose one of: > > 1. Make a new commit with these settings, which will have the > canonical format. Accept that the old history will be funny, but > you will be OK from here on out. > > 2. Rewrite the old history to pretend that it was always LF. This > gives you a nice clean history, but if you are collaborating with > other people, they will need to rebase their work on the new > history. See "git help filter-branch" for details. > > -Peff -- 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: CRLF, LF ... CR ?
Hi Johannes. I've changed... tr '\\r' '\\n' ...to... tr '\\15' '\\12' ...As you are right in that it is more correct. (Then in theory, it would be portable). [I once came across tftpd, tried compiling it on a Mac, but it failed to work, because \r and \n were swapped on the compiler, so I asked the author to use \15 and \12, which made it fully portable] It now works even better. I can't and won't complain - thank you. =) Love Jens On Thu, 13 Sep 2012 20:34:08 +0200, Johannes Sixt wrote: > Am 13.09.2012 17:53, schrieb Jens Bauer: >> Hi Jeff and Drew. >> >> Thank you for your quick replies! :) >> >> The diffs look nasty yes; that's my main issue. >> It can be worked around in many ways; eg a simple (but time consuming) way: >> $ git diff mypcb.osm >mypcb.diff && nano mypcb.diff >> >> -It'd be better to just pipe it into a regex, which changes CR to LF >> on the fly. >> >> OsmondPCB is able to read files that has mixed LF and CR. (By mixed, >> I do not talk about CRLF) > > That is good news. Just write a 'clean' filter that amounts to > >tr '\015' '\012' > > You don't need a 'smudge' filter that reverts this conversion. > > -- 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: {bug} warning: unable to access 'RelNotes/.gitattributes'
Jeff King writes: > On Wed, Sep 12, 2012 at 11:32:22PM -0700, Junio C Hamano wrote: > >> "git repack" started giving the above warning, and I am guessing >> that the recent 11e50b2 (attr: warn on inaccessible attribute files, >> 2012-08-21) exposed a bug where we ask stat(2) not lstat(2) by >> mistake before deciding to append .gitattributes to see if that >> directory has a per-directory attributes file. > > Interesting. I don't get any such warning on repack. And RelNotes points > to a file, so I'm not sure why stat() would make us think it was a dir. Interesting. The command in question is git-pack-objects --keep-true-parents --honor-pack-keep --non-empty \ --all --reflog --delta-base-offset http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/6] rev-list/log: document logic with several limiting options
Michael J Gruber writes: > So, this turned out to be a bit longer. > I decided not to implement "--debug" for "git log --grep" and such > because the current code does a lot of special casing, so that the > existing debug code happily outputs OR nodes in cases where the code > in grep.c effectively does AND (without changing the expression nodes). Is that something we (not necessarily you) would want to fix? How many are they? The reason I am asking is because I do not think of any. The entire document is considered unmatched unless all of the OR nodes in the top-level backbone have triggered for some line in the document when "all-match" is in effect, but that is quite different from turning OR nodes into AND nodes (they both are about "does this line match the pattern?"), so... -- 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 v3] cherry-pick: don't forget -s on failure
In case 'git cherry-pick -s ' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Also update 'git commit -s', so that in case there is already a relevant
Signed-off-by line before the Conflicts: line, it won't add one more at
the end of the message. If there is no such line, then add it before the
the Conflicts: line.
Signed-off-by: Miklos Vajna
---
> This is somewhat iffy. Shouldn't "test_commit --signoff --notick"
> work?
Indeed, fixed now.
> Hrm, what is this thing trying to do? It does start scanning from
> the end (ignoring the "Conflicts:" thing) to see who the last person
> that signed it off was, but once it decides that it needs to add a
> new sign-off, it still adds it at the very end anyway.
Ah, I did not handle that, as the original git commit -s didn't do it
either -- and originally I just wanted to touch git cherry-pick.
Implemented now.
builtin/commit.c| 79 +++---
sequencer.c | 72 +++
sequencer.h |4 ++
t/t3507-cherry-pick-conflict.sh | 32
t/t3510-cherry-pick-sequence.sh |6 +-
t/test-lib-functions.sh | 20 +++--
6 files changed, 149 insertions(+), 64 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 778cf16..4d50484 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -28,6 +28,7 @@
#include "submodule.h"
#include "gpg-interface.h"
#include "column.h"
+#include "sequencer.h"
static const char * const builtin_commit_usage[] = {
N_("git commit [options] [--] ..."),
@@ -466,8 +467,6 @@ static int is_a_merge(const struct commit *current_head)
return !!(current_head->parents && current_head->parents->next);
}
-static const char sign_off_header[] = "Signed-off-by: ";
-
static void export_one(const char *var, const char *s, const char *e, int hack)
{
struct strbuf buf = STRBUF_INIT;
@@ -552,47 +551,6 @@ static void determine_author_info(struct strbuf
*author_ident)
}
}
-static int ends_rfc2822_footer(struct strbuf *sb)
-{
- int ch;
- int hit = 0;
- int i, j, k;
- int len = sb->len;
- int first = 1;
- const char *buf = sb->buf;
-
- for (i = len - 1; i > 0; i--) {
- if (hit && buf[i] == '\n')
- break;
- hit = (buf[i] == '\n');
- }
-
- while (i < len - 1 && buf[i] == '\n')
- i++;
-
- for (; i < len; i = k) {
- for (k = i; k < len && buf[k] != '\n'; k++)
- ; /* do nothing */
- k++;
-
- if ((buf[k] == ' ' || buf[k] == '\t') && !first)
- continue;
-
- first = 0;
-
- for (j = 0; i + j < len; j++) {
- ch = buf[i + j];
- if (ch == ':')
- break;
- if (isalnum(ch) ||
- (ch == '-'))
- continue;
- return 0;
- }
- }
- return 1;
-}
-
static char *cut_ident_timestamp_part(char *string)
{
char *ket = strrchr(string, '>');
@@ -717,21 +675,30 @@ static int prepare_to_commit(const char *index_file,
const char *prefix,
stripspace(&sb, 0);
if (signoff) {
- struct strbuf sob = STRBUF_INIT;
- int i;
+ /*
+* See if we have a Conflicts: block at the end. If yes, count
+* its size, so we can ignore it.
+*/
+ int ignore_footer = 0;
+ int i, eol, previous = 0;
+ const char *nl;
- strbuf_addstr(&sob, sign_off_header);
- strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
-getenv("GIT_COMMITTER_EMAIL")));
- strbuf_addch(&sob, '\n');
- for (i = sb.len - 1; i > 0 && sb.buf[i - 1] != '\n'; i--)
- ; /* do nothing */
- if (prefixcmp(sb.buf + i, sob.buf)) {
- if (!i || !ends_rfc2822_footer(&sb))
- strbuf_addch(&sb, '\n');
- strbuf_addbuf(&sb, &sob);
+ for (i = 0; i < sb.len; i++) {
+ nl = memchr(sb.buf + i, '\n', sb.len - i);
+ if (nl)
+ eol = nl - sb.buf;
+ else
+ eol = sb.len;
+ if (!prefixcmp(sb.buf + previous, "\nConflicts:\n")) {
+ ignore_footer = sb.len - previous;
+ break;
+ }
+
Re: [PATCHv2 3/6] t7810-grep: test multiple --author with --all-match
Michael J Gruber writes:
> --all-match is ignored for author matching on purpose.
>
> Signed-off-by: Michael J Gruber
> ---
What the added test expects is correct, but I do not think the above
description is correct. "all-match" is implicitly turned on when
you use header match.
When you say
git log --grep=Linus --grep=Junio
you will get
(or
pattern_bodyJunio
pattern_bodyLinus
)
but when you say
git log --author=Linus --author=Junio
you will get
[all-match]
(or
(or
pattern_headLinus
pattern_headJunio
)
true
)
instead. Notice that there is one extra level of "OR" node, so that
two OR nodes on the top-level backbone (think of these as cons cells
with car and cdr) are "author is either Linus or junio" and "True".
Because "all-match" is about rejecting a document as non-matching
unless all the OR nodes on the top-level backbone have fired, this
allows commit that is authored either by Linus or by Junio to match,
and "on purpose" part in your message is correct.
But
git log --author=Linus --author=Junio --grep=commit
will be parsed to
[all-match]
(or
pattern_bodycommit
(or
(or
pattern_headLinus
pattern_headJunio
)
true
)
)
to have three OR nodes on the backbone: "the log message must have commit",
"authored by either Linus or Junio", and "true". All three must
match somewhere in the "git cat-file commit" output for the commit
to be considered a match (but obviously they do not have to match on
the same line).
So what is giving commits made by Linus, even though it is not
authored by Junio, with "--author=Linus --author=Junio" is not the
lack of --all-match. In fact, --all-match is implicitly set for
other things, so that the last example finds commits that mention
"commit" authored by one of these two people. Commits that do
mention "commit" but are done by other people are excluded. Commits
that do not mention "commit" are excluded even if they were done by
Linus or Junio.
git log --committer=Linus --author=Junio
turns into
[all-match]
(or
pattern_headLinus
(or
pattern_headJunio
true
)
)
which has "committed by Linus", "authored by Junio" on the top-level
backbone, so both has to be true for a commit to match.
Adding --grep=commit makes it
[all-match]
(or
pattern_bodycommit
(or
pattern_headLinus
(or
pattern_headJunio
true
)
)
)
which has "committed by Linus", "authored by Junio", "mentions
commit" on the top-level, and all three has to be true.
git log --committer=Linus --author=Junio --grep=commit --grep=tag
groups the "mentions commit" and "mentions tag" under a new
top-level OR node, i.e.
[all-match]
(or
(or
pattern_bodycommit
pattern_bodytag
)
(or
pattern_headLinus
(or
pattern_headJunio
true
)
)
)
so the top-level backbone "all-match" works on becomes
- Mentions either commit or tag,
- Committed by Linus,
- Authored by Junio
One possible improvement we can make is to parse the command line in
the last example with "--all-match" to
[all-match]
(or
pattern_bodycommit
(or
pattern_bodytag
(or
pattern_headLinus
(or
pattern_headJunio
true
)
)
)
)
so that the backbone becomes
- Mentions commit,
- Mentions tag,
- Committed by Linus,
- Authored by Junio
to require that both commit and tag are mentioned in the message.
> t/t7810-grep.sh | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
> index 1db3dcb..9bc63a3 100755
> --- a/t/t7810-grep.sh
> +++ b/t/t7810-grep.sh
> @@ -580,6 +580,14 @@ test_expect_success 'log with multiple --author uses
> union' '
> test_cmp expect actual
> '
>
> +test_expect_success 'log --all-match with multiple --author still uses
> union' '
> + git log --all-match --author="Thor" --author="Aster" --format=%s
> >actual &&
> + {
> + echo third && echo second && echo initial
> + } >expect &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'log with --grep and multiple --author uses all-match' '
> git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
> {
--
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] Documentation: Use 'First Paragraph' instead of 'First Line'.
Thanks for the feedback; new patch inbound. Minor nits: >> diff --git a/Documentation/gitcore-tutorial.txt >> b/Documentation/gitcore-tutorial.txt >> index f7815e9..92f97e6 100644 >> --- a/Documentation/gitcore-tutorial.txt >> +++ b/Documentation/gitcore-tutorial.txt >> @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch >> >> >> The first two lines indicate that it is showing the two branches >> -and the first line of the commit log message from their >> +and the first paragraph of the commit log message from their >> top-of-the-tree commits, you are currently on `master` branch >> (notice the asterisk `\*` character), and the first column for >> the later output lines is used to show commits contained in the > > Ditto. I did not substantially alter this. The emphasis of this section is on the broader show-branch output, and belaboring the subject would be distracting and unnecessary imho. Cheers, Jeremy -- 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] Revert diffstat back to English
On Thu, Sep 13, 2012 at 11:40:12AM -0700, Junio C Hamano wrote:
> > More than one people explicitly said that they do not want to see
> > this in Klingon. Even if the system is fully internationalized,
> > these "... (+), ... (-)" should never be localized, just like we
> > will never localize "diff --git", "index f00f..abcd", etc.
>
> Nah, I was being silly. People complaining on Klingon on _this_
> list does not argue for this to be in "C"; it just means the
> i18n.projectlang for this project is "C".
Right, I think that is the case.
> How about _not_ reverting it and doing something like this instead?
> [...]
> +static int project_lang_config(const char *var, const char *value, void
> *cb_data)
> +{
> + if (!strcmp(var, "i18n.projectlang")) {
> + setenv("LANG", val, 1);
> + setenv("LC_ALL", val, 1);
> + }
> + return 0;
> +}
Doesn't that mean that anyone working on git.git will never get to see
their localized language, even when it is not likely to be communicated
to the rest of the project? I am OK with that as a native speaker, but I
wonder what others would have to say.
I suspect we will end up with people not setting i18n.projectlang, and
getting Klingon diffstats on the list.
-Peff
--
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] Revert diffstat back to English
Jeff King writes: > I suspect we will end up with people not setting i18n.projectlang, and > getting Klingon diffstats on the list. Yes, but when our starting point is that the diffstat summary is not meant for machine consumption, which I tend to agree, that is a logical consequence no matter how you cut it, no? After all, they want to be careless when running format-patch meant for _this_ project whose project language is C locale, but still want to be able to see output that is not meant for machine consumption in their native language, and these are incompatible goals. Giving them a mechanism so that they do not have to remember setting LANG/LC_ALL every time they context switch into this project would be the best we can do, I am afraid. Unless somebody has a better design that does not involve three languages (always C, project language and Klingon), that is. -- 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 v3] cherry-pick: don't forget -s on failure
Miklos Vajna writes:
> +void append_signoff(struct strbuf *msgbuf, int ignore_footer)
> +{
> + struct strbuf sob = STRBUF_INIT;
> + int i;
> +
> + strbuf_addstr(&sob, sign_off_header);
> + strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
> + getenv("GIT_COMMITTER_EMAIL")));
> + strbuf_addch(&sob, '\n');
> + for (i = msgbuf->len - 1 - ignore_footer; i > 0 && msgbuf->buf[i - 1]
> != '\n'; i--)
> + ; /* do nothing */
> + struct strbuf footer = STRBUF_INIT;
> + if (ignore_footer > 0) {
> + strbuf_addstr(&footer, msgbuf->buf + msgbuf->len -
> ignore_footer);
> + strbuf_setlen(msgbuf, msgbuf->len - ignore_footer);
> + }
That's decl-after-stmt.
I would have expected that you can just do strbuf_splice() to add
the &sob into &msgbuf with the original code structure, without a
substantial rewrite of the function like this. Perhaps I am missing
something?
--
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 v2] Documentation: describe subject more precisely
The discussion of email subject throughout the documentation is misleading; it indicates that the first line will always become the subject. In fact, the subject is generally all lines up until the first full blank line. Signed-off-by: Jeremy White --- Documentation/git-commit.txt |2 +- Documentation/git-for-each-ref.txt |7 --- Documentation/git-format-patch.txt | 11 +++ Documentation/git-shortlog.txt |2 +- Documentation/gitcore-tutorial.txt |2 +- Documentation/gittutorial.txt |2 +- Documentation/user-manual.txt |2 +- 7 files changed, 16 insertions(+), 12 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 4622297..6b9ba20 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -389,7 +389,7 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line +Tools that turn commits into email, for example, use the first paragraph on the Subject: line and the rest of the commit in the body. include::i18n.txt[] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index c872b88..db55a4e 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -102,9 +102,10 @@ Fields that have name-email-date tuple as its value (`author`, and `date` to extract the named component. The complete message in a commit and tag object is `contents`. -Its first line is `contents:subject`, the remaining lines -are `contents:body` and the optional GPG signature -is `contents:signature`. +Its first line is `contents:subject`, where subject is the concatenation +of all lines of the commit message up to the first blank line. The next +line is 'contents:body', where body is all of the lines after the first +blank line. Finally, the optional GPG signature is `contents:signature`. For sorting purposes, fields with numeric values sort in numeric order (`objectsize`, `authordate`, `committerdate`, `taggerdate`). diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 04c7346..6d43f56 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -58,10 +58,13 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in . Otherwise they are created in the current working directory. -By default, the subject of a single patch is "[PATCH] First Line" and -the subject when multiple patches are output is "[PATCH n/m] First -Line". To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +By default, the subject of a single patch is "[PATCH] " followed by +the concatenation of lines from the commit message up to the first blank +line (see the DISCUSSION section of linkgit:git-commit[1]). + +When multiple patches are output, the subject prefix will instead be +"[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`. +To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 01d8417..6ec30e3 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -15,7 +15,7 @@ DESCRIPTION --- Summarizes 'git log' output in a format suitable for inclusion in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +all text from the commit message up to the first blank line will be shown. Additionally, "[PATCH]" will be stripped from the commit description. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 9d89336..b5b3534 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their +and the first part of the commit log message from their top-of-the-tree commits, you are currently on `master` branch (notice the asterisk `*` character), and the first column for the later output lines is used to show commits contained in the diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index dee0505..76aba59 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -140,7 +140,7 @@ A note on commit messages: Though not required, it's a good idea to begin the commit message with a single
Re: {bug} warning: unable to access 'RelNotes/.gitattributes'
On Thu, Sep 13, 2012 at 12:40:39PM -0700, Junio C Hamano wrote:
> > Interesting. I don't get any such warning on repack. And RelNotes points
> > to a file, so I'm not sure why stat() would make us think it was a dir.
>
> Interesting. The command in question is
>
> git-pack-objects --keep-true-parents --honor-pack-keep --non-empty \
> --all --reflog --delta-base-offset - "rev-list --object --all" does not produce "Relnotes/1.7.4.txt"
>(it does have "Documentation/RelNotes/1.7.4.txt", of course).
>Somebody in this callchain is screwing the name up.
Yeah, that sounds like a pretty huge bug. But since I can't reproduce,
you're on your own for tracking it down.
> - Even if the name were correct, we are looking at the path that
>existed in the past. The value of checking the attributes file
>in the working tree for "delta" attribute is dubious.
I don't think it's dubious. Imagine you had a bunch of binary files and
you did:
$ echo "*.bin -delta" >.gitattributes
$ git repack -ad
You would expect it to affect all of the .bin files through history, no?
The real issue is that we should be much more lenient, because we have
no clue if the filename has any basis in the working tree.
While it's cool that the ENOTDIR warning has possibly found another bug,
I think in the long run we would want to ignore ENOTDIR along with
ENOENT to handle this situation (and I think it would be safe to do it
all the time, and not worry about this "special" case).
> - This is done while traversing the commit list and enumerating
>objects, so even if we have many incarnations of the same path in
>different commits, the attr stack mechanism would only help
>objects in the same directory in the same commit. Perhaps we
>could do this after collecting all the blobs, check attributes
>for each path only once (in a sorted order so that we can take
>advantage of the attr stack), to reduce the cost of "delta"
>attribute check.
That is a totally separate issue, but it might be a nice optimization.
A good start would be just running "prof" and seeing how much time we
spend on the attr stack now (I suspect it is really not much compared to
the actual packing, but maybe on systems with horribly slow stat() it
would be worse).
> In any case, because the directory that used to exist to house the
> blob in it may no longer exist, giving the warning on ENOTDIR that
> your 11e50b2 (attr: warn on inaccessible attribute files,
> 2012-08-21) is a wrong thing to do (assuming that checking the
> current attribute setting for historical tree is a sensible thing to
> do, that is).
I think that this:
> diff --git i/attr.c w/attr.c
> index f12c83f..056d702 100644
> --- i/attr.c
> +++ w/attr.c
> @@ -353,7 +353,7 @@ static struct attr_stack *read_attr_from_file(const char
> *path, int macro_ok)
> int lineno = 0;
>
> if (!fp) {
> - if (errno != ENOENT)
> + if (errno != ENOENT && errno != ENOTDIR)
> warn_on_inaccessible(path);
> return NULL;
> }
is the right thing to do. It's cool that it uncovered a bug in this
case, but it is easy to construct a non-bug case that would exhibit the
same bogus warning (just convert a directory into a file).
-Peff
--
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] Documentation: Use 'First Paragraph' instead of 'First Line'.
Jeremy White writes: > Thanks for the feedback; new patch inbound. Minor nits: > >>> diff --git a/Documentation/gitcore-tutorial.txt >>> b/Documentation/gitcore-tutorial.txt >>> index f7815e9..92f97e6 100644 >>> --- a/Documentation/gitcore-tutorial.txt >>> +++ b/Documentation/gitcore-tutorial.txt >>> @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch >>> >>> >>> The first two lines indicate that it is showing the two branches >>> -and the first line of the commit log message from their >>> +and the first paragraph of the commit log message from their >>> top-of-the-tree commits, you are currently on `master` branch >>> (notice the asterisk `\*` character), and the first column for >>> the later output lines is used to show commits contained in the >> >> Ditto. > > I did not substantially alter this. The emphasis of this section > is on the broader show-branch output, and belaboring the subject would > be distracting and unnecessary imho. Yeah, but if that is the focus of this part of the documentation, wouldn't a patch to update "the first line" with something more generic like "title of the commit" be more appropriate? -- 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] Documentation: Use 'First Paragraph' instead of 'First Line'.
>> I did not substantially alter this. The emphasis of this section >> is on the broader show-branch output, and belaboring the subject would >> be distracting and unnecessary imho. > > Yeah, but if that is the focus of this part of the documentation, > wouldn't a patch to update "the first line" with something more > generic like "title of the commit" be more appropriate? See my patch; I went with 'first part'. That, I think, does not mislead (the goal of my change), but also does not distract from the main point of the section (detailing the various bits of git show-branch). Cheers, Jeremy -- 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] Revert diffstat back to English
On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I suspect we will end up with people not setting i18n.projectlang, and > > getting Klingon diffstats on the list. > > Yes, but when our starting point is that the diffstat summary is not > meant for machine consumption, which I tend to agree, that is a > logical consequence no matter how you cut it, no? After all, they > want to be careless when running format-patch meant for _this_ > project whose project language is C locale, but still want to be > able to see output that is not meant for machine consumption in > their native language, and these are incompatible goals. I do not think they are incompatible if you separate it into three categories: machine readable (must never be translated), for the current user right now (current i18n), and for sharing with other humans (i18n.projectlang). Whether the maintenance of that three-way split is worthwhile, I don't know (and that is why I said "in an ideal world..." in my original mail, and left the implementation for people who care more). In the meantime, before we have a working i18n.projectlang solution, which slot should we put those messages in? I'd argue for putting them in the machine-readable category, because it is less likely to cause interoperability annoyances (and since git is not fully translated anyway, we kind of assume at this point that people know some basic phrases in the C locale). And of course it is not fool-proof. The "for the current user right now" messages may bleed into conversation with other people. But that cannot be helped if we are to do any localization at all, and it does not seem to be a big problem in practice. The only practical problem so far is with certain meant-to-be-shared messages. -Peff -- 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] rev-list/log: document logic with several limiting options
Michael J Gruber writes:
> Thanks for "this" ;)
Here is a replacement to "this", that adds the "--debug" option to
"git grep" and an equivalent "--debug-grep" to "git log" family.
-- >8 --
Subject: [PATCH] grep: teach --debug option to dump the parse tree
Our "grep" allows complex boolean expressions to be formed to match
each individual line with operators like --and, '(', ')' and --not.
Introduce the "--debug" option to show the parse tree to help people
who want to debug and enhance it.
Also "log" learns "--debug-grep" option to do the same. The command
line parser to the log family is a lot more limited than the general
"git grep" parser, but it has special handling for header matching
(e.g. "--author"), and a parse tree is valuable when working on it.
Note that "--all-match" is *not* any individual node in the parse
tree. It is an instruction to the evaluator to check all the nodes
in the top-level backbone have matched and reject a document as
non-matching otherwise.
Signed-off-by: Junio C Hamano
---
builtin/grep.c | 3 ++
grep.c | 93 --
grep.h | 1 +
revision.c | 2 ++
4 files changed, 97 insertions(+), 2 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 09ca4c9..1c6b95a 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -817,6 +817,9 @@ int cmd_grep(int argc, const char **argv, const char
*prefix)
N_("indicate hit with exit status without output")),
OPT_BOOLEAN(0, "all-match", &opt.all_match,
N_("show only matches from files that match all
patterns")),
+ { OPTION_SET_INT, 0, "debug", &opt.debug, NULL,
+ N_("show parse tree for grep expression"),
+ PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 1 },
OPT_GROUP(""),
{ OPTION_STRING, 'O', "open-files-in-pager", &show_in_pager,
N_("pager"), N_("show matching files in the pager"),
diff --git a/grep.c b/grep.c
index 04e3ec6..f896d68 100644
--- a/grep.c
+++ b/grep.c
@@ -332,6 +332,87 @@ static struct grep_expr *compile_pattern_expr(struct
grep_pat **list)
return compile_pattern_or(list);
}
+static void indent(int in)
+{
+ while (in-- > 0)
+ fputc(' ', stderr);
+}
+
+static void dump_grep_pat(struct grep_pat *p)
+{
+ switch (p->token) {
+ case GREP_AND: fprintf(stderr, "*and*"); break;
+ case GREP_OPEN_PAREN: fprintf(stderr, "*(*"); break;
+ case GREP_CLOSE_PAREN: fprintf(stderr, "*)*"); break;
+ case GREP_NOT: fprintf(stderr, "*not*"); break;
+ case GREP_OR: fprintf(stderr, "*or*"); break;
+
+ case GREP_PATTERN: fprintf(stderr, "pattern"); break;
+ case GREP_PATTERN_HEAD: fprintf(stderr, "pattern_head"); break;
+ case GREP_PATTERN_BODY: fprintf(stderr, "pattern_body"); break;
+ }
+
+ switch (p->token) {
+ default: break;
+ case GREP_PATTERN_HEAD:
+ fprintf(stderr, "", p->field); break;
+ case GREP_PATTERN_BODY:
+ fprintf(stderr, ""); break;
+ }
+ switch (p->token) {
+ default: break;
+ case GREP_PATTERN_HEAD:
+ case GREP_PATTERN_BODY:
+ case GREP_PATTERN:
+ fprintf(stderr, "%.*s", (int)p->patternlen, p->pattern);
+ break;
+ }
+ fputc('\n', stderr);
+}
+
+static void dump_grep_expression_1(struct grep_expr *x, int in)
+{
+ indent(in);
+ switch (x->node) {
+ case GREP_NODE_TRUE:
+ fprintf(stderr, "true\n");
+ break;
+ case GREP_NODE_ATOM:
+ dump_grep_pat(x->u.atom);
+ break;
+ case GREP_NODE_NOT:
+ fprintf(stderr, "(not\n");
+ dump_grep_expression_1(x->u.unary, in+1);
+ indent(in);
+ fprintf(stderr, ")\n");
+ break;
+ case GREP_NODE_AND:
+ fprintf(stderr, "(and\n");
+ dump_grep_expression_1(x->u.binary.left, in+1);
+ dump_grep_expression_1(x->u.binary.right, in+1);
+ indent(in);
+ fprintf(stderr, ")\n");
+ break;
+ case GREP_NODE_OR:
+ fprintf(stderr, "(or\n");
+ dump_grep_expression_1(x->u.binary.left, in+1);
+ dump_grep_expression_1(x->u.binary.right, in+1);
+ indent(in);
+ fprintf(stderr, ")\n");
+ break;
+ }
+}
+
+void dump_grep_expression(struct grep_opt *opt)
+{
+ struct grep_expr *x = opt->pattern_expression;
+
+ if (opt->all_match)
+ fprintf(stderr, "[all-match]\n");
+ dump_grep_expression_1(x, 0);
+ fflush(NULL);
+}
+
static struct grep_expr *grep_true_expr(void)
{
struct grep_expr *z = xcalloc(1, sizeof(*z));
@@ -395,7 +476,7 @@ static struct grep_expr *prep_header_patterns(struct
Re: [PATCH] Revert diffstat back to English
Jeff King writes: > I do not think they are incompatible if you separate it into three > categories: machine readable (must never be translated), for the current > user right now (current i18n), and for sharing with other humans > (i18n.projectlang). Anything you see as a user is potentially useful to other project participants, so I do not think there is a bright line that delineates the latter two classes. The output of format-patch is obviously meant as the latter, but how about the output from show or log? Is it worth trying to define the bright line somewhere, only to annoy users who may want to draw the line differently? > Whether the maintenance of that three-way split is worthwhile, I don't > know (and that is why I said "in an ideal world..." in my original > mail, and left the implementation for people who care more). In the > meantime, before we have a working i18n.projectlang solution, which slot > should we put those messages in? > > I'd argue for putting them in the machine-readable category, because it > is less likely to cause interoperability annoyances (and since git is > not fully translated anyway, we kind of assume at this point that people > know some basic phrases in the C locale). > > And of course it is not fool-proof. The "for the current user right now" > messages may bleed into conversation with other people. But that cannot > be helped if we are to do any localization at all, and it does not seem > to be a big problem in practice. The only practical problem so far is > with certain meant-to-be-shared messages. > > -Peff -- 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] Documentation: Use 'First Paragraph' instead of 'First Line'.
Jeremy White writes: >>> I did not substantially alter this. The emphasis of this section >>> is on the broader show-branch output, and belaboring the subject would >>> be distracting and unnecessary imho. >> >> Yeah, but if that is the focus of this part of the documentation, >> wouldn't a patch to update "the first line" with something more >> generic like "title of the commit" be more appropriate? > > See my patch; I went with 'first part'. That, I think, does not > mislead (the goal of my change), but also does not distract from > the main point of the section (detailing the various bits of > git show-branch). For that kind of casual wording, we have used "title" on this list for quite a long time, I think. So I'd rather see a change that just says "title" (if we are making such a change to the documentation, that is). This is not a very strong preference, though. -- 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] Revert diffstat back to English
On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I do not think they are incompatible if you separate it into three > > categories: machine readable (must never be translated), for the current > > user right now (current i18n), and for sharing with other humans > > (i18n.projectlang). > > Anything you see as a user is potentially useful to other project > participants, so I do not think there is a bright line that > delineates the latter two classes. The output of format-patch is > obviously meant as the latter, but how about the output from show or > log? Is it worth trying to define the bright line somewhere, only > to annoy users who may want to draw the line differently? I agree that the line is not bright. I do not know if it is worthwhile or not. I think it will solve some practical problems, but it may also introduce others. But basically having a per-repo LANG setting (which is what the projectlang you are talking about would do) also does not seem like a solution that people will use, because they will not get any localization benefit at all. So again, I'd rather err on the side of pushing those things that are near the line into the "do not translate" side, letting people use LANG to localize the rest, and accepting that occasionally people are going to accidentally show you output in a language you don't understand. But hopefully that keeps it to "occasionally" and not "every time you send out a patch". -Peff -- 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 v2] Documentation: describe subject more precisely
Jeremy White writes: > The discussion of email subject throughout the documentation is > misleading; it indicates that the first line will always become > the subject. In fact, the subject is generally all lines up until > the first full blank line. > > Signed-off-by: Jeremy White > --- > Documentation/git-commit.txt |2 +- > Documentation/git-for-each-ref.txt |7 --- > Documentation/git-format-patch.txt | 11 +++ > Documentation/git-shortlog.txt |2 +- > Documentation/gitcore-tutorial.txt |2 +- > Documentation/gittutorial.txt |2 +- > Documentation/user-manual.txt |2 +- > 7 files changed, 16 insertions(+), 12 deletions(-) > > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt > index 4622297..6b9ba20 100644 > --- a/Documentation/git-commit.txt > +++ b/Documentation/git-commit.txt > @@ -389,7 +389,7 @@ DISCUSSION > Though not required, it's a good idea to begin the commit message > with a single short (less than 50 character) line summarizing the > change, followed by a blank line and then a more thorough description. > -Tools that turn commits into email, for example, use the first line > +Tools that turn commits into email, for example, use the first paragraph > on the Subject: line and the rest of the commit in the body. Good, but as somebody else pointed out and you did in the patch for for-each-ref, the definition of "paragraph" may want to be clarified here. > include::i18n.txt[] > diff --git a/Documentation/git-for-each-ref.txt > b/Documentation/git-for-each-ref.txt > index c872b88..db55a4e 100644 > --- a/Documentation/git-for-each-ref.txt > +++ b/Documentation/git-for-each-ref.txt > @@ -102,9 +102,10 @@ Fields that have name-email-date tuple as its value > (`author`, > and `date` to extract the named component. > > The complete message in a commit and tag object is `contents`. > -Its first line is `contents:subject`, the remaining lines > -are `contents:body` and the optional GPG signature > -is `contents:signature`. > +Its first line is `contents:subject`, where subject is the concatenation > +of all lines of the commit message up to the first blank line. The next > +line is 'contents:body', where body is all of the lines after the first > +blank line. Finally, the optional GPG signature is `contents:signature`. Very good. > diff --git a/Documentation/git-format-patch.txt > b/Documentation/git-format-patch.txt > index 04c7346..6d43f56 100644 > --- a/Documentation/git-format-patch.txt > +++ b/Documentation/git-format-patch.txt > @@ -58,10 +58,13 @@ output, unless the `--stdout` option is specified. > If `-o` is specified, output files are created in . Otherwise > they are created in the current working directory. > > -By default, the subject of a single patch is "[PATCH] First Line" and > -the subject when multiple patches are output is "[PATCH n/m] First > -Line". To force 1/1 to be added for a single patch, use `-n`. To omit > -patch numbers from the subject, use `-N`. > +By default, the subject of a single patch is "[PATCH] " followed by > +the concatenation of lines from the commit message up to the first blank > +line (see the DISCUSSION section of linkgit:git-commit[1]). > + > +When multiple patches are output, the subject prefix will instead be > +"[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`. > +To omit patch numbers from the subject, use `-N`. Good. > diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt > index 01d8417..6ec30e3 100644 > --- a/Documentation/git-shortlog.txt > +++ b/Documentation/git-shortlog.txt > @@ -15,7 +15,7 @@ DESCRIPTION > --- > Summarizes 'git log' output in a format suitable for inclusion > in release announcements. Each commit will be grouped by author and > -the first line of the commit message will be shown. > +all text from the commit message up to the first blank line will be shown. OK, but I think "title" would be better for casual discussion like this. > diff --git a/Documentation/gitcore-tutorial.txt > b/Documentation/gitcore-tutorial.txt > index 9d89336..b5b3534 100644 > --- a/Documentation/gitcore-tutorial.txt > +++ b/Documentation/gitcore-tutorial.txt > @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch > > > The first two lines indicate that it is showing the two branches > -and the first line of the commit log message from their > +and the first part of the commit log message from their > top-of-the-tree commits, you are currently on `master` branch > (notice the asterisk `*` character), and the first column for > the later output lines is used to show commits contained in the Likewise. > diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt > index dee0505..76aba59 100644 > --- a/Documentation/gittutorial.txt > +++ b/Documentation/gittutorial.txt > @@ -140,7 +140,7 @@ A note on
Re: [PATCH] Revert diffstat back to English
Jeff King writes: > On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > I do not think they are incompatible if you separate it into three >> > categories: machine readable (must never be translated), for the current >> > user right now (current i18n), and for sharing with other humans >> > (i18n.projectlang). >> >> Anything you see as a user is potentially useful to other project >> participants, so I do not think there is a bright line that >> delineates the latter two classes. The output of format-patch is >> obviously meant as the latter, but how about the output from show or >> log? Is it worth trying to define the bright line somewhere, only >> to annoy users who may want to draw the line differently? > > I agree that the line is not bright. I do not know if it is worthwhile > or not. I think it will solve some practical problems, but it may also > introduce others. But basically having a per-repo LANG setting (which > is what the projectlang you are talking about would do) also does not > seem like a solution that people will use, because they will not get any > localization benefit at all. > > So again, I'd rather err on the side of pushing those things that are > near the line into the "do not translate" side, letting people use LANG > to localize the rest, and accepting that occasionally people are going > to accidentally show you output in a language you don't understand. But > hopefully that keeps it to "occasionally" and not "every time you send > out a patch". I am confused asto what you really want. In a Klingon-only project, I think it is perfectly fine to localize the diffstat summary line to Klingon. It is not machine readble, and it is not personal, but it is to be shared with project members, who all speak Klingon. Pushing more things to "do not translate" side of the line means robbing the benefit of i18n from people, no? -- 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] Documentation: Use 'First Paragraph' instead of 'First Line'.
> For that kind of casual wording, we have used "title" on this list > for quite a long time, I think. So I'd rather see a change that > just says "title" (if we are making such a change to the > documentation, that is). This is not a very strong preference, > though. Ah, I was unaware of the use of title, and I rather like it. v3 inbound making more use of title, and hopefully addressing your other points as well. Cheers, Jeremy -- 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 v3] Documentation: describe subject more precisely
The discussion of email subject throughout the documentation is misleading; it indicates that the first line will always become the subject. In fact, the subject is generally all lines up until the first full blank line. This patch refines that, and makes more use of the concept of a commit title, with the title being all text up to the first blank line. Signed-off-by: Jeremy White --- Documentation/git-commit.txt |6 -- Documentation/git-for-each-ref.txt |7 --- Documentation/git-format-patch.txt | 11 +++ Documentation/git-shortlog.txt |3 +-- Documentation/gitcore-tutorial.txt |9 - Documentation/gittutorial.txt |8 +--- Documentation/user-manual.txt |9 ++--- 7 files changed, 31 insertions(+), 22 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 4622297..9594ac8 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -389,8 +389,10 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line -on the Subject: line and the rest of the commit in the body. +The text up to the first blank line in a commit message is treated +as the commit title, and that title is used throughout git. +For example, linkgit:git-format-patch[1] turns a commit into email, and it uses +the title on the Subject line and the rest of the commit in the body. include::i18n.txt[] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index c872b88..db55a4e 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -102,9 +102,10 @@ Fields that have name-email-date tuple as its value (`author`, and `date` to extract the named component. The complete message in a commit and tag object is `contents`. -Its first line is `contents:subject`, the remaining lines -are `contents:body` and the optional GPG signature -is `contents:signature`. +Its first line is `contents:subject`, where subject is the concatenation +of all lines of the commit message up to the first blank line. The next +line is 'contents:body', where body is all of the lines after the first +blank line. Finally, the optional GPG signature is `contents:signature`. For sorting purposes, fields with numeric values sort in numeric order (`objectsize`, `authordate`, `committerdate`, `taggerdate`). diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 04c7346..6d43f56 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -58,10 +58,13 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in . Otherwise they are created in the current working directory. -By default, the subject of a single patch is "[PATCH] First Line" and -the subject when multiple patches are output is "[PATCH n/m] First -Line". To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +By default, the subject of a single patch is "[PATCH] " followed by +the concatenation of lines from the commit message up to the first blank +line (see the DISCUSSION section of linkgit:git-commit[1]). + +When multiple patches are output, the subject prefix will instead be +"[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`. +To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 01d8417..afeb4cd 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -14,8 +14,7 @@ git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w] DESCRIPTION --- Summarizes 'git log' output in a format suitable for inclusion -in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +in release announcements. Each commit will be grouped by author and title. Additionally, "[PATCH]" will be stripped from the commit description. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 9d89336..5325c5a 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -956,12 +956,11 @@ $ git show-branch --topo-order --more=1 master mybranch The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their -top-of-the-tree commits, you are currently on `master` branch -(notice the asterisk `*` character), and the fir
Re: [PATCHv2 6/6] rev-list/log: document logic with several limiting options
Michael J Gruber writes: > The current behavior is probably as useful as it is confusing. In any > case it is going to stay. So, document it. > > This does not take into account the issue of 'log --all-match > --author=me --grep=foo --grep=bar' not honoring '--all-match' because it > is hopefully a corner case (and, even more hopefully, fixed some time > soon). > > Signed-off-by: Michael J Gruber > --- > Documentation/rev-list-options.txt | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/Documentation/rev-list-options.txt > b/Documentation/rev-list-options.txt > index 5436eba..b2dbfb5 100644 > --- a/Documentation/rev-list-options.txt > +++ b/Documentation/rev-list-options.txt > @@ -6,6 +6,19 @@ special notations explained in the description, additional > commit > limiting may be applied. Note that they are applied before commit > ordering and formatting options, such as '--reverse'. > > +Different options are ANDed: '--author=bar --grep=foo' > +limits to commits which match both conditions. > + > +Several occurences of the '--grep' option are ORed: '--grep=foo --grep=bar' > +limits to commits matching any of these conditions. > +(If '--all-match' is given, the conditions are ANDed.) > + > +Several occurences of the '--author' and '--committer' options are ORed > +(because there can be only one each per commit). As I would really want to eventually see the revision command option parser understand the full power of grep expressions in the future, I would really want to avoid a misleading explanation that calls what "--all-match" does as "ANDed". With such a change, we could say something like git log --grep=commit --and --grep=count to require the log message to have both "commit" and "count" on the same line (in any order). This obviously is different from git log --grep="commit.*count" but more importantly, it is vastly different from git log --all-match --grep=commit --grep=count that requires some line that has "commit", and some line (which may not be the same line) that has "count", in the log message. -- 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: [PATCHv2 3/6] t7810-grep: test multiple --author with --all-match
Junio C Hamano writes:
> One possible improvement we can make is to parse the command line in
> the last example with "--all-match" to
>
> [all-match]
> (or
> pattern_bodycommit
> (or
> pattern_bodytag
> (or
>pattern_headLinus
>(or
> pattern_headJunio
> true
>)
> )
> )
> )
>
> so that the backbone becomes
>
> - Mentions commit,
> - Mentions tag,
> - Committed by Linus,
> - Authored by Junio
>
> to require that both commit and tag are mentioned in the message.
And this is an attempt to do exactly that. Earlier, when we have
both header expression (which by the way has to be an OR node by
construction) and pattern expression (which could be anything), we
created a top-level OR node (again, look at this as if you are
reading LISP),
OR
/\
/ \
patternOR
/ \ / \
.committerOR
/ \
author TRUE
in other words, the three elements on the top-level backbone are
"pattern", "committer" and "author"; when there are more than one
elements in the "pattern", the top-level node of it is OR, so that
node is inspected by "all-match", hence the result ends up ignoring
the "--all-match" given from the command line.
This patch turns it into
OR
/ \
/ \
/ OR
committer/\
author\
pattern
when "--all-match" was given from the command line, so that the
"committer", "author" and elements on the top-level backbone in
"pattern" form the top-level backbone of the resulting expression to
be inspected by the "all-match" logic.
Does this pass the expect-failure test in your [PATCH 5/6]?
grep.c | 19 +++
1 file changed, 19 insertions(+)
diff --git c/grep.c w/grep.c
index be15c47..925aa92 100644
--- c/grep.c
+++ w/grep.c
@@ -476,6 +476,22 @@ static struct grep_expr *prep_header_patterns(struct
grep_opt *opt)
return header_expr;
}
+static struct grep_expr *grep_splice_or(struct grep_expr *x, struct grep_expr
*y)
+{
+ struct grep_expr *z = x;
+
+ while (x) {
+ assert(x->node == GREP_NODE_OR);
+ if (x->u.binary.right &&
+ x->u.binary.right->node == GREP_NODE_TRUE) {
+ x->u.binary.right = y;
+ break;
+ }
+ x = x->u.binary.right;
+ }
+ return z;
+}
+
static void compile_grep_patterns_real(struct grep_opt *opt)
{
struct grep_pat *p;
@@ -510,6 +526,9 @@ static void compile_grep_patterns_real(struct grep_opt *opt)
if (!opt->pattern_expression)
opt->pattern_expression = header_expr;
+ else if (opt->all_match)
+ opt->pattern_expression = grep_splice_or(header_expr,
+
opt->pattern_expression);
else
opt->pattern_expression = grep_or_expr(opt->pattern_expression,
header_expr);
--
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] Revert diffstat back to English
On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote: > > I agree that the line is not bright. I do not know if it is worthwhile > > or not. I think it will solve some practical problems, but it may also > > introduce others. But basically having a per-repo LANG setting (which > > is what the projectlang you are talking about would do) also does not > > seem like a solution that people will use, because they will not get any > > localization benefit at all. > > > > So again, I'd rather err on the side of pushing those things that are > > near the line into the "do not translate" side, letting people use LANG > > to localize the rest, and accepting that occasionally people are going > > to accidentally show you output in a language you don't understand. But > > hopefully that keeps it to "occasionally" and not "every time you send > > out a patch". > > I am confused asto what you really want. In a Klingon-only project, > I think it is perfectly fine to localize the diffstat summary line > to Klingon. It is not machine readble, and it is not personal, but > it is to be shared with project members, who all speak Klingon. > > Pushing more things to "do not translate" side of the line means > robbing the benefit of i18n from people, no? Yes. But you cannot please both sides without creating a third category, as you noted. If you do not translate diffstat, then Klingon-only projects are unhappy. If you do translate, then projects run in LANG=C will either get public Klingon, or the project members will turn off all translation and lose all benefit of i18n. So for the time being, I would rather choose LANG=C as a lingua franca and err on the side of interoperability with other people and not translating. And then if and when somebody feels like putting the effort into doing i18n.projectlang by splitting out a third category, they are welcome to. I just do not see much point in doing i18n.projectlang any other way. But again, please don't take my input with too much force. I am personally perfectly happy to live in LANG=C the rest of my life. I really started on this topic just by responding to your "I guess nobody minds the Klingon..." statement. I do find it a little annoying, but I can learn to live with it if that is significantly easier. -Peff -- 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: [PATCHv2 6/6] rev-list/log: document logic with several limiting options
Junio C Hamano writes: >> diff --git a/Documentation/rev-list-options.txt >> b/Documentation/rev-list-options.txt >> index 5436eba..b2dbfb5 100644 >> --- a/Documentation/rev-list-options.txt >> +++ b/Documentation/rev-list-options.txt >> @@ -6,6 +6,19 @@ special notations explained in the description, additional >> commit >> limiting may be applied. Note that they are applied before commit >> ordering and formatting options, such as '--reverse'. >> >> +Different options are ANDed: '--author=bar --grep=foo' >> +limits to commits which match both conditions. >> + >> +Several occurences of the '--grep' option are ORed: '--grep=foo --grep=bar' >> +limits to commits matching any of these conditions. >> +(If '--all-match' is given, the conditions are ANDed.) >> + >> +Several occurences of the '--author' and '--committer' options are ORed >> +(because there can be only one each per commit). > > As I would really want to eventually see the revision command option > parser understand the full power of grep expressions in the future, > I would really want to avoid a misleading explanation that calls > what "--all-match" does as "ANDed". Assuming that the patch I posted earlier actually works, I think the description can become vastly simpler, if you stop explaining author and committer in terms of "grep". It is implementation detail that the same grep machinery is handling these two header fields and the end users do not have to even be aware of. You can use "--grep=foo" to limit the output to commits that mention "foo" in their messages. If you use more than one of them, e.g. "--grep=foo" and "--grep=bar", by default, the command shows commits that mention "foo" or "bar" (or naturally, both) in their messages. If you want to limit the output to commits that mention both "foo" and "bar" in their messages (note that they do not have to appear on the same line), you can use "--all-match". You can use "--author=Linus" to limit the output to commits authored by Linus. If you use more than one of them, e.g. "--author=Linus" and "--author=Junio", the command shows commits that are authored by either Linus or Junio. As a commit cannot be authored by more than one person, there is no option to choose commits that are authored by Linus and Junio (and there is no need for such an option). To limit the output with the committer information, use "--committer=" instead of "--author=". -- 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: {bug} warning: unable to access 'RelNotes/.gitattributes'
Jeff King writes:
> On Thu, Sep 13, 2012 at 12:40:39PM -0700, Junio C Hamano wrote:
>
>> > Interesting. I don't get any such warning on repack. And RelNotes points
>> > to a file, so I'm not sure why stat() would make us think it was a dir.
>>
>> Interesting. The command in question is
>>
>> git-pack-objects --keep-true-parents --honor-pack-keep --non-empty \
>> --all --reflog --delta-base-offset
> Weird. I don't see any problems with that command, either (I tried it
> with the current 'next'). Thinking that maybe delta reuse was getting in
> the way, I also tried it with --no-reuse-delta.
>
>> - "rev-list --object --all" does not produce "Relnotes/1.7.4.txt"
>>(it does have "Documentation/RelNotes/1.7.4.txt", of course).
>>Somebody in this callchain is screwing the name up.
>
> Yeah, that sounds like a pretty huge bug. But since I can't reproduce,
> you're on your own for tracking it down.
I have a remote tracking branch refs/remotes/repo/html that has the
path RelNotes/1.7.4.txt at the top ;-) Depending on how traversal
goes, if the tree that represents that RelNotes directory in the html
tree is found before the tree that represents Documentation/RelNotes
directory in the main history at the corresponding commit, it is
perfectly normal that we discover the blob as RelNotes/1.7.4.txt, so
there is no bug.
So among the three points I raised, the first one was a false issue,
the second one is real (we do look for attributes in the working
tree for historical commit, or for a commit that does not belong to
the same lineage as the one that is currently checked out, hence we
must ignore ENOTDIR), and the third one is unrelated.
> I think that this:
>
>> diff --git i/attr.c w/attr.c
>> index f12c83f..056d702 100644
>> --- i/attr.c
>> +++ w/attr.c
>> @@ -353,7 +353,7 @@ static struct attr_stack *read_attr_from_file(const char
>> *path, int macro_ok)
>> int lineno = 0;
>>
>> if (!fp) {
>> -if (errno != ENOENT)
>> +if (errno != ENOENT && errno != ENOTDIR)
>> warn_on_inaccessible(path);
>> return NULL;
>> }
>
> is the right thing to do. It's cool that it uncovered a bug in this
> case, but it is easy to construct a non-bug case that would exhibit the
> same bogus warning (just convert a directory into a file).
Yes.
--
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: [PATCHv2 6/6] rev-list/log: document logic with several limiting options
Junio C Hamano writes: > Assuming that the patch I posted earlier actually works, I think the > description can become vastly simpler, if you stop explaining author > and committer in terms of "grep". And here is a replacement in a patch form. -- >8 -- Subject: [PATCH] log: document use of multiple commit limiting options Generally speaking, using more options will further narrow the selection, but there are a few exceptions. Document them. Signed-off-by: Junio C Hamano --- Documentation/rev-list-options.txt | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 1ae3c89..57d6c90 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -3,7 +3,14 @@ Commit Limiting Besides specifying a range of commits that should be listed using the special notations explained in the description, additional commit -limiting may be applied. Note that they are applied before commit +limiting may be applied. + +Using more options generally further limits the output (e.g. +"--since=" limits to commits newer than , and using it +with "--grep=" further limits to commits whose log message +has a line that match ), unless otherwise noted. + +Note that these are applied before commit ordering and formatting options, such as '--reverse'. -- @@ -38,16 +45,22 @@ endif::git-rev-list[] --committer=:: Limit the commits output to ones with author/committer - header lines that match the specified pattern (regular expression). + header lines that match the specified pattern (regular + expression). With more than one `--author=`, + commits whose author match any of the given patterns are + chosen (similarly for multiple `--committer=`). --grep=:: Limit the commits output to ones with log message that - matches the specified pattern (regular expression). + matches the specified pattern (regular expression). With + more than one `--grep=`, commits whose message + match any of the given patterns are chosen (but see + `--all-match`). --all-match:: Limit the commits output to ones that match all given --grep, - --author and --committer instead of ones that match at least one. + instead of ones that match at least one. -i:: --regexp-ignore-case:: -- 1.7.12.469.g5235eb6 -- 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: Suggestions for "What's cooking"
On 14 September 2012 04:06, Junio C Hamano wrote: > Andrew Ardill writes: > >> Currently, the output for each branch looks something like: >> * () >> () >> [list-of-commits] >> () >> >> >> >> >> and these are grouped by current integration status (new, graduated, >> stalled etc) > > Yes. Thanks for a concise summary. > >> A format that would make this information easier for me to parse would >> be something like: >> >> >> >> >> >> * () >> () >>[list-of-commits] >> () > > I do not see how it makes any sense to have the "This is where the > section begins with, and its name is this" line in the middle of a > block indented in such a way. Care to explain? I'm not quite sure what aspect you are referring to, so let me just expand my reasoning a little bit and hopefully that clears things up. First of all, I didn't spend that much time thinking through the layout, merely re-arranged things so that what I considered most important was at the start of each listing. I kept everything else the same, with an extra level of indentation for everything except the first line of each listing. Perhaps modifying the existing indentation to better fit in this layout is in order, but that is in some ways orthogonal to the ideas I was trying to present. I am not against changing how each listing is laid out in a more disruptive way, this was just a first attempt at making it easier to parse. I like the idea proposed by others to increase whitespace between listings to make each stand out, however I think indentation is a better method. * Increased whitespace between listings lengthens the entire list, requiring more scrolling and decreasing the amount of information on each page. Simply indenting most lines by a few columns of whitespace may cause some lines to wrap, but in general will not lengthen the listing or decrease information density. [edit] I realised after writing this that the addition of a does actually increase the length of the listing, however it does not decrease information density as much as a blank line. * The visual difference between two blank lines and one is significant, but not as distinct as the presence (or not) of a character in the first column of text. In scanning a long document, I propose that finding a line that starts in the first column of text is easier than finding the next line which is preceded by two blank lines. Similarly jumping forwards or backwards a listing would be easier. This is all a little academic though, so lets compare both versions with an excerpt from the most recent "What's cooking"! First, the extra blank line -- >8 -- * jc/maint-blame-no-such-path (2012-09-10) 1 commit - blame $path: avoid getting fooled by case insensitive filesystems "git blame MAKEFILE" run in a history that has "Makefile" but not "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got confused on a case insensitive filesystem. * sl/autoconf (2012-09-11) 2 commits - build: don't duplicate substitution of make variables - build: improve GIT_CONF_SUBST signature * cn/branch-set-upstream-to (2012-09-11) 2 commits - completion: complete branch name for "branch --set-upstream-to=" - completion: add --set-upstream-to and --unset-upstream Will merge to 'next'. -- [Graduated to "master"] * jc/maint-ident-missing-human-name (2012-08-31) 1 commit (merged to 'next' on 2012-09-07 at 0e99b20) + split_ident_line(): make best effort when parsing author/committer line "git show --format='%ci'" did not give timestamp correctly for commits created without human readable name on "committer" line. * jc/merge-bases (2012-08-31) 9 commits (merged to 'next' on 2012-09-07 at ab0974d) + reduce_heads(): reimplement on top of remove_redundant() + merge-base: "--is-ancestor A B" + get_merge_bases_many(): walk from many tips in parallel + in_merge_bases(): use paint_down_to_common() + merge_bases_many(): split out the logic to paint history + in_merge_bases(): omit unnecessary redundant common ancestor reduction + http-push: use in_merge_bases() for fast-forward check + receive-pack: use in_merge_bases() for fast-forward check + in_merge_bases(): support only one "other" commit Optimise the "merge-base" computation a bit, and also update its users that do not need the full merge-base information to call a cheaper subset. -- 8< -- Now, the extra indentation and re-organised contents -- >8 -- jc/maint-blame-no-such-path "git blame MAKEFILE" run in a history that has "Makefile" but not "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got confused on a case insensitive filesystem. * jc/maint-blame-no-such-path (2012-09-10) 1 commit - blame $path: avoid getting fooled by case insensitive filesystems sl/autoconf * sl/autoconf (2012-09-11) 2 commits - build: don't duplicate substitution of make variables - build: improve GIT_CONF_SUBST signature cn/branch-set-upstream-
Re: Suggestions for "What's cooking"
Andrew Ardill writes: > On 14 September 2012 04:06, Junio C Hamano wrote: >> Andrew Ardill writes: >> >>> >>> >>> >>> >>> * () >>> () >>>[list-of-commits] >>> () >> >> I do not see how it makes any sense to have the "This is where the >> section begins with, and its name is this" line in the middle of a >> block indented in such a way. Care to explain? > > I'm not quite sure what aspect you are referring to,... Just this part, as I do not have much time. Here is your reordered one I will reject: A > jc/maint-blame-no-such-path > "git blame MAKEFILE" run in a history that has "Makefile" but not > "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got > confused on a case insensitive filesystem. > B > * jc/maint-blame-no-such-path (2012-09-10) 1 commit >- blame $path: avoid getting fooled by case insensitive filesystems I was noting that B which *is* formatted as a header line (it EVEN has a leading asterisk to make it clear that it begins something new) is in the middle, and you added a redundant A that is not even marked clearly as a header line. -- 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: Suggestions for "What's cooking"
On 14 September 2012 12:29, Junio C Hamano wrote: > Andrew Ardill writes: > >> On 14 September 2012 04:06, Junio C Hamano wrote: >>> Andrew Ardill writes: >>> * () () [list-of-commits] () >>> >>> I do not see how it makes any sense to have the "This is where the >>> section begins with, and its name is this" line in the middle of a >>> block indented in such a way. Care to explain? >> >> I'm not quite sure what aspect you are referring to,... > > Just this part, as I do not have much time. Here is your reordered > one I will reject: > > A > jc/maint-blame-no-such-path > > "git blame MAKEFILE" run in a history that has "Makefile" but not > > "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got > > confused on a case insensitive filesystem. > > > B > * jc/maint-blame-no-such-path (2012-09-10) 1 commit > >- blame $path: avoid getting fooled by case insensitive filesystems > > I was noting that B which *is* formatted as a header line (it EVEN > has a leading asterisk to make it clear that it begins something > new) is in the middle, and you added a redundant A that is not even > marked clearly as a header line. The leading asterisk is actually not as useful to me, as indicating a header line, as the 'out-denting' I am proposing. I think this is due to the similarities between the asterisk and the other symbols used to indicate commits. This is maybe just a typographic issue, but I think in general the contrast between letters and spaces appearing in the first columns of text is stronger than either of characters and letters, or spaces and characters. A quick comparison of all three: --Letters and Spaces-- jc/maint-ident-missing-human-name "git show --format='%ci'" did not give timestamp correctly for... + split_ident_line(): make best effort when parsing author/committer line --Characters and Letters-- * jc/maint-ident-missing-human-name "git show --format='%ci'" did not give timestamp correctly for... + split_ident_line(): make best effort when parsing author/committer line --Characters and Spaces-- * jc/maint-ident-missing-human-name "git show --format='%ci'" did not give timestamp correctly for + split_ident_line(): make best effort when parsing author/committer line My preference would be first for letters and spaces, or if that is not good enough then characters and spaces. With regards to the comment that the old header line appears in the middle of the output, as I said earlier that was a consequence of reordering and indenting everything but otherwise leaving it as is. This should be changed, so how about: () <#-commits> () [list-of-commits] () eg: jc/maint-ident-missing-human-name (2012-08-31) "git show --format='%ci'" did not give timestamp correctly for commits created without human readable name on "committer" line. 1 commit (merged to 'next' on 2012-09-07 at 0e99b20) + split_ident_line(): make best effort when parsing author/committer line with no description: sl/autoconf (2012-09-11) 2 commits - build: don't duplicate substitution of make variables - build: improve GIT_CONF_SUBST signature Hopefully that makes more sense and addresses the concerns you raised. Adding an asterisk at the start is ok by me, if that is something you think is needed. One thing I did think about, when leaving the asterisk in the middle of the listing in the first version, was how machine readable the format was. I'm not sure if that is important, but the asterisk was a clear signal that what followed was a listing of commits. In any case, the new and revised format is perhaps slightly less machine readable as a result. I feel a little bit like I might be bikeshedding this, however I do think an improvement to the formatting of "What's cooking" is a meaningful one for the project! Regards, Andrew Ardill -- 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: CRLF, LF ... CR ?
On Thu, Sep 13, 2012 at 8:09 AM, Jens Bauer wrote: > Hi everyone. > > I'm quite fond of git, and have used it for a while. > Recently, I've started making printed circuit boards (PCBs) using an > application called OsmondPCB (for Mac), and I'd like to use git to track > changes on these. > This application was originally written for the old Mac OS (Mac OS 6 to Mac > OS 9.2). > The old Mac OS does not use LF, nor CRLF for line endings, but only CR. > > I've read that git supports two different line endings; either CRLF or LF, > but it does not support CR. > Would it make sense to add support for CR (if so, I hereby request it as a > new feature) ? > The alternative is to ask the developer if he would change the file format, > so that new versions of his software would change the files to end in LF, but > he'd have to be careful not to break compatibility. > If the software is to be changed, this would not fix similar issues that > other people might have. Do you mean that you want automatic conversion from CR to LF? What's about just storing the files as-is, with no conversion at all? (this is the default git behavior) git doesn't really even support LF. It stores content as-is which means LF works just fine. git prefers to not mess around with the content, but we do have autocrlf to help folks stuck on windows. If you need to, you can use .gitattributes to add a clean/smudge filter that does this conversion for you. See the "filter" section for an example: http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html If you're serious about wanting that feature then we'll happily review any patches you might have. That said, I don't really think it's a common enough case for git to natively support, so I'd recommend going with the .gitattributes filter. good luck, -- David -- 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: Suggestions for "What's cooking"
Andrew Ardill writes: > I feel a little bit like I might be bikeshedding this... Yes you are. -- 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: CRLF, LF ... CR ?
Hi David. Thank you for the information. I am not the one to decide whether or not this should be a built-in feature; I'm only a plain user. :) My personal opinion: If it was a built-in feature, people all over the World would not be getting into trouble with it. I've seen on the net, that even on PC (I don't know if it's DOS or Windows), a user wrote a program, that did not output CRLF, nor LF, but only CR. Perhaps git does not treat LF or CRLF in any special way, if that's the case, git's very beautifully programmed. -But gitweb does not seem to make correct output unless I add a clean/smudge filter. In addition to that, there is also the detail, that the terminal treats CR and LF differently... echo -e "this\ris\ra\rtest" will in bash only output... test ...while echo -e "this\nis\na\ntest" in bash outputs... this is a test ...This means that 'git diff' will (to the user) only output a single line of "junk", when line-endings are CR and not LF or CRLF. Also... git diff says that a file containing CR line endings have no end-of-line, which to me appears as that git diff thinks there is only one line. Finally, when I want to display the file using head, cat or tail, I still see only one line of text. [That's correct behaviour!] As you mentioned, there are good possibilites for fixing these things using clean/smudge filters. The clean/smudge filter I ended up using is quite simple (much simpler than I first thought it would be). I ended up with... [filter "cr"] clean = tr '\\15' '\\12' ...and no smudge, because the application supports reading lines ending in LF, so I wanted the files to stay readable. -But normally, there should ofcourse be a smudge filter, that reverses \15 and \12. In my opinion, the benefit from having git diff support CR, would be that the user does not lose the history if he/she wants to 'clean' the projects. Existing projects would be shown correctly. Of course, gitweb would need to support CR, so it generates correct line endings, instead of showing one long line with a lot of "\r" in them. [When thinking about all these CR/LF problems, I am grateful that Sinclair Research did not continue to use the ZX81 characterset in the ZX Spectrum. Imagine a mess we could have had!] Love Jens On Thu, 13 Sep 2012 21:06:32 -0700, David Aguilar wrote: > On Thu, Sep 13, 2012 at 8:09 AM, Jens Bauer wrote: >> Hi everyone. >> >> I'm quite fond of git, and have used it for a while. >> Recently, I've started making printed circuit boards (PCBs) using an >> application called OsmondPCB (for Mac), and I'd like to use git to >> track changes on these. >> This application was originally written for the old Mac OS (Mac OS 6 >> to Mac OS 9.2). >> The old Mac OS does not use LF, nor CRLF for line endings, but only CR. >> >> I've read that git supports two different line endings; either CRLF >> or LF, but it does not support CR. >> Would it make sense to add support for CR (if so, I hereby request >> it as a new feature) ? >> The alternative is to ask the developer if he would change the file >> format, so that new versions of his software would change the files >> to end in LF, but he'd have to be careful not to break compatibility. >> If the software is to be changed, this would not fix similar issues >> that other people might have. > > Do you mean that you want automatic conversion from CR to LF? > > What's about just storing the files as-is, > with no conversion at all? (this is the default git behavior) > > git doesn't really even support LF. It stores content as-is which > means LF works just fine. git prefers to not mess around with the content, > but we do have autocrlf to help folks stuck on windows. > > If you need to, you can use .gitattributes to add a clean/smudge filter > that does this conversion for you. > > See the "filter" section for an example: > > http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html > > If you're serious about wanting that feature then we'll > happily review any patches you might have. That said, I don't really > think it's a common enough case for git to natively support, so > I'd recommend going with the .gitattributes filter. > > good luck, > -- > David -- 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: Suggestions for "What's cooking"
Junio C Hamano writes: > I've played with both and have prepared patches to Reintegrate and > cook (both in the 'todo' branch). Will play with the changes a bit > more and then decide. So here is how tonight's "What's cooking" may look like with extra indentation and blank lines. The tools that read this file to help my workflow have been minimally adjusted. I am hoping that the updates to them I made were enough to make the format tweak not to negatively affect me, and so far things are going smoothly, but I may find some corner cases later. Knock wood... -- >8 -- To: git@vger.kernel.org Bcc: l...@lwn.net Subject: What's cooking in git.git (Sep 2012, #05; Thu, 13) X-master-at: ce5cf6ffc6feb9fb4f9a50cdfa2f527fa119c94f X-next-at: dd7cb6d65b94d88f3bfb9efefabd5818614bf587 What's cooking in git.git (Sep 2012, #05; Thu, 13) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. ***BLURB*** I'm planning to keep this cycle reasonably short and aim for tagging the result as 1.8.0 at the end of 9th week, on October 21st, after which I'd disappear for a few weeks. http://tinyurl.com/gitCal is where you can always find my rough tagging schedule at. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * jw/doc-commit-title (2012-09-13) 1 commit - Documentation: describe subject more precisely Update parts of document that talked about "first line of commit log" to say "title of commit" with definition of what that "title" is. Will merge to 'next' after eyeballing. * nd/maint-diffstat-summary (2012-09-13) 1 commit - Revert diffstat summary back to English Earlier we made the diffstat summary line that shows the number of lines added/deleted localizable, but it was found irritating having to see them in various languages on a list whose discussion language is English. Breaks many tests which need to be fixed before moving forward. * nd/fetch-status-alignment (2012-09-12) 2 commits - [FIXUP] %.*s width must be int, not size_t - fetch: align per-ref summary report in UTF-8 locales Will merge to 'next' after squashing the fix-up. * mv/cherry-pick-s (2012-09-13) 1 commit . cherry-pick: don't forget -s on failure * jc/maint-log-grep-all-match (2012-09-13) 3 commits - log: document use of multiple commit limiting options - log --grep/--author: honor --all-match honored for multiple --grep patterns - grep: teach --debug option to dump the parse tree Fix a long-standing bug in "git log --grep" when multiple "--grep" are used together with "--all-match" and "--author" or "--committer". -- [Stalled] * ph/credential-refactor (2012-09-02) 5 commits - wincred: port to generic credential helper - Merge branch 'ef/win32-cred-helper' into ph/credential-refactor - osxkeychain: port to generic credential helper implementation - gnome-keyring: port to generic helper implementation - contrib: add generic credential helper Attempts to refactor to share code among OSX keychain, Gnome keyring and Win32 credential helpers. * jc/maint-name-rev (2012-09-04) 7 commits - describe --contains: use "name-rev --weight" - name-rev --weight: tests and documentation - name-rev --weight: cache the computed weight in notes - name-rev --weight: trivial optimization - name-rev: --weight option - name_rev: clarify the logic to assign a new tip-name to a commit - name-rev: lose unnecessary typedef "git name-rev" names the given revision based on a ref that can be reached in the smallest number of steps from the rev, but that is not useful when the caller wants to know which tag is the oldest one that contains the rev. This teaches a new mode to the command that uses the oldest ref among those which contain the rev. I am not sure if this is worth it; for one thing, even with the help from notes-cache, it seems to make the "describe --contains" even slower. Also the command will be unusably slow for a user who does not have a write access (hence unable to create or update the notes-cache). Needs another round to at least find a better name for the option, and possibly a cheaper but still better than the current "close to the tip" heuristics. * ms/contrib-thunderbird-updates (2012-08-31) 2 commits - [SQUASH] minimum fixup - Thunderbird: fix appp.sh format problems Update helper to send out format-patch output using Thunderbird. Seems to have design regression for silent users. * as/check-ignore (2012-09-02) 10 commits . fixup: decl-after-stmt etc. . Add git-check-ignore . Provide free_directory() for reclaiming dir_struct memory . Extract some useful pathspec handling code from builtin/add.c into a l
Re: CRLF, LF ... CR ?
David Aguilar writes: > git doesn't really even support LF. At the storage level that is correct, but the above is a bit of stretch. It may not be "support", but git _does_ rely on LF when running many text oriented operations (a rough rule of thumb is "does 'a line' in a file matter to the operation?"). Think about "git diff" and "git blame". -- 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] clone: fix refspec on "--single-branch" option
After using "git clone" with the "--single-branch"
option, the configured refspec for this repo was
"+refs/heads/*:refs/remotes/origin/*".
After fetching changes from this repo again, it'll
receive all refs instead of the single ref which
was used in "--single-branch". Fixing the refspec
that it just contains the ref of the branch which
was cloned.
Signed-off-by: Ralf Thielow
---
builtin/clone.c | 5 -
1 Datei geändert, 4 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 5e8f3ba..3e74d55 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -754,7 +754,10 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
strbuf_addf(&branch_top, "refs/remotes/%s/", option_origin);
}
- strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
+ if (option_single_branch)
+ strbuf_addf(&value, "+%s%s:%s%s", src_ref_prefix,
option_branch, branch_top.buf, option_branch);
+ else
+ strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
if (option_mirror || !option_bare) {
/* Configure the remote */
--
1.7.12.395.g6b149ce.dirty
--
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
What's the point of saying "HEAD is now at ..."?
I sometimes wonder what value the message is giving us.
For example, while reviewing a patch in my Emacs session, I may say
| git am -s3c
which runs the command on the contents of the e-mail I am reading,
to apply the patch. After that, I would go to a separate terminal
and do things like "git show -U20", etc. Once I am done, I reset
the temporary commit away, and get this:
$ git reset --hard HEAD^
HEAD is now at ce5cf6f Merge git://github.com/git-l10n/git-po
or often it is
$ git reset --hard ko/master
HEAD is now at ce5cf6f Merge git://github.com/git-l10n/git-po
In either case, I know where I am resetting to, so "HEAD is now at"
is a less than useful noise. If it contained "HEAD was at ...", it
may let me realize that I was still going to use the contents in
some other way and quickly go back to it with another reset, with
cut and paste or with HEAD@{1}. In either case, showing the tip of
what I just discarded seems to be a lot more useful information than
what we are currently giving the users.
--
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] clone: fix refspec on "--single-branch" option
Ralf Thielow writes:
> After using "git clone" with the "--single-branch"
> option, the configured refspec for this repo was
> "+refs/heads/*:refs/remotes/origin/*".
> After fetching changes from this repo again, it'll
> receive all refs instead of the single ref which
> was used in "--single-branch". Fixing the refspec
> that it just contains the ref of the branch which
> was cloned.
>
> Signed-off-by: Ralf Thielow
> ---
> builtin/clone.c | 5 -
> 1 Datei geändert, 4 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 5e8f3ba..3e74d55 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -754,7 +754,10 @@ int cmd_clone(int argc, const char **argv, const char
> *prefix)
> strbuf_addf(&branch_top, "refs/remotes/%s/", option_origin);
> }
>
> - strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
> + if (option_single_branch)
> + strbuf_addf(&value, "+%s%s:%s%s", src_ref_prefix,
> option_branch, branch_top.buf, option_branch);
> + else
> + strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
Who guarantees at this point in the codepath that option_branch is
set when option_single_branch is non-zero? Until we talk with the
remote, "clone --single-branch" without an explicit "--branch" will
not learn which branch at the remote we are going to fetch (it will
be their HEAD).
I wonder if this should be more like this:
if (option_single_branch) {
if (option_branch)
Your patch "+refs/heads/foo:refs/remotes/origin/foo";
else
"HEAD";
} else {
Original "+refs/heads/*:refs/remotes/origin/*";
}
That is, "clone --single-branch" will continue fetching from and
integrating with their HEAD without storing any remote tracking
branch.
--
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: Suggestions for "What's cooking"
From: "Junio C Hamano" Sent: Friday, September 14, 2012 3:29 AM Andrew Ardill writes: On 14 September 2012 04:06, Junio C Hamano wrote: Andrew Ardill writes: * () () [list-of-commits] () I do not see how it makes any sense to have the "This is where the section begins with, and its name is this" line in the middle of a block indented in such a way. Care to explain? I'm not quite sure what aspect you are referring to,... Just this part, as I do not have much time. Here is your reordered one I will reject: A > jc/maint-blame-no-such-path > "git blame MAKEFILE" run in a history that has "Makefile" but not > "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got > confused on a case insensitive filesystem. > B > * jc/maint-blame-no-such-path (2012-09-10) 1 commit >- blame $path: avoid getting fooled by case insensitive filesystems I was noting that B which *is* formatted as a header line (it EVEN has a leading asterisk to make it clear that it begins something new) is in the middle, and you added a redundant A that is not even marked clearly as a header line. Are we all working with Black text on a White background? (or is it vice versa) as this changes which bits of emphasis the eye will pick up. I'm reading the emails as black text against a white background. I find that for black text, in a block format, that one does not notice any special inital character, such as the '*', when it is part of a rectangular block. In fact I feel I tend to, if anything, down grade text begining with special characters as being bullet points below some main block text. Hence my suggestion to have either a visual break (extra line above), or a block indent (extra left hand space). Changing the contrast to white text on a black background totally changes what the eye/brain will see/notice [$dayjob is electro-optic vision systems where contrast inversion is a standard requirement for that reason]. It maybe that we are seeing different personal effects because of our set-ups. -- 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/RFC] remote-helper: allow fetch to discover sha1 later
"Devin J. Pohly" writes: > From: "Devin J. Pohly" > > Allow a fetch-style remote helper to issue the notification > ref > to specify a ref's value during the fetch operation. > > Currently, a remote helper with the "fetch" capability cannot fetch a > ref unless its sha1 was known when the "list" command was executed. > This limitation is arbitrary, as the helper may eventually be able to > determine the correct sha1 as it fetches objects. While I am not fundamentally against supporting a remote helper that is not capable of saying what the object names of the tip of its histories are before doing a lot of work, I do not think it is a good idea to allow such a helper to claim that it supports "fetch" capability, for at least two reasons: * Being able to "list" is essential for "fetch" based helpers, I think, far from "arbitrary". When running a "git fetch" against such a remote, we can first issue "list" to see what it has and avoid asking for the refs that point at the histories we already have (or the refs that are the same as the last time we fetched from the remote). I do not offhand know if we do this kind of optimization, but if we don't, we should. * Existing versions of "git" that can drive remote helpers that claim to have "fetch" capability are not prepared to accept an unknown "refs" protocol message from the helper, so a helper written for your new semantics of "fetch" capability will not work with them. The point of capability mechanism is to prevent such a compatibility issue from breaking the system, and this patch goes against that spirit. Such a remote helper should not advertise to support "fetch" capability, because it does not support it. It can advertise that it supports "something else" and it is OK to make an updated Git that knows how to drive a remote helper that lack "fetch" but support that "something else" work with 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] clone: fix refspec on "--single-branch" option
Junio C Hamano writes:
> Who guarantees at this point in the codepath that option_branch is
> set when option_single_branch is non-zero? Until we talk with the
> remote, "clone --single-branch" without an explicit "--branch" will
> not learn which branch at the remote we are going to fetch (it will
> be their HEAD).
>
> I wonder if this should be more like this:
>
> if (option_single_branch) {
> if (option_branch)
> Your patch "+refs/heads/foo:refs/remotes/origin/foo";
> else
> "HEAD";
> } else {
> Original "+refs/heads/*:refs/remotes/origin/*";
> }
>
> That is, "clone --single-branch" will continue fetching from and
> integrating with their HEAD without storing any remote tracking
> branch.
Alternatively, if you can move the logic to set up this
configuration further down so that it happens after we talked to the
other side and figured out remote_head_points_at, you could instead
set it up to keep a single remote tracking branch.
Even if you did so, guess_remote_head() may not find any branch when
the other repository's HEAD is detached, so you would need to decide
what to do in such a case, and "fetch and integrate their HEAD
without using any remote tracking branch" may be a reasonable thing
to do in such a case.
--
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
