Junio C Hamano | 1 Mar 03:00 2010
Picon
Picon

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.
Sebastian Pipping | 1 Mar 03:08 2010

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)

Junio C Hamano | 1 Mar 04:25 2010
Picon
Picon

[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)

Junio C Hamano | 1 Mar 04:49 2010
Picon
Picon

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.
Phil Miller | 1 Mar 04:55 2010

'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
Daniel Barkalow | 1 Mar 05:42 2010

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*
Eli Barzilay | 1 Mar 07:54 2010

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)

Bert Wesarg | 1 Mar 07:57 2010

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

>
>
>
Christian Couder | 1 Mar 08:00 2010

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.
Johannes Sixt | 1 Mar 09:20 2010
Picon

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.)


Gmane