* [PATCH da/difftool-mergtool-refactor] Makefile: fix permissions of mergetools/ checked out with permissive umask
From: Jonathan Nieder @ 2011-10-09 9:17 UTC (permalink / raw)
To: David Aguilar
Cc: Junio C Hamano, git, Tanguy Ortolo, Charles Bailey,
Sebastian Schuberth
In-Reply-To: <1313652227-48545-4-git-send-email-davvid@gmail.com>
Ever since mergetool--lib was split into multiple files in
v1.7.7-rc0~3^2~1 (2011-08-18), the Makefile takes care to reset umask
and use tar --no-owner when installing merge tool definitions to
$(gitexecdir)/mergetools/. Unfortunately it does not take into
account the possibility that the permission bits of the files being
copied might already be wrong.
Rather than fixing the "tar" incantation and making it even more
complicated, let's just use the "install" utility. This only means
losing the ability to install executables and subdirectories of
mergetools/, which wasn't used.
Noticed by installing from a copy of git checked out with umask 002.
Compare v1.6.0.3~81^2 (Fix permission bits on sources checked out with
an overtight umask, 2008-08-21).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
David Aguilar wrote:
> +++ b/Makefile
[...]
> @@ -2266,6 +2274,9 @@ install: all
> $(INSTALL) -m 644 $(SCRIPT_LIB) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
> $(INSTALL) $(install_bindir_programs) '$(DESTDIR_SQ)$(bindir_SQ)'
> $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
> + $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
> + (cd mergetools && $(TAR) cf - .) | \
> + (cd '$(DESTDIR_SQ)$(mergetools_instdir_SQ)' && umask 022 && $(TAR) xof -)
Last month I tried this out and found that, strangely, my files under
/usr/lib/git-core/mergetools/ had the g+w bit set. Leading me to
wonder: does the "umask" here have any effect at all?
Since debian/rules install is run as root, the default is for tar to
act as thought --preserve-permissions were passed, so the umask when
running "tar" is not relevant. Luckily I think "tar" is overkill
here, anyway.
Thoughts? Sorry to have taken so long to send this out.
Makefile | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 1e91b19c..e27755e7 100644
--- a/Makefile
+++ b/Makefile
@@ -2275,8 +2275,7 @@ install: all
$(INSTALL) $(install_bindir_programs) '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
- (cd mergetools && $(TAR) cf - .) | \
- (cd '$(DESTDIR_SQ)$(mergetools_instdir_SQ)' && umask 022 && $(TAR) xof -)
+ $(INSTALL) -m 644 mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C gitweb install
--
1.7.7.rc1
^ permalink raw reply related
* Re: [PATCH 6/6] revert: Simplify passing command-line arguments around
From: Ramkumar Ramachandra @ 2011-10-09 9:04 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Tay Ray Chuan, Git List, Junio C Hamano, Jeff King,
Daniel Barkalow, Christian Couder
In-Reply-To: <20111009085306.GA9209@elie.hsd1.il.comcast.net>
Hi Jonathan,
Jonathan Nieder writes:
> More important than the idiom is the intent. Presumably that intent
> was something like "I wrote the commit message, so if it makes you
> scratch your head, blame me, not Jonathan; and I made some other
> (minor) improvements, so consider blaming me even if it's the
> functional part that makes you scratch your head."
Exactly.
> Sorry I haven't had a chance to look over the patch yet. Is it
> supposed to introduce a behavior change, does it prepare for some
> future change, or is it just a cleanup?
Prepare for some future change. See $gmane/179282 for original discussion.
-- Ram
^ permalink raw reply
* Re: [PATCH 6/6] revert: Simplify passing command-line arguments around
From: Jonathan Nieder @ 2011-10-09 9:24 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Tay Ray Chuan, Git List, Junio C Hamano, Jeff King,
Daniel Barkalow, Christian Couder
In-Reply-To: <CALkWK0niwg1Ogs+xBr8NHEce-MUUzPc_Upn0ZKRi3iCZ6fA4BQ@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Jonathan Nieder writes:
>> Sorry I haven't had a chance to look over the patch yet. Is it
>> supposed to introduce a behavior change, does it prepare for some
>> future change, or is it just a cleanup?
>
> Prepare for some future change. See $gmane/179282 for original discussion.
Thanks, but I shouldn't have had to ask. Care to fix the commit
message? :)
^ permalink raw reply
* Re: A Basic Git Question About File Tracking [ANSWERED]
From: Jakub Narebski @ 2011-10-09 9:37 UTC (permalink / raw)
To: Jon Forrest; +Cc: git, Jonathan Nieder
In-Reply-To: <4E910A14.7040801@gmail.com>
On Sun, 9 Oct 2011, Jon Forrest wrote:
> On 10/8/2011 6:17 PM, Jakub Narebski wrote:
>
> > You seem to be under [false] impression that git commit is about
> > _changes_ / _changeset_.
>
> This is correct. The Pro Git book says:
>
> "You stage these modified files and then commit
> all your staged changes"
>
> Plus, even "git status" tells me
>
> $ git status
> # On branch master
> # Changes to be committed:
Well, that is because the two representations: delta / changeset
("differential") representation and snapshot ("integral") representation
are related, and [in practice] one can be transformed into the other.
Sometimes it is better to think about commit as representing changeset
from parent commit, sometimes it is better to think of a commit as of
snapshot of a state of project.
But under the hood git model is snapshot-based.
> But I see my error. Below is what I hope is a clear
> explanation of what I didn't understand. It presumes
> that the reader understands the git objects model.
> Please let me know if anything is incorrect.
> ----------
> When you "git add" a file two things happen:
>
> 1) The file is copied to the git objects tree.
Actually it is file _contents_ that is copied to git object _store_.
> This location where the file is copied depends
> on the hash of the file's content.
I'd say that this is unnecessary implementation detail of "loose"
object format. I would say that _identifier_ of added object is
based on its contents.
>
> 2) An entry for the file is added to the git index.
> This entry includes the same hash that was mentioned
> in #1.
Yes.
> A tracked file has an entry in the git index file.
Yes.
> A copy of the file also exists in the objects tree.
A copy of a _contents_ of a file at specific point of time
exists in object _store_ (not necessary object tree, as it
can be packed).
> When you run 'git status', git computes the hash of
> every file in your working directory and looks
> up each file in the index. If the file isn't found
> then the file is shown as untracked.
Sidenote: git stores in the index also stats of a file (modification
time etc.) so it is possible to avoid recomputing the hash of every
file.
> When you do a commit, the hash values of everything
> in the index are copied into a tree object. The hash
> value of the tree object is then placed in a commit object.
True, though I would probably state it a bit differently.
> No copies of tracked files in the working directory are
> made at commit time. This is because the files were already
> copied into the objects tree when 'git add' was run.
> This is one reason why git commits are so fast.
Well, there is also "git commit -a", but it is true that git
copies into object store only those tracked files that changed.
Also I think that the main reason that git commits are fast is
that they are local operation, and not over the network as in the
case of centralized version control systems.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 6/6] Retain caches of submodule refs
From: Michael Haggerty @ 2011-10-09 11:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt
In-Reply-To: <7v4o1hgemp.fsf@alter.siamese.dyndns.org>
On 08/17/2011 12:45 AM, Junio C Hamano wrote:
> All the changes except for this one made sense to me, but I am not sure
> about this one. How often do we look into different submodule refs in the
> same process over and over again?
I am having pangs of uncertainty about this patch.
Previous to this patch, the submodule reference cache was only used for
the duration of one call to do_for_each_ref(). (It was not *discarded*
until later, but the old cache was never reused.) Therefore, the
submodule reference cache was implicitly invalidated between successive
uses.
After this change, submodule ref caches are invalidated whenever
invalidate_cached_refs() is called. But this function is static, and it
is only called when main-module refs are changed.
AFAIK there is no way within refs.c to add, modify, or delete a
submodule reference. But if other code modifies submodule references
directly, then the submodule ref cache in refs.c would become stale.
Moreover, there is currently no API for invalidating the cache.
So I think I need help from a submodule guru (Heiko?) who can tell me
what is done with submodule references and whether they might be
modified while a git process is executing in the main module. If so,
then either this patch has to be withdrawn, or more work has to be put
in to make such code invalidate the submodule reference cache.
Sorry for the oversight, but I forgot that not all code necessarily uses
the refs.c API when dealing with references (a regrettable situation, BTW).
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH 1/2] xdiff: factor out get_func_line()
From: René Scharfe @ 2011-10-09 11:34 UTC (permalink / raw)
To: Git Mailing List; +Cc: Sverre Rabbelier, Junio C Hamano
Move the code to search for a function line to be shown in the hunk
header into its own function and to make returning the length-limited
result string easier, introduce struct func_line.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
xdiff/xemit.c | 43 +++++++++++++++++++++++++++----------------
1 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 277e2ee..64eb17a 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -100,14 +100,35 @@ static int xdl_emit_common(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
return 0;
}
+struct func_line {
+ long len;
+ char buf[80];
+};
+
+static void get_func_line(xdfenv_t *xe, xdemitconf_t const *xecfg,
+ struct func_line *func_line, long start, long limit)
+{
+ find_func_t ff = xecfg->find_func ? xecfg->find_func : def_ff;
+ long l, size = sizeof(func_line->buf);
+ char *buf = func_line->buf;
+
+ for (l = start; l > limit && 0 <= l; l--) {
+ const char *rec;
+ long reclen = xdl_get_rec(&xe->xdf1, l, &rec);
+ long len = ff(rec, reclen, buf, size, xecfg->find_func_priv);
+ if (len >= 0) {
+ func_line->len = len;
+ break;
+ }
+ }
+}
+
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdemitconf_t const *xecfg) {
long s1, s2, e1, e2, lctx;
xdchange_t *xch, *xche;
- char funcbuf[80];
- long funclen = 0;
long funclineprev = -1;
- find_func_t ff = xecfg->find_func ? xecfg->find_func : def_ff;
+ struct func_line func_line = { 0 };
if (xecfg->flags & XDL_EMIT_COMMON)
return xdl_emit_common(xe, xscr, ecb, xecfg);
@@ -130,22 +151,12 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
*/
if (xecfg->flags & XDL_EMIT_FUNCNAMES) {
- long l;
- for (l = s1 - 1; l >= 0 && l > funclineprev; l--) {
- const char *rec;
- long reclen = xdl_get_rec(&xe->xdf1, l, &rec);
- long newfunclen = ff(rec, reclen, funcbuf,
- sizeof(funcbuf),
- xecfg->find_func_priv);
- if (newfunclen >= 0) {
- funclen = newfunclen;
- break;
- }
- }
+ get_func_line(xe, xecfg, &func_line,
+ s1 - 1, funclineprev);
funclineprev = s1 - 1;
}
if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2,
- funcbuf, funclen, ecb) < 0)
+ func_line.buf, func_line.len, ecb) < 0)
return -1;
/*
--
1.7.7
^ permalink raw reply related
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Charles Bailey @ 2011-10-09 11:26 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Junio C Hamano, Phil Hord, Sitaram Chamarty, git
In-Reply-To: <20111008131015.GA28213@sita-lt.atc.tcs.com>
On Sat, Oct 08, 2011 at 06:40:15PM +0530, Sitaram Chamarty wrote:
>
> git-difftool--helper.sh | 9 +++++----
> t/t7800-difftool.sh | 44 +++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
> index 8452890..0468446 100755
> --- a/git-difftool--helper.sh
> +++ b/git-difftool--helper.sh
> @@ -38,15 +38,16 @@ launch_merge_tool () {
>
> # $LOCAL and $REMOTE are temporary files so prompt
> # the user with the real $MERGED name before launching $merge_tool.
> + ans=y
> if should_prompt
> then
> printf "\nViewing: '$MERGED'\n"
> if use_ext_cmd
> then
> - printf "Hit return to launch '%s': " \
> + printf "Launch '%s' [Y/n]: " \
> "$GIT_DIFFTOOL_EXTCMD"
> else
> - printf "Hit return to launch '%s': " "$merge_tool"
> + printf "Launch '%s' [Y/n]: " "$merge_tool"
> fi
> read ans
> fi
> @@ -54,9 +55,9 @@ launch_merge_tool () {
> if use_ext_cmd
> then
> export BASE
> - eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
> + test "$ans" != "n" && eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
> else
> - run_merge_tool "$merge_tool"
> + test "$ans" != "n" && run_merge_tool "$merge_tool"
> fi
> }
It's a minor point but for me, this looks a little more difficult to
follow than it needs to be.
Why do we need to hold on to 'ans' for so long? With the new prompt,
if we ever 'read ans' we always want to return from the
launch_merge_tool without doing anything else if we read "n". I think
it's easier to follow if we just change 'read ans' and leave the 'if
use_ext_cmd' clauses alone. Perhaps some people don't like the early
return, though?
Charles.
E.g. (for discussion, untested):
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index 8452890..b668a12 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -43,12 +43,16 @@ launch_merge_tool () {
printf "\nViewing: '$MERGED'\n"
if use_ext_cmd
then
- printf "Hit return to launch '%s': " \
+ printf "Launch '%s' [Y/n]: " \
"$GIT_DIFFTOOL_EXTCMD"
else
- printf "Hit return to launch '%s': " "$merge_tool"
+ printf "Launch '%s' [Y/n]: " "$merge_tool"
+ fi
+
+ if read ans && test "$ans" = "n"
+ then
+ return
fi
- read ans
fi
if use_ext_cmd
^ permalink raw reply related
* [PATCH 2/2] diff: add option to show whole functions as context
From: René Scharfe @ 2011-10-09 11:36 UTC (permalink / raw)
To: Git Mailing List; +Cc: Sverre Rabbelier, Junio C Hamano
In-Reply-To: <4E9186D9.4060805@lsrfire.ath.cx>
Add the option -W/--function-context to git diff. It is similar to
the same option of git grep and expands the context of change hunks
so that the whole surrounding function is shown. This "natural"
context can allow changes to be understood better.
Note: GNU patch doesn't like diffs generated with the new option;
it seems to expect context lines to be the same before and after
changes. git apply doesn't complain.
This implementation has the same shortcoming as the one in grep,
namely that there is no way to explicitly find the end of a
function. That means that a few lines of extra context are shown,
right up to the next recognized function begins. It's already
useful in its current form, though.
The function get_func_line() in xdiff/xemit.c is extended to work
forward as well as backward to find post-context as well as
pre-context. It returns the position of the first found matching
line. The func_line parameter is made optional, as we don't need
it for -W.
The enhanced function is then used in xdl_emit_diff() to extend
the context as needed. If the added context overlaps with the
next change, it is merged into the current hunk.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/diff-options.txt | 4 ++
diff.c | 8 +++
diff.h | 1 +
t/t4051-diff-function-context.sh | 92 ++++++++++++++++++++++++++++++++++++++
xdiff/xdiff.h | 1 +
xdiff/xemit.c | 54 ++++++++++++++++++++---
6 files changed, 154 insertions(+), 6 deletions(-)
create mode 100644 t/t4051-diff-function-context.sh
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index b620b3a..1ce4ae3 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -404,6 +404,10 @@ endif::git-format-patch[]
Show the context between diff hunks, up to the specified number
of lines, thereby fusing hunks that are close to each other.
+-W::
+--function-context::
+ Show whole surrounding functions of changes.
+
ifndef::git-format-patch[]
--exit-code::
Make the program exit with codes similar to diff(1).
diff --git a/diff.c b/diff.c
index fcc0078..42c4891 100644
--- a/diff.c
+++ b/diff.c
@@ -2169,6 +2169,8 @@ static void builtin_diff(const char *name_a,
xecfg.ctxlen = o->context;
xecfg.interhunkctxlen = o->interhunkcontext;
xecfg.flags = XDL_EMIT_FUNCNAMES;
+ if (DIFF_OPT_TST(o, FUNCCONTEXT))
+ xecfg.flags |= XDL_EMIT_FUNCCONTEXT;
if (pe)
xdiff_set_find_func(&xecfg, pe->pattern, pe->cflags);
if (!diffopts)
@@ -3530,6 +3532,12 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
else if (opt_arg(arg, '\0', "inter-hunk-context",
&options->interhunkcontext))
;
+ else if (!strcmp(arg, "-W"))
+ DIFF_OPT_SET(options, FUNCCONTEXT);
+ else if (!strcmp(arg, "--function-context"))
+ DIFF_OPT_SET(options, FUNCCONTEXT);
+ else if (!strcmp(arg, "--no-function-context"))
+ DIFF_OPT_CLR(options, FUNCCONTEXT);
else if ((argcount = parse_long_opt("output", av, &optarg))) {
options->file = fopen(optarg, "w");
if (!options->file)
diff --git a/diff.h b/diff.h
index 8c66b59..0c51724 100644
--- a/diff.h
+++ b/diff.h
@@ -79,6 +79,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct diff_options *opt, void *data)
#define DIFF_OPT_IGNORE_DIRTY_SUBMODULES (1 << 26)
#define DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG (1 << 27)
#define DIFF_OPT_DIRSTAT_BY_LINE (1 << 28)
+#define DIFF_OPT_FUNCCONTEXT (1 << 29)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
diff --git a/t/t4051-diff-function-context.sh b/t/t4051-diff-function-context.sh
new file mode 100644
index 0000000..001d678
--- /dev/null
+++ b/t/t4051-diff-function-context.sh
@@ -0,0 +1,92 @@
+#!/bin/sh
+
+test_description='diff function context'
+
+. ./test-lib.sh
+. "$TEST_DIRECTORY"/diff-lib.sh
+
+
+cat <<\EOF >hello.c
+#include <stdio.h>
+
+static int a(void)
+{
+ /*
+ * Dummy.
+ */
+}
+
+static int hello_world(void)
+{
+ /* Classic. */
+ printf("Hello world.\n");
+
+ /* Success! */
+ return 0;
+}
+static int b(void)
+{
+ /*
+ * Dummy, too.
+ */
+}
+
+int main(int argc, char **argv)
+{
+ a();
+ b();
+ return hello_world();
+}
+EOF
+
+test_expect_success 'setup' '
+ git add hello.c &&
+ test_tick &&
+ git commit -m initial &&
+
+ grep -v Classic <hello.c >hello.c.new &&
+ mv hello.c.new hello.c
+'
+
+cat <<\EOF >expected
+diff --git a/hello.c b/hello.c
+--- a/hello.c
++++ b/hello.c
+@@ -10,8 +10,7 @@ static int a(void)
+ static int hello_world(void)
+ {
+- /* Classic. */
+ printf("Hello world.\n");
+
+ /* Success! */
+ return 0;
+ }
+EOF
+
+test_expect_success 'diff -U0 -W' '
+ git diff -U0 -W >actual &&
+ compare_diff_patch actual expected
+'
+
+cat <<\EOF >expected
+diff --git a/hello.c b/hello.c
+--- a/hello.c
++++ b/hello.c
+@@ -9,9 +9,8 @@ static int a(void)
+
+ static int hello_world(void)
+ {
+- /* Classic. */
+ printf("Hello world.\n");
+
+ /* Success! */
+ return 0;
+ }
+EOF
+
+test_expect_success 'diff -W' '
+ git diff -W >actual &&
+ compare_diff_patch actual expected
+'
+
+test_done
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 4beb10c..00d36c3 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -43,6 +43,7 @@ extern "C" {
#define XDL_EMIT_FUNCNAMES (1 << 0)
#define XDL_EMIT_COMMON (1 << 1)
+#define XDL_EMIT_FUNCCONTEXT (1 << 2)
#define XDL_MMB_READONLY (1 << 0)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 64eb17a..2e669c3 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -105,22 +105,27 @@ struct func_line {
char buf[80];
};
-static void get_func_line(xdfenv_t *xe, xdemitconf_t const *xecfg,
+static long get_func_line(xdfenv_t *xe, xdemitconf_t const *xecfg,
struct func_line *func_line, long start, long limit)
{
find_func_t ff = xecfg->find_func ? xecfg->find_func : def_ff;
- long l, size = sizeof(func_line->buf);
- char *buf = func_line->buf;
+ long l, size, step = (start > limit) ? -1 : 1;
+ char *buf, dummy[1];
- for (l = start; l > limit && 0 <= l; l--) {
+ buf = func_line ? func_line->buf : dummy;
+ size = func_line ? sizeof(func_line->buf) : sizeof(dummy);
+
+ for (l = start; l != limit && 0 <= l && l < xe->xdf1.nrec; l += step) {
const char *rec;
long reclen = xdl_get_rec(&xe->xdf1, l, &rec);
long len = ff(rec, reclen, buf, size, xecfg->find_func_priv);
if (len >= 0) {
- func_line->len = len;
- break;
+ if (func_line)
+ func_line->len = len;
+ return l;
}
}
+ return -1;
}
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
@@ -139,6 +144,17 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
s1 = XDL_MAX(xch->i1 - xecfg->ctxlen, 0);
s2 = XDL_MAX(xch->i2 - xecfg->ctxlen, 0);
+ if (xecfg->flags & XDL_EMIT_FUNCCONTEXT) {
+ long fs1 = get_func_line(xe, xecfg, NULL, xch->i1, -1);
+ if (fs1 < 0)
+ fs1 = 0;
+ if (fs1 < s1) {
+ s2 -= s1 - fs1;
+ s1 = fs1;
+ }
+ }
+
+ again:
lctx = xecfg->ctxlen;
lctx = XDL_MIN(lctx, xe->xdf1.nrec - (xche->i1 + xche->chg1));
lctx = XDL_MIN(lctx, xe->xdf2.nrec - (xche->i2 + xche->chg2));
@@ -146,6 +162,32 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
e1 = xche->i1 + xche->chg1 + lctx;
e2 = xche->i2 + xche->chg2 + lctx;
+ if (xecfg->flags & XDL_EMIT_FUNCCONTEXT) {
+ long fe1 = get_func_line(xe, xecfg, NULL,
+ xche->i1 + xche->chg1,
+ xe->xdf1.nrec);
+ if (fe1 < 0)
+ fe1 = xe->xdf1.nrec;
+ if (fe1 > e1) {
+ e2 += fe1 - e1;
+ e1 = fe1;
+ }
+
+ /*
+ * Overlap with next change? Then include it
+ * in the current hunk and start over to find
+ * its new end.
+ */
+ if (xche->next) {
+ long l = xche->next->i1;
+ if (l <= e1 ||
+ get_func_line(xe, xecfg, NULL, l, e1) < 0) {
+ xche = xche->next;
+ goto again;
+ }
+ }
+ }
+
/*
* Emit current hunk header.
*/
--
1.7.7
^ permalink raw reply related
* Re: [PATCH da/difftool-mergtool-refactor] Makefile: fix permissions of mergetools/ checked out with permissive umask
From: Jonathan Nieder @ 2011-10-09 11:43 UTC (permalink / raw)
To: David Aguilar
Cc: Junio C Hamano, git, Tanguy Ortolo, Charles Bailey,
Sebastian Schuberth
In-Reply-To: <20111009091617.GA29150@elie.hsd1.il.comcast.net>
Jonathan Nieder wrote:
> ---
[...]
> Since debian/rules install is run as root, the default is for tar to
> act as thought --preserve-permissions were passed
I should have said: "when 'make install' is run as root, ...".
Typically people building git for private use would run "make install"
as root when installing to /usr/local, but as an unprivileged user
when installing to $HOME. The RPM packaging runs "make install"
without special privileges and the Debian packaging runs it as (fake)
root, iirc.
Sorry for the lack of clarity.
^ permalink raw reply
* Re: [PATCH v3 5/5] attr.c: respect core.ignorecase when matching attribute patterns
From: Michael Haggerty @ 2011-10-09 15:16 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git, peff, j.sixt, Brandon Casey
In-Reply-To: <U4wiHVyDLLG1PhI-8iY3YhHT7CEcTMEfg9MCDSaeuwAkg0N1a5wRE5NXaKAVQx8kpEYt75REVpRavoc-HiKe6rLk2AUepzHWptkevo08MRbGyWxqBHT_rySLemcbi66NKLRXwFGtaRQ@cipher.nrlssc.navy.mil>
On 10/06/2011 08:22 PM, Brandon Casey wrote:
> The last set of tests is performed only on a case-insensitive filesystem.
> Those tests make sure that git handles the case where the .gitignore file
> resides in a subdirectory and the user supplies a path that does not match
> the case in the filesystem. In that case^H^H^H^Hsituation, part of the
> path supplied by the user is effectively interpreted case-insensitively,
> and part of it is dependent on the setting of core.ignorecase. git should
> only match the portion of the path below the directory holding the
> .gitignore file according to the setting of core.ignorecase.
Isn't this a rather perverse scenario? It is hard to imagine that
anybody *wants* part of a single filename to be matched
case-insensitively and another part to be matched case-sensitively.
ISTM that a person who is using a case-insensitive filesystem and has
core-ignorecase=false is (1) a glutton for punishment and (2) probably
very careful to make sure that the case of all pathnames is correct. So
such a person is not likely to benefit from this schizophrenic behavior.
> [...] If git instead built the attr
> stack by scanning the repository, then the paths in the origin field would
> not necessarily match the paths supplied by the user. If someone makes a
> change like that in the future, these tests will notice.
Your decision to treat path names as partly case-insensitive will make
this kind of improvement considerably more complicated.
Therefore, weighing the negligible benefit of declaring this
schizophrenic behavior against the potential big pain of remaining
backwards-compatible with this behavior, I suggest that we either (1)
declare that when core.ignorecase=false then the *whole* filenames
(including the path leading up to the .gitignore file) must match
case-sensitively, or (2) declare the behavior in this situation to be
undefined so that nobody thinks they should depend on it.
But given that I'm a potential implementer but not a potential Windows
user, perhaps my judgment is biased...
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 1/3] traverse_trees(): allow pruning with pathspec
From: Michael Haggerty @ 2011-10-09 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Nguyen Thai Ngoc Duy
In-Reply-To: <1314653603-7533-2-git-send-email-gitster@pobox.com>
On 08/29/2011 11:33 PM, Junio C Hamano wrote:
> diff --git a/tree-walk.c b/tree-walk.c
> index 33f749e..808bb55 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> [...]
> @@ -376,16 +396,22 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
> mask |= 1ul << i;
> if (S_ISDIR(entry[i].mode))
> dirmask |= 1ul << i;
> + e = &entry[i];
> }
> if (!mask)
> break;
> - ret = info->fn(n, mask, dirmask, entry, info);
> - if (ret < 0) {
> - error = ret;
> - if (!info->show_all_errors)
> - break;
> + interesting = prune_traversal(e, info, &base, interesting);
According to gcc 4.2.4 (though, strangely, not gcc 4.4.3):
tree-walk.c: In function ‘traverse_trees’:
tree-walk.c:347: warning: ‘e’ may be used uninitialized in this function
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Check revision and if no files modified (looking for svnversion equivalent)
From: fkater @ 2011-10-09 16:29 UTC (permalink / raw)
To: git
Hi,
in my subversion software repository I use the 'svnversion'
command to do both:
- get the last revision (e.g. r1001)
- check for modified files not yet checked in (e.g. r1001 M)
Both information is required for the application's build
process (Makefiles):
- to display the version in the application
- to refuse to build a proper 'release' version if something
was not checked in
Would there be a way to do both in git somehow?
Felix
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Michael J Gruber @ 2011-10-09 16:32 UTC (permalink / raw)
Cc: Git Mailing List, Robin H. Johnson, Junio C Hamano
In-Reply-To: <4E8EBAFE.8020805@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 07.10.2011 10:40:
> [readding JCH to cc whom you dropped]
> Robin H. Johnson venit, vidit, dixit 07.10.2011 00:24:
>> On Wed, Oct 05, 2011 at 05:56:55PM -0700, Junio C Hamano wrote:
>>> And this uses the gpg-interface.[ch] to allow signing the commit, i.e.
>>>
>>> $ git commit --gpg-sign -m foo
>>> You need a passphrase to unlock the secret key for
>>> user: "Junio C Hamano <gitster@pobox.com>"
>>> 4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
>>>
>>> [master 8457d13] foo
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>> I like it, but I have a couple of questions:
>> 1. Are the sig lines used in computed SHA1/commitid of a given commit (I
>> see examples w/ --amend and that would usually change the SHA1)?
>
> Yes, just like with tag objects.
>
>> 2. Can we allow more than one person sign a commit?
>
> I don't think we support it now (tags) but we could allow concatenating
> signatures since they are detached.
Quick update:
Sticking two signatures into a signed tag works perfectly with current
git, both signatures are verified and displayed.
So, it might make sense to have "commit --amend" append to an existing
signature.
> There's a somewhat delicate issue here: The signature (tag/commit) is a
> signature on the contents of the object, and is itself not part of the
> contents (or else we would have a chicken-egg-problem).
>
> The sha1 of the object is determined by the content+header, i.e.
> including the signature.
NB: "header" is the wrong term here, it's "data" I think.
> So, by adding a signature, you change the sha1, but any existing
> signature remains valid.
>
> This is also how you can try to achieve a specific sha1 for a given
> object content...
>
^ permalink raw reply
* Re: A Basic Git Question About File Tracking
From: Scott Chacon @ 2011-10-09 16:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jon Forrest, git, Jonathan Nieder
In-Reply-To: <m3ipnz0xri.fsf@localhost.localdomain>
Jon,
2011/10/8 Jakub Narebski <jnareb@gmail.com>:
>> This spoils my understanding of what the index
>> is. I had been thinking that after you add files
>> to the index, and then commit, the index is then
>> empty. In other words, whatever's in the index
>> gets committed, and then the index is cleaned.
>>
>> On the other hand, if the definition of a tracked
>> file is a file that's in the index, then this definitely
>> clears up my understanding of tracked files.
>>
>> If every file that's 'git add'ed stays in the
>> index, how does git know which files to commit?
It may help to read a blog post I put on the Pro Git blog called
"Reset Demystified" that talks about a simplified model of the HEAD,
index and working directory.
http://progit.org/2011/07/11/reset.html
Let me know if that helps. And you're right, the book should say "not
in the index" rather than "not be in the last commit", that would be
more technically correct. I think at that point in the book I have not
gone into any details about the index yet, so it would be confusing
without more detail.
thanks,
Scott
^ permalink raw reply
* Re: Check revision and if no files modified (looking for svnversion equivalent)
From: Jonathan Nieder @ 2011-10-09 18:10 UTC (permalink / raw)
To: fkater@googlemail.com; +Cc: git
In-Reply-To: <20111009162902.GA3000@comppasch2>
fkater@googlemail.com wrote:
> - get the last revision (e.g. r1001)
> - check for modified files not yet checked in (e.g. r1001 M)
"git describe --dirty", maybe. Thanks to Jean Privat for inventing
it.
> Both information is required for the application's build
> process (Makefiles):
>
> - to display the version in the application
> - to refuse to build a proper 'release' version if something
> was not checked in
Ok, this seems like two different needs.
- For the former, see GIT-VERSION-GEN in git.git for inspiration.
- For the latter, I'd recommend something like
git update-index -q --refresh &&
git diff-index --quiet HEAD ||
{
echo >&2 fail
exit 1
}
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH da/difftool-mergtool-refactor] Makefile: fix permissions of mergetools/ checked out with permissive umask
From: David Aguilar @ 2011-10-09 18:26 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, git@vger.kernel.org, Tanguy Ortolo,
Charles Bailey, SebastianSchuberth
In-Reply-To: <20111009114333.GA29829@elie.hsd1.il.comcast.net>
On Oct 9, 2011, at 4:43 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Jonathan Nieder wrote:
>
>> ---
> [...]
>> Since debian/rules install is run as root, the default is for tar to
>> act as thought --preserve-permissions were passed
>
> I should have said: "when 'make install' is run as root, ...".
>
> Typically people building git for private use would run "make install"
> as root when installing to /usr/local, but as an unprivileged user
> when installing to $HOME. The RPM packaging runs "make install"
> without special privileges and the Debian packaging runs it as (fake)
> root, iirc.
>
> Sorry for the lack of clarity.
thanks. I agree that the tar is overkill. I think I copied that snippet from templates/makefile. does that have the same bug?
--
David (mobile)
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Michael J Gruber @ 2011-10-09 20:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9f3pk8.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 06.10.2011 02:56:
> And this uses the gpg-interface.[ch] to allow signing the commit, i.e.
>
> $ git commit --gpg-sign -m foo
> You need a passphrase to unlock the secret key for
> user: "Junio C Hamano <gitster@pobox.com>"
> 4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
>
> [master 8457d13] foo
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> The lines of GPG detached signature are placed in new header lines, after
> the standard tree/parent/author/committer headers, instead of tucking the
> signature block at the end of the commit log message text (similar to how
> signed tag is done), for multiple reasons:
>
> - The signature won't clutter output from "git log" and friends if it is
> in the extra header. If we place it at the end of the log message, we
> would need to teach "git log" and friends to strip the signature block
> with an option.
>
> - Teaching new versions of "git log" and "gitk" to optionally verify and
> show signatures is cleaner if we structurally know where the signature
> block is (instead of scanning in the commit log message).
>
> - The signature needs to be stripped upon various commit rewriting
> operations, e.g. rebase, filter-branch, etc. They all already ignore
> unknown headers, but if we place signature in the log message, all of
> these tools (and third-party tools) also need to learn how a signature
> block would look like.
>
> - When we added the optional encoding header, all the tools (both in tree
> and third-party) that acts on the raw commit object should have been
> fixed to ignore headers they do not understand, so it is not like that
> new header would be more likely to break than extra text in the commit.
>
> A commit made with the above sample sequence would look like this:
>
> $ git cat-file commit HEAD
> tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
> parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
> author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
> committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
> sig -----BEGIN PGP SIGNATURE-----
> sig Version: GnuPG v1.4.10 (GNU/Linux)
> sig
> sig iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
> sig ...
> sig =dt98
> sig -----END PGP SIGNATURE-----
>
> foo
>
I just noticed that this format differs from the one of signed tags.
What special reason is there for the "sig " indentation?
BTW: commit --amend --gpg-sign strips an existing signature rather than
adding one. We might want the user to have a say here.
> but "git log" (unless you ask for it with --pretty=raw) output is not
> cluttered with the signature information.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> Cf.
> Message-ID: <7vfwjgui8s.fsf_-_@alter.siamese.dyndns.org>
> http://thread.gmane.org/gmane.comp.version-control.git/182297/focus=182384
>
> builtin/commit-tree.c | 24 +++++++++++++++++++++---
> builtin/commit.c | 12 ++++++++++--
> builtin/merge.c | 16 ++++++++++++++--
> commit.c | 41 ++++++++++++++++++++++++++++++++++++++++-
> commit.h | 2 +-
> notes-cache.c | 2 +-
> notes-merge.c | 2 +-
> 7 files changed, 88 insertions(+), 11 deletions(-)
>
> diff --git a/builtin/commit-tree.c b/builtin/commit-tree.c
> index d083795..a17811f 100644
> --- a/builtin/commit-tree.c
> +++ b/builtin/commit-tree.c
> @@ -8,8 +8,9 @@
> #include "tree.h"
> #include "builtin.h"
> #include "utf8.h"
> +#include "gpg-interface.h"
>
> -static const char commit_tree_usage[] = "git commit-tree <sha1> [(-p <sha1>)...] < changelog";
> +static const char commit_tree_usage[] = "git commit-tree [-S<signer>] <sha1> [(-p <sha1>)...] < changelog";
>
> static void new_parent(struct commit *parent, struct commit_list **parents_p)
> {
> @@ -25,6 +26,14 @@ static void new_parent(struct commit *parent, struct commit_list **parents_p)
> commit_list_insert(parent, parents_p);
> }
>
> +static int commit_tree_config(const char *var, const char *value, void *cb)
> +{
> + int status = git_gpg_config(var, value, NULL);
> + if (status)
> + return status;
> + return git_default_config(var, value, cb);
> +}
> +
> int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> {
> int i;
> @@ -32,11 +41,19 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> unsigned char tree_sha1[20];
> unsigned char commit_sha1[20];
> struct strbuf buffer = STRBUF_INIT;
> + const char *sign_commit = NULL;
>
> - git_config(git_default_config, NULL);
> + git_config(commit_tree_config, NULL);
>
> if (argc < 2 || !strcmp(argv[1], "-h"))
> usage(commit_tree_usage);
> +
> + if (!memcmp(argv[1], "-S", 2)) {
> + sign_commit = argv[1] + 2;
> + argv++;
> + argc--;
> + }
> +
> if (get_sha1(argv[1], tree_sha1))
> die("Not a valid object name %s", argv[1]);
>
> @@ -56,7 +73,8 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> if (strbuf_read(&buffer, 0, 0) < 0)
> die_errno("git commit-tree: failed to read");
>
> - if (commit_tree(buffer.buf, tree_sha1, parents, commit_sha1, NULL)) {
> + if (commit_tree(buffer.buf, tree_sha1, parents, commit_sha1,
> + NULL, sign_commit)) {
> strbuf_release(&buffer);
> return 1;
> }
> diff --git a/builtin/commit.c b/builtin/commit.c
> index cbc9613..90cf7e8 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -26,6 +26,7 @@
> #include "unpack-trees.h"
> #include "quote.h"
> #include "submodule.h"
> +#include "gpg-interface.h"
>
> static const char * const builtin_commit_usage[] = {
> "git commit [options] [--] <filepattern>...",
> @@ -85,6 +86,8 @@ static int all, edit_flag, also, interactive, patch_interactive, only, amend, si
> static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
> static int no_post_rewrite, allow_empty_message;
> static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
> +static char *sign_commit;
> +
> /*
> * The default commit message cleanup mode will remove the lines
> * beginning with # (shell comments) and leading and trailing
> @@ -144,6 +147,8 @@ static struct option builtin_commit_options[] = {
> OPT_BOOLEAN('e', "edit", &edit_flag, "force edit of commit"),
> OPT_STRING(0, "cleanup", &cleanup_arg, "default", "how to strip spaces and #comments from message"),
> OPT_BOOLEAN(0, "status", &include_status, "include status in commit message template"),
> + { OPTION_STRING, 'S', "gpg-sign", &sign_commit, "key id",
> + "GPG sign commit", PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
> /* end commit message options */
>
> OPT_GROUP("Commit contents options"),
> @@ -1323,6 +1328,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1,
> static int git_commit_config(const char *k, const char *v, void *cb)
> {
> struct wt_status *s = cb;
> + int status;
>
> if (!strcmp(k, "commit.template"))
> return git_config_pathname(&template_file, k, v);
> @@ -1330,7 +1336,9 @@ static int git_commit_config(const char *k, const char *v, void *cb)
> include_status = git_config_bool(k, v);
> return 0;
> }
> -
> + status = git_gpg_config(k, v, NULL);
> + if (status)
> + return status;
> return git_status_config(k, v, s);
> }
>
> @@ -1481,7 +1489,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> }
>
> if (commit_tree(sb.buf, active_cache_tree->sha1, parents, sha1,
> - author_ident.buf)) {
> + author_ident.buf, sign_commit)) {
> rollback_index_files();
> die(_("failed to write commit object"));
> }
> diff --git a/builtin/merge.c b/builtin/merge.c
> index ab4077f..53cff02 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -26,6 +26,7 @@
> #include "merge-recursive.h"
> #include "resolve-undo.h"
> #include "remote.h"
> +#include "gpg-interface.h"
>
> #define DEFAULT_TWOHEAD (1<<0)
> #define DEFAULT_OCTOPUS (1<<1)
> @@ -63,6 +64,7 @@ static int allow_rerere_auto;
> static int abort_current_merge;
> static int show_progress = -1;
> static int default_to_upstream;
> +static const char *sign_commit;
>
> static struct strategy all_strategy[] = {
> { "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
> @@ -206,6 +208,8 @@ static struct option builtin_merge_options[] = {
> OPT_BOOLEAN(0, "abort", &abort_current_merge,
> "abort the current in-progress merge"),
> OPT_SET_INT(0, "progress", &show_progress, "force progress reporting", 1),
> + { OPTION_STRING, 'S', "gpg-sign", &sign_commit, "key id",
> + "GPG sign commit", PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
> OPT_END()
> };
>
> @@ -525,6 +529,8 @@ static void parse_branch_merge_options(char *bmo)
>
> static int git_merge_config(const char *k, const char *v, void *cb)
> {
> + int status;
> +
> if (branch && !prefixcmp(k, "branch.") &&
> !prefixcmp(k + 7, branch) &&
> !strcmp(k + 7 + strlen(branch), ".mergeoptions")) {
> @@ -562,6 +568,10 @@ static int git_merge_config(const char *k, const char *v, void *cb)
> default_to_upstream = git_config_bool(k, v);
> return 0;
> }
> +
> + status = git_gpg_config(k, v, NULL);
> + if (status)
> + return status;
> return git_diff_ui_config(k, v, cb);
> }
>
> @@ -870,7 +880,8 @@ static int merge_trivial(void)
> parent->next->item = remoteheads->item;
> parent->next->next = NULL;
> run_prepare_commit_msg();
> - commit_tree(merge_msg.buf, result_tree, parent, result_commit, NULL);
> + commit_tree(merge_msg.buf, result_tree, parent, result_commit, NULL,
> + sign_commit);
> finish(result_commit, "In-index merge");
> drop_save();
> return 0;
> @@ -900,7 +911,8 @@ static int finish_automerge(struct commit_list *common,
> free_commit_list(remoteheads);
> strbuf_addch(&merge_msg, '\n');
> run_prepare_commit_msg();
> - commit_tree(merge_msg.buf, result_tree, parents, result_commit, NULL);
> + commit_tree(merge_msg.buf, result_tree, parents, result_commit,
> + NULL, sign_commit);
> strbuf_addf(&buf, "Merge made by the '%s' strategy.", wt_strategy);
> finish(result_commit, buf.buf);
> strbuf_release(&buf);
> diff --git a/commit.c b/commit.c
> index 97b4327..969435d 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -6,6 +6,7 @@
> #include "diff.h"
> #include "revision.h"
> #include "notes.h"
> +#include "gpg-interface.h"
>
> int save_commit_buffer = 1;
>
> @@ -814,6 +815,41 @@ struct commit_list *reduce_heads(struct commit_list *heads)
> return result;
> }
>
> +static int do_sign_commit(struct strbuf *buf, const char *keyid)
> +{
> + struct strbuf sig = STRBUF_INIT;
> + int inspos, copypos;
> + const char gpg_sig[] = "sig ";
> + const int header_len = sizeof(gpg_sig) - 1;
> +
> + /* find the end of the header */
> + inspos = strstr(buf->buf, "\n\n") - buf->buf + 1;
> + copypos = buf->len;
> +
> + strbuf_addbuf(&sig, buf);
> +
> + if (!keyid || !*keyid)
> + keyid = get_signing_key();
> + if (sign_buffer(&sig, keyid)) {
> + strbuf_release(&sig);
> + return -1;
> + }
> +
> + while (sig.buf[copypos]) {
> + const char *bol = sig.buf + copypos;
> + const char *eol = strchrnul(bol, '\n');
> + int len = (eol - bol) + !!*eol;
> + strbuf_insert(buf, inspos, gpg_sig, header_len);
> + inspos += header_len;
> + strbuf_insert(buf, inspos, bol, len);
> + inspos += len;
> + copypos += len;
> + }
> + strbuf_release(&sig);
> + return 0;
> +}
> +
> +
> static const char commit_utf8_warn[] =
> "Warning: commit message does not conform to UTF-8.\n"
> "You may want to amend it after fixing the message, or set the config\n"
> @@ -821,7 +857,7 @@ static const char commit_utf8_warn[] =
>
> int commit_tree(const char *msg, unsigned char *tree,
> struct commit_list *parents, unsigned char *ret,
> - const char *author)
> + const char *author, const char *sign_commit)
> {
> int result;
> int encoding_is_utf8;
> @@ -864,6 +900,9 @@ int commit_tree(const char *msg, unsigned char *tree,
> if (encoding_is_utf8 && !is_utf8(buffer.buf))
> fprintf(stderr, commit_utf8_warn);
>
> + if (sign_commit && do_sign_commit(&buffer, sign_commit))
> + return -1;
> +
> result = write_sha1_file(buffer.buf, buffer.len, commit_type, ret);
> strbuf_release(&buffer);
> return result;
> diff --git a/commit.h b/commit.h
> index 12d100b8..8c2419b 100644
> --- a/commit.h
> +++ b/commit.h
> @@ -175,6 +175,6 @@ struct commit_list *reduce_heads(struct commit_list *heads);
>
> extern int commit_tree(const char *msg, unsigned char *tree,
> struct commit_list *parents, unsigned char *ret,
> - const char *author);
> + const char *author, const char *sign_commit);
>
> #endif /* COMMIT_H */
> diff --git a/notes-cache.c b/notes-cache.c
> index 4c8984e..c36a960 100644
> --- a/notes-cache.c
> +++ b/notes-cache.c
> @@ -56,7 +56,7 @@ int notes_cache_write(struct notes_cache *c)
>
> if (write_notes_tree(&c->tree, tree_sha1))
> return -1;
> - if (commit_tree(c->validity, tree_sha1, NULL, commit_sha1, NULL) < 0)
> + if (commit_tree(c->validity, tree_sha1, NULL, commit_sha1, NULL, NULL) < 0)
> return -1;
> if (update_ref("update notes cache", c->tree.ref, commit_sha1, NULL,
> 0, QUIET_ON_ERR) < 0)
> diff --git a/notes-merge.c b/notes-merge.c
> index e1aaf43..c29c434 100644
> --- a/notes-merge.c
> +++ b/notes-merge.c
> @@ -546,7 +546,7 @@ void create_notes_commit(struct notes_tree *t, struct commit_list *parents,
> /* else: t->ref points to nothing, assume root/orphan commit */
> }
>
> - if (commit_tree(msg, tree_sha1, parents, result_sha1, NULL))
> + if (commit_tree(msg, tree_sha1, parents, result_sha1, NULL, NULL))
> die("Failed to commit notes tree to database");
> }
>
^ permalink raw reply
* Re: [PATCH 6/6] Retain caches of submodule refs
From: Junio C Hamano @ 2011-10-09 20:10 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt
In-Reply-To: <4E918194.5060102@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> So I think I need help from a submodule guru (Heiko?) who can tell me
> what is done with submodule references and whether they might be
> modified while a git process is executing in the main module. If so,
> then either this patch has to be withdrawn, or more work has to be put
> in to make such code invalidate the submodule reference cache.
>
> Sorry for the oversight, but I forgot that not all code necessarily uses
> the refs.c API when dealing with references (a regrettable situation, BTW).
In the longer term, I would agree with you that we very much prefer all
the ref accesses to go through the refs API, and I also foresee that the
submodule support would need to become more aware of the status of refs in
checked out submodules. For example, a recursive "submodule update" may
want to inspect the refs in a submodule directory, compare them with the
commit bound in the superproject tree for the submodule path, and decide
to spawn a "fetch && checkout $branch" in there. The same process then may
want to run "status" at the superproject level to show the result, which
in turn would inspect the relationship between the commit bound in the
superproject tree and the commit at the HEAD of the submodule directory.
So let's not rip out the commit but instead give submodule machinery an
explicit way to say "We do not know the current status of the refs in this
submodule anymore".
Thanks.
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Junio C Hamano @ 2011-10-09 21:22 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E91FD57.7050808@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I just noticed that this format differs from the one of signed tags.
> What special reason is there for the "sig " indentation?
Read the part of the message you are quoting.
^ permalink raw reply
* Re: [PATCH 1/3] traverse_trees(): allow pruning with pathspec
From: Nguyen Thai Ngoc Duy @ 2011-10-09 21:35 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <4E91C031.9030205@alum.mit.edu>
On Mon, Oct 10, 2011 at 2:39 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 08/29/2011 11:33 PM, Junio C Hamano wrote:
>> diff --git a/tree-walk.c b/tree-walk.c
>> index 33f749e..808bb55 100644
>> --- a/tree-walk.c
>> +++ b/tree-walk.c
>> [...]
>> @@ -376,16 +396,22 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
>> mask |= 1ul << i;
>> if (S_ISDIR(entry[i].mode))
>> dirmask |= 1ul << i;
>> + e = &entry[i];
>> }
>> if (!mask)
>> break;
>> - ret = info->fn(n, mask, dirmask, entry, info);
>> - if (ret < 0) {
>> - error = ret;
>> - if (!info->show_all_errors)
>> - break;
>> + interesting = prune_traversal(e, info, &base, interesting);
>
> According to gcc 4.2.4 (though, strangely, not gcc 4.4.3):
>
> tree-walk.c: In function ‘traverse_trees’:
> tree-walk.c:347: warning: ‘e’ may be used uninitialized in this function
False alarm. If e is not initialized in the for loop, mask would be
zero and therefore prune_traversal(e, info, &base, interesting), which
would use uninitialized "e", would never be called.
--
Duy
^ permalink raw reply
* Re: [PATCH da/difftool-mergtool-refactor] Makefile: fix permissions of mergetools/ checked out with permissive umask
From: Jonathan Nieder @ 2011-10-09 21:47 UTC (permalink / raw)
To: David Aguilar
Cc: Junio C Hamano, git@vger.kernel.org, Tanguy Ortolo,
Charles Bailey, SebastianSchuberth
In-Reply-To: <1C9F1683-4C6E-4D49-86D3-3A47B2843F23@gmail.com>
David Aguilar wrote:
> thanks. I agree that the tar is overkill. I think I copied that
> snippet from templates/makefile. does that have the same bug?
It did have a similar bug before, but it was fixed (in a different
way) by v1.6.0.3~81^2 (Fix permission bits on sources checked out with
an overtight umask, 2008-08-21). The main difference from the
mergetools/ case is that the blt/ directory is populated at build
time.
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Junio C Hamano @ 2011-10-09 22:27 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E91FD57.7050808@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> BTW: commit --amend --gpg-sign strips an existing signature rather than
> adding one. We might want the user to have a say here.
I think it deserves a separate command (commit --add-gpg-sign) that is
used _only_ to add an additional signature by another person without
affecting anything else in the commit (i.e. the tree, the parents and the
author and committership information) from the viewpoint of the workflow,
Obviously that "add-signature" mode needs to be aware of the existing
signature. It is a deliberate design decision to strip existing signature
when anything in the commit changes, which is the norm for --amend.
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Robin H. Johnson @ 2011-10-09 22:57 UTC (permalink / raw)
To: Michael J Gruber, Git Mailing List; +Cc: Robin H. Johnson, Junio C Hamano
In-Reply-To: <4E8EBAFE.8020805@drmicha.warpmail.net>
On Fri, Oct 07, 2011 at 10:40:30AM +0200, Michael J Gruber wrote:
> [readding JCH to cc whom you dropped]
> Robin H. Johnson venit, vidit, dixit 07.10.2011 00:24:
> > On Wed, Oct 05, 2011 at 05:56:55PM -0700, Junio C Hamano wrote:
> >> And this uses the gpg-interface.[ch] to allow signing the commit, i.e.
> >>
> >> $ git commit --gpg-sign -m foo
> >> You need a passphrase to unlock the secret key for
> >> user: "Junio C Hamano <gitster@pobox.com>"
> >> 4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
> >>
> >> [master 8457d13] foo
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> > I like it, but I have a couple of questions:
> > 1. Are the sig lines used in computed SHA1/commitid of a given commit (I
> > see examples w/ --amend and that would usually change the SHA1)?
> Yes, just like with tag objects.
Ok, at the core, this is going to pose a problem with multiple
signatures.
Workflow example:
1. Dev1 creates a commit, signs it, pushes to central repo.
2. Dev2 pulls, signs the tip commit, pushes it back.
Since signing model here actually alters the commit, the push by Dev2
loses the history point of a commit with only a single signature, like
if somebody pushes a rewritten history (which should usually be
prohibited).
The push certificate variant of signing does permit this case without
breaking history.
> > I think this isn't a replacement for push certificates, but has value in
> > itself. It's certainly provides better integration than the
> > signature-in-note variants.
> >
>
> I do think it's meant as an implementation of push certificates. I don't
> see any other value in it which could not be achieved by signed tags.
> Can you describe any?
Identify of the committer for verification.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Junio C Hamano @ 2011-10-09 23:18 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Michael J Gruber, Git Mailing List, Junio C Hamano
In-Reply-To: <robbat2-20111009T225253-591026811Z@orbis-terrarum.net>
"Robin H. Johnson" <robbat2@gentoo.org> writes:
> Workflow example:
> 1. Dev1 creates a commit, signs it, pushes to central repo.
> 2. Dev2 pulls, signs the tip commit, pushes it back.
I personally am not sympathetic to such a "sign every and all commits by
multiple people" workflow. If you really want to do such a thing, you can
have the second and subsequent one to create a new commit on top whose
sole purpose is to hold such a signature (commit --allow-empty --gpg-sig),
or use signed tags.
^ permalink raw reply
* Re: Recovering Committed Changes in a Detached Head?
From: Junio C Hamano @ 2011-10-09 23:22 UTC (permalink / raw)
To: Martin Fick; +Cc: SZEDER Gábor, Daly Gutierrez, git
In-Reply-To: <ab706826-75df-4410-941e-6b40ec92713c@email.android.com>
Martin Fick <mfick@codeaurora.org> writes:
> While rflog is cool,...
>
> First, maybe git could create refs for these automatically, perhaps with a name like orphans/1? Maybe these refs would only be visible via git branch --orphans.
Instead of spelling them orphans/$n, you already have @{$n}.
^ 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