* Re: current git kernel has strange problems during bisect
From: Christian Couder @ 2009-01-12 4:51 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Alexey Zaytsev, Sam Ravnborg, Linus Torvalds,
Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <20090111230240.GA27489@artemis.corp>
Le lundi 12 janvier 2009, Pierre Habouzit a écrit :
> On Sun, Jan 11, 2009 at 07:47:18PM +0000, Alexey Zaytsev wrote:
> > On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg <sam@ravnborg.org> wrote:
> > >> For bisect, it's indeed somewhat annoying, and we could have perhaps
> > >> done some things a bit differently, but it's about the closest you
> > >> can get to "real history" without making the first btrfs merge-point
> > >> a _total_ disaster.
> > >>
> > >> For bisect purposes, if you know you're not chasing down a btrfs
> > >> issue, you can do
> > >>
> > >> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
> > >>
> > >> where that commit 34353029 is the last one which has _just_ the
> > >> btrfs files. The next commit is when it does "Merge Btrfs into
> > >> fs/btrfs", and that one has the whole kernel tree again.
> > >
> > > The cost of moving this piece of history from one git tree to another
> > > git tree is that we make it harder to debug the kernel for the
> > > advanced user that knows how to do bisect.
> >
> > And wasn't is trivial to avoid? Just exporting the commits as
> > patches and importing them into the kernel tree would preserve
> > the history, and not break bisection.
>
> And would have brought a whole history of totally irrelevant stuff that
> never exited for real, with probably a lot of non-compiling sub-steps
> which would be even worse.
>
> No, the two possible choices were to squash the whole stuff at once, or
> do what has been done IMNSHO. People have to grok how to take shortcuts
> with git-bisect. I know that git-bisect puts people on the brainless
> course of actions where they git-bisect; configure; compile; boot; test;
> mark as good/bad and retry. And that's what I sometimes don't like with
> it. Because people trust git-bisect too much and forget how to think
> right.
Well "git bisect" can be more usefull if it can be fully automated (with git
bisect run) because then you can make the computer do all the boring work.
So I think putting people on the "brainless course of actions" can often be
a good thing.
Anyway it looks to me that this kind of problem could be avoided if one
could "replace" some commits only when bisecting. In this case what could
be done is that one could "replace" the commit where btrfs is merged with
one commit that cuts off the btrfs history. If the merge commit is only
replaced when bisecting, then you get the best of both worlds:
_ when you bisect, you don't see the btrfs history that breaks the kernel
build,
_ when you don't bisect, you see the full real history.
Of course if the bisection process finds out that the "replaced" commit is
the culprit, then you need to understand what this means...
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH/RFC v6 1/3] lstat_cache(): more cache effective symlink/directory detection
From: Junio C Hamano @ 2009-01-12 4:05 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, René Scharfe, Linus Torvalds
In-Reply-To: <1231680542-17315-2-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> -static inline void set_pathname(int len, const char *name, struct pathname *match)
> +static inline void reset_lstat_cache(void)
> {
> - if (len < PATH_MAX) {
> - match->len = len;
> - memcpy(match->path, name, len);
> - match->path[len] = 0;
> - }
> + cache.path[0] = '\0';
> + cache.len = 0;
> + cache.flags = 0;
> }
I see you made this internal to the caching code, but I suspect in the
long run there needs to be a way for callers that use the caching
mechanism to check and then create new paths in the work tree to
invalidate the cached code (namely, builtin-apply.c::write_out_results()
and entry.c::checkout_entry() codepaths).
I'll queue this round to 'pu' anyway, though.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-01-12 4:03 UTC (permalink / raw)
To: Marcel Koeppen; +Cc: git
In-Reply-To: <A40F4753-A81B-43FD-B1A5-B28B627F8BBD@marzelpan.de>
Marcel Koeppen <lists@marzelpan.de> writes:
> Hi,
>
> Am 11.01.2009 um 10:51 schrieb Junio C Hamano:
>
>> ----------------------------------------------------------------
>> [Will merge to "master" soon]
>
>> * mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
>> + git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
>> OS X
>
> I think this belongs into maint - without it the testsuite fails on OSX.
One step at a time.
I did fork the topic at v1.6.1 so that after it proves itself in next and
then in master it can go to maint.
^ permalink raw reply
* Re: [PATCH] Documentation/git-push.txt: minor: compress one option
From: Junio C Hamano @ 2009-01-12 3:59 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <1231729554-10513-1-git-send-email-jidanni@jidanni.org>
Thanks, queued.
This unfortunately missed tonight's integration window and won't appear
until I start next round of integration tomorrow evening.
^ permalink raw reply
* "git diff --stat" doesn't show added empty file
From: Ping Yin @ 2009-01-12 3:36 UTC (permalink / raw)
To: Git Mailing List
$ git --version
git version 1.6.1.9.g97c34
$ mkdir test && cd test && git init && git commit --allow-empty -m
"Initial commit"
$ touch .gitignore && git add .gitignore && git commit -m "Add empty .gitignore"
$ git diff --stat HEAD^..
0 files changed, 0 insertions(+), 0 deletions(-)
May be the following is better?
.gitignore | 0 +
1 files changed, 0 insertions(+), 0 deletions(-)
Ping Yin
^ permalink raw reply
* Re: [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Junio C Hamano @ 2009-01-12 3:15 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1231717555-10559-2-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> If the commit referenced by a gitlink is available in the (possibly
> alternate) object database, read_tree_recursive() is now able to descend
> into the tree of the linked commit if the flag 'traverse_gitlinks' is
> turned on.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
> tree.c | 20 +++++++++++++++++---
> tree.h | 1 +
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/tree.c b/tree.c
> index 03e782a..1468e10 100644
> --- a/tree.c
> +++ b/tree.c
> @@ -7,6 +7,7 @@
> #include "tree-walk.h"
>
> const char *tree_type = "tree";
> +int traverse_gitlinks = 0;
I think we tend to put these global settings that will affect everybody in
environment.c. You do not have to initialize variable to zero; BSS will
take care of it.
When the user explicitly asks you to traverse into submodules and the
necessary commit is not available in a submodule, the code goes on without
complaining. I am not saying it is bad, but I wonder if we would want to
distinguish these three cases:
(1) the submodule is initialized and the necessary commit is there.
(2) the submodule is initialized, but the necessary commit is missing.
(3) the submodule is not even initialized (aka "the user is not
interested in it"); there is only an empty directory.
I think it is perfectly fine not to say anything for (3) but I am unsure
about the second case.
^ permalink raw reply
* [PATCH] Documentation/git-push.txt: minor: compress one option
From: jidanni @ 2009-01-12 3:05 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-push.txt | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6150b1b..3321966 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -86,14 +86,12 @@ nor in any Push line of the corresponding remotes file---see below).
line.
--receive-pack=<git-receive-pack>::
+--exec=<git-receive-pack>::
Path to the 'git-receive-pack' program on the remote
end. Sometimes useful when pushing to a remote
repository over ssh, and you do not have the program in
a directory on the default $PATH.
---exec=<git-receive-pack>::
- Same as \--receive-pack=<git-receive-pack>.
-
-f::
--force::
Usually, the command refuses to update a remote ref that is
--
1.6.0.6
^ permalink raw reply related
* Re: [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
From: Giuseppe Bilotta @ 2009-01-12 2:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901120215.13668.jnareb@gmail.com>
On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Commit 4afbaef by Giuseppe Bilotta (gitweb: ref markers link to named
> shortlogs) turned ref markers for tags and heads into links to
> appropriate views for the ref name.
>
> Unfortunately the code didn't take into account the fact that nesting
> links (A elements) is illegal in (X)HTML:
>
> 12.2.2 Nested links are illegal
>
> Links and anchors defined by the A element must not be nested;
> an A element must not contain any other A elements.
>
> (from http://www.w3.org/TR/html401/struct/links.html#h-12.2.2), and that
> some browsers (e.g. Mozilla 1.17.2 I still use) in the very strict
> conformance mode (application/xhtml+xml mimetype and XML + XHTML DTD)
> _enforce_ this requirement by moving inner link immediately outside the
> end of outer link, i.e. for the HTML source looking like the following
> <a ...> some text <a ...>v1.5.1</a></a>
> rendered HTML (which you can see using "View Selection Source") is
> instead
> <a ...> some text </a><a ...>v1.5.1</a>
> And of course SPAN elements which wraps inner link (inner A element) is
> _not_ moved.
>
>
> This is quite easy to fix for hyperlinked ref markers in 'shortlog' and
> 'history' views: just close the "title" hyperlink before printing
> $extra, i.e. ref markers. I have even made a patch doing that. Then
> instead of incorrect
> _Merge branch into maint_ [] _maint_
> where _aaa_ means that 'aaa' is hyperlink, and [xxx] is a fer marker,
> we will have correct:
> _Merge branch into maint_ [_maint_]
> See that we have two separate and not nested links...
I've seen from the list that you already have patches ready to fix at
least this problem. I think we might start from having these patches
in while we think of the best way to fix the biggest issue:
> What is more complicated is the issue of ref marker from
> git_print_header_div e.g. in 'commit'/'commitdiff' view, and in 'log'
> view. There link is made into block element using "display: block;"
> CSS rule (div.title, a.title), so that you can click _anywhere_ on the
> header block. This breaks layout even worse, making hyperlinked ref
> marker text appear *below* header div:
>
> -----------------------------------------------------------
> |_Merge branch into maint_ [] |
> -----------------------------------------------------------
> _maint_
>
> To preserve current layout and behavior it would be needed to do some
> deep HTML + CSS positioning hackery, perhaps with additional link block
> without any text... But I don't know exactly how to do this; all [few]
> experiments I did failed.
>
> I see possible the following alternate solutions:
> * Ignore this issue (e.g. if it does not affect modern browsers)
That would be my current choice until we find a better solution.
> * Revert 4afbaef (we lose feature, but how often used is it?)
> * Always use quirks mode, or check browser and use quirks mode if it
> would break layout
> * Use extra divs and links and CSS positioning to make layout which
> looks like current one, and behaves as current one, but is more
> complicated.
I'm asking on #html, hopefully I'll get some interesting idea to try for this.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* grammar patches not best use of talent
From: jidanni @ 2009-01-12 2:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vprito32u.fsf@gitster.siamese.dyndns.org>
I've decided to back out of my plan to patch grammar.
$ perl -nwle '/\w+\s+handful.*/i&& print $&' Documentation/*|sort -uf
a handful commits on top of that,
A handful documentation fixes.
A handful documentation updates.
a handful example hooks are copied in the
a handful fixes to run it
a handful of examples:
A handful of sample hooks are installed when
a handful pack-objects changes to help you cope better
a handful small fixes to gitweb.
a handful the real changes in non-zero
first handful of characters, show the full
only handful hexdigits prefix.
only handful hexdigits prefix. Non default number of
only handful hexdigits prefix. This is
At first some of the above lines irritated me, but who am I to say
that English must be said like my mom says it, and is never allowed to
evolve further. Nope, I'll stick to correcting 2+2=3 type things.
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Eric Wong @ 2009-01-12 2:32 UTC (permalink / raw)
To: Morgan Christiansson; +Cc: git
In-Reply-To: <496A890C.8080208@mog.se>
Morgan Christiansson <git@mog.se> wrote:
> The "Ignoring path" message appears to be coming from git which is
> refusing to commit the .git directory. Which leads to git-svn being
> unaware of the files being ignored and giving an error when it can't
> find them.
> I'm personally fine with these files being ignored by git, but git-svn
> needs to be aware that they are not added to the repository.
Hi Morgan,
Can you try the following rough patch and see it it fixes things
for you? Thanks!
>From 559f4b673592f364e9773f2ba65caf09b138521b Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 11 Jan 2009 18:23:38 -0800
Subject: [PATCH/RFC] git-svn: avoid importing nested repos
Some SVN repositories contain .git repositories within them
(hopefully accidentally checked in). Since git refuses to
check in ".git" repositories, this can be a problem when
fetching updates from SVN.
This seems to repull the entire blob from SVN everytime a user
changes something inside the ".git" directory on the SVN side,
but hopefully this will be a rare case and the SVN users will
correct the error quickly.
The test could probably be expanded to be more thorough...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 8 +++++
t/t9133-git-svn-nested-git-repo.sh | 61 ++++++++++++++++++++++++++++++++++++
2 files changed, 69 insertions(+), 0 deletions(-)
create mode 100755 t/t9133-git-svn-nested-git-repo.sh
diff --git a/git-svn.perl b/git-svn.perl
index b0e3d7c..d34d967 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3379,6 +3379,13 @@ sub apply_textdelta {
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '<&', $fh or croak $!;
my $base = $::_repository->temp_acquire('git_blob');
+
+ # skip any .git directories that may have gone into SVN
+ # since update-index refuses to add anything under ".git"
+ if ($fb->{path} =~ m{(?:^|/)\.git(?:/|$)}) {
+ goto apply;
+ }
+
if ($fb->{blob}) {
my ($base_is_link, $size);
@@ -3412,6 +3419,7 @@ sub apply_textdelta {
}
}
seek $base, 0, 0 or croak $!;
+apply:
$fb->{fh} = $fh;
$fb->{base} = $base;
[ SVN::TxDelta::apply($base, $dup, undef, $fb->{path}, $fb->{pool}) ];
diff --git a/t/t9133-git-svn-nested-git-repo.sh b/t/t9133-git-svn-nested-git-repo.sh
new file mode 100755
index 0000000..85402f4
--- /dev/null
+++ b/t/t9133-git-svn-nested-git-repo.sh
@@ -0,0 +1,61 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Eric Wong
+#
+
+test_description='git svn property tests'
+. ./lib-git-svn.sh
+
+test_expect_success 'setup repo with a git repo inside it' '
+ svn co "$svnrepo" s &&
+ (
+ cd s &&
+ git init &&
+ test -f .git/HEAD &&
+ echo a > a &&
+ svn add .git a &&
+ test a = "`sed -ne 1p < a`" &&
+ svn commit -m "create a nested git repo"
+ )
+'
+
+test_expect_success 'clone an SVN repo containing a git repo' '
+ git svn clone "$svnrepo" g
+'
+
+test_expect_success 'SVN-side change outside of .git' '
+ (
+ cd s &&
+ echo b >> a &&
+ svn commit -m "SVN-side change outside of .git"
+ )
+'
+
+test_expect_success 'update git svn-cloned repo' '
+ (
+ cd g &&
+ git svn rebase &&
+ test a = "`sed -ne 1p < a`" &&
+ test b = "`sed -ne 2p < a`"
+ )
+'
+test_expect_success 'SVN-side change inside of .git' '
+ (
+ cd s &&
+ git add a &&
+ git commit -m "add a inside an SVN repo" &&
+ svn add .git &&
+ svn commit -m "SVN-side change inside of .git"
+ )
+'
+
+test_expect_success 'update git svn-cloned repo' '
+ (
+ cd g &&
+ git svn rebase &&
+ grep ^b a &&
+ git log --raw -r
+ )
+'
+
+test_done
--
Eric Wong
^ permalink raw reply related
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Junio C Hamano @ 2009-01-12 2:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901110336380.19665@iabervon.org>
Hmm...
CC vcs-p4.o
cc1: warnings being treated as errors
vcs-p4.c: In function 'output_data':
vcs-p4.c:253: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
vcs-p4.c: In function 'p4_where':
vcs-p4.c:291: warning: ISO C90 forbids mixed declarations and code
vcs-p4.c: In function 'p4_submit':
vcs-p4.c:363: warning: ISO C90 forbids mixed declarations and code
vcs-p4.c: In function 'p4_print':
vcs-p4.c:433: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
vcs-p4.c: In function 'p4_change':
vcs-p4.c:453: warning: ISO C90 forbids mixed declarations and code
vcs-p4.c: In function 'p4_filelog':
vcs-p4.c:504: warning: ISO C90 forbids mixed declarations and code
make: *** [vcs-p4.o] Error 1
^ permalink raw reply
* Re: [RFC/PATCH 0/3] Enable in-process submodule traversal
From: Junio C Hamano @ 2009-01-12 2:07 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1231717555-10559-1-git-send-email-hjemli@gmail.com>
Sounds interesting except 1/3 didn't seem to reach the list...
^ permalink raw reply
* Re: [RFC PATCH 2/3] Add specification of git-vcs helpers
From: Daniel Barkalow @ 2009-01-12 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk591mhwj.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > So far, I've actually used list and import; I've also implemented an
> > export, but haven't figured out exactly how the user should cause it to be
> > used.
> > ...
> > +'capabilities'::
> > + Prints the capabilities of the helper, one per line. These are:
> > + - import: the basic import command
> > + - marks: import should be done with a saved marks file
> > + - find-new-branches: detect new branches
> > + - export: the general export command
> > + - fork: create a new branch and export to it
> > + - anonymous-fork: make commits on a branch without an inherent name
> > + - merge: merge branches (of whatever type the system supports)
> > +
> > + If the helper doesn't support "merge", the default for pull is
> > + to rebase instead of merging.
>
> Have you tried formatting this to both html and man? I think you need to
> dedent the second paragraph, and have '+' as the sole character on a line
> immediately before, without any blank lines. The formatted output of the
> description of 'export' is probably more troublesome as it is much longer.
Nope, I've just been referring to it in the original text, so I've been
careless with markup.
> This list feels like overengineered yet without enough thinking behind it.
Yeah, I haven't really nailed this one down; it's hard to get really right
without having a bunch of different helpers which can do different amounts
of stuff and need different git-side help.
> Your 'list' allows to list what can become branches on the git end, so as
> long as you have tracking information on the git side, find-new-branches
> seems unnecessary, for examle.
I was unclear about what that one meant, I guess. It's supposed to handle
systems where it's possible to create things that work like branches but
are hard to find. If a helper doesn't report the capability, then the user
may need to say, "I also want some/branch/location", or the helper
wouldn't know that's a branch.
For example, in order to find all of the branches in Perforce, you have
to figure out both directions of integration, in order to find branches
that haven't been integrated back into the location you know about, and
that's kind of expensive to determine and a bit tricky to parse.
It's not intended to indicate that the helper will tell you which ones are
new or not, just that, if the helper doesn't have it, it will only tell
you about branches that it's been told about.
> What does 'merge' mean? It cannot mean to fetch their changes from
> foreign vcs and create a merge locally (you only need import from the
> backend, and merge will be a usual git merge). Perhaps you meant if you
> can export a merge back? Some foreign systems may support importing
> merges but not octopus, so it may not be just a black-or-white boolean.
If the helper supports "merge", it means that it is able to create a merge
in the foreign vcs. You're right about needing to separately list an
"octopus" capability, and maybe further refinements.
> Also "the default is to rebase instead of merge" is probably too weak.
> You would want to error out if the user tried to merge, wouldn't you?
I think users should be able to create merges in git if they want to, but
they'd have to linearize the history in order to push it back. Hopefully,
at some point, we'll have a tool to help with this (which would be helpful
for generating patch series, anyway).
> > +'list'::
> > + Takes the remote name, and outputs the names of refs. These
> > + may be followed, after a single space, by "changed" or
> > + "unchanged", indicating whether the foreign repository has
> > + changed from the state in the ref. If the helper doesn't know,
> > + it doesn't have to provide a value. (In particular, it
> > + shouldn't do expensive operations, such as importing the
> > + content, to see whether it matches.)
>
> I am guessing by 'a value' you mean 'changed/unchanged', iow you are not
> saying if the helper does not know it can omit such refs from the list,
> but it is unclear.
Yeah, that's what I meant.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Marcel Koeppen @ 2009-01-12 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63kmtbk6.fsf@gitster.siamese.dyndns.org>
Hi,
Am 11.01.2009 um 10:51 schrieb Junio C Hamano:
> ----------------------------------------------------------------
> [Will merge to "master" soon]
> * mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
> + git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
> OS X
I think this belongs into maint - without it the testsuite fails on OSX.
Marcel
^ permalink raw reply
* [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Lars Hjemli @ 2009-01-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1231717555-10559-1-git-send-email-hjemli@gmail.com>
If the commit referenced by a gitlink is available in the (possibly
alternate) object database, read_tree_recursive() is now able to descend
into the tree of the linked commit if the flag 'traverse_gitlinks' is
turned on.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
tree.c | 20 +++++++++++++++++---
tree.h | 1 +
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/tree.c b/tree.c
index 03e782a..1468e10 100644
--- a/tree.c
+++ b/tree.c
@@ -7,6 +7,7 @@
#include "tree-walk.h"
const char *tree_type = "tree";
+int traverse_gitlinks = 0;
static int read_one_entry_opt(const unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage, int opt)
{
@@ -114,16 +115,29 @@ int read_tree_recursive(struct tree *tree,
default:
return -1;
}
- if (S_ISDIR(entry.mode)) {
+ if (S_ISDIR(entry.mode) || (traverse_gitlinks && S_ISGITLINK(entry.mode))) {
int retval;
char *newbase;
unsigned int pathlen = tree_entry_len(entry.path, entry.sha1);
-
+ struct commit *commit;
+ struct tree *node;
+
+ if (S_ISDIR(entry.mode)) {
+ node = lookup_tree(entry.sha1);
+ } else {
+ commit = lookup_commit_reference_gently(entry.sha1, 1);
+ if (!commit)
+ continue;
+ if (parse_commit(commit))
+ die("parse_commit(%s) failed",
+ sha1_to_hex(entry.sha1));
+ node = commit->tree;
+ }
newbase = xmalloc(baselen + 1 + pathlen);
memcpy(newbase, base, baselen);
memcpy(newbase + baselen, entry.path, pathlen);
newbase[baselen + pathlen] = '/';
- retval = read_tree_recursive(lookup_tree(entry.sha1),
+ retval = read_tree_recursive(node,
newbase,
baselen + pathlen + 1,
stage, match, fn, context);
diff --git a/tree.h b/tree.h
index 2ff01a4..b6b938f 100644
--- a/tree.h
+++ b/tree.h
@@ -4,6 +4,7 @@
#include "object.h"
extern const char *tree_type;
+extern int traverse_gitlinks;
struct tree {
struct object object;
--
1.6.1.81.g1df1.dirty
^ permalink raw reply related
* What's in my gitweb StGit queue (12 Jan 2009)
From: Jakub Narebski @ 2009-01-12 1:52 UTC (permalink / raw)
To: git
Starting from the bottom of the stack; all but first two are
unapplied, and might not apply without conflicts.
I wrote it down among others to get comments which features would you
like to see first. If you plan on working on some feature listed here
yourself, ask and I can send a patch as it is now.
* gitweb: Document that gitweb deals with bare repositories
This was sent to git mailing list with the comment that I could not
find best way of phrasing it. But I think it is worth applying,
anyway. But on the other hand side it can wait, too.
* gitweb: Incremental blame (proof of concept)
This patch was sent to git mailing list as an RFC. It is resend
(with some corrections and additions) of patch by Petr Baudis, which
in turn was tweaked up version of Fredrik Kuivinen. I think it
should be split into three or four patches:
- gitweb: Add optional "Generated in ..." info to footer
- gitweb: Incremental blame
- gitweb: Colorize output during incremental blame
- gitweb: Use incremental blame if JavaScript is enabled
* gitweb: Fix nested links problem with ref markers (WIP)
This is currently more of notification of a bug, than a feature.
The problem is that some browsers in strict mode actively forbid
nested links (which is not allowed according to (X)HTML standard),
and they move inner link to just outside outer link element,
breaking layout in the case of page header for 'commit' action and
other views.
I have just send email about this issue.
* gitweb: Separate features with no project specific override
Currently both per-project features like 'snapshots' (which can be
configured to be overridable by project repository config), and
global features like 'search' or 'forks' (which does not support
project specific overrides) are both put in %feature hash.
* gitweb: Extend project_index file format by project description
Change format of $projects_list file by making it possible to add
optional project description, and make 'project_index' output new
format, with description. This is to have all project info for
project list page in one place.
* gitweb: open files (e.g. indextext.html) in utf8 mode
TO BE DELETED. I think it was (independently?) sent and accepted
already.
* gitweb: Project search
TO BE DELETED. There is implementation by Pasky in gitweb already.
* gitweb: Paginate project list
This patch was sent to git mailing list together with the one above
in one series, but now it will probably conflict due to the changes
in the area. It was perhaps a bit overcomplicated because of trying
to calculate only _minimal_ set of information needed for sorting
(or searching) for all projects, and filling all info only for
_displayed_ projects.
Probably would have to be preceded by patch which makes selection of
what is displayed (searching projects, selecting tags, hiding forks)
be explicit and not happen at display time. Otherwise we will have
less items per page than it should be.
* gitweb: Remove commit title from comitdiff_plain body
This name is not entirely correct, as this commit is about making
commitdiff_plain view to look more like "git show --format=email".
It is a bit obsoleted by 'patch' view (in cooking); further
discussion is required about this patch, for example if
commitdiff_plain view should perhaps be dropped.
* gitweb: Uniquify usage of subroutine prototypes
Truth to be told this patch is mainly because imenu support for
CPerl mode in GNU Emacs trips from time to time on
"sub S_ISGITLINK($) {"
* gitweb: Redirect to appropriate view if 'a=' parameter is missing
* gitweb: Simplify object type detection in git_object()
* gitweb: Make 'object' action implicit by using no action URL
This series of patches is about the fact that gitweb currently has
two ways of filling 'action' parameter: one if it is missing by just
deciding based on type of object what to put in $action, without
changing URL; and the one used for generic 'object' view when we do
full HTTP redurection (and change URL). Those patches try to unify
this area a bit.
* gitweb: Use list form of 'open "-|"' pipeline
Gitweb uses list form of open, which has the double advantage of not
invoking shell (one fork less) and not having to shell escape
parameters... with the exception of a few places where output of git
command has to be filtered (pipelined) to other command. Currently
only snapshot uses that (to compress tarball from git-archive); in
the future syntax highlighting would also use the same mechanism.
This patch is very much work in progress / research in motion.
* gitweb: Try harder in parse_tag; perhaps it was given ambiguous name
This is companion to the patch which is already in gitweb making git
use full ref names, i.e. 'refs/tags/v1.6.0', and not 'v1.6.0' for
h/hb. Well, companion in the sense that it does the other side of
this issue: whet to do if we have ambiguous refs, and not generating
always unambiguous refs. The problem is with "git cat-file tag <ref>",
when <ref> is both tag and non-tag ref... but perhaps this should be
resolved in-core.
* gitweb: Change division of gitweb pages into parts
* gitweb: CSS cleanup (WIP)
This patch series tries to uniquify page division, and simplify CSS
for gitweb to not have to repeat rules, to not have to use class to
not break layout, etc.
* gitweb: Try to sanitize mimetype for 'blob_plain' view
Defensive programming: use 'text/plain' for files which are text and
can be viewed in a browser, and are not among a few 'text/*' mimetypes
universally recognized by web browsers (e.g. 'application/x-perl'
should be shown as 'text/plain'). Alternate solution would be to
use own mime.types (gitweb has configuration option for this).
* gitweb: Add an option to show size of blobs in the tree view
This probably has to be a %feature bacause of performance impact:
make use of the fact that 'git ls-tree -l' can show sizes of blobs.
Thsi feature is inspired by cgit.
* gitweb: Enable transparent compression for HTTP output
IIRC the consensus was that it usually doesn't make sense to use it,
but perhaps with caching... Is %feature. Requires quite modern Perl
with PerlIO::gzip, but fallback on no-compression if it does not
exists.
--
Jakub Narebski
Poland
^ permalink raw reply
* Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 1:46 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
The ISP I use (Telekomunikacja Polska S.A., aka TP) made some
unannounced changes for ADSL service (Neostrada) which made it block
repo.or.cz (and of course its aliases, including git.or.cz where git
wiki resides). It blocks also gimp.org and some Polish IRC servers
(irc.freenode.org on which #git resides works O.K.). People speculate
that this blocking was based on MAPS (Mail Abuse Prevention System,
which is SPAM backwards) lists to fight SPAM and/or to block botnets,
and uses null routing (IP based) blocking. I have no idea why repo.or.cz
is blocked: gimp.org is supposedly blocked because it hosts
irc.gimp.org on the same IP. By block I mean that even ping doesn't
work (no reply at all).
I can access git wiki via one of many free HTTP proxies; currently I use
http://www.4proxy.de so there are only slight problems there.
The problems is with fetching (via git:// protocol) of forks of git
repository on repo.or.cz, and pushing (via SSH) to a few of my git
repositories hosted on repo.or.cz.
Do you have any suggestions to bypass this block for git? I have access
to Linux shell account (no root access, though) which doesn't have
problems with repo.or.cz, so I think I could set up SSH tunnel: but
how? And what to do with access via git:// - move to SSH too?
Thanks in advance
--
Jakub Narebski
Poland
http://forums.thedailywtf.com/forums/t/10789.aspx
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-01-12 1:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Sebastien Cevey, Giuseppe Bilotta
In-Reply-To: <200901120225.30175.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Sun, 11 Jan 2009, Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> These should be moved to the Stalled category; nobody seems to be
>> discussing improvements and sending updates to the series as far as I
>> recall.
>
> I think it is just the author being slow moving; there was quite
> a bit of time between subsequent versions of this patch series.
Oh, being slow is fine and "Stalled" is exactly that.
> But if Sebastien would not resend this series in about a week,
> I'll try to clean it up, add fourth patch, and resend it.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Junio C Hamano @ 2009-01-12 1:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901110335520.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> This supports a useful subset of the usual fetch logic, mostly in the
> config file.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
I like the direction this series is going. In the longer term, it would
be nice if we can have git-svn and git-cvsimport replaced with something
like this.
Is the current foreign vcs interface sufficiently rich to support git as a
foreign scm by using fast-import and fast-export?
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 1/3] Add "vcs" config option in remotes
From: Daniel Barkalow @ 2009-01-12 1:32 UTC (permalink / raw)
To: Ping Yin; +Cc: git, Junio C Hamano
In-Reply-To: <46dff0320901111729y3869db2bxcc2b66a7be247d0b@mail.gmail.com>
On Mon, 12 Jan 2009, Ping Yin wrote:
> On Mon, Jan 12, 2009 at 4:12 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > This will indicate to programs using the remote that it should be
> > accessed through a VCS helper. Until programs support it, have them
> > fail it the option is set.
>
> s/it/if/ ?
Yes. It was pretty late last night when I wrote the commit messages.
-Daniel
^ permalink raw reply
* Re: [RFC PATCH 2/3] Add specification of git-vcs helpers
From: Junio C Hamano @ 2009-01-12 1:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901110334350.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> So far, I've actually used list and import; I've also implemented an
> export, but haven't figured out exactly how the user should cause it to be
> used.
> ...
> +'capabilities'::
> + Prints the capabilities of the helper, one per line. These are:
> + - import: the basic import command
> + - marks: import should be done with a saved marks file
> + - find-new-branches: detect new branches
> + - export: the general export command
> + - fork: create a new branch and export to it
> + - anonymous-fork: make commits on a branch without an inherent name
> + - merge: merge branches (of whatever type the system supports)
> +
> + If the helper doesn't support "merge", the default for pull is
> + to rebase instead of merging.
Have you tried formatting this to both html and man? I think you need to
dedent the second paragraph, and have '+' as the sole character on a line
immediately before, without any blank lines. The formatted output of the
description of 'export' is probably more troublesome as it is much longer.
This list feels like overengineered yet without enough thinking behind it.
Your 'list' allows to list what can become branches on the git end, so as
long as you have tracking information on the git side, find-new-branches
seems unnecessary, for examle. Worse, find-new-branches needs its own
tracking mechansim anyway, but that means how the namespace for remote
tracking branches is managed is left to the vcs backends, even though that
namespace is directly visiblt to git --- my gut feeling is that it would
probably better to arrange things similar to what git native transport
does already. 'list' would say "The remote has what can become refs on
the git end and calls them A, B, C", and the built-in code, using ref
mapping specification, maps them to refs/remotes/somename/{A,B,C}. You do
it again and if you see the remote has D but does not have B anymore, you
know D is a new branch and B was deleted.
What does 'merge' mean? It cannot mean to fetch their changes from
foreign vcs and create a merge locally (you only need import from the
backend, and merge will be a usual git merge). Perhaps you meant if you
can export a merge back? Some foreign systems may support importing
merges but not octopus, so it may not be just a black-or-white boolean.
Also "the default is to rebase instead of merge" is probably too weak.
You would want to error out if the user tried to merge, wouldn't you?
> +'list'::
> + Takes the remote name, and outputs the names of refs. These
> + may be followed, after a single space, by "changed" or
> + "unchanged", indicating whether the foreign repository has
> + changed from the state in the ref. If the helper doesn't know,
> + it doesn't have to provide a value. (In particular, it
> + shouldn't do expensive operations, such as importing the
> + content, to see whether it matches.)
I am guessing by 'a value' you mean 'changed/unchanged', iow you are not
saying if the helper does not know it can omit such refs from the list,
but it is unclear.
^ permalink raw reply
* Re: [RFC PATCH 1/3] Add "vcs" config option in remotes
From: Ping Yin @ 2009-01-12 1:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110332580.19665@iabervon.org>
On Mon, Jan 12, 2009 at 4:12 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> This will indicate to programs using the remote that it should be
> accessed through a VCS helper. Until programs support it, have them
> fail it the option is set.
s/it/if/ ?
^ permalink raw reply
* Re: [PATCH v2 1/4] Add color_fwrite(), a function coloring each line individually
From: Jakub Narebski @ 2009-01-12 1:27 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901120049190.3586@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> We have to set the color before every line and reset it before every
> newline. Add a function color_fwrite() which does that for us.
color_fwrite_lines(), but I guess Junio can correct this himself.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Jakub Narebski @ 2009-01-12 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sebastien Cevey, Giuseppe Bilotta
In-Reply-To: <7vwsd1pjst.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> ----------------------------------------------------------------
>>> [Actively cooking]
>>>
>>> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
>>> - gitweb: Optional grouping of projects by category
>>> - gitweb: Split git_project_list_body in two functions
>>> - gitweb: Modularized git_get_project_description to be more generic
>>
>> This I think needs some further cooking. I guess with addition of one
>> more patch to series categories could be sorted together with projects
>> they contain, and not always have to be in fixed ordering.
>
> These should be moved to the Stalled category; nobody seems to be
> discussing improvements and sending updates to the series as far as I
> recall.
I think it is just the author being slow moving; there was quite
a bit of time between subsequent versions of this patch series.
But if Sebastien would not resend this series in about a week,
I'll try to clean it up, add fourth patch, and resend it.
As to lack of discussion: I think it is cause bu two issues. First,
there is support for tags already implemented which somewhat reduces
need for categories support. Second, hosting sites which have large
number of projects for which categories support might be a nice thing,
use I guess modified gitweb with caching, don't they?
>>> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
>>> - gitweb: link to patch(es) view in commit(diff) and (short)log view
>>> - gitweb: add patches view
>>> - gitweb: change call pattern for git_commitdiff
>>> - gitweb: add patch view
>>
>> If I remember correctly the only point of discussion is calling
>> convention for git_commitdiff, and whether 'patches' view should
>> (re)use git_commitdiff or use its own subroutine.
>
> Thanks; I take it that it is basically usable, useful and can be
> incrementally improved in 'next'?
Yes, I think so. The changes are cosmetic in nature, and I think
the feature this patch adds is quite useful: you can now get patches
and [short] patch series from gitweb which you can apply using git-am.
Nice, isn't it?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Removing a commit from a local branch
From: Sitaram Chamarty @ 2009-01-12 1:20 UTC (permalink / raw)
To: git
In-Reply-To: <a038bef50901111442y16695664y4fed7cdd9d8af27@mail.gmail.com>
On 2009-01-11, Chris Packham <judge.packham@gmail.com> wrote:
> Consider the following example. The maintainer has the
> following branch locally
>
> todeliver: A-B-C-D
>
> He is happy with commits A, C and D but wants to reject B. Ideally I
> want to be able to say
> git rebase --onto <parent of B> <child of B> todelvier
>
> and get
> todeliver: A-C'-D'
you have an off-by-one error here. You need B, not child of
B. Problem solved :-)
^ 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