* [PATCH] gitweb: localhost placeholder parser for cloneurl file
From: Leandro Dorileo @ 2007-07-29 6:54 UTC (permalink / raw)
To: git
Hi...
I just started to use gitweb and saw that there isn`t in the git-tree
of gitweb the feature of that link to the git url (wich we can see in
git.kernel.org:D - I didn`t understand it, was that changed/done only
for kernel.org?).
I also have a specific need. I work with my laptop and there I keep
some git repositories, these repositories are shared/published with
some coworkers but as it`s a notebook the network environment normally
changes depending where I`m, so I implemented a placeholder for
cloneurl file. Gitweb will change #localhost# by server_name.
If your git repositories aren`t in your local machine or if your
gitweb is hosted in a specific server what you have to do (in fact
what you don`t have to do :D) is just not use it.
>From 32da24e1e18a1c5f32bfa0afdbcb6d0f2b0432f3 Mon Sep 17 00:00:00 2001
From: Leandro Dorileo <dorileo@ossystems.com.br>
Date: Sat, 28 Jul 2007 15:34:20 -0400
Subject: [PATCH] gitweb: localhost placeholder parser for cloneurl file
Implementation of a localhost placeholder parsing in git_get_project_url_list.
It`s useful in cases of gitweb being hosted in a work-station (like a notebook)
used in a local team development environment and, implementation of a git-url
link in the git project list body like in git.kernel.org.
---
gitweb/gitweb.perl | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b381692..281d823 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1471,7 +1471,16 @@ sub git_get_project_url_list {
my @git_project_url_list = map { chomp; $_ } <$fd>;
close $fd;
- return wantarray ? @git_project_url_list : \@git_project_url_list;
+ if(wantarray){
+ for(my $i = 0; $i < @git_project_url_list; $i++){
+ if(index(@git_project_url_list[$i], "#localhost#") != -1){
+ @git_project_url_list[$i] =~
s/#localhost#/server_name()/eg;
+ }
+ }
+ return @git_project_url_list;
+ }else{
+ return \@git_project_url_list;
+ }
}
sub git_get_projects_list {
@@ -3384,8 +3393,14 @@ sub git_project_list_body {
$cgi->a({-href => href(project=>$pr->{'path'},
action=>"shortlog")}, "shortlog") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'},
action=>"log")}, "log") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'},
action=>"tree")}, "tree") .
- ($pr->{'forks'} ? " | " . $cgi->a({-href =>
href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
- "</td>\n" .
+ ($pr->{'forks'} ? " | " . $cgi->a({-href =>
href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '');
+
+ my @url_list = git_get_project_url_list($pr->{'path'});
+ if(@url_list != 0){
+ print " | " . $cgi->a({-href => @url_list[0]}, "git");
+ }
+
+ print "</td>\n" .
"</tr>\n";
}
if (defined $extra) {
--
1.5.2.4
--
Dorileo
^ permalink raw reply related
* [PATCH] gitk: Added support for OS X mouse wheel
From: Väinö Järvelä @ 2007-07-29 6:38 UTC (permalink / raw)
To: git
MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all.
So i added a support for the MouseWheel event, which i limited to Tcl/tk
aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to
be updated from the version that is shipped with OS X 10.4 Tiger, for
this patch to work.
Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
---
gitk | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index f74ce51..985c30a 100755
--- a/gitk
+++ b/gitk
@@ -825,6 +825,12 @@ proc makewindow {} {
#bindall <B1-Motion> {selcanvline %W %x %y}
bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ if {[tk windowingsystem] eq "aqua"} {
+ bindall <MouseWheel> {
+ set delta [expr {- (%D)}]
+ allcanvs yview scroll $delta units
+ }
+ }
bindall <2> "canvscan mark %W %x %y"
bindall <B2-Motion> "canvscan dragto %W %x %y"
bindkey <Home> selfirstline
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Jeff King @ 2007-07-29 4:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Jakub Narebski, Jon Smirl
In-Reply-To: <7vbqdvolww.fsf@assigned-by-dhcp.cox.net>
On Sat, Jul 28, 2007 at 09:48:15PM -0700, Junio C Hamano wrote:
> However, I think Jeff's patch always makes it recursive even
> when the user asks for --raw, which makes it inappropriate for
> inclusion whether before or after 1.5.3.
Right, that's the point. git-diff is currently inconsistent (unless you
understand that index comparisons are always recursed, and tree
comparisons need it explicitly -- but part of the point of git-diff is
to abstract those sorts of details), so this attempts to harmonize the
behavior no matter what you're diffing (whether it be --name-status or
--raw).
If you really want not to recurse, then you have to know you are
comparing trees anyway, at which point it makes sense to use the
git-diff-tree plumbing.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Jeff King @ 2007-07-29 4:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, Jakub Narebski, Jon Smirl
In-Reply-To: <alpine.LFD.0.999.0707282119010.3442@woody.linux-foundation.org>
On Sat, Jul 28, 2007 at 09:27:18PM -0700, Linus Torvalds wrote:
> The fact that "--name-status" is not considered a "patch" is an
> implementation detail, and I would _almost_ suggest that we just make it
> always recurse, and leave thenon-recursing case for _just_ "--raw". But
> that is a separate decision.
I think it makes some sense, but I'm not sure it is worth it for two
reasons:
1. --raw and --name-status are very linked in the diff code. Turning
on recursion for --name-status without --raw will be somewhat
hairy.
2. If all of the porcelain tools turn on recursion anyway, that
implementation detail just goes away anyway.
On the other hand, it looks like we just set options->recursive = 1 for
most formats anyway. So doing "git-log --raw" will not recurse, but
"git-log --raw -p" will recurse for _both_ the raw and the log formats.
Which I think is a bit non-intuitive, but it certainly makes the patch
much simpler:
diff --git a/diff.c b/diff.c
index a5fc56b..3137cac 100644
--- a/diff.c
+++ b/diff.c
@@ -2151,6 +2151,7 @@ int diff_setup_done(struct diff_options *options)
DIFF_FORMAT_DIFFSTAT |
DIFF_FORMAT_SHORTSTAT |
DIFF_FORMAT_SUMMARY |
+ DIFF_FORMAT_NAME_STATUS |
DIFF_FORMAT_CHECKDIFF))
options->recursive = 1;
/*
> It *is* a change in behaviour, though, so I can understand if Junio
> doesn't think it's appropriate this late in the 1.5.3 series.
Agreed.
> "git log", of course, defaults to no output at all, so the only way to get
> non-recursive behaviour is to ask for "--raw", and then having to specify
> explicitly whether to get recursion or not make sense. Once you want raw
> output, it really _is_ your choice.
I wonder if git-log should match the behavior of the other commands. I
have often see git-whatchanged explained as the equivalent of "git-log
-p" but that's not exactly true. Similarly, git-show has been explained
as "git-log -p for the first commit." And using "-p" they are basically
the same. But it means I can't just replace all use of "git-whatchanged"
with "git-log" and get the exact same behavior. I think it makes to
harmonize these little "gotchas".
-Peff
^ permalink raw reply related
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Junio C Hamano @ 2007-07-29 4:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, git, Jakub Narebski, Jon Smirl
In-Reply-To: <alpine.LFD.0.999.0707282119010.3442@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
>> Does anybody else find this behavior confusing? I can understand why
>> diff-tree might not recurse by default, but I wonder if porcelain like
>> git-diff should try to be a little more consistent and always recurse.
>
> I do agree.
>
> The behaviour is obviously historical, and comes from "git diff" being
> just a shell-script wrapper around the different versions of diffing trees
> and indexes etc.
>
> So it makes sense in that historical setting (and realizing that the
> "HEAD<->index" and "index<->files" cases were really a totally different
> operations), but it makes no sense in the modern world where people don't
> even *know* about "git diff-tree", but just use "git diff" for everything.
>
> So:
>
>> Something like:
>
> Ack. Patch looks fine, makes sense, and is obviously good.
That makes it two of us. ... eh, excuse me, there is one issue
I mention at the end.
> It *is* a change in behaviour, though, so I can understand if Junio
> doesn't think it's appropriate this late in the 1.5.3 series.
One minor objection I do have is that, just as a matter of
principle, in order to avoid setting precedence of making a
fundamental semantics change in late -rc stage in the game, we
should not swallow it. I do not mind if this were clearly a
good change.
However, I think Jeff's patch always makes it recursive even
when the user asks for --raw, which makes it inappropriate for
inclusion whether before or after 1.5.3.
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Linus Torvalds @ 2007-07-29 4:27 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Jakub Narebski, Jon Smirl
In-Reply-To: <20070729041159.GA5544@coredump.intra.peff.net>
On Sun, 29 Jul 2007, Jeff King wrote:
>
> So if I "git diff" two commits with --raw or --name-status, we don't
> recurse into recurse into subdirectories (because they are actually
> subtrees).
Exactly.
As it pertains to "git diff", none of this actually makes sense, and I
think it might make sense to make "git diff" automatically set
"recursive", exactly because "git diff" sometimes operates on trees, and
sometimes on the index.
> If I "git diff" a commit against the index using --raw or
> --name-status, I we do recurse (since the index is actually flat). But
> if I "git diff" using -p, --stat, or --summary, it _does_ recurse no
> matter what I'm diffing.
When you ask for patches, it has to recurse, because there is no way to
show a patch for a directory. So yes, anything non-raw will always enable
recursing.
The fact that "--name-status" is not considered a "patch" is an
implementation detail, and I would _almost_ suggest that we just make it
always recurse, and leave thenon-recursing case for _just_ "--raw". But
that is a separate decision.
> Does anybody else find this behavior confusing? I can understand why
> diff-tree might not recurse by default, but I wonder if porcelain like
> git-diff should try to be a little more consistent and always recurse.
I do agree.
The behaviour is obviously historical, and comes from "git diff" being
just a shell-script wrapper around the different versions of diffing trees
and indexes etc.
So it makes sense in that historical setting (and realizing that the
"HEAD<->index" and "index<->files" cases were really a totally different
operations), but it makes no sense in the modern world where people don't
even *know* about "git diff-tree", but just use "git diff" for everything.
So:
> Something like:
Ack. Patch looks fine, makes sense, and is obviously good.
It *is* a change in behaviour, though, so I can understand if Junio
doesn't think it's appropriate this late in the 1.5.3 series.
> For comparison, whatchanged, show, and format-patch are already always
> recursive. log is not.
Yeah. The other cases already default to patches, so they get the
recursive from there.
"git log", of course, defaults to no output at all, so the only way to get
non-recursive behaviour is to ask for "--raw", and then having to specify
explicitly whether to get recursion or not make sense. Once you want raw
output, it really _is_ your choice.
Whether we should make "--name-status" default to "-r" is worth
discussing. I don't have any really strong opinion, although I _suspect_
that we should. The non-recursive case is useful, but in a very limited
sense, and I think we might as well limit it to just the --raw case.
Linus
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Jeff King @ 2007-07-29 4:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, Jakub Narebski, Jon Smirl
In-Reply-To: <alpine.LFD.0.999.0707281905050.3442@woody.linux-foundation.org>
On Sat, Jul 28, 2007 at 07:06:38PM -0700, Linus Torvalds wrote:
> For diffing against (or using) the index, the "-r" is superfluous.
>
> Why? Because the index is always the *full* list of files. It's "flat".
>
> However, when you diff two trees, the -r makes a difference.
>
> So I think you'd find a difference if you actually diffed two commits
> with "git diff tree2..tree2".
Ah...right you are.
So if I "git diff" two commits with --raw or --name-status, we don't
recurse into recurse into subdirectories (because they are actually
subtrees). If I "git diff" a commit against the index using --raw or
--name-status, I we do recurse (since the index is actually flat). But
if I "git diff" using -p, --stat, or --summary, it _does_ recurse no
matter what I'm diffing.
Does anybody else find this behavior confusing? I can understand why
diff-tree might not recurse by default, but I wonder if porcelain like
git-diff should try to be a little more consistent and always recurse.
Something like:
diff --git a/builtin-diff.c b/builtin-diff.c
index 7f367b6..b48121e 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -233,6 +233,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
die("diff_setup_done failed");
}
rev.diffopt.allow_external = 1;
+ rev.diffopt.recursive = 1;
/* Do we have --cached and not have a pending object, then
* default to HEAD by hand. Eek.
For comparison, whatchanged, show, and format-patch are already always
recursive. log is not.
-Peff
^ permalink raw reply related
* Re: What's in git.git (stable)
From: Theodore Tso @ 2007-07-29 3:16 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85bqdw27mb.fsf@lola.goethe.zz>
On Sat, Jul 28, 2007 at 11:35:40AM +0200, David Kastrup wrote:
> David Kastrup <dak@gnu.org> writes:
>
> > If you use the desktop package, this means that you get a bear of a
> > startup time while a _new_ instance of Emacs gets loaded against the
> > wishes of the setup, and the command line parameters will be
> > interpreted relatively to the last file restored into the desktop
> > rather than the current directory (arguably a bug in the desktop
> > package which I plan to fix eventually, but in the meantime the
> > current package is farspread).
>
> I can't reproduce anything similar outside of mergetool, so it appears
> more likely that mergetool is passing wrong relative file names.
See my recent posting on this issue. The problem is that the desktop
package fundamentally changes how emacs behaves when it starts up.
And in order to fix it we will need to change git-mergetool to do an
"emacs --version", parse the version number, and then start changing
how it calls emacs (and if you *really* want to use emacsclient,
whether it can use emacsclient) based on the version of emacs which is
installed as the default for the user. It's going to be really messy,
and fundamentally, emacs as used by people who are using the desktop
package really wants to be the center of the universe, instead of
something which gets called to run a "merge application". Testing to
make sure this works on every single emacs version/variant, and every
single user's weird-sh*t startup scripts isn't something I'm looking
forward to.
So I really am beginning to think the right answer is to give up on
using git-mergetool to support anything other than basic emacs users
(who just use emacs as an editor, what a concept), and for the H4rd
C0re emacs l33t, they can use a contrib/git-mergetool.el that does
everything inside emacs. Since these are the people who want emacs to
be their desktop, their shell, *and* their window manager, they will
probably be happier that way....
- Ted
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Theodore Tso @ 2007-07-29 2:38 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85hcno287w.fsf@lola.goethe.zz>
On Sat, Jul 28, 2007 at 11:22:43AM +0200, David Kastrup wrote:
> Ted, I think you are somewhat missing the main audience here. The
> main audience are people who actually _use_ Emacs, and those will be
> comfortable with the concept "save to have changes persist, don't save
> if you don't want changes to persist, exit using C-x # or C-x C-c as
> appropriate". Basically, it would appear that you try figuring out
> how to make ediff appeal to non-Emacs users. But those would not have
> emacs/emacsclient in their EDITOR variable in the first place.
>
> I have been bitten by mergetool calling emacs rather than emacsclient,
> resulting in a non-working merge (since the default directory was set
> differently from what the call expected due to my use of the desktop
> package), and mergetool afterwards assuming that the not-even-started
> merge was successful. A royal nuisance, and completely unworkable.
Emacsclient is a completely different problem, or at least adds a
whole new dimention, compared to the ediff/emerge issue. You can't
run either emerge or ediff using the emacsclient in emacs21, since it
lacks support for either the -e or the -f command-line option. All
you can do in emacs21 when using eamcsclient is to request emacs to
edit a file.
One of the problems with emacs is that it is so customizable that
people can set up emacs in such a way that different ways of launching
emacs may lead to surprises, thanks to their .emacs21. This makes
supporting emacs based merging clients to be highly problematic. Use
of the desktop package is one way in which things can be quite
surprising. Worse yet, the desktop package is only in emacs22 and up.
(And emacs 22 was *just* released, not all that long ago; many people
may still be using emacs21). So if we use emacs --no-desktop to
disable the desktop package, it will cause emacs21 to complain about
an unknown option. Joy. Which means that to avoid running into
problems with emacs22 users who are using the desktop package,
git-mergetool is going to have to find out in advance whether emacs21
or emacs22 (or an emacs development 23.0.0 snapshot) is in use; on a
debian system you can have 3 or 4 emacs installed simultaneously. What fun.
In any case, the main issue is that there is an emerging (sorry)
standard about how merge tools are supposed to work, in terms of being
able to support 2-way or 3-way merges, about being able to specify
which file (and which file only, in the best case) should be used as
the output file as the result of the merge, and about how tools can
signal either a successful merge, or a request by the user to abort
the merge becuase things didn't work out for one reason or another.
The problem is that ediff doesn't really fit this model. For people
who really want to live their life in emacs, and using emacs as their
desktop (not for me, but maybe for some folks), maybe it would be
better for those folks to simply build a git-mergetool.el that ran
100% in emacs, instead of trying to shift back and forth between the
command-line and emacs, would make everyone happier. Right now
git-mergetool needs to ask questions about the disposition of
symlinks, permission changes, etc. If it is done as a
git-mergetool.el which is tied into git.el and ediff, it could be a
lot more seamless.
> While it may be nice to have some Lisp preparation for people who
> don't want to touch or learn Emacs _except_ for using it for merging
> in git, I think we should first cater to people actually using Emacs
> already.
Catering to the hard-core Emacs folks is *hard*. I knew someone who
had PDP-10 assembly language in their .emacs.el file, and one day his
custom emacs extension worked again when he started playing with the
KLH10 PDP-10 emulator, and reused his .emacs.el startup file there....
Of course, at some level folks like that will always need to fend for
themselves.
As I said earlier, I don't have a huge objection to support ediff in
some degraded mode (I think the UI is ghastly bad), if users
explicitly request it, but I would *not* want to make it the default
and spring it on some unsuspecting user. Quite frankly, right now the
KDE and GNOME tools are way better either emerge or ediff, so they are
only really useful as a default in the terminal-only case.
- Ted
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Linus Torvalds @ 2007-07-29 2:06 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Jakub Narebski, Jon Smirl
In-Reply-To: <20070729002427.GA1566@coredump.intra.peff.net>
On Sat, 28 Jul 2007, Jeff King wrote:
>
> The '-r' now seems to be superfluous.
For diffing against (or using) the index, the "-r" is superfluous.
Why? Because the index is always the *full* list of files. It's "flat".
However, when you diff two trees, the -r makes a difference.
So I think you'd find a difference if you actually diffed two commits
with "git diff tree2..tree2".
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: Simplify 'opt' parameter validation, add "no merges" feeds
From: Junio C Hamano @ 2007-07-29 1:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Luben Tuikov, Petr Baudis
In-Reply-To: <11856328582066-git-send-email-jnareb@gmail.com>
This and the submodule stuff look good. Thanks.
Applied.
^ permalink raw reply
* [PATCH 3/3] rebase: try not to munge commit log message
From: Junio C Hamano @ 2007-07-29 1:11 UTC (permalink / raw)
To: Sean; +Cc: Benoit SIGOURE, git
In-Reply-To: <7vzm1gnhin.fsf@assigned-by-dhcp.cox.net>
This makes rebase/am keep the original commit log message
better, even when it does not conform to "single line paragraph
to say what it does, then explain and defend why it is a good
change in later paragraphs" convention.
This change is a two-edged sword. While the earlier behaviour
would make such commit log messages more friendly to readers who
expect to get the birds-eye view with oneline summary formats,
users who primarily use git as a way to interact with foreign
SCM systems would not care much about the convenience of oneline
git log tools, but care more about preserving their own
convention. This changes their commits less useful to readers
who read them with git tools while keeping them more consistent
with the foreign SCM systems they interact with.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-mailinfo.c | 29 +++++++++++++++++++++----
t/t3405-rebase-malformed.sh | 48 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 5 deletions(-)
create mode 100755 t/t3405-rebase-malformed.sh
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index b4f6e91..b558754 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -237,8 +237,6 @@ static int eatspace(char *line)
static char *cleanup_subject(char *subject)
{
- if (keep_subject)
- return subject;
for (;;) {
char *p;
int len, remove;
@@ -425,6 +423,7 @@ static int read_one_header_line(char *line, int sz, FILE *in)
if (addlen >= sz - len)
addlen = sz - len - 1;
memcpy(line + len, continuation, addlen);
+ line[len] = '\n';
len += addlen;
}
}
@@ -846,6 +845,22 @@ static void handle_body(void)
return;
}
+static void output_header_lines(FILE *fout, const char *hdr, char *data)
+{
+ while (1) {
+ char *ep = strchr(data, '\n');
+ int len;
+ if (!ep)
+ len = strlen(data);
+ else
+ len = ep - data;
+ fprintf(fout, "%s: %.*s\n", hdr, len, data);
+ if (!ep)
+ break;
+ data = ep + 1;
+ }
+}
+
static void handle_info(void)
{
char *sub;
@@ -863,9 +878,13 @@ static void handle_info(void)
continue;
if (!memcmp(header[i], "Subject", 7)) {
- sub = cleanup_subject(hdr);
- cleanup_space(sub);
- fprintf(fout, "Subject: %s\n", sub);
+ if (keep_subject)
+ sub = hdr;
+ else {
+ sub = cleanup_subject(hdr);
+ cleanup_space(sub);
+ }
+ output_header_lines(fout, "Subject", sub);
} else if (!memcmp(header[i], "From", 4)) {
handle_from(hdr);
fprintf(fout, "Author: %s\n", name);
diff --git a/t/t3405-rebase-malformed.sh b/t/t3405-rebase-malformed.sh
new file mode 100755
index 0000000..e4e2e64
--- /dev/null
+++ b/t/t3405-rebase-malformed.sh
@@ -0,0 +1,48 @@
+#!/bin/sh
+
+test_description='rebase should not insist on git message convention'
+
+. ./test-lib.sh
+
+cat >F <<\EOF
+This is an example of a commit log message
+that does not conform to git commit convention.
+
+It has two paragraphs, but its first paragraph is not friendly
+to oneline summary format.
+EOF
+
+test_expect_success setup '
+
+ >file1 &&
+ >file2 &&
+ git add file1 file2 &&
+ test_tick &&
+ git commit -m "Initial commit" &&
+
+ git checkout -b side &&
+ cat F >file2 &&
+ git add file2 &&
+ test_tick &&
+ git commit -F F &&
+
+ git cat-file commit HEAD | sed -e "1,/^\$/d" >F0 &&
+
+ git checkout master &&
+
+ echo One >file1 &&
+ test_tick &&
+ git add file1 &&
+ git commit -m "Second commit"
+'
+
+test_expect_success rebase '
+
+ git rebase master side &&
+ git cat-file commit HEAD | sed -e "1,/^\$/d" >F1 &&
+
+ diff -u F0 F1 &&
+ diff -u F F0
+'
+
+test_done
--
1.5.3.rc3.24.g83b3d
^ permalink raw reply related
* [PATCH 2/3] symbolic-ref, update-ref: do not refuse reflog message with LF
From: Junio C Hamano @ 2007-07-29 1:10 UTC (permalink / raw)
To: Sean; +Cc: Benoit SIGOURE, git
In-Reply-To: <7vzm1gnhin.fsf@assigned-by-dhcp.cox.net>
Earlier these tools refused to create a reflog entry when the
message given by the calling Porcelain had a LF in it, partially
to keep the file format integrity of reflog file, which is
one-entry-per-line. These tools should not be dictating such a
policy.
Instead, let the codepath to write out the reflog entry worry
about the format integrity and allow messages with LF in them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-symbolic-ref.c | 2 --
builtin-update-ref.c | 2 --
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
index d41b406..9eb95e5 100644
--- a/builtin-symbolic-ref.c
+++ b/builtin-symbolic-ref.c
@@ -43,8 +43,6 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
msg = argv[1];
if (!*msg)
die("Refusing to perform update with empty message");
- if (strchr(msg, '\n'))
- die("Refusing to perform update with \\n in message");
}
else if (!strcmp("--", arg)) {
argc--;
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index feac2ed..8339cf1 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -23,8 +23,6 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
msg = argv[++i];
if (!*msg)
die("Refusing to perform update with empty message.");
- if (strchr(msg, '\n'))
- die("Refusing to perform update with \\n in message.");
continue;
}
if (!strcmp("-d", argv[i])) {
--
1.5.3.rc3.24.g83b3d
^ permalink raw reply related
* [PATCH 1/3] log_ref_write() -- do not chomp reflog message at the first LF
From: Junio C Hamano @ 2007-07-29 1:10 UTC (permalink / raw)
To: Sean; +Cc: Benoit SIGOURE, git
In-Reply-To: <7vzm1gnhin.fsf@assigned-by-dhcp.cox.net>
A reflog file is organized as one-line-per-entry records, and we
enforced the file format integrity by chomping the given message
at the first LF. This changes it to convert them to SP, which
is more in line with the --pretty=oneline format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
refs.c | 44 ++++++++++++++++++++++++++++----------------
1 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/refs.c b/refs.c
index 2694e70..fac6548 100644
--- a/refs.c
+++ b/refs.c
@@ -1036,6 +1036,32 @@ void unlock_ref(struct ref_lock *lock)
free(lock);
}
+/*
+ * copy the reflog message msg to buf, which has been allocated sufficiently
+ * large, while cleaning up the whitespaces. Especially, convert LF to space,
+ * because reflog file is one line per entry.
+ */
+static int copy_msg(char *buf, const char *msg)
+{
+ char *cp = buf;
+ char c;
+ int wasspace = 1;
+
+ *cp++ = '\t';
+ while ((c = *msg++)) {
+ if (wasspace && isspace(c))
+ continue;
+ wasspace = isspace(c);
+ if (wasspace)
+ c = ' ';
+ *cp++ = c;
+ }
+ while (buf < cp && isspace(cp[-1]))
+ cp--;
+ *cp++ = '\n';
+ return cp - buf;
+}
+
static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
const unsigned char *new_sha1, const char *msg)
{
@@ -1080,21 +1106,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
adjust_shared_perm(log_file);
- msglen = 0;
- if (msg) {
- /* clean up the message and make sure it is a single line */
- for ( ; *msg; msg++)
- if (!isspace(*msg))
- break;
- if (*msg) {
- const char *ep = strchr(msg, '\n');
- if (ep)
- msglen = ep - msg;
- else
- msglen = strlen(msg);
- }
- }
-
+ msglen = msg ? strlen(msg) : 0;
committer = git_committer_info(-1);
maxlen = strlen(committer) + msglen + 100;
logrec = xmalloc(maxlen);
@@ -1103,7 +1115,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
sha1_to_hex(new_sha1),
committer);
if (msglen)
- len += sprintf(logrec + len - 1, "\t%.*s\n", msglen, msg) - 1;
+ len += copy_msg(logrec + len - 1, msg) - 1;
written = len <= maxlen ? write_in_full(logfd, logrec, len) : -1;
free(logrec);
if (close(logfd) != 0 || written != len)
--
1.5.3.rc3.24.g83b3d
^ permalink raw reply related
* Re: git-svn rebase screwing up commit messages
From: Junio C Hamano @ 2007-07-29 1:08 UTC (permalink / raw)
To: Sean; +Cc: Benoit SIGOURE, git
In-Reply-To: <7vd4ycp8ff.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Sean <seanlkml@sympatico.ca> writes:
>
>> I would argue that you shouldn't try to have it both ways.
>
> You cannot have it both ways as-is, but this is solvable. The
> invocation of am from rebase needs an extra (internal to
> implementation) option to use the code it patches, and the
> regular am can fold what are found on Subject: lines it used
> to.
>
> The patch as-is breaks the more important case of e-mail
> acceptance codepath, because MUAs are free to fold the Subject:
> line when the original line is long, and what the user (the
> original patch submitter) expects to happen is that a
> single-line-ness of the original Subject: of the message to be
> kept. The patch breaks such a line at the place MUA happens to
> fold such a long, single line, for comforming messages.
So here comes an updated series, properly split along the
logical lines.
0001-log_ref_write-do-not-chomp-reflog-message-at-the.txt
0002-symbolic-ref-update-ref-do-not-refuse-reflog-message.txt
0003-rebase-try-not-to-munge-commit-log-message.txt
I am not absolutely sure about the implications of mailinfo
change. I tried to be careful by making sure that:
- the updated code kicks in when "format-patch piped to am"
toolchain uses the -k option on both ends, as rebase/am
does. This is the case where we would want to keep the
way original commit log message was formatted.
- otherwise the original "line folding" clean-up is used, so
that usual e-mailed patch acceptance codepath cleanses the
oneline summary obtained from the "Subject:" header.
Because it would be a serious regression to break the latter,
while the former is just "an improvement" [*1], somebody really
should double check the change for me.
[Footnote]
*1* It does not mean that improved support for foreign SCM
interoperation does not matter. It is "merely an improvement"
in the sense that people do not like what the code currently
does anyway, and if the updated code is still not liked, then
not having such "an improvement" does not matter.
^ permalink raw reply
* [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Jeff King @ 2007-07-29 0:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Jon Smirl
Calling 'git-diff --name-status' will recursively show any
changes already, and it has for quite some time (at least as
far back as v1.4.1).
Signed-off-by: Jeff King <peff@peff.net>
---
On Sat, Jul 28, 2007 at 05:26:27PM +0200, Jakub Narebski wrote:
> > How about --name-status?
>
> Or -r --name-status?
The '-r' now seems to be superfluous. I checked using the following
script:
mkdir repo && cd repo && git-init &&
touch root && git-add root && git-commit -m root &&
mkdir sub && touch sub/file && git-add sub/file &&
git-diff --cached --name-status
And it correctly reports
A sub/file
at least since v1.4.1. I didn't look further, but the example is from
the 0.99 era, so I suspect this behavior was changed with the
libification of the revision machinery and the reworking of git-diff.
Or maybe I just totally don't understand what '-r' is supposed to be
doing.
Documentation/git-diff.txt | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 639b969..b1f5e7f 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -102,17 +102,14 @@ Limiting the diff output::
+
------------
$ git diff --diff-filter=MRC <1>
-$ git diff --name-status -r <2>
+$ git diff --name-status <2>
$ git diff arch/i386 include/asm-i386 <3>
------------
+
<1> show only modification, rename and copy, but not addition
nor deletion.
<2> show only names and the nature of change, but not actual
-diff output. --name-status disables usual patch generation
-which in turn also disables recursive behavior, so without -r
-you would only see the directory name if there is a change in a
-file in a subdirectory.
+diff output.
<3> limit diff output to named subtrees.
Munging the diff output::
--
1.5.3.rc3.845.g88e3-dirty
^ permalink raw reply related
* [PATCH] Rename git-rebase interactive buffer: todo => git-rebase-todo
From: Seth Falcon @ 2007-07-28 23:44 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
When using emacsclient or similar, a temporary buffer (file) named
'todo' could cause confusion with a pre-existing buffer of the same
name.
Signed-off-by: Seth Falcon <sethfalcon@gmail.com>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c987311..061cd0a 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -17,7 +17,7 @@ USAGE='(--continue | --abort | --skip | [--preserve-merges] [--verbose]
require_work_tree
DOTEST="$GIT_DIR/.dotest-merge"
-TODO="$DOTEST"/todo
+TODO="$DOTEST"/git-rebase-todo
DONE="$DOTEST"/done
MSG="$DOTEST"/message
SQUASH_MSG="$DOTEST"/message-squash
--
1.5.3.rc3.24.g83b3d
^ permalink raw reply related
* Re: suggestion for git rebase -i
From: Seth Falcon @ 2007-07-28 23:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Seth Falcon, git
In-Reply-To: <Pine.LNX.4.64.0707282109090.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay, fair enough. But since you want that feature, you get to do the
> patch. Hint: it is just one line that has to be changed.
Heh, I actually wrote the patch first, but thought it was so
trivial... :-)
ok, I will send the patch and hopefully not screw up the formatting,
etc. Feedback and hints welcome.
+ seth
^ permalink raw reply
* [PATCH] gitweb: Allow for multivalued parameters passed to href subroutine
From: Jakub Narebski @ 2007-07-28 23:04 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Make it possible to generate URLs with multivalued parameters in the
href() subroutine, via passing reference to array of values.
Example:
href(action=>"log", extra_options=>["--no-merges", "--first-parent"])
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8a32899..498b936 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -629,7 +629,13 @@ sub href(%) {
for (my $i = 0; $i < @mapping; $i += 2) {
my ($name, $symbol) = ($mapping[$i], $mapping[$i+1]);
if (defined $params{$name}) {
- push @result, $symbol . "=" . esc_param($params{$name});
+ if (ref($params{$name}) eq "ARRAY") {
+ foreach my $par (@{$params{$name}}) {
+ push @result, $symbol . "=" . esc_param($par);
+ }
+ } else {
+ push @result, $symbol . "=" . esc_param($params{$name});
+ }
}
}
$href .= "?" . join(';', @result) if scalar @result;
--
1.5.2.4
^ permalink raw reply related
* Re: Gitweb and submodules
From: Jakub Narebski @ 2007-07-28 20:39 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <20070728104054.GI31114MdfPADPa@greensroom.kotnet.org>
On Sat, 28 July 2007, Sven Verdoolaege wrote:
> On Sat, Jul 28, 2007 at 12:29:16PM +0200, Jakub Narebski wrote:
>>
>> What do you think about using "submodule.$name.gitdir" configuration
>> variable for that?
>
> What will be the value? A path relative to the gitdir of the superproject?
Or absolute path. I was thinking about absolute path, but path
relative to GIT_DIR of superproject is a good idea.
>> It has to be configuration variable because the
>> location of repository which has submodule objects doesn't change when
>> checking out (or rewinding) to different commit in supermodule.
>
> Let's hope Pasky provides a way to set this information...
Why Pasky?
>> As a special case I'd use 'no value' to note that submodule objects are
>> contained in the supermodule repository.
>
> How about using '.' for that and no value for submodules that
> are not available on this server?
Very good idea, both using '.' to mark that submodule objects are in
the superproject objects database, and no value for not available
(although I'm less sure about the latter).
I am thinking about the following sequence to search for submodule
objects:
>From $GIT_DIR/config:
submodule.$name.objects (absolute or relative to gitdir of superproject)
submodule.$name.gitdir (absolute or relative to gitdir of superproject)
submodule.$name.url (to find GIT_DIR, if it is local filesystem URL)
If there is working directory, from .gitmodules file in top level
of working directory:
submodule.$name.path/.git (relative to toplevel of working directory)
What do you think about this?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-svn rebase screwing up commit messages
From: Junio C Hamano @ 2007-07-28 20:41 UTC (permalink / raw)
To: Sean; +Cc: Benoit SIGOURE, git
In-Reply-To: <20070728101156.20304d11.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> I would argue that you shouldn't try to have it both ways.
You cannot have it both ways as-is, but this is solvable. The
invocation of am from rebase needs an extra (internal to
implementation) option to use the code it patches, and the
regular am can fold what are found on Subject: lines it used
to.
The patch as-is breaks the more important case of e-mail
acceptance codepath, because MUAs are free to fold the Subject:
line when the original line is long, and what the user (the
original patch submitter) expects to happen is that a
single-line-ness of the original Subject: of the message to be
kept. The patch breaks such a line at the place MUA happens to
fold such a long, single line, for comforming messages.
^ permalink raw reply
* Re: [PATCH guilt] guilt-rebase: Make fast-forward work
From: Josef Sipek @ 2007-07-28 20:40 UTC (permalink / raw)
To: Eric Lesh; +Cc: Josef Sipek, Git mailing list
In-Reply-To: <87d4ycen0r.fsf@hubert.paunchy.net>
On Sat, Jul 28, 2007 at 05:22:12AM -0700, Eric Lesh wrote:
> Merges created with --no-commit and a blank commit message didn't update
> the branch's HEAD in a fast-forward merge. Rebasing didn't actually do
> anything in that case.
>
> Also quote the log message when displaying the new HEAD.
Applied. Thanks.
Josef 'Jeff' Sipek.
--
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
- Abbie Hoffman
^ permalink raw reply
* Re: [PATCH] Don't rely on unspecified behavior
From: Thomas Glanzmann @ 2007-07-28 20:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: GIT
In-Reply-To: <Pine.LNX.4.64.0707282115450.14781@racer.site>
Hello,
> Ah. Thanks for the explanation.
I have operating system / real time systems exam on monday. I have to
prepare myself in stating the obvious.
Thomas
^ permalink raw reply
* Re: [PATCH] git-gui.git: Wording suggestions, 2nd try
From: Christian Stimming @ 2007-07-28 20:17 UTC (permalink / raw)
To: David Kastrup
Cc: Shawn O. Pearce, Brett Schwarz, git, Paul Mackerras,
Junio C Hamano
In-Reply-To: <861wevqz7d.fsf@lola.quinscape.zz>
Unify wording to say "to stage" instead of "to add" always.
Also, the warning message when clicking "Reset" is adapted to
the wording "Reset" rather than a confusion "Cancel commit?".
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
This time, this patch is actually based on git-gui.git's master. If you want to, you can directly apply this regardless of i18n work that was deferred until later.
The last hunk in lib/merge.tcl looks a bit confusing; in preparation of i18n work, the previous message that inserted a single word into the long english sentence was already replaced by the i18n'able form of two completely different messages. But nevertheless the main point is that when clicking "Reset", the upcoming question should use the wording "reset", which it will do after this patch.
git-gui.sh | 6 +++---
lib/checkout_op.tcl | 2 +-
lib/commit.tcl | 4 ++--
lib/index.tcl | 2 +-
lib/merge.tcl | 18 +++++++++++-------
5 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index f87b955..d7fad46 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1827,12 +1827,12 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
lappend disable_on_lock \
[list .mbar.commit entryconf [.mbar.commit index last] -state]
- .mbar.commit add command -label {Add To Commit} \
+ .mbar.commit add command -label {Stage To Commit} \
-command do_add_selection
lappend disable_on_lock \
[list .mbar.commit entryconf [.mbar.commit index last] -state]
- .mbar.commit add command -label {Add Tracked Files To Commit} \
+ .mbar.commit add command -label {Stage Changed Files To Commit} \
-command do_add_all \
-accelerator $M1T-I
lappend disable_on_lock \
@@ -2154,7 +2154,7 @@ pack .vpane.lower.commarea.buttons.rescan -side top -fill x
lappend disable_on_lock \
{.vpane.lower.commarea.buttons.rescan conf -state}
-button .vpane.lower.commarea.buttons.incall -text {Add Tracked} \
+button .vpane.lower.commarea.buttons.incall -text {Stage Changed} \
-command do_add_all
pack .vpane.lower.commarea.buttons.incall -side top -fill x
lappend disable_on_lock \
diff --git a/lib/checkout_op.tcl b/lib/checkout_op.tcl
index 40cc73a..170f737 100644
--- a/lib/checkout_op.tcl
+++ b/lib/checkout_op.tcl
@@ -248,7 +248,7 @@ method _checkout {} {
if {[lock_index checkout_op]} {
after idle [cb _start_checkout]
} else {
- _error $this "Index is already locked."
+ _error $this "Staging area (index) is already locked."
delete_this
}
}
diff --git a/lib/commit.tcl b/lib/commit.tcl
index 1f5c2c3..f857a2f 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -153,7 +153,7 @@ The rescan will be automatically started now.
U? {
error_popup "Unmerged files cannot be committed.
-File [short_path $path] has merge conflicts. You must resolve them and add the file before committing.
+File [short_path $path] has merge conflicts. You must resolve them and stage the file before committing.
"
unlock_index
return
@@ -169,7 +169,7 @@ File [short_path $path] cannot be committed by this program.
if {!$files_ready && ![string match *merge $curType]} {
info_popup {No changes to commit.
-You must add at least 1 file before you can commit.
+You must stage at least 1 file before you can commit.
}
unlock_index
return
diff --git a/lib/index.tcl b/lib/index.tcl
index 3ea72e1..f47f929 100644
--- a/lib/index.tcl
+++ b/lib/index.tcl
@@ -360,7 +360,7 @@ proc revert_helper {txt paths} {
"[appname] ([reponame])" \
"Revert changes in $s?
-Any unadded changes will be permanently lost by the revert." \
+Any unstaged changes will be permanently lost by the revert." \
question \
1 \
{Do Nothing} \
diff --git a/lib/merge.tcl b/lib/merge.tcl
index 148d859..f6a2df3 100644
--- a/lib/merge.tcl
+++ b/lib/merge.tcl
@@ -45,7 +45,7 @@ The rescan will be automatically started now.
File [short_path $path] has merge conflicts.
-You must resolve them, add the file, and commit to complete the current merge. Only then can you begin another merge.
+You must resolve them, stage the file, and commit to complete the current merge. Only then can you begin another merge.
"
unlock_index
return 0
@@ -219,16 +219,20 @@ You must finish amending this commit.
if {![lock_index abort]} return
if {[string match *merge* $commit_type]} {
- set op merge
+ set op_question "Abort merge?
+
+Aborting the current merge will cause *ALL* uncommitted changes to be lost.
+
+Continue with aborting the current merge?"
} else {
- set op commit
- }
+ set op_question "Reset changes?
- if {[ask_popup "Abort $op?
+Resetting the changes will cause *ALL* uncommitted changes to be lost.
-Aborting the current $op will cause *ALL* uncommitted changes to be lost.
+Continue with resetting the current changes?"
+ }
-Continue with aborting the current $op?"] eq {yes}} {
+ if {[ask_popup $op_question] eq {yes}} {
set fd [git_read read-tree --reset -u HEAD]
fconfigure $fd -blocking 0 -translation binary
fileevent $fd readable [namespace code [list _reset_wait $fd]]
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] Don't rely on unspecified behavior
From: Johannes Schindelin @ 2007-07-28 20:17 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: git
In-Reply-To: <20070728194306.GA32203@fencepost.gnu.org>
Hi,
On Sat, 28 Jul 2007, Thomas Schwinge wrote:
> On Sat, Jul 28, 2007 at 08:30:07PM +0100, Johannes Schindelin wrote:
> > On Sat, 28 Jul 2007, Thomas Schwinge wrote:
> > > Calling access(p, m) with p == NULL is not specified, so don't do that. On
> > > GNU/Hurd systems doing so will result in a SIGSEGV.
> > >
> > > Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
> > > ---
> >
> > Isn't this the same patch as you sent before?
>
> As I wrote in <20070728182542.GA22651@fencepost.gnu.org>: ``I noticed
> that the patch I sent was prepared for an old version of the file. I'll
> send an updated patch that applies to the current revision.''
Ah.
> > > + if (excludes_file != NULL && !access(excludes_file, R_OK))
> >
> > We usually omit the "!= NULL"; see the other source code in git.git.
>
> Okay, so I should sent a thusly modified version to get it applied?
I don't think that is necessary; a small change like this is usually fixed
by Junio with --amend.
Ciao,
Dscho
^ 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