* Re: BUG. git rebase -i successfully continues (and also skips rewording) when pre-commit hook fails (exits with non-zero code)
From: Andrew Wong @ 2011-11-28 16:15 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
In-Reply-To: <20111117125847.190e9b25@ashu.dyn.rarus.ru>
I actually have a patch to fix this sitting in my repo for a while. Thanks for bringing this issue up again.
Andrew Wong (1):
rebase -i: interrupt rebase when "commit --amend" failed during
"reword"
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
--
1.7.8.rc3.32.gb2fac
^ permalink raw reply
* [PATCH] rebase -i: interrupt rebase when "commit --amend" failed during "reword"
From: Andrew Wong @ 2011-11-28 16:15 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
In-Reply-To: <1322496952-23819-1-git-send-email-andrew.kw.w@gmail.com>
"commit --amend" could fail in cases like the user empties the commit
message, or pre-commit failed. When it fails, rebase should be
interrupted, rather than ignoring the error and continue on rebasing.
This gives users a way to gracefully interrupt a "reword" if they
decided they actually want to do an "edit", or even "rebase --abort".
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
---
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 804001b..669f378 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -408,7 +408,8 @@ do_next () {
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
- git commit --amend --no-post-rewrite
+ git commit --amend --no-post-rewrite ||
+ die_with_patch $sha1 "Cannot amend commit after successfully picking $sha1... $rest"
record_in_rewritten $sha1
;;
edit|e)
--
1.7.8.rc3.32.gb2fac
^ permalink raw reply related
* Git Submodule Problem - Bug?
From: Manuel Koller @ 2011-11-28 17:13 UTC (permalink / raw)
To: git; +Cc: Jens Lehmann, Heiko Voigt
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
Hi
I've encountered strange behavior of git submodule and I cannot think about a way to avoid the problem. I've added a small script that reproduces the problem in the current version of git (1.7.7.3, git-osx-installer).
The problem arises when I pull a commit that switches a submodule with another one and then run git submodule update. Say I have a repo "super" that has one submodule "sub1" in the folder "sub" and a clone "super2". Now I remove the submodule in "super2" and add another one ("sub2") again named "sub", commit this and push it. Now after pulling the commit to "super", I need to run git submodule sync and then git submodule update.
I expect to end up with the submodule "sub2" in sub. But the log clearly shows that the commits from "sub1" are still there (the master branch belongs to "sub1" while origin/master comes from "sub2"). I get the following output:
> ...
> commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39
> Author: Manuel Koller <koller@stat.math.ethz.ch>
> Date: Mon Nov 28 17:46:45 2011 +0100
>
> initial commit sub1
> commit 346fe6bd9e7957f10c5e833bb1155153379da41c
> Author: Manuel Koller <koller@stat.math.ethz.ch>
> Date: Mon Nov 28 17:46:45 2011 +0100
>
> initial commit sub2
I think it should be twice the same, and "sub2". I checked also with Charon, on his machine, the two log messages reported are "sub1" which completely baffles me.
Best regards,
Manuel
[-- Attachment #2: submodule-bug-minimal-example.bash --]
[-- Type: application/octet-stream, Size: 1491 bytes --]
#/bin/bash
## set -e explicitly
set -e
## set current directory as working directory
wd=`pwd`
## create repositories to be used as submodules
mkdir sub1 sub2 remote
(cd sub1
git init
echo "test sub1" >> file
git add file
git commit -m "initial commit sub1"
)
git clone --bare sub1 remote/sub1.git
(cd sub2
git init
echo "test sub2" >> file
git add file
git commit -m "initial commit sub2"
)
git clone --bare sub2 remote/sub2.git
## create super repository
git init --bare remote/super.git
git clone remote/super.git super
(cd super
git submodule add $wd/remote/sub1.git sub
git commit -m "Added submodule sub1 as sub"
git push -u origin master
)
## clone super repository again
## and switch submodule sub1 by sub2
git clone --recursive remote/super.git super2
(cd super2
## remote submodule sub
git config --remove-section submodule.sub
git rm .gitmodules
rm -rf sub
git rm sub
git commit -m "Removed submodule sub"
## add submodule sub2 as sub
git submodule add $wd/remote/sub2.git sub
git commit -m "Added submodule sub2 as sub"
git push
)
## now pull super
(cd super
git pull
## this will fail
git submodule update --init || echo "submodule update fails, that's ok"
## so sync first und update again
git submodule sync
git submodule update --init
## now sub is corrupt
(cd sub
git log master ## this is from sub1
git log origin/master ## this is from sub2
)
)
^ permalink raw reply
* Re: gitweb: 404 links on some blob pages
From: Jakub Narebski @ 2011-11-28 17:24 UTC (permalink / raw)
To: Jürgen Kreileder; +Cc: git
In-Reply-To: <CAKD0Uuyom0chUGfsh+oBRw8NoH4XutbmkVVKoQon6YO2V5oWkA@mail.gmail.com>
Jürgen Kreileder wrote:
> 2011/11/27 Jakub Narebski <jnareb@gmail.com>:
> > Jürgen Kreileder <jk@blackdown.de> writes:
> >
> > > some blob pages have broken links:
> > >
> > > For example, on
> > > https://git.blackdown.de/?p=contactalbum.git;a=blob;f=Classes/WindowController.m;h=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a;hb=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a
> > > the blob_plain link for WindowController.m leads to '404 - Cannot find file':
> > > https://git.blackdown.de/?p=contactalbum.git;a=blob_plain;f=Classes/WindowController.m;hb=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a
> >
> > That is strange. The check is the same for 'blob' and 'blob_plain'
> > action...
>
> The problem is the missing hash (h) parameter for the latter URL.
> Adding it to the blob_plain link makes it work. Just as removing it
> from the blob link breaks that one as well.
Strange. From the look of the page it looks like the 'hb' ("hash_base")
parameter that should lead to the commit from which we get the file is
bogus.
But the "raw" link uses
href(action=>"blob_plain", -replay=>1)
which means that if 'blob' has "h" set correctly, then 'blob_plain'
should too.
> Adding h=... to the tree link doesn't fix that case, though.
Of course it doesn't if you just copy _blob_ hash as _tree_ hash... :-P
(i.e. if you just copy "h" parameter from 'blob' URL).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Permissions per git repository
From: Jakub Narebski @ 2011-11-28 17:40 UTC (permalink / raw)
To: pcm2a; +Cc: git
In-Reply-To: <1322487502060-7038724.post@n2.nabble.com>
pcm2a <cameron@ree-yees.com> writes:
> I have a central git repository running on Windows Server 2008 using Apache
> 2.2 + Smart HTTP + SSPI (for authentication). I can easily limit users to
> all of the repositories with the 'require' command in apache. This is for
> all repositories and not just certain ones.
>
> How can I limit user(s) or group(s) to one repository and a different
> user(s) or group(s) to another repository using git or apache configuration?
If I remember correctly gitolite (a tool to manage access to git
repositories) has support for controlling access via smart HTTP.
--
Jakub Narębski
^ permalink raw reply
* Copy branch into master
From: Ron Eggler @ 2011-11-28 18:25 UTC (permalink / raw)
To: git
Hi,
Some time ago I created a DVT branch in my project and I have almost been
exclusively working in it. Now the time for some test deployment came and I
didn't have time to merge it all back into the master thus I gave out the
DVT branch version. Now I would like to copy exactly what I have in that
branch back into my master to have an exact copy in my master of what got
deployed with out any changes.
How can I do this?
Please advise.
Thank you!
Ron
--
Ron Eggler
1804 - 1122 Gilford St.
Vancouver, BC
V6G 2P5
(778) 230-9442
^ permalink raw reply
* Re: Copy branch into master
From: Andrew Eikum @ 2011-11-28 18:36 UTC (permalink / raw)
To: Ron Eggler; +Cc: git
In-Reply-To: <CAHxBh_T-f7O4r0zn=NtLTYtdbNqd3qSo2tW84aYRJp7ugDSMpw@mail.gmail.com>
On Mon, Nov 28, 2011 at 10:25:33AM -0800, Ron Eggler wrote:
> Some time ago I created a DVT branch in my project and I have almost been
> exclusively working in it. Now the time for some test deployment came and I
> didn't have time to merge it all back into the master thus I gave out the
> DVT branch version. Now I would like to copy exactly what I have in that
> branch back into my master to have an exact copy in my master of what got
> deployed with out any changes.
> How can I do this?
Couple options, depending on what you want:
Rename DVT to master (similar to 'mv DVT master', including
losing the contents of 'master'):
$ git checkout --detach HEAD
$ git branch -M DVT master
$ git checkout master
Retain old master (like 'mv master old_master; mv DVT master'):
$ git checkout --detach HEAD
$ git branch -m master old_master
$ git branch -m DVT master
$ git checkout master
The "checkout --detach" is just so Git doesn't complain about
moving/deleting the currently checked out branch.
If you haven't yet, be sure to read ProGit, which should make
questions like this trivial for you to answer yourself in the future:
<http://progit.org/book/>
Hope this helps,
Andrew
^ permalink raw reply
* Re: [PATCH 0/6] echo usernames as they are typed
From: Jeff King @ 2011-11-28 18:59 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <CABPQNSYd8PFsoRi6NtjQYNQzM+NHv_aRCLRWQ=XsFuw2gGWAng@mail.gmail.com>
On Mon, Nov 28, 2011 at 01:59:34PM +0100, Erik Faye-Lund wrote:
> > Certainly on non-Windows something like that would not be welcome. The
> > user can already have specified GIT_ASKPASS if they don't have a
> > terminal. And once the credential-helper code is in, they can use a
> > platform-specific helper that provides a nice dialog if they want it.
> >
>
> Yes, that's certainly cleaner implementation-wise. But didn't you
> change it to only do the storage-part in the last round, or did I
> misunderstand the updated series?
Yeah, sorry, I'm getting ahead of myself. I left room in the spec for an
"ask" operation on helpers, but I haven't implemented it yet.
-Peff
^ permalink raw reply
* RE: Copy branch into master
From: Ron Eggler @ 2011-11-28 19:08 UTC (permalink / raw)
To: 'Andrew Eikum'; +Cc: git
In-Reply-To: <20111128183616.GB29503@foghorn.codeweavers.com>
Thanks for that,
I guess I'd go for renaming DVT to master.
However, I also played around with merge a little, started a merge (in
Windows GUI) and aborted it but the icon of my directory keeps showing the
ywellow exclemation mark, signing that a merge is going on right now but
going into the directory, all the files are with a geen check mark. What's
going on here? How do I resolve this - I don't wanna mess things up so I
might rather resolve this before moving DVT to master.
Thanks,
Ron
-----Original Message-----
From: Andrew Eikum [mailto:aeikum@codeweavers.com]
Sent: Monday, November 28, 2011 10:36 AM
To: Ron Eggler
Cc: git@vger.kernel.org
Subject: Re: Copy branch into master
On Mon, Nov 28, 2011 at 10:25:33AM -0800, Ron Eggler wrote:
> Some time ago I created a DVT branch in my project and I have almost been
> exclusively working in it. Now the time for some test deployment came and
I
> didn't have time to merge it all back into the master thus I gave out the
> DVT branch version. Now I would like to copy exactly what I have in that
> branch back into my master to have an exact copy in my master of what got
> deployed with out any changes.
> How can I do this?
Couple options, depending on what you want:
Rename DVT to master (similar to 'mv DVT master', including
losing the contents of 'master'):
$ git checkout --detach HEAD
$ git branch -M DVT master
$ git checkout master
Retain old master (like 'mv master old_master; mv DVT master'):
$ git checkout --detach HEAD
$ git branch -m master old_master
$ git branch -m DVT master
$ git checkout master
The "checkout --detach" is just so Git doesn't complain about
moving/deleting the currently checked out branch.
If you haven't yet, be sure to read ProGit, which should make
questions like this trivial for you to answer yourself in the future:
<http://progit.org/book/>
Hope this helps,
Andrew
^ permalink raw reply
* Re: Infinite loop in cascade_filter_fn()
From: Junio C Hamano @ 2011-11-28 19:18 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Henrik Grubbström, Git Mailing list
In-Reply-To: <20111128104812.GA2386@beez.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
>> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO"
>> Content-Disposition: inline
Please do not do this. It makes it unnecessarily cumbersome to handle
patches without adding much value to the patch.
> --- 8< ---
> Subject: [PATCHv2] convert: track state in LF-to-CRLF filter
>
> There may not be enough space to store CRLF in the output. If we don't
> fill the buffer, then the filter will keep getting called with the same
> short buffer and will loop forever.
>
> Instead, always store the CR and record whether there's a missing LF
> if so we store it in the output buffer the next time the function gets
> called.
>
> Reported-by: Henrik Grubbström <grubba@roxen.com>
> Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
> ---
> convert.c | 50 +++++++++++++++++++++++++++++++++++++-------------
> 1 files changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/convert.c b/convert.c
> index 86e9c29..1c91409 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -876,24 +876,39 @@ int is_null_stream_filter(struct stream_filter *filter)
> /*
> * LF-to-CRLF filter
> */
> +
> +struct lf_to_crlf_filter {
> + struct stream_filter filter;
> + int want_lf;
> +};
> +
> static int lf_to_crlf_filter_fn(struct stream_filter *filter,
> const char *input, size_t *isize_p,
> char *output, size_t *osize_p)
> {
> - size_t count;
> + size_t count, o = 0;
> + struct lf_to_crlf_filter *lfcrlf = (struct lf_to_crlf_filter *) filter;
> ...
> -};
> +static struct stream_filter *lf_to_crlf_filter(void)
> +{
> + struct lf_to_crlf_filter *lfcrlf = xmalloc(sizeof(*lfcrlf));
>
> + lfcrlf->filter.vtbl = &lf_to_crlf_vtbl;
> + lfcrlf->want_lf = 0;
> + return (struct stream_filter *)lfcrlf;
> +}
Patch looks sane; you may want to rename the variable to lf_crlf at least,
though. The name does not consist of three tokens ("lf", "cr" and "lf")
but of two ("lf" and "crlf"), and your naming loses it.
^ permalink raw reply
* Re: Copy branch into master
From: Andrew Eikum @ 2011-11-28 19:26 UTC (permalink / raw)
To: Ron Eggler; +Cc: git
In-Reply-To: <3655DADD9B52450B81B0CD34F1B0FAB6@bny.us.bosch.com>
On Mon, Nov 28, 2011 at 11:08:33AM -0800, Ron Eggler wrote:
> I guess I'd go for renaming DVT to master.
>
> However, I also played around with merge a little, started a merge (in
> Windows GUI) and aborted it but the icon of my directory keeps showing the
> ywellow exclemation mark, signing that a merge is going on right now but
> going into the directory, all the files are with a geen check mark. What's
> going on here? How do I resolve this - I don't wanna mess things up so I
> might rather resolve this before moving DVT to master.
>
Sorry, I have no idea how to use any of the GUI tools. Perhaps your
GUI tool has a mailing list where you can ask about merge conflict
resolution?
Andrew
^ permalink raw reply
* RE: Copy branch into master
From: Ron Eggler @ 2011-11-28 19:30 UTC (permalink / raw)
To: 'Andrew Eikum'; +Cc: git
In-Reply-To: <20111128192659.GD29503@foghorn.codeweavers.com>
> Sorry, I have no idea how to use any of the GUI tools. Perhaps your
> GUI tool has a mailing list where you can ask about merge conflict
> resolution?
No problem, I actually got it all figured out now, and got my branch
smoothly merged back into master.
Thanks for your help!
Ron
^ permalink raw reply
* Re: git branch -M" regression in 1.7.7?
From: Junio C Hamano @ 2011-11-28 19:38 UTC (permalink / raw)
To: Jonathan Nieder
Cc: ☂Josh Chia (谢任中), git,
Soeren Sonnenburg, Conrad Irwin
In-Reply-To: <20111126023002.GA17652@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> git branch -M master
>
> This seems like a valuable exception to allow, because then "git
> branch -M foo" would _always_ be allowed --- either 'foo' is not the
> current branch, and it does the obvious thing, or 'foo' is the current
> branch, and nothing happens.
>
> Buildbot uses this idiom and was broken in 1.7.7 (it would emit the
> message "Cannot force update the current branch").
Although I am not sure the practice deserves to be called "idiom", I agree
that there is no reason to forbid renaming the current branch to the tip
commit of itself.
Will queue.
^ permalink raw reply
* Re: Is there a "--follow" equvalent argument to git-rev-list?
From: Junio C Hamano @ 2011-11-28 19:53 UTC (permalink / raw)
To: Steinar Bang; +Cc: git
In-Reply-To: <87vcq4zg6p.fsf@dod.no>
[administrivia: do not use Mail-Followup-To here]
Steinar Bang <sb@dod.no> writes:
> Is there an argument to "git rev-list" that will make it track across
> renames?
There isn't, and it is more or less deliberate.
The "log --follow" is not meant as anything more than a checkbox hack. The
intended audience of "rev-list" is scripts that reads plumbing output and
it is expected to be capable of doing all of what "follow" does and more.
It can notice that the path you were following has disappeared at a
particular commit, see what other paths (notice the plural, which is not
what --follow does) in the older tree may have contributed the contents of
the newly added path by running "diff-tree -M" (or -C), etc. That way the
scripts can even notice a case where a file you were following originally
were two separate files that the commit merged into one, which "follow"
would never do.
^ permalink raw reply
* Re: gitweb: in-page errors don't work with mod_perl
From: Jürgen Kreileder @ 2011-11-28 20:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201111281754.59205.jnareb@gmail.com>
On Mon, Nov 28, 2011 at 17:54, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
>
> The configuration is very similar. Perhaps that is the difference between
> Apache 2.0.x (mine) and Apache 2.2.x (yours).
>
> Does adding `$r->err_headers_out();` before `$r->status(200);` helps?
> I'm grasping at straws here. mod_perl documentation is not very helpful.
Doesn't help unfortunately. It's hard to find any information about
this on the net (except for your comment on stackoverflow :).
The only way to get mod_perl to return a custom error message with
correct status code I've found so far is $r->custom_response($status,
$msg). Unfortunately mod_perl then ignores header I set, e.g.
content-type.
Juergen
^ permalink raw reply
* Re: gitweb: in-page errors don't work with mod_perl
From: Jürgen Kreileder @ 2011-11-28 21:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <CAKD0Uuws=zU+Pg8afn91mm0t4Rp_GNF++dTYnjA9okndyR=cXQ@mail.gmail.com>
On Mon, Nov 28, 2011 at 21:13, Jürgen Kreileder <jk@blackdown.de> wrote:
> On Mon, Nov 28, 2011 at 17:54, Jakub Narebski <jnareb@gmail.com> wrote:
> [...]
>>
>> The configuration is very similar. Perhaps that is the difference between
>> Apache 2.0.x (mine) and Apache 2.2.x (yours).
>>
>> Does adding `$r->err_headers_out();` before `$r->status(200);` helps?
>> I'm grasping at straws here. mod_perl documentation is not very helpful.
>
> Doesn't help unfortunately. It's hard to find any information about
> this on the net (except for your comment on stackoverflow :).
>
> The only way to get mod_perl to return a custom error message with
> correct status code I've found so far is $r->custom_response($status,
> $msg). Unfortunately mod_perl then ignores headers I set, e.g.
> content-type.
I guess this explains it:
http://foertsch.name/ModPerl-Tricks/custom-content_type-with-custom_response.shtml
Requires quite some restructuring to gitweb.perl.
Juergen
^ permalink raw reply
* Re: [PATCH 03/13] introduce credentials API
From: Junio C Hamano @ 2011-11-28 21:46 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111124110105.GA8417@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt
> new file mode 100644
> index 0000000..3061077
> --- /dev/null
> +++ b/Documentation/technical/api-credentials.txt
> @@ -0,0 +1,148 @@
> + ...
> +`credential_fill`::
> +
> + Attempt to fill the username and password fields of the passed
> + credential struct, first consulting storage helpers, then asking
> + the user. Guarantees that the username and password fields will
> + be filled afterwards (or die() will be called).
> +
> +`credential_reject`::
> +
> + Inform the credential subsystem that the provided credentials
> + have been rejected. This will notify any storage helpers of the
> + rejection (which allows them to, for example, purge the invalid
> + credentials from storage), and then clear the username and
> + password fields in `struct credential`. It can then be
> + `credential_fill`-ed again.
> +
> +`credential_approve`::
> +
> + Inform the credential subsystem that the provided credentials
> + were successfully used for authentication. This will notify any
> + storage helpers of the approval, so that they can store the
> + result to be used again.
It's a bit hard to read and understand which part of the system calls
these and which other part of the system is responsible for implementing
them, and how "helper" fits into the picture (perhaps calling some of
these interfaces will result in "helper" getting called?).
> +Credential Storage Helpers
> +--------------------------
> +
> +Credential storage helpers are programs executed by git to fetch or save
> +credentials from and to long-term storage (where "long-term" is simply
> +longer than a single git process; e.g., credentials may be stored
> +in-memory for a few minutes, or indefinitely on disk).
> +
> +Helper scripts should generally be found in the PATH, and have names of
> +the form "git-credential-$HELPER".
Is this normal PATH or can a helper be moved away into $GIT_EXEC_PATH?
I briefly wondered if they want to be git-credential--$HELPER; I do not
deeply care either way, though.
> When the helper string "$HELPER" is
> +passed to credential functions, they will run "git-credential-$HELPER"
> +via the shell. If the first word of $HELPER contains non-alphanumeric
> +characters, then $HELPER is executed as a shell command. This makes it
> +possible to specify individual scripts by their full path (e.g.,
> +`/path/to/helper`) or even shell snippets (`f() { do_whatever; }; f`).
The definition of "the first word" above is not specified but it seems to
be "space separated". In other words, 'f() { do_whatever; }; f' would be
OK but 'f () { do_whatever; }; f' would not be. Am I reading and guessing
your intention correctly?
Funnily enough, 'f<TAB>() { do_whatever; }; f' would qualify as the first
word having a non alphanumeric.
> +The details of the credential will be provided on the helper's stdin
> +stream. The credential is split into a set of named attributes.
> +Attributes are provided to the helper, one per line. Each attribute is
> +specified by a key-value pair, separated by an `=` (equals) sign,
> +followed by a newline. The key may contain any bytes except `=` or
> +newline. The value may contain any bytes except a newline. In both
> +cases, all bytes are treated as-is (i.e., there is no quoting, and one
> +cannot transmit a value with newline in it).
Can k or v contain a NUL? The literal reading of the above implies they
could, but I do not think you meant to.
> +int credential_read(struct credential *c, FILE *fp)
> +{
> ...
> + c->host = xstrdup(value);
> + }
> + else if (!strcmp(key, "path")) {
> ...
> + /* ignore other lines; we don't know what they mean, but
> + * this future-proofs us when later versions of git do
> + * learn new lines, and the helpers are updated to match */
Two style nits.
^ permalink raw reply
* Re: gitweb: in-page errors don't work with mod_perl
From: Jakub Narebski @ 2011-11-28 22:32 UTC (permalink / raw)
To: Jürgen Kreileder; +Cc: git
In-Reply-To: <CAKD0UuzsV7A_j8YD4b0Lb95L2NcRcSu5PH8C9aZQmEx3tOuQjQ@mail.gmail.com>
Jürgen Kreileder wrote:
> On Mon, Nov 28, 2011 at 21:13, Jürgen Kreileder <jk@blackdown.de> wrote:
> > On Mon, Nov 28, 2011 at 17:54, Jakub Narebski <jnareb@gmail.com> wrote:
> > [...]
> > >
> > > The configuration is very similar. Perhaps that is the difference between
> > > Apache 2.0.x (mine) and Apache 2.2.x (yours).
> > >
> > > Does adding `$r->err_headers_out();` before `$r->status(200);` helps?
> > > I'm grasping at straws here. mod_perl documentation is not very helpful.
> >
> > Doesn't help unfortunately. It's hard to find any information about
> > this on the net (except for your comment on stackoverflow :).
> >
> > The only way to get mod_perl to return a custom error message with
> > correct status code I've found so far is $r->custom_response($status,
> > $msg). Unfortunately mod_perl then ignores headers I set, e.g.
> > content-type.
>
> I guess this explains it:
> http://foertsch.name/ModPerl-Tricks/custom-content_type-with-custom_response.shtml
> Requires quite some restructuring to gitweb.perl.
I'm coming close to declaring that ModPerl::Registry is horribly broken
with respect to error pages created by CGI, and say that we don't support
it, removing mod_perl configuration examples from gitweb documentation.
WTF 'return Apache2::Const::DONE;' doesn't work with ModPerl::Registry?
It is supposed to work with native mod_perl scripts...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitweb: Escape attribute in chop_and_escape_str()
From: Jürgen Kreileder @ 2011-11-28 23:27 UTC (permalink / raw)
To: git
Fixes the title attribute in <span title="Jürgen Kreileder">Jürgen
Kreileder</span>
for example because to_utf8() is called implicitly now.
(Not sure why the attribute is there at all in the example. From my
point of view
nothing got chopped.)
Signed-off-by: Juergen Kreileder <jk@blackdown.de>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4f0c3bd..fd76407 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1699,7 +1699,7 @@ sub chop_and_escape_str {
return esc_html($chopped);
} else {
$str =~ s/[[:cntrl:]]/?/g;
- return $cgi->span({-title=>$str}, esc_html($chopped));
+ return $cgi->span({-title => esc_attr($str)}, esc_html($chopped));
}
}
--
1.7.5.4
^ permalink raw reply related
* [ANNOUNCE] Git 1.7.8-rc4
From: Junio C Hamano @ 2011-11-28 23:37 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git 1.7.8-rc4 is available for testing. This hopefully
is the last rc before the final release (we had to make a last-minute UI
tweak to a new feature in multi-step "revert" command to avoid later
regrets). We already have interesting topics queued together with proposed
fixes for older non-regression bugs which would make the next cycle short,
sweet and fun.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
528b8099e980877eb7e2268be8afdf12efe13490 git-1.7.8.rc4.tar.gz
f775ddd3ee207816840ced38c28d1a400a823536 git-htmldocs-1.7.8.rc4.tar.gz
b35301ed60712f441a9c3af08446184faf624d51 git-manpages-1.7.8.rc4.tar.gz
Also the following public repositories all have a copy of the v1.7.8.rc4
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
----------------------------------------------------------------
Changes since v1.7.8-rc3 are as follows:
Johannes Sixt (1):
Fix revert --abort on Windows
Jonathan Nieder (11):
do not let git_path clobber errno when reporting errors
notes merge: eliminate OUTPUT macro
Makefile: add missing header file dependencies
Makefile: add option to disable automatic dependency generation
revert: rename --reset option to --quit
revert: rearrange pick_revisions() for clarity
revert: improve error message for cherry-pick during cherry-pick
revert: write REVERT_HEAD pseudoref during conflicted revert
revert: introduce --abort to cancel a failed cherry-pick
revert: remove --reset compatibility option
revert --abort: do not leave behind useless sequencer-old directory
Junio C Hamano (5):
name-rev --all: do not even attempt to describe non-commit object
Git 1.7.7.4
Hopefully final update of release notes before 1.7.8 final
Update 1.7.8 draft release notes in preparation for rc4
Git 1.7.8-rc4
Marc-André Lureau (1):
mailmap: xcalloc mailmap_info
Nguyễn Thái Ngọc Duy (1):
revert: do not pass non-literal string as format to git_path()
Ramkumar Ramachandra (4):
http: remove unused function hex()
convert: don't mix enum with int
sha1_file: don't mix enum with int
git-compat-util: don't assume value for undefined variable
Ramsay Allan Jones (3):
t5501-*.sh: Fix url passed to clone in setup test
config.c: Fix a static buffer overwrite bug by avoiding mkpath()
convert.c: Fix return type of git_path_check_eol()
Thomas Hochstein (1):
documentation fix: git difftool uses diff tools, not merge tools.
Vincent van Ravesteijn (2):
builtin-branch: Fix crash on invalid use of --force
builtin-reset: Documentation update
^ permalink raw reply
* Re: gitweb: in-page errors don't work with mod_perl
From: Jürgen Kreileder @ 2011-11-28 23:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201111282332.07276.jnareb@gmail.com>
On Mon, Nov 28, 2011 at 23:32, Jakub Narebski <jnareb@gmail.com> wrote:
> Jürgen Kreileder wrote:
>> On Mon, Nov 28, 2011 at 21:13, Jürgen Kreileder <jk@blackdown.de> wrote:
>> > On Mon, Nov 28, 2011 at 17:54, Jakub Narebski <jnareb@gmail.com> wrote:
>> > [...]
>> > >
>> > > The configuration is very similar. Perhaps that is the difference between
>> > > Apache 2.0.x (mine) and Apache 2.2.x (yours).
>> > >
>> > > Does adding `$r->err_headers_out();` before `$r->status(200);` helps?
>> > > I'm grasping at straws here. mod_perl documentation is not very helpful.
>> >
>> > Doesn't help unfortunately. It's hard to find any information about
>> > this on the net (except for your comment on stackoverflow :).
>> >
>> > The only way to get mod_perl to return a custom error message with
>> > correct status code I've found so far is $r->custom_response($status,
>> > $msg). Unfortunately mod_perl then ignores headers I set, e.g.
>> > content-type.
>>
>> I guess this explains it:
>> http://foertsch.name/ModPerl-Tricks/custom-content_type-with-custom_response.shtml
>> Requires quite some restructuring to gitweb.perl.
>
> I'm coming close to declaring that ModPerl::Registry is horribly broken
> with respect to error pages created by CGI, and say that we don't support
> it, removing mod_perl configuration examples from gitweb documentation.
Makes sense. The benefits of mod_perl are properly small for gitweb anyway.
Juergen
--
http://blog.blackdown.de/
http://www.flickr.com/photos/jkreileder/
^ permalink raw reply
* Re: [PATCH 10/13] credentials: add "cache" helper
From: Junio C Hamano @ 2011-11-29 0:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111124110710.GH8417@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/t/lib-credential.sh b/t/lib-credential.sh
> index 54ae1f4..ac54b38 100755
> --- a/t/lib-credential.sh
> +++ b/t/lib-credential.sh
> @@ -21,6 +21,225 @@ read_chunk() {
> ...
> + test_expect_success "helper ($HELPER) can forget user" '
> + check reject $HELPER <<-\EOF &&
> + protocol=https
> + host=example.com
> + username=user1
> + EOF
> + check fill $HELPER <<-\EOF
> + protocol=https
> + host=example.com
> + username=user1
> + --
> + username=user1
> + password=askpass-password
> + --
> + askpass: Password for '\''https://user1@example.com'\'':
> + '
Missing EOF for here document; I fixed this already in 'pu', but please
squash it in when rerolling after 1.7.8 final.
^ permalink raw reply
* Re: gitweb: in-page errors don't work with mod_perl
From: Jakub Narebski @ 2011-11-29 0:49 UTC (permalink / raw)
To: Jürgen Kreileder; +Cc: git
In-Reply-To: <CAKD0Uuw35Kdno=OxqP5SYtaVjqUFZCLL9fSSscN7sq=KmycyxA@mail.gmail.com>
Jürgen Kreileder wrote:
> On Mon, Nov 28, 2011 at 23:32, Jakub Narebski <jnareb@gmail.com> wrote:
>> Jürgen Kreileder wrote:
>>> On Mon, Nov 28, 2011 at 21:13, Jürgen Kreileder <jk@blackdown.de> wrote:
>>>> On Mon, Nov 28, 2011 at 17:54, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> [...]
>>>>>
>>>>> The configuration is very similar. Perhaps that is the difference between
>>>>> Apache 2.0.x (mine) and Apache 2.2.x (yours).
>>>>>
>>>>> Does adding `$r->err_headers_out();` before `$r->status(200);` helps?
>>>>> I'm grasping at straws here. mod_perl documentation is not very helpful.
>>>>
>>>> Doesn't help unfortunately. It's hard to find any information about
>>>> this on the net (except for your comment on stackoverflow :).
>>>>
>>>> The only way to get mod_perl to return a custom error message with
>>>> correct status code I've found so far is $r->custom_response($status,
>>>> $msg). Unfortunately mod_perl then ignores headers I set, e.g.
>>>> content-type.
>>>
>>> I guess this explains it:
>>> http://foertsch.name/ModPerl-Tricks/custom-content_type-with-custom_response.shtml
>>> Requires quite some restructuring to gitweb.perl.
>>
>> I'm coming close to declaring that ModPerl::Registry is horribly broken
>> with respect to error pages created by CGI, and say that we don't support
>> it, removing mod_perl configuration examples from gitweb documentation.
>
> Makes sense. The benefits of mod_perl are properly small for gitweb anyway.
Anyway you can run gitweb with FastCGI (supposedly - I don't know if it
was tested), which provides the same (or most of the) advantages that
mod_perl gives, without the troubles. Just rename gitweb.cgi to
gitweb.fcgi and configure web server appropriately (and have FCGI Perl
module installed).
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitweb: Don't append ';js=(0|1)' to external links
From: Jürgen Kreileder @ 2011-11-29 0:53 UTC (permalink / raw)
To: git
Signed-off-by: Juergen Kreileder <jk@blackdown.de>
---
gitweb/gitweb.perl | 2 +-
gitweb/static/js/javascript-detection.js | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4f0c3bd..dfe3407 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3974,7 +3974,7 @@ sub git_footer_html {
print qq!<script type="text/javascript">\n!.
qq!window.onload = function () {\n!;
if (gitweb_check_feature('javascript-actions')) {
- print qq! fixLinks();\n!;
+ print qq! fixLinks('$my_url');\n!;
}
if ($jstimezone && $tz_cookie && $datetime_class) {
print qq! var tz_cookie = { name: '$tz_cookie', expires: 14, path:
'/' };\n!. # in days
diff --git a/gitweb/static/js/javascript-detection.js
b/gitweb/static/js/javascript-detection.js
index fa2596f..36964ad 100644
--- a/gitweb/static/js/javascript-detection.js
+++ b/gitweb/static/js/javascript-detection.js
@@ -29,11 +29,11 @@ var jsExceptionsRe = /[;?]js=[01](#.*)?$/;
*
* @globals jsExceptionsRe
*/
-function fixLinks() {
+function fixLinks(baseurl) {
var allLinks = document.getElementsByTagName("a") || document.links;
for (var i = 0, len = allLinks.length; i < len; i++) {
var link = allLinks[i];
- if (!jsExceptionsRe.test(link)) {
+ if (!jsExceptionsRe.test(link) && !link.href.indexOf(baseurl)) {
link.href = link.href.replace(/(#|$)/,
(link.href.indexOf('?') === -1 ? '?' : ';') + 'js=1$1');
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 03/13] introduce credentials API
From: Jeff King @ 2011-11-29 5:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nxnvs1w.fsf@alter.siamese.dyndns.org>
On Mon, Nov 28, 2011 at 01:46:35PM -0800, Junio C Hamano wrote:
> > diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt
> > new file mode 100644
> > index 0000000..3061077
> > --- /dev/null
> > +++ b/Documentation/technical/api-credentials.txt
> > @@ -0,0 +1,148 @@
> > + ...
> > +`credential_fill`::
> > +
> > + Attempt to fill the username and password fields of the passed
> > + credential struct, first consulting storage helpers, then asking
> > + the user. Guarantees that the username and password fields will
> > + be filled afterwards (or die() will be called).
> > +
> > +`credential_reject`::
> > +
> > + Inform the credential subsystem that the provided credentials
> > + have been rejected. This will notify any storage helpers of the
> > + rejection (which allows them to, for example, purge the invalid
> > + credentials from storage), and then clear the username and
> > + password fields in `struct credential`. It can then be
> > + `credential_fill`-ed again.
> > +
> > +`credential_approve`::
> > +
> > + Inform the credential subsystem that the provided credentials
> > + were successfully used for authentication. This will notify any
> > + storage helpers of the approval, so that they can store the
> > + result to be used again.
>
> It's a bit hard to read and understand which part of the system calls
> these and which other part of the system is responsible for implementing
> them, and how "helper" fits into the picture (perhaps calling some of
> these interfaces will result in "helper" getting called?).
How about following it with a rough example of how they would be used,
like:
/*
* Create a credential with some context; we don't yet know the
* username or password.
*/
struct credential c = CREDENTIAL_INIT;
c.protocol = xstrdup("https");
c.host = xstrdup("example.com");
c.path = xstrdup("foo.git");
/*
* Fill in the username and password fields by contacting helpers
* and/or asking the user. The function will die if it fails.
*/
credential_fill(&c);
/*
* And then finally make our request, reporting back to the credential
* system on whether it succeeded or failed.
*/
if (make_http_request(c.host, c.path, c.username, c.password) < 0)
credential_reject(&c);
else
credential_accept(&c);
Does that make it more clear?
> > +Credential Storage Helpers
> > +--------------------------
> > +
> > +Credential storage helpers are programs executed by git to fetch or save
> > +credentials from and to long-term storage (where "long-term" is simply
> > +longer than a single git process; e.g., credentials may be stored
> > +in-memory for a few minutes, or indefinitely on disk).
> > +
> > +Helper scripts should generally be found in the PATH, and have names of
> > +the form "git-credential-$HELPER".
>
> Is this normal PATH or can a helper be moved away into $GIT_EXEC_PATH?
They are executed as normal git commands, so $GIT_EXEC_PATH. Actually,
they could even be aliases or builtins, for that matter. I'll update the
documentation to reflect that.
> I briefly wondered if they want to be git-credential--$HELPER; I do not
> deeply care either way, though.
Yeah, I thought about that. In some ways they are implementation details
that you don't care about, and that makes the "--" separator make sense.
But some of them may want to expose other actions to the user. For
example, git-credential-cache has an "exit" action that you can call to
ask the cache daemon to exit prematurely, forgetting all credentials.
Git will never use it; it's purely an end-user interface.
I think it might also make sense to ask helpers to provide a "clear"
operation which will delete any stored items. Git wouldn't use it, but
it would be helpful for testing.
> > When the helper string "$HELPER" is
> > +passed to credential functions, they will run "git-credential-$HELPER"
> > +via the shell. If the first word of $HELPER contains non-alphanumeric
> > +characters, then $HELPER is executed as a shell command. This makes it
> > +possible to specify individual scripts by their full path (e.g.,
> > +`/path/to/helper`) or even shell snippets (`f() { do_whatever; }; f`).
>
> The definition of "the first word" above is not specified but it seems to
> be "space separated". In other words, 'f() { do_whatever; }; f' would be
> OK but 'f () { do_whatever; }; f' would not be. Am I reading and guessing
> your intention correctly?
Yes, that is my intent, though I am not altogether happy with it, as
there are too many confusing corner cases (e.g., your "f ()" example
above). My thinking was guided by these requirements:
1. Users who are using one of the included helpers or a drop-in
third-party helper should be able to just do:
git config credential.helper cache
which is extremely readable and intuitive. Thus, I want to prepend
"git credential-" at least for simple cases.
2. You should be able to add arguments to a helper, if it takes them.
For example, with the current code you can do:
git config credential.helper 'cache --timeout=300'
or
git config credential.helper 'store --store=/some/path'
and that's all interpreted by the shell, and the helpers receive
your configuration (the "--store" name is a holdover from version 1
of the series, which had many more options. Probably "--path" or
"--file" would be better name).
So that means that the rule for when to prepend "git credential-"
is not simply "when the helper is a single token". It can be
arbitrary arguments, and should be interpreted by the shell (to
handle things like quoting).
3. You should be able to use a full path, like:
git config credential.helper '/path/to/git-credential-foo'
This works with the isalnum thing. But you could also use
is_absolute_path.
4. You should be able to insert full shell snippets if you really want
to. This is handy for testing, and I could even see somebody doing
something like:
git config credential.helper '
f() {
case "`uname -s`" in
Linux) git credential-gnome "$@" ;;
Darwin) git credential-osx "$@" ;;
esac
}
f'
if they have a multi-platform config file (or they could check
$DISPLAY, or `hostname`, or any of a zillion other things). You
could put it in a shell script, of course, but sometimes it is
nice to carry little snippets like that in the config file.
You could do something like "prepend ! to execute via the shell",
like we do for aliases. But that is perhaps a little confusing, in
that we are _always_ executing via the shell. It is just that
sometimes we prepend some magic to the command name. I dunno.
So one possible rule would be:
1. If it starts with "!", clip off the "!" and hand it to the shell.
2. Otherwise, if is_absolute_path(), hand it to the shell directly.
3. Otherwise, prepend "git credential-" and hand it to the shell.
I think that is slightly less confusing than the "first word is alnum"
thing.
> Funnily enough, 'f<TAB>() { do_whatever; }; f' would qualify as the first
> word having a non alphanumeric.
Yeah, arguably a bug in my code. ;)
> > +The details of the credential will be provided on the helper's stdin
> > +stream. The credential is split into a set of named attributes.
> > +Attributes are provided to the helper, one per line. Each attribute is
> > +specified by a key-value pair, separated by an `=` (equals) sign,
> > +followed by a newline. The key may contain any bytes except `=` or
> > +newline. The value may contain any bytes except a newline. In both
> > +cases, all bytes are treated as-is (i.e., there is no quoting, and one
> > +cannot transmit a value with newline in it).
>
> Can k or v contain a NUL? The literal reading of the above implies they
> could, but I do not think you meant to.
No, they cannot. I'll make that more explicit in the next version.
How do you feel about the "values cannot contain a newline" requirement?
It feels wrong to me to design a protocol with no escape hatch for
quoting. But I really didn't want helper implementations to have to deal
with unquoting or other parsing headaches. And terminating with NUL
instead of newline makes things annoying in some languages (e.g.,
shell). So I considered it "good enough", but I'd be curious to hear
other opinions.
> > +int credential_read(struct credential *c, FILE *fp)
> > +{
> > ...
> > + c->host = xstrdup(value);
> > + }
> > + else if (!strcmp(key, "path")) {
> > ...
> > + /* ignore other lines; we don't know what they mean, but
> > + * this future-proofs us when later versions of git do
> > + * learn new lines, and the helpers are updated to match */
>
> Two style nits.
I'm supposed to guess? ;P
I know you like blank lines at the top and bottom of multi-line
comments; I often forget that, as they are not part of my usual style (I
find them no easier to read).
I'm guessing the other is an uncuddled else? I can never remember which
we prefer, as we are horribly inconsistent in the current code.
-Peff
^ 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