* Re: [BUG] incorrect search result returned when using git log with a future date parameter
From: Junio C Hamano @ 2013-01-30 22:22 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Caspar Zhang, git, Gris Ge
In-Reply-To: <20130130221544.GA15680@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> When it is fed 2013-02-12, it is ambiguous and "approxidate" can and
>> should use whatever heuristics (including rejection of future) to
>> guess what the user wanted, but 2013-02-13 cannot be interpreted in
>> any other way, so we should parse it as such.
>
> FWIW, if you said 02/12/2013, I'd agree, but I've never seen someone
> using 2013-02-12 to mean December 2.
>
> So that suggests another possible tweak on top. :)
I think in the original context that triggered the "be more friendly
to Europeans" discussion long time ago, some correlations between
the delimiting characters (i.e. 'xxxx-xx-xx' vs 'xxxx.xx.xx' vs
'xxxx/xx/xx') and month-day ordering convention. I do not recall if
we actually added that as a signal when disambiguating, though.
^ permalink raw reply
* Re: Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
From: Heiko Voigt @ 2013-01-30 22:49 UTC (permalink / raw)
To: Michael Sims; +Cc: git, Jens Lehmann, Junio C Hamano, Martin von Zweigbergk
In-Reply-To: <20130130215615.GA1053@book.hvoigt.net>
Hi,
On Wed, Jan 30, 2013 at 10:56:15PM +0100, Heiko Voigt wrote:
> On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote:
> > I'm seeing what might be a bug that was introduced in git 1.7.12 (also
> > observed in 1.8.1.2). If not a bug, it's a changed behavior from
> > previous versions that I don't understand.
> >
> > Here's the scenario:
> > * I have a remote repo containing a pointer to a submodule.
> > * Developer A and Developer B clone this repo, and both make a commit
> > to first the submodule, and then the parent repo, changing some files
> > and also the submodule pointer at the same time.
> > * Developer A pushes his changes to both the submodule and the parent
> > module to the shared remote
> > * Developer B either does a "git pull --rebase" or a "git fetch && git
> > rebase origin/master"
>
> Thanks for the detailed bug report and the demo script. I can reproduce
> the behavior here and will have a look into it. The submodule should be
> marked as conflict.
Bisect identified the following commit:
commit a230949409f4a650c6a1a9a5879e2a8b993ba695 (HEAD)
Author: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Tue Jun 26 07:51:56 2012 -0700
am --rebasing: get patch body from commit, not from mailbox
Rebasing a commit that contains a diff in the commit message results
in a failure with output such as
First, rewinding head to replay your work on top of it...
Applying: My cool patch.
fatal: sha1 information is lacking or useless
(app/controllers/settings_controller.rb).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 My cool patch.
The reason is that 'git rebase' without -p/-i/-m internally calls 'git
format-patch' and pipes the output to 'git am --rebasing', which has
no way of knowing what is a real patch and what is a commit message
that contains a patch.
Make 'git am' while in --rebasing mode get the patch body from the
commit object instead of extracting it from the mailbox.
Patch by Junio, test case and commit log message by Martin.
Reported-by: anikey <arty.anikey@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Maybe Martin or Junio immediately see whats going wrong here? I would
need to further dig into the git-am code to find out how to fix it.
Cheers Heiko
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Sitaram Chamarty @ 2013-01-30 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Max Horn, John Keeping, git, Scott Chacon
In-Reply-To: <7vlibalhcv.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 09:18:24AM -0800, Junio C Hamano wrote:
> Max Horn <max@quendi.de> writes:
>
> [administrivia: please wrap lines to a reasonable width]
Curiously, gmail's web interface appears to have started doing
this only recently. I've noticed it when trying to respond to
others too.
> > On 30.01.2013, at 16:59, Sitaram Chamarty wrote:
> >
> >> I'm curious... what's wrong with 'git checkout html' from the git repo
> >> and just browsing them using a web browser?
> >
> > Hm, do you mean "make html", perhaps? At least I couldn't figure
> > out what "git checkout html" should do, but out of curiosity gave
> > it a try and got an error...
>
> Perhaps some information from "A note from the maintainer" (posted
> to this list from time to time) is lacking. Some excerpts:
>
> You can browse the HTML manual pages at:
>
> http://git-htmldocs.googlecode.com/git/git.html
>
> Preformatted documentation from the tip of the "master" branch can be
> found in:
>
> git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
> git://repo.or.cz/git-{htmldocs,manpages}.git/
> ...
>
>
> Armed with that knowledge, I think Sitaram may have something like
> this:
>
> [remote "htmldocs"]
> url = git://git.kernel.org/pub/scm/git/git-htmldocs.git/
> fetch = +refs/heads/master:refs/heads/html
>
> and does
>
> git fetch htmldocs
> git checkout html
Hmm; I don't recall ever doing that. But I just realised that
my "html" branch is stuck at 1.7.7:
$ git branch -v -v | grep html
html 8fb66e5 [origin/html] Autogenerated HTML docs for v1.7.7-138-g7f41b6
Is it possible that upto that point, the main git.git repo did
carry this branch also? I have 3 remotes:
$ git remote -v
gc https://code.google.com/p/git-core (fetch)
gc https://code.google.com/p/git-core (push)
ghgit git://github.com/git/git.git (fetch)
ghgit git://github.com/git/git.git (push)
origin git://git.kernel.org/pub/scm/git/git.git (fetch)
origin git://git.kernel.org/pub/scm/git/git.git (push)
and all 3 of them carry this branch:
$ git branch -a -v -v | grep html
html 8fb66e5 [origin/html] Autogenerated HTML docs for v1.7.7-138-g7f41b6
remotes/gc/html 8fb66e5 Autogenerated HTML docs for v1.7.7-138-g7f41b6
remotes/ghgit/html 8fb66e5 Autogenerated HTML docs for v1.7.7-138-g7f41b6
remotes/origin/html 8fb66e5 Autogenerated HTML docs for v1.7.7-138-g7f41b6
Even if I had, at one point, added a remote specifically for
html, I am sure it could not have created those refs!
So I tried a prune:
$ git remote update --prune
Fetching origin
x [deleted] (none) -> origin/html
x [deleted] (none) -> origin/man
Fetching ghgit
x [deleted] (none) -> ghgit/html
x [deleted] (none) -> ghgit/man
Fetching gc
x [deleted] (none) -> gc/html
x [deleted] (none) -> gc/man
and now I'm on par with the rest of you ;-)
> You can, too, of course ;-)
You can do even more! If you don't find a suitable website for
this, it's trivial to host it yourself. You can host it on your
intranet, if you have one.
^ permalink raw reply
* Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
From: Junio C Hamano @ 2013-01-30 23:39 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Michael Sims, git, Jens Lehmann, Martin von Zweigbergk
In-Reply-To: <20130130224904.GB1053@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> Maybe Martin or Junio immediately see whats going wrong here? I would
> need to further dig into the git-am code to find out how to fix it.
"am -3" has never worked on a patch that describes changes to any
non-blobs; the underlyihng "apply --fake-ancestor" is not prepared
to see anything other than blobs.
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Jonathan Nieder @ 2013-01-31 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bryan Turner, git, Andrej E Baranov
In-Reply-To: <7va9rrq1o3.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Odd. "https://www.gravatar.com/" also seems to work. I've put in a
>> technical support query to find out what the Gravatar admins prefer.
>
> Thanks; will hold onto Andrej's patch until we hear what the story
> is.
Good news: a kind person from Automattic answered that
www.gravatar.com should work fine over SSL, both now and in the
future, and promised to add updating documentation to their todo list.
Thanks for your help and patience.
Jonathan
^ permalink raw reply
* Segmentation fault with latest git (070c57df)
From: Jongman Heo @ 2013-01-31 1:35 UTC (permalink / raw)
To: git
Hi all,
Looks like following commit causes a segmentation fault in my machine (when running git pull or git fetch);
commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jan 7 12:24:55 2013 -0800
string-list: allow case-insensitive string list
In my case, list->cmp (at get_entry_index() function) has an invalid address, obviously not an address of string comparision function, instead it points to 1.
Regards,
Jongman Heo.
^ permalink raw reply
* [PATCH 0/3] GPG running out of pipes fixes
From: Stephen Boyd @ 2013-01-31 2:01 UTC (permalink / raw)
To: git
While running --show-signatures on the linux kernel I noticed that after
a while git failed with an error message indicating it had run out of
file descriptors. The first patch fixes this problem, and the next
two are randmom bits since I was in the area.
Stephen Boyd (3):
gpg: Close stderr once finished with it in verify_signed_buffer()
run-command: Be more informative about what failed
gpg: Allow translation of more error messages
gpg-interface.c | 8 +++++---
run-command.c | 8 ++++++--
2 files changed, 11 insertions(+), 5 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
From: Stephen Boyd @ 2013-01-31 2:01 UTC (permalink / raw)
To: git
In-Reply-To: <1359597666-10108-1-git-send-email-sboyd@codeaurora.org>
Failing to close the stderr pipe in verify_signed_buffer() causes
git to run out of file descriptors if there are many calls to
verify_signed_buffer(). An easy way to trigger this is to run
git log --show-signature --merges | grep "key"
on the linux kernel git repo. Eventually it will fail with
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
Close the stderr pipe so that this can't happen.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
gpg-interface.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gpg-interface.c b/gpg-interface.c
index 0863c61..2c0bed3 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -133,6 +133,8 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
if (gpg_output)
strbuf_read(gpg_output, gpg.err, 0);
ret = finish_command(&gpg);
+ if (gpg_output)
+ close(gpg.err);
unlink_or_warn(path);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 3/3] gpg: Allow translation of more error messages
From: Stephen Boyd @ 2013-01-31 2:01 UTC (permalink / raw)
To: git
In-Reply-To: <1359597666-10108-1-git-send-email-sboyd@codeaurora.org>
Mark these strings for translation so that error messages are
printed in the user's language of choice.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
gpg-interface.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gpg-interface.c b/gpg-interface.c
index 2c0bed3..474c037 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -109,10 +109,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
args_gpg[0] = gpg_program;
fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
if (fd < 0)
- return error("could not create temporary file '%s': %s",
+ return error(_("could not create temporary file '%s': %s"),
path, strerror(errno));
if (write_in_full(fd, signature, signature_size) < 0)
- return error("failed writing detached signature to '%s': %s",
+ return error(_("failed writing detached signature to '%s': %s"),
path, strerror(errno));
close(fd);
@@ -124,7 +124,7 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
args_gpg[2] = path;
if (start_command(&gpg)) {
unlink(path);
- return error("could not run gpg.");
+ return error(_("could not run gpg."));
}
write_in_full(gpg.in, payload, payload_size);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 2/3] run-command: Be more informative about what failed
From: Stephen Boyd @ 2013-01-31 2:01 UTC (permalink / raw)
To: git
In-Reply-To: <1359597666-10108-1-git-send-email-sboyd@codeaurora.org>
While debugging an error with verify_signed_buffer() the error
messages from run-command weren't very useful:
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
because they didn't indicate *which* pipe couldn't be created.
Print which pipe failed to be created in the error message so we
can more easily debug similar problems in the future.
For example, the above error now prints:
error: cannot create stderr pipe for gpg: Too many open files
error: could not run gpg.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
run-command.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/run-command.c b/run-command.c
index 12d4ddb..016dd05 100644
--- a/run-command.c
+++ b/run-command.c
@@ -274,6 +274,7 @@ int start_command(struct child_process *cmd)
int need_in, need_out, need_err;
int fdin[2], fdout[2], fderr[2];
int failed_errno = failed_errno;
+ char *str;
/*
* In case of errors we must keep the promise to close FDs
@@ -286,6 +287,7 @@ int start_command(struct child_process *cmd)
failed_errno = errno;
if (cmd->out > 0)
close(cmd->out);
+ str = "stdin";
goto fail_pipe;
}
cmd->in = fdin[1];
@@ -301,6 +303,7 @@ int start_command(struct child_process *cmd)
close_pair(fdin);
else if (cmd->in)
close(cmd->in);
+ str = "stdout";
goto fail_pipe;
}
cmd->out = fdout[0];
@@ -318,9 +321,10 @@ int start_command(struct child_process *cmd)
close_pair(fdout);
else if (cmd->out)
close(cmd->out);
+ str = "stderr";
fail_pipe:
- error("cannot create pipe for %s: %s",
- cmd->argv[0], strerror(failed_errno));
+ error("cannot create %s pipe for %s: %s",
+ str, cmd->argv[0], strerror(failed_errno));
errno = failed_errno;
return -1;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 0/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: TJ @ 2013-01-31 2:08 UTC (permalink / raw)
To: git
During a build/install cycle of the current HEAD whilst attempting to identify the cause of a bug in
git version 1.8.0.3 whilst doing:
GIT_CURL_VERBOSE=1 git clone -v https://git01.codeplex.com/typescript
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
I hit a local install failure whilst installing to the prefix /usr/local/ where the $(INSTALL)
command reported a Permission Denied error.
This was due to the $(INSTALL) modes being 755/644 but the file-system modes being 775/664.
In this case ownership and permissions are:
$ ls -ald /usr/local
drwxrwxr-x 13 root adm 4096 Sep 26 04:16 /usr/local
Users belonging to the 'adm' group have permission to install local packages.
The fix I've implemented is to convert the hard-coded 755/644 modes to variables which can
be over-ridden on the make command-line if necessary.
^ permalink raw reply
* [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: TJ @ 2013-01-31 2:08 UTC (permalink / raw)
To: git
Installation would fail if the target location had anything other than 755/644
file permissions. Therefore replace the hard-coded modes for each $(INSTALL)
with variables.
Default values are 755/644 but can be over-ridden on the make command line
e.g. "make INSTALL_MODE_EXECUTABLE=755 INSTALL_MODE_DATA=644 install".
Signed-off-by: TJ <git@iam.tj>
---
Documentation/Makefile | 20 ++++++++++----------
Makefile | 17 +++++++++++------
contrib/emacs/Makefile | 2 +-
contrib/subtree/Makefile | 4 ++--
git-gui/Makefile | 12 ++++++------
gitk-git/Makefile | 6 +++---
gitweb/Makefile | 8 ++++----
templates/Makefile | 2 +-
8 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 971977b..913928c 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -190,16 +190,16 @@ pdf: user-manual.pdf
install: install-man
install-man: man
- $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
- $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
- $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
- $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
- $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
- $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man1dir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man5dir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man7dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN1) $(DESTDIR)$(man1dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN5) $(DESTDIR)$(man5dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN7) $(DESTDIR)$(man7dir)
install-info: info
- $(INSTALL) -d -m 755 $(DESTDIR)$(infodir)
- $(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(infodir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) git.info gitman.info $(DESTDIR)$(infodir)
if test -r $(DESTDIR)$(infodir)/dir; then \
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\
@@ -208,8 +208,8 @@ install-info: info
fi
install-pdf: pdf
- $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir)
- $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(pdfdir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) user-manual.pdf $(DESTDIR)$(pdfdir)
install-html: html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir)
diff --git a/Makefile b/Makefile
index 731b6a8..7a59202 100644
--- a/Makefile
+++ b/Makefile
@@ -354,6 +354,11 @@ ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
+# default installation file modes. Can be overridden from the 'make' command-line.
+# E.g. For allowing group write: "make INSTALL_MODE_EXECUTABLE=775 install"
+INSTALL_MODE_EXECUTABLE = 755
+INSTALL_MODE_DATA = 644
+
# Among the variables below, these:
# gitexecdir
# template_dir
@@ -2257,16 +2262,16 @@ mergetools_instdir_SQ = $(subst ','\'',$(mergetools_instdir))
install_bindir_programs := $(patsubst %,%$X,$(BINDIR_PROGRAMS_NEED_X)) $(BINDIR_PROGRAMS_NO_X)
install: all
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
- $(INSTALL) -m 644 $(SCRIPT_LIB) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(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)'
- $(INSTALL) -m 644 mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
+ $(INSTALL) -m $(INSTALL_MODE_DATA) mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
ifndef NO_GETTEXT
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(localedir_SQ)'
(cd po/build/locale && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) xof -)
endif
diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
index 24d9312..a405744 100644
--- a/contrib/emacs/Makefile
+++ b/contrib/emacs/Makefile
@@ -4,7 +4,7 @@ EMACS = emacs
ELC = git.elc git-blame.elc
INSTALL ?= install
-INSTALL_ELC = $(INSTALL) -m 644
+INSTALL_ELC = $(INSTALL) -m $(INSTALL_MODE_DATA)
prefix ?= $(HOME)
emacsdir = $(prefix)/share/emacs/site-lisp
RM ?= rm -f
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 05cdd5c..40d8d2f 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -30,12 +30,12 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH)
doc: $(GIT_SUBTREE_DOC)
install: $(GIT_SUBTREE)
- $(INSTALL) -m 755 $(GIT_SUBTREE) $(libexecdir)
+ $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) $(GIT_SUBTREE) $(libexecdir)
install-doc: install-man
install-man: $(GIT_SUBTREE_DOC)
- $(INSTALL) -m 644 $^ $(man1dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $^ $(man1dir)
$(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
xmlto -m $(MANPAGE_NORMAL_XSL) man $^
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e22ba5c..472a10c 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -48,11 +48,11 @@ endif
RM_RF ?= rm -rf
RMDIR ?= rmdir
-INSTALL_D0 = $(INSTALL) -d -m 755 # space is required here
+INSTALL_D0 = $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) # space is required here
INSTALL_D1 =
-INSTALL_R0 = $(INSTALL) -m 644 # space is required here
+INSTALL_R0 = $(INSTALL) -m $(INSTALL_MODE_DATA) # space is required here
INSTALL_R1 =
-INSTALL_X0 = $(INSTALL) -m 755 # space is required here
+INSTALL_X0 = $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) # space is required here
INSTALL_X1 =
INSTALL_A0 = find # space is required here
INSTALL_A1 = | cpio -pud
@@ -76,11 +76,11 @@ ifndef V
QUIET_2DEVNULL = 2>/dev/null
INSTALL_D0 = dir=
- INSTALL_D1 = && echo ' ' DEST $$dir && $(INSTALL) -d -m 755 "$$dir"
+ INSTALL_D1 = && echo ' ' DEST $$dir && $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) "$$dir"
INSTALL_R0 = src=
- INSTALL_R1 = && echo ' ' INSTALL 644 `basename $$src` && $(INSTALL) -m 644 $$src
+ INSTALL_R1 = && echo ' ' INSTALL $(INSTALL_MODE_DATA) `basename $$src` && $(INSTALL) -m $(INSTALL_MODE_DATA) $$src
INSTALL_X0 = src=
- INSTALL_X1 = && echo ' ' INSTALL 755 `basename $$src` && $(INSTALL) -m 755 $$src
+ INSTALL_X1 = && echo ' ' INSTALL $(INSTALL_MODE_EXECUTABLE) `basename $$src` && $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) $$src
INSTALL_A0 = src=
INSTALL_A1 = && echo ' ' INSTALL ' ' `basename "$$src"` && find "$$src" | cpio -pud
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..bc18cce 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -40,9 +40,9 @@ endif
all:: gitk-wish $(ALL_MSGFILES)
install:: all
- $(INSTALL) -m 755 gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(msgsdir_SQ)'
- $(foreach p,$(ALL_MSGFILES), $(INSTALL) -m 644 $p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
+ $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(msgsdir_SQ)'
+ $(foreach p,$(ALL_MSGFILES), $(INSTALL) -m $(INSTALL_MODE_DATA) $p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
diff --git a/gitweb/Makefile b/gitweb/Makefile
index cd194d0..7d760b0 100644
--- a/gitweb/Makefile
+++ b/gitweb/Makefile
@@ -179,10 +179,10 @@ test-installed:
### Installation rules
install: all
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitwebdir_SQ)'
- $(INSTALL) -m 755 $(GITWEB_PROGRAMS) '$(DESTDIR_SQ)$(gitwebdir_SQ)'
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitwebstaticdir_SQ)'
- $(INSTALL) -m 644 $(GITWEB_FILES) '$(DESTDIR_SQ)$(gitwebstaticdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(gitwebdir_SQ)'
+ $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) $(GITWEB_PROGRAMS) '$(DESTDIR_SQ)$(gitwebdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(gitwebstaticdir_SQ)'
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(GITWEB_FILES) '$(DESTDIR_SQ)$(gitwebstaticdir_SQ)'
### Cleaning rules
diff --git a/templates/Makefile b/templates/Makefile
index d22a71a..3e7c7d2 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -61,6 +61,6 @@ clean:
$(RM) -r blt boilerplates.made
install: all
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
--
1.8.1.2.432.g070c57d.dirty
^ permalink raw reply related
* Re: [PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
From: Jeff King @ 2013-01-31 5:50 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1359597666-10108-2-git-send-email-sboyd@codeaurora.org>
On Wed, Jan 30, 2013 at 06:01:04PM -0800, Stephen Boyd wrote:
> Failing to close the stderr pipe in verify_signed_buffer() causes
> git to run out of file descriptors if there are many calls to
> verify_signed_buffer(). An easy way to trigger this is to run
>
> git log --show-signature --merges | grep "key"
>
> on the linux kernel git repo. Eventually it will fail with
>
> error: cannot create pipe for gpg: Too many open files
> error: could not run gpg.
>
> Close the stderr pipe so that this can't happen.
I was able to easily reproduce the bug and verify your fix here.
> diff --git a/gpg-interface.c b/gpg-interface.c
> index 0863c61..2c0bed3 100644
> --- a/gpg-interface.c
> +++ b/gpg-interface.c
> @@ -133,6 +133,8 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
> if (gpg_output)
> strbuf_read(gpg_output, gpg.err, 0);
> ret = finish_command(&gpg);
> + if (gpg_output)
> + close(gpg.err);
The strbuf_read above will read to EOF, so it should be equivalent (and
IMHO slightly more readable) to do:
diff --git a/gpg-interface.c b/gpg-interface.c
index 0863c61..5f142f6 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -130,8 +130,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
write_in_full(gpg.in, payload, payload_size);
close(gpg.in);
- if (gpg_output)
+ if (gpg_output) {
strbuf_read(gpg_output, gpg.err, 0);
+ close(gpg.err);
+ }
ret = finish_command(&gpg);
unlink_or_warn(path);
But that is a minor nit; either way, the patch looks good to me.
-Peff
^ permalink raw reply related
* How to identify the users?
From: Scott Yan @ 2013-01-31 5:52 UTC (permalink / raw)
To: git
Hello everyone:
The user info of git client (user name and email) is set by the users
themselves, so , how to avoid userA pretend to be userB?
Git server could authentication the user, but it do nothing about the
user info of commit message.
For example:
There are 20 people of my team, and everyone can push to the public
repository(git server),
If I found some backdoor code in my project, and the commit record
shows it was committed by userA, so I ask userA: why do you do this?
but he told me: no, this is not my code, I have never committed such
thing. ----and yes, everyone could change his user info to userA very
easily .
so... what should I do to avoid such situations?
Thanks!
^ permalink raw reply
* Re: How to identify the users?
From: Scott Yan @ 2013-01-31 6:07 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451nd81aHtaxqpkTeCNG0xpuPd8ptdxRcOgGHaYuN3Qb7WA@mail.gmail.com>
Thanks, Andrew.
you said:
--have the server reject commits that have the 'committer' set to
someone other then the authenticated user
but I don't know how to do that?
Our central repository is hosted by apache, and there are some
username and passwords saved by apache to authentication valid user,
but as I know, there are no relation between the apache username and
the git client user ino (saved in .gitconfig), so can you describe
some detail?
Regards,
Scott Yan
On Thu, Jan 31, 2013 at 1:56 PM, Andrew Ardill <andrew.ardill@gmail.com> wrote:
>
>
>
> On 31 January 2013 16:52, Scott Yan <scottyan19@gmail.com> wrote:
>>
>> The user info of git client (user name and email) is set by the users
>> themselves, so , how to avoid userA pretend to be userB?
>>
>> Git server could authentication the user, but it do nothing about the
>> user info of commit message.
>
>
> The simplest thing is to have the server reject commits that have the
> 'committer' set to someone other then the authenticated user.
>
> Of course, there are potential workflows that this would cause problems for,
> such as if you sync directly to another user's repository and then try and
> push those to a central server.
>
> The most robust system would probably involve using signed tags to verify
> what is being pushed, however I am not aware of any set-ups that have done
> this yet.
>
> Regards,
>
> Andrew Ardill
^ permalink raw reply
* Re: How to identify the users?
From: Tomas Carnecky @ 2013-01-31 6:08 UTC (permalink / raw)
To: Scott Yan, git
In-Reply-To: <CACkbei+Jby13B7rsEb3iLQM2ZSFDgrkgvrYC5M7u4yatppvLxA@mail.gmail.com>
On Thu, 31 Jan 2013 13:52:32 +0800, Scott Yan <scottyan19@gmail.com> wrote:
> Hello everyone:
>
> The user info of git client (user name and email) is set by the users
> themselves, so , how to avoid userA pretend to be userB?
>
> Git server could authentication the user, but it do nothing about the
> user info of commit message.
>
> For example:
> There are 20 people of my team, and everyone can push to the public
> repository(git server),
> If I found some backdoor code in my project, and the commit record
> shows it was committed by userA, so I ask userA: why do you do this?
> but he told me: no, this is not my code, I have never committed such
> thing. ----and yes, everyone could change his user info to userA very
> easily .
>
> so... what should I do to avoid such situations?
gitolite keeps a log of which SSH user pushed which commits. The smart-http
backend does the same if you have reflog enabled on the server (see the
ENVIRONMENT section in man git-http-backend). So unless someone can steal
userA's credentials (http password, ssh key) you'll be able to detect who it
really was.
^ permalink raw reply
* Re: How to identify the users?
From: Sitaram Chamarty @ 2013-01-31 6:10 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Scott Yan, git
In-Reply-To: <1359612481-ner-5936@calvin>
On 01/31/2013 11:38 AM, Tomas Carnecky wrote:
> On Thu, 31 Jan 2013 13:52:32 +0800, Scott Yan <scottyan19@gmail.com> wrote:
>> Hello everyone:
>>
>> The user info of git client (user name and email) is set by the users
>> themselves, so , how to avoid userA pretend to be userB?
>>
>> Git server could authentication the user, but it do nothing about the
>> user info of commit message.
>>
>> For example:
>> There are 20 people of my team, and everyone can push to the public
>> repository(git server),
>> If I found some backdoor code in my project, and the commit record
>> shows it was committed by userA, so I ask userA: why do you do this?
>> but he told me: no, this is not my code, I have never committed such
>> thing. ----and yes, everyone could change his user info to userA very
>> easily .
>>
>> so... what should I do to avoid such situations?
>
> gitolite keeps a log of which SSH user pushed which commits. The smart-http
> backend does the same if you have reflog enabled on the server (see the
> ENVIRONMENT section in man git-http-backend). So unless someone can steal
> userA's credentials (http password, ssh key) you'll be able to detect who it
> really was.
See also my rant on this topic:
https://github.com/sitaramc/gitolite/blob/master/src/VREF/EMAIL-CHECK#L37
^ permalink raw reply
* Re: How to identify the users?
From: Andrew Ardill @ 2013-01-31 6:16 UTC (permalink / raw)
To: Scott Yan; +Cc: git@vger.kernel.org
In-Reply-To: <CACkbei+Jby13B7rsEb3iLQM2ZSFDgrkgvrYC5M7u4yatppvLxA@mail.gmail.com>
(resending previous response. Forgot to turn off HTML, and apprently
gmail doesn't wrap lines automatically anymore?)
On 31 January 2013 16:52, Scott Yan <scottyan19@gmail.com> wrote:
>
> The user info of git client (user name and email) is set by the users
> themselves, so , how to avoid userA pretend to be userB?
>
> Git server could authentication the user, but it do nothing about the
> user info of commit message.
The simplest thing is to have the server reject commits that have the
'committer' set to someone other then the authenticated user.
Of course, there are potential workflows that this would cause problems
for, such as if you sync directly to another user's repository and then try
and push those to a central server.
The most robust system would probably involve using signed tags to
verify what is being pushed, however I am not aware of any set-ups that
have done this yet.
Regards,
Andrew Ardill
^ permalink raw reply
* [PATCH 0/2] improve "git branch --contains=<commit> <pattern>"
From: Jeff King @ 2013-01-31 6:43 UTC (permalink / raw)
To: Peter Wu; +Cc: git
In-Reply-To: <679787987.uZRbjA7AMj@al>
On Wed, Jan 30, 2013 at 07:57:03PM +0100, Peter Wu wrote:
> Hi,
>
> I was trying to check whether a certain branch contained a commit and ran:
>
> git branch --contains ddc150f7a33ae0c9cb16eaac3641abc00f56316f master
>
> This resulted in:
>
> fatal: A branch named 'master' already exists.
> When "name" does not exist, this command creates a branch. I expect this
> command to search the mentioned branch, not trying to create it. The manual
> page of git-branch(1) does not mention such special behavior either.
Yeah, it's sort-of a bug. It is a syntactic ambiguity that an argument
to git-branch could be a listing pattern or a new branch name. When
using a listing pattern, you need to explicitly specify that you want
list mode with `--list`. This is documented in git-branch under --list,
but it should be more prominent, in the section that covers the various
invocation modes. The first patch below fixes that.
That being said, we could be much more helpful. It seems like --contains
should imply listing mode, since it is nonsensical in other modes. The
second patch below adjusts that, and makes the command above do what you
expect.
[1/2]: docs: clarify git-branch --list behavior
[2/2]: branch: let branch filters imply --list
-Peff
^ permalink raw reply
* [PATCH 1/2] docs: clarify git-branch --list behavior
From: Jeff King @ 2013-01-31 6:45 UTC (permalink / raw)
To: Peter Wu; +Cc: git
In-Reply-To: <20130131064357.GA24660@sigill.intra.peff.net>
It was not clear from the "description" section of
git-branch(1) that using a <pattern> meant that you _had_ to
use the --list option. Let's clarify that, and while we're
at it, reword some clunky and ambiguous sentences.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-branch.txt | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 45a225e..01aa87f 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -22,13 +22,15 @@ DESCRIPTION
DESCRIPTION
-----------
-With no arguments, existing branches are listed and the current branch will
-be highlighted with an asterisk. Option `-r` causes the remote-tracking
-branches to be listed, and option `-a` shows both. This list mode is also
-activated by the `--list` option (see below).
-<pattern> restricts the output to matching branches, the pattern is a shell
-wildcard (i.e., matched using fnmatch(3)).
-Multiple patterns may be given; if any of them matches, the branch is shown.
+If `--list` is given, or if there are no non-option arguments, existing
+branches are listed; the current branch will be highlighted with an
+asterisk. Option `-r` causes the remote-tracking branches to be listed,
+and option `-a` shows both local and remote branches. If a `<pattern>`
+is given, it is used as a shell wildcard to restrict the output to
+matching branches. If multiple patterns are given, a branch is shown if
+any it is matched by any of the patterns. Note that when providing a
+`<pattern>`, you must use `--list`; otherwise the command is interpreted
+as branch creation.
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
--
1.8.1.2.5.g1cb3f73
^ permalink raw reply related
* [PATCH 2/2] branch: let branch filters imply --list
From: Jeff King @ 2013-01-31 6:46 UTC (permalink / raw)
To: Peter Wu; +Cc: git
In-Reply-To: <20130131064357.GA24660@sigill.intra.peff.net>
Currently, a branch filter like `--contains`, `--merged`, or
`--no-merged` is ignored when we are not in listing mode.
For example:
git branch --contains=foo bar
will create the branch "bar" from the current HEAD, ignoring
the `--contains` argument entirely. This is not very
helpful. There are two reasonable behaviors for git here:
1. Flag an error; the arguments do not make sense.
2. Implicitly go into `--list` mode
This patch chooses the latter, as it is more convenient, and
there should not be any ambiguity with attempting to create
a branch; using `--contains` and not wanting to list is
nonsensical.
That leaves the case where an explicit modification option
like `-d` is given. We already catch the case where
`--list` is given alongside `-d` and flag an error. With
this patch, we will also catch the use of `--contains` and
other filter options alongside `-d`.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-branch.txt | 6 +++---
builtin/branch.c | 3 +++
t/t3201-branch-contains.sh | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 01aa87f..07ef5af 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -195,15 +195,15 @@ start-point is either a local or remote-tracking branch.
--contains [<commit>]::
Only list branches which contain the specified commit (HEAD
- if not specified).
+ if not specified). Implies `--list`.
--merged [<commit>]::
Only list branches whose tips are reachable from the
- specified commit (HEAD if not specified).
+ specified commit (HEAD if not specified). Implies `--list`.
--no-merged [<commit>]::
Only list branches whose tips are not reachable from the
- specified commit (HEAD if not specified).
+ specified commit (HEAD if not specified). Implies `--list`.
<branchname>::
The name of the branch to create or delete.
diff --git a/builtin/branch.c b/builtin/branch.c
index 873f624..4aa3d4e 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -825,6 +825,9 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (!delete && !rename && !edit_description && !new_upstream && !unset_upstream && argc == 0)
list = 1;
+ if (with_commit || merge_filter != NO_FILTER)
+ list = 1;
+
if (!!delete + !!rename + !!force_create + !!list + !!new_upstream + !!unset_upstream > 1)
usage_with_options(builtin_branch_usage, options);
diff --git a/t/t3201-branch-contains.sh b/t/t3201-branch-contains.sh
index f86f4bc..141b061 100755
--- a/t/t3201-branch-contains.sh
+++ b/t/t3201-branch-contains.sh
@@ -55,6 +55,16 @@ test_expect_success 'branch --contains=side' '
'
+test_expect_success 'branch --contains with pattern implies --list' '
+
+ git branch --contains=master master >actual &&
+ {
+ echo " master"
+ } >expect &&
+ test_cmp expect actual
+
+'
+
test_expect_success 'side: branch --merged' '
git branch --merged >actual &&
@@ -66,6 +76,16 @@ test_expect_success 'side: branch --merged' '
'
+test_expect_success 'branch --merged with pattern implies --list' '
+
+ git branch --merged=side master >actual &&
+ {
+ echo " master"
+ } >expect &&
+ test_cmp expect actual
+
+'
+
test_expect_success 'side: branch --no-merged' '
git branch --no-merged >actual &&
@@ -95,4 +115,19 @@ test_expect_success 'master: branch --no-merged' '
'
+test_expect_success 'branch --no-merged with pattern implies --list' '
+
+ git branch --no-merged=master master >actual &&
+ >expect &&
+ test_cmp expect actual
+
+'
+
+test_expect_success 'implicit --list conflicts with modification options' '
+
+ test_must_fail git branch --contains=master -d &&
+ test_must_fail git branch --contains=master -m foo
+
+'
+
test_done
--
1.8.1.2.5.g1cb3f73
^ permalink raw reply related
* Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-01-31 6:49 UTC (permalink / raw)
To: Jongman Heo; +Cc: git
In-Reply-To: <28799936.346521359596121253.JavaMail.weblogic@epmltmp3>
On Thu, Jan 31, 2013 at 01:35:21AM +0000, Jongman Heo wrote:
> Looks like following commit causes a segmentation fault in my machine
> (when running git pull or git fetch);
>
> commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Mon Jan 7 12:24:55 2013 -0800
>
> string-list: allow case-insensitive string list
>
>
> In my case, list->cmp (at get_entry_index() function) has an invalid
> address, obviously not an address of string comparision function,
> instead it points to 1.
Can you show us a stack trace? The string-list functions are generic and
get called in a lot of places. It would be useful to know which list is
causing the problem.
-Peff
^ permalink raw reply
* Re: How to identify the users?
From: Scott Yan @ 2013-01-31 6:53 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Tomas Carnecky, git@vger.kernel.org
In-Reply-To: <510A0ACF.5060501@gmail.com>
Thanks to all.
Tomas:
I can't find reflog setting of git-http-backend
doc(http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html),
I tried this setting:
git config core.logAllRefUpdates true
and after some test push, the output is as below:
>git log -g master
commit d34e61baa28eabf46ba5e9f6a2feb24cc683ed39
Reflog: master@{0} (Scott Yan <scottyan19@gmail.com>)
Reflog message: push
Author: Scott Yan <scottyan19@gmail.com>
Date: Thu Jan 31 14:19:30 2013 +0800
this log shows when pushed, but still can't tell Who, because the
author info may be fake.
I don't know if I made some mistake.
Sitaram:
It seems I must host my central repo on Gitolite first...
I don't know Gitolite much, but you are right, maybe I should use
Gitolite as my git server.
I'll find more documents about gitolite these days,
can you give me some suggestion which tutorial should I read? Thanks!
ps: my OS is windows.
Regards,
Scott Yan
On Thu, Jan 31, 2013 at 2:10 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On 01/31/2013 11:38 AM, Tomas Carnecky wrote:
>> On Thu, 31 Jan 2013 13:52:32 +0800, Scott Yan <scottyan19@gmail.com> wrote:
>>> Hello everyone:
>>>
>>> The user info of git client (user name and email) is set by the users
>>> themselves, so , how to avoid userA pretend to be userB?
>>>
>>> Git server could authentication the user, but it do nothing about the
>>> user info of commit message.
>>>
>>> For example:
>>> There are 20 people of my team, and everyone can push to the public
>>> repository(git server),
>>> If I found some backdoor code in my project, and the commit record
>>> shows it was committed by userA, so I ask userA: why do you do this?
>>> but he told me: no, this is not my code, I have never committed such
>>> thing. ----and yes, everyone could change his user info to userA very
>>> easily .
>>>
>>> so... what should I do to avoid such situations?
>>
>> gitolite keeps a log of which SSH user pushed which commits. The smart-http
>> backend does the same if you have reflog enabled on the server (see the
>> ENVIRONMENT section in man git-http-backend). So unless someone can steal
>> userA's credentials (http password, ssh key) you'll be able to detect who it
>> really was.
>
> See also my rant on this topic:
>
> https://github.com/sitaramc/gitolite/blob/master/src/VREF/EMAIL-CHECK#L37
^ permalink raw reply
* Re: Segmentation fault with latest git (070c57df)
From: Antoine Pelisse @ 2013-01-31 7:02 UTC (permalink / raw)
To: Jeff King; +Cc: Jongman Heo, git
In-Reply-To: <20130131064921.GB24660@sigill.intra.peff.net>
In "clean.c" we have a "string_list" created on the stack with
"STRING_LIST_INIT_NODUP" (there are probably others, I stopped at the
first occurrence).
But, "STRING_LIST_INIT_NODUP" doesn't init the "list->cmp" pointer
which can thus be random.
I don't have much time to provide a patch right now (have to go to
work), but will tonight if still needed.
Antoine,
On Thu, Jan 31, 2013 at 7:49 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 31, 2013 at 01:35:21AM +0000, Jongman Heo wrote:
>
>> Looks like following commit causes a segmentation fault in my machine
>> (when running git pull or git fetch);
>>
>> commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
>> Author: Junio C Hamano <gitster@pobox.com>
>> Date: Mon Jan 7 12:24:55 2013 -0800
>>
>> string-list: allow case-insensitive string list
>>
>>
>> In my case, list->cmp (at get_entry_index() function) has an invalid
>> address, obviously not an address of string comparision function,
>> instead it points to 1.
>
> Can you show us a stack trace? The string-list functions are generic and
> get called in a lot of places. It would be useful to know which list is
> causing the problem.
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Re: Segmentation fault with latest git (070c57df)
From: Jongman Heo @ 2013-01-31 7:27 UTC (permalink / raw)
To: git, Antoine Pelisse, Jeff King
On Thu, Jan 31, 2013 at 7:49 AM, Jeff King wrote:
> On Thu, Jan 31, 2013 at 01:35:21AM +0000, Jongman Heo wrote:
>
>> Looks like following commit causes a segmentation fault in my machine
>> (when running git pull or git fetch);
>>
>> commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
>> Author: Junio C Hamano
>> Date: Mon Jan 7 12:24:55 2013 -0800
>>
>> string-list: allow case-insensitive string list
>>
>>
>> In my case, list->cmp (at get_entry_index() function) has an invalid
>> address, obviously not an address of string comparision function,
>> instead it points to 1.
>
> Can you show us a stack trace? The string-list functions are generic and
> get called in a lot of places. It would be useful to know which list is
> causing the problem.
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
FYI, gdb backtrace and valgrind output attached below, Thanks.
(gdb) run fetch
Starting program: /home/hjongman/repos/git/git fetch
warning: .dynamic section for "/lib/libc.so.6" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00000001 in ?? ()
(gdb) bt
#0 0x00000001 in ?? ()
#1 0x0812b457 in get_entry_index (list=0xbfffe7c0, string=0x821ec3c "refs/remotes/origin/HEAD", exact_match=0xbfffe568)
at string-list.c:14
#2 0x0812bd60 in add_entry (list=0xbfffe7c0, insert_at=-1, string=0x821ec3c "refs/remotes/origin/HEAD") at string-list.c:33
#3 string_list_insert_at_index (list=0xbfffe7c0, insert_at=-1, string=0x821ec3c "refs/remotes/origin/HEAD") at string-list.c:63
#4 0x0812bda0 in string_list_insert (list=0xbfffe7c0, string=0x821ec3c "refs/remotes/origin/HEAD") at string-list.c:57
#5 0x08071838 in add_existing (refname=0x821ec3c "refs/remotes/origin/HEAD",
sha1=0x821ec14 "\a\fW\337B\352N\255\314C\320Em\021E`\022C&", <incomplete sequence \303>, flag=1, cbdata=0xbfffe7c0)
at builtin/fetch.c:570
#6 0x0810af97 in do_one_ref (base=<value optimized out>, fn=0x8071820 <add_existing>, trim=0, flags=<value optimized out>,
cb_data=0xbfffe7c0, entry=0x821ec10) at refs.c:525
#7 0x0810bd9f in do_for_each_ref_in_dirs (dir1=0x8215d54, dir2=0x821ea44, base=0x814f9ff "", fn=0x8071820 <add_existing>, trim=0,
flags=0, cb_data=0xbfffe7c0) at refs.c:627
#8 0x0810bc8e in do_for_each_ref_in_dirs (dir1=0x8215cac, dir2=0x8226954, base=0x814f9ff "", fn=0x8071820 <add_existing>, trim=0,
flags=0, cb_data=0xbfffe7c0) at refs.c:597
#9 0x0810bc8e in do_for_each_ref_in_dirs (dir1=0x8215c0c, dir2=0x8215a54, base=0x814f9ff "", fn=0x8071820 <add_existing>, trim=0,
flags=0, cb_data=0xbfffe7c0) at refs.c:597
#10 0x0810bc8e in do_for_each_ref_in_dirs (dir1=0x8215a1c, dir2=0x821862c, base=0x814f9ff "", fn=0x8071820 <add_existing>, trim=0,
flags=0, cb_data=0xbfffe7c0) at refs.c:597
#11 0x0810c304 in do_for_each_ref (submodule=<value optimized out>, base=0x814f9ff "", fn=0x8071820 <add_existing>, trim=0, flags=0,
cb_data=0xbfffe7c0) at refs.c:1295
#12 0x0810c63b in for_each_ref (fn=0x8071820 <add_existing>, cb_data=0xbfffe7c0) at refs.c:1343
#13 0x0807390a in do_fetch (remote=<value optimized out>, argc=0, argv=0xbfffe9f8) at builtin/fetch.c:699
#14 fetch_one (remote=<value optimized out>, argc=0, argv=0xbfffe9f8) at builtin/fetch.c:949
#15 0x08074251 in cmd_fetch (argc=1, argv=0xbfffe9f8, prefix=0x0) at builtin/fetch.c:992
#16 0x0804b60b in run_builtin (argc=1, argv=0xbfffe9f8) at git.c:281
#17 handle_internal_command (argc=1, argv=0xbfffe9f8) at git.c:443
#18 0x0804ba51 in run_argv (argc=1, argv=0xbfffe9f8) at git.c:489
#19 main (argc=1, argv=0xbfffe9f8) at git.c:564
$ valgrind git fetch
==2195== Memcheck, a memory error detector
==2195== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2195== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==2195== Command: git fetch
==2195==
==2195== Conditional jump or move depends on uninitialised value(s)
==2195== at 0x812B41F: get_entry_index (string-list.c:10)
==2195== by 0x812BD5F: string_list_insert_at_index (string-list.c:33)
==2195== by 0x812BD9F: string_list_insert (string-list.c:57)
==2195== by 0x8071837: add_existing (fetch.c:570)
==2195== by 0x810AF96: do_one_ref (refs.c:525)
==2195== by 0x810BB20: do_for_each_ref_in_dir (refs.c:551)
==2195== by 0x810BD34: do_for_each_ref_in_dirs (refs.c:623)
==2195== by 0x810BC8D: do_for_each_ref_in_dirs (refs.c:597)
==2195== by 0x810C303: do_for_each_ref (refs.c:1295)
==2195== by 0x810C63A: for_each_ref (refs.c:1343)
==2195== by 0x8073909: fetch_one (fetch.c:699)
==2195== by 0x8074250: cmd_fetch (fetch.c:992)
==2195==
==2195== Use of uninitialised value of size 4
==2195== at 0x812B454: get_entry_index (string-list.c:14)
==2195== by 0x812BD5F: string_list_insert_at_index (string-list.c:33)
==2195== by 0x812BD9F: string_list_insert (string-list.c:57)
==2195== by 0x8071837: add_existing (fetch.c:570)
==2195== by 0x810AF96: do_one_ref (refs.c:525)
==2195== by 0x810BD9E: do_for_each_ref_in_dirs (refs.c:627)
==2195== by 0x810BC8D: do_for_each_ref_in_dirs (refs.c:597)
==2195== by 0x810BC8D: do_for_each_ref_in_dirs (refs.c:597)
==2195== by 0x810BC8D: do_for_each_ref_in_dirs (refs.c:597)
==2195== by 0x810C303: do_for_each_ref (refs.c:1295)
==2195== by 0x810C63A: for_each_ref (refs.c:1343)
==2195== by 0x8073909: fetch_one (fetch.c:699)
==2195==
==2195==
==2195== Process terminating with default action of signal 11 (SIGSEGV)
==2195== Access not within mapped region at address 0x0
==2195== at 0x1: ???
==2195== by 0x812BD5F: string_list_insert_at_index (string-list.c:33)
==2195== by 0x812BD9F: string_list_insert (string-list.c:57)
==2195== by 0x8071837: add_existing (fetch.c:570)
==2195== by 0x810AF96: do_one_ref (refs.c:525)
==2195== by 0x810BD9E: do_for_each_ref_in_dirs (refs.c:627)
==2195== by 0x810BC8D: do_for_each_ref_in_dirs (refs.c:597)
==2195== by 0x810BC8D: do_for_each_ref_in_dirs (refs.c:597)
==2195== by 0x810BC8D: do_for_each_ref_in_dirs (refs.c:597)
==2195== by 0x810C303: do_for_each_ref (refs.c:1295)
==2195== by 0x810C63A: for_each_ref (refs.c:1343)
==2195== by 0x8073909: fetch_one (fetch.c:699)
==2195== If you believe this happened as a result of a stack
==2195== overflow in your program's main thread (unlikely but
==2195== possible), you can try to increase the size of the
==2195== main thread stack using the --main-stacksize= flag.
==2195== The main thread stack size used in this run was 10485760.
==2195==
==2195== HEAP SUMMARY:
==2195== in use at exit: 325,604 bytes in 3,579 blocks
==2195== total heap usage: 3,687 allocs, 108 frees, 518,058 bytes allocated
==2195==
==2195== LEAK SUMMARY:
==2195== definitely lost: 72 bytes in 2 blocks
==2195== indirectly lost: 0 bytes in 0 blocks
==2195== possibly lost: 31,347 bytes in 460 blocks
==2195== still reachable: 294,185 bytes in 3,117 blocks
==2195== suppressed: 0 bytes in 0 blocks
==2195== Rerun with --leak-check=full to see details of leaked memory
==2195==
==2195== For counts of detected and suppressed errors, rerun with: -v
==2195== Use --track-origins=yes to see where uninitialised values come from
==2195== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 17 from 8)
Segmentation fault
^ 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