* Re: [PATCH 1/3] add alloc_ref_with_prefix()
From: Andreas Ericsson @ 2008-10-20 10:34 UTC (permalink / raw)
To: Bert Wesarg; +Cc: René Scharfe, Git Mailing List, Junio C Hamano
In-Reply-To: <36ca99e90810180507q2dedf4ck7262239ae91d892f@mail.gmail.com>
Bert Wesarg wrote:
> On Sat, Oct 18, 2008 at 11:39, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>>> +static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
>>>> + const char *name)
>>>> +{
>>>> + size_t len = strlen(name);
>>>> + struct ref *ref = xcalloc(1, sizeof(struct ref) + prefixlen + len + 1);
>>>> + memcpy(ref->name, prefix, prefixlen);
>>>> + memcpy(ref->name + prefixlen, name, len);
>>> Where does you \0-terminate the string?
>> xcalloc() calls calloc(), which zeroes the memory.
> So, you write the memory range twice, just for the last \0?
>
calloc() doesn't do the zeroing pass if it gets memory from the kernel,
which guarantees that the memory is already zeroed out. In reality,
calloc() usually saves on both readability and performance over
explicitly nul-terminating strings.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Andreas Ericsson @ 2008-10-20 10:36 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Junio C Hamano, git
In-Reply-To: <ee2a733e0810180459m5fd20365s3c27bea5c1f3f704@mail.gmail.com>
Leo Razoumov wrote:
> When source git repository has extension ".git" like in "MyRepo.git"
> "git fetch" will drop ".git" extension and refer to it as "MyRepo".
>
> Example:
>
> sh$ git fetch -v ../MyRepo.git master
> From ../MyRepo
> * branch master -> FETCH_HEAD
>
> sh$ cat .git/FETCH_HEAD
> 6eb10bd105f2ef7f64c595100c0a850c5b3cfeb9 branch 'master' of ../MyRepo
>
> Please, note that "git fetch" writes "../MyRepo" instead of "../MyRepo.git"
>
> My workflow makes it convenient to have two distinct repositories
> (1) "MyRepo" => where I work daily (WIP)
> (2) "MyRepo.git" => --bare repository accessible to others. "MyRepo"
> pushes ready changes to "MyRepo.git"
> Dropping ".git" extension causes confusion between these two quite
> similarly named repositories.
>
> This problem can be easily solved by the patch below that removes the
> code that strips off ".git" extension.
>
> --Leo--
>
> ----8<-------------------
>
> builtin-fetch--tool.c | 2 --
> builtin-fetch.c | 2 --
> 2 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
> index 7460ab7..5d0b95f 100644
> --- a/builtin-fetch--tool.c
> +++ b/builtin-fetch--tool.c
> @@ -160,8 +160,6 @@ static int append_fetch_head(FILE *fp,
> for (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)
> ;
> remote_len = i + 1;
> - if (4 < i && !strncmp(".git", remote + i - 3, 4))
> - remote_len = i - 3;
>
> note_len = 0;
> if (*what) {
> diff --git a/builtin-fetch.c b/builtin-fetch.c
> index ee93d3a..28123a5 100644
> --- a/builtin-fetch.c
> +++ b/builtin-fetch.c
> @@ -348,8 +348,6 @@ static int store_updated_refs(const char *url,
> const char *remote_name,
> for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)
> ;
> url_len = i + 1;
> - if (4 < i && !strncmp(".git", url + i - 3, 4))
> - url_len = i - 3;
>
Will this still play nicely with
git clone foo.git
?
Otherwise, please also fix the fallout from this patch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCHv6 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Jakub Narebski @ 2008-10-20 9:18 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-5-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> This patch makes it possible to use an URL such as
> $project/somebranch..otherbranch:/filename to get a diff between
> different version of a file. Paths like
> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
> as well.
Just a nitpick: why '$project' and '$action', but 'somebranch',
'otherbranch' and 'filename'?
>
> All '*diff' actions and in general actions that use $hash_parent[_base]
> and $file_parent can now get all of their parameters from PATH_INFO
Which currently mean 'shortlog', and I guess in the future would mean
also all other log-like views: 'log', 'history', 'search' (the commit
message kind, not the pickaxe kind), and perhaps also 'rss'/'atom'.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
For what is worth:
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 36 ++++++++++++++++++++++++++++++++++--
> 1 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 49730f3..1a7b0b9 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -548,7 +548,12 @@ sub evaluate_path_info {
> 'history',
> );
>
> - my ($refname, $pathname) = split(/:/, $path_info, 2);
> + # horrible regexp to catch
> + # [$hash_parent_base[:$file_parent]..]$hash_parent[:$file_name]
This comment is really nice here, to explain what we try to catch.
Is it really "horrible"... let others decide.
Note: this (as also previous code) makes use of the fact that refname
cannot contain ':' as per git-check-ref-format(1), and the fact that
gitweb limits $hash* parameters to simple revision syntax, allowing
only SHA1 and refnames, and not allowing (see validate_refname() used
in $hash* validation) extended SHA1 syntax like <commit-ish>:<path>
for $hash ('h') param for 'blob' view: gitweb uses $hash_base and
$file_name for that.
(But I guess it is too long explanation to put it in comment)
Side note: the regexp below allow for $parentpathname to contain
'..', but we don't want to rely on such minute detail of implementation
detail (because it depends on whether we use greedy or non-greedy
matching there).
> + my ($parentrefname, $parentpathname, $refname, $pathname) =
> + ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
> +
> + # first, analyze the 'current' part
> if (defined $pathname) {
> # we got "branch:filename" or "branch:dir/"
> # we could use git_get_type(branch:pathname), but it needs $git_dir
> @@ -557,7 +562,13 @@ sub evaluate_path_info {
> $input_params{'action'} ||= "tree";
> $pathname =~ s,/$,,;
> } else {
> - $input_params{'action'} ||= "blob_plain";
> + # the default action depends on whether we had parent info
> + # or not
> + if ($parentrefname) {
> + $input_params{'action'} ||= "blobdiff_plain";
> + } else {
> + $input_params{'action'} ||= "blob_plain";
> + }
Nice.
I was wondering about 'project/hash_parent..hash' syntax, but then I have
realized that it doesn't change action (as in 'blob_plain' -> 'blobdiff_plain'),
but is always 'shortlog'.
By the way, I wonder if it should be 'blobdiff_plain' or just 'blobdiff'.
the 'blob_plain' was here to use gitweb as a kind of versioned web
server; there is no such equivalent for 'p/hbp..hb:f' syntax. On the
other hand it is consistent behavior, always using *_plain...
> }
> $input_params{'hash_base'} ||= $refname;
> $input_params{'file_name'} ||= $pathname;
> @@ -577,6 +588,27 @@ sub evaluate_path_info {
> $input_params{'hash'} ||= $refname;
> }
> }
> +
> + # next, handle the 'parent' part, if present
> + if (defined $parentrefname) {
> + # a missing pathspec defaults to the 'current' filename, allowing e.g.
> + # someproject/blobdiff/oldrev..newrev:/filename
> + if ($parentpathname) {
> + $parentpathname =~ s,^/+,,;
> + $parentpathname =~ s,/$,,;
Hmmm... should we strip trailing '/' here?
> + $input_params{'file_parent'} ||= $parentpathname;
> + } else {
> + $input_params{'file_parent'} ||= $input_params{'file_name'};
> + }
> + # we assume that hash_parent_base is wanted if a path was specified,
> + # or if the action wants hash_base instead of hash
Nice comment.
> + if (defined $input_params{'file_parent'} ||
> + grep {$input_params{'action'} eq $_} @wants_base) {
My preference of style would be to use here:
+ grep { $input_params{'action'} eq $_ } @wants_base) {
> + $input_params{'hash_parent_base'} ||= $parentrefname;
> + } else {
> + $input_params{'hash_parent'} ||= $parentrefname;
> + }
> + }
> }
> evaluate_path_info();
>
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv6 5/5] gitweb: generate parent..current URLs
From: Jakub Narebski @ 2008-10-20 10:49 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-6-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> If use_pathinfo is enabled, href now creates links that contain paths in
> the form $project/$action/oldhash:/oldname..newhash:/newname for actions
> that use hash_parent etc.
>
> If any of the filename contains two consecutive dots, it's kept as a CGI
> parameter since the resulting path would otherwise be ambiguous.
Note that this part is _required_ after previous patch, because
otherwise gitweb could generate path_info links which point to
different view than intended, when filename contains '..' in it,
like for example some test vectors in git test suite, for example
files in t/t5515
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
For what is worth:
Acked-by: Jakub Narebski <jnareb@gmail.com>
BTW. I wanted to test this using gitweb-Mechanize test from Lea Wiemann
GSoC 2008 work on gitweb caching, but I couldn't make it run as single
individual test (cd t && ./t9503-gitweb-Mechanize.sh); it requires to
run as "make test" and I didn't want that. I could have resurrected my
initial version of Test::WWW::Mechanize::CGI test...
> ---
> gitweb/gitweb.perl | 30 +++++++++++++++++++++++++-----
> 1 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 1a7b0b9..f4642e7 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -759,7 +759,8 @@ sub href (%) {
> # try to put as many parameters as possible in PATH_INFO:
> # - project name
> # - action
> - # - hash or hash_base:/filename
> + # - hash_parent or hash_parent_base:/file_parent
> + # - hash or hash_base:/file_name
Minor nit: this contain independent change 'filename' -> 'file_name',
but I think it is not worth separating...
>
> # When the script is the root DirectoryIndex for the domain,
> # $href here would be something like http://gitweb.example.com/
> @@ -778,17 +779,36 @@ sub href (%) {
> delete $params{'action'};
> }
>
> - # Finally, we put either hash_base:/file_name or hash
> + # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
> + # stripping nonexistent or useless pieces
> + $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
> + || $params{'hash_parent'} || $params{'hash'});
Nice trick (and required change).
> if (defined $params{'hash_base'}) {
> - $href .= "/".esc_url($params{'hash_base'});
> - if (defined $params{'file_name'}) {
> + if (defined $params{'hash_parent_base'}) {
> + $href .= esc_url($params{'hash_parent_base'});
> + # skip the file_parent if it's the same as the file_name
> + delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
> + if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
> + $href .= ":/".esc_url($params{'file_parent'});
> + delete $params{'file_parent'};
> + }
Side note: I wonder if we should use esc_url or esc_param here...
> + $href .= "..";
> + delete $params{'hash_parent'};
> + delete $params{'hash_parent_base'};
> + } elsif (defined $params{'hash_parent'}) {
> + $href .= esc_url($params{'hash_parent'}). "..";
> + delete $params{'hash_parent'};
> + }
> +
> + $href .= esc_url($params{'hash_base'});
> + if (defined $params{'file_name'} && $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'});
> + $href .= esc_url($params{'hash'});
> delete $params{'hash'};
> }
> }
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] rebase-i-p: only list commits that require rewriting in todo
From: Jeff King @ 2008-10-20 11:50 UTC (permalink / raw)
To: Stephen Haberman; +Cc: gitster, git
In-Reply-To: <0977b23f6c709d4aea76de7a88e9fe17272b31ea.1224055978.git.stephen@exigencecorp.com>
On Wed, Oct 15, 2008 at 02:44:38AM -0500, Stephen Haberman wrote:
> + cat "$TODO" | grep -v "${rev:0:7}" > "${TODO}2" ; mv "${TODO}2" "$TODO"
Substring expansion (like ${rev:0:7}) is not portable. At least it
doesn't work on FreeBSD /bin/sh, and "it's not even in POSIX", I
believe.
-Peff
^ permalink raw reply
* Re: need help stripping a repo to one file
From: Baz @ 2008-10-20 11:53 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0810190327i7842d346g4c20f5816e8a9eda@mail.gmail.com>
2008/10/19 Caleb Cushing <xenoterracide@gmail.com>:
> here's what I've done so far (note: this is a public repo if anyone
> wants to take a look)
>
> git clone git@github.com:xenoterracide/dot_usr.git sql_iabbr
> cd sql_iabbr/
> git checkout db3c5ffb180f10dde8e539a81a6644760e098dcd
> git branch -D master
> git checkout -b master
> git filter-branch --subdirectory-filter vim/ftplugin/ -- --all
>
>
> that leaves me with this
> html sgml sh tex vim xhtml xml sql_iabbr.vim xml.vim
>
> all I want left is sql_iabbr.vim and it's history
So you just want the history for a single file?
git log -p --reverse --pretty=email -- sql_iabbr.vim
That outputs a patch history for sql_iabbr.vim in mbox format, you can
import that into an empty repo with git-am.
(I had a look at the project, the history is simple with no merges
etc, so nothing like --first-parent is needed)
Cheers,
Baz
>
> I've used stuff like
> git filter-branch --tree-filter 'rm -rf xml.vim' HEAD
>
> to remove the files... but I notice that leaves the logs.
>
> I'm thinking I could do that and then remove those commits but I
> haven't figured out how to remove the commits, and even then I'm not
> sure the repo would be in the state I want.
>
> can anyone help me get to where I want to be? also is there an easier
> way to do what I've done so far?
> --
> Caleb Cushing
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Jeff King @ 2008-10-20 12:15 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nicolas Pitre, Johan Herland, git
In-Reply-To: <200810201026.57306.trast@student.ethz.ch>
On Mon, Oct 20, 2008 at 10:26:55AM +0200, Thomas Rast wrote:
> > Currently I get the following error when trying to pull from git.git at
> > kernel.org:
> >
> > $ git pull
> > remote: Counting objects: 279, done.
> > remote: Compressing objects: 100% (78/78), done.
> > remote: Total 177 (delta 136), reused 135 (delta 99)
> > Receiving objects: 100% (177/177), 66.59 KiB | 59 KiB/s, done.
> > fatal: pack has bad object at offset 53487: failed to apply delta
> > fatal: index-pack failed
>
> I just had the same, panicked, then compiled 'maint' and the fetch
> worked. Unfortunately I wasn't awake enough to make a copy of the
> repo. Maybe you can make one, then use it to bisect the problem
> between maint and next...
I am getting it, too, but I remembered to save my repo. :) The 'next'
branch is broken, but master works fine. The bisect points to
commit 9441b61dc5c3f1f984114ec8bd470dc20c55dfe0
Author: Nicolas Pitre <nico@cam.org>
Date: Fri Oct 17 15:57:57 2008 -0400
index-pack: rationalize delta resolution code
but I don't have time to look further right now (there is a small child
who apparently thinks coloring with crayons is more interesting than
bisecting bugs).
I can make my broken repo available if need be (though given the number
of us seeing the problem, I doubt it is hard to reproduce).
-Peff
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Michael J Gruber @ 2008-10-20 12:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Maciej Pasternacki, git
In-Reply-To: <7vr66b50gy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 20.10.2008 06:55:
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:
>>
>>> As for -C being superfluous: --git-dir and --work-tree seem to support
>>> weird usage patterns (like work tree separate from git-dir), but it seems
>> Hmm. Yeah, thinking about it more, -C is not really superfluous with
>> respect to those options. You don't want to say "here is the work-tree,
>> and here is the git-dir". You want to say "find the work-tree and
>> git-dir for me using the usual rules, as if I were in this directory."
>
> I think that interpretation of -C, if the option existed, makes sense, but
> I do not understand why the tool that drives git refuses to chdir to the
> repository for itself in the first place.
>
> The only excuse I remember seeing in the thread was that "make has '-C'
> option, so let's have it, because it is similar", which does not justfiy
> addition of that option to git at all to me.
I want to have '-j2' ;)
Seriously:
git -C elsewhere command opts
is shorther and more direct than
(cd elsewhere && git command opts)
which is the true equivalent, or
pushd elsewhere; git command opts; popd
And much shorter than using --git-dir and --work-tree, which are
semi-broken right now.
I just think it's very useful to be able to peek into a repo somewhere
else quickly; or for transferral of objects between unrelated objects
(run rev-parse elsewhere etc.).
Michael
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-20 13:22 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Michael J Gruber, Peter Harris, git
In-Reply-To: <48F8ECA2.3040208@xiplink.com>
Marc Branchaud venit, vidit, dixit 17.10.2008 21:50:
> Michael J Gruber wrote:
>> "pull -s strategy repo master" does a fetch followed by "merge -s
>> strategy repomaster", where repomaster is the ref for master on repo.
>> So, if you got that branch (repomaster=ThingOne/master) by cloning from
>> main you can do the merge (subtree or other) on your clone, even without
>> the remote repo config for ThingOne on clone.
>
> I'm afraid I'm having trouble translating what you're saying into actual
> git commands (or are you proposing some new git functionality?). How
> would I get the ThingOne/master branch into the clone?
Sorry for being cryptic. What I meant was: The clones don't need the
full remote config of main in order to get main's remote branches for
the ThingOne remote. Say, main stores the remote tracking branches for
ThingOne in "refs/remotes/ThingOne", using an appropriate remote config.
Then a clone could use the refspec
"refs/remotes/ThingOne/*:refs/remotes/ThingOne/*" (when fetching from
main) in order to fetch those branches, without having a remote config
for ThingOne on the clone. Concretely:
git config remote.main.fetch
'+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'
on a clone which has a remote config "main" for the main repo.
> After some more thought I realized that the clone can just pull directly
> from the ThingOne repository:
>
> clone/$ git pull -s subtree git://thing/ThingOne.git master
I thought that's what you were trying to avoid...
> (I'm still getting used to git's ability to match commit IDs from
> anywhere -- it's magic! :) )
... but this explains everything ;)
> This goes a long way to where we want to be, in that we don't have to do
> our merging work in the original main repository.
>
> It would be nice, though, if the clone were able to use the main
> repository's definition of the ThingOne remote. I can think of some
> plausible scenarios where a person could get confused about which
> repo/branch they're supposed to pull. It's easy to recover from that
> kind of mistake, but there'd be less chance of a mistake if one could
> tell git to "pull from X as defined in the origin repository".
I think the approach I outlined above could solve this: main prepares
everything to be pulled under refs/remotes/ThingOne, and clones (i.e.
clone users) are told to fetch with a refspec like above. This way they
get a copy of main's remote tracking branches for ThingOne. (Maybe you
use one branch only, then the refspec is even simpler.)
> And actually, git's remote functionality feels a bit crippled if clones
> can't make some use of the origin's remotes. Is there a reason for
> keeping remote definitions out of a clone?
Say A and B are working on a project C. Then, typically, A is interested
in B's work on C, i.e. some of B's local branches, but not on B's remote
tracking branches: A tracks a "central" C already, just like B does,
and remote tracking branches don't carry any "value adding" by the
cloner, they're just a local unmodified copy of the remote.
But you can always add a refspec like above.
Michael
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Nguyen Thai Ngoc Duy @ 2008-10-20 13:59 UTC (permalink / raw)
To: Jeff King; +Cc: Maciej Pasternacki, git
In-Reply-To: <20081019131745.GA8643@coredump.intra.peff.net>
On 10/19/08, Jeff King <peff@peff.net> wrote:
> I'm not sure if the actual problem is related to the oft-discussed,
> unresolved work-tree startup woes, or is something much simpler to fix.
> I'll try to look closer later today.
I think all commands should be able to jump to worktree even if you
are outside work-tree. git-pull and similar commands are easy because
they don't take pathnames. The way pathnames are handled in git does
not make it easy for outside current working directory, because if old
cwd is outside worktree, the parameter "prefix" sent to those commands
become "../../blah/", not a real prefix anymore. If a command expects
an index pathname, then that prefix should be rejected. If they expect
a filesystem pathname, it can be used with care.
--
Duy
^ permalink raw reply
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Nicolas Pitre @ 2008-10-20 13:59 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Johan Herland, git
In-Reply-To: <20081020121533.GA2177@coredump.intra.peff.net>
On Mon, 20 Oct 2008, Jeff King wrote:
> I am getting it, too, but I remembered to save my repo. :) The 'next'
> branch is broken, but master works fine. The bisect points to
>
> commit 9441b61dc5c3f1f984114ec8bd470dc20c55dfe0
> Author: Nicolas Pitre <nico@cam.org>
> Date: Fri Oct 17 15:57:57 2008 -0400
>
> index-pack: rationalize delta resolution code
Dammit... I'm growing a habit of breaking things lately.
> but I don't have time to look further right now (there is a small child
> who apparently thinks coloring with crayons is more interesting than
> bisecting bugs).
>
> I can make my broken repo available if need be (though given the number
> of us seeing the problem, I doubt it is hard to reproduce).
It certainly is... to me at least.
When index-pack dies like that, a temporary (and incomplete) pack file
is left in .git/objects/pack/ with tmp in the file name. I'd need only
that to reproduce the issue.
Nicolas
^ permalink raw reply
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Thomas Rast @ 2008-10-20 14:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johan Herland, Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0810200955250.26244@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
Nicholas Pitre wrote:
> When index-pack dies like that, a temporary (and incomplete) pack file
> is left in .git/objects/pack/ with tmp in the file name. I'd need only
> that to reproduce the issue.
Like this?
http://n.ethz.ch/~trast/download/tmp_pack_NMj69p
--
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, RFC] diff: add option to show context between close chunks
From: Johannes Sixt @ 2008-10-20 14:32 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <48FB757B.9030105@lsrfire.ath.cx>
René Scharfe schrieb:
> This patch adds a new diff option, --inter-chunk-context. It can be
> used to show the context in gaps between chunks, thereby creating a
> big chunk out of two close chunks, in order to have an unbroken
> context, making reviews easier.
>
> With --inter-chunk-context=1, patches have the same number of lines
> as without the option, as only the chunk header is replaced by the
> context line it was shadowing.
>
> You can use commit b0b44bc7b26c8c4b4221a377ce6ba174b843cb8d in the
> git repo to try out this option; there's a chunk in transport.c
> which is just one line away from the next. (I found this option
> helpful in reviewing my own patch before sending. :)
>
> I think it makes sense to make 1, or even 3, the default for this
> option for all commands that create patches intended for human
> consumption. The patch keeps the default at 0, though.
>
> There are downsides, of course: values higher than 1 potentially make
> the resulting patch longer. More context means a higher probability
> of (perhaps unnecessary) merge conflicts.
>
> Comments?
Why can't you just use -U6 instead instead of --inter-chunk-context=3? If
this is intended for human consumption anyway, then you can just as well
increase the overall number of context lines: You get extra context lines
in the places where hunks are not fused, but this cannot be a disadvantage
for the targeted audience.
-- Hannes
^ permalink raw reply
* Re: Archiving tags/branches?
From: Jakub Narebski @ 2008-10-20 14:35 UTC (permalink / raw)
To: Pete Harlan; +Cc: Johan Herland, git, SZEDER Gabor
In-Reply-To: <48FC26DA.10508@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> Johan Herland wrote:
> > BTW, the best way IMHO to archive old refs is to clone your repo
> > (with all tags/branches) to a backup disk, and then regularly push
> > (git push --all && git push --tags) your new tags/branches to this
> > backup. You are now free to delete these tags/branches from your
> > work repo (they will not be deleted from the backup unless you use
> > "git push --mirror"). And if you ever need to retrieve an old
> > tag/branch, it's just a matter of pulling it from the backup
> > repo. Nice, clean, flexible, and requires no changes to git.
>
> Thank you; that indeed seems to work and solves the problem of managing
> refs/archived-tags manually.
>
> Using a secondary repo solely to overcome a flat tag/branch namespace
> feels hackish. Perhaps git will benefit someday from work in this area,
> but until I come up with a patch your suggestion should work fine. Just
> knowing I didn't overlook an existing feature helps a lot.
I don't quite understand what you mean by _flat_ namespace for tags
and branches.
First, it is not unusual to have hierarchical branch names, at least
for short-term topic branches. For example in git.git history (and in
"What's cooking..." announcements on git mailing list) you can find
branch names such as rs/alloc-ref, nd/narrow, tr/workflow-doc.
Additionally remote-tracking branch names have inherently hierarchical
names: refs/remotes/<remote>/<remote branch>. While tag names usually
are of the type x.y.z, it is not mandated by some technological
limitation.
Second, you can always put your archived refs in another namespace,
beside 'heads', 'tags', and 'remotes'. I for example use
refs/tags/Attic for lightweigth tags to some interesting abandoned
experiments, but it could have been refs/deleted/tags, or
refs/Attic/tags.
Last, please remember that there exists something like packed refs
format (see git-pack-refs(1)... oops, it dies not describe
.git/packed-refs format, unfortunately).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* git add --patch newfile doesn't add newfile to cache ?
From: Marc Weber @ 2008-10-20 14:36 UTC (permalink / raw)
To: git
Is this desired behaviour?
Testcase:
#!/bin/sh
# this script creates testGitAddPatch and will run the testcase there
rm -fr testGitAddPatch
mkdir testGitAddPatch
cd testGitAddPatch
git init
echo test > test
git add --patch test
echo "running status, nothing has been added"
git status
git --version
My output
marc@mail: /tmp/git ]$ sh test.sh
Initialized empty Git repository in /tmp/git/testGitAddPatch/.git/
No changes.
running status, nothing has been added
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# test
nothing added to commit but untracked files present (use "git add" to
track)
git version 1.6.0.2.GIT
Marc Weber
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-20 14:43 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FC55F9.3060509@op5.se>
Andreas Ericsson wrote:
> Christian Jaeger wrote:
>> If you really wanted, I suppose you could additionally look into
>> implementing a kind of shallow cloning that only copies objects over
>> the wire which are necessary for representing the subdirectory you're
>> interested in.
>>
>
> So what do you do when one such commit also affects something outside
> the subdirectory?
You haven't said what you mean with "affect".
Since the point is that you do not want to see any effect to be made nor
described if it is about something outside the subdirectory, the program
would just not look at those?
Did you mean, new commits to be made from changed subdirectory contents?
The stuff outside the subdirectory would just be kept the same and thus
again doesn't need to be present locally.
Did you mean merging branches where one or more of the branches have
changes outside the working directory? As long as the changes from the
branches don't touch any of the same files (outside the
subworkingdirectory), there's no need to fetch the files' contents, the
program is only interested in the changes in the directory listings
(thus directory objects). Now if there *are* changes to the same files
(and outside the subworkingdirectory), the program would certainly need
to fetch those contents, too, to be able to create the new contents.
Would it require a place in the working directory? Yes if there are
conflicts which need to be resolved manually, since it needs a place to
put the conflicts to ask the user to resolve. So I guess it boils down
to SVN having a different notion of what a merge entails?
Christian.
^ permalink raw reply
* Re: [PATCHv6 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-20 14:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200810201118.44654.jnareb@gmail.com>
On Mon, Oct 20, 2008 at 11:18 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
>
>> This patch makes it possible to use an URL such as
>> $project/somebranch..otherbranch:/filename to get a diff between
>> different version of a file. Paths like
>> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
>> as well.
>
> Just a nitpick: why '$project' and '$action', but 'somebranch',
> 'otherbranch' and 'filename'?
Good question ... I think I got distracted along the way.
>> All '*diff' actions and in general actions that use $hash_parent[_base]
>> and $file_parent can now get all of their parameters from PATH_INFO
>
> Which currently mean 'shortlog', and I guess in the future would mean
> also all other log-like views: 'log', 'history', 'search' (the commit
> message kind, not the pickaxe kind), and perhaps also 'rss'/'atom'.
I'm not sure rss/atom makes sense, but the others were already in my
todo list after the shortlog patch, so I'll try to get them ready as
soon as I have the time to refactor them as we discussed on IRC.
> Side note: the regexp below allow for $parentpathname to contain
> '..', but we don't want to rely on such minute detail of implementation
> detail (because it depends on whether we use greedy or non-greedy
> matching there).
>
>> + my ($parentrefname, $parentpathname, $refname, $pathname) =
>> + ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
Hm, actually it might be a better idea to make the first pathname
match non-greedy.
>> - $input_params{'action'} ||= "blob_plain";
>> + # the default action depends on whether we had parent info
>> + # or not
>> + if ($parentrefname) {
>> + $input_params{'action'} ||= "blobdiff_plain";
>> + } else {
>> + $input_params{'action'} ||= "blob_plain";
>> + }
>
> Nice.
>
> I was wondering about 'project/hash_parent..hash' syntax, but then I have
> realized that it doesn't change action (as in 'blob_plain' -> 'blobdiff_plain'),
> but is always 'shortlog'.
>
> By the way, I wonder if it should be 'blobdiff_plain' or just 'blobdiff'.
> the 'blob_plain' was here to use gitweb as a kind of versioned web
> server; there is no such equivalent for 'p/hbp..hb:f' syntax. On the
> other hand it is consistent behavior, always using *_plain...
Moreover, it allows sending shorter URLs for patches, which are the
ones you usually write by hand.
>> +
>> + # next, handle the 'parent' part, if present
>> + if (defined $parentrefname) {
>> + # a missing pathspec defaults to the 'current' filename, allowing e.g.
>> + # someproject/blobdiff/oldrev..newrev:/filename
>> + if ($parentpathname) {
>> + $parentpathname =~ s,^/+,,;
>> + $parentpathname =~ s,/$,,;
>
> Hmmm... should we strip trailing '/' here?
I must confess I don't remember why I decided that was needed.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv6 5/5] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-10-20 14:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200810201249.14426.jnareb@gmail.com>
On Mon, Oct 20, 2008 at 12:49 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> - # - hash or hash_base:/filename
>> + # - hash_parent or hash_parent_base:/file_parent
>> + # - hash or hash_base:/file_name
>
> Minor nit: this contain independent change 'filename' -> 'file_name',
> but I think it is not worth separating...
Oopsie. Oh well, I was getting so used to all those _ that it felt
strange without
>> # When the script is the root DirectoryIndex for the domain,
>> # $href here would be something like http://gitweb.example.com/
>> @@ -778,17 +779,36 @@ sub href (%) {
>> delete $params{'action'};
>> }
>>
>> - # Finally, we put either hash_base:/file_name or hash
>> + # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
>> + # stripping nonexistent or useless pieces
>> + $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
>> + || $params{'hash_parent'} || $params{'hash'});
>
> Nice trick (and required change).
>
>> if (defined $params{'hash_base'}) {
>> - $href .= "/".esc_url($params{'hash_base'});
>> - if (defined $params{'file_name'}) {
>> + if (defined $params{'hash_parent_base'}) {
>> + $href .= esc_url($params{'hash_parent_base'});
>> + # skip the file_parent if it's the same as the file_name
>> + delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
>> + if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
>> + $href .= ":/".esc_url($params{'file_parent'});
>> + delete $params{'file_parent'};
>> + }
>
> Side note: I wonder if we should use esc_url or esc_param here...
esc_url, I would say, allowing us to build RFC-compliant URLs. Isn't
esc_param for CGI?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Andreas Ericsson @ 2008-10-20 15:02 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FC9927.5030903@jaeger.mine.nu>
Christian Jaeger wrote:
> Andreas Ericsson wrote:
>> Christian Jaeger wrote:
>>> If you really wanted, I suppose you could additionally look into
>>> implementing a kind of shallow cloning that only copies objects over
>>> the wire which are necessary for representing the subdirectory you're
>>> interested in.
>>>
>>
>> So what do you do when one such commit also affects something outside
>> the subdirectory?
>
> You haven't said what you mean with "affect".
>
I mean "how would you handle a commit (and its tree-object) that updates
all Makefiles in, for example, the Linux kernel project?". Those files
are spread far and wide, and you'd want that change to *your* tree, but
getting it into your tree either means you need to rewrite the tree (and
thereby the commit) itself to get rid of uninteresting blob's from the
tree, and you'd also have to prune the tree to not reveal the directory
layout of the rest of the repository.
I take it parentage could be resolved by a ridiculously large grafts-file.
What you'd end up with wouldn't be a git repository at all anymore. It
would be a "stump", as it'd be missing large parts of the tree entirely.
I'm unsure just how much you'd have to compute to be able to use such a
stump to incorporate your changes with other users again, but I doubt it
would be trivial to implement. Good thing it's not my itch, really.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-20 15:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <48FC5F1B.1050608@op5.se>
On 10/20/08, Andreas Ericsson <ae@op5.se> wrote:
> [..snip..]]
> Will this still play nicely with
>
> git clone foo.git
>
> ?
>
> Otherwise, please also fix the fallout from this patch.
>
> --
Andreas,
thanks for the comment. I have been testing this patch for over two
weeks already and so far encountered no problems. I routinely perform
"git clone foo.git" and it works correctly creating new repo "foo" and
properly populating it.
--Leo--
^ permalink raw reply
* Re: bug: git-stash save and symbolic links
From: Jeff King @ 2008-10-20 15:17 UTC (permalink / raw)
To: Simon Strandgaard; +Cc: git
In-Reply-To: <df1390cc0810200134x68a8eb1fyc7f24650c8c9c5d3@mail.gmail.com>
On Mon, Oct 20, 2008 at 10:34:53AM +0200, Simon Strandgaard wrote:
> git-stash cannot find the repository when the path is a symbolic link.
> solution for me was to cd to the absolute path and then do git-stash.
Sorry, I can't reproduce here, using this test:
mkdir repo &&
cd repo &&
git init &&
echo content >file &&
git add file &&
git commit -m one &&
cd .. &&
ln -s repo linked &&
cd repo &&
echo cruft >>file &&
git stash &&
echo non-linked directory stashed ok &&
cd ../linked &&
echo cruft >>file &&
git stash &&
echo linked directory stashed ok
What version of git are you running (though I tried a few different
ones, and all passed my test)?
-Peff
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-20 15:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FC9D87.3010303@op5.se>
Andreas Ericsson wrote:
> Christian Jaeger wrote:
>> Andreas Ericsson wrote:
>>> Christian Jaeger wrote:
>>>> If you really wanted, I suppose you could additionally look into
>>>> implementing a kind of shallow cloning that only copies objects
>>>> over the wire which are necessary for representing the subdirectory
>>>> you're interested in.
>>>>
>>>
>>> So what do you do when one such commit also affects something outside
>>> the subdirectory?
>>
>> You haven't said what you mean with "affect".
>>
>
> I mean "how would you handle a commit (and its tree-object) that updates
> all Makefiles in, for example, the Linux kernel project?". Those files
> are spread far and wide, and you'd want that change to *your* tree, but
> getting it into your tree either means you need to rewrite the tree (and
> thereby the commit) itself to get rid of uninteresting blob's from the
> tree, and you'd also have to prune the tree to not reveal the directory
> layout of the rest of the repository.
You have said "either" but not "or".
> I take it parentage could be resolved by a ridiculously large
> grafts-file.
Hm, not sure whether you mean to rescue the situation with rewritten
commits here -- but hell no, I certainly don't mean to have different
commit objects for different clones/checkouts.
> What you'd end up with wouldn't be a git repository at all anymore. It
> would be a "stump", as it'd be missing large parts of the tree entirely.
That was my point, yes.
> I'm unsure just how much you'd have to compute to be able to use such a
> stump to incorporate your changes with other users again, but I doubt it
> would be trivial to implement. Good thing it's not my itch, really.
I've been suggesting it to Garry :)
Maybe whoever writes up something on the wiki regarding subdirectory
checkouts in SVN versus Git could still care about what the "fundamental
technical" limits are versus what the current implementation (or
practicalness) imposes. It will be both a more enlightening and
potentially more future-proof explanation then.
Christian.
^ permalink raw reply
* Re: Git graph on GitHub
From: Pedro Melo @ 2008-10-20 15:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tom Werner, git
In-Reply-To: <m3zll1ipw6.fsf@localhost.localdomain>
Hi,
On Oct 18, 2008, at 9:56 PM, Jakub Narebski wrote:
> By the way, it might be not relevant because while (if I understand
> correctly) graphs are ordered by commit date they are not aligned on
> time axis, but the timeline of commits for given author on Ohloh looks
> quite nice. (Unfortunately this part of Ohloh is not open source,
> although AFAIK it is also in Ruby). Example:
> https://www.ohloh.net/projects/git/contributors/1194000913727
> (but it doesn't use Flash).
The timeline code is open source. They are using project timeline (http://simile.mit.edu/timeline/
).
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: bug: git-stash save and symbolic links
From: Simon Strandgaard @ 2008-10-20 15:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081020151715.GA13553@coredump.intra.peff.net>
On Mon, Oct 20, 2008 at 5:17 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 20, 2008 at 10:34:53AM +0200, Simon Strandgaard wrote:
[snip]
> What version of git are you running (though I tried a few different
> ones, and all passed my test)?
I have made some changes, so it can be reproduced
prompt> sh run.sh
Initialized empty Git repository in /Users/neoneye/Desktop/test/repo/.git/
Created initial commit a2a7d6f: one
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
before stash
fatal: Not a git repository
fatal: Not a git repository
fatal: Not a git repository
You do not have the initial commit yet
prompt> cat run.sh
rm -rf repo &&
rm -f linked &&
mkdir repo &&
cd repo &&
git init &&
echo content >file &&
git add file &&
git commit -m one &&
mkdir test &&
cd .. &&
ln -s repo/test linked &&
cd linked &&
echo cruft >>file &&
echo before stash &&
git stash &&
echo after stash
prompt> pwd
/Users/neoneye/Desktop/test
prompt>
This is my computer
prompt> git --version
git version 1.5.6.2
prompt> uname -a
Darwin Macintosh.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3
11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386
prompt>
--
Simon Strandgaard
http://toolboxapp.com/
^ permalink raw reply
* Re: bug: git-stash save and symbolic links
From: Simon Strandgaard @ 2008-10-20 15:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <df1390cc0810200832i4fa974fx1d70ed489aa1be02@mail.gmail.com>
On Mon, Oct 20, 2008 at 5:32 PM, Simon Strandgaard <neoneye@gmail.com> wrote:
> On Mon, Oct 20, 2008 at 5:17 PM, Jeff King <peff@peff.net> wrote:
>> On Mon, Oct 20, 2008 at 10:34:53AM +0200, Simon Strandgaard wrote:
> [snip]
>> What version of git are you running (though I tried a few different
>> ones, and all passed my test)?
>
>
> I have made some changes, so it can be reproduced
[snip]
Sorry, forget the other run.sh I forgot to add the dir to the repository.
Here the linked dir is included in the repository.
prompt> sh run.sh
Initialized empty Git repository in /Users/neoneye/Desktop/test/repo/.git/
Created initial commit b904776: one
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
Created commit 19746b5: two
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 test/file2
before stash
fatal: Not a git repository
fatal: Not a git repository
fatal: Not a git repository
You do not have the initial commit yet
prompt> cat run.sh
rm -rf repo &&
rm -f linked &&
mkdir repo &&
cd repo &&
git init &&
echo content >file &&
git add file &&
git commit -m one &&
mkdir test &&
echo content >test/file2 &&
git add test/file2 &&
git commit -m two &&
cd .. &&
ln -s repo/test linked &&
cd linked &&
echo cruft >>file &&
echo before stash &&
git stash &&
echo after stash
prompt> pwd
/Users/neoneye/Desktop/test
prompt>
[snip]
> This is my computer
>
> prompt> git --version
> git version 1.5.6.2
> prompt> uname -a
> Darwin Macintosh.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3
> 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386
> prompt>
>
>
> --
> Simon Strandgaard
> http://toolboxapp.com/
>
--
Simon Strandgaard
http://toolboxapp.com/
^ 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