Re: [PATCH 3/3] sha1: use char type for temporary work buffer
Le mercredi 12 septembre 2012 à 17:04 -0400, Jeff King a écrit : Wouldn't this break all of the code that is planning to index W by 32-bit words (see the definitions of setW in block-sha1/sha1.c)? That's not the same W ... This part of the code is indeed unclear. Sorry, you're right, that's a different work array (though it has the identical issue, no?). No, this one is really accessed as int. But would probably benefit being declared as uint32_t. But the point still stands. Did you audit the block-sha1 code to make sure nobody is ever indexing the W array? Yes. It was the first thing to do before changing its definition (for alignment purpose especially). If you didn't, then your change is not safe. If you did, then you should really mention that in the commit message. Sorry about this. I thought having the test suite OK was enough to prove this. If that is indeed the problem, wouldn't the simplest fix be using uint32_t instead of unsigned int? It's another way to fix this oddity, but not simpler. It is simpler in the sense that it does not have any side effects (like changing how every user of the data structure needs to index it). There's no other user than blk_SHA1_Update() Moreover, would that be sufficient to run on such a platform? At the very least, H above would want the same treatment. And I would not be surprised if some of the actual code in block-sha1/sha1.c needed updating, as well. ctx-H is actually used as an array of integer, so it would benefits of being declared uint32_t for an ILP64 system. This fix would also be required for blk_SHA1_Block() function. So...if we are not ready to run on an ILP system after this change, then what is the purpose? Readility: in blk_SHA1_Block(), the ctx-W array is used a 64 bytes len array, so, AFAIK, there's no point of having it defined as a 16 int len. It's disturbing while reading the code. This could allows us to change the memcpy() call further: @@ -246,7 +246,7 @@ void blk_SHA1_Update(blk_SHA_CTX *ctx, const void *data, unsigned long len) unsigned int left = 64 - lenW; if (len left) left = len; - memcpy((char *)ctx-W + lenW, data, left); + memcpy(ctx-W + lenW, data, left); lenW = (lenW + left) 63; if (lenW) Regards. -- Yann Droneaud OPTEYA -- 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
{bug} warning: unable to access 'RelNotes/.gitattributes'
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. 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. It is getting late so I won't dig it further for now, but just a heads up. -- 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 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 j...@schmitz-digital.de --- 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 j...@schmitz-digital.de
---
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 philipoak...@iee.org Sent: Wednesday, September 12, 2012 11:49 PM From: Jens Lehmann jens.lehm...@web.de 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 g...@drmicha.warpmail.net 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_bodybodyregexp (or (or pattern_headhead 0Linus pattern_headhead 0Michael ) 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 commit' 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 vmik...@suse.cz
---
On Wed, Sep 12, 2012 at 03:45:10PM -0700, Junio C Hamano gits...@pobox.com
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] [--] filepattern...),
@@ -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');
-
[PATCH/RFC] remote-helper: allow fetch to discover sha1 later
From: Devin J. Pohly djpo...@gmail.com
Allow a fetch-style remote helper to issue the notification
ref sha1 name
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 djpo...@gmail.com
---
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 sha1 name' 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 file' 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 ti...@suse.de 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 ti...@suse.de 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 ti...@suse.de 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 jwh...@codeweavers.com --- 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 dir. 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
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 g...@drmicha.warpmail.net
---
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 g...@drmicha.warpmail.net
---
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
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: [GIT PULL] sound fixes for 3.6-rc6
Takashi Iwai ti...@suse.de 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
Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
2012/9/12 Junio C Hamano gits...@pobox.com: 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
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 gits...@pobox.com 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 andrew.ard...@gmail.com writes: Currently, the output for each branch looks something like: * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) long-description notes-and-memoranda next-steps 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: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) 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 cr 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 (cr) lines. After that, I see lf 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 (cr) lines. After that, I see lf 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 jwh...@codeweavers.com 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 jwh...@codeweavers.com --- 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 dir. 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 change, followed by a blank line and then a more thorough
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
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 gits...@pobox.com writes:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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 ralf.thie...@gmail.com 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 jwh...@codeweavers.com 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 jwh...@codeweavers.com --- 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 dir. 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
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 (cr) lines. After that, I see lf 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 p...@peff.net 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 /dev/null .junk-pack
And pack-objects.c::no_try_delta() is given RelNotes/1.7.4.txt as
a path (which is very strange), and is trying to see if -delta is
set for the path.
Three problems:
- 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.
- 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.
- 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.
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 could check for ENOTDIR to squelch the warning, but I think your
patch uncovered a lot deeper issues.
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;
}
--
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 commit' 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 vmik...@suse.cz
---
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] [--] filepattern...),
@@ -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;
+ }
+ while (i
Re: [PATCHv2 3/6] t7810-grep: test multiple --author with --all-match
Michael J Gruber g...@drmicha.warpmail.net writes:
--all-match is ignored for author matching on purpose.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
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_bodybodyJunio
pattern_bodybodyLinus
)
but when you say
git log --author=Linus --author=Junio
you will get
[all-match]
(or
(or
pattern_headhead 0Linus
pattern_headhead 0Junio
)
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_bodybodycommit
(or
(or
pattern_headhead 0Linus
pattern_headhead 0Junio
)
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_headhead 1Linus
(or
pattern_headhead 0Junio
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_bodybodycommit
(or
pattern_headhead 1Linus
(or
pattern_headhead 0Junio
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_bodybodycommit
pattern_bodybodytag
)
(or
pattern_headhead 1Linus
(or
pattern_headhead 0Junio
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_bodybodycommit
(or
pattern_bodybodytag
(or
pattern_headhead 1Linus
(or
pattern_headhead 0Junio
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 v3] cherry-pick: don't forget -s on failure
Miklos Vajna vmik...@suse.cz 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 jwh...@codeweavers.com --- 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 dir. 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
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 /dev/null .junk-pack
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.
- 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 jwh...@codeweavers.com 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] Revert diffstat back to English
On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net 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 g...@drmicha.warpmail.net 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 gits...@pobox.com
---
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, head %d, p-field); break;
+ case GREP_PATTERN_BODY:
+ fprintf(stderr, body); 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
grep_opt *opt)
return header_expr;
}
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 jwh...@codeweavers.com --- 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 dir. 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 `*`
Re: [PATCHv2 6/6] rev-list/log: document logic with several limiting options
Michael J Gruber g...@drmicha.warpmail.net 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 g...@drmicha.warpmail.net --- 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 gits...@pobox.com 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_bodybodycommit
(or
pattern_bodybodytag
(or
pattern_headhead 1Linus
(or
pattern_headhead 0Junio
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: Suggestions for What's cooking
Andrew Ardill andrew.ard...@gmail.com writes: On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) 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 gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) 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: branch-name (creation-date) branch-description? notes-and-memoranda? next-steps? #-commits (merge-status?) [list-of-commits] (branch-usage?) 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 jens-li...@gpio.dk 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 gits...@pobox.com 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 library .
Re: CRLF, LF ... CR ?
David Aguilar dav...@gmail.com 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 ralf.thie...@gmail.com
---
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 RETURN
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 ralf.thie...@gmail.com 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 ralf.thie...@gmail.com
---
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
