headers
Junio C Hamano | 1 Mar 2010 03:00
Picon
Picon
Favicon
Gravatar

Re: 'git add' regression in git-1.7?

Jeff King <peff <at> peff.net> writes:

> I'm not sure of the right way to fix this. We can drop further down into
> the directory hierarchy when doing COLLECT_IGNORED and look for actual
> files, but that may have a negative performance impact.

Wouldn't that have negative correctness impact?  I don't see an obvious
way out, other than perhaps checking the set of pathspecs twice.  One
thing that might help is to carry the seen[] array a bit longer so that we
do not have to lose sight of what paths we were given but didn't match.
Permalink | Reply | 9 comments |
headers
Sebastian Pipping | 1 Mar 2010 03:08

Re: [BUG?] fail to svn clone debian's kernel repository

On 06/10/09 18:05, Uwe Kleine-König wrote:
> Hello,
> 
> using git v1.6.3.1 from Debian I fail to successfully run
> 
> 	git svn clone svn://svn.debian.org/kernel/dists/trunk/linux-2.6
> 
> It runs for some time and then ends in:
> 
> 	...
> 	r4695 = f552d98386b301cbeaa3b5a20f9e9d5d3c9c4886 (git-svn)
> 		M	debian/arch/alpha/defines
> 	r4696 = 18c0a37de057d24955b66e8f49db0791f6018288 (git-svn)
> 	Found possible branch point: svn://svn.debian.org/kernel/dists/sid/linux-2.6 =>
svn://svn.debian.org/kernel/dists/trunk/linux-2.6, 4731
> 	Initializing parent: git-svn <at> 4731
> 	W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: File not
found: revision 101, path '/dists/sid/linux-2.6'
> 	W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
> 	This may take a while on large repositories
> 	Found possible branch point: svn://svn.debian.org/kernel/dists/sid/kernel/linux-2.6 =>
svn://svn.debian.org/kernel/dists/sid/linux-2.6, 4094
> 	Initializing parent: git-svn <at> 4094
> 	Found branch parent: (git-svn <at> 4731) e71da640593b63647fb23f915acee03f02fbaa98
> 	Following parent with do_switch
> 	Invalid filesystem path syntax: Cannot replace a directory from within at /usr/lib/git-core/git-svn
line 4388

I have run into a similar problem, both with Git 1.7.0 as well as with
Git via Git.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Junio C Hamano | 1 Mar 2010 04:25
Picon
Picon
Favicon
Gravatar

[PATCH] add: fail "git add ignored-dir/file" without -f

"git add <pathspec>" usually fails the request and gives an advice message
to use the -f option when <pathspec> exactly names an existing path in the
work tree.  However, we didn't issue the warning nor fail the request when
the <pathspec> matches an existing path but it is ignored because a higher
level directory is ignored as a whole.  In such a case, we do not even
descend into it (and we shouldn't).

This catches such a case and issues some warning.

Signed-off-by: Junio C Hamano <gitster <at> pobox.com>
---

 * This is still provisional and I am not fully happy with it; it seems to
   pass the tests.  The error message is based on the full directory name
   we are culling, not on the actual pathspec the user gave us, as we do
   not have access to it.

 dir.c                  |   15 +++++-----
 t/t2204-add-ignored.sh |   70 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+), 7 deletions(-)
 create mode 100755 t/t2204-add-ignored.sh

diff --git a/dir.c b/dir.c
index 00d698d..af4ba92 100644
--- a/dir.c
+++ b/dir.c
 <at>  <at>  -413,13 +413,10  <at>  <at>  static struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathna
 	return dir->entries[dir->nr++] = dir_entry_new(pathname, len);
 }
(Continue reading)

Permalink | Reply | 1 comment |
headers
Junio C Hamano | 1 Mar 2010 04:49
Picon
Picon
Favicon
Gravatar

Re: [PATCH v2 00/12] add --ff option to cherry-pick

Thanks, but this seems to conflict with too many things in flight (it
applies cleanly on top of 'pu' but not on top of 'next').

Given that "rebase--interactive", which is the sole in-tree user of
cherry-pick, has its own fast-forwarding logic to skip call to it, it
seems to take too much time out of me to deal with the code churn for
dubious benefit---the series does not seem to solve any real problem.

After other topics have either graduated to 'master' or dropped out of
'pu', things might look differently, though.
Permalink | Reply | 8 comments |
headers
Phil Miller | 1 Mar 2010 04:55
Favicon

'Deepen' after "git clone --depth=1"?

Suppose I want to make a shallow clone of a repository for some
size-sensitive application. I may later want to fill out the complete
history of that repository, so that I can work with it as if I had
done a full-depth clone to begin with. Is there an existing porcelain
command/option to produce that effect? If not, is there a fundamental
reason why this couldn't be implemented? It looks like this is
something fetch-pack should be able to do, but its documentation
doesn't seem to describe how. Also, the man page for fetch appears to
lie, in that --depth=n (where n is greater than the clone depth)
doesn't have any noticeable effect.

If the answer is simply "no one's written the code to do it yet", I'll
be happy to provide the necessary round tuits.

Phil
Permalink | Reply | 1 comment |
headers
Daniel Barkalow | 1 Mar 2010 05:42

Re: [PATCH v2 00/12] add --ff option to cherry-pick

On Sun, 28 Feb 2010, Junio C Hamano wrote:

> Given that "rebase--interactive", which is the sole in-tree user of
> cherry-pick, has its own fast-forwarding logic to skip call to it, it
> seems to take too much time out of me to deal with the code churn for
> dubious benefit---the series does not seem to solve any real problem.

"git cherry-pick" is a porcelain command, so it shouldn't be evaluated on 
the basis of in-tree users, but on whether people running it from the 
command line would find it helpful.

Of course, I don't think it's especially high-value there, either.

	-Daniel
*This .sig left intentionally blank*
Permalink | Reply | 0 comments |
headers
Eli Barzilay | 1 Mar 2010 07:54
Favicon
Gravatar

gitweb problem?

Whenever I view the toplevel gitweb page (running as a cgi script
under apache), but not when in a specific repo, I get this in my error
log:

gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at
/home/git/gitweb/gitweb.cgi line 2065.
fatal: error processing config file(s)
gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at
/home/git/gitweb/gitweb.cgi line 2221.
gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at
/home/git/gitweb/gitweb.cgi line 2218.

(taken verbatim from the apache error log, removed uninteresting line
prefixes.)

I'm using the pathinfo option, so perhaps there is a problem with that
setup?

Looking at the source, the last two line numbers are in
`git_get_project_config' -- so my guess is that the code is trying to
get the options from the repository config file even when showing the
toplevel page.  Based on this, and also guessing that $git_dir is
unset when viewing the toplevel page, I added

	return unless (defined $git_dir);

to the top (of the `git_get_project_config' function), and I get no
warnings and everything works as it should.

(Disclaimer: I can barely read perl, and I'm a git newbie, so all of
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bert Wesarg | 1 Mar 2010 07:57

Re: [PATCH 2/3] make union merge an xdl merge favor

On Sun, Feb 28, 2010 at 21:15, Junio C Hamano <gitster <at> pobox.com> wrote:
> Bert Wesarg <bert.wesarg <at> googlemail.com> writes:
>
>> The current union merge driver is implemented as an post process.  But the
>> xdl_merge code is quite capable to produce the result by itself.  Therefore
>> move to it there and teach git-merge-file a new --union option.
>
> I like the idea of patch 2 and 3 but they are independent of what we do
> (or don't do) to merge-file.  Could you flip the order of the patches so
> that 2 and 3 can go first?

WIll do. On a side note: I plan to support the --union option also for
git-checkout. Would that be a good idea?

Bert

>
>
>
Permalink | Reply | 3 comments |
headers
Christian Couder | 1 Mar 2010 08:00
Favicon

Re: [PATCH v2 00/12] add --ff option to cherry-pick

On Monday 01 March 2010 04:49:12 Junio C Hamano wrote:
> Thanks, but this seems to conflict with too many things in flight (it
> applies cleanly on top of 'pu' but not on top of 'next').
> 
> Given that "rebase--interactive", which is the sole in-tree user of
> cherry-pick, has its own fast-forwarding logic to skip call to it, it
> seems to take too much time out of me to deal with the code churn for
> dubious benefit---the series does not seem to solve any real problem.
> 
> After other topics have either graduated to 'master' or dropped out of
> 'pu', things might look differently, though.

Ok I will wait for something like a week, and then rebase on top of next and 
resend.

Thanks,
Christian.
Permalink | Reply | 6 comments |
headers
Johannes Sixt | 1 Mar 2010 09:20
Favicon

Re: [PATCH v2 00/12] add --ff option to cherry-pick

Christian Couder schrieb:
> The goal of this patch series is to make it possible for "git cherry-pick"
> to fast forward instead of creating a new commit if the cherry picked commit
> has the same parent as the one we are cherry-picking on.

Why don't you just divert to 'git merge --ff' in this case?

-- Hannes

(PS: Please _do_not_ Cc me if/when you resend this series.)
Permalink | Reply | 1 comment |

Gmane