* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 23:39 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Alex Riesen, git
In-Reply-To: <alpine.DEB.2.00.0901120324490.18989@vellum.laroia.net>
Asheesh Laroia wrote:
> On Mon, 12 Jan 2009, Jakub Narebski wrote:
>
> > But I have to run
> >
> > $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
> >
> > first. Is there any way to automate this?
>
> Check out 'gstm' or 'autossh'.
I don't know about gSTM (Gnome SSH Tunnel Manager), but autossh
does only provide reconnect in the case the gateway host closes
connection. I still have to run it, perhaps from startup script.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 23:43 UTC (permalink / raw)
To: Mike Hommey; +Cc: Alex Riesen, git
In-Reply-To: <20090112122337.GA7262@glandium.org>
On Mon, 12 January 2009, Mike Hommey wrote:
> On Mon, Jan 12, 2009 at 12:13:44PM +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>> Currently I have the folowing in my ~/.ssh/config:
>>
>> # TP S.A. blocks repo.or.cz
>> Host repo.or.cz
>> NoHostAuthenticationForLocalhost yes
>> HostName localhost
>> Port 2222
>>
>> and I can simply use "git push repo" without any changes.
>> But I have to run
>>
>> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>>
>> first. Is there any way to automate this?
>
> Something like the following should do the trick:
> Host repo.or.cz
> ProxyCommand ssh jnareb@host.example.com nc %h %p
>
> You will need nc (netcat) installed on the host.example.com server, though.
I assume that is both in place of above ~/.ssh/config configuration,
and making unnecessary port forwarding (ssh -L) invocation, isn't it?
P.S. What should I put in core.gitProxy to make it possible to fetch
via git:// protocol from repo.or.cz?
--
Jakub Narebski
Poland
^ permalink raw reply
* git-patches list?
From: Akira Kitada @ 2009-01-12 23:43 UTC (permalink / raw)
To: git
Hi,
Can I propose having another mailing list for posting patches to avoid
daily mail flood to this list?
Yes, I can filter out the emails but still...
Thanks,
^ permalink raw reply
* Re: git-patches list?
From: Junio C Hamano @ 2009-01-12 23:54 UTC (permalink / raw)
To: Akira Kitada; +Cc: git
In-Reply-To: <90bb445a0901121543q29d30d49yaa723b4b913a4b31@mail.gmail.com>
Akira Kitada <akitada@gmail.com> writes:
> Can I propose having another mailing list for posting patches to avoid
> daily mail flood to this list?
>
> Yes, I can filter out the emails but still...
This list has always been the only place where git development happens.
It would make the development very awkward to set up another list only for
patches, forbid patches to be sent to anywhere but that new list, but
still discuss the patches on this list.
It does not make much sense to me.
Consider what you would do when you see a problem somebody is having on
this list, and wanted to respond with a quick "this may fix it" patch?
Should you be sending that to the patches list, and sending a separate
message to this list saying that you have a potential fix in mind you
would want to discuss here, but the patches list rule mandated that you
had to send the patch to the other list, asking people who are reading
this list to look at the other list as well?
And no, having a separate "user list" won't solve the above problem either
and that is not what I am suggesting.
Not that I am seeing any problem right now; I am saying that the split
list as you suggest _will_ create problems.
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Jakub Narebski @ 2009-01-12 23:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Davide Libenzi, Thomas Rast
In-Reply-To: <alpine.DEB.1.00.0901101507590.30769@pacific.mpi-cbg.de>
Hello!
On Sat, 10 Jan 2009, Johannes Schindelin wrote:
> On Sat, 10 Jan 2009, Jakub Narebski wrote:
>> On Sat, 10 Jan 2009, Johannes Schindelin wrote:
>>> On Sat, 10 Jan 2009, Jakub Narebski wrote:
>>>> Thomas Rast wrote:
>>>>
>>>>> --color-words works (and always worked) by splitting words onto one
>>>>> line each, and using the normal line-diff machinery to get a word
>>>>> diff.
>>>>
>>>> Cannot we generalize diff machinery / use underlying LCS diff engine
>>>> instead of going through line diff?
>>>
>>> What do you think we're doing? libxdiff is pretty hardcoded to newlines.
>>> That's why we're substituting non-word characters with newlines.
>>
>> Isn't Meyers algorithm used by libxdiff based on LCS, largest common
>> subsequence, and doesn't it generate from the mathematical point of
>> view "diff" between two sequences (two arrays) which just happen to
>> be lines? It is a bit strange that libxdiff doesn't export its low
>> level algorithm...
>
> Umm.
>
> It _is_ Myers' algorithm. It just so happens that libxdiff hardcodes
> newline to be the separator.
So amd I to understand that _exported_ functions hardcode separator
to be newline (most probably for performance), and there is no function
in libxdiff which calculates LCS, or returns diff for arrays
(sequences)?
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitweb: recognize six digit abbreviated SHA1
From: Anders Melchiorsen @ 2009-01-13 0:04 UTC (permalink / raw)
To: git; +Cc: jnareb, gitster
This lets gitweb hightlight abbreviated hashes as produced by
git rev-parse --short.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
It seems like seven digit hashes are in vogue now. So, did I miss some
reason for keeping it at eight in this spot?
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0ac84d1..1a7d448 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1337,7 +1337,7 @@ sub format_log_line_html {
my $line = shift;
$line = esc_html($line, -nbsp=>1);
- if ($line =~ m/([0-9a-fA-F]{8,40})/) {
+ if ($line =~ m/([0-9a-fA-F]{7,40})/) {
my $hash_text = $1;
my $link =
$cgi->a({-href => href(action=>"object", hash=>$hash_text),
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* Re: [PATCH] gitweb: recognize six digit abbreviated SHA1
From: Anders Melchiorsen @ 2009-01-13 0:08 UTC (permalink / raw)
To: git; +Cc: jnareb, gitster
In-Reply-To: <87mydw2hrb.fsf@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> + if ($line =~ m/([0-9a-fA-F]{7,40})/) {
I could not make up my mind between the seven digits from "git
rev-parse --short" and the six digits currently used by gitk.
So I put one option in the patch, and the other one in the subject.
Cheers,
Anders.
^ permalink raw reply
* Re: [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
From: Jakub Narebski @ 2009-01-13 0:13 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0901111859q3a166d92k5176b27af2c4d256@mail.gmail.com>
On Mon, 12 Jan 2009, Giuseppe Bilotta wrote:
> On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Commit 4afbaef by Giuseppe Bilotta (gitweb: ref markers link to named
> > shortlogs) turned ref markers for tags and heads into links to
> > appropriate views for the ref name.
> >
> > Unfortunately the code didn't take into account the fact that nesting
> > links (A elements) is illegal in (X)HTML:
> >
> > 12.2.2 Nested links are illegal
> >
> > Links and anchors defined by the A element must not be nested;
> > an A element must not contain any other A elements.
[...]
> > What is more complicated is the issue of ref marker from
> > git_print_header_div e.g. in 'commit'/'commitdiff' view, and in 'log'
> > view. There link is made into block element using "display: block;"
> > CSS rule (div.title, a.title), so that you can click _anywhere_ on the
> > header block. This breaks layout even worse, making hyperlinked ref
> > marker text appear *below* header div:
> >
> > -----------------------------------------------------------
> > |_Merge branch into maint_ [] |
> > -----------------------------------------------------------
> > _maint_
> >
> > To preserve current layout and behavior it would be needed to do some
> > deep HTML + CSS positioning hackery, perhaps with additional link block
> > without any text... But I don't know exactly how to do this; all [few]
> > experiments I did failed.
> >
> > I see possible the following alternate solutions:
> > * Ignore this issue (e.g. if it does not affect modern browsers)
>
> That would be my current choice until we find a better solution.
By the way, how common this error is? Could you check if _your_ web
browser (Firefox, Internet Explorer, Opera, Konqueror, Safari, Chrome)
does show this bug or not, please?
> > * Revert 4afbaef (we lose feature, but how often used is it?)
> > * Always use quirks mode, or check browser and use quirks mode if it
> > would break layout
> > * Use extra divs and links and CSS positioning to make layout which
> > looks like current one, and behaves as current one, but is more
> > complicated.
>
> I'm asking on #html, hopefully I'll get some interesting idea to try for this.
I have found _a_ solution. Perhaps not the best one, but it works.
And IMHO gives / can give even better visual.
Current version (line wrapped for better visibility):
<div class="header">
<a class="title" href="...">GIT 1.6.1
<span class="refs">
<span class="tag indirect" title="tags/v1.6.1">
<a href="...">v1.6.1</a>
</span>
</span>
</a>
</div>
Current CSS (relevant part):
a.title {
display: block;
padding: 6px 8px;
}
Current rendering:
-----------------------------------------------------------
|_GIT 1.6.1_ [] |
-----------------------------------------------------------
__v1.6.1__
Proposed code (line wrapped for better visibility, with CSS embedded,
which would change in final version of course). Only parts of style
related to positioning are shown.
<div class="header">
<a href="..." style="float: left; margin: 6px 1px 6px 8px;">GIT 1.6.1</a>
<div style="float: left; margin: 6px 1px;">
<span class="refs">
<span class="tag indirect" title="tags/v1.6.1">
<a href="...">v1.6.1</a>
</span>
</span>
</div>
<a href="..." style="display: block; padding: 6px 8px;"> </a>
</div>
Rendering with proposed code:
-----------------------------------------------------------
_|_GIT 1.6.1_ [_v1.6.1_] |_
-----------------------------------------------------------
I guess that instead of additional DIV element, we could use DIV for
.refs, or use "float: right" style with SPAN element. I have not
checked if other variations works: this one does.
What do you think?
--
Jakub Narebski
Poland
^ permalink raw reply
* the meaning of keephardlinks
From: Geoff Russell @ 2009-01-13 0:17 UTC (permalink / raw)
To: git
I'm curious about what keephardlinks means.
If I do: "ln X Y ; git add Y ; git commit" in my origin and then
"git pull" in my cloned repository,
should I get a hard linked file in the clone
when core.keephardlinks is set to true?
Cheers,
Geoff Russell
^ permalink raw reply
* Re: [PATCH] Fix Dcoumentation typos surrounding the word 'handful'.
From: Markus Heidelberg @ 2009-01-13 0:31 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1231790527-7515-1-git-send-email-jdl@freescale.com>
Jon Loeliger, 12.01.2009:
> +++ b/Documentation/git-ls-tree.txt
> @@ -59,7 +59,7 @@ OPTIONS
>
> --abbrev[=<n>]::
> Instead of showing the full 40-byte hexadecimal object
> - lines, show only handful hexdigits prefix.
> + lines, show only a partal prefix.
partial :)
Markus
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Johannes Schindelin @ 2009-01-13 0:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Davide Libenzi, Thomas Rast
In-Reply-To: <200901130059.19511.jnareb@gmail.com>
Hi,
On Tue, 13 Jan 2009, Jakub Narebski wrote:
> On Sat, 10 Jan 2009, Johannes Schindelin wrote:
> > On Sat, 10 Jan 2009, Jakub Narebski wrote:
> >> On Sat, 10 Jan 2009, Johannes Schindelin wrote:
> >>> On Sat, 10 Jan 2009, Jakub Narebski wrote:
> >>>> Thomas Rast wrote:
> >>>>
> >>>>> --color-words works (and always worked) by splitting words onto one
> >>>>> line each, and using the normal line-diff machinery to get a word
> >>>>> diff.
> >>>>
> >>>> Cannot we generalize diff machinery / use underlying LCS diff engine
> >>>> instead of going through line diff?
> >>>
> >>> What do you think we're doing? libxdiff is pretty hardcoded to newlines.
> >>> That's why we're substituting non-word characters with newlines.
> >>
> >> Isn't Meyers algorithm used by libxdiff based on LCS, largest common
> >> subsequence, and doesn't it generate from the mathematical point of
> >> view "diff" between two sequences (two arrays) which just happen to
> >> be lines? It is a bit strange that libxdiff doesn't export its low
> >> level algorithm...
> >
> > Umm.
> >
> > It _is_ Myers' algorithm. It just so happens that libxdiff hardcodes
> > newline to be the separator.
>
> So amd I to understand that _exported_ functions hardcode separator
> to be newline (most probably for performance), and there is no function
> in libxdiff which calculates LCS, or returns diff for arrays
> (sequences)?
That is my understanding, yes.
Ciao,
Dscho
^ permalink raw reply
* Re: the meaning of keephardlinks
From: Johannes Schindelin @ 2009-01-13 0:42 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0901121617m43af82a7te946b1607fbf3f77@mail.gmail.com>
Hi,
On Tue, 13 Jan 2009, Geoff Russell wrote:
> I'm curious about what keephardlinks means.
>
> If I do: "ln X Y ; git add Y ; git commit" in my origin and then
> "git pull" in my cloned repository,
> should I get a hard linked file in the clone
> when core.keephardlinks is set to true?
Nope.
It means that if you have a hard link locally, it will stay a hard link
(and if it is modified, the other linked files will obviously change,
too).
Note that this feature is not even in 'next'.
Ciao,
Dscho
^ permalink raw reply
* [PATCH/RFC] contrib/examples/README: warn of obsolescence
From: jidanni @ 2009-01-13 0:45 UTC (permalink / raw)
To: git
We attempt to give an explanation of the status of the files in this
directory.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
contrib/examples/README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 contrib/examples/README
diff --git a/contrib/examples/README b/contrib/examples/README
new file mode 100644
index 0000000..b10910c
--- /dev/null
+++ b/contrib/examples/README
@@ -0,0 +1 @@
+Note that these are obsolete versions of programs now replaced by C code.
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH v2] make diff --color-words customizable
From: Jakub Narebski @ 2009-01-13 0:52 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Johannes Schindelin, git, Thomas Rast
In-Reply-To: <alpine.DEB.1.10.0901100950230.21891@alien.or.mcafeemobile.com>
On Sat, 10 Jan 2009, Davide Libenzi wrote:
> On Sat, 10 Jan 2009, Jakub Narebski wrote:
>> On Sat, 10 Jan 2009, Johannes Schindelin wrote:
>>> On Sat, 10 Jan 2009, Jakub Narebski wrote:
>>>> Thomas Rast wrote:
>>>>
>>>>> --color-words works (and always worked) by splitting words onto one
>>>>> line each, and using the normal line-diff machinery to get a word
>>>>> diff.
>>>>
>>>> Cannot we generalize diff machinery / use underlying LCS diff engine
>>>> instead of going through line diff?
>>>
>>> What do you think we're doing? libxdiff is pretty hardcoded to newlines.
>>> That's why we're substituting non-word characters with newlines.
>>
>> Isn't Meyers algorithm used by libxdiff based on LCS, largest common
>> subsequence, and doesn't it generate from the mathematical point of
>> view "diff" between two sequences (two arrays) which just happen to
>> be lines? It is a bit strange that libxdiff doesn't export its low
>> level algorithm...
>
> The core doesn't know anything about lines. Only pre-processing (setting
> up the hash by tokenizing the input) and post-processing (adding '\n' to
> the end of each token), knows about newlines. Memory consumption would
> increase significantly though, since there is a per-token cost, and a
> word-based diff will create more of them WRT the same input.
Is this core algorithm available as some exported function in libxdiff?
I mean would it be easy to replace default line tokenizer (per-line
pre-processing) and post-processing to better deal with word diff?
The other side would be to generate per-paragraph diffs (with empty
line being separator)...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git/webdav is refusing to authenticate properly.
From: Peter Spierenburg @ 2009-01-13 0:35 UTC (permalink / raw)
Cc: git
In-Reply-To: <alpine.DEB.1.00.0901130003490.3586@pacific.mpi-cbg.de>
C'mon, leave my password 'in-the-clear', in a text file on a networked
box? That is the kind of prank a fourth-year student would try to pull
on a freshman.
How do I really do it?
Peter.
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Jan 2009, Peter Spierenburg wrote:
>
>
>> I'm trying to push a local git repository to a remote site using WebDAV,
>> but it is eating my lunch.
>>
>
> Please see Documentation/howto/setup-git-server-over-http.txt.
>
> In short, http-push does not ask for a password interactively, but you
> have to use .netrc.
>
> Hth,
> Dscho
>
>
^ permalink raw reply
* Re: [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
From: Giuseppe Bilotta @ 2009-01-13 0:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901130113.54517.jnareb@gmail.com>
On Mon, Jan 12, 2009 at 7:13 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 12 Jan 2009, Giuseppe Bilotta wrote:
>> On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> > I see possible the following alternate solutions:
>> > * Ignore this issue (e.g. if it does not affect modern browsers)
>>
>> That would be my current choice until we find a better solution.
>
> By the way, how common this error is? Could you check if _your_ web
> browser (Firefox, Internet Explorer, Opera, Konqueror, Safari, Chrome)
> does show this bug or not, please?
Opera works fine (no display or functionality anomaly). That makes
sense, since I was the one who submitted the patch 8-D. Konqueror
3.5.9 does the ugly thing instead.
Notice that nested links are actually valid *XML*. Indeed, I asked on
www-style and they suggested leaving the problem as-is, serving as
html+xml which is what we do.
>> > * Revert 4afbaef (we lose feature, but how often used is it?)
>> > * Always use quirks mode, or check browser and use quirks mode if it
>> > would break layout
>> > * Use extra divs and links and CSS positioning to make layout which
>> > looks like current one, and behaves as current one, but is more
>> > complicated.
>>
>> I'm asking on #html, hopefully I'll get some interesting idea to try for this.
>
> I have found _a_ solution. Perhaps not the best one, but it works.
> And IMHO gives / can give even better visual.
>
> Current version (line wrapped for better visibility):
> <div class="header">
> <a class="title" href="...">GIT 1.6.1
> <span class="refs">
> <span class="tag indirect" title="tags/v1.6.1">
> <a href="...">v1.6.1</a>
> </span>
> </span>
> </a>
> </div>
>
> Current CSS (relevant part):
> a.title {
> display: block;
> padding: 6px 8px;
> }
>
> Current rendering:
> -----------------------------------------------------------
> |_GIT 1.6.1_ [] |
> -----------------------------------------------------------
> __v1.6.1__
>
>
> Proposed code (line wrapped for better visibility, with CSS embedded,
> which would change in final version of course). Only parts of style
> related to positioning are shown.
> <div class="header">
> <a href="..." style="float: left; margin: 6px 1px 6px 8px;">GIT 1.6.1</a>
> <div style="float: left; margin: 6px 1px;">
> <span class="refs">
> <span class="tag indirect" title="tags/v1.6.1">
> <a href="...">v1.6.1</a>
> </span>
> </span>
> </div>
> <a href="..." style="display: block; padding: 6px 8px;"> </a>
> </div>
>
> Rendering with proposed code:
> -----------------------------------------------------------
> _|_GIT 1.6.1_ [_v1.6.1_] |_
> -----------------------------------------------------------
>
> I guess that instead of additional DIV element, we could use DIV for
> .refs, or use "float: right" style with SPAN element. I have not
> checked if other variations works: this one does.
>
> What do you think?
The float thing was the second suggestion I was given on www-style.
Can you provide a patch I can apply to my tree for testing to see how
it comes up?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Markus Heidelberg @ 2009-01-13 0:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Mike Hommey, Alex Riesen, git
In-Reply-To: <200901130043.04772.jnareb@gmail.com>
Jakub Narebski, 13.01.2009:
> P.S. What should I put in core.gitProxy to make it possible to fetch
> via git:// protocol from repo.or.cz?
I'm not sure if this is what you need, but I use this at work for
fetching via git protocol:
[core]
gitProxy = /etc/gitproxy.sh for kernel.org
gitProxy = /etc/gitproxy.sh for or.cz
# and several others ...
gitproxy.sh:
#! /bin/sh
(echo "CONNECT $1:$2 HTTP/1.0"; echo; cat ) | socket <company proxy host> <port> | (read a; read a; cat )
Markus
^ permalink raw reply
* Re: [PATCH] Teach format-patch to handle output directory relative to cwd
From: Junio C Hamano @ 2009-01-13 1:00 UTC (permalink / raw)
To: Cesar Eduardo Barros; +Cc: git
In-Reply-To: <496BCE55.8030407@cesarb.net>
Cesar Eduardo Barros <cesarb@cesarb.net> writes:
> Works great, only the resulting output to the screen is a bit
> ugly/confusing:
>
> drivers/net/../../../0001-sc92031-more-useful-banner-in-kernel-log.patch
> ...
> (after all, I am still inside the drivers/net directory)
Fair enough. Here is a replacement diff.
builtin-log.c | 28 ++++++++++++++++++++++--
t/t4014-format-patch.sh | 52 ++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 76 insertions(+), 4 deletions(-)
diff --git c/builtin-log.c w/builtin-log.c
index db71e0d..16a0f11 100644
--- c/builtin-log.c
+++ w/builtin-log.c
@@ -568,6 +568,7 @@ static const char *get_oneline_for_filename(struct commit *commit,
static FILE *realstdout = NULL;
static const char *output_directory = NULL;
+static int outdir_offset;
static int reopen_stdout(const char *oneline, int nr, int total)
{
@@ -594,7 +595,7 @@ static int reopen_stdout(const char *oneline, int nr, int total)
strcpy(filename + len, fmt_patch_suffix);
}
- fprintf(realstdout, "%s\n", filename);
+ fprintf(realstdout, "%s\n", filename + outdir_offset);
if (freopen(filename, "w", stdout) == NULL)
return error("Cannot open patch file %s",filename);
@@ -757,6 +758,27 @@ static const char *clean_message_id(const char *msg_id)
return xmemdupz(a, z - a);
}
+static const char *set_outdir(const char *prefix, const char *output_directory)
+{
+ if (output_directory && is_absolute_path(output_directory))
+ return output_directory;
+
+ if (!prefix || !*prefix) {
+ if (output_directory)
+ return output_directory;
+ /* The user did not explicitly ask for "./" */
+ outdir_offset = 2;
+ return "./";
+ }
+
+ outdir_offset = strlen(prefix);
+ if (!output_directory)
+ return prefix;
+
+ return xstrdup(prefix_filename(prefix, outdir_offset,
+ output_directory));
+}
+
int cmd_format_patch(int argc, const char **argv, const char *prefix)
{
struct commit *commit;
@@ -935,8 +957,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)
DIFF_OPT_SET(&rev.diffopt, BINARY);
- if (!output_directory && !use_stdout)
- output_directory = prefix;
+ if (!use_stdout)
+ output_directory = set_outdir(prefix, output_directory);
if (output_directory) {
if (use_stdout)
diff --git c/t/t4014-format-patch.sh w/t/t4014-format-patch.sh
index 7fe853c..16de436 100755
--- c/t/t4014-format-patch.sh
+++ w/t/t4014-format-patch.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2006 Junio C Hamano
#
-test_description='Format-patch skipping already incorporated patches'
+test_description='various format-patch tests'
. ./test-lib.sh
@@ -230,4 +230,54 @@ test_expect_success 'shortlog of cover-letter wraps overly-long onelines' '
'
+test_expect_success 'format-patch from a subdirectory (1)' '
+ filename=$(
+ rm -rf sub &&
+ mkdir -p sub/dir &&
+ cd sub/dir &&
+ git format-patch -1
+ ) &&
+ case "$filename" in
+ 0*)
+ ;; # ok
+ *)
+ echo "Oops? $filename"
+ false
+ ;;
+ esac &&
+ test -f "$filename"
+'
+
+test_expect_success 'format-patch from a subdirectory (2)' '
+ filename=$(
+ rm -rf sub &&
+ mkdir -p sub/dir &&
+ cd sub/dir &&
+ git format-patch -1 -o ..
+ ) &&
+ case "$filename" in
+ ../0*)
+ ;; # ok
+ *)
+ echo "Oops? $filename"
+ false
+ ;;
+ esac &&
+ basename=$(expr "$filename" : ".*/\(.*\)") &&
+ test -f "sub/$basename"
+'
+
+test_expect_success 'format-patch from a subdirectory (3)' '
+ here="$TEST_DIRECTORY/$test" &&
+ rm -f 0* &&
+ filename=$(
+ rm -rf sub &&
+ mkdir -p sub/dir &&
+ cd sub/dir &&
+ git format-patch -1 -o "$here"
+ ) &&
+ basename=$(expr "$filename" : ".*/\(.*\)") &&
+ test -f "$basename"
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH/RFC] contrib/examples/README: warn of obsolescence
From: Junio C Hamano @ 2009-01-13 1:05 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87fxjoowyp.fsf@jidanni.org>
jidanni@jidanni.org writes:
> We attempt to give an explanation of the status of the files in this
> directory.
Yeah, that is a good discipline.
They are original scripted implementations, kept primarily for their
reference value to any aspiring plumbing users who want to learn how
pieces can be fit together.
^ permalink raw reply
* [PATCH/RFC] Documentation/git-blame.txt, git-gui.txt: link SEE ALSOs
From: jidanni @ 2009-01-13 1:13 UTC (permalink / raw)
To: git
As git gui is heavily blame focused, we link its SEE ALSO to
git-blame, and add a link back while we're at it.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-blame.txt | 1 +
Documentation/git-gui.txt | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index fba374d..d71a2c3 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -186,6 +186,7 @@ commit commentary), a blame viewer won't ever care.
SEE ALSO
--------
+linkgit:git-gui[1],
linkgit:git-annotate[1]
AUTHOR
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index d0bc98b..3a71074 100644
--- a/Documentation/git-gui.txt
+++ b/Documentation/git-gui.txt
@@ -105,6 +105,9 @@ linkgit:gitk[1]::
and file differences. gitk is the utility started by
'git-gui''s Repository Visualize actions.
+linkgit:git-blame[1]::
+ Command-line blame viewer.
+
Other
-----
'git-gui' is actually maintained as an independent project, but stable
--
1.6.0.6
^ permalink raw reply related
* [PATCH,v2] contrib/examples/README: give an explanation of the status of these files
From: jidanni @ 2009-01-13 1:19 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7viqokf21j.fsf@gitster.siamese.dyndns.org>
We attempt to give an explanation of the status of the files in this
directory.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
contrib/examples/README | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 contrib/examples/README
diff --git a/contrib/examples/README b/contrib/examples/README
new file mode 100644
index 0000000..6946f3d
--- /dev/null
+++ b/contrib/examples/README
@@ -0,0 +1,3 @@
+These are original scripted implementations, kept primarily for their
+reference value to any aspiring plumbing users who want to learn how
+pieces can be fit together.
--
1.6.0.6
^ permalink raw reply related
* Re: [RFC/PATCH 3/7] replace_object: add mechanism to replace objects found in "refs/replace/"
From: Junio C Hamano @ 2009-01-13 1:31 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20090112184403.ebb99b75.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> diff --git a/replace_object.c b/replace_object.c
> new file mode 100644
> index 0000000..25b3ef3
> --- /dev/null
> +++ b/replace_object.c
> @@ -0,0 +1,116 @@
> +#include "cache.h"
> +#include "refs.h"
> +
> +static struct replace_object {
> + unsigned char sha1[2][20];
> +} **replace_object;
> +
> +static int replace_object_alloc, replace_object_nr;
> +
> +static int replace_object_pos(const unsigned char *sha1)
> +{
> + int lo, hi;
> + lo = 0;
> + hi = replace_object_nr;
> + while (lo < hi) {
> + int mi = (lo + hi) / 2;
> + struct replace_object *rep = replace_object[mi];
> + int cmp = hashcmp(sha1, rep->sha1[0]);
> + if (!cmp)
> + return mi;
> + if (cmp < 0)
> + hi = mi;
> + else
> + lo = mi + 1;
> + }
> + return -lo - 1;
> +}
Hmm, this is a tangent of this topic, but I wonder if we can do something
more generic to factor out many binary search like this we have throughout
the code. Also I wonder if they can be made more efficient by taking
advantage of the fact that our hash is expected to produce a good uniform
distribution, similar to the way patch-ids.c::patch_pos() does this.
I guess the performance should not matter much for this table, as we
expect there won't be massive object replacements.
Also I recall Dscho muttered something about hashmap I didn't quite
understand.
> +static int register_replace_ref(const char *refname,
> + const unsigned char *sha1,
> + int flag, void *cb_data)
> +{
> + /* Get sha1 from refname */
> + const char *slash = strrchr(refname, '/');
> + const char *hash = slash ? slash + 1 : refname;
> + struct replace_object * repl_obj = xmalloc(sizeof(*repl_obj));
struct replace_object *repl_obj = ...
> + if (strlen(hash) != 40 || get_sha1_hex(hash, repl_obj->sha1[0])) {
> + free(repl_obj);
> + warning("bad replace ref name: %s", refname);
> + }
> +
> + /* Copy sha1 from the read ref */
> + hashcpy(repl_obj->sha1[1], sha1);
Upon an error, you free and warn and then still copy into it?
> + /* Register new object */
> + if (register_replace_object(repl_obj, 1))
> + warning("duplicate replace ref: %s", refname);
I'd say this is a grave error and should be reported as a repository
corruption.
> +static void prepare_replace_object(void)
> +{
> + static int replace_object_prepared;
> +
> + if (replace_object_prepared)
> + return;
> +
> + for_each_replace_ref(register_replace_ref, NULL);
> + replace_object_prepared = 1;
> +}
> +
> +/* We allow "recursive" replacement. Only within reason, though */
> +#define MAXREPLACEDEPTH 5
> +
> +const unsigned char *lookup_replace_object(const unsigned char *sha1)
> +{
> + int pos, depth = MAXREPLACEDEPTH;
> + const unsigned char *cur = sha1;
> +
> + prepare_replace_object();
> +
> + /* Try to recursively replace the object */
> + do {
> + if (--depth < 0)
> + die("replace depth too high for object %s",
> + sha1_to_hex(sha1));
> +
> + pos = replace_object_pos(cur);
> + if (0 <= pos)
> + cur = replace_object[pos]->sha1[1];
> + } while (0 <= pos);
> +
> + return cur;
> +}
Since your paradigm is prepare replacement once at the beginning, never
allowing to update it, I think you can update the table while you look it
up. E.g. if A->B and B->C exists, and A is asked for, you find A->B (to
tentatively make cur to point at B) and then you find B->C, and before
returning you can rewrite the first mapping to A->C. Later look-up won't
need to dereference the table twice that way.
This assumes that there will be small number of replacements, but the same
object can be asked for more than once during the process.
> diff --git a/sha1_file.c b/sha1_file.c
> index f08493f..4f2fd10 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2163,10 +2163,18 @@ static void *read_object(const unsigned char *sha1, enum object_type *type,
> void *read_sha1_file(const unsigned char *sha1, enum object_type *type,
> unsigned long *size)
> {
> - void *data = read_object(sha1, type, size);
> + const unsigned char *repl = lookup_replace_object(sha1);
> + void *data = read_object(repl, type, size);
> +
> + /* die if we replaced an object with one that does not exist */
> + if (!data && repl != sha1)
> + die("replacement %s not found for %s",
> + sha1_to_hex(repl), sha1_to_hex(sha1));
> +
> /* legacy behavior is to die on corrupted objects */
> - if (!data && (has_loose_object(sha1) || has_packed_and_bad(sha1)))
> - die("object %s is corrupted", sha1_to_hex(sha1));
> + if (!data && (has_loose_object(repl) || has_packed_and_bad(repl)))
> + die("object %s is corrupted", sha1_to_hex(repl));
> +
> return data;
> }
Later we'd need a global switch to forbid the replacement for connectivity
walkers, but other than that I think this is sane.
I also looked at 1/ and 2/ which looked Ok.
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC] Documentation/git-blame.txt, git-gui.txt: link SEE ALSOs
From: Junio C Hamano @ 2009-01-13 1:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, jidanni
In-Reply-To: <87bpucovnz.fsf@jidanni.org>
jidanni@jidanni.org writes:
> As git gui is heavily blame focused, we link its SEE ALSO to
> git-blame, and add a link back while we're at it.
>
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
> Documentation/git-blame.txt | 1 +
> Documentation/git-gui.txt | 3 +++
> 2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
> index fba374d..d71a2c3 100644
> --- a/Documentation/git-blame.txt
> +++ b/Documentation/git-blame.txt
> @@ -186,6 +186,7 @@ commit commentary), a blame viewer won't ever care.
>
> SEE ALSO
> --------
> +linkgit:git-gui[1],
> linkgit:git-annotate[1]
>
> AUTHOR
> diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
> index d0bc98b..3a71074 100644
> --- a/Documentation/git-gui.txt
> +++ b/Documentation/git-gui.txt
> @@ -105,6 +105,9 @@ linkgit:gitk[1]::
> and file differences. gitk is the utility started by
> 'git-gui''s Repository Visualize actions.
>
> +linkgit:git-blame[1]::
> + Command-line blame viewer.
> +
> Other
> -----
> 'git-gui' is actually maintained as an independent project, but stable
As a general principle, I tend to refrain from referring to X from the
description of Y only because X happens to use Y heavily.
Referring people who heavily use Y to an alternative, which is X, hoping
that X may give a better user experience in certain environments is a
different matter, but in such a case, I'd rather see not just link but
in-text description as well (study the way "log -S" is suggested in the
description part for an example). The attached patch shows you how.
On the other hand, what X does using Y sometimes may be easier to
understand if the reader is familiar with the way how Y works. Even in
such a case, I think the documentation of X should be self contained
enough and ideally it shouldn't have to refer to Y. And in the case of
git-gui documentation, I think it is.
So I am moderately negative about the first hunk of this patch as-is, and
I'll leave the decision on the second hunk to Shawn.
diff --git i/Documentation/git-blame.txt w/Documentation/git-blame.txt
index fba374d..ff7bbfb 100644
--- i/Documentation/git-blame.txt
+++ w/Documentation/git-blame.txt
@@ -36,6 +36,11 @@ $ git log --pretty=oneline -S'blame_usage'
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
-----------------------------------------------------------------------------
+People working in GUI environment may find linkgit:git-gui[1] an useful
+alternative that provides an interactive interface to the history of
+each line. It uses this command as an underlying engine.
+
+
OPTIONS
-------
include::blame-options.txt[]
^ permalink raw reply related
* Re: [PATCH,v2] contrib/examples/README: give an explanation of the status of these files
From: Junio C Hamano @ 2009-01-13 1:48 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <877i50ovdd.fsf_-_@jidanni.org>
Thanks.
^ permalink raw reply
* Re: git/webdav is refusing to authenticate properly.
From: Boyd Stephen Smith Jr. @ 2009-01-13 1:53 UTC (permalink / raw)
To: Peter Spierenburg; +Cc: git
In-Reply-To: <496BE1E0.9010908@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
On Monday 12 January 2009, Peter Spierenburg
<ionlyusethisaddressforlists@gmail.com> wrote about 'Re: git/webdav is
refusing to authenticate properly.':
>C'mon, leave my password 'in-the-clear', in a text file on a networked
>box? That is the kind of prank a fourth-year student would try to pull
>on a freshman.
>
>How do I really do it?
AFAIK, that's the only way for now.
Personally, I'd welcome a patch that allowed fetch/push to prompt the user
for a password, but I'm not holding my breath. If I want to limit access
to a few users, I serve that repository over ssh and depend on ssh for
authentication and filesystem permissions for authorization.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
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