* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812291845.20500.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
> index 74d14c4..556ea23 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>]
Shouldn't this be [<upstream> [<head> [<limit>]]]?
^ permalink raw reply
* Re: [PATCH] Document git-ls-tree --full-tree
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Markus Heidelberg
In-Reply-To: <20081231190050.6117@nanako3.lavabit.com>
Thanks.
^ permalink raw reply
* Re: [PATCH,RESEND] objects to be pruned immediately don't have to be loosened
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0812301441540.30266@xanadu.home>
Thanks. I take this as a usability fix for large repository?
^ permalink raw reply
* Re: [PATCH] Documentation/gitcli.txt: dashed forms not allowed anymore
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: jidanni, git
In-Reply-To: <20090101144045.GC21154@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Jan 01, 2009 at 12:39:39PM +0800, jidanni@jidanni.org wrote:
>> - * it's preferred to use the non dashed form of git commands, which means that
>> - you should prefer `"git foo"` to `"git-foo"`.
>> + * it's required to use the non dashed form of git commands, which means that
>> + you must use `"git foo"` and not `"git-foo"`. The latter no longer works.
>
> I would append: "unless you add the output of `git --exec-path` to your
> PATH."
I actually wouldn't.
There needs to be a description about use of PATH=$(git --exec-path):$PATH
if you choose to use the dashed forms in your script. Don't we already
have that elsewhere more basic in the documentation set?
The quoted part of the documentation talks about the syntax and convention
used while scripting, and what it wants to say with the sentence is that
the dashless form is preferred, even with PATH=$(git --exec-path):$PATH
(iow, it was preferred before 1.6.0, and it still is preferred with the
$PATH adjustments after 1.6.0).
I think it muddies the point of the list if you talk about the necessity
of $PATH adjustment, which is a irrelevant detail.
^ permalink raw reply
* Re: [PATCH v2 1/3] rebase: learn to rebase root commit
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <7b2902d36a4790670f20f786d4ea2e26052a6e71.1230639970.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Teach git-rebase a new option --root, which instructs it to rebase the
> entire history leading up to <branch>.
>
> The main use-case is with git-svn: suppose you start hacking (perhaps
> offline) on a new project, but later notice you want to commit this
> work to SVN. You will have to rebase the entire history, including
> the root commit, on a (possibly empty) commit coming from git-svn, to
> establish a history connection. This previously had to be done by
> cherry-picking the root commit manually.
I like what this series tries to do. Using the --root option is probably
a more natural way to do what people often do with the "add graft and
filter-branch the whole history once" procedure.
But it somewhat feels sad if the "main" use-case for this is to start your
project in git and then migrate away by feeding your history to subversion
;-).
> @@ -344,17 +348,23 @@ case "$diff" in
> ;;
> esac
>
> +if test -z "$rebase_root"; then
> # The upstream head must be given. Make sure it is valid.
> -upstream_name="$1"
> -upstream=`git rev-parse --verify "${upstream_name}^0"` ||
> - die "invalid upstream $upstream_name"
> + upstream_name="$1"
> + shift
> + upstream=`git rev-parse --verify "${upstream_name}^0"` ||
> + die "invalid upstream $upstream_name"
> +fi
> +
> +test ! -z "$rebase_root" -a -z "$newbase" &&
> + die "--root must be used with --onto"
This is much easier to read if it were:
if test -z "$rebase_root"
then
... do the upstream_name/upstream thing, such as
upstream_name="$1"
...
else
... do the rebase_root thing, including
unset upstream
unset upstream_name
test -z "$newbase" && die "--root without --onto"
...
fi
(Mental note. You shifted positional parameters and the remainders need
to be adjusted, which you seem to have done).
> # Make sure the branch to rebase onto is valid.
> onto_name=${newbase-"$upstream_name"}
> onto=$(git rev-parse --verify "${onto_name}^0") || exit
>
> # If a hook exists, give it a chance to interrupt
> -run_pre_rebase_hook ${1+"$@"}
> +run_pre_rebase_hook ${upstream_name+"$upstream_name"} "$@"
I do not think ${upstream_name+"$upstream_name"} is a good check to begin
with, because presense of it does not necessarily mean the command was
invoked without --root; it could have come from the environment of the
invoker (hence the suggestion to unset the variable explicitly).
And I do not think this is a good way to extend the calling convention of
the hook, either. pre-rebase-hook used to always take upstream and
optionally the explicit branch name. When --root is given, your code will
give the hook a single parameter which is the explicit branch name
(i.e. "we will switch to this branch and rebase it, are you Ok with it?"),
but the hook will mistakenly think you are feeding the fork-point commit.
Because an old pre-rebase-hook cannot verify --root case correctly anyway
and needs to be updated, how about doing 'run_pre_rebase_hook --root "$@"'
when --root was given?
> @@ -393,7 +403,8 @@ case "$#" in
> esac
> orig_head=$branch
>
> -# Now we are rebasing commits $upstream..$branch on top of $onto
> +# Now we are rebasing commits $upstream..$branch (or simply $branch
> +# with --root) on top of $onto
"or simply everything leading to $branch if --root is given"?
> # Check if we are already based on $onto with linear history,
> # but this should be done only when upstream and onto are the same.
> @@ -429,10 +440,18 @@ then
> exit 0
> fi
>
> +if test ! -z "$rebase_root"; then
> + revisions="$orig_head"
> + fp_flag="--root"
> +else
> + revisions="$upstream..$orig_head"
> + fp_flag="--ignore-if-in-upstream"
> +fi
Hmph, the reason why --ignore-if-in-upstream is irrelevant when --root is
given is because...?
> diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
> new file mode 100755
> index 0000000..63ec5e6
> --- /dev/null
> +++ b/t/t3412-rebase-root.sh
> @@ -0,0 +1,52 @@
> +#!/bin/sh
> +
> +test_description='git rebase --root
> ...
> +test_done
Including tests for the pre-rebase-hook would be nice.
^ permalink raw reply
* Re: [PATCH] Pass --upload-pack and --receive-pack through submodules.
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <1230649782-14710-1-git-send-email-jason@acm.org>
Jason Riedy <jason@acm.org> writes:
> While I no longer have to worry about a zillion ancient OS versions,
> I now have to worry about a remote site where I cannot control the
> path for non-interactive shells. Thus, submodules need to handle
> explicitly specified git-upload-pack and git-receive-pack programs.
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?
^ permalink raw reply
* Re: Subject: [PATCH] Documentation/git-merge: deprecated syntax moved to end
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87bpuqvpfz.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Moving the deprecated syntax moved to the end of the document.
> Or please at least stamp it *deprecated* in the SYNOPSIS, in case the
> user reads no further down the page.
To my mind, there is a difference between something being kept (and will
be kept for foreseeable future), and something being deprecated (and
eventual removal is at least contemplated). The original merge syntax
falls into the first category, and the current description is correct and
fine as-is.
The wording "for historical reasons" does not refer to the reason why the
second syntax is still kept. It merely refers to the reason why two
syntaxes exist in the first place.
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge: at least one <remote> not two
From: Junio C Hamano @ 2009-01-01 21:25 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87d4f6vph7.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Make SYNOPSIS match usage message
>
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
> Documentation/git-merge.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index f7be584..a3ac828 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -10,7 +10,7 @@ SYNOPSIS
> --------
> [verse]
> 'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
> - [-m <msg>] <remote> <remote>...
> + [-m <msg>] <remote>...
> 'git merge' <msg> HEAD <remote>...
The original uses ellipses for the first-class UI syntax as "zero or
more", while it means "one or more" in the description for the original
syntax, which is inconsistent, and you are matching them by making both
use "one or more" interpretation.
Two issues:
* Are there similar breakages like this in the documentation and the
usage text? It would be a good idea to make the ellipses to mean the
same thing everywhere, and a janitorial patch series that would fix
the "ellipses" breakage (and nothing else) may be a good thing to
have. But before going that route...
* 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>...]
While I prefer "zero or more" because I think it is more logical, if the
preparatory study for the first issue reveals that we use "one or more" a
lot more often, it might be easier to standardize on that interpretation.
Oh, you also need to give ellipses to the usage string for the original
syntax in builtin-merge.c to match SYNOPSIS and usage string.
Thanks.
^ permalink raw reply
* [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
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