* Re: commit.template
From: Junio C Hamano @ 2008-12-27 0:13 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: jidanni, git
In-Reply-To: <20081227090727.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting jidanni@jidanni.org:
>
>> NS> Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
>>
>> No. I want in fact just to use "Signed-off-by: jidanni@jidanni.org",
>
> I think everybody on the list now understands that you desperately want to be different. I think it would be beneficial for you to try making a difference in areas that matter, instead of just trying to be different in how your name is spelled.
>
> Just my two yen ;-)
Even though I soft-of-kind-of understand that you are frustrated for
getting that response after offering an advice to satisfy his earlier
wish:
"Thanks but I want to be http://zh.wikipedia.org/wiki/積丹尼"
made in $gmane/103591, you do not sound so harsh and play a bad girl.
Be civil and friendly around here, please...
^ permalink raw reply
* Re: commit.template
From: Junio C Hamano @ 2008-12-27 0:16 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: jidanni, git
In-Reply-To: <7vwsdmjwzr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> made in $gmane/103591, you do not sound so harsh and play a bad girl.
Sorry, I meant "do not have to"...
^ permalink raw reply
* Re: [PATCH] describe: Avoid unnecessary warning when using --all
From: Junio C Hamano @ 2008-12-27 0:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: demerphq, rene.scharfe, git
In-Reply-To: <20081226220201.GA20516@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> In 212945d4 ("Teach git-describe to verify annotated tag names
> before output") git-describe learned how to output a warning if
> an annotated tag object was matched but its internal name doesn't
> match the local ref name.
>
> However, "git describe --all" causes the local ref name to be
> prefixed with "tags/", so we need to skip over this prefix before
> comparing the local ref name with the name recorded inside of the
> tag object.
>
> Patch-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
> Signed-off-by: Shawn O. Pearce <sop@google.com>
> ---
> IMHO, suitable for maint...
Yeah, do you prefer to be known as "sop" over "spearce" these days, by the
way? It does not make a difference to me but I just noticed that Author
and S-o-b won't be matching, so I am just being curious.
^ permalink raw reply
* Re: [PATCH] describe: Avoid unnecessary warning when using --all
From: Shawn O. Pearce @ 2008-12-27 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: demerphq, rene.scharfe, git
In-Reply-To: <7vmyeijws2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Patch-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
> > Signed-off-by: Shawn O. Pearce <sop@google.com>
>
> Yeah, do you prefer to be known as "sop" over "spearce" these days, by the
> way? It does not make a difference to me but I just noticed that Author
> and S-o-b won't be matching, so I am just being curious.
Whoops.
I use spearce@spearce.org for my Git work so the S-o-b line above
is wrong. I just fixed it in my development repository on the work
system I used to make this patch.
Having two personalities is hard... ;-)
Can you please amend to use my normal spearce@spearce.org address?
--
Shawn.
^ permalink raw reply
* [PATCH 1/3] pretty: factor out skip_empty_lines()
From: René Scharfe @ 2008-12-27 0:32 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
The patch after the next one will use it.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
pretty.c | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/pretty.c b/pretty.c
index f6ff312..c43497b 100644
--- a/pretty.c
+++ b/pretty.c
@@ -181,6 +181,20 @@ static int is_empty_line(const char *line, int *len_p)
return !len;
}
+static const char *skip_empty_lines(const char *msg)
+{
+ for (;;) {
+ int linelen = get_one_line(msg);
+ int ll = linelen;
+ if (!linelen)
+ break;
+ if (!is_empty_line(msg, &ll))
+ break;
+ msg += linelen;
+ }
+ return msg;
+}
+
static void add_merge_info(enum cmit_fmt fmt, struct strbuf *sb,
const struct commit *commit, int abbrev)
{
@@ -850,15 +864,7 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
}
/* Skip excess blank lines at the beginning of body, if any... */
- for (;;) {
- int linelen = get_one_line(msg);
- int ll = linelen;
- if (!linelen)
- break;
- if (!is_empty_line(msg, &ll))
- break;
- msg += linelen;
- }
+ msg = skip_empty_lines(msg);
/* These formats treat the title line specially. */
if (fmt == CMIT_FMT_ONELINE || fmt == CMIT_FMT_EMAIL)
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] Add a commit.signoff configuration variable to always use --signoff.
From: Junio C Hamano @ 2008-12-27 0:36 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, Johannes Schindelin
In-Reply-To: <20081226221033.GA841@chistera.yi.org>
Adeodato Simó <dato@net.com.org.es> writes:
> ... I'd
> still like to hear if my patch would be suitable for inclusion, because
> it's much more straightforward to use (and to discover).
But "straightforward to discover" is not an advantage in this case.
As long as it comes with documentation that clearly explains why this
feature should not be used blindly in order to avoid diluting the value of
S-o-b, I think the feature itself is not a harmful thing to have. Dscho's
argument in the quoted thread that says it should be a conscious act to
add S-o-b (except for the part he misunderstands what S-o-b attests), is a
good one and still is valid.
By the way, please do not deflect away responses meant to you by using a
Mail-Followup-To header that points at the git mailing list. It is rude.
^ permalink raw reply
* Re: [PATCH] describe: Avoid unnecessary warning when using --all
From: Miklos Vajna @ 2008-12-27 0:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, demerphq, rene.scharfe, git
In-Reply-To: <20081227002627.GA21386@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
On Fri, Dec 26, 2008 at 04:26:27PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> Having two personalities is hard... ;-)
>
> Can you please amend to use my normal spearce@spearce.org address?
BTW, what Pasky/Nice did was to keep the author field the same, but
change the S-o-b line based on if they did it in their free time or in
work hours.
Like this one:
http://article.gmane.org/gmane.comp.version-control.git/97419
And the related thread:
http://thread.gmane.org/gmane.comp.version-control.git/96690/focus=96768
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 2/3] pretty: factor out format_subject()
From: René Scharfe @ 2008-12-27 0:39 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <1230337969.8363.84.camel@ubuntu.ubuntu-domain>
The next patch will use it.
In the version that was factored out, we can't rely on the len of the
struct strbuf to find out if a line separator needs to be added, as
it might already contain something. Add a guard variable ("first")
instead.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
pretty.c | 42 ++++++++++++++++++++++++------------------
1 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/pretty.c b/pretty.c
index c43497b..632abc5 100644
--- a/pretty.c
+++ b/pretty.c
@@ -495,6 +495,28 @@ static void parse_commit_header(struct format_commit_context *context)
context->commit_header_parsed = 1;
}
+static const char *format_subject(struct strbuf *sb, const char *msg,
+ const char *line_separator)
+{
+ int first = 1;
+
+ for (;;) {
+ const char *line = msg;
+ int linelen = get_one_line(line);
+
+ msg += linelen;
+ if (!linelen || is_empty_line(line, &linelen))
+ break;
+
+ strbuf_grow(sb, linelen + 2);
+ if (!first)
+ strbuf_addstr(sb, line_separator);
+ strbuf_add(sb, line, linelen);
+ first = 0;
+ }
+ return msg;
+}
+
static void format_decoration(struct strbuf *sb, const struct commit *commit)
{
struct name_decoration *d;
@@ -718,27 +740,11 @@ void pp_title_line(enum cmit_fmt fmt,
const char *encoding,
int need_8bit_cte)
{
+ const char *line_separator = (fmt == CMIT_FMT_EMAIL) ? "\n " : " ";
struct strbuf title;
strbuf_init(&title, 80);
-
- for (;;) {
- const char *line = *msg_p;
- int linelen = get_one_line(line);
-
- *msg_p += linelen;
- if (!linelen || is_empty_line(line, &linelen))
- break;
-
- strbuf_grow(&title, linelen + 2);
- if (title.len) {
- if (fmt == CMIT_FMT_EMAIL) {
- strbuf_addch(&title, '\n');
- }
- strbuf_addch(&title, ' ');
- }
- strbuf_add(&title, line, linelen);
- }
+ *msg_p = format_subject(&title, *msg_p, line_separator);
strbuf_grow(sb, title.len + 1024);
if (subject) {
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] describe: Avoid unnecessary warning when using --all
From: Miklos Vajna @ 2008-12-27 0:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, demerphq, rene.scharfe, git
In-Reply-To: <20081227003859.GU21154@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
On Sat, Dec 27, 2008 at 01:38:59AM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Fri, Dec 26, 2008 at 04:26:27PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > Having two personalities is hard... ;-)
> >
> > Can you please amend to use my normal spearce@spearce.org address?
>
> BTW, what Pasky/Nice did was to keep the author field the same, but
Err, I meant to mention Nico, sorry.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] describe: Avoid unnecessary warning when using --all
From: Junio C Hamano @ 2008-12-27 0:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: demerphq, rene.scharfe, git
In-Reply-To: <20081227002627.GA21386@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I use spearce@spearce.org for my Git work so the S-o-b line above
> is wrong. I just fixed it in my development repository on the work
> system I used to make this patch.
>
> Having two personalities is hard... ;-)
>
> Can you please amend to use my normal spearce@spearce.org address?
Thanks, done.
^ permalink raw reply
* [PATCH 3/3] pretty: support multiline subjects with format:
From: René Scharfe @ 2008-12-27 0:49 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <1230338375.8363.91.camel@ubuntu.ubuntu-domain>
git log --pretty=format:%s (and tformat:) used to display the first
line of the subject, unlike the other --pretty options, which would
construct a subject line from all lines of the first paragraph of
the commit message.
For consistency and increased code reuse, change format: to do the
same as the other options.
Before:
$ git log --pretty=oneline v1.6.1 | md5sum
7c0896d2a94fc3315a0372b9b3373a8f -
$ git log --pretty=tformat:"%H %s" v1.6.1 | md5sum
298903b1c065002e15daa5329213c51f -
After:
$ git log --pretty=tformat:"%H %s" v1.6.1 | md5sum
7c0896d2a94fc3315a0372b9b3373a8f -
$ git log --pretty=oneline v1.6.1 | md5sum
7c0896d2a94fc3315a0372b9b3373a8f -
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
pretty.c | 53 ++++++++++++++++++++++++++++++++++-------------------
1 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/pretty.c b/pretty.c
index 632abc5..343dca5 100644
--- a/pretty.c
+++ b/pretty.c
@@ -424,13 +424,15 @@ struct chunk {
struct format_commit_context {
const struct commit *commit;
enum date_mode dmode;
+ unsigned commit_header_parsed:1;
+ unsigned commit_message_parsed:1;
/* These offsets are relative to the start of the commit message. */
- int commit_header_parsed;
- struct chunk subject;
struct chunk author;
struct chunk committer;
struct chunk encoding;
+ size_t message_off;
+ size_t subject_off;
size_t body_off;
/* The following ones are relative to the result struct strbuf. */
@@ -460,23 +462,14 @@ static void parse_commit_header(struct format_commit_context *context)
{
const char *msg = context->commit->buffer;
int i;
- enum { HEADER, SUBJECT, BODY } state;
- for (i = 0, state = HEADER; msg[i] && state < BODY; i++) {
+ for (i = 0; msg[i]; i++) {
int eol;
for (eol = i; msg[eol] && msg[eol] != '\n'; eol++)
; /* do nothing */
- if (state == SUBJECT) {
- context->subject.off = i;
- context->subject.len = eol - i;
- i = eol;
- }
if (i == eol) {
- state++;
- /* strip empty lines */
- while (msg[eol] == '\n' && msg[eol + 1] == '\n')
- eol++;
+ break;
} else if (!prefixcmp(msg + i, "author ")) {
context->author.off = i + 7;
context->author.len = eol - i - 7;
@@ -488,10 +481,8 @@ static void parse_commit_header(struct format_commit_context *context)
context->encoding.len = eol - i - 9;
}
i = eol;
- if (!msg[i])
- break;
}
- context->body_off = i;
+ context->message_off = i;
context->commit_header_parsed = 1;
}
@@ -508,6 +499,8 @@ static const char *format_subject(struct strbuf *sb, const char *msg,
if (!linelen || is_empty_line(line, &linelen))
break;
+ if (!sb)
+ continue;
strbuf_grow(sb, linelen + 2);
if (!first)
strbuf_addstr(sb, line_separator);
@@ -517,6 +510,21 @@ static const char *format_subject(struct strbuf *sb, const char *msg,
return msg;
}
+static void parse_commit_message(struct format_commit_context *c)
+{
+ const char *msg = c->commit->buffer + c->message_off;
+ const char *start = c->commit->buffer;
+
+ msg = skip_empty_lines(msg);
+ c->subject_off = msg - start;
+
+ msg = format_subject(NULL, msg, NULL);
+ msg = skip_empty_lines(msg);
+ c->body_off = msg - start;
+
+ c->commit_message_parsed = 1;
+}
+
static void format_decoration(struct strbuf *sb, const struct commit *commit)
{
struct name_decoration *d;
@@ -636,9 +644,6 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
parse_commit_header(c);
switch (placeholder[0]) {
- case 's': /* subject */
- strbuf_add(sb, msg + c->subject.off, c->subject.len);
- return 1;
case 'a': /* author ... */
return format_person_part(sb, placeholder[1],
msg + c->author.off, c->author.len,
@@ -650,6 +655,16 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'e': /* encoding */
strbuf_add(sb, msg + c->encoding.off, c->encoding.len);
return 1;
+ }
+
+ /* Now we need to parse the commit message. */
+ if (!c->commit_message_parsed)
+ parse_commit_message(c);
+
+ switch (placeholder[0]) {
+ case 's': /* subject */
+ format_subject(sb, msg + c->subject_off, " ");
+ return 1;
case 'b': /* body */
strbuf_addstr(sb, msg + c->body_off);
return 1;
--
1.6.1
^ permalink raw reply related
* Re: commit.template
From: Boyd Stephen Smith Jr. @ 2008-12-27 0:53 UTC (permalink / raw)
To: git; +Cc: jidanni, nanako3
In-Reply-To: <87hc4qscz5.fsf@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
On Friday 2008 December 26 18:01:18 jidanni@jidanni.org wrote:
> OK, both
>
> >> 1) man git-config mentions
> >> commit.template
>
> and
> BSS> git commit --help tells how this configuration option is used, in the
> BSS> documentation of the "-t" option.
> should
>
> >> mention what file is being used presently
There is no file being used presently. With the "-m" or "-F" option, no
template is ever used. Without those options, either the argument to "-t" or
the value of commit.template is used in that order; the editor is invoked on
that. Finally if neither of those are defined the editor is invoked on a
new, empty file.
> as one needs a template in order to modify a template.
You aren't modifying the template with commit.template or "-t", you are
specifying one. You can create one from scratch in your editor of choice.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: commit.template
From: jidanni @ 2008-12-27 1:04 UTC (permalink / raw)
To: bss; +Cc: git
In-Reply-To: <200812261853.55464.bss@iguanasuicide.net>
OK, but there should be a reference to any %escapes available in
templates, etc.
Or say the template is purely and additional ".signature" style file
that will be inserted at some certain spot...
^ permalink raw reply
* Re: commit.template
From: Boyd Stephen Smith Jr. @ 2008-12-27 1:48 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <874p0qsa2h.fsf@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
On Friday 2008 December 26 19:04:06 jidanni@jidanni.org wrote:
> OK, but there should be a reference to any %escapes available in
> templates, etc.
There are none, at least not right now.
> Or say the template is purely and additional ".signature" style file
> that will be inserted at some certain spot...
There's what it says:
"Use the contents of the given file as the initial version of the
commit message. The editor is invoked and you can make subsequent
changes. [...] This overrides the commit.template
configuration variable."
-- 'git commit --help'
What isn't clear about that? It's not an *extra* file; it is the template
(what you start with) for commit messages.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Nicolas Pitre @ 2008-12-27 1:56 UTC (permalink / raw)
To: Heikki Orsila; +Cc: Junio C Hamano, git, lkml
In-Reply-To: <20081225114443.GD6115@zakalwe.fi>
On Thu, 25 Dec 2008, Heikki Orsila wrote:
> On Wed, Dec 24, 2008 at 10:36:27PM -0800, Junio C Hamano wrote:
> > * The packfile machinery hopefully is more robust when dealing with
> > corrupt packs if redundant objects involved in the corruption are
> > available elsewhere.
>
> Has anyone written a summary of how Git's redundancy operates?
>
> * What would be the probability for a single bit flip to corrupt the
> repository?
This is not something that git itself could answer. The probability
depends on the quality of your hardware. Once that probability has
occurred though, it is clear that your repository is then corrupted as
there is hardly any redundant bits in a git repository.
> * And what is the situation where a single bit flip can not corrupt the
> database?
The database can be resilient against most kind of corruptions if you
have a redundant copy of the affected object. It will still be
corrupted, but git is now able to detect corruptions gracefully and
function correctly with some fallback objects. Those objects must exist
in some other related repository though, and copied over to the affected
repository manually. It's then possible and recommended to "fix" the
corruption simply by repacking the repository at that point.
So there is no magic involved: you need to have some kind of backups,
either using traditional backup solutions, or by simply having your
repository cloned somewhere else. The idea of having a repository fixed
with redundant objects is for those cases where you need to salvage new
work that has no corresponding backup, but although corresponding
objects are not corrupted, they could be delta objects which base is
against old objects which happen to be corrupted.
> * When (which commands/functions) is error detection done?
Error detection is performed all the time. When it's not the more
expensive SHA1 checksum, at least the zlib CRC32 is verified. What the
latest git version does amongst other corruption related things is to
close some small holes where some specific kind of corruptions could
have been undetected and propagated from one pack to another when
repacking.
Nicolas
^ permalink raw reply
* Re: commit.template
From: jidanni @ 2008-12-27 2:00 UTC (permalink / raw)
To: bss; +Cc: git
In-Reply-To: <200812261948.58032.bss@iguanasuicide.net>
I see, it's not replacing something current. It is adding something
extra. OK, would have never guessed. OK, stopping here.
^ permalink raw reply
* Re: getting started, happy with cmd line on windows [Scanned]
From: Zorba @ 2008-12-27 2:18 UTC (permalink / raw)
To: git
In-Reply-To: <7v4p0qlcnc.fsf@gitster.siamese.dyndns.org>
> Drop "rm *.*". Instead, probably what you want is
>
>> $ <import code>
>> $ git init
>> $ git commit
>
> which is a good way to make an initial import.
>
>> $ git tag versionA <commitID>
>> $ hack hack hack
>> ...
>
> and you futzed with the codebase without any intention of committing;
> it is nice to be able to experiment freely.
>
> After you are done experimenting,
>
> $ git reset --hard versionA
>
> if you did not make any commit, or even if you did commit while you were
> experimenting, if you do not want these experimental commits at all.
>
> No need for "rm *.*" anywhere.
Hi Junio,
Yes, I had not considered the possibility of being able to reset to last
commit (as manual page talked about UNDOing commits). $git reset -hard HEAD
= This is great, and gives me the functionality I want, get back to the last
conscious commit after hacking.
I've noticed since discovering this that the Reset function on the Win GUI
will ONLY let you reset as far as but not beyond the last commit (i.e.
unable to undo any commits) so I can use that too.
The other functionality I was looking for is being able to handle a changing
"portfolio" of files from version to version:
e.g.
version A = ABC.txt, AB.txt, AC.txt
version B = ABC.txt, AB.txt
version C = ABC.txt, AC.txt
version D = no files
I'm sure this is a common scenario, for ppl starting out with git as they
load up versions that till now have been sitting in file systems.
By using git-add and git-rm (or git-commit -a) I was able to have my
add/remove files to the index in "staging" and in the end the versions in
the repo match up to real life example. Then I can --hard reset back to any
of these, and ONLY got the files that were in that version.
Its a shame though that git-commit -a only removes files from the index, and
doesn't add files to the index, otherwise creating new versions is just a
case of importing the files needed for eacch version and cranking..
$ git commit -a
repeatedly.
But thanks to all who helped me on this one, and who knows maybe this post
will help some other pilgrim following after me
:-)
Season's geetings,
CR
^ permalink raw reply
* [PATCH] Documentation/gitrepository-layout.txt: enhance discussion of objects/[0-9a-f][0-9a-f]
From: jidanni @ 2008-12-27 2:48 UTC (permalink / raw)
To: git
Signed-off-by: jidanni <jidanni@jidanni.org>
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index 03c52ff..bf900df 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -46,6 +46,4 @@ objects/[0-9a-f][0-9a-f]::
- Traditionally, each object is stored in its own file.
- They are split into 256 subdirectories using the first
- two letters from its object name to keep the number of
- directory entries `objects` directory itself needs to
- hold. Objects found here are often called 'unpacked'
- (or 'loose') objects.
+ Each object is stored in its own file. They are split into 256
+ subdirectories to keep directory sizes down. Example: object
+ 92b35d66... is stored in .git/object/92/b35d66... Objects
+ found here are often called 'unpacked' (or 'loose') objects.
--
1.5.6.5
^ permalink raw reply related
* [JGIT PATCH] Expose the advertised refs to ReceivePack hooks
From: Shawn O. Pearce @ 2008-12-27 3:47 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Hooks may want to be able to consider what the client was shown, so
they can make decisions based on that information.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/transport/ReceivePack.java | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/ReceivePack.java b/org.spearce.jgit/src/org/spearce/jgit/transport/ReceivePack.java
index 95519b8..76d11c4 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/ReceivePack.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/ReceivePack.java
@@ -155,6 +155,11 @@ public final RevWalk getRevWalk() {
return walk;
}
+ /** @return all refs which were advertised to the client. */
+ public final Map<String, Ref> getAdvertisedRefs() {
+ return refs;
+ }
+
/**
* @return true if this instance will verify received objects are formatted
* correctly. Validating objects requires more CPU time on this side
--
1.6.1.302.gccd4d
^ permalink raw reply related
* [PATCH] parse-opt: migrate builtin-apply.
From: Miklos Vajna @ 2008-12-27 4:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The only notable user-visible/incompatible change is that the
--build-fake-ancestor option now conforms to gitcli(7).
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I know that we do care about incompatible changes a lot, though I think
this is the right direction and probably --build-fake-ancestor is not a
heavily used switch, so I hope that part is OK.
Documentation/git-apply.txt | 4 +-
builtin-apply.c | 360 ++++++++++++++++++++++++++++---------------
2 files changed, 234 insertions(+), 130 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index e726510..9400f6a 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git apply' [--stat] [--numstat] [--summary] [--check] [--index]
- [--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
+ [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]
[--allow-binary-replacement | --binary] [--reject] [-z]
[-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
[--whitespace=<nowarn|warn|fix|error|error-all>]
@@ -64,7 +64,7 @@ OPTIONS
cached data, apply the patch, and store the result in the index,
without using the working tree. This implies '--index'.
---build-fake-ancestor <file>::
+--build-fake-ancestor=<file>::
Newer 'git-diff' output has embedded 'index information'
for each blob to help identify the original version that
the patch applies to. When this flag is given, and if
diff --git a/builtin-apply.c b/builtin-apply.c
index 07244b0..c2a587f 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -14,6 +14,7 @@
#include "builtin.h"
#include "string-list.h"
#include "dir.h"
+#include "parse-options.h"
/*
* --check turns on checking that the working tree matches the
@@ -46,8 +47,10 @@ static int no_add;
static const char *fake_ancestor;
static int line_termination = '\n';
static unsigned long p_context = ULONG_MAX;
-static const char apply_usage[] =
-"git apply [--stat] [--numstat] [--summary] [--check] [--index] [--cached] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [--reverse] [--reject] [--verbose] [-z] [-pNUM] [-CNUM] [--whitespace=<nowarn|warn|fix|error|error-all>] <patch>...";
+static const char * const apply_usage[] = {
+ "git apply [--stat] [--numstat] [--summary] [--check] [--index] [--cached] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [--reverse] [--reject] [--verbose] [-z] [-pNUM] [-CNUM] [--whitespace=<nowarn|warn|fix|error|error-all>] <patch>...",
+ NULL
+};
static enum ws_error_action {
nowarn_ws_error,
@@ -61,6 +64,8 @@ static int applied_after_fixing_ws;
static const char *patch_input_file;
static const char *root;
static int root_len;
+static int read_stdin = 1;
+static int options;
static void parse_whitespace_option(const char *option)
{
@@ -3135,150 +3140,249 @@ static int git_apply_config(const char *var, const char *value, void *cb)
return git_default_config(var, value, cb);
}
+static int option_parse_stdin(const struct option *opt,
+ const char *arg, int unset)
+{
+ int *errs = opt->value;
+
+ *errs |= apply_patch(0, "<stdin>", options);
+ read_stdin = 0;
+ return 0;
+}
+
+static int option_parse_exclude(const struct option *opt,
+ const char *arg, int unset)
+{
+ add_name_limit(arg, 1);
+ return 0;
+}
+
+static int option_parse_include(const struct option *opt,
+ const char *arg, int unset)
+{
+ add_name_limit(arg, 0);
+ has_include = 1;
+ return 0;
+}
+
+static int option_parse_p(const struct option *opt,
+ const char *arg, int unset)
+{
+ p_value = atoi(arg);
+ p_value_known = 1;
+ return 0;
+}
+
+static int option_parse_stat(const struct option *opt,
+ const char *arg, int unset)
+{
+ apply = 0;
+ diffstat = 1;
+ return 0;
+}
+
+static int option_parse_numstat(const struct option *opt,
+ const char *arg, int unset)
+{
+ apply = 0;
+ numstat = 1;
+ return 0;
+}
+
+static int option_parse_summary(const struct option *opt,
+ const char *arg, int unset)
+{
+ apply = 0;
+ summary = 1;
+ return 0;
+}
+
+static int option_parse_check(const struct option *opt,
+ const char *arg, int unset)
+{
+ apply = 0;
+ check = 1;
+ return 0;
+}
+
+static int option_parse_index(const struct option *opt,
+ const char *arg, int unset)
+{
+ int *is_not_gitdir = opt->value;
+
+ if (*is_not_gitdir)
+ die("--index outside a repository");
+ check_index = 1;
+ return 0;
+}
+
+static int option_parse_cached(const struct option *opt,
+ const char *arg, int unset)
+{
+ int *is_not_gitdir = opt->value;
+
+ if (*is_not_gitdir)
+ die("--cached outside a repository");
+ check_index = 1;
+ cached = 1;
+ return 0;
+}
+
+static int option_parse_ancestor(const struct option *opt,
+ const char *arg, int unset)
+{
+ apply = 0;
+ fake_ancestor = arg;
+ return 0;
+}
+
+static int option_parse_z(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (unset)
+ line_termination = '\n';
+ else
+ line_termination = 0;
+ return 0;
+}
+
+static int option_parse_whitespace(const struct option *opt,
+ const char *arg, int unset)
+{
+ const char **whitespace_option = opt->value;
+
+ *whitespace_option = arg;
+ parse_whitespace_option(arg);
+ return 0;
+}
+
+static int option_parse_reject(const struct option *opt,
+ const char *arg, int unset)
+{
+ apply = apply_with_reject = apply_verbosely = 1;
+ return 0;
+}
+
+static int option_parse_inaccurate(const struct option *opt,
+ const char *arg, int unset)
+{
+ options |= INACCURATE_EOF;
+ return 0;
+}
+
+static int option_parse_recount(const struct option *opt,
+ const char *arg, int unset)
+{
+ options |= RECOUNT;
+ return 0;
+}
+
+static int option_parse_directory(const struct option *opt,
+ const char *arg, int unset)
+{
+ root_len = strlen(arg);
+ if (root_len && arg[root_len - 1] != '/') {
+ char *new_root;
+ root = new_root = xmalloc(root_len + 2);
+ strcpy(new_root, arg);
+ strcpy(new_root + root_len++, "/");
+ } else
+ root = arg;
+ return 0;
+}
int cmd_apply(int argc, const char **argv, const char *unused_prefix)
{
int i;
- int read_stdin = 1;
- int options = 0;
int errs = 0;
int is_not_gitdir;
+ int binary;
const char *whitespace_option = NULL;
+ struct option builtin_apply_options[] = {
+ { OPTION_CALLBACK, '-', NULL, &errs, NULL,
+ "read the patch from the standard input",
+ PARSE_OPT_NOARG, option_parse_stdin },
+ { OPTION_CALLBACK, 0, "exclude", NULL, "path",
+ "don´t apply changes matching the given path",
+ 0, option_parse_exclude },
+ { OPTION_CALLBACK, 0, "include", NULL, "path",
+ "apply changes matching the given path",
+ 0, option_parse_include },
+ { OPTION_CALLBACK, 'p', NULL, NULL, "num",
+ "remove <num> leading slashes from traditional diff paths",
+ 0, option_parse_p },
+ OPT_BOOLEAN(0, "no-add", &no_add,
+ "ignore additions made by the patch"),
+ { OPTION_CALLBACK, 0, "stat", NULL, NULL,
+ "instead of applying the patch, output diffstat for the input",
+ PARSE_OPT_NOARG, option_parse_stat },
+ OPT_BOOLEAN(0, "allow-binary-replacement", &binary,
+ "now no-op"),
+ OPT_BOOLEAN(0, "binary", &binary,
+ "now no-op"),
+ { OPTION_CALLBACK, 0, "numstat", NULL, NULL,
+ "shows number of added and deleted lines in decimal notation",
+ PARSE_OPT_NOARG, option_parse_numstat },
+ { OPTION_CALLBACK, 0, "summary", NULL, NULL,
+ "instead of applying the patch, output a summary for the input",
+ PARSE_OPT_NOARG, option_parse_summary },
+ { OPTION_CALLBACK, 0, "check", NULL, NULL,
+ "instead of applying the patch, see if the patch is applicable",
+ PARSE_OPT_NOARG, option_parse_check },
+ { OPTION_CALLBACK, 0, "index", &is_not_gitdir, NULL,
+ "make sure the patch is applicable to the current index",
+ PARSE_OPT_NOARG, option_parse_index },
+ { OPTION_CALLBACK, 0, "cached", &is_not_gitdir, NULL,
+ "apply a patch without touching the working tree",
+ PARSE_OPT_NOARG, option_parse_cached },
+ OPT_BOOLEAN(0, "apply", &apply,
+ "also apply the patch (use with --stat/--summary/--check)"),
+ { OPTION_CALLBACK, 0, "build-fake-ancestor", NULL, "file",
+ "build a temporary index based on embedded index information",
+ 0, option_parse_ancestor },
+ { OPTION_CALLBACK, 'z', NULL, NULL, NULL,
+ "paths are separated with NUL character",
+ PARSE_OPT_NOARG, option_parse_z },
+ OPT_INTEGER('C', NULL, &p_context,
+ "ensure at least <n> lines of context match"),
+ { OPTION_CALLBACK, 0, "whitespace", &whitespace_option, "action",
+ "detect new or modified lines that have whitespace errors",
+ 0, option_parse_whitespace },
+ OPT_BOOLEAN('R', "reverse", &apply_in_reverse,
+ "apply the patch in reverse"),
+ OPT_BOOLEAN(0, "unidiff-zero", &unidiff_zero,
+ "don't expect at least one line of context"),
+ { OPTION_CALLBACK, 0, "reject", NULL, NULL,
+ "leave the rejected hunks in corresponding *.rej files",
+ PARSE_OPT_NOARG, option_parse_reject },
+ OPT__VERBOSE(&apply_verbosely),
+ { OPTION_CALLBACK, 0, "inaccurate-eof", NULL, NULL,
+ "tolerate incorrectly detected missing new-line at the end of file",
+ PARSE_OPT_NOARG, option_parse_inaccurate },
+ { OPTION_CALLBACK, 0, "recount", NULL, NULL,
+ "do not trust the line counts in the hunk headers",
+ PARSE_OPT_NOARG, option_parse_recount },
+ { OPTION_CALLBACK, 0, "directory", NULL, "root",
+ "prepend <root> to all filenames",
+ 0, option_parse_directory },
+ OPT_END()
+ };
+
prefix = setup_git_directory_gently(&is_not_gitdir);
prefix_length = prefix ? strlen(prefix) : 0;
git_config(git_apply_config, NULL);
if (apply_default_whitespace)
parse_whitespace_option(apply_default_whitespace);
- for (i = 1; i < argc; i++) {
+ argc = parse_options(argc, argv, builtin_apply_options,
+ apply_usage, 0);
+
+ for (i = 0; i < argc; i++) {
const char *arg = argv[i];
- char *end;
int fd;
- if (!strcmp(arg, "-")) {
- errs |= apply_patch(0, "<stdin>", options);
- read_stdin = 0;
- continue;
- }
- if (!prefixcmp(arg, "--exclude=")) {
- add_name_limit(arg + 10, 1);
- continue;
- }
- if (!prefixcmp(arg, "--include=")) {
- add_name_limit(arg + 10, 0);
- has_include = 1;
- continue;
- }
- if (!prefixcmp(arg, "-p")) {
- p_value = atoi(arg + 2);
- p_value_known = 1;
- continue;
- }
- if (!strcmp(arg, "--no-add")) {
- no_add = 1;
- continue;
- }
- if (!strcmp(arg, "--stat")) {
- apply = 0;
- diffstat = 1;
- continue;
- }
- if (!strcmp(arg, "--allow-binary-replacement") ||
- !strcmp(arg, "--binary")) {
- continue; /* now no-op */
- }
- if (!strcmp(arg, "--numstat")) {
- apply = 0;
- numstat = 1;
- continue;
- }
- if (!strcmp(arg, "--summary")) {
- apply = 0;
- summary = 1;
- continue;
- }
- if (!strcmp(arg, "--check")) {
- apply = 0;
- check = 1;
- continue;
- }
- if (!strcmp(arg, "--index")) {
- if (is_not_gitdir)
- die("--index outside a repository");
- check_index = 1;
- continue;
- }
- if (!strcmp(arg, "--cached")) {
- if (is_not_gitdir)
- die("--cached outside a repository");
- check_index = 1;
- cached = 1;
- continue;
- }
- if (!strcmp(arg, "--apply")) {
- apply = 1;
- continue;
- }
- if (!strcmp(arg, "--build-fake-ancestor")) {
- apply = 0;
- if (++i >= argc)
- die ("need a filename");
- fake_ancestor = argv[i];
- continue;
- }
- if (!strcmp(arg, "-z")) {
- line_termination = 0;
- continue;
- }
- if (!prefixcmp(arg, "-C")) {
- p_context = strtoul(arg + 2, &end, 0);
- if (*end != '\0')
- die("unrecognized context count '%s'", arg + 2);
- continue;
- }
- if (!prefixcmp(arg, "--whitespace=")) {
- whitespace_option = arg + 13;
- parse_whitespace_option(arg + 13);
- continue;
- }
- if (!strcmp(arg, "-R") || !strcmp(arg, "--reverse")) {
- apply_in_reverse = 1;
- continue;
- }
- if (!strcmp(arg, "--unidiff-zero")) {
- unidiff_zero = 1;
- continue;
- }
- if (!strcmp(arg, "--reject")) {
- apply = apply_with_reject = apply_verbosely = 1;
- continue;
- }
- if (!strcmp(arg, "-v") || !strcmp(arg, "--verbose")) {
- apply_verbosely = 1;
- continue;
- }
- if (!strcmp(arg, "--inaccurate-eof")) {
- options |= INACCURATE_EOF;
- continue;
- }
- if (!strcmp(arg, "--recount")) {
- options |= RECOUNT;
- continue;
- }
- if (!prefixcmp(arg, "--directory=")) {
- arg += strlen("--directory=");
- root_len = strlen(arg);
- if (root_len && arg[root_len - 1] != '/') {
- char *new_root;
- root = new_root = xmalloc(root_len + 2);
- strcpy(new_root, arg);
- strcpy(new_root + root_len++, "/");
- } else
- root = arg;
- continue;
- }
if (0 < prefix_length)
arg = prefix_filename(prefix, prefix_length, arg);
--
1.6.1.rc1.35.gae26e.dirty
^ permalink raw reply related
* Re: [PATCH] parse-opt: migrate builtin-apply.
From: Junio C Hamano @ 2008-12-27 7:29 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1230351727-20116-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> The only notable user-visible/incompatible change is that the
> --build-fake-ancestor option now conforms to gitcli(7).
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> I know that we do care about incompatible changes a lot, though I think
> this is the right direction and probably --build-fake-ancestor is not a
> heavily used switch, so I hope that part is OK.
An acceptable justification for such a plumbing change is if (1) the old
syntax is still supported the same way as the original implementation,
*and* if (2) the new syntax is something that could not possibly have been
a valid input to the original implementation with a different meaning.
I think the condition (1) holds but (2) does not hold for your patch; even
though I think the latter breakage is excusable in this particular case,
it is not for the reason you cited.
That is,
(1) The parseopt parser allows both of these forms:
$ git apply --build-fake-ancestor file <input
$ git apply --build-fake-ancestor=file <input
The former has been how existing scripts that use the plumbing have
been feeding the file, and it is still supported.
(2) A script that used "git apply" and relied on the behaviour of
the original implementation could have fed a patch from a file
whose name is "--build-fake-ancestor=some-string", with this command
line:
$ git apply --build-fake-ancestor=file
Now such a script would break with the new parser.
The reason you are excused to break such an insane script is definitely
not because --build-fake-ancestor is a rarely used option. The whole
defence depends on the fact that --build-fake-ancestor=something is a very
unlikely name for any sane script to be using for its temporary file. It
could still be an end user input, but at that point you could simply doubt
the sanity of the end user and dismiss the issue away.
I am not fundamentally opposed to using parseopt in git-apply, and I think
the change to add a new and saner meaning to "--build-fake-ancestor=file"
on the command line is a good thing in the longer term. But your
justification for such a change should be given in such a way to show
clearly that you have thought things through. It has to be much better
than "it is not a heavily used switch anyway".
The saddest part of the story that pisses me off about this patch is that
you did not seem to have even run the test suite before sending it. t4105
and t4252 fail for me, at least.
I did not look at the patch very closely, but do you really need that many
option callbacks? My gut feeling is that many of them should be just
setting a boolean flag, and you can postprocess to get the correct "apply"
behaviour.
For example, you start with "apply" set to true, and let parseopt set
"diffstat" upon seeing "--stat", and set "cmdline_apply" upon seeing
"--apply". After parseopt returns, you determine the final value of
"apply" by using "diffstat" (and friends that would normally drop "apply")
and "cmdline_apply" (which would override such droppages). That way I
think you can lose many callback functions whose sole purpose is to drop
"apply" option, no?
^ permalink raw reply
* [PATCH 2/2] grep: grep cache entries if they are "assume unchanged"
From: Nguyễn Thái Ngọc Duy @ 2008-12-27 8:21 UTC (permalink / raw)
To: Junio C Hamano, git, Daniel Barkalow
Cc: Nguyễn Thái Ngọc Duy
"Assume unchanged" bit means "please pretend that I have never touched
this file", so if user removes the file, we should not care.
This patch teaches "git grep" to use cache version in such
situations. External grep case has not been fixed yet. But given that
on the platform that CE_VALID bit may be used like Windows, external
grep is not available anyway, I would wait for people to raise their
hands before touching it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I will do git-grep fixes for sparse checkout later because it will require
nd/narrow. This series does not, so it can be applied separatedly.
builtin-grep.c | 7 ++++++-
t/t7002-grep.sh | 7 +++++++
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 3c97c2c..bebf15c 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -404,7 +404,12 @@ static int grep_cache(struct grep_opt *opt, const char **paths, int cached)
continue;
if (!pathspec_matches(paths, ce->name))
continue;
- if (cached) {
+ /*
+ * If CE_VALID is on, we assume worktree file and its cache entry
+ * are identical, even if worktree file has been modified, so use
+ * cache version instead
+ */
+ if (cached || (ce->ce_flags & CE_VALID)) {
if (ce_stage(ce))
continue;
hit |= grep_sha1(opt, ce->sha1, ce->name, 0);
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index 18fe6f2..e12b5dc 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -161,7 +161,14 @@ test_expect_success 'log grep (6)' '
git log --author=-0700 --pretty=tformat:%s >actual &&
>expect &&
test_cmp expect actual
+'
+test_expect_success 'grep with CE_VALID file' '
+ git update-index --assume-unchanged t/t &&
+ rm t/t &&
+ test "$(git grep --no-ext-grep t)" = "t/t:test" &&
+ git update-index --no-assume-unchanged t/t &&
+ git checkout t/t
'
test_done
--
1.6.0.4.1116.g25b13
^ permalink raw reply related
* [PATCH 1/2] grep: support --no-ext-grep to test builtin grep
From: Nguyễn Thái Ngọc Duy @ 2008-12-27 8:21 UTC (permalink / raw)
To: Junio C Hamano, git, Daniel Barkalow
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1230366064-1306-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
used by the next patch
builtin-grep.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 624f86e..3c97c2c 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -20,6 +20,8 @@
#endif
#endif
+static int builtin_grep;
+
/*
* git grep pathspecs are somewhat different from diff-tree pathspecs;
* pathname wildcards are allowed.
@@ -389,7 +391,7 @@ static int grep_cache(struct grep_opt *opt, const char **paths, int cached)
* we grep through the checked-out files. It tends to
* be a lot more optimized
*/
- if (!cached) {
+ if (!cached && !builtin_grep) {
hit = external_grep(opt, paths, cached);
if (hit >= 0)
return hit;
@@ -545,6 +547,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
cached = 1;
continue;
}
+ if (!strcmp("--no-ext-grep", arg)) {
+ builtin_grep = 1;
+ continue;
+ }
if (!strcmp("-a", arg) ||
!strcmp("--text", arg)) {
opt.binary = GREP_BINARY_TEXT;
--
1.6.0.4.1116.g25b13
^ permalink raw reply related
* Re: [PATCH] Add a commit.signoff configuration variable to always use --signoff.
From: Adeodato Simó @ 2008-12-27 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vabaijvxl.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano [Fri, 26 Dec 2008 16:36:38 -0800]:
> Adeodato Simó <dato@net.com.org.es> writes:
> > ... I'd
> > still like to hear if my patch would be suitable for inclusion, because
> > it's much more straightforward to use (and to discover).
> But "straightforward to discover" is not an advantage in this case.
> As long as it comes with documentation that clearly explains why this
> feature should not be used blindly in order to avoid diluting the value of
> S-o-b, I think the feature itself is not a harmful thing to have. Dscho's
> argument in the quoted thread that says it should be a conscious act to
> add S-o-b (except for the part he misunderstands what S-o-b attests), is a
> good one and still is valid.
Does this sound good? If so, I'll send an amended patch (or should I send an
incremental/extra one instead?):
+commit.signoff::
+ If set, 'git-commit' will always add a Signed-off-by line.
+ Please use this option with care: by enabling it, you're stating
+ that all your commits will invariably meet the S-o-b
+ requirements for any project you send patches to. It's probably
+ best to only use it from your private repositories' .git/config
+ file, and only for projects who require a S-o-b as proof of
+ provenance of the patch, and not of its correctness or quality.
> By the way, please do not deflect away responses meant to you by using a
> Mail-Followup-To header that points at the git mailing list. It is rude.
I set a M-F-T header because I prefer not to be CC'ed. I have other
mechanisms in place that prevent me from missing replies to my messages
(based on In-Reply-To/References headers).
Nevertheless, if the list normally operates CC-based, I can see how pressing
Reply-to-all and not seing the original autor in the recipient list can be
offputting, so I'll stop setting M-F-T in my messages to git@. (Hopefully
starting with this message already.)
I didn't mean for it to be rude in any way.
Thanks,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A conference is a gathering of important people who singly can do nothing
but together can decide that nothing can be done.
-- Fred Allen
^ permalink raw reply
* Re: [PATCH] Add a commit.signoff configuration variable to always use --signoff.
From: Junio C Hamano @ 2008-12-27 8:44 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, Johannes Schindelin
In-Reply-To: <20081227082620.GA5230@chistera.yi.org>
Adeodato Simó <dato@net.com.org.es> writes:
> Does this sound good? If so, I'll send an amended patch (or should I send an
> incremental/extra one instead?):
>
> +commit.signoff::
> + If set, 'git-commit' will always add a Signed-off-by line.
It is not a big deal, but my first reaction to the above was "S-o-b by
whom? It misses details and does not say where to find them".
How about "if set, 'git commit' will behave as if '-s' option was given",
so that we can leave the details of whose S-o-b line to generate and such
to the description of "git commit -s" manual page?
> + Please use this option with care: by enabling it, you're stating
> + that all your commits will invariably meet the S-o-b
> + requirements for any project you send patches to. It's probably
> + best to only use it from your private repositories' .git/config
> + file, and only for projects who require a S-o-b as proof of
> + provenance of the patch, and not of its correctness or quality.
Yeah, many projects do not even have S-o-b convention.
>> By the way, please do not deflect away responses meant to you by using a
>> Mail-Followup-To header that points at the git mailing list. It is rude.
>
> I set a M-F-T header because I prefer not to be CC'ed. I have other
> mechanisms in place that prevent me from missing replies to my messages
> (based on In-Reply-To/References headers).
>
> Nevertheless, if the list normally operates CC-based, I can see how pressing
> Reply-to-all and not seing the original autor in the recipient list can be
> offputting, so I'll stop setting M-F-T in my messages to git@. (Hopefully
> starting with this message already.)
Thanks.
Another problem that you seem to have missed about M-F-T is that while you
solicited responses from general public by CC'ing the list (which allowed
me to respond to you), by forcing the response go only to the list, you
excluded people on the To: and Cc: list of your original message from my
response. You required them to be subscribed to the list, if they want to
be kept in the loop.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox