* Re: interactive rebase not rebasing
From: Andreas Ericsson @ 2008-09-29 6:42 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20080928235013.5c749c6e.stephen@exigencecorp.com>
Stephen Haberman wrote:
> Hello,
>
> Per the emails from me last week, I'm working in an environment with
> shared topic branches and am trying to find a bullet-proof way for devs
> to rebase their local commits after the topic branch has moved.
>
> The easy approach would be to just let `git pull` create merge commits,
> and I would have been done with this long ago, but I'm striving to get
> rebasing to "just work" and avoid the ugliness of same-branch merge
> commits. Cross-branch merge commits are cool, but not same-branch.
>
> So, here's a crazy scenario we've ran into--a new release has hit
> stable, with two devs working on the same topic branch, and both of them
> merge. One wins, and the other has to rebase. Previously, this was
> replaying commits, but with great tips from the list last week, `rebase
> -i -p` is handling most scenarios.
>
> However, not this one:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \|
> # g -- h <-- topic2
>
> topic2 is a dev that has locally merged stable in g, moved on in h, is
> ready to push, but another dev already merged stable in E, and also
> committed F.
>
> If we do a `git pull --no-rebase`, the result is:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \| \
> # g -- h ------- i <-- topic2
>
> But i is a same-branch merge, and we'd rather rebase to something like:
>
> # A --C------ <-- origin/stable
> # \ \
> # B -- D -- E -- F <-- origin/topic2
> # \
> # h' <-- topic2
>
> (...maybe g' in there if g resolved stable conflicts differently
> E did them. I'm not sure, I haven't gotten there yet.)
>
> However, currently, `git rebase -i -p origin/topic2` results in:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \|
> # g -- h <-- topic2
>
> Nothing has changed. g & h haven't moved...I can keep executing this
> operation and the commits never make it on top of origin/topic2's F.
>
> Frustratingly, if I run non-interactive rebase, it works perfectly.
I can imagine. Since you don't want to preserve the merges in this
case, you shouldn't be using the -p flag.
In fact, for this particular scenario (assuming "h" is really the only
commit on topic2), you probably want to just cherry-pick that commit
into origin/topic2:
git checkout topic2
git reset --hard origin/topic2
git cherry-pick ORIG_HEAD
would work nicely for that. If topic2 and topic1 resolved merge
conflicts differently, cherry-picking topic2 will give conflicts again,
so they'll have to be resolved. rebase (without -p) will have the same
effect, ofcourse.
I don't think you can have a single command that does all the things
you want, because the possible differences in input makes it very nearly
impossible to always do "the right thing". For this case, you don't
want to preserve merges, so "git rebase" without -p does the right
thing. For that other case earlier this week, you wanted to preserve
merges, so "git rebase -p" does the right thing there. It's complex
to try to dwim things like that, and complexity will cause very weird
and surprising errors when it *does* fail.
Instead, I think you should give your developers some training in the
more advanced parts of git's integration tools and also look over
your workflow. Frequently merging 'master' into a topic is very rarely
the right thing to do. It's usually better to rebase the topic onto
master or cherry-pick relevant bugfixes from 'master' into the topic.
If two devs need to work on one topic, then that topic probably needs
breaking up into a sub-topic. However, sub-topics should never merge
'master' into them themselves; only 'topic'. Otherwise you'll get
more merges than work done.
> But
> I've got other cases (see earlier posts) that do need the interactive
> rebase. Personally, I could probably make do with trying each and
> seeing what happened, but I'm really trying to find a bullet proof
> command/alias/script for devs to run and have it "just work".
>
Or you could sit down and think about what you want to happen and then
run the appropriate command. ;-)
> I've attached a test that sets up the DAG as above and currently passes
> by asserting the not-desired/unchanged-DAG result. The assert for the
> desired result is commented out at the end.
>
Thanks for this. If all bug-reports had this, bugfixing would be a lot
easier. However, for this particular case, I'm not so sure it's a bug.
> Am I correct in asserting this is some sort of bug in the interactive
> rebase such that g & h are not ending up on top of F?
>
Assuming you're passing a correct input file to rebase -i; yes. At the
very least, "h" should be moved to the tip of origin/topic2.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: A note from the interim Git maintainer
From: Mike Ralphson @ 2008-09-29 7:51 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080926225423.GA25502@coredump.intra.peff.net>
2008/9/26 Jeff King <peff@peff.net>
>
> On Fri, Sep 26, 2008 at 02:24:31PM +0100, Mike Ralphson wrote:
>
> > Jeff, if you want to switch your BSD builds to Shawn's tree too, I
> > made and pushed a tiny change to the gitbuild.sh script to allow for
> > the spearce/{branch} format becoming spearce_{branch} in the tag
> > names.
>
> Thanks, that's a good idea. I'm building Shawn's master (on my todo is
> adding the other branches, too, but I need to tweak my script or tweak
> gitbuild.sh and switch to it).
Feel free to push changes to gitbuild.sh, including getting rid of
anything which looks environment-specific.
Mike
^ permalink raw reply
* Re: [PATCH 5/6] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Jakub Narebski @ 2008-09-29 8:33 UTC (permalink / raw)
To: Giuseppe Bilotta
Cc: git, Petr Baudis, Lea Wiemann,
Shawn O. Pearce (interim Git maintainer)
In-Reply-To: <1222030663-22540-6-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
> This patch (combined with appropriate server configuration) allows usage
> of the gitweb CGI script as DirectoryIndex for the server root even when
> the pathinfo feature is enabled.
>
This is IMHO a bugfix for a path_info handling bug, for which there
was an ugly workaround of specifying base URL ($my_url and $my_uri)
explicitly in gitweb configuration (GITWEB_CONFIG).
Therefore I think that this patch should have been sent outside of
the rest of "new path_info features" series, as a separate single
patch, and now that it is there it really should be applied, perhaps
even to the 'maint' branch.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
(for what is worth)
> ---
> gitweb/gitweb.perl | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 0dd2526..4a91d07 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -26,6 +26,10 @@ our $cgi = new CGI;
> our $version = "++GIT_VERSION++";
> our $my_url = $cgi->url();
> our $my_uri = $cgi->url(-absolute => 1);
Perhaps some comment here?
> +if (my $path_info = $ENV{"PATH_INFO"}) {
> + $my_url =~ s,$path_info$,,;
> + $my_uri =~ s,$path_info$,,;
+ $my_url =~ s,\Q$path_info\E$,,;
+ $my_uri =~ s,\Q$path_info\E$,,;
Just in case.
> +}
>
> # core git executable to use
> # this can just be "git" if your webserver has a sensible PATH
I was wondering if $path_info should be global variable, but then
I checked that $path_info is local to evaluate_path_info() subroutine.
So it is good as it is now, but with quoting regular expression
metacharacters.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Clarify how the user can satisfy stash's 'dirty state' check.
From: Stephen Haberman @ 2008-09-29 9:12 UTC (permalink / raw)
To: git; +Cc: spearce
Clarify how the user can satisfy stash's 'dirty state' check.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
Feel free to tweak the wording, but we had a false assumption that you
could not apply multiple stashes in a row due to this confusing error
message. I.e. "dirty state" was taken as "dirty working tree and/or
index" instead of just "dirty working tree".
I don't have any tests, but t3903-stash.sh runs the same ("10: stash
branch" is failing both before and after my change change).
Looking into it more, I dislike that t3903's "3: apply needs clean
working directory" uses test_must_fail because without actively
asserting that the expected error message comes back, we can't be sure
the boundary condition that was originally tested for is still being met
(e.g. `git stash` could be returning non-zero for some entirely
different reason now--not likely, yes, but possible). test_must_fail
mentions a "segv" reason, which I'll somewhat blindly accept as good,
but it would be nice if I could pass in/grep against/something the error
message. Perhaps on another line/invocation?
Anyway...the patch:
git-stash.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index e15c12a..a932ca7 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -151,7 +151,7 @@ show_stash () {
apply_stash () {
git diff-files --quiet --ignore-submodules ||
- die 'Cannot restore on top of a dirty state'
+ die 'Cannot apply to a dirty working tree, please stage your changes'
unstash_index=
case "$1" in
--
1.6.0.2
^ permalink raw reply related
* git can't find none
From: Hinko Kocevar @ 2008-09-29 11:16 UTC (permalink / raw)
To: git
Hi,
I've recently discovered that some git command stopped working. I'm not sure if this is related to my git tree or not, it happens on other trees too:
$ git blame Makefile
sh: none: command not found
'none' ?
$ git clone ...
Works fine.
This is on gentoo using gentoo provided ebuild for git (I even tied reemerging git package with no avail).
$ git --version
git version 1.5.6.4
--
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply
* Re: git can't find none
From: Johannes Sixt @ 2008-09-29 11:34 UTC (permalink / raw)
To: Hinko Kocevar; +Cc: git
In-Reply-To: <48E0B8FE.6060203@cetrtapot.si>
Hinko Kocevar schrieb:
> Hi,
>
> I've recently discovered that some git command stopped working. I'm not sure if this is related to my git tree or not, it happens on other trees too:
> $ git blame Makefile
> sh: none: command not found
>
> 'none' ?
Try
$ git --no-pager blame Makefile
and if that works, correct your setting of PAGER or GIT_PAGER, e.g.
$ export GIT_PAGER=cat
-- Hannes
^ permalink raw reply
* Re: git can't find none
From: Hinko Kocevar @ 2008-09-29 11:33 UTC (permalink / raw)
To: git
In-Reply-To: <48E0B8FE.6060203@cetrtapot.si>
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
Hinko Kocevar wrote:
> Hi,
>
> I've recently discovered that some git command stopped working. I'm not sure if this is related to my git tree or not, it happens on other trees too:
> $ git blame Makefile
> sh: none: command not found
>
> 'none' ?
>
> $ git clone ...
> Works fine.
>
>
> This is on gentoo using gentoo provided ebuild for git (I even tied reemerging git package with no avail).
> $ git --version
> git version 1.5.6.4
>
ou,
forgot to attach strace output if anyone can see what is going on.
Thank you,
Hinko
--
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si
[-- Attachment #2: log --]
[-- Type: text/plain, Size: 15770 bytes --]
execve("/usr/bin/git", ["git", "status"], [/* 42 vars */]) = 0
brk(0) = 0x814e000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=78249, ...}) = 0
mmap2(NULL, 78249, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f1d000
close(3) = 0
open("/usr/lib/libcurl.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\221\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=244612, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f1c000
mmap2(NULL, 243932, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ee0000
mmap2(0xb7f1a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3a) = 0xb7f1a000
close(3) = 0
open("/lib/libz.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\25\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=71064, ...}) = 0
mmap2(NULL, 73976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ecd000
mmap2(0xb7ede000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10) = 0xb7ede000
close(3) = 0
open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\317\3\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=1294876, ...}) = 0
mmap2(NULL, 1307384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d8d000
mmap2(0xb7eb4000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x127) = 0xb7eb4000
mmap2(0xb7ec9000, 13048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ec9000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@a\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1237276, ...}) = 0
mmap2(NULL, 1242576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c5d000
mmap2(0xb7d87000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12a) = 0xb7d87000
mmap2(0xb7d8a000, 9680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7d8a000
close(3) = 0
open("/lib/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\30\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=30552, ...}) = 0
mmap2(NULL, 33356, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c54000
mmap2(0xb7c5b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb7c5b000
close(3) = 0
open("/usr/lib/libssl.so.0.9.8", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\305\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=266084, ...}) = 0
mmap2(NULL, 265016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c13000
mmap2(0xb7c50000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3d) = 0xb7c50000
close(3) = 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=9612, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c12000
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c0e000
mmap2(0xb7c10000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7c10000
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20H\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=118357, ...}) = 0
mmap2(NULL, 90592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7bf7000
mmap2(0xb7c0a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xb7c0a000
mmap2(0xb7c0c000, 4576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7c0c000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7bf6000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7bf68d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7c0a000, 4096, PROT_READ) = 0
mprotect(0xb7c10000, 4096, PROT_READ) = 0
mprotect(0xb7c50000, 4096, PROT_READ) = 0
mprotect(0xb7c5b000, 4096, PROT_READ) = 0
mprotect(0xb7d87000, 8192, PROT_READ) = 0
mprotect(0xb7eb4000, 32768, PROT_READ) = 0
mprotect(0xb7ede000, 4096, PROT_READ) = 0
mprotect(0xb7f1a000, 4096, PROT_READ) = 0
mprotect(0x8106000, 4096, PROT_READ) = 0
mprotect(0xb7f4b000, 4096, PROT_READ) = 0
munmap(0xb7f1d000, 78249) = 0
set_tid_address(0xb7bf6918) = 30293
set_robust_list(0xb7bf6920, 0xc) = 0
rt_sigaction(SIGRTMIN, {0xb7bfb310, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb7bfb390, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="alala", ...}) = 0
brk(0) = 0x814e000
brk(0x816f000) = 0x816f000
getcwd("/tmp/sdk", 4096) = 9
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(".git/objects", X_OK) = 0
access(".git/refs", X_OK) = 0
lstat64(".git/HEAD", {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
open(".git/HEAD", O_RDONLY|O_LARGEFILE) = 3
read(3, "ref: refs/heads/master\n", 255) = 23
read(3, "", 232) = 0
close(3) = 0
access("/etc/gitconfig", R_OK) = -1 ENOENT (No such file or directory)
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/home/hinkok/.gitconfig", R_OK) = 0
open("/home/hinkok/.gitconfig", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=155, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f30000
read(3, "[user]\n\temail = hinkocevar@gmail"..., 4096) = 155
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f30000, 4096) = 0
open(".git/config", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=244, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f30000
read(3, "[core]\n\trepositoryformatversion "..., 4096) = 244
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f30000, 4096) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
access("/etc/gitconfig", R_OK) = -1 ENOENT (No such file or directory)
access("/home/hinkok/.gitconfig", R_OK) = 0
open("/home/hinkok/.gitconfig", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=155, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f30000
read(3, "[user]\n\temail = hinkocevar@gmail"..., 4096) = 155
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f30000, 4096) = 0
open(".git/config", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=244, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f30000
read(3, "[core]\n\trepositoryformatversion "..., 4096) = 244
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f30000, 4096) = 0
pipe([3, 4]) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7bf6918) = 30294
dup2(3, 0) = 0
close(3) = 0
close(4) = 0
select(1, [0], NULL, [0], NULL) = 1 ()
--- SIGCHLD (Child exited) @ 0 (0) ---
execve("/usr/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/home/hinkok/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/work/tools/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/local/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/opt/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/i486-pc-linux-gnu/gcc-bin/4.1.2/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/i686-pc-linux-gnu/gcc-bin/4.1.2/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/bin/sh", ["sh"..., "-c"..., "none"...], [/* 42 vars */]) = 0
brk(0) = 0x80ed000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=78249, ...}) = 0
mmap2(NULL, 78249, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f14000
close(3) = 0
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\364\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=266136, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f13000
mmap2(NULL, 267076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ed1000
mmap2(0xb7f09000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x38) = 0xb7f09000
mmap2(0xb7f12000, 836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f12000
close(3) = 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=9612, ...}) = 0
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ecd000
mmap2(0xb7ecf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7ecf000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@a\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1237276, ...}) = 0
mmap2(NULL, 1242576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d9d000
mmap2(0xb7ec7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12a) = 0xb7ec7000
mmap2(0xb7eca000, 9680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7eca000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d9c000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7d9c6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7ec7000, 8192, PROT_READ) = 0
mprotect(0xb7ecf000, 4096, PROT_READ) = 0
mprotect(0xb7f09000, 32768, PROT_READ) = 0
mprotect(0x80e2000, 4096, PROT_READ) = 0
mprotect(0xb7f42000, 4096, PROT_READ) = 0
munmap(0xb7f14000, 78249) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
close(3) = 0
brk(0) = 0x80ed000
brk(0x810e000) = 0x810e000
getuid32() = 1000
getgid32() = 1000
geteuid32() = 1000
getegid32() = 1000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
time(NULL) = 1222687397
open("/proc/meminfo", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f27000
read(3, "MemTotal: 4079432 kB\nMemFre"..., 1024) = 754
close(3) = 0
munmap(0xb7f27000, 4096) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_IGN}, 8) = 0
uname({sys="Linux", node="alala", ...}) = 0
stat64("/tmp/sdk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getpid() = 30293
getppid() = 30292
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/home/hinkok/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/work/tools/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/bin/sh", {st_mode=S_IFREG|0755, st_size=651148, ...}) = 0
open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 3
read(3, "65536\n", 31) = 6
close(3) = 0
mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d5b000
getgroups32(65536, [7, 10, 14, 18, 19, 27, 80, 85, 100, 411, 1000, 1003]) = 12
stat64("/bin/sh", {st_mode=S_IFREG|0755, st_size=651148, ...}) = 0
getpgrp() = 30292
rt_sigaction(SIGCHLD, {0x807b8d5, [], 0}, {SIG_DFL}, 8) = 0
getrlimit(RLIMIT_NPROC, {rlim_cur=38400, rlim_max=38400}) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/home/hinkok/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/work/tools/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/opt/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/usr/i486-pc-linux-gnu/gcc-bin/4.1.2/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/usr/i686-pc-linux-gnu/gcc-bin/4.1.2/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {0x807b8d5, [], 0}, 8) = 0
fstat64(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f27000
write(2, "sh: none: command not found\n", 28) = 28
exit_group(127) = ?
^ permalink raw reply
* Re: git can't find none
From: Hinko Kocevar @ 2008-09-29 12:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <48E0BD38.6070602@viscovery.net>
Johannes Sixt wrote:
> Hinko Kocevar schrieb:
>> Hi,
>>
>> I've recently discovered that some git command stopped working. I'm not sure if this is related to my git tree or not, it happens on other trees too:
>> $ git blame Makefile
>> sh: none: command not found
>>
>> 'none' ?
>
> Try
>
> $ git --no-pager blame Makefile
It works! yes.
>
> and if that works, correct your setting of PAGER or GIT_PAGER, e.g.
>
> $ export GIT_PAGER=cat
I don't want any pager. I've set the config property to 'none' instead to "":
$ git-config core.pager ""
Thank you,
Hinko
--
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply
* Re: [PATCH] Add contrib/rerere-train script
From: Johannes Schindelin @ 2008-09-29 12:39 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080927204415.6117@nanako3.lavabit.com>
Hi,
On Sat, 27 Sep 2008, Nanako Shiraishi wrote:
> This script takes a range of commits (e.g. maint..next) as its
> arguments, recreates merge commits in the range to prime rr-cache
> database.
Cute idea. However, I would _love_ to have this as an option to
git-rerere, which would work in memory only.
This is how I would do it (if I had enough time to play with Git):
- teach merge_recursive_options not to write anything to the working
directory (should be relatively easy, as many parts of merge-recursive.c
already have no_wd/update_wd/!o->call_depth checks for that),
- refactor handle_file() in rerere.c to provide an in-memory-only version,
- teach rerere to call merge_recursive() with the in-memory-only option,
and then call the in-memory version of the handle_file() function for
all unmerged paths, using the resolutions from the given merge commit.
- then teach this new function to take an arbitrary commit range (but only
handling the two-parent merges within it).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/6] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Giuseppe Bilotta @ 2008-09-29 13:05 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Petr Baudis, Lea Wiemann,
Shawn O. Pearce (interim Git maintainer)
In-Reply-To: <200809291033.34588.jnareb@gmail.com>
On Mon, Sep 29, 2008 at 10:33 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
>
>> This patch (combined with appropriate server configuration) allows usage
>> of the gitweb CGI script as DirectoryIndex for the server root even when
>> the pathinfo feature is enabled.
>>
>
> This is IMHO a bugfix for a path_info handling bug, for which there
> was an ugly workaround of specifying base URL ($my_url and $my_uri)
> explicitly in gitweb configuration (GITWEB_CONFIG).
>
> Therefore I think that this patch should have been sent outside of
> the rest of "new path_info features" series, as a separate single
> patch, and now that it is there it really should be applied, perhaps
> even to the 'maint' branch.
Ok, I'll resend it separately, with the suggested fix.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Giuseppe Bilotta @ 2008-09-29 13:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
This patch fixes PATH_INFO handling by removing the relevant part from
$my_url and $my_uri, thus making it unnecessary to specify them by hand
in the gitweb configuration.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index da474d0..ffe3dbf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -27,6 +27,13 @@ our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
+# if we're called with PATH_INFO, we have to strip that
+# from the URL to find our real URL
+if (my $path_info = $ENV{"PATH_INFO"}) {
+ $my_url =~ s,\Q$path_info\E$,,;
+ $my_uri =~ s,\Q$path_info\E$,,;
+}
+
# core git executable to use
# this can just be "git" if your webserver has a sensible PATH
our $GIT = "++GIT_BINDIR++/git";
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Jakub Narebski @ 2008-09-29 13:39 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce
In-Reply-To: <1222693662-27426-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta wrote:
> This patch fixes PATH_INFO handling by removing the relevant part from
> $my_url and $my_uri, thus making it unnecessary to specify them by hand
> in the gitweb configuration.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/6] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-09-29 14:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <200809290308.09312.jnareb@gmail.com>
On Mon, Sep 29, 2008 at 3:08 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
>
>> When using path info, make filenames start with a / (right after the :
>> that separates them from the hash base). This minimal change allows
>> relative navigation to work properly when viewing HTML files.
>
> Good idea. Nitpick: instead of "using path info", perhaps "generating
> path info URL"; this change is about gitweb link generation...
Right.
> Did you check if gitweb strips leading '/' from filename?
Yes.
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>> gitweb/gitweb.perl | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index e783d12..18da484 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -664,7 +664,7 @@ sub href (%) {
>> if (defined $params{'hash_base'}) {
>> $href .= "/".esc_url($params{'hash_base'});
>> if (defined $params{'file_name'}) {
>> - $href .= ":".esc_url($params{'file_name'});
>> + $href .= ":/".esc_url($params{'file_name'});
>> delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
>> delete $params{'file_name'};
>> } else {
>> --
>> 1.5.6.5
>
> Is there reason why this change is separate (not squashed) from
> previous commit?
Historical reason (i.e. I came up with the idea later on). I'll squash it.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] git-svn: call 'fatal' correctly in set-tree
From: Luc Heinrich @ 2008-09-29 13:58 UTC (permalink / raw)
To: git; +Cc: gitster, Luc Heinrich
When doing a set-tree and there is no revision to commit to, the following unrelated error message is displayed: "Undefined subroutine &Git::SVN::fatal called at /opt/local/libexec/git-core/git-svn line 2575." The following patch fixes the problem and allows the real error message to be shown.
Signed-off-by: Luc Heinrich <luc@honk-honk.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 80a5728..7609a83 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2591,7 +2591,7 @@ sub set_tree {
my ($self, $tree) = (shift, shift);
my $log_entry = ::get_commit_entry($tree);
unless ($self->{last_rev}) {
- fatal("Must have an existing revision to commit");
+ ::fatal("Must have an existing revision to commit");
}
my %ed_opts = ( r => $self->{last_rev},
log => $log_entry->{log},
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Giuseppe Bilotta @ 2008-09-29 14:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <200809290303.21290.jnareb@gmail.com>
On Mon, Sep 29, 2008 at 3:03 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> I'm sorry for the delay reviewing those patches.
>
> On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
>
>> When using path info, reduce the number of CGI parameters by embedding
>> the action in the path. The typicial cgiweb path is thus
>> $project/$action/$hash_base:$file_name or $project/$action/$hash
>
> cgiweb?
Good question. I have no idea why I wrote that instad of gitweb.
>> This is mostly backwards compatible with the old-style gitweb paths,
>> except when $project/$branch was used to access a branch whose name
>> matches a gitweb action.
>
> I would also state that gitweb _generates_ such pathinfo links if
> configured (or if coming from pahinfo URL), and that this change
> allow to represent wider number of gitweb links (gitweb URLs) in
> pathinfo form.
Can do.
> Also, from what I understand, generated pathinfo links now always
> use action, so they are a tiny little bit longer.
Is that a problem, by the way? I've had half-thoughts about making the
action implicit when possible, but I'm afraid that's prone to make the
code way more complex and the path info handling much less robust.
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>> gitweb/gitweb.perl | 109 ++++++++++++++++++++++++++++++++++------------------
>> 1 files changed, 72 insertions(+), 37 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index da474d0..e783d12 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -488,6 +488,37 @@ if (defined $searchtext) {
>> $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
>> }
>>
>> +# dispatch
>> +my %actions = (
>> + "blame" => \&git_blame,
>> + "blobdiff" => \&git_blobdiff,
>> + "blobdiff_plain" => \&git_blobdiff_plain,
>> + "blob" => \&git_blob,
>> + "blob_plain" => \&git_blob_plain,
>> + "commitdiff" => \&git_commitdiff,
>> + "commitdiff_plain" => \&git_commitdiff_plain,
>> + "commit" => \&git_commit,
>> + "forks" => \&git_forks,
>> + "heads" => \&git_heads,
>> + "history" => \&git_history,
>> + "log" => \&git_log,
>> + "rss" => \&git_rss,
>> + "atom" => \&git_atom,
>> + "search" => \&git_search,
>> + "search_help" => \&git_search_help,
>> + "shortlog" => \&git_shortlog,
>> + "summary" => \&git_summary,
>> + "tag" => \&git_tag,
>> + "tags" => \&git_tags,
>> + "tree" => \&git_tree,
>> + "snapshot" => \&git_snapshot,
>> + "object" => \&git_object,
>> + # those below don't need $project
>> + "opml" => \&git_opml,
>> + "project_list" => \&git_project_list,
>> + "project_index" => \&git_project_index,
>> +);
>> +
>
> This is as I understand simply moving %actions hash around?
Yes.
> Well, you could instead split hash declaration from defining it,
> in the form of
>
> my %actions = ();
> ...
> %actions = (
> ...
> );
>
> but I guess moving declaration earlier is good solution.
Is there some coding style recommendation wrt this situations, or is
it just a matter of making the patch smaller?
>> # now read PATH_INFO and use it as alternative to parameters
>> sub evaluate_path_info {
>> return if defined $project;
>> @@ -512,6 +543,16 @@ sub evaluate_path_info {
>> # do not change any parameters if an action is given using the query string
>> return if $action;
>> $path_info =~ s,^\Q$project\E/*,,;
>> +
>> + # next comes the action
>> + $action = $path_info;
>> + $action =~ s,/.*$,,;
>
> I would use perhaps "$action = ($path_info =~ m!^([^/]+)/!;"
> But that is Perl, so TIMTOWDI.
Well, Perl is not my native language so I tend to stay away from
complex expressions if possible ;-)
>> + if (exists $actions{$action}) {
>> + $path_info =~ s,^\Q$action\E/*,,;
>> + } else {
>> + $action = undef;
>> + }
>> +
>
> I don't think you need quoting pattern metacharacters; valid actions
> should not contain regexp metacharacters. Defensive programming?
You're right, in this case it's probably excessive. I'll strip it out.
>> my ($refname, $pathname) = split(/:/, $path_info, 2);
>> if (defined $pathname) {
>> # we got "project.git/branch:filename" or "project.git/branch:dir/"
>> @@ -525,10 +566,12 @@ sub evaluate_path_info {
>> }
>> $hash_base ||= validate_refname($refname);
>> $file_name ||= validate_pathname($pathname);
>> + $hash ||= git_get_hash_by_path($hash_base, $file_name);
>
> I don't understand why you feel that you need to do this (this is
> additional git command fork, as git_get_hash_by_path calls Git, to
> be more exact it calls git-ls-tree (it could call git-rev-parse
> instead). Moreover, I don't understand why you need to do this _here_,
> instead of just before where you would have to have $hash variable set.
Hm. I must confess that I honestly don't remember. The same holds for
the other chunks you have perplexities on. When I started writing
these patches I came across a few situations where $hash wouldn't
carry over properly, but now I can't seem to recreate those issues
anymore, which leads me to suspect it was a problem with hand-crafted
links (i.e. before I coded the link generation part too). I'll resend
without these chunks.
> > @@ -624,8 +636,13 @@ sub href (%) {
> > if ($params{-replay}) {
> > while (my ($name, $symbol) = each %mapping) {
> > if (!exists $params{$name}) {
> > - # to allow for multivalued params we use arrayref form
> > - $params{$name} = [ $cgi->param($symbol) ];
> > + if ($cgi->param($symbol)) {
> > + # to allow for multivalued params we use arrayref form
> > + $params{$name} = [ $cgi->param($symbol) ];
> > + } else {
> > + no strict 'refs';
> > + $params{$name} = $$name if $$name;
> > + }
> > }
> > }
> > }
>
> What this change is about? And why this change is _here_, in this
> commit? It is I think unrelated, and wrong change.
This is about being able to recycle CGI parameters that came through
as part of path_info instead of the CGI parameter list. It might not
be the best way to recover it, though. I *did* have a few thoughts
about an alternative way that consisted of build a parameter list
merging CGI and path-info parameter, but since this approach seemed to
work, I went with it.
> href(..., -replay=>1) is all about reusing current URL, perhaps with
> a few parameters changed, like for example pagination links differ only
> in page number param change. For example if we had only hb= and f=
> parameters, -replay=>1 links should use only those, and not add h=
> parameter because somewhere we felt that we need $hash to be calculated.
Assume for example that you are to an url such as
http://git.oblomov.eu/git/tree/refs/remotes/origin/master:gitweb
Without this patch, the 'history' link on the second header line links
to ARRAY(0xblah)ARRAY(0xblah). With this patch, it shows the proper
link. So either replay is being abused somewhere in the link
generation code, or this CGI+path_info parameter retrieval is
necessary, one way or the other.
>> @@ -636,10 +653,28 @@ sub href (%) {
>
> This hunk is about generating pathinfo URL, isn't it?
Yes.
> You probably would want to change comment at the top of this part
> of href() subroutine, namely
>
> if ($use_pathinfo) {
> # use PATH_INFO for project name
>
> as you now try to use PATH_INFO for more than project name. Please do
> not leave comments to get out of sync with the code.
Right.
>> $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
>> delete $params{'project'};
>>
>> - # Summary just uses the project path URL
>> - if (defined $params{'action'} && $params{'action'} eq 'summary') {
>> + # Summary just uses the project path URL, any other action come next
>> + # in the URL
>> + if (defined $params{'action'}) {
>> + $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
>> delete $params{'action'};
>> }
>> +
>> + # next, we put either hash_base:file_name or hash
>> + if (defined $params{'hash_base'}) {
>> + $href .= "/".esc_url($params{'hash_base'});
>> + if (defined $params{'file_name'}) {
>> + $href .= ":".esc_url($params{'file_name'});
>> + delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
>
> First, this page has around 140 characters. That is too long, much too long.
> Please try to wrap code around 80-characters.
>
> Second, following Petr 'Pasky' Baudis suggestion of reducing complexity
> and shortening gitweb URLs, we could unconditionally remove redundant
> 'hash' parameter if we have both 'hash_base' and 'file_name'
> parameters. This would also simplify and speed up (lack of extra fork)
> gitweb code.
If it's indeed guaranteed that hash is not needed in these cases, it's
surely the best course of action. I changed the code to that effect.
>> + delete $params{'file_name'};
>> + } else {
>> + delete $params{'hash'} if $params{'hash'} eq $params{'hash_base'};
>> + }
>> + delete $params{'hash_base'};
>> + } elsif (defined $params{'hash'}) {
>> + $href .= "/".esc_url($params{'hash'});
>> + delete $params{'hash'};
>> + }
>
> O.K.... I think.
>
> Did you test this, preferably also using Mechanize test, with gitweb
> configuration turning path_info on by default.?
The whole patchset is running both on my machine on
http://git.oblomov.eu and on the rbot repository
http://ruby-rbot.org/gitweb (older version there, though). I have no
idea how to run automated Mechanize tests though.
>> }
>>
>> # now encode the parameters explicitly
>
> Hmmm... now I am not so sure if it wouldn't be better to split this
> patch in pathinfo parsing and pathinfo generation. The first part
> would be obvious, the second part would be smaller and easier to review.
Ok, I'll split parsing from generation. Since it's what I did for
subsequent extensions (such as the parent..current thing) it also fits
nicely with the patchflow.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC/PATCH] remove vim syntax highlighting in favor of upstream
From: Shawn O. Pearce @ 2008-09-29 14:55 UTC (permalink / raw)
To: SZEDER GGGbor; +Cc: Jeff King, vim, git
In-Reply-To: <20080924195658.GB6816@neumann>
SZEDER GGGbor <szeder@ira.uka.de> wrote:
> remove vim syntax highlighting in favor of upstream
>
> As of version 7.2, vim ships with its own syntax
> highlighting for git commit messages, which is:
>
> 1. more comprehensive in splitting up the various
> components of the file
>
> 2. in accordance with the usual vim behavior for syntax
> highlighting (e.g., respecting b:current_syntax)
>
> 3. presumably better maintained (I have not been using
> what's in git's contrib/ directory for some time in
> favor of the upstream version)
>
> Furthermore, vim 7.2 also provides syntax highlighting for
> other git filetypes (gitconfig, rebase, send-email).
>
> This patch gets rid of our local version and just points
> interested parties to the upstream version.
>
> The code for auto-detecting filetypes is taken from vim 7.2's
> runtime/filetype.vim.
>
> ---
> contrib/vim/README | 38 ++++++++++++++++++++++++++++++--------
> contrib/vim/syntax/gitcommit.vim | 18 ------------------
> 2 files changed, 30 insertions(+), 26 deletions(-)
> delete mode 100644 contrib/vim/syntax/gitcommit.vim
Missing SBO line?
--
Shawn.
^ permalink raw reply
* [PATCH] Fix typo in release notes for 1.6.0.3
From: Miklos Vajna @ 2008-09-29 14:58 UTC (permalink / raw)
To: spearce; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/RelNotes-1.6.0.3.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/RelNotes-1.6.0.3.txt b/Documentation/RelNotes-1.6.0.3.txt
index 46e13a4..a374690 100644
--- a/Documentation/RelNotes-1.6.0.3.txt
+++ b/Documentation/RelNotes-1.6.0.3.txt
@@ -16,7 +16,7 @@ Fixes since v1.6.0.2
* Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code"
with the output redirected to /dev/null.
-* "git stash apply sash@{1}" was fixed to error out. Prior versions
+* "git stash apply stash@{1}" was fixed to error out. Prior versions
would have applied stash@{0} incorrectly.
* "git for-each-ref --format=%(subject)" fixed for commits with no
--
1.6.0
^ permalink raw reply related
* Re: having to pull twice
From: Miklos Vajna @ 2008-09-29 15:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: Shawn O. Pearce, Michael P. Soulier, git
In-Reply-To: <200809281726.23062.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]
On Sun, Sep 28, 2008 at 05:26:20PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
> IIUC, this is not the same as "racy git". The racy case is if you
> manage to get a file changed immediately after its index entry was
> updated, so that it will look unchanged. In this case, it's simply
> the same file with a new mtime, which means it looks changed
> superficially but still has the same contents.
Right. I called it "racy" because it had something to do with
timestamps. I guess we have no proper term for this kind of problem yet.
;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] doc: enhance git describe --tags help
From: Shawn O. Pearce @ 2008-09-29 15:01 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Erez Zilber, git@vger.kernel.org, open-iscsi, Junio C Hamano
In-Reply-To: <20080928151259.GJ5302@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index c4dbc2a..9cc8c2f 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -30,7 +30,8 @@ OPTIONS
>
> --tags::
> Instead of using only the annotated tags, use any tag
> - found in `.git/refs/tags`.
> + found in `.git/refs/tags`. Though if an annotated tag is found in the
> + ancestry, it will always be preferred to lightweight tags.
As technically correct as the statement is, I read this and go
"why do we even have --tags?".
If I read builtin-describe.c right we only honor --tags on an exact
match, or if there are no annotated tags at all in the history.
I wonder if docs like this aren't better for --tags:
--tags::
If a lightweight tag exactly matches, output it. If no
annotated tag is found in the ancestry but a lightweight
tag is found, output the lightweight tag.
?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Miklos Vajna @ 2008-09-29 15:07 UTC (permalink / raw)
To: Jakub Narebski
Cc: SZEDER Gábor, git, Shawn O. Pearce, Johannes.Schindelin
In-Reply-To: <200809270151.51785.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
On Sat, Sep 27, 2008 at 01:51:47AM +0200, Jakub Narebski <jnareb@gmail.com> wrote:
> > Actually I think this would be ugly. MERGE_HEAD is about you can see
> > what will be merged once you commit the merge, but once you include HEAD
> > there, you can't easily check that. Maybe it's just me who sometimes
> > have a look at that file myself directly... :-)
>
> The new semantic would be very simple. If there is no MERGE_HEAD, it
> is an ordinary no-merge commit, and its only parent would be previous
> (current) version of HEAD. If there is MERGE_HEAD it contains _all_
> parents in a merge commit, and only those heads which will be parents
> (_reduced_ heads); if HEAD is symref, we modify given branch so it
> points to newly created merge commit.
>
> Currently parents of merge commits are 'reduce(HEAD + MERGE_HEAD)'
> in symbolic equation; I propose they would be simply 'MERGE_HEAD'.
> then we set this branch to new commit
Yes. Currently - after a merge conflict - you are able to check what
heads caused were merged, which caused the conflict, but with this
approach you would not be able to. I think this would be a step back...
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix typo in release notes for 1.6.0.3
From: Shawn O. Pearce @ 2008-09-29 15:08 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1222700288-29717-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> diff --git a/Documentation/RelNotes-1.6.0.3.txt b/Documentation/RelNotes-1.6.0.3.txt
> index 46e13a4..a374690 100644
> --- a/Documentation/RelNotes-1.6.0.3.txt
> +++ b/Documentation/RelNotes-1.6.0.3.txt
> @@ -16,7 +16,7 @@ Fixes since v1.6.0.2
> * Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code"
> with the output redirected to /dev/null.
>
> -* "git stash apply sash@{1}" was fixed to error out. Prior versions
> +* "git stash apply stash@{1}" was fixed to error out. Prior versions
> would have applied stash@{0} incorrectly.
Actually maybe that typo was a good thing. The commit was about
erroring out on typos rather than silently applying stash@{0}.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Jan Nieuwenhuizen @ 2008-09-29 10:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: martin f krafft, git, Jan Holesovsky
In-Reply-To: <20080923132728.GV10360@machine.or.cz>
On di, 2008-09-23 at 15:27 +0200, Petr Baudis wrote:
> what we can't make to work is just the
> most generic case, but e.g. if master is a *leaf* branch nothing else
> depends on and it can't get the branch through multiple paths, you can
> do the dependency removal rather easily (if it can get through multiple
> paths, you can still do it but you might have to deal with big
> conflicts).
This already would be very nice and would probably remove the last
technical hurdle to switch. Is it also easy to detect if a branch is
a leaf node?
> But if you scenario indeed is totally generic, I'm afraid I don't know
> how to make TopGit remove dependencies, except perhaps for the price of
> massive complexity and massive slowdown (pretty much redoing all the
> history walking etc.). Maybe someone else comes by with a genial
> solution...
Ah, so the problem is about branches depending on a branch from which
a dependency is removed. What is it that we need to be looking for
by history walking? Can't we possibly keep/cache that info in a
special topgit file?
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* [PATCHv3] gitweb path info enhancements
From: Giuseppe Bilotta @ 2008-09-29 15:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
Third run for the PATH_INFO handling enhancements in gitweb. A
trivial but important bugfix was sent as a separate patch, and the
other patches were rearranged a little, reducing the total number of
patches to four, paired in parsing and generation of the enhanced
PATH_INFO URLs.
The first two patches deal with the inclusion of action and hash or
the hash_base:filename pair in the URL, while still keeping support
for old-style PATH_INFO URLs whenever possible.
The other two patches extend the URL format to also include parent
hash/filename information when possible.
Giuseppe Bilotta (4):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: parse parent..current syntax from pathinfo
gitweb: generate parent..current URLs
gitweb/gitweb.perl | 167 +++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 126 insertions(+), 41 deletions(-)
^ permalink raw reply
* [PATCHv3] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-09-29 15:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1222702017-4496-1-git-send-email-giuseppe.bilotta@gmail.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
except when $project/$branch was used to access a branch whose name
matches a gitweb action.
---
gitweb/gitweb.perl | 90 +++++++++++++++++++++++++++++++---------------------
1 files changed, 54 insertions(+), 36 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ffe3dbf..a3076bd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -495,6 +495,37 @@ if (defined $searchtext) {
$search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
+# dispatch
+my %actions = (
+ "blame" => \&git_blame,
+ "blobdiff" => \&git_blobdiff,
+ "blobdiff_plain" => \&git_blobdiff_plain,
+ "blob" => \&git_blob,
+ "blob_plain" => \&git_blob_plain,
+ "commitdiff" => \&git_commitdiff,
+ "commitdiff_plain" => \&git_commitdiff_plain,
+ "commit" => \&git_commit,
+ "forks" => \&git_forks,
+ "heads" => \&git_heads,
+ "history" => \&git_history,
+ "log" => \&git_log,
+ "rss" => \&git_rss,
+ "atom" => \&git_atom,
+ "search" => \&git_search,
+ "search_help" => \&git_search_help,
+ "shortlog" => \&git_shortlog,
+ "summary" => \&git_summary,
+ "tag" => \&git_tag,
+ "tags" => \&git_tags,
+ "tree" => \&git_tree,
+ "snapshot" => \&git_snapshot,
+ "object" => \&git_object,
+ # those below don't need $project
+ "opml" => \&git_opml,
+ "project_list" => \&git_project_list,
+ "project_index" => \&git_project_index,
+);
+
# now read PATH_INFO and use it as alternative to parameters
sub evaluate_path_info {
return if defined $project;
@@ -519,9 +550,19 @@ sub evaluate_path_info {
# do not change any parameters if an action is given using the query string
return if $action;
$path_info =~ s,^\Q$project\E/*,,;
+
+ # next comes the action
+ $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^$action/*,,;
+ } else {
+ $action = undef;
+ }
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
- # we got "project.git/branch:filename" or "project.git/branch:dir/"
+ # we got "project.git/action/branch:filename" or "project.git/action/branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
$pathname =~ s,^/+,,;
if (!$pathname || substr($pathname, -1) eq "/") {
@@ -534,8 +575,9 @@ sub evaluate_path_info {
$file_name ||= validate_pathname($pathname);
} elsif (defined $refname) {
# we got "project.git/branch"
- $action ||= "shortlog";
- $hash ||= validate_refname($refname);
+ $action ||= "shortlog";
+ $hash ||= validate_refname($refname);
+ $hash_base ||= validate_refname($refname);
}
}
evaluate_path_info();
@@ -544,37 +586,6 @@ evaluate_path_info();
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
-# dispatch
-my %actions = (
- "blame" => \&git_blame,
- "blobdiff" => \&git_blobdiff,
- "blobdiff_plain" => \&git_blobdiff_plain,
- "blob" => \&git_blob,
- "blob_plain" => \&git_blob_plain,
- "commitdiff" => \&git_commitdiff,
- "commitdiff_plain" => \&git_commitdiff_plain,
- "commit" => \&git_commit,
- "forks" => \&git_forks,
- "heads" => \&git_heads,
- "history" => \&git_history,
- "log" => \&git_log,
- "rss" => \&git_rss,
- "atom" => \&git_atom,
- "search" => \&git_search,
- "search_help" => \&git_search_help,
- "shortlog" => \&git_shortlog,
- "summary" => \&git_summary,
- "tag" => \&git_tag,
- "tags" => \&git_tags,
- "tree" => \&git_tree,
- "snapshot" => \&git_snapshot,
- "object" => \&git_object,
- # those below don't need $project
- "opml" => \&git_opml,
- "project_list" => \&git_project_list,
- "project_index" => \&git_project_index,
-);
-
if (!defined $action) {
if (defined $hash) {
$action = git_get_type($hash);
@@ -631,8 +642,15 @@ sub href (%) {
if ($params{-replay}) {
while (my ($name, $symbol) = each %mapping) {
if (!exists $params{$name}) {
- # to allow for multivalued params we use arrayref form
- $params{$name} = [ $cgi->param($symbol) ];
+ # the parameter we want to recycle may be either part of the
+ # list of CGI parameter, or recovered from PATH_INFO
+ if ($cgi->param($symbol)) {
+ # to allow for multivalued params we use arrayref form
+ $params{$name} = [ $cgi->param($symbol) ];
+ } else {
+ no strict 'refs';
+ $params{$name} = $$name if $$name;
+ }
}
}
}
--
1.5.6.5
^ permalink raw reply related
* [PATCHv3] gitweb: generate project/action/hash URLs
From: Giuseppe Bilotta @ 2008-09-29 15:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1222702017-4496-2-git-send-email-giuseppe.bilotta@gmail.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 32 +++++++++++++++++++++++++++++---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a3076bd..75d4178 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -657,14 +657,40 @@ sub href (%) {
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
- # use PATH_INFO for project name
+ # try to put as many parameters as possible in PATH_INFO:
+ # - project name
+ # - action
+ # - hash or hash_base:filename
+
+ # Strip any trailing / from $href, or we might get double
+ # slashes when the script is the DirectoryIndex
+ #
+ $href =~ s,/$,,;
+
+ # Then add the project name, if present
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action is
+ # added to the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # Finally, we put either hash_base:/file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":/".esc_url($params{'file_name'});
+ delete $params{'file_name'};
+ }
+ delete $params{'hash'};
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
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