* Re: [Patch 1/1] Wire html for all files in ./technical and ./howto in Makefile
From: Jeff King @ 2012-11-12 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Ackermann, git
In-Reply-To: <7vpq3iiukk.fsf@alter.siamese.dyndns.org>
On Mon, Nov 12, 2012 at 09:45:31AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Mon, Oct 29, 2012 at 07:33:47PM +0100, Thomas Ackermann wrote:
> >
> >> This patch addresses Junios comment in WC:
> >> "Misapplication of a patch fixed; the ones near the tip needs to
> >> update the links to point at the html files, though."
> >>
> >> See older mail in this thread:
> >> [...]
> >> That means that for the patch [6/8], which adds content-type to the
> >> text files, to be complete, it needs to update Makefile to produce
> >> html files from them.
> >> [...]
> >> So IMHO no open issues with this patch.
> >
> > OK, that explains the situation. Thanks, I'll merge it to master in the
> > next iteration.
>
> What happened to this topic?
I mistyped in the above response; it should have been "next" not
"master".
But then I forgot to merge it to next in the last iteration; it is
ta/doc-cleanup in pu, and is marked in "What's Cooking" to be merged to
next.
-Peff
^ permalink raw reply
* Re: [BUG] gitweb: XSS vulnerability of RSS feed
From: Drew Northup @ 2012-11-12 18:55 UTC (permalink / raw)
To: glpk xypron; +Cc: git, jnareb, Junio C Hamano
In-Reply-To: <20121111232820.284510@gmx.net>
On Sun, Nov 11, 2012 at 6:28 PM, glpk xypron <xypron.glpk@gmx.de> wrote:
> Gitweb can be used to generate an RSS feed.
>
> Arbitrary tags can be inserted into the XML document describing
> the RSS feed by careful construction of the URL.
>
> Example
> http://server/?p=project.git&a=rss&f=</title><script>alert(document.cookie)</script><title>
>
> The generated XML contains
> <script>alert(document.cookie)</script>
>
> Depending on the system used to render the XML this might lead
> to the execution of javascript in the security context of the
> gitweb server pages.
>
> Please, escape all URL parameters.
>
> Version tested:
> gitweb v.1.8.0.dirty with git 1.7.2.5
>
> Best regards
>> Heinrich Schuchardt
Something like this may be useful to defuse the "file" parameter, but
I presume a more definitive fix is in order...
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10ed9e5..af93e65 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1447,6 +1447,10 @@ sub validate_pathname {
if ($input =~ m!\0!) {
return undef;
}
+ # No XSS <script></script> inclusions
+ if ($input =~ m!(<script>)(.*)(</script>)!){
+ return undef;
+ }
return $input;
}
(I am not a perl god, so this was the lowest hanging fruit.)
If desired I'll fashion this up into a proper patch.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply related
* Re: [PATCHv3 1/4] Refactor print_state into get_state
From: Ramkumar Ramachandra @ 2012-11-12 18:29 UTC (permalink / raw)
To: Phil Hord
Cc: git, phil.hord, Jeff King, Junio C Hamano, konglu, Matthieu Moy,
Kong Lucien, Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <1352487385-5929-2-git-send-email-hordp@cisco.com>
Phil Hord wrote:
> Recently git-status learned to display the state of the git
> sequencer in long form to help the user remember an interrupted
> command. This information is useful to other callers who do
> not want it printed in the same way.
Nit: Please mention that "Recently" refers to 83c750ac to save future
readers the trouble of running blame.
Thanks.
Ram
^ permalink raw reply
* Re: splitting off shell test framework
From: Drew Northup @ 2012-11-12 18:18 UTC (permalink / raw)
To: Adam Spiers; +Cc: Git Mailing List, felipe.contreras, Jason J Pyeron CTR (US)
In-Reply-To: <CAOkDyE8KxFvM4CJhC4U=Jb95D6HQ-4qQBtKAgBMyHH15UOhvqg@mail.gmail.com>
On Mon, Nov 12, 2012 at 11:37 AM, Adam Spiers <git@adamspiers.org> wrote:
> Hi all,
>
> I've been pretty impressed with git's test framework, and I'm not
> aware of many other (decent) shell-based test frameworks out there.
> (One that springs to mind is the one used by rvm, but last time I
> looked - admittedly a while ago now - it had limitations).
>
> Recently a situation arose where I craved the ability to test
> something via shell. I did a quick proof of concept and successfully
> extracted out the non-git-specific bits of git's test framework to be
> used to test something entirely unrelated to git:
>
> https://github.com/aspiers/shell-env/tree/master/t
>
> As it turned out to be fairly easy, I was wondering if there would be
> any interest in doing this more formally, i.e. splitting off the
> framework so that it could be used and improved outside the scope of
> git development? Of course this would pose the question how git would
> consume this new project without any risk of destabilisation. I'm
> guessing that simply using a git submodule would solve the problem,
> but ICBW ...
>
> Just an idea. Interesting, or terrible? :)
Done at least once already:
http://comments.gmane.org/gmane.comp.version-control.git/201591
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Phil Hord @ 2012-11-12 18:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <7vip9aiuk8.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Phil Hord <hordp@cisco.com> writes:
>
>> State token strings which may be emitted and their meanings:
>> merge a merge is in progress
>> am an am is in progress
>> am-is-empty the am patch is empty
>> rebase a rebase is in progress
>> rebase-interactive an interactive rebase is in progress
>> cherry-pick a cherry-pick is in progress
>> bisect a bisect is in progress
>> conflicted there are unresolved conflicts
>> commit-pending a commit operation is waiting to be completed
>> splitting interactive rebase, commit is being split
>>
>> I also considered adding these tokens, but I decided it was not
>> appropriate since these changes are not sequencer-related. But
>> it is possible I am being too short-sighted or have chosen the
>> switch name poorly.
>> changed-index Changes exist in the index
>> changed-files Changes exist in the working directory
>> untracked New files exist in the working directory
> I tend to agree; unlike all the normal output from "status -s" that
> are per-file, the above are the overall states of the working tree.
>
> It is just that most of the "overall states" look as if they are
> dominated by "sequencer states", but that is only because you chose
> to call states related to things like "am" and "bisect" that are not
> sequencer states as such.
>
> It probably should be called the tree state, working tree state, or
> somesuch.
I think you are agreeing that I chose the switch name poorly, right?
Do you think '--tree-state' is an acceptable switch or do you have other
suggestions?
Phil
^ permalink raw reply
* Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
From: Junio C Hamano @ 2012-11-12 17:47 UTC (permalink / raw)
To: Michael Haggerty, David Aguilar
Cc: Jiang Xin, Lea Wiemann, David Reiss, Johannes Sixt, git,
Lars R. Damerow, Jeff King, Marc Jordan
In-Reply-To: <508E0FAC.5050600@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> The log message of the original commit (0454dd93bf) described the
> following scenario: a /home partition under which user home directories
> are automounted, and setting GIT_CEILING_DIRECTORIES=/home to avoid
> hitting /home/.git, /home/.git/objects, and /home/objects (which would
> attempt to automount those directories). I believe that this scenario
> would not be slowed down by my patches.
>
> How do you use GIT_CEILING_DIRECTORIES that the proposed changes cause a
> slowdown?
Yeah, I was also wondering about that.
David?
>> Is there another way to accomplish this without the performance hit?
>> Maybe something that can be solved with configuration?
>
> Without doing the symlink expansion there is no way for git to detect
> that GIT_CEILING_DIRECTORIES contains symlinks and is therefore
> ineffective. So the user has no warning about the misconfiguration
> (except that git runs slowly).
>
> On 10/29/2012 02:42 AM, Junio C Hamano wrote:
>> Perhaps not canonicalize elements on the CEILING list ourselves? If
>> we make it a user error to put symlinked alias in the variable, and
>> document it clearly, wouldn't it suffice?
>
> There may be no other choice. (That, and fix the test suite in another
> way to tolerate a $PWD that involves symlinks.)
^ permalink raw reply
* Re: Strange behaviour of git diff branch1 ... branch2
From: Junio C Hamano @ 2012-11-12 17:46 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Aaron Schrab
In-Reply-To: <CACsJy8BkKRxp9AQW0M0vDSL8Mb16VGSrZ1OnQpwCrERWKVLSyA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Sat, Oct 27, 2012 at 7:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>>>
>>>Notice the --cc in the first line, which is combined diff. Usually
>>>combined-diff is between two points and one parent. Though somehow git
>>>passes 4 parents down combined-diff.c:show_combined_header, as you can
>>>see in the "index" line. I think we should fix rev parsing code as it
>>>does not make sense to pass 4 identical parents this way.
>>
>> The two heads home from HEAD...HEAD the user has on the command line.
>>
>> The user is getting exactly what she asked; there is nothing to fix.
>
> Is there any use case where HEAD...HEAD (or "..." alone) is actually useful?
That is an invalid question, implying a proposal that will introduce
more confusion to the users while hurting the code.
There is no use case where "cat A >>A" is actually useful, either,
but it does not mean "cat A >>A" should be special cased to do
something different from what it happens to do in line with the case
where "cat A >>B" does. I think "diff ..." or "diff HEAD...HEAD"
are the same as that example.
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Junio C Hamano @ 2012-11-12 17:45 UTC (permalink / raw)
To: Phil Hord
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <1352487385-5929-4-git-send-email-hordp@cisco.com>
Phil Hord <hordp@cisco.com> writes:
> State token strings which may be emitted and their meanings:
> merge a merge is in progress
> am an am is in progress
> am-is-empty the am patch is empty
> rebase a rebase is in progress
> rebase-interactive an interactive rebase is in progress
> cherry-pick a cherry-pick is in progress
> bisect a bisect is in progress
> conflicted there are unresolved conflicts
> commit-pending a commit operation is waiting to be completed
> splitting interactive rebase, commit is being split
>
> I also considered adding these tokens, but I decided it was not
> appropriate since these changes are not sequencer-related. But
> it is possible I am being too short-sighted or have chosen the
> switch name poorly.
> changed-index Changes exist in the index
> changed-files Changes exist in the working directory
> untracked New files exist in the working directory
I tend to agree; unlike all the normal output from "status -s" that
are per-file, the above are the overall states of the working tree.
It is just that most of the "overall states" look as if they are
dominated by "sequencer states", but that is only because you chose
to call states related to things like "am" and "bisect" that are not
sequencer states as such.
It probably should be called the tree state, working tree state, or
somesuch.
^ permalink raw reply
* Re: [Patch 1/1] Wire html for all files in ./technical and ./howto in Makefile
From: Junio C Hamano @ 2012-11-12 17:45 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Ackermann, git
In-Reply-To: <20121029215739.GG20513@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Oct 29, 2012 at 07:33:47PM +0100, Thomas Ackermann wrote:
>
>> This patch addresses Junios comment in WC:
>> "Misapplication of a patch fixed; the ones near the tip needs to
>> update the links to point at the html files, though."
>>
>> See older mail in this thread:
>> [...]
>> That means that for the patch [6/8], which adds content-type to the
>> text files, to be complete, it needs to update Makefile to produce
>> html files from them.
>> [...]
>> So IMHO no open issues with this patch.
>
> OK, that explains the situation. Thanks, I'll merge it to master in the
> next iteration.
What happened to this topic?
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Junio C Hamano @ 2012-11-12 17:45 UTC (permalink / raw)
To: gitzilla; +Cc: Felipe Contreras, Michael J Gruber, Git Mailing List, Jeff King
In-Reply-To: <509FD9BC.7050204@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> On 11/11/2012 07:41 AM, Felipe Contreras wrote:
>> On Sat, Nov 10, 2012 at 8:25 PM, A Large Angry SCM<gitzilla@gmail.com> wrote:
>>> On 11/10/2012 01:43 PM, Felipe Contreras wrote:
>>
>>>> So, the options are:
>>>>
>>>> a) Leave the name conversion to the export tools, and when they miss
>>>> some weird corner case, like 'Author<email', let the user face the
>>>> consequences, perhaps after an hour of the process.
>>>>
>>>> We know there are sources of data that don't have git-formatted author
>>>> names, so we know every tool out there must do this checking.
>>>>
>>>> In addition to that, let the export tool decide what to do when one of
>>>> these bad names appear, which in many cases probably means do nothing,
>>>> so the user would not even see that such a bad name was there, which
>>>> might not be what they want.
>>>>
>>>> b) Do the name conversion in fast-import itself, perhaps optionally,
>>>> so if a tool missed some weird corner case, the user does not have to
>>>> face the consequences.
>>>>
>>>> The tool writers don't have to worry about this, so we would not have
>>>> tools out there doing a half-assed job of this.
>>>>
>>>> And what happens when such bad names end up being consistent: warning,
>>>> a scaffold mapping of bad names, etc.
>>>>
>>>>
>>>> One is bad for the users, and the tools writers, only disadvantages,
>>>> the other is good for the users and the tools writers, only
>>>> advantages.
>>>>
>>>
>>> c) Do the name conversion, and whatever other cleanup and manipulations
>>> you're interesting in, in a filter between the exporter and git-fast-import.
>>
>> Such a filter would probably be quite complicated, and would decrease
>> performance.
>>
>
> Really?
>
> The fast import stream protocol is pretty simple. All the filter
> really needs to do is pass through everything that isn't a 'commit'
> command. And for the 'commit' command, it only needs to do something
> with the 'author' and 'committer' lines; passing through everything
> else.
>
> I agree that an additional filter _may_ decrease performance somewhat
> if you are already CPU constrained. But I suspect that the effect
> would be negligible compared to the all of the SHA-1 calculations.
More importantly, which do users prefer: quickly produce an
incorrect result, or spend some more time to get it right?
Because the exporting tool has a lot more intimate knowledge about
how the names are represented in the history of the original SCM,
canonicalization of the names, if done at that point, would likely
to give us more useful results, than a canonicalization done at the
beginning of the importer, which lacks SCM specific details. So in
that sense, (a) is more preferrable than (b).
On the other hand, we would want consistency across the converted
results no matter what SCM the history was originally in. E.g. a
name without email that came from CVS or SVN would consistently want
to become "name <noname@noname>" or "name <name>" or whatever, and
letting exporting tools responsible for the canonicalization will
lead them to create their own garbage. In that sense, (b) can be
better than (a).
I think (c) implements worst of both choices. It cannot exploit
knowledge specific to the original SCM like (a) would, and while it
can enforce consistency the same way as (b) would, it would be a
separate program, unlike (b).
So...
^ permalink raw reply
* Re: [PATCH 2/5] launch_editor: ignore SIGINT while the editor has control
From: Junio C Hamano @ 2012-11-12 17:44 UTC (permalink / raw)
To: Jeff King; +Cc: Paul Fox, Kalle Olavi Niemitalo, git
In-Reply-To: <20121111165510.GB19850@sigill.intra.peff.net>
How did this message happen?
Subject: [PATCH 2/5] launch_editor: ignore SIGINT while the editor has control
To: Kalle Olavi Niemitalo <kon@iki.fi>
Cc: Paul Fox <pgf@foxharp.boston.ma.us>, git@vger.kernel.org
Date: Sun, 11 Nov 2012 11:55:11 -0500
Message-ID: <20121111165510.GB19850@sigill.intra.peff.net>
References: <20121111163100.GB13188@sigill.intra.peff.net>
The user's editor likely catches SIGINT (ctrl-C). but if
the user spawns a command from the editor and uses ctrl-C to
kill that command, the SIGINT will likely also kill git
itself (depending on the editor, this can leave the terminal
in an unusable state).
Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
Signed-off-by: Jeff King <peff@peff.net>
---
Judging from S-o-b, message-id and EHLO, I think this was sent by
Peff, but came without Sender: or anything.
Just being curious.
^ permalink raw reply
* Re: [PATCH v5 01/15] fast-export: avoid importing blob marks
From: Junio C Hamano @ 2012-11-12 17:44 UTC (permalink / raw)
To: Jeff King
Cc: Torsten Bögershausen, Felipe Contreras, git,
Johannes Schindelin, Max Horn, Sverre Rabbelier, Brandon Casey,
Brandon Casey, Jonathan Nieder, Ilari Liusvaara, Pete Wyckoff,
Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <20121111163827.GA11408@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> Major issue: "echo -n" is still not portable.
>>
>> Could we simply use
>>
>> touch marks-cur &&
>> touch marks-new
>
> Yes, "echo -n" is definitely not portable. Our preferred way of
> creating an empty file is just ">file".
Yes.
And it is misleading to use "touch" in this case; unless you are
updating the timestamp of an existing file while preserving the
contents of it, please don't use the command.
Thanks.
^ permalink raw reply
* Re: [PATCH] Re:gitweb: add readme to overview page
From: Junio C Hamano @ 2012-11-12 17:44 UTC (permalink / raw)
To: Heinrich Schuchardt; +Cc: git
In-Reply-To: <1352652039-31453-1-git-send-email-xypron.glpk@gmx.de>
Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
> In this version of the patch the formatting has been corrected.
>
> Warnings for double / in filenames are avoided.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>
> ---
The above is *not* a proper log message.
Those of us who are reading the messages on the list would know that
this is a replacement for your earlier
Message-ID: <1352647962-21910-1-git-send-email-xypron.glpk@gmx.de>
where it has more proper description of the change, but because
nobody will be applying that earlier one to the history (instead,
you would want this version to be applied), the description is lost
in the history.
> gitweb/gitweb.perl | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 10ed9e5..699ffac 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -6369,6 +6369,18 @@ sub git_project_list {
> }
>
> git_project_search_form($searchtext, $search_use_regexp);
> + # If XSS prevention is on, we don't include README.html.
> + # TODO: Allow a readme in some safe format.
> + my $path = "";
> + if (defined $project_filter) {
> + $path = "/$project_filter";
> + }
> + if (!$prevent_xss && -s "$projectroot$path/README.html") {
> + print "<div class=\"title\">readme</div>\n" .
> + "<div class=\"readme\">\n";
> + insert_file("$projectroot$path/README.html");
> + print "\n</div>\n"; # class="readme"
> + }
> git_project_list_body(\@list, $order);
> git_footer_html();
> }
^ permalink raw reply
* Re: [PATCH 1/2] git-sh-setup: refactor ident-parsing functions
From: Junio C Hamano @ 2012-11-12 17:44 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Ilya Basin, git
In-Reply-To: <20121018072522.GA9999@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The only ident-parsing function we currently provide is
> get_author_ident_from_commit. This is not very
> flexible for two reasons:
>
> 1. It takes a commit as an argument, and can't read from
> commit headers saved on disk.
>
> 2. It will only parse authors, not committers.
>
> This patch provides a more flexible interface which will
> parse multiple idents from a commit provide on stdin. We can
> easily use it as a building block for the current function
> to retain compatibility.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Since we are counting processes in this series, I should note that this
> actually adds a subshell invocation for each call, since it went from:
>
> script='...'
> sed $script
>
> to:
>
> sed "$(make_script)"
>
> For filter-branch, which is really the only high-performance caller we
> have, this is negated by the fact that it will do author and committer
> at the same time, saving us an extra subshell (in addition to an extra
> sed invocation).
Given that pick-ident-script is a const function, a caller that
repeatedly call is could call it once and use it in a variable, no?
>
> git-sh-setup.sh | 62 +++++++++++++++++++++++++++++++++++++++------------------
> 1 file changed, 43 insertions(+), 19 deletions(-)
>
> diff --git a/git-sh-setup.sh b/git-sh-setup.sh
> index ee0e0bc..22f0aed 100644
> --- a/git-sh-setup.sh
> +++ b/git-sh-setup.sh
> @@ -191,28 +191,52 @@ get_author_ident_from_commit () {
> fi
> }
>
> +# Generate a sed script to parse identities from a commit.
> +#
> +# Reads the commit from stdin, which should be in raw format (e.g., from
> +# cat-file or "--pretty=raw").
> +#
> +# The first argument specifies the ident line to parse (e.g., "author"), and
> +# the second specifies the environment variable to put it in (e.g., "AUTHOR"
> +# for "GIT_AUTHOR_*"). Multiple pairs can be given to parse author and
> +# committer.
> +pick_ident_script () {
> + while test $# -gt 0
> + do
> + lid=$1; shift
> + uid=$1; shift
> + printf '%s' "
> + /^$lid /{
> + s/'/'\\\\''/g
> + h
> + s/^$lid "'\([^<]*\) <[^>]*> .*$/\1/'"
> + s/.*/GIT_${uid}_NAME='&'/p
> +
> + g
> + s/^$lid "'[^<]* <\([^>]*\)> .*$/\1/'"
> + s/.*/GIT_${uid}_EMAIL='&'/p
> +
> + g
> + s/^$lid "'[^<]* <[^>]*> \(.*\)$/@\1/'"
> + s/.*/GIT_${uid}_DATE='&'/p
> + }
> + "
> + done
> + echo '/^$/q'
> +}
> +
> +# Create a pick-script as above and feed it to sed. Stdout is suitable for
> +# feeding to eval.
> +parse_ident_from_commit () {
> + LANG=C LC_ALL=C sed -ne "$(pick_ident_script "$@")"
> +}
> +
> +# Parse the author from a commit given as an argument. Stdout is suitable for
> +# feeding to eval to set the usual GIT_* ident variables.
> get_author_ident_from_commit () {
> - pick_author_script='
> - /^author /{
> - s/'\''/'\''\\'\'\''/g
> - h
> - s/^author \([^<]*\) <[^>]*> .*$/\1/
> - s/.*/GIT_AUTHOR_NAME='\''&'\''/p
> -
> - g
> - s/^author [^<]* <\([^>]*\)> .*$/\1/
> - s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
> -
> - g
> - s/^author [^<]* <[^>]*> \(.*\)$/@\1/
> - s/.*/GIT_AUTHOR_DATE='\''&'\''/p
> -
> - q
> - }
> - '
> encoding=$(git config i18n.commitencoding || echo UTF-8)
> git show -s --pretty=raw --encoding="$encoding" "$1" -- |
> - LANG=C LC_ALL=C sed -ne "$pick_author_script"
> + parse_ident_from_commit author AUTHOR
> }
>
> # Clear repo-local GIT_* environment variables. Useful when switching to
^ permalink raw reply
* Re: [PATCH] Documentation/log: fix description of format.pretty
From: Junio C Hamano @ 2012-11-12 17:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <20121112153855.GA3546@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Ramkumar Ramachandra wrote:
>
>> Oops, I read about `--pretty` in pretty-formats.txt and didn't realize
>> that `--format` existed. However, your patch is still wrong because
>> there seems to be a subtle (and confusing) difference between
>> `--pretty` and `--format`. In the latter, you can't omit the format,
>> and expect it to be picked up from format.pretty:
>>
>> $ git log --format
>> fatal: unrecognized argument: --format
We probably should say "--format needs an argument" here.
> ... It is based on the
> following text from Documentation/config.txt:
>
> format.pretty::
> The default pretty format for log/show/whatchanged command,
> See linkgit:git-log[1], linkgit:git-show[1],
> linkgit:git-whatchanged[1].
>
> I do imagine it can be made clearer. s/--format/--pretty/ does not go
> far enough --- it only replaces one confusing explanation with
> another.
The --format and --pretty are more or less the same thing since
3a4c1a5 (Add --format that is a synonym to --pretty, 2009-02-24).
The --format option was added as a synonym because majority of new
users who have never heard of --pretty found it more natural; in
that sense, Ram's patch goes backwards.
The entry in config.txt came from 94c22a5 (log/show/whatchanged:
introduce format.pretty configuration, 2008-03-02) that predates the
synonym, and originally it was to allow
[format] pretty = fuller
to make "git log" by default use "git log --pretty=fuller" in the
configuration; back then there wasn't a support for custom formats
like
[format] pretty = "%h %s"
until 3640754 (Give short-hands to --pretty=tformat:%formatstring,
2009-02-24) introduced it.
"The default pretty format" in the description was written to refer
to the original "raw/medium/short/email/full/fuller" set, but these
days, we accept anything that you can write after "--pretty=" (or
its synonym "--format=") on the command line.
This is one of the reasons why I do not want to see abbreviated
descriptions for configuration variables duplicated in the manual
pages of individual commands, as the practice tends to lead to this
kind of confusion.
^ permalink raw reply
* [PATCH 4/4] remote-hg: avoid bad refs
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1352742068-15346-1-git-send-email-felipe.contreras@gmail.com>
Turns out fast-export throws bad 'reset' commands because of a behavior
in transport-helper that is not even needed.
Either way, better to ignore them, otherwise the user will get warnings
when we OK them.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 3cdc1e2..48f8f5d 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -704,6 +704,9 @@ def do_export(parser):
elif ref.startswith('refs/tags/'):
tag = ref[len('refs/tags/'):]
parser.repo.tag([tag], node, None, True, None, {})
+ else:
+ # transport-helper/fast-export bugs
+ continue
print "ok %s" % ref
print
--
1.8.0
^ permalink raw reply related
* [PATCH 3/4] remote-hg: try the 'tip' if no checkout present
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1352742068-15346-1-git-send-email-felipe.contreras@gmail.com>
There's no concept of HEAD in mercurial, but let's try our best to do
something sensible.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-hg | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index c6d0367..3cdc1e2 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -440,6 +440,8 @@ def list_head(repo, cur):
head = cur
node = repo['.']
if not node:
+ node = repo['tip']
+ if not node:
return
if head == 'default':
head = 'master'
--
1.8.0
^ permalink raw reply related
* [PATCH 2/4] remote-hg: fix compatibility with older versions of hg
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1352742068-15346-1-git-send-email-felipe.contreras@gmail.com>
Turns out repo.revs was introduced quite late, and it doesn't do
anything fancy for our refspec; only list all the numbers in that range.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 1d46838..c6d0367 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -294,7 +294,7 @@ def export_ref(repo, name, kind, head):
if tip and tip == head.rev():
# nothing to do
return
- revs = repo.revs('%u:%u' % (tip, head))
+ revs = xrange(tip, head.rev() + 1)
count = 0
revs = [rev for rev in revs if not marks.is_marked(rev)]
--
1.8.0
^ permalink raw reply related
* [PATCH 1/4] remote-hg: add missing config for basic tests
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Ramkumar Ramachandra
In-Reply-To: <1352742068-15346-1-git-send-email-felipe.contreras@gmail.com>
From: Ramkumar Ramachandra <artagnon@gmail.com>
'hg commit' fails otherwise in some versiosn of mercurial because of
the missing user information. Other versions simply throw a warning and
guess though.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/test-hg.sh | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
index 40e6e3c..031dcbd 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -29,6 +29,15 @@ check () {
test_cmp expected actual
}
+setup () {
+ (
+ echo "[ui]"
+ echo "username = A U Thor <author@example.com>"
+ ) >> "$HOME"/.hgrc
+}
+
+setup
+
test_expect_success 'cloning' '
test_when_finished "rm -rf gitrepo*" &&
--
1.8.0
^ permalink raw reply related
* [PATCH 0/4] remote-hg: small fixes
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Hi,
Just a few fixes, nothing major.
Felipe Contreras (3):
remote-hg: fix compatibility with older versions of hg
remote-hg: try the 'tip' if no checkout present
remote-hg: avoid bad refs
Ramkumar Ramachandra (1):
remote-hg: add missing config for basic tests
contrib/remote-helpers/git-remote-hg | 7 ++++++-
contrib/remote-helpers/test-hg.sh | 9 +++++++++
2 files changed, 15 insertions(+), 1 deletion(-)
--
1.8.0
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Douglas Mencken @ 2012-11-12 17:13 UTC (permalink / raw)
To: Kevin; +Cc: git
In-Reply-To: <CAO54GHA=r8WUK3okm2imVkoB=SuZ=3o+wwdwLr_rmPXhdFzG_g@mail.gmail.com>
> Maybe handy to say that you're on a Powerpc platform.
My host, build and target is: powerpc-linux-gnu
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Kevin @ 2012-11-12 17:12 UTC (permalink / raw)
To: Douglas Mencken; +Cc: git
In-Reply-To: <CACYvZ7jPd0_XD6YVdfJ2AnKRnKewmzX4uu7w3zt+_gK+qU49gQ@mail.gmail.com>
Maybe handy to say that you're on a Powerpc platform.
On Mon, Nov 12, 2012 at 5:32 PM, Douglas Mencken <dougmencken@gmail.com> wrote:
> *Any* git clone fails with:
>
> fatal: premature end of pack file, 106 bytes missing
> fatal: index-pack failed
>
> At first, I tried 1.8.0, and it failed. Then I tried to build 1.7.10.5
> then, and it worked. Then I tried 1.7.12.2, but it fails the same way
> as 1.8.0.
> So I decided to git bisect.
>
^ permalink raw reply
* RE: splitting off shell test framework
From: Pyeron, Jason J CTR (US) @ 2012-11-12 16:57 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <CAMP44s2n56c=k4o6wup81Hb3WNzuDLkL30GpMdivQixJX_YOsw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
> -----Original Message-----
> From: Felipe Contreras
> Sent: Monday, November 12, 2012 11:44 AM
>
> On Mon, Nov 12, 2012 at 5:37 PM, Adam Spiers <git@adamspiers.org>
> wrote:
>
> > I've been pretty impressed with git's test framework, and I'm not
> > aware of many other (decent) shell-based test frameworks out there.
> > (One that springs to mind is the one used by rvm, but last time I
> > looked - admittedly a while ago now - it had limitations).
> >
> > Recently a situation arose where I craved the ability to test
> > something via shell. I did a quick proof of concept and successfully
> > extracted out the non-git-specific bits of git's test framework to be
> > used to test something entirely unrelated to git:
> >
> > https://github.com/aspiers/shell-env/tree/master/t
> >
> > As it turned out to be fairly easy, I was wondering if there would be
> > any interest in doing this more formally, i.e. splitting off the
> > framework so that it could be used and improved outside the scope of
> > git development? Of course this would pose the question how git
> would
> > consume this new project without any risk of destabilisation. I'm
> > guessing that simply using a git submodule would solve the problem,
> > but ICBW ...
>
> FWIW, the notmuch project seems to be doing the same; extracting and
> using git's test framework.
The Apache Maven project is migrating to GIT right now and they just covered a long discussion on the pros and cons of this (sort of). It might be a bit of a read [1] but I can also provide some perspective. The question is asked in reverse in [2] since Maven had them separate and some suggested to merge them.
1: http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3cA5D13406-474A-43E6-9708-D5D4DE9BE64C@tesla.io%3e
2: http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3c1349937687.79626.YahooMailNeo@web28903.mail.ir2.yahoo.com%3e
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: splitting off shell test framework
From: Felipe Contreras @ 2012-11-12 16:44 UTC (permalink / raw)
To: Adam Spiers; +Cc: Git Mailing List
In-Reply-To: <CAOkDyE8KxFvM4CJhC4U=Jb95D6HQ-4qQBtKAgBMyHH15UOhvqg@mail.gmail.com>
On Mon, Nov 12, 2012 at 5:37 PM, Adam Spiers <git@adamspiers.org> wrote:
> I've been pretty impressed with git's test framework, and I'm not
> aware of many other (decent) shell-based test frameworks out there.
> (One that springs to mind is the one used by rvm, but last time I
> looked - admittedly a while ago now - it had limitations).
>
> Recently a situation arose where I craved the ability to test
> something via shell. I did a quick proof of concept and successfully
> extracted out the non-git-specific bits of git's test framework to be
> used to test something entirely unrelated to git:
>
> https://github.com/aspiers/shell-env/tree/master/t
>
> As it turned out to be fairly easy, I was wondering if there would be
> any interest in doing this more formally, i.e. splitting off the
> framework so that it could be used and improved outside the scope of
> git development? Of course this would pose the question how git would
> consume this new project without any risk of destabilisation. I'm
> guessing that simply using a git submodule would solve the problem,
> but ICBW ...
FWIW, the notmuch project seems to be doing the same; extracting and
using git's test framework.
> Just an idea. Interesting, or terrible? :)
That I don't know :)
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 11/15] remote-testgit: make clear the 'done' feature
From: Felipe Contreras @ 2012-11-12 16:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Max Horn, git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <20121112154515.GB3546@elie.Belkin>
On Mon, Nov 12, 2012 at 4:45 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Max Horn wrote:
>
>> Aha, now I understand what this patch is about. So I would suggest
>> this alternate commit message:
>>
>> remote-testgit: make it explicit clear that we use the 'done' feature
>>
>> Previously we relied on passing '--use-done-feature ' to git
>> fast-export, which is easy to miss when looking at this script.
>
> I'm not immediately sure I agree this is even a problem. Is the point
> that other fast-import frontends do not have a --use-done-feature
> switch,
You mean other fast-exports.
And what other fast-exports? Most remote helpers don't use an external
fast-export tool, and the only I know that used one is the one I wrote
(and is now deprecated) that used bzr fast-export, and no, that one
didn't support the done feature.
Most remote helpers would probably be doing the equivalent of
fast-export themselves.
> so a typical remote helper has to do that work itself, and the
> sample "testgit" remote helper would be a more helpful example by
> doing that work itself?
Yes.
> The idea behind --use-done-feature is that if fast-export exits early
> for some reason and its output is going to a pipe then at least the
> stream will be malformed, making it easier to catch errors. So there
> is something to be weighed here: is it more important to illustrate
> how to make your fast-export tool's output prefix-free,
What fast-export tool?
This is a remote helper.
> or is it more
> important to illustrate how to work around a fast-export tool that
> doesn't support that feature?
Ditto.
If you want to launch a campaign of adding the 'done' feature to
whatever fast-export tools are out there (that I'm not aware of), go
ahead, but this is about remote helpers, most (all?) of which would
not use a fast-export tool to achieve the export, but do it
themselves.
Cheers.
--
Felipe Contreras
^ 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