* [PATCH 3/3] unpack-trees: remove redundant path search in verify_absent
From: Clemens Buchacher @ 2009-01-01 20:54 UTC (permalink / raw)
To: git; +Cc: gitster, Clemens Buchacher
In-Reply-To: <1230843273-11056-3-git-send-email-drizzd@aon.at>
Since the only caller, verify_absent, relies on the fact that o->pos
points to the next index entry anyways, there is no need to recompute
its position.
Furthermore, if a nondirectory entry were found, this would return too
early, because there could still be an untracked directory in the way.
This is currently not a problem, because verify_absent is only called
if the index does not have this entry.
---
unpack-trees.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index f8e2484..c4dc6dc 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -495,7 +495,7 @@ static int verify_clean_subdirectory(struct cache_entry *ce, const char *action,
* anything in the existing directory there.
*/
int namelen;
- int pos, i;
+ int i;
struct dir_struct d;
char *pathbuf;
int cnt = 0;
@@ -516,11 +516,7 @@ static int verify_clean_subdirectory(struct cache_entry *ce, const char *action,
* in that directory.
*/
namelen = strlen(ce->name);
- pos = index_name_pos(o->src_index, ce->name, namelen);
- if (0 <= pos)
- return 0; /* we have it as nondirectory */
- pos = -pos - 1;
- for (i = pos; i < o->src_index->cache_nr; i++) {
+ for (i = o->pos; i < o->src_index->cache_nr; i++) {
struct cache_entry *ce2 = o->src_index->cache[i];
int len = ce_namelen(ce2);
if (len < namelen ||
--
1.6.1
^ permalink raw reply related
* Re: unpack-trees: fix D/F conflict bugs in verify_absent
From: Junio C Hamano @ 2009-01-01 21:28 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, gitster
In-Reply-To: <1230843273-11056-1-git-send-email-drizzd@aon.at>
Clemens Buchacher <drizzd@aon.at> writes:
> I came across a few bugs while investigating the changes I proposed in the
> modify/delete conflict thread. The first two are quite obvious. The third I'm
> not so sure about. I could not find a testcase where it matters. Junio, do you
> recall the original intention of that code?
Thanks, but I see only [PATCH 1/3] and [PATCH 2/3] (both of which look
sane, by the way).
^ permalink raw reply
* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: Markus Heidelberg @ 2009-01-01 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr63mivx3.fsf@gitster.siamese.dyndns.org>
The upstream branch <upstream> now defaults to the first tracked
remote branch, which is set by the configuration variables
branch.<name>.remote and branch.<name>.merge of the current branch.
Without such a remote branch, the command "git cherry [-v]" fails with
usage output as before and an additional message.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Junio C Hamano, 01.01.2009:
> > -'git cherry' [-v] <upstream> [<head>] [<limit>]
> > +'git cherry' [-v] [<upstream>] [<head>] [<limit>]
>
> Shouldn't this be [<upstream> [<head> [<limit>]]]?
Sure.
Documentation/git-cherry.txt | 3 ++-
builtin-log.c | 16 ++++++++++++++--
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
index 74d14c4..7deefda 100644
--- a/Documentation/git-cherry.txt
+++ b/Documentation/git-cherry.txt
@@ -7,7 +7,7 @@ git-cherry - Find commits not merged upstream
SYNOPSIS
--------
-'git cherry' [-v] <upstream> [<head>] [<limit>]
+'git cherry' [-v] [<upstream> [<head> [<limit>]]]
DESCRIPTION
-----------
@@ -51,6 +51,7 @@ OPTIONS
<upstream>::
Upstream branch to compare against.
+ Defaults to the first tracked remote branch, if available.
<head>::
Working branch; defaults to HEAD.
diff --git a/builtin-log.c b/builtin-log.c
index 99d1137..7e9616e 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -16,6 +16,7 @@
#include "patch-ids.h"
#include "run-command.h"
#include "shortlog.h"
+#include "remote.h"
/* Set a default date-time format for git log ("log.date" config variable) */
static const char *default_date_mode = NULL;
@@ -1070,13 +1071,14 @@ static int add_pending_commit(const char *arg, struct rev_info *revs, int flags)
}
static const char cherry_usage[] =
-"git cherry [-v] <upstream> [<head>] [<limit>]";
+"git cherry [-v] [<upstream> [<head> [<limit>]]]";
int cmd_cherry(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
struct patch_ids ids;
struct commit *commit;
struct commit_list *list = NULL;
+ struct branch *current_branch;
const char *upstream;
const char *head = "HEAD";
const char *limit = NULL;
@@ -1099,7 +1101,17 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
upstream = argv[1];
break;
default:
- usage(cherry_usage);
+ current_branch = branch_get(NULL);
+ if (!current_branch || !current_branch->merge
+ || !current_branch->merge[0]
+ || !current_branch->merge[0]->dst) {
+ fprintf(stderr, "Could not find a tracked"
+ " remote branch, please"
+ " specify <upstream> manually.\n");
+ usage(cherry_usage);
+ }
+
+ upstream = current_branch->merge[0]->dst;
}
init_revisions(&revs, prefix);
--
1.6.1.35.ge4490
^ permalink raw reply related
* [RFC/PATCH] git-web--browse: don't add start as candidate on Ubuntu
From: Ramsay Jones @ 2009-01-01 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi *,
When upgrading to v1.6.1, I noticed that the html help had stopped
working on Linux (Ububtu), viz:
$ git help -w tag
start: Need to be root
So, after squinting at git-web--browse.sh, I tried a few things:
$ ls /bin/start
ls: /bin/start: No such file or directory
$ test -n /bin/start; echo $?
0
$ which start
/sbin/start
$ start fred
start: Need to be root
$ ls -l /sbin/start
lrwxrwxrwx 1 root root 7 2007-06-24 19:45 /sbin/start -> initctl*
So, it would seem that /sbin/start is part of upstart, which would
explain the "Need to be root" ;-)
$ test -x /bin/start; echo $?
1
$
So, the patch below fixes the issue for me, but as I don't have MinGW
installed, I can't test this fix works there.
Does anybody else see this issue and can someone test the patch?
ATB,
Ramsay Jones
git-web--browse.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 78d236b..7ed0fad 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -115,7 +115,7 @@ if test -z "$browser" ; then
browser_candidates="open $browser_candidates"
fi
# /bin/start indicates MinGW
- if test -n /bin/start; then
+ if test -x /bin/start; then
browser_candidates="start $browser_candidates"
fi
--
1.6.1
^ permalink raw reply related
* Re: Extracting a single commit or object
From: Alex Riesen @ 2009-01-01 22:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: yitzhakbg, git
In-Reply-To: <20081230222106.GE29071@spearce.org>
2008/12/30 Shawn O. Pearce <spearce@spearce.org>:
> yitzhakbg <yitzhakbg@gmail.com> wrote:
>>
>> How would I extract a single commit from a repository by it's SHA1 (or any
>> other treeish)?
>> For that matter, how is any one single object extracted? Examples please.
>
> git cat-file $type $sha1
>
git cat-file -p $sha1
^ permalink raw reply
* Re: [PATCH] Documentation/git-bundle.txt: Dumping contents of any bundle
From: jidanni @ 2009-01-01 22:12 UTC (permalink / raw)
To: peff, Johannes.Schindelin; +Cc: nico, gitster, mdl123, spearce, git
In-Reply-To: <20090101192153.GA6536@coredump.intra.peff.net>
JK> Maybe it would be worth adding an option to dump the uncompressed
JK> deltas to a file or directory so you could run "strings" on them
JK> to recover some of the data.
I got as far as these wheezy little bytes,
$ ls ??/*|tr -d /|sed q|xargs git cat-file tree|perl -pwe 's/[^\0]+[\0]//'|hd
00000000 ae 83 2f 22 45 89 2d dd e5 22 13 57 46 64 48 b4 |../"E.-..".WFdH.|
00000010 09 77 51 42 |.wQB|
before I ran out of tools to crack it. It must be in some standard git
gzip format. There should be a command line tool to crack it with
provided in the git suite.
Anyways, one day some forensics department will need to crack one of
these things, and I want the instructions available.
JS> Just for the record: this is in so many ways not a commit message I want
JS> to have in git.git. I hope it is not applied.
Is that where they end up? Oops, please reword it for me, anybody.
^ permalink raw reply
* Re: [RFC PATCH] builtin-apply: prevent non-explicit permission changes
From: Alexander Potashev @ 2009-01-01 22:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfxk3npuc.fsf@gitster.siamese.dyndns.org>
On 05:00 Thu 01 Jan , Junio C Hamano wrote:
> Alexander Potashev <aspotashev@gmail.com> writes:
>
> > builtin-apply.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/builtin-apply.c b/builtin-apply.c
> > index 07244b0..071f6d8 100644
> > --- a/builtin-apply.c
> > +++ b/builtin-apply.c
> > @@ -630,7 +630,7 @@ static int gitdiff_index(const char *line, struct patch *patch)
> > memcpy(patch->new_sha1_prefix, line, len);
> > patch->new_sha1_prefix[len] = 0;
> > if (*ptr == ' ')
> > - patch->new_mode = patch->old_mode = strtoul(ptr+1, NULL, 8);
> > + patch->old_mode = strtoul(ptr+1, NULL, 8);
> > return 0;
> > }
> >
> > @@ -2447,6 +2447,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
> > if (st_mode != patch->old_mode)
> > fprintf(stderr, "warning: %s has type %o, expected %o\n",
> > old_name, st_mode, patch->old_mode);
> > + patch->new_mode = st_mode;
>
> Can you do this unconditionally, overwriting whatever we read from the
> patch header metainfo lines?
Do you mean overwriting of 'patch->new_mode' right after patch parsing?
If so, there would be yet another call to 'stat' to get the permissions
of the existing file (that is not very good).
I'm not very familiar with Git sources.
Also, I don't understand what are the permissions in 'index ...' lines
for (e.g. "index fc3c3a4..066a4ac 100644"), my patch simply drops them:
> > - patch->new_mode = patch->old_mode = strtoul(ptr+1, NULL, 8);
> > + patch->old_mode = strtoul(ptr+1, NULL, 8);
...not completely drops, probably we should cross out this line
completely (I don't know whether it breaks something).
Alexander
^ permalink raw reply
* Re: [PATCH v3] Add a commit.signoff configuration option to always use --signoff in commit
From: Adeodato Simó @ 2009-01-01 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4p0l1ik2.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano [Tue, 30 Dec 2008 13:04:13 -0800]:
> They actually started making me think
> that commmit.signoff might be more trouble than it is worth.
I am beginning to think the same myself, and I'm okay with letting go.
If somebody has a sensible plan, I can invest some time on implementing
it, but I'll reckon it all tastes too messy at the moment.
Thanks for your time.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Vanessa-Mae - Leyenda
^ permalink raw reply
* [PATCH] use || instead of | in logical expressions
From: Alexander Potashev @ 2009-01-01 22:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Bit OR ('|') is probably faster and it always works correctly (but '&'
doesn't!), but it looks horrible here.
Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 07244b0..c71afa1 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2487,7 +2487,7 @@ static int check_patch(struct patch *patch)
ok_if_exists = 0;
if (new_name &&
- ((0 < patch->is_new) | (0 < patch->is_rename) | patch->is_copy)) {
+ (0 < patch->is_new || 0 < patch->is_rename || patch->is_copy)) {
if (check_index &&
cache_name_pos(new_name, strlen(new_name)) >= 0 &&
!ok_if_exists)
--
1.6.0.6
^ permalink raw reply related
* Re: gitweb $export_ok question
From: Jakub Narebski @ 2009-01-01 22:51 UTC (permalink / raw)
To: Thomas Amsler; +Cc: git@vger.kernel.org
In-Reply-To: <6db6bed70812311027g3be1cfbei35c014243237fd59@mail.gmail.com>
Two requests: could you please do not toppost, as it goes against
natural flow of discussion and reading, but rather quote relevant
parts and respond below? It would be good to not try to send HTML
mail, as it is forbidden by VGER anti-SPAM filter, so you trying
to send HTML-formatted email result in me getting two copies: one
with and one without HTML version.
On Wed, 31 Dec 2008, Thomas Amsler wrote:
> One more question. Now, on the gitweb home page, the project name hyper link
> shows up as:
>
> authz.git/.git
>
> where it used to be just:
>
> authz.git/
>
> is there a way to configure this so that it doesn't show the trailing .git?
I'm afraid it is not possible without modifying gitweb, unless you use
symlinks in place of real repositories, i.e. if you have authz.git in
$projectroot being symlink to authz.git/.git or even authz/.git (which
might be somewhere else).
For example I have /home/local/scm/git.git be symlink to ~/git/.git
The longer explanation (which probably should made into gitweb/README
or gitweb/INSTALL) is that gitweb is meant to deal with _bare_
repositories; gitweb doesn't touch and doesn't examine working area
of "live" (non-bare) repository. If you host git repositories (like
kernel.org, freedesktop.org or repo.or.cz) you usually host them bare
(public repositories should be bare); but you might want to have
gitweb for your own repository too.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] use || instead of | in logical expressions
From: Alexander Potashev @ 2009-01-01 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <20090101223953.GA16680@myhost>
On 01:39 Fri 02 Jan , Alexander Potashev wrote:
> Bit OR ('|') is probably faster and it always works correctly (but '&'
> doesn't!), but it looks horrible here.
Sorry, I was wrong: '&' would work as well (for example in expression
'(a < 1) & (b == 5)') because logical operators can return only 0 or 1.
>
> Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
> ---
> builtin-apply.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 07244b0..c71afa1 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -2487,7 +2487,7 @@ static int check_patch(struct patch *patch)
> ok_if_exists = 0;
>
> if (new_name &&
> - ((0 < patch->is_new) | (0 < patch->is_rename) | patch->is_copy)) {
> + (0 < patch->is_new || 0 < patch->is_rename || patch->is_copy)) {
> if (check_index &&
> cache_name_pos(new_name, strlen(new_name)) >= 0 &&
> !ok_if_exists)
> --
> 1.6.0.6
>
^ permalink raw reply
* git ls-tree prints wacko file sizes if it can't find the blob
From: jidanni @ 2009-01-01 23:18 UTC (permalink / raw)
To: git
In-Reply-To: <20090101192153.GA6536@coredump.intra.peff.net>
git ls-tree prints wacko file sizes if it can't find the blob:
$ git ls-tree --abbrev=4 -l 76e4
error: unable to find ae832f2245892ddde5221357466448b409775142
100644 blob ae83 3220821896 words
It is even affected by --abbrev:
$ for i in 4 5 40 999; do git ls-tree --abbrev=$i -l 76e4; done 2>&-|
perl -nwale 'print $F[3]'
3214344536
3219092952
3216251688
3217198088
$ git version
git version 1.6.0.6
^ permalink raw reply
* Re: [PATCH] doc/git-send-email: mention sendemail.cc config variable
From: Markus Heidelberg @ 2009-01-01 23:40 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
In-Reply-To: <200812291400.08924.trast@student.ethz.ch>
Thomas Rast, 29.12.2008:
> Markus Heidelberg wrote:
> > Specify a starting "Cc:" value for each email.
> > + Default is the value of 'sendemail.cc'.
> > +
> > The --cc option must be repeated for each user you want on the cc list.
>
> Judging from the source, this is not a default value that you can
> override: any recipients listed in sendemail.cc configuration(s) are
> always added to the Cc list. The same goes for --bcc and
> sendemail.bcc however, which uses the exact same formulation.
I just tested it with --dry-run: the command line options for all three
header lines (to cc bcc) override the corresponding config settings. So
the formulation is correct: the settings are only default values.
Markus
^ permalink raw reply
* Re: git ls-tree prints wacko file sizes if it can't find the blob
From: jidanni @ 2009-01-01 23:47 UTC (permalink / raw)
To: git
In-Reply-To: <87eizmty25.fsf_-_@jidanni.org>
> It is even affected by --abbrev:
It's not. It is just randomly grabbing digits even without --abbrev.
^ permalink raw reply
* Re: [PATCH] Documentation/git-bundle.txt: Dumping contents of any bundle
From: Jeff King @ 2009-01-01 23:48 UTC (permalink / raw)
To: jidanni; +Cc: Johannes.Schindelin, nico, gitster, mdl123, spearce, git
In-Reply-To: <87fxk2u13r.fsf@jidanni.org>
On Fri, Jan 02, 2009 at 06:12:56AM +0800, jidanni@jidanni.org wrote:
> I got as far as these wheezy little bytes,
> $ ls ??/*|tr -d /|sed q|xargs git cat-file tree|perl -pwe 's/[^\0]+[\0]//'|hd
> 00000000 ae 83 2f 22 45 89 2d dd e5 22 13 57 46 64 48 b4 |../"E.-..".WFdH.|
> 00000010 09 77 51 42 |.wQB|
Those are just the bytes of the sha1 of the blob object, which is
pointed to by the tree object. You have the tree object correctly
unpacked, but not the blob, as I said before. So no amount of looking
in .git/objects is going to help you: git-unpack-objects didn't unpack
it, and the data isn't there in any form.
The data is in the pack, but as a delta, and that delta has further been
gzipped. So you can either write a custom parser based on the pack
format (which, as I mentioned, is described in
Documentation/technical/pack-format.txt), or you can add a switch to
unpack-objects, which is already parsing that format, to dump the
unresolved deltas. Which is what I was suggesting before.
Here's a very rough patch to do the latter. Try:
git unpack-objects --dump-delta <mybundle.pack
strings .git/lost-found/delta/*
Probably one could also write some tool to decode the delta format into
something more human readable.
---
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 47ed610..ab33ab1 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -13,6 +13,7 @@
#include "fsck.h"
static int dry_run, quiet, recover, has_errors, strict;
+static int dump_deltas;
static const char unpack_usage[] = "git unpack-objects [-n] [-q] [-r] [--strict] < pack-file";
/* We always read in 4kB chunks. */
@@ -462,6 +463,36 @@ static void unpack_one(unsigned nr)
}
}
+static void dump_delta_list(void)
+{
+ struct delta_info *d;
+
+ for (d = delta_list; d; d = d->next) {
+ git_SHA_CTX c;
+ unsigned char sha1[20];
+ char *path;
+ int fd;
+
+ git_SHA1_Init(&c);
+ git_SHA1_Update(&c, d->delta, d->size);
+ git_SHA1_Final(sha1, &c);
+ path = git_path("lost-found/delta/%s", sha1_to_hex(sha1));
+
+ if (safe_create_leading_directories(path) < 0)
+ die("could not create lost-found directory");
+
+ fd = open(path, O_CREAT|O_WRONLY, 0666);
+ if (fd < 0)
+ die("unable to open %s: %s", path, strerror(errno));
+ if (write_in_full(fd, d->delta, d->size) < 0)
+ die("error writing to %s: %s", path, strerror(errno));
+ if (close(fd) < 0)
+ die("error writing to %s: %s", path, strerror(errno));
+
+ fprintf(stderr, "dumped delta %s\n", sha1_to_hex(sha1));
+ }
+}
+
static void unpack_all(void)
{
int i;
@@ -486,8 +517,11 @@ static void unpack_all(void)
}
stop_progress(&progress);
- if (delta_list)
+ if (delta_list) {
+ if (dump_deltas)
+ dump_delta_list();
die("unresolved deltas left after unpacking");
+ }
}
int cmd_unpack_objects(int argc, const char **argv, const char *prefix)
@@ -534,6 +568,10 @@ int cmd_unpack_objects(int argc, const char **argv, const char *prefix)
len = sizeof(*hdr);
continue;
}
+ if (!strcmp(arg, "--dump-deltas")) {
+ dump_deltas = 1;
+ continue;
+ }
usage(unpack_usage);
}
^ permalink raw reply related
* [PATCH] Handle sha1_object_info failures in ls-tree -l
From: Alex Riesen @ 2009-01-01 23:52 UTC (permalink / raw)
To: jidanni; +Cc: git, Junio C Hamano
In-Reply-To: <87eizmty25.fsf_-_@jidanni.org>
Printing 0 as the size of the blob seem to be the safest. The error
message is already printed by sha1_object_info itself.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
jidanni@jidanni.org, Fri, Jan 02, 2009 00:18:42 +0100:
> git ls-tree prints wacko file sizes if it can't find the blob:
> $ git ls-tree --abbrev=4 -l 76e4
> error: unable to find ae832f2245892ddde5221357466448b409775142
> 100644 blob ae83 3220821896 words
Not tested, but should print size of 0 if this happens.
I actually would prefer ls-tree finish listing and exit(1) in this case,
but ... am a little lazy (or scared of a "static int exit_code;").
builtin-ls-tree.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index cb61717..234df50 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -96,7 +96,8 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
if (!(ls_options & LS_NAME_ONLY)) {
if (ls_options & LS_SHOW_SIZE) {
if (!strcmp(type, blob_type)) {
- sha1_object_info(sha1, &size);
+ if (sha1_object_info(sha1, &size))
+ size = 0;
printf("%06o %s %s %7lu\t", mode, type,
abbrev ? find_unique_abbrev(sha1, abbrev)
: sha1_to_hex(sha1),
--
1.6.1.73.g7450
^ permalink raw reply related
* Re: [PATCH] gitweb: Handle actions with no project in evaluate_path_info
From: Jakub Narebski @ 2009-01-01 23:58 UTC (permalink / raw)
To: Devin Doucette; +Cc: git, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <a899d7ef0812272326j1a407c30k936bf8d8975c9063@mail.gmail.com>
On Sun, 28 Dec 2008, Devin Doucette wrote:
> The action would not be set if no valid project was found in
> path_info. Removing the return if the project was not specified fixes
> the project_index and opml actions when using path_info.
>
Thanks for catching this.
Truth to be told we parse action parameter in path_info only since
d8c2882 (gitweb: parse project/action/hash_base:filename PATH_INFO)
by Giuseppe Bilotta (CC-ed; I think he is correct person to give
Ack for this patch). Earlier only "default" actions could be expressed
using only path_info, and project-less 'opml' and 'project_index'
actions are not default actions for projectless URL, so there was no
such problem then.
> Signed-off-by: Devin Doucette <devin@doucette.cc>
> ---
> gitweb/gitweb.perl | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 8f574c7..b6a8ea9 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -552,8 +552,7 @@ sub evaluate_path_info {
> while ($project && !check_head_link("$projectroot/$project")) {
> $project =~ s,/*[^/]*$,,;
> }
> - return unless $project;
> - $input_params{'project'} = $project;
> + $input_params{'project'} = $project if $project;
>
> # do not change any parameters if an action is given using the query string
> return if $input_params{'action'};
> --
> 1.6.1.rc4
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-difftool
From: Markus Heidelberg @ 2009-01-02 0:04 UTC (permalink / raw)
To: Ping Yin; +Cc: Matthieu Moy, David Aguilar, git
In-Reply-To: <46dff0320812312338i5a3ee0cem702a6b67ef76e48c@mail.gmail.com>
Ping Yin, 01.01.2009:
> On Thu, Jan 1, 2009 at 12:04 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> > David Aguilar <davvid@gmail.com> writes:
> >
> >> The usual use case for this script is when you have either
> >> staged or unstaged changes and you'd like to see the changes
> >> in a side-by-side diff viewer (e.g. xxdiff, tkdiff, etc).
> >>
> >> git difftool [<filename>*]
> >
> > Is it not a complex way of saying
> >
> > GIT_EXTERNAL_DIFF=xxdiff git diff
>
> $ cat mydiff
> #!/bin/bash
> exec vimdiff $2 $5
>
> then i run
>
> $ GIT_EXTERNAL_DIFF=mydiff git diff
>
> but it gives me the error
> Vim: Warning: Output is not to a terminal
Just the warning and everything else works? For me the display is
totally screwed up and the commands don't really work because of the
pager. I have to add GIT_PAGER="" to get it working.
Markus
^ permalink raw reply
* Re: [PATCH] Documentation/git-bundle.txt: Dumping contents of any bundle
From: jidanni @ 2009-01-02 0:10 UTC (permalink / raw)
To: peff; +Cc: johannes.schindelin, nico, gitster, mdl123, spearce, git
In-Reply-To: <20090101234815.GA9049@coredump.intra.peff.net>
JK> diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
OK, I wish you luck in the fruition of the new --dump-delta option, and
can proofread the man pages involved, otherwise this is no area for
junior programmer me.
^ permalink raw reply
* Re: git-difftool
From: Markus Heidelberg @ 2009-01-02 0:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: David Aguilar, git
In-Reply-To: <vpq8wpux61c.fsf@bauges.imag.fr>
Matthieu Moy, 01.01.2009:
> "David Aguilar" <davvid@gmail.com> writes:
>
> > Hmm... in theory, yes, but in practice, no.
> > xxdiff is too gimp to handle what 'git diff' hands it =)
>
> As done with "vimdiff" in another message, simply write a one-liner
> wrapper script that calls xxdiff $2 $3, and call this wrapper script.
This works with GUI tools, but not with console tools. GVim works, Vim
doesn't.
And invoking
git difftool
is by far more convenient than
GIT_EXTERNAL_DIFF=vimdiff git diff
Markus
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge: at least one <remote> not two
From: Sitaram Chamarty @ 2009-01-02 0:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vk59ehg7l.fsf@gitster.siamese.dyndns.org>
On 2009-01-01, Junio C Hamano <gitster@pobox.com> wrote:
> * Is it a good idea to standardize on "one or more" semantics? I suspect
> we would rather want to standardize on "zero or more", because it would
> be more natural to say:
>
> $ git diff [--] <paths>...
>
> to mean "You can give paths if you want to but you do not have to". If
> ellipses meant "one or more", you have to say this instead:
>
> $ git diff [--] [<paths>...]
For what it is worth, I have always understood "..." to mean
"more of the preceding", meaning "one or more". That is
your first example above.
Zero or more is your second syntax above, because the whole
thing is in brackets, and hence completely optional.
In regex terms (to me anyway):
a? == [a]
a+ == a...
a* == [a...]
^ permalink raw reply
* Re: [PATCH] doc/git-send-email: mention sendemail.cc config variable
From: Thomas Rast @ 2009-01-02 0:43 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git, gitster
In-Reply-To: <200901020040.41399.markus.heidelberg@web.de>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Markus Heidelberg wrote:
> I just tested it with --dry-run: the command line options for all three
> header lines (to cc bcc) override the corresponding config settings. So
> the formulation is correct: the settings are only default values.
Indeed, you're right. Apologies for the false alarm.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: Handle actions with no project in evaluate_path_info
From: Giuseppe Bilotta @ 2009-01-02 0:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Devin Doucette, git, Petr Baudis
In-Reply-To: <200901020058.30748.jnareb@gmail.com>
On Fri, Jan 2, 2009 at 12:58 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Truth to be told we parse action parameter in path_info only since
> d8c2882 (gitweb: parse project/action/hash_base:filename PATH_INFO)
> by Giuseppe Bilotta (CC-ed; I think he is correct person to give
> Ack for this patch). Earlier only "default" actions could be expressed
> using only path_info, and project-less 'opml' and 'project_index'
> actions are not default actions for projectless URL, so there was no
> such problem then.
Actually, the early bailout was sort of intentional. The problem is
the ambiguity: does git.example.com/opml refer to the opml project, or
does it refer to the opml action?
HOWEVER, href() *does* create the opml action as git.example.com/opml,
so gitweb is currently broken in the sense that ti doesn't correctly
parse its own pathinfo output. So the question is: shall we go with
this patch, preventing pathinfo from working for projects named like a
no-project gitweb action, or should we fix href() to not generate
pathinfo unless project is defined?
>> - return unless $project;
>> - $input_params{'project'} = $project;
>> + $input_params{'project'} = $project if $project;
Note that if this patch is accepted, we probably need an appropriate
patch in href() anyway to use query params for projects named like
no-project actions.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC PATCH] builtin-apply: prevent non-explicit permission changes
From: Junio C Hamano @ 2009-01-02 0:56 UTC (permalink / raw)
To: Alexander Potashev; +Cc: Git Mailing List
In-Reply-To: <20090101221720.GA5603@myhost>
Alexander Potashev <aspotashev@gmail.com> writes:
> On 05:00 Thu 01 Jan , Junio C Hamano wrote:
>> Alexander Potashev <aspotashev@gmail.com> writes:
> ...
>> > @@ -2447,6 +2447,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
>> > if (st_mode != patch->old_mode)
>> > fprintf(stderr, "warning: %s has type %o, expected %o\n",
>> > old_name, st_mode, patch->old_mode);
>> > + patch->new_mode = st_mode;
>>
>> Can you do this unconditionally, overwriting whatever we read from the
>> patch header metainfo lines?
>
> Do you mean overwriting of 'patch->new_mode' right after patch parsing?
My question was if we should assign st_mode to new_mode _unconditionally_
here, even when patch->new_mode has already been read from the explicit
mode change line (i.e. "new mode ", line not "index "line) of the patch
input.
The call-chain of the program looks like this:
-> apply_patch()
-> parse_chunk()
-> find_header()
* initialize new_mode and old_mode to 0
-> parse_git_header()
* set new_mode and old_mode from the patch metainfo, i.e.
"new mode", "old mode" and "index" lines.
-> parse_single_patch()
-> check_patch_list()
-> check_patch()
-> check_preimage()
* make sure there is no local mods
* warn if old_mode read from the patch (i.e. the preimage file
the patch submitter used to prepare the patch against) does not
match what we have
* warn about mode inconsistency (e.g. the patch submitter thinks
the mode should be 0644 but our tree has 0755).
-> apply_data()
-> write_out_results()
-> write_out_one_result(0)
* delete old
-> write_out_one_result(1)
* create new
Currently the mode 100644 on the "index" line in a patch is handled
exactly in the same way as having "old mode 100644" and "new mode 100644"
lines in the metainfo. The patch submitter claims to have started from
100644 and he claims that he wants to have 100644 as the result. That is
why there is a warning in check_patch().
If we stop reading the new mode from the "index" line (but we still read
"old_mode" there) without any other change you made in your patch, what
breaks (i.e. without the patch->new_mode assignment hunk)? I haven't
followed the codepath too closely, and I suspect you found some cases
where new_mode stays 0 as initialized, and that may be the reason you have
this assignment.
But the assignment being unconditional bothered me a lot.
I tend to agree that the current "The final mode bits I want to have on
this path is this" semantics we give to the "index" line is much less
useful and less sane and it is a good idea to redefine it as "FYI, the
copy I made this patch against had this mode bits. I do not intend to
change the mode bits of the path with this patch."
builtin-apply.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git c/builtin-apply.c w/builtin-apply.c
index 07244b0..a8f75ed 100644
--- c/builtin-apply.c
+++ w/builtin-apply.c
@@ -630,7 +630,7 @@ static int gitdiff_index(const char *line, struct patch *patch)
memcpy(patch->new_sha1_prefix, line, len);
patch->new_sha1_prefix[len] = 0;
if (*ptr == ' ')
- patch->new_mode = patch->old_mode = strtoul(ptr+1, NULL, 8);
+ patch->old_mode = strtoul(ptr+1, NULL, 8);
return 0;
}
@@ -2447,6 +2447,8 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
if (st_mode != patch->old_mode)
fprintf(stderr, "warning: %s has type %o, expected %o\n",
old_name, st_mode, patch->old_mode);
+ if (!patch->new_mode)
+ patch->new_mode = st_mode;
return 0;
is_new:
^ permalink raw reply related
* Re: [PATCH] Pass --upload-pack and --receive-pack through submodules.
From: Jason Riedy @ 2009-01-02 1:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6xuhhbx.fsf@gitster.siamese.dyndns.org>
And Junio C. Hamano writes:
> Do we (and can we) assume that the remote repositories submodules fetch
> from all reside on the same host and can share the same values for these
> parameters? Shouldn't these instead be specified in the configuration
> files for the submodules, if they need to be nonstandard values?
git does not and (for me) should not make the assumption above.
I'm fetching different pieces from different administrative
domains where I also have push access. While I could clone them
all into one place, that adds another level of repositories I'd
have to keep up-to-date.
Essentially, I'm collecting experimental libraries and drivers
into one build tree. My intent is to record exactly what is
being built on multiple machines while being able to push local
build configurations back to my central superproject. Then I can
make a version with pull-only remote URLs[1] for others to
duplicate the setup for my experiments.
I suppose I could clone the submodules by hand and then use git
submodule add. But then I'll have to build the structure by hand
(with my own wrapper) everywhere I use the supermodule. At that
point, using git submodule becomes a tad silly. Or I could set
up the superproject with pull-only URLs and modify the
configurations with a separate wrapper. Seemed like adding the
two options to git submodule was easier.
Jason
Footnotes:
[1] Or ask for separate pull- and push-urls in git remote. But
I haven't thought that through.
^ 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