* Re: How to push changes from clone back to master
From: Tomas Carnecky @ 2010-01-09 1:00 UTC (permalink / raw)
To: Simon C; +Cc: git
In-Reply-To: <1262986087967-4275010.post@n2.nabble.com>
On 1/8/10 10:28 PM, Simon C wrote:
>
>
> I created master branch in git:
>
> mkdir git_master;
> cd git_master
> git init
> git add .
> git commit
>
> create a clone
> git clone . ../git_clone1
> create newfile
> git add newfile
> git commit .
>
> then try to propagate changes to master
> git push
>
> it gave me some warning, and subsequent git push says everything is up to
> date.
> but I do not see the new file under git_master
If you asked that question in the official IRC channel, the answer would
be 'faq non-bare', which would cause the bot to send you a link to this
entry in the Git FAQ:
http://git.or.cz/gitwiki/GitFaq#Whywon.27tIseechangesintheremoterepoafter.22gitpush.22.3F
tom
^ permalink raw reply
* Re: git-svn: git svn dcommit doesn't handle network failure
From: Jonathan Nieder @ 2010-01-09 1:00 UTC (permalink / raw)
To: Eric Wong
Cc: Brice Goglin, 557477-forwarded, 557477, git, Alex Vandiver,
Pedro Melo, Sam Vilain
In-Reply-To: <20091122112434.29914.59452.reportbug@localhost.localdomain>
Hi Eric,
'git svn dcommit' does not seem to have any error recovery built in,
so the user is put in a not-great situation if the network cable is
pulled in the middle, as in the report below.
See also <http://thread.gmane.org/gmane.comp.version-control.git/70458>
Ideally, it would be nice if users could pretend that each push of
a single commit is an atomic operation that rewrites the corresponding
local commit at the same time. In other words, to clean up we might
unapply the unpushed patch, then run rebase_cmd().
What do you think?
Brice Goglin wrote:
> Package: git-svn
> Version: 1:1.6.5-1
> Severity: important
>
> Hello,
>
> If the network fails during dcommit, git svn gets totally screwed up.
> It will give you the prompt back with HEAD pointing to the last SVN-pushed
> commit, and the next one applied and not git-committed.
>
> $ git svn dcommit
> Committing to svn+ssh://bgoglin@scm.gforge.inria.fr/svn/knem/branches/rma ...
> M common/knem_io.h
> Committed r237
> M common/knem_io.h
> r237 = f839e16b94052f8b71aa4b66124b37a8337182e0 (refs/remotes/rma)
> No changes between current HEAD and refs/remotes/rma
> Resetting to the latest refs/remotes/rma
> Unstaged changes after reset:
> M common/knem_io.h
> M driver/linux/knem_main.c
> ssh: connect to host scm.gforge.inria.fr port 22: Connection timed out
> Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/SVN/Core.pm line 584.
> Network connection closed unexpectedly: at /usr/lib/git-core/git-svn line 557
>
>
> Now the only way I found to solve this mess is to git-reset --hard,
> git checkout the old HEAD again, and git svn dcommit the remaining stuff.
>
> The big problem is that I don't see any easy way to find the old HEAD.
> I had to look back in my terminal history in case there's still the output
> of a git log showing the old HEAD commitid.
>
> I don't know how dcommit works internally, but my feeling is that it
> should go to a new temporary branch during dcommit. This way, we would
> just have to checkout the non-temporary branch on failure. For now,
> I do it manually in case the SVN server fails again, but that's really
> annoying.
>
> thanks,
> Brice
^ permalink raw reply
* [PATCH] hg-to-git: fix COMMITTER type-o
From: Bart Trojanowski @ 2010-01-09 0:54 UTC (permalink / raw)
To: git; +Cc: bart, Stelian Pop
This script passes the author and committer to git-commit via environment
variables, but it was missing the seccond T of COMMITTER in a few places.
Signed-off-by: Bart Trojanowski <bart@jukie.net>
---
contrib/hg-to-git/hg-to-git.py | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 2a6839d..854cd94 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -59,14 +59,14 @@ def getgitenv(user, date):
elems = re.compile('(.*?)\s+<(.*)>').match(user)
if elems:
env += 'export GIT_AUTHOR_NAME="%s" ;' % elems.group(1)
- env += 'export GIT_COMMITER_NAME="%s" ;' % elems.group(1)
+ env += 'export GIT_COMMITTER_NAME="%s" ;' % elems.group(1)
env += 'export GIT_AUTHOR_EMAIL="%s" ;' % elems.group(2)
- env += 'export GIT_COMMITER_EMAIL="%s" ;' % elems.group(2)
+ env += 'export GIT_COMMITTER_EMAIL="%s" ;' % elems.group(2)
else:
env += 'export GIT_AUTHOR_NAME="%s" ;' % user
- env += 'export GIT_COMMITER_NAME="%s" ;' % user
+ env += 'export GIT_COMMITTER_NAME="%s" ;' % user
env += 'export GIT_AUTHOR_EMAIL= ;'
- env += 'export GIT_COMMITER_EMAIL= ;'
+ env += 'export GIT_COMMITTER_EMAIL= ;'
env += 'export GIT_AUTHOR_DATE="%s" ;' % date
env += 'export GIT_COMMITTER_DATE="%s" ;' % date
--
1.6.6.2.g9ad4f53
^ permalink raw reply related
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Linus Torvalds @ 2010-01-09 1:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7v8wc8kshh.fsf@alter.siamese.dyndns.org>
On Fri, 8 Jan 2010, Junio C Hamano wrote:
>
> Yes, and the previous patch wasn't adding what is ignored to the array, so
> here is a re-roll to fix that in addition to the fix to "should the loop
> start from checking an empty path?" issue you noticed.
Ack. Looks ok to me, and I think it's a lot more obvious.
> But I am starting to wonder if we might be better off restructuring
> read_directory_recursive(). Currently it assumes that the path it was
> given _must_ be of interest (i.e. not ignored) and runs excluded() on
> subdirectories it finds to make that same decision before recursing into
> them or skipping them. It might make more sense if it first checked if
> the path given by the caller should be ignored and act accordingly.
Hmm. I can't make myself care one way or the other, I have to admit. I
assume you mean basically taking the path and using the first component of
it _instead_ of doing a readdir() - and getting rid of the simplification
up front?
I agree that that should work. Would it be simpler and cleaner? Perhaps.
I'd have to see both patches to be able to tell. I do admit that while I
acked your patch, it sure ain't _pretty_ to do that special odd
"has_leading_ignored_dir()" thing.
Linus
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Johannes Schindelin @ 2010-01-09 1:36 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Sverre Rabbelier, Avery Pennarun, Junio C Hamano,
Nanako Shiraishi, git
In-Reply-To: <4B47BE13.7070509@gmail.com>
Hi,
On Fri, 8 Jan 2010, A Large Angry SCM wrote:
> Sverre Rabbelier wrote:
> >
> > On Fri, Jan 8, 2010 at 15:31, Avery Pennarun <apenwarr@gmail.com>
> > wrote:
> > > Thanks, I didn't know about that one. But my general point is
> > > still: we seem to have two implementations when the functionality of
> > > one is actually a superset of the other. As far as I can see,
> > > anyway. So the obvious way to reduce the duplicated code is to
> > > simply eliminate the less-featureful implementation.
> >
> > *cough* git sequencer *cough*
>
> *cough* not in my ${PATH} *cough*
*cough* because that GSoC project failed in all but writing? *cough*
^ permalink raw reply
* Re: For real now: bug tracking and secretary tasks in git
From: J.H. @ 2010-01-09 1:54 UTC (permalink / raw)
To: Jan Krüger; +Cc: Git ML
In-Reply-To: <20100109013850.16f82412@perceptron>
> The proposal goes like this:
>
> * Set up bug tracker (done; it's at http://gitbugs.jk.gs/).
> * Optionally make it an official public bug tracker.
Is there a reason that the bug tracker should live outside of
kernel.org? I mean pretty much everything official, the official source
tree for instance, already lives on kernel.org - wouldn't having the bug
tracker under the same domain make more sense?
I also thought there was some discussion about a distributed bug tracker
a while back for this, what ever came of that? If I've been living
under a rock about those issues please pardon my ignorance.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: git-svn: git svn dcommit doesn't handle network failure
From: Eric Wong @ 2010-01-09 2:13 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Brice Goglin, 557477-forwarded, 557477, git, Alex Vandiver,
Pedro Melo, Sam Vilain
In-Reply-To: <20100109010058.GA11922@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Eric,
>
> 'git svn dcommit' does not seem to have any error recovery built in,
> so the user is put in a not-great situation if the network cable is
> pulled in the middle, as in the report below.
>
> See also <http://thread.gmane.org/gmane.comp.version-control.git/70458>
>
> Ideally, it would be nice if users could pretend that each push of
> a single commit is an atomic operation that rewrites the corresponding
> local commit at the same time. In other words, to clean up we might
> unapply the unpushed patch, then run rebase_cmd().
>
> What do you think?
Hi Jonathan,
I agree that error recovery for dcommit sucks right now.
I think Brice's idea (creating a temporary branch to dcommit from)
is easier to implement and less likely to break than automatically
unapplying patches.
Not sure when I'll have time to implement this, but I'll accept
patches in the mean time.
> Brice Goglin wrote:
>
> > Package: git-svn
> > Version: 1:1.6.5-1
> > Severity: important
> >
> > Hello,
> >
> > If the network fails during dcommit, git svn gets totally screwed up.
> > It will give you the prompt back with HEAD pointing to the last SVN-pushed
> > commit, and the next one applied and not git-committed.
> >
> > $ git svn dcommit
> > Committing to svn+ssh://bgoglin@scm.gforge.inria.fr/svn/knem/branches/rma ...
> > M common/knem_io.h
> > Committed r237
> > M common/knem_io.h
> > r237 = f839e16b94052f8b71aa4b66124b37a8337182e0 (refs/remotes/rma)
> > No changes between current HEAD and refs/remotes/rma
> > Resetting to the latest refs/remotes/rma
> > Unstaged changes after reset:
> > M common/knem_io.h
> > M driver/linux/knem_main.c
> > ssh: connect to host scm.gforge.inria.fr port 22: Connection timed out
> > Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/SVN/Core.pm line 584.
> > Network connection closed unexpectedly: at /usr/lib/git-core/git-svn line 557
> >
> >
> > Now the only way I found to solve this mess is to git-reset --hard,
> > git checkout the old HEAD again, and git svn dcommit the remaining stuff.
> >
> > The big problem is that I don't see any easy way to find the old HEAD.
> > I had to look back in my terminal history in case there's still the output
> > of a git log showing the old HEAD commitid.
> >
> > I don't know how dcommit works internally, but my feeling is that it
> > should go to a new temporary branch during dcommit. This way, we would
> > just have to checkout the non-temporary branch on failure. For now,
> > I do it manually in case the SVN server fails again, but that's really
> > annoying.
> >
> > thanks,
> > Brice
> --
^ permalink raw reply
* [PATCH v2 1/2] Test update-index for a gitlink to a .git file
From: Brad King @ 2010-01-09 3:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Avery Pennarun, Lars Hjemli
In-Reply-To: <32541b131001081524g43d54a44i582dd286c1dfe7a5@mail.gmail.com>
Check that update-index recognizes a submodule that uses a .git file.
Currently it works when the .git file specifies an absolute path, but
not when it specifies a relative path.
Signed-off-by: Brad King <brad.king@kitware.com>
---
t/t2104-update-index-gitfile.sh | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100755 t/t2104-update-index-gitfile.sh
diff --git a/t/t2104-update-index-gitfile.sh b/t/t2104-update-index-gitfile.sh
new file mode 100755
index 0000000..ba71984
--- /dev/null
+++ b/t/t2104-update-index-gitfile.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+#
+# Copyright (c) 2010 Brad King
+#
+
+test_description='git update-index for gitlink to .git file.
+'
+
+. ./test-lib.sh
+
+test_expect_success 'submodule with absolute .git file' '
+ mkdir sub1 &&
+ (cd sub1 &&
+ git init &&
+ REAL="$(pwd)/.real" &&
+ mv .git "$REAL"
+ echo "gitdir: $REAL" >.git &&
+ test_commit first)
+'
+
+test_expect_success 'add gitlink to absolute .git file' '
+ git update-index --add -- sub1
+'
+
+test_expect_success 'submodule with relative .git file' '
+ mkdir sub2 &&
+ (cd sub2 &&
+ git init &&
+ mv .git .real &&
+ echo "gitdir: .real" >.git &&
+ test_commit first)
+'
+
+test_expect_failure 'add gitlink to relative .git file' '
+ git update-index --add -- sub2
+'
+
+test_done
--
1.6.5
^ permalink raw reply related
* [PATCH v2 0/2] Support relative .git file in a submodule
From: Brad King @ 2010-01-09 3:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Avery Pennarun, Lars Hjemli
In-Reply-To: <32541b131001081524g43d54a44i582dd286c1dfe7a5@mail.gmail.com>
Junio C Hamano wrote:
> then I've always thought that is simply a misconfiguration (t0002
> seems to use full path for this exact reason).
Everything in that test works with REAL=.real except the line
test "$REAL" = "$(git rev-parse --git-dir)"
because --git-dir returns an absolute path.
> Is there a reason why relative path should be used/usable here, other
> than "being able to is better than not being able to"???
Similar configurations already work:
- A .git file with a relative path works inside its work tree
- A .git symlink with a relative path works inside its work tree
- A submodule whose .git is a real symlink with a relative path works
My patch just fixes an intuitive combination of these cases.
> I don't like my process randomly chdir'ing around assuming they can
> chdir back safely very much, and would prefer not to add such
> codepaths unless absolutely necessary.
Here is a new patch series. Patch 1/2 is unchanged. Patch 2/2 has been
re-written to avoid chdir.
Avery Pennarun wrote:
> This problem seems especially true with submodules. If the
> submodule's repo is something like supermodule/.git/submodule.git, a
> relative path would almost always be a appropriate, no?
Exactly. In fact the experiment I was doing involved creating submodule
repos inside the main .git and linking to them from the work tree
subdirectories. I'm looking into combining the approach with that of
git-new-workdir to keep submodules in the same object database.
Brad King (2):
Test update-index for a gitlink to a .git file
Handle relative paths in submodule .git files
setup.c | 22 +++++++++++++++++++---
t/t2104-update-index-gitfile.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 57 insertions(+), 3 deletions(-)
create mode 100755 t/t2104-update-index-gitfile.sh
^ permalink raw reply
* [PATCH v2 2/2] Handle relative paths in submodule .git files
From: Brad King @ 2010-01-09 3:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Avery Pennarun, Lars Hjemli
In-Reply-To: <32541b131001081524g43d54a44i582dd286c1dfe7a5@mail.gmail.com>
Commit 842abf06f36b5b31050db6406265972e3e1cc189 taught
resolve_gitlink_ref() to call read_gitfile_gently() to resolve .git
files. In this commit teach read_gitfile_gently() to interpret a
relative path in a .git file with respect to the file location.
This change allows update-index to recognize a submodule that uses a
relative path in its .git file. It previously failed because the
relative path was wrongly interpreted with respect to the superproject
directory.
Signed-off-by: Brad King <brad.king@kitware.com>
---
setup.c | 22 +++++++++++++++++++---
t/t2104-update-index-gitfile.sh | 2 +-
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/setup.c b/setup.c
index 2cf0f19..f10e2dd 100644
--- a/setup.c
+++ b/setup.c
@@ -252,6 +252,8 @@ static int check_repository_format_gently(int *nongit_ok)
const char *read_gitfile_gently(const char *path)
{
char *buf;
+ char* dir;
+ const char *slash;
struct stat st;
int fd;
size_t len;
@@ -276,9 +278,23 @@ const char *read_gitfile_gently(const char *path)
if (len < 9)
die("No path in gitfile: %s", path);
buf[len] = '\0';
- if (!is_git_directory(buf + 8))
- die("Not a git repository: %s", buf + 8);
- path = make_absolute_path(buf + 8);
+ dir = buf + 8;
+
+ if (!is_absolute_path(dir) && (slash = strrchr(path, '/'))) {
+ size_t pathlen = slash+1 - path;
+ size_t dirlen = pathlen + len - 8;
+ dir = xmalloc(dirlen + 1);
+ strncpy(dir, path, pathlen);
+ strncpy(dir + pathlen, buf + 8, len - 8);
+ dir[dirlen] = '\0';
+ free(buf);
+ buf = dir;
+ }
+
+ if (!is_git_directory(dir))
+ die("Not a git repository: %s", dir);
+ path = make_absolute_path(dir);
+
free(buf);
return path;
}
diff --git a/t/t2104-update-index-gitfile.sh b/t/t2104-update-index-gitfile.sh
index ba71984..641607d 100755
--- a/t/t2104-update-index-gitfile.sh
+++ b/t/t2104-update-index-gitfile.sh
@@ -31,7 +31,7 @@ test_expect_success 'submodule with relative .git file' '
test_commit first)
'
-test_expect_failure 'add gitlink to relative .git file' '
+test_expect_success 'add gitlink to relative .git file' '
git update-index --add -- sub2
'
--
1.6.5
^ permalink raw reply related
* [PATCH] help: fix configured help format taking over command line one
From: Christian Couder @ 2010-01-09 5:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Gerrit Pape, David Aguilar
Since commit 7c3baa9 (help -a: do not unnecessarily look for a
repository, 2009-09-04), the help format that is passed as a
command line option is not used if an help format has been
configured. This patch fixes that.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-help.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/builtin-help.c b/builtin-help.c
index 09ad4b0..3182a2b 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -23,13 +23,14 @@ static struct man_viewer_info_list {
} *man_viewer_info_list;
enum help_format {
+ HELP_FORMAT_NONE,
HELP_FORMAT_MAN,
HELP_FORMAT_INFO,
HELP_FORMAT_WEB,
};
static int show_all = 0;
-static enum help_format help_format = HELP_FORMAT_MAN;
+static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
OPT_BOOLEAN('a', "all", &show_all, "print all available commands"),
OPT_SET_INT('m', "man", &help_format, "show man page", HELP_FORMAT_MAN),
@@ -415,10 +416,12 @@ int cmd_help(int argc, const char **argv, const char *prefix)
{
int nongit;
const char *alias;
+ enum help_format parsed_help_format;
load_command_list("git-", &main_cmds, &other_cmds);
argc = parse_options(argc, argv, prefix, builtin_help_options,
builtin_help_usage, 0);
+ parsed_help_format = help_format;
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
@@ -437,6 +440,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
setup_git_directory_gently(&nongit);
git_config(git_help_config, NULL);
+ if (parsed_help_format != HELP_FORMAT_NONE)
+ help_format = parsed_help_format;
+
alias = alias_lookup(argv[0]);
if (alias && !is_git_command(argv[0])) {
printf("`git %s' is aliased to `%s'\n", argv[0], alias);
@@ -444,6 +450,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
}
switch (help_format) {
+ case HELP_FORMAT_NONE:
case HELP_FORMAT_MAN:
show_man_page(argv[0]);
break;
--
1.6.6.271.gc8799
^ permalink raw reply related
* Re: Linking multiple Git repositories for version tracking
From: Michael Witten @ 2010-01-09 5:25 UTC (permalink / raw)
To: James Beck; +Cc: git@vger.kernel.org
In-Reply-To: <op.u574cwxqn3qeew@klee>
On Fri, Jan 8, 2010 at 11:03 AM, James Beck <james@jmbeck.com> wrote:
> I'm starting to move into alpha with this code, so I really need to have a
> system that keeps track of compatible firmware versions. The best I can
> come up with is a plain text file (or Excel spreadsheet) that lists the
> overall firmware version, and the Git hash for each individual project.
> That way, if I want to load up a particular firmware version, I can
> checkout each hash for that version. Seems foolproof, but not terribly
> easy, and somewhat annoying.
The Xorg project is currently composed of 197 separate `modules', and
I believe that (practically) each has its own Git repo.
Their solution seems to be the exact same as yours, though it involves
translating between official release numbers and commits from what I
recall, all of which uses this hand-written list:
http://cgit.freedesktop.org/xorg/util/modular/tree/module-list.txt
So, perhaps you just need to write a small script to do the checkouts
automatically for you.
Also, you could use Git tags rather than raw Git hashes. If you have
"releases", you could just make the same tag name in each Git repo, so
that checking out any particular "release" just amounts to having a
script loop through the repos and checkout the necesarry commit using
the associated tag. In fact, I suggested this to the Xorg guys not
long ago:
http://www.mail-archive.com/xorg-devel@lists.x.org/msg03037.html
See:
http://cgit.freedesktop.org/xorg/util/modular/tree/
http://www.x.org/wiki/Development/Documentation/ReleaseHOWTO
^ permalink raw reply
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Jeff King @ 2010-01-09 5:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <alpine.LFD.2.00.1001081701570.7821@localhost.localdomain>
On Fri, Jan 08, 2010 at 05:07:46PM -0800, Linus Torvalds wrote:
> > But I am starting to wonder if we might be better off restructuring
> > read_directory_recursive(). Currently it assumes that the path it was
> > given _must_ be of interest (i.e. not ignored) and runs excluded() on
> > subdirectories it finds to make that same decision before recursing into
> > them or skipping them. It might make more sense if it first checked if
> > the path given by the caller should be ignored and act accordingly.
>
> Hmm. I can't make myself care one way or the other, I have to admit. I
> assume you mean basically taking the path and using the first component of
> it _instead_ of doing a readdir() - and getting rid of the simplification
> up front?
>
> I agree that that should work. Would it be simpler and cleaner? Perhaps.
> I'd have to see both patches to be able to tell. I do admit that while I
> acked your patch, it sure ain't _pretty_ to do that special odd
> "has_leading_ignored_dir()" thing.
It would look something like this:
diff --git a/dir.c b/dir.c
index 3a8d3e6..306d354 100644
--- a/dir.c
+++ b/dir.c
@@ -811,12 +811,19 @@ static void free_simplify(struct path_simplify *simplify)
int read_directory(struct dir_struct *dir, const char *path, int len, const char **pathspec)
{
struct path_simplify *simplify;
+ int d_type = DT_DIR;
+ int exclude;
if (has_symlink_leading_path(path, len))
return dir->nr;
simplify = create_simplify(pathspec);
- read_directory_recursive(dir, path, len, 0, simplify);
+ exclude = excluded(dir, path, &d_type);
+ if (exclude && (dir->flags & DIR_COLLECT_IGNORED) &&
+ in_pathspec(path, len, simplify))
+ dir_add_ignored(dir, path, len);
+ if (!exclude || (dir->flags & DIR_SHOW_IGNORED))
+ read_directory_recursive(dir, path, len, 0, simplify);
free_simplify(simplify);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
But unfortunately excluded() is not happy with the trailing slash on the
path given to read_directory, so we also need on top:
diff --git a/dir.c b/dir.c
index 306d354..6045a84 100644
--- a/dir.c
+++ b/dir.c
@@ -813,12 +813,17 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
struct path_simplify *simplify;
int d_type = DT_DIR;
int exclude;
+ char *path_without_slash;
if (has_symlink_leading_path(path, len))
return dir->nr;
simplify = create_simplify(pathspec);
- exclude = excluded(dir, path, &d_type);
+ path_without_slash = xstrdup(path);
+ if (path_without_slash[strlen(path_without_slash)-1] == '/')
+ path_without_slash[strlen(path_without_slash)-1] = '\0';
+ exclude = excluded(dir, path_without_slash, &d_type);
+ free(path_without_slash);
if (exclude && (dir->flags & DIR_COLLECT_IGNORED) &&
in_pathspec(path, len, simplify))
dir_add_ignored(dir, path, len);
And that does fix the case that triggered this whole discussion, but I
haven't tested thoroughly to make sure we are not adversely affecting
other cases.
-Peff
^ permalink raw reply related
* Re: How to push changes from clone back to master
From: Simon Chu @ 2010-01-09 5:53 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git@vger.kernel.org
In-Reply-To: <4B47D52A.1050608@dbservice.com>
Tomas,
How do I push code to master then, do I do got reset - hard on the
master??
Simon
On Jan 8, 2010, at 5:00 PM, Tomas Carnecky <tom@dbservice.com> wrote:
> On 1/8/10 10:28 PM, Simon C wrote:
> >
> >
> > I created master branch in git:
> >
> > mkdir git_master;
> > cd git_master
> > git init
> > git add .
> > git commit
> >
> > create a clone
> > git clone . ../git_clone1
> > create newfile
> > git add newfile
> > git commit .
> >
> > then try to propagate changes to master
> > git push
> >
> > it gave me some warning, and subsequent git push says everything
> is up to
> > date.
> > but I do not see the new file under git_master
>
> If you asked that question in the official IRC channel, the answer
> would be 'faq non-bare', which would cause the bot to send you a
> link to this entry in the Git FAQ:
> http://git.or.cz/gitwiki/GitFaq#Whywon.27tIseechangesintheremoterepoafter.22gitpush.22.3F
>
> tom
>
^ permalink raw reply
* Re: Problem Using Git with Subversion Repository
From: Eric Wong @ 2010-01-09 6:31 UTC (permalink / raw)
To: Bryan Richardson; +Cc: git
In-Reply-To: <3f81a4241001071453g24297atc1caab4a0a4ad176@mail.gmail.com>
Bryan Richardson <btricha@gmail.com> wrote:
> Hello all,
>
> Has anyone come across a similar problem as this?
>
> Item already exists in filesystem: File already exists: filesystem
> '/usr/local/svn/repos/my-apps/db', transaction '96-2v', path
> '/app/trunk/vendor/rails/actionpack/test/fixtures/layout_tests/layouts/symlinked'
> at /usr/lib/git-core/git-svn line 508
>
> I *think* what happened is in a previous git-svn dcommit I removed the
> vendor/rails directory (unfroze rails from my app) and now I'm trying
> to freeze it again, in which case git-svn thinks a file needs to be
> added (instead of modified) and the Subversion repository says the
> file already exists.
Hi Bryan,
Which version of git svn are you using? Any chance we can take a look
at the SVN/git history to know what's going on?
Thanks.
> Anyone know a way around it?!
Can you try manually removing that file with "svn rm" and then
doing "git svn rebase" to rebase your working HEAD before trying
to dcommit?
--
Eric Wong
^ permalink raw reply
* Re: How to push changes from clone back to master
From: Junio C Hamano @ 2010-01-09 6:49 UTC (permalink / raw)
To: Simon Chu; +Cc: Tomas Carnecky, git@vger.kernel.org
In-Reply-To: <2394EBAE-BA99-4817-93E3-D5441D6DA46B@gmail.com>
Simon Chu <simonchu.web@gmail.com> writes:
> On Jan 8, 2010, at 5:00 PM, Tomas Carnecky <tom@dbservice.com> wrote:
>
>> If you asked that question in the official IRC channel, the answer
>> would be 'faq non-bare', which would cause the bot to send you a
>> link to this entry in the Git FAQ:
>> http://git.or.cz/gitwiki/GitFaq#Whywon.27tIseechangesintheremoterepoafter.22gitpush.22.3F
>
> How do I push code to master then, do I do got reset - hard on the
> master??
(Please do not top post).
If you asked that question on the IRC, the answer would be 'faq
mothership-satellite', which would cause the bot to send you a link to
this entry in the Git FAQ:
push is reverse of fetch. See
http://git.or.cz/gitwiki/GitFaq#mothership-satellite
This link is recommended by the entry Tomas gave you, so I am having this
sad feeling that you wouldn't read it either... Sigh.
^ permalink raw reply
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Junio C Hamano @ 2010-01-09 7:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <alpine.LFD.2.00.1001081701570.7821@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I'd have to see both patches to be able to tell. I do admit that while I
> acked your patch, it sure ain't _pretty_ to do that special odd
> "has_leading_ignored_dir()" thing.
Revised patch (v4) series is coming shortly.
^ permalink raw reply
* [PATCH 1/4] t3001: test ls-files -o ignored/dir
From: Junio C Hamano @ 2010-01-09 7:35 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Jeff King, Michael J Gruber, Jon Schewe, spearce
In-Reply-To: <7veilzaguf.fsf@alter.siamese.dyndns.org>
When you have "t" directory that is marked as ignored in the top-level
.gitignore file (or $GIT_DIR/info/exclude), running
$ git ls-files -o --exclude-standard
from the top-level correctly excludes files in "t" directory, but
any of the following:
$ git ls-files -o --exclude-standard t/
$ cd t && git ls-files -o --exclude-standard
would show untracked files in that directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t3001-ls-files-others-exclude.sh | 39 ++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
index c65bca8..e3e4d71 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -153,4 +153,43 @@ test_expect_success 'negated exclude matches can override previous ones' '
grep "^a.1" output
'
+test_expect_success 'subdirectory ignore (setup)' '
+ mkdir -p top/l1/l2 &&
+ (
+ cd top &&
+ git init &&
+ echo /.gitignore >.gitignore &&
+ echo l1 >>.gitignore &&
+ echo l2 >l1/.gitignore &&
+ >l1/l2/l1
+ )
+'
+
+test_expect_success 'subdirectory ignore (toplevel)' '
+ (
+ cd top &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'subdirectory ignore (l1/l2)' '
+ (
+ cd top/l1/l2 &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_failure 'subdirectory ignore (l1)' '
+ (
+ cd top/l1 &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
test_done
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* [PATCH 2/4] read_directory_recursive(): refactor handling of a single path into a separate function
From: Junio C Hamano @ 2010-01-09 7:35 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Jeff King, Michael J Gruber, Jon Schewe, spearce
In-Reply-To: <1263022535-12822-1-git-send-email-gitster@pobox.com>
Primarily because I want to reuse it in a separate function later,
but this de-dents a huge function by one tabstop which by itself is
an improvement as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
dir.c | 153 ++++++++++++++++++++++++++++++++++++++---------------------------
1 files changed, 90 insertions(+), 63 deletions(-)
diff --git a/dir.c b/dir.c
index d0999ba..dec8365 100644
--- a/dir.c
+++ b/dir.c
@@ -625,6 +625,84 @@ static int get_dtype(struct dirent *de, const char *path, int len)
return dtype;
}
+enum path_treatment {
+ path_ignored,
+ path_handled,
+ path_recurse,
+};
+
+static enum path_treatment treat_path(struct dir_struct *dir,
+ struct dirent *de,
+ char *path, int path_max,
+ int baselen,
+ const struct path_simplify *simplify,
+ int *len)
+{
+ int dtype, exclude;
+
+ if (is_dot_or_dotdot(de->d_name) || !strcmp(de->d_name, ".git"))
+ return path_ignored;
+ *len = strlen(de->d_name);
+ /* Ignore overly long pathnames! */
+ if (*len + baselen + 8 > path_max)
+ return path_ignored;
+ memcpy(path + baselen, de->d_name, *len + 1);
+ *len += baselen;
+ if (simplify_away(path, *len, simplify))
+ return path_ignored;
+
+ dtype = DTYPE(de);
+ exclude = excluded(dir, path, &dtype);
+ if (exclude && (dir->flags & DIR_COLLECT_IGNORED)
+ && in_pathspec(path, *len, simplify))
+ dir_add_ignored(dir, path, *len);
+
+ /*
+ * Excluded? If we don't explicitly want to show
+ * ignored files, ignore it
+ */
+ if (exclude && !(dir->flags & DIR_SHOW_IGNORED))
+ return path_ignored;
+
+ if (dtype == DT_UNKNOWN)
+ dtype = get_dtype(de, path, *len);
+
+ /*
+ * Do we want to see just the ignored files?
+ * We still need to recurse into directories,
+ * even if we don't ignore them, since the
+ * directory may contain files that we do..
+ */
+ if (!exclude && (dir->flags & DIR_SHOW_IGNORED)) {
+ if (dtype != DT_DIR)
+ return path_ignored;
+ }
+
+ switch (dtype) {
+ default:
+ return path_ignored;
+ case DT_DIR:
+ memcpy(path + *len, "/", 2);
+ (*len)++;
+ switch (treat_directory(dir, path, *len, simplify)) {
+ case show_directory:
+ if (exclude != !!(dir->flags
+ & DIR_SHOW_IGNORED))
+ return path_ignored;
+ break;
+ case recurse_into_directory:
+ return path_recurse;
+ case ignore_directory:
+ return path_ignored;
+ }
+ break;
+ case DT_REG:
+ case DT_LNK:
+ break;
+ }
+ return path_handled;
+}
+
/*
* Read a directory tree. We currently ignore anything but
* directories, regular files and symlinks. That's because git
@@ -634,7 +712,10 @@ static int get_dtype(struct dirent *de, const char *path, int len)
* Also, we ignore the name ".git" (even if it is not a directory).
* That likely will not change.
*/
-static int read_directory_recursive(struct dir_struct *dir, const char *base, int baselen, int check_only, const struct path_simplify *simplify)
+static int read_directory_recursive(struct dir_struct *dir,
+ const char *base, int baselen,
+ int check_only,
+ const struct path_simplify *simplify)
{
DIR *fdir = opendir(*base ? base : ".");
int contents = 0;
@@ -645,70 +726,16 @@ static int read_directory_recursive(struct dir_struct *dir, const char *base, in
memcpy(path, base, baselen);
while ((de = readdir(fdir)) != NULL) {
- int len, dtype;
- int exclude;
-
- if (is_dot_or_dotdot(de->d_name) ||
- !strcmp(de->d_name, ".git"))
- continue;
- len = strlen(de->d_name);
- /* Ignore overly long pathnames! */
- if (len + baselen + 8 > sizeof(path))
+ int len;
+ switch (treat_path(dir, de, path, sizeof(path),
+ baselen, simplify, &len)) {
+ case path_recurse:
+ contents += read_directory_recursive
+ (dir, path, len, 0, simplify);
continue;
- memcpy(path + baselen, de->d_name, len+1);
- len = baselen + len;
- if (simplify_away(path, len, simplify))
+ case path_ignored:
continue;
-
- dtype = DTYPE(de);
- exclude = excluded(dir, path, &dtype);
- if (exclude && (dir->flags & DIR_COLLECT_IGNORED)
- && in_pathspec(path, len, simplify))
- dir_add_ignored(dir, path,len);
-
- /*
- * Excluded? If we don't explicitly want to show
- * ignored files, ignore it
- */
- if (exclude && !(dir->flags & DIR_SHOW_IGNORED))
- continue;
-
- if (dtype == DT_UNKNOWN)
- dtype = get_dtype(de, path, len);
-
- /*
- * Do we want to see just the ignored files?
- * We still need to recurse into directories,
- * even if we don't ignore them, since the
- * directory may contain files that we do..
- */
- if (!exclude && (dir->flags & DIR_SHOW_IGNORED)) {
- if (dtype != DT_DIR)
- continue;
- }
-
- switch (dtype) {
- default:
- continue;
- case DT_DIR:
- memcpy(path + len, "/", 2);
- len++;
- switch (treat_directory(dir, path, len, simplify)) {
- case show_directory:
- if (exclude != !!(dir->flags
- & DIR_SHOW_IGNORED))
- continue;
- break;
- case recurse_into_directory:
- contents += read_directory_recursive(dir,
- path, len, 0, simplify);
- continue;
- case ignore_directory:
- continue;
- }
- break;
- case DT_REG:
- case DT_LNK:
+ case path_handled:
break;
}
contents++;
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* [PATCH 3/4] read_directory(): further split treat_path()
From: Junio C Hamano @ 2010-01-09 7:35 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Jeff King, Michael J Gruber, Jon Schewe, spearce
In-Reply-To: <1263022535-12822-1-git-send-email-gitster@pobox.com>
The next caller I'll be adding won't have an access to struct dirent
because it won't be reading from a directory stream. Split the main
part of the function further into a separate function to make it usable
by a caller without passing a dirent as long as it knows what type is
feeding the function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
dir.c | 50 +++++++++++++++++++++++++++++---------------------
1 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/dir.c b/dir.c
index dec8365..35cc89b 100644
--- a/dir.c
+++ b/dir.c
@@ -631,28 +631,12 @@ enum path_treatment {
path_recurse,
};
-static enum path_treatment treat_path(struct dir_struct *dir,
- struct dirent *de,
- char *path, int path_max,
- int baselen,
- const struct path_simplify *simplify,
- int *len)
+static enum path_treatment treat_one_path(struct dir_struct *dir,
+ char *path, int *len,
+ const struct path_simplify *simplify,
+ int dtype, struct dirent *de)
{
- int dtype, exclude;
-
- if (is_dot_or_dotdot(de->d_name) || !strcmp(de->d_name, ".git"))
- return path_ignored;
- *len = strlen(de->d_name);
- /* Ignore overly long pathnames! */
- if (*len + baselen + 8 > path_max)
- return path_ignored;
- memcpy(path + baselen, de->d_name, *len + 1);
- *len += baselen;
- if (simplify_away(path, *len, simplify))
- return path_ignored;
-
- dtype = DTYPE(de);
- exclude = excluded(dir, path, &dtype);
+ int exclude = excluded(dir, path, &dtype);
if (exclude && (dir->flags & DIR_COLLECT_IGNORED)
&& in_pathspec(path, *len, simplify))
dir_add_ignored(dir, path, *len);
@@ -703,6 +687,30 @@ static enum path_treatment treat_path(struct dir_struct *dir,
return path_handled;
}
+static enum path_treatment treat_path(struct dir_struct *dir,
+ struct dirent *de,
+ char *path, int path_max,
+ int baselen,
+ const struct path_simplify *simplify,
+ int *len)
+{
+ int dtype;
+
+ if (is_dot_or_dotdot(de->d_name) || !strcmp(de->d_name, ".git"))
+ return path_ignored;
+ *len = strlen(de->d_name);
+ /* Ignore overly long pathnames! */
+ if (*len + baselen + 8 > path_max)
+ return path_ignored;
+ memcpy(path + baselen, de->d_name, *len + 1);
+ *len += baselen;
+ if (simplify_away(path, *len, simplify))
+ return path_ignored;
+
+ dtype = DTYPE(de);
+ return treat_one_path(dir, path, len, simplify, dtype, de);
+}
+
/*
* Read a directory tree. We currently ignore anything but
* directories, regular files and symlinks. That's because git
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* [PATCH 4/4] ls-files: fix overeager pathspec optimization
From: Junio C Hamano @ 2010-01-09 7:35 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Jeff King, Michael J Gruber, Jon Schewe, spearce
In-Reply-To: <1263022535-12822-1-git-send-email-gitster@pobox.com>
Given pathspecs that share a common prefix, ls-files optimized its call
into recursive directory reader by starting at the common prefix
directory.
If you have a directory "t" with an untracked file "t/junk" in it, but the
top-level .gitignore file told us to ignore "t/", this resulted in:
$ git ls-files -o --exclude-standard
$ git ls-files -o --exclude-standard t/
t/junk
$ git ls-files -o --exclude-standard t/junk
t/junk
$ cd t && git ls-files -o --exclude-standard
junk
We could argue that you are overriding the ignore file by giving a
patchspec that matches or being in that directory, but it is somewhat
unexpected. Worse yet, these behave differently:
$ git ls-files -o --exclude-standard t/ .
$ git ls-files -o --exclude-standard t/
t/junk
This patch changes the optimization so that it notices when the common
prefix directory that it starts reading from is an ignored one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
dir.c | 38 +++++++++++++++++++++++++++++++++++-
t/t3001-ls-files-others-exclude.sh | 2 +-
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index 35cc89b..00d698d 100644
--- a/dir.c
+++ b/dir.c
@@ -813,6 +813,41 @@ static void free_simplify(struct path_simplify *simplify)
free(simplify);
}
+static int treat_leading_path(struct dir_struct *dir,
+ const char *path, int len,
+ const struct path_simplify *simplify)
+{
+ char pathbuf[PATH_MAX];
+ int baselen, blen;
+ const char *cp;
+
+ while (len && path[len - 1] == '/')
+ len--;
+ if (!len)
+ return 1;
+ baselen = 0;
+ while (1) {
+ cp = path + baselen + !!baselen;
+ cp = memchr(cp, '/', path + len - cp);
+ if (!cp)
+ baselen = len;
+ else
+ baselen = cp - path;
+ memcpy(pathbuf, path, baselen);
+ pathbuf[baselen] = '\0';
+ if (!is_directory(pathbuf))
+ return 0;
+ if (simplify_away(pathbuf, baselen, simplify))
+ return 0;
+ blen = baselen;
+ if (treat_one_path(dir, pathbuf, &blen, simplify,
+ DT_DIR, NULL) == path_ignored)
+ return 0; /* do not recurse into it */
+ if (len <= baselen)
+ return 1; /* finished checking */
+ }
+}
+
int read_directory(struct dir_struct *dir, const char *path, int len, const char **pathspec)
{
struct path_simplify *simplify;
@@ -821,7 +856,8 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
return dir->nr;
simplify = create_simplify(pathspec);
- read_directory_recursive(dir, path, len, 0, simplify);
+ if (!len || treat_leading_path(dir, path, len, simplify))
+ read_directory_recursive(dir, path, len, 0, simplify);
free_simplify(simplify);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
index e3e4d71..9e71260 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -183,7 +183,7 @@ test_expect_success 'subdirectory ignore (l1/l2)' '
test_cmp expect actual
'
-test_expect_failure 'subdirectory ignore (l1)' '
+test_expect_success 'subdirectory ignore (l1)' '
(
cd top/l1 &&
git ls-files -o --exclude-standard
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* Bug#557477: git-svn: git svn dcommit doesn't handle network failure
From: Jonathan Nieder @ 2010-01-09 7:57 UTC (permalink / raw)
To: Eric Wong
Cc: Brice Goglin, 557477-forwarded, 557477, git, Alex Vandiver,
Pedro Melo, Sam Vilain
In-Reply-To: <20100109021347.GA26520@dcvr.yhbt.net>
Eric Wong wrote:
> I agree that error recovery for dcommit sucks right now.
>
> I think Brice's idea (creating a temporary branch to dcommit from)
> is easier to implement and less likely to break than automatically
> unapplying patches.
Sounds sane to me. Probably that temporary branch could just be
a detached HEAD.
Current dcommit:
diff-index --quiet HEAD || carp "Cannot dcommit with a dirty index"
if head ne 'HEAD':
save the old HEAD
check out the head
find svn upstream
decide what commits to push (linearize_history)
for each commit d to push:
commit diff from d~ to d to the remote repository
(this involves applying the diff locally?)
remember parents
fetch remote revision, using remembered parents for commit
unless args include --no-rebase:
rebase the current HEAD against fetched revision
(or reset if there are no changes)
update the list of commits to push
if head ne 'HEAD':
let the user know the branch or commit id for the finished dcommit
check out the old head again
If I understand you correctly, before finding the svn upstream,
dcommit would save the HEAD ref name (if any) and detach the HEAD;
after pushing the relevant commits, update that ref and reattach the
HEAD.
If pushing fails early, what should git-svn do? Leave the HEAD
detached, with a message suggesting to return to the old ref? Check
out the old ref, with a message suggesting to 'git svn rebase' and try
again? Do the 'git svn rebase' automatically?
I guess the safest option is the first one. That would at least be a
starting point for experimenting with more friendly behaviors.
I should also mention that there seems to be a little race here: if
git-svn dies before (or while) fetching the newly commited revision,
when it is fetched later it will have the wrong parents.
Jonathan
^ permalink raw reply
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Junio C Hamano @ 2010-01-09 8:07 UTC (permalink / raw)
To: Linus Torvalds, Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7veilzaguf.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> I'd have to see both patches to be able to tell. I do admit that while I
>> acked your patch, it sure ain't _pretty_ to do that special odd
>> "has_leading_ignored_dir()" thing.
>
> Revised patch (v4) series is coming shortly.
Having sent these patches, I am wondering if the simplest fix might be this
one-liner.
diff --git a/dir.c b/dir.c
index d0999ba..7fba335 100644
--- a/dir.c
+++ b/dir.c
@@ -788,3 +788,3 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
simplify = create_simplify(pathspec);
- read_directory_recursive(dir, path, len, 0, simplify);
+ read_directory_recursive(dir, "", 0, 0, simplify);
free_simplify(simplify);
What my series does is to keep all the "depending on dir->flags and what
excluded() says for path, decide to recurse, add it to dir->ignored[],
etc." logic and optimize only the readdir() loop, pretending as if it
returned only the entry on the "common prefix" path and nothing else, as
we know all other paths will be skipped by either simplified away or
filtered by in_pathspec() check.
If the directories we are reading are not humongous, maybe using this much
simpler patch might be preferrable (although it is completely untested).
^ permalink raw reply related
* Re: [PATCH] Don't pass CFLAGS to the linker
From: Paolo Bonzini @ 2010-01-09 10:32 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <1261896918-1953-1-git-send-email-tom@dbservice.com>
On 12/27/2009 07:55 AM, Tomas Carnecky wrote:
> Signed-off-by: Tomas Carnecky<tom@dbservice.com>
> ---
>
> I don't remember exactly which tool had problems with CFLAGS being passed
> to the linker. Maybe it was the clang static analyzer, or some other
> tool that I let run on git.git. Anyway, I don't think there's any
> reason to pass CFLAGS to the linker.
One reason is if you want to use GCC's upcoming link-time optimization
(-flto).
Paolo
^ permalink raw reply
* Re: [PATCHv3 3/4 (resent)] gitweb: Optionally add "git" links in project list page
From: Jakub Narebski @ 2010-01-09 11:20 UTC (permalink / raw)
To: J.H.; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <4B47E06C.9070503@eaglescrag.net>
On Sat, 9 Jan 2010, J.H. wrote:
> On 01/03/2010 08:07 AM, Jakub Narebski wrote:
> > From: John 'Warthog9' Hawley <warthog9@kernel.org>
> >
> > This adds a "git" link for each project in the project list page,
> > should a common $gitlinkurl_base be defined and not empty. The full
> > URL of each link is composed of $gitlinkurl_base and project name.
> > It is intended for git:// links, and in fact GITWEB_BASE_URL build
> > variable is used as its default value only if it starts with git://
> >
> > This does make the assumption that the git repositories share a common
> > path. Nothing to date is known to actually make use of introduced
> > link.
> >
> > Created "git" link follows rel=vcs-* microformat specification:
> > http://kitenet.net/~joey/rfc/rel-vcs/
> >
> > Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
> > Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> > ---
> > I think it might be good idea... but for the fact "Nothing to date is
> > known to actually make use of introduced link". What's its intended
> > use?
> >
> > Differences to original version by John 'Warthog9' Hawley (J.H.):
> > * It doesn't cause syntax error ;-)
> > * Escaping of attribute value is left to CGI.pm (avoid double escaping)
> > * $gitlinkurl got renamed to $gitlinkurl_base, now includes git://
> > prefix, and defaults to GITWEB_BASE_URL if it begins with git://
> > * Added description of $gitlinkurl_base to gitweb/README
> > * Uses rel=vcs-* microformat by Joey Hess
> > gitweb/README | 4 ++++
> > gitweb/gitweb.perl | 8 ++++++++
> > 2 files changed, 12 insertions(+), 0 deletions(-)
A reminder - this patch series consists of the following patches:
[PATCHv2 1/4 (resent)] gitweb: Load checking
[RFC/PATCHv2 2/4 (resent)] gitweb: Add option to force version match
[PATCHv3 3/4 (resent)] gitweb: Optionally add "git" links in project list page
[PATCHv2/RFC 4/4 (resent)] gitweb: Makefile improvements
> Ok I've been debating this as I've been going through the patches, I've
> got small modifications on top of your patches Jakub for 1 and 2,
> haven't pushed them yet but they are relatively trivial. The changes to
> the first patch sets things up for additional load checkers to be added
> later on.
Good idea, although I think that such addition can be left for a separate
patch.
By the way, are you doing if-elsif fallback chain, trying different
mechanisms (like '/proc/loadavg', BSD::getloadavg, etc.), or did
you made get_loadavg() into code reference, i.e. run it with
$get_loadavg->(), which has the advantage that the gitweb admin can
override it in gitweb config file (including such thing like simply
using load average over last 5 minutes, and not over last minute)?
> The second changes the error message to use/abuse die_error()
> vs. doing it's own thing (though I still think this should be on by
> default).
True, the error message could use improvement (and not only using
its own class instead of abusing 'readme' class, or renaming 'readme'
class to something more generic). The problem with error message for
this is who is the target of this message: is it gitweb administrator
(who can change gitweb configuration), or is it gitweb user (who need
to contact web admin).
The problem with this patch is that for it to be useful for protecting
against silent errors it should be on by default, but OTOH having it on
by default is quite inconvenient.
Best solution would be to treat core of this issue, namely eliminate
silent errors and always provide some message in case of error.
> Patch 4 I don't have anything to add or change at this point.
>
> This patch has me pondering and I'm unsure of what I'd suggest, mainly
> because of the addition of the smart http support meaning that git://
> and http:// are legitimate and useful links for supporting full git
> transactions.
>
> I may withdraw the patch entirely since the link on kernel.org has been
> around for years, and I'm unsure if anything actually uses it (though I
> can see it being useful still). If it stays I think there's got to be a
> way to specifically mark a url as being the one to link to vs.
> defaulting to git:// (or allow for a marking to override the git://) and
> I need to ponder that.
Also, it has to be _fast_, I think, i.e. no reading cloneurl and repo
config (for gitweb.url) for each repository.
You can always remove the check for "git://" prefix, and/or take first
base in @git_base_url_list.
>
> I have given some initial thought to converting the $output options I'm
> currently using to a print <FH> that Jakub is suggesting & exploring.
It's 'print {$fh}', i.e. use indirect filehandle, not global filehandle.
> I think all told it's going to be a similarly sized patch, since all
> output still has to get adjusted (including the things that directly
> output but don't print).
print -> print {$fh} can be separate patch, and it can be checked that
it produces the same results. Well print -> $output .= could also be
separate patch...
> I'm unsure if there's a real advantage to
> either way, other than design preference. My patch (forcing the output
> to get passed around) moves towards more of a modal style design
> separating data & layout vs. it's combined nature now, well it's a step
> in that direction anyway.
Errr... what? Forcing buffering (you need to read whole output into
memory, including for snapshots (uncompressed in case of .tar.gz))
is IMVHO orthogonal to the issue of separating data & layout.
BTW. Modern web server interfaces like Rack, PSGI/Plack etc. explicitly
include streaming support.
The advantage of doing 'print {$fh}' is that $fh can be \*STDOUT, can
be \$buffer, but can be filehandle to (temporary) file on disk, and
you can even "tee" it, i.e. both write to memory/file, and to STDOUT.
The number of possible choices / possible improvements is much larger.
And what is also important it means that people who do not use caching
do not suffer latency penalty and memory pressure from caching
infrastructure they do not use.
P.S.
Subject: [Virus] Exploit.PDF-9669
X-Virus-Scanned: ClamAV 0.88.7/10275/Fri Jan 8 17:06:46 2010 on shards.monkeyblade.net
X-Virus-Status: Infected with Exploit.PDF-9669
X-Original-Subject: Re: [PATCHv3 3/4 (resent)] gitweb: Optionally add "git"
links in project list page
A message sent from <warthog9@eaglescrag.net> to
<jnareb@gmail.com>
<git@vger.kernel.org>
<warthog9@kernel.org>
contained Exploit.PDF-9669 and has not been delivered.
--
Jakub Narebski
Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox