* How to push changes from clone back to master
From: Simon C @ 2010-01-08 21:28 UTC (permalink / raw)
To: git
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
--
View this message in context: http://n2.nabble.com/How-to-push-changes-from-clone-back-to-master-tp4275010p4275010.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Dmitry Potapov @ 2010-01-08 21:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: kusmabite, msysgit, git, Andrzej K. Haczewski
In-Reply-To: <201001082140.36717.j6t@kdbg.org>
On Fri, Jan 08, 2010 at 09:40:36PM +0100, Johannes Sixt wrote:
> On Freitag, 8. Januar 2010, Erik Faye-Lund wrote:
> > On Fri, Jan 8, 2010 at 4:32 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > > AFAIK, Win32 API assumes that reading LONG is always atomic, so
> > > the critical section is not really necesary here, but you need
> > > to declare 'waiters' as 'volatile':
> >
> > "Simple reads and writes to properly-aligned 32-bit variables are
> > atomic operations."
> > http://msdn.microsoft.com/en-us/library/ms684122(VS.85).aspx
> >
> > In other words: Yes, you are right.
>
> Quite frankly, I do not want to stretch this statement to apply to the MinGW
> compiler.
I am sure that MinGW compiler (i.e. gcc) will work fine as long as the
variable is marked as 'volatile'.
> The code in question is not performance critical anyway. I'd prefer
> to leave it as is - it's undergone 2 months of testing already.
Well, it is a strong argument for not change anything, in general, but
the change is trivial -- instead of increment and decrementing some
varaible under a lock, it is increment/decrement using atomic operation.
There is no change to the logic, or anything that can have unexpected
side effects.
> Besides,
> IMHO, it is much more readable the way it is written.
I _completely_ disagree with that. Using atomic operations is not only
more efficient, but it is more readable. Having an additional mutex just
to increment and decrement does not increase readability in any way but
only raises additional questions -- why do you need it here? Is it used
for something else besides incrementing and decrementing the variable,
which can be done atomically?
Dmitry
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Johannes Sixt @ 2010-01-08 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1262122958-9378-10-git-send-email-gitster@pobox.com>
Your implementation forgets to re-insert the forgotten resolutions into
MERGE_RR, therefore, the next 'git rerere' does not record the new
resolution.
In my implementation of 'rerere forget', I had the following tests.
The latter two of the three new tests fail with your implementation.
-- Hannes
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index a6bc028..a3f0c18 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -75,8 +75,9 @@ test_expect_success 'no postimage or thisimage yet' \
test_expect_success 'preimage has right number of lines' '
cnt=$(sed -ne "/^<<<<<<</,/^>>>>>>>/p" $rr/preimage | wc -l) &&
- test $cnt = 13
-
+ test $cnt = 13 &&
+ cnt=$(grep "To die! T" $rr/preimage | wc -l) &&
+ test $cnt = 1
'
git show first:a1 > a1
@@ -142,7 +143,23 @@ test_expect_success 'rerere kicked in' "! grep ^=======$ a1"
test_expect_success 'rerere prefers first change' 'test_cmp a1 expect'
-rm $rr/postimage
+test_expect_success 'rerere forget drops postimage' '
+ git rerere forget a1 &&
+ ! test -f $rr/postimage
+'
+
+test_expect_success 'conflict hash is the same as before' '
+ test $sha1 = "$(perl -pe "s/ .*//" .git/MERGE_RR)"
+'
+
+test_expect_success 'preimage was updated' '
+ cnt=$(sed -ne "/^<<<<<<</,/^>>>>>>>/p" $rr/preimage | wc -l) &&
+ test $cnt = 13 &&
+ cnt=$(grep "To die! T" $rr/preimage | wc -l) &&
+ test $cnt = 2
+'
+
+rm -f $rr/postimage
echo "$sha1 a1" | perl -pe 'y/\012/\000/' > .git/MERGE_RR
test_expect_success 'rerere clear' 'git rerere clear'
^ permalink raw reply related
* unchecked mallocs
From: Marinescu Paul dan @ 2010-01-08 21:59 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <D6F784B72498304C93A8A4691967698E8EE2C45016@REX2.intranet.epfl.ch>
While checking out the git code in xdiff/xpatience.c and xdiff/xmerge.c I
came across several (three) locations where the return values of xdl_malloc
(#defined as malloc) is not checked. Shouldn't this be done here?
In git 1.6.6 the calls are at
xmerge.c:567
merge.c:571
xpatience.c:191
Paul
^ permalink raw reply
* Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Hakim Cassimally @ 2010-01-08 22:29 UTC (permalink / raw)
To: git; +Cc: Sam Vilain
In-Reply-To: <7vzl4qegdm.fsf@alter.siamese.dyndns.org>
(woops, sent just to Junio, resending to list)
Hi,
Thanks for the suggestions, I've tried both those commands, and they
break too :-(
2010/1/7 Junio C Hamano <gitster@pobox.com>:
> Junio C Hamano <gitster@pobox.com> writes:
>> What "cherry-pick" internally does is to run:
>>
>> git merge-recursive 301a^ -- HEAD 301a
>>
>> That is, "We are at HEAD; consolidate the change since 301a^ to 301a into
>> our state, and leave the result in the index and the work tree". Then it
>> commits the result. One thing to try is to see if this gives the same
>> kind of breakage.
$ git merge-recursive 301a^ -- HEAD 301a
# woo! no response! promising
$ git status
# On branch cgi_branch
<snip>
# new file: bin/upload_module.pl
#
# Unmerged paths:
# added by us: www/client/css/admin-clean.css
# added by us: www/client/css/admin.css
<snip dozens of spurious "added by us">
> There actually is another possibility; we used to run inside "cherry-pick"
>
> git merge-resolve 301a^ -- HEAD 301a
>
> instead. The request is the same but it uses a different algorithm, so if
> one fails and one succeeds, that might give us a better clue to figure out
> what is going on.
$ git merge-resolve 301a^ -- HEAD 301a
Trying simple merge.
Simple merge failed, trying Automatic merge.
error: www/client: is a directory - add individual files instead
fatal: Unable to process path www/client
error: www/css: is a directory - add individual files instead
fatal: Unable to process path www/css
error: www/images: is a directory - add individual files instead
fatal: Unable to process path www/images
error: www/js: is a directory - add individual files instead
fatal: Unable to process path www/js
fatal: merge program failed
At least the latter fails more informatively?
Thanks again for the help and suggestions ;-)
osfameron
^ permalink raw reply
* Re: [PATCH 2/3] ident.c: check explicit identity for name and email separately
From: Santi Béjar @ 2010-01-08 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adam Megacz
In-Reply-To: <7vbph4eg63.fsf_-_@alter.siamese.dyndns.org>
On Fri, Jan 8, 2010 at 5:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> bb1ae3f (commit: Show committer if automatic, 2008-05-04) added a logic to
> check both name and email were given explicitly by the end user, but it
> assumed that fmt_ident() is never called before git_default_user_config()
> is called, which was fragile. The former calls setup_ident() and fills
> the "default" name and email, so the check in the config parser would have
> mistakenly said both are given even if only user.name was provided.
>
> Make the logic more robust by keeping track of name and email separately.
>
It's a good improvement, thanks.
Acked-by: Santi Béjar <santi@agolina.net>
Santi
^ permalink raw reply
* [PATCH] string-list: rename the include guard to STRING_LIST_H
From: Thiago Farina @ 2010-01-08 22:45 UTC (permalink / raw)
To: git
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
string-list.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/string-list.h b/string-list.h
index 14bbc47..6569cf6 100644
--- a/string-list.h
+++ b/string-list.h
@@ -1,5 +1,5 @@
-#ifndef PATH_LIST_H
-#define PATH_LIST_H
+#ifndef STRING_LIST_H
+#define STRING_LIST_H
struct string_list_item {
char *string;
@@ -39,4 +39,4 @@ struct string_list_item *string_list_append(const char *string, struct string_li
void sort_string_list(struct string_list *list);
int unsorted_string_list_has_string(struct string_list *list, const char *string);
-#endif /* PATH_LIST_H */
+#endif /* STRING_LIST_H */
--
1.6.6.75.g37bae
^ permalink raw reply related
* [PATCH 1/2] Test update-index for a gitlink to a .git file
From: Brad King @ 2010-01-08 22:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lars Hjemli
In-Reply-To: <1262990208-15554-1-git-send-email-brad.king@kitware.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 0/2] Support relative .git file in a submodule
From: Brad King @ 2010-01-08 22:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lars Hjemli
While experimenting with submodules I discovered that if a submodule
has a .git file "symlink" with a relative path to the real submodule
repository then it cannot be added to the superproject:
$ git init
$ mkdir sub
$ cd sub
$ git init
$ mv .git .real
$ echo 'gitdir: .real' > .git
$ echo a > a
$ git add a
$ git commit -m a
$ cd ..
$ git add sub
fatal: Not a git repository: .real
This patch series adds a test demonstrating the problem, and then
fixes it.
Brad King (2):
Test update-index for a gitlink to a .git file
Handle relative paths in submodule .git files
setup.c | 17 +++++++++++++++++
t/t2104-update-index-gitfile.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 0 deletions(-)
create mode 100755 t/t2104-update-index-gitfile.sh
^ permalink raw reply
* [PATCH 2/2] Handle relative paths in submodule .git files
From: Brad King @ 2010-01-08 22:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lars Hjemli
In-Reply-To: <1262990208-15554-1-git-send-email-brad.king@kitware.com>
Commit 842abf06f36b5b31050db6406265972e3e1cc189 taught
resolve_gitlink_ref() to call read_gitfile_gently() to resolve .git
files. However, read_gitfile_gently() needs to chdir over to the
directory containing the .git file to resolve relative paths correctly.
Signed-off-by: Brad King <brad.king@kitware.com>
---
setup.c | 17 +++++++++++++++++
t/t2104-update-index-gitfile.sh | 2 +-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 2cf0f19..a233e01 100644
--- a/setup.c
+++ b/setup.c
@@ -255,6 +255,8 @@ const char *read_gitfile_gently(const char *path)
struct stat st;
int fd;
size_t len;
+ char cwd[1024] = "";
+ const char *slash;
if (stat(path, &st))
return NULL;
@@ -276,9 +278,24 @@ const char *read_gitfile_gently(const char *path)
if (len < 9)
die("No path in gitfile: %s", path);
buf[len] = '\0';
+
+ slash = strrchr(path, '/');
+ if (slash) {
+ char *dir = xstrndup(path, slash - path);
+ if (!getcwd(cwd, sizeof(cwd)))
+ die_errno ("Could not get current working directory");
+ if (chdir(dir))
+ die_errno ("Could not switch to '%s'", dir);
+ free(dir);
+ }
+
if (!is_git_directory(buf + 8))
die("Not a git repository: %s", buf + 8);
path = make_absolute_path(buf + 8);
+
+ if (*cwd && chdir(cwd))
+ die_errno ("Could not change back to '%s'", cwd);
+
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] ls-files: fix overeager pathspec optimization
From: Junio C Hamano @ 2010-01-08 23:01 UTC (permalink / raw)
To: Jeff King, Linus Torvalds; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vvdfcfjxo.fsf@alter.siamese.dyndns.org>
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 an
unexpected behaviour:
$ git ls-files -o --exclude-standard
$ cd t && git ls-files -o --exclude-standard
junk
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
>> I think a proper fix should be in dir.c::read_directory() where it calls
>> read_directory_recursive() without first checking if the directory itself
>> should be ignored. read_directory_recursive() itself has a logic to see
>> if the dirent it found is worth recursing into and a similar logic should
>> be in the toplevel caller.
So here it is.
dir.c | 37 ++++++++++++++++++++++++++++++++++
t/t3001-ls-files-others-exclude.sh | 39 ++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/dir.c b/dir.c
index f9ac454..9316eb6 100644
--- a/dir.c
+++ b/dir.c
@@ -787,6 +787,40 @@ static void free_simplify(struct path_simplify *simplify)
free(simplify);
}
+static int has_leading_ignored_dir(struct dir_struct *dir,
+ const char *path_, int len,
+ const struct path_simplify *simplify)
+{
+ int at, dtype = DT_DIR;
+ char path[PATH_MAX];
+
+ at = 0;
+ memcpy(path, path_, len);
+ while (1) {
+ char *cp;
+ path[at] = '\0';
+ /*
+ * NOTE! NOTE! NOTE!: we might want to actually lstat(2)
+ * path[] to make sure it is a directory.
+ */
+ if (excluded(dir, path, &dtype))
+ return 1;
+ if (at < len) {
+ path[at] = path_[at];
+ if (at < len && path[at] == '/')
+ at++;
+ }
+ if (len <= at)
+ break;
+ cp = memchr(path + at, '/', len - at);
+ if (!cp)
+ at = len;
+ else
+ at = cp - path;
+ }
+ return 0;
+}
+
int read_directory(struct dir_struct *dir, const char *path, int len, const char **pathspec)
{
struct path_simplify *simplify;
@@ -795,6 +829,9 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
return dir->nr;
simplify = create_simplify(pathspec);
+ if (has_leading_ignored_dir(dir, path, len, simplify))
+ return dir->nr;
+
read_directory_recursive(dir, path, len, 0, simplify);
free_simplify(simplify);
qsort(dir->entries, dir->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 c65bca8..9e71260 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_success '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
* Re: [PATCH 0/2] Support relative .git file in a submodule
From: Junio C Hamano @ 2010-01-08 23:09 UTC (permalink / raw)
To: Brad King; +Cc: git, Lars Hjemli
In-Reply-To: <1262990208-15554-1-git-send-email-brad.king@kitware.com>
Brad King <brad.king@kitware.com> writes:
> ... if a submodule
> has a .git file "symlink" with a relative path to the real submodule
> repository then ...
... then I've always thought that is simply a misconfiguration (t0002
seems to use full path for this exact reason). Is there a reason why
relative path should be used/usable here, other than "being able to is
better than not being able to"???
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.
^ permalink raw reply
* Re: [PATCH 3/3] base85: Make the code more obvious instead of explaining the non-obvious
From: A Large Angry SCM @ 2010-01-08 23:15 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <1262958000-27181-3-git-send-email-agruen@suse.de>
Andreas Gruenbacher wrote:
> Here is another cleanup ...
>
I LOVE the subject line of this commit!
^ permalink raw reply
* [PATCH] sample pre-commit hook: don't trigger when recording a merge
From: Nanako Shiraishi @ 2010-01-08 23:16 UTC (permalink / raw)
To: git
When recording a merge, even if there are problematic whitespace errors,
let them pass, because the damage has already been done in the history. If
this hook triggers, it will invite a novice to fix such errors in a merge
commit but such a change is not related to the merge. Don't encourage it.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
templates/hooks--pre-commit.sample | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/templates/hooks--pre-commit.sample b/templates/hooks--pre-commit.sample
index 439eefd..66e56bb 100755
--- a/templates/hooks--pre-commit.sample
+++ b/templates/hooks--pre-commit.sample
@@ -7,6 +7,11 @@
#
# To enable this hook, rename this file to "pre-commit".
+if test -f "${GIT_DIR-.git}"/MERGE_HEAD
+then
+ exit 0
+fi
+
if git-rev-parse --verify HEAD >/dev/null 2>&1
then
against=HEAD
--
1.6.6
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Junio C Hamano @ 2010-01-08 23:20 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <201001082255.51499.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Your implementation forgets to re-insert the forgotten resolutions into
> MERGE_RR, therefore, the next 'git rerere' does not record the new
> resolution.
>
> In my implementation of 'rerere forget', I had the following tests.
Please filfre to roll a patch that adds the tests and code that inserts
necessary MERGE_RR entries, if the feature is pressing; unfortunately I
don't think I will have much git time during the coming weekend.
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: A Large Angry SCM @ 2010-01-08 23:21 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Avery Pennarun, Junio C Hamano, Nanako Shiraishi,
Johannes Schindelin, git
In-Reply-To: <fabb9a1e1001081237n11fa61b5m63fa46fac2ad8d4a@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> 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*
^ permalink raw reply
* Re: [PATCH 0/2] Support relative .git file in a submodule
From: Avery Pennarun @ 2010-01-08 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brad King, git, Lars Hjemli
In-Reply-To: <7vocl4urc6.fsf@alter.siamese.dyndns.org>
On Fri, Jan 8, 2010 at 6:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brad King <brad.king@kitware.com> writes:
>
>> ... if a submodule
>> has a .git file "symlink" with a relative path to the real submodule
>> repository then ...
>
> ... then I've always thought that is simply a misconfiguration (t0002
> seems to use full path for this exact reason). Is there a reason why
> relative path should be used/usable here, other than "being able to is
> better than not being able to"???
If I have a bunch of git repos in ~/src, and I decide I'd rather
rename it all to ~/source, it seems like it would be nice for all my
links not to be broken. This sort of thing can also happen if you
have NFS-mounted home directories on a farm of machines, and some of
them automount in /u/username and others use /home/username, for
example. I think this is the same reason that common sysadmin advice
is to use relative symlinks instead of absolute links.
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?
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Linus Torvalds @ 2010-01-08 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7veim0w68q.fsf_-_@alter.siamese.dyndns.org>
On Fri, 8 Jan 2010, Junio C Hamano wrote:
>
> 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 an
> unexpected behaviour:
Ok, I'm not sure how "unexpected" this is, since arguably you are
overriding the ignore file by _being_ in that directory (the same way
index contents override ignore files), but I could go either way on that.
Your patch looks fine, although I think you did this in a very odd way.
> + at = 0;
> + memcpy(path, path_, len);
> + while (1) {
> + char *cp;
> + path[at] = '\0';
> + /*
> + * NOTE! NOTE! NOTE!: we might want to actually lstat(2)
> + * path[] to make sure it is a directory.
> + */
> + if (excluded(dir, path, &dtype))
> + return 1;
The above starts by testing the empty string, and then after that test it
goes on to the next directory component. That is just _odd_.
Wouldn't it be more natural to write the loop the other way around, ie
_first_ look up the next directory component, and _then_ do the exclude
processing for thoose components?
Or is there some subtle reason I'm missing for actually checking the empty
name?
Linus
^ permalink raw reply
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Junio C Hamano @ 2010-01-08 23:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Jeff King, Michael J Gruber, Jon Schewe, spearce,
git
In-Reply-To: <alpine.LFD.2.00.1001081520240.7821@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, 8 Jan 2010, Junio C Hamano wrote:
>>
>> 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 an
>> unexpected behaviour:
>
> Ok, I'm not sure how "unexpected" this is, since arguably you are
> overriding the ignore file by _being_ in that directory (the same way
> index contents override ignore files), but I could go either way on that.
>
> Your patch looks fine, although I think you did this in a very odd way.
>
>> + at = 0;
>> + memcpy(path, path_, len);
>> + while (1) {
>> + char *cp;
>> + path[at] = '\0';
>> + /*
>> + * NOTE! NOTE! NOTE!: we might want to actually lstat(2)
>> + * path[] to make sure it is a directory.
>> + */
>> + if (excluded(dir, path, &dtype))
>> + return 1;
>
> The above starts by testing the empty string, and then after that test it
> goes on to the next directory component. That is just _odd_.
>
> Wouldn't it be more natural to write the loop the other way around, ie
> _first_ look up the next directory component, and _then_ do the exclude
> processing for thoose components?
>
> Or is there some subtle reason I'm missing for actually checking the empty
> name?
No, just being paranoid in case somebody managed to .gitignore the
top-level of the working tree ;-)
^ permalink raw reply
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Junio C Hamano @ 2010-01-09 0:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Jeff King, Michael J Gruber, Jon Schewe, spearce,
git
In-Reply-To: <alpine.LFD.2.00.1001081520240.7821@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, 8 Jan 2010, Junio C Hamano wrote:
>>
>> 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 an
>> unexpected behaviour:
>
> Ok, I'm not sure how "unexpected" this is, since arguably you are
> overriding the ignore file by _being_ in that directory (the same way
> index contents override ignore files), but I could go either way on that.
>
> Your patch looks fine, although I think you did this in a very odd way.
Actually, there is some funny interaction with "git add" I ran out of time
to figure out what the right fix should be:
$ git init new
$ cd new
$ mkdir t
$ >kuzu
$ >t/gomi
$ echo t >.gitignore
$ echo kuzu >>.gitignore
$ git add kuzu
The following paths are ignored...
kuzu
Use -f if you really want to add them.
$ git add t/gomi
Since "git add" uses the exact same codepath to find the untracked files
that match the pathspecs, I expected the "fix" will make it complain about
"t/gomi" being ignored. Not so.
Actually, it does start ignoring t/gomi (the index does not have t/gomi
after the above sequence with the patch), but lack of the error message
makes it a rather unfortunate regression---it works as specified in the
sense that ignored paths are not added to the index unless --forced, but
it does so without telling the user about it.
^ permalink raw reply
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Linus Torvalds @ 2010-01-09 0:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7v3a2gnnv2.fsf@alter.siamese.dyndns.org>
On Fri, 8 Jan 2010, Junio C Hamano wrote:
>
> Since "git add" uses the exact same codepath to find the untracked files
> that match the pathspecs, I expected the "fix" will make it complain about
> "t/gomi" being ignored. Not so.
No. Since 't' is ignored, it won't even do a readdir() in there.
And since it didn't do a readdir() in there, it won't find any files in
there to add to the ignored list.
And that's how the "git add" logic for "apparently ignored" files works:
it looks at whether the list of ignored files is empty or not.
> Actually, it does start ignoring t/gomi (the index does not have t/gomi
> after the above sequence with the patch), but lack of the error message
> makes it a rather unfortunate regression---it works as specified in the
> sense that ignored paths are not added to the index unless --forced, but
> it does so without telling the user about it.
I have this memory that _used_ to have a per-filename flag in "git add"
that checked if that particular filename component was used or not. But
now it just looks at 'dir->ignored_nr' and 'dir->ignored[]'.
[ Digging back in history.. Yes: commit e96980ef ]
Linus
^ permalink raw reply
* For real now: bug tracking and secretary tasks in git
From: Jan Krüger @ 2010-01-09 0:38 UTC (permalink / raw)
To: Git ML
I thought about Cc'ing everyone who was involved in previous
discussions about this but that would have been a huge list so I
didn't. No more introductory stuff needed; onwards to the wonderfully
formatted proposal thingy!
I) SUMMARY OF EVERYTHING THAT EVER HAPPENED
-------------------------------------------
Mass consensus in previous discussions[1][2] goes a bit like this:
1. It would be desirable to have people who do the work of interfacing
between bug reporters and developers. These same people could make
sure reports didn't get lost. These people are the *secretaries*.
They should be pretty reliable.
2. People who contribute to git shouldn't be forced to work with the
tracker. Having a tracker that isn't actively maintained by dedicated
secretaries is pretty much worthless anyway, so there's no need to
pretend that forcing developers to use a tracker interface is any
kind of improvement.
3. The "human element" is important. For example, automatic reminders
are a lot less valuable than reminders from an actual person.
II) PROPOSAL
------------
Of course, since I am semi-formally proposing this, I'm also
volunteering to make it happen, BUT I think that no single person can
handle all the list traffic conscientiously enough to do a really good
job. This proposal can only work if more volunteers are found. If you
(and of course I'm speaking to YOU personally now) want to help out,
speak up now!
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.
* To conform to (2) above, tasks are only ever assigned to secretaries.
Whoever assigns a task to himself is responsible for finding someone
to actually get the task done, and to keep that person on his toes.
The bug tracker has features that make this easier (there is no
actual field for "assigned to external entity 'dscho'" in the
interface because there is no bug tracker software that doesn't suck,
but a comment gets the job done, and you can send reminders to
yourself).
* Tasks filed by the general public get pre-screened by secretaries;
worthwhile tasks are (semi-manually, to conform with (3)) forwarded to
this list. The task is updated with summaries of whatever gets
discussed on the list whenever appropriate.
* Tasks get pruned mercilessly to remove anything that is irrelevant,
e.g. comments that do not contribute anything to getting the task
done.
* Things reported to the list get posted to the bug tracker by
secretaries (unless, for example, patches have already been accepted
by a maintainer), in order to be able to keep track of them more
easily. The task contains links to list discussions related to it.
To make it easier for a group of secretaries to collaborate, and for
any interested party to see the progress of a discussion, whenever a
secretary adds a task to the tracker, he replies to the list post
that prompted him to do so, with a subject starting with
"[TASK]" (ideally containing the task's summary line, too) and the URL
of the task in the message body.
Advantages:
* Secretaries don't need to coordinate their activities much. As such,
there can be dozens of secretaries without scalability issues, which
would reduce the workload on each of them.
* People who report things don't have to involve themselves in a
technical discussion that may be completely over their heads. For
example, when Joe Randomuser reports that a certain command does weird
things, he most likely won't want to hear anything about whether the
current strategy for confabulating stochastic index entries in a
distributed manner is error-free, nor does he benefit at all from
getting all that technical stuff delivered to his mailbox.
* People who report things can have more confidence that their report
doesn't get lost in The Noise(tm).
* Git developers don't have to deal with incomplete/nonsensical reports
all if they are submitted to the tracker.
* Git developers can choose themselves how much they want to interact
with the bug tracker.
Disadvantages:
* There is a certain level of redundancy in this approach. It's not
clear to me whether that's a bad thing. I tend to think that it isn't.
III) THIS SECTION IS USELESS
----------------------------
Having section headings for just two sections looked stupid, so here is
another one.
If there are no general objections to the proposal, I will start using
the tracker for tracking less-than-all reports posted to this list.
Whether the tracker really takes off depends on everyone who reads
this... and I'm sure there are lots of great ideas that just didn't
occur to me that you guys can share here.
[1] http://thread.gmane.org/gmane.comp.version-control.git/108109
[2] http://thread.gmane.org/gmane.comp.version-control.git/110117
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 06/11] run-command: add kill_async() and is_async_alive()
From: Erik Faye-Lund @ 2010-01-09 0:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200912022027.23344.j6t@kdbg.org>
On Wed, Dec 2, 2009 at 8:27 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Mittwoch, 2. Dezember 2009, Erik Faye-Lund wrote:
>> On Fri, Nov 27, 2009 at 8:59 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> > "relatively small chance of stuff blowing up"? The docs of
>> > TerminateThread: "... the kernel32 state for the thread's process could
>> > be inconsistent." That's scary if we are talking about a process that
>> > should run for days or weeks without interruption.
>>
>> I think there's a misunderstanding here. I thought your suggestion was
>> to simply call die(), which would take down the main process. After
>> reading this explanation, I think you're talking about giving an error
>> and rejecting the connection instead. Which makes more sense than to
>> risk crashing the main-process, indeed.
>
> Just rejecting a connection is certainly the simplest do to keep the daemon
> process alive. But the server can be DoS-ed from a single source IP.
>
> Currently git-daemon can only be DDoS-ed because there is a maximum number of
> connections, which are not closed if all of them originate from different
> IPs.
>
After some testing I've found that git-daemon can very much be DoS-ed
from a single IP in it's current form. This is for two reasons:
1) The clever xcalloc + memcmp trick has a fault; the port for each
connection is different, so there will never be a match. I have a
patch[1] for this that I plan to send out soon.
2) Even with this patch the effect of the DoS-protection is kind of
limited. This is because it's a child process of the fork()'d process
again that does all the heavy lifting, and kill(pid, SIGHUP) doesn't
kill child processes. So, the connection gets to continue the action
until upload-pack (or whatever the current command is) finish. This
might be quite lengthy.
As I said, I have a patch for 1), but I don't quite know how to fix
2). Perhaps this is a good use for process groups? I'm a Windows-guy;
my POSIX isn't exactly super-awesome...
I found these issues during my latest effort to port git-daemon to
Windows. I managed to get this to work fine on Windows, by
implementing a kill(x, SIGTERM) that terminated child-processes
(because I was under the impression that this was what happened... I
guess daemon.c lead me to believe that).
[1]: http://repo.or.cz/w/git/kusma.git/commit/b1d286d32f42c57b90a1db9b7b8d6775a5d1ad7b
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] ls-files: fix overeager pathspec optimization
From: Junio C Hamano @ 2010-01-09 0:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <alpine.LFD.2.00.1001081619570.7821@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I have this memory that _used_ to have a per-filename flag in "git add"
> that checked if that particular filename component was used or not. But
> now it just looks at 'dir->ignored_nr' and 'dir->ignored[]'.
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.
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. If it
is to be ignored, perhaps it will simply return without doing anything
(normal case), or it will return but adds the path to ignored[]
(DIR_COLLECT_IGNORED case), or it will recurse into itself but tell it
that everything it finds is to be ignored. I dunno...
-- >8 --
Subject: [PATCH (v3)] ls-files: fix overeager pathspec optimization
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 | 36 +++++++++++++++++++++++++++++++++
t/t3001-ls-files-others-exclude.sh | 39 ++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/dir.c b/dir.c
index d0999ba..e8be909 100644
--- a/dir.c
+++ b/dir.c
@@ -778,6 +778,39 @@ static void free_simplify(struct path_simplify *simplify)
free(simplify);
}
+static int has_leading_ignored_dir(struct dir_struct *dir,
+ const char *path_, int len,
+ const struct path_simplify *simplify)
+{
+ int dtype = DT_DIR;
+ char path[PATH_MAX], *cp = path;
+
+ memcpy(path, path_, len);
+ while (1) {
+ char *next = memchr(cp, '/', path + len - cp);
+ int exclude;
+
+ /*
+ * NOTE! NOTE! NOTE!: we might want to actually lstat(2)
+ * path[] to make sure it is a directory.
+ */
+ if (next)
+ *next = '\0';
+ exclude = excluded(dir, path, &dtype);
+ if (next)
+ *next = '/';
+ if (exclude) {
+ if (dir->flags & DIR_COLLECT_IGNORED)
+ dir_add_ignored(dir, path, len);
+ return 1;
+ }
+ if (!next)
+ break;
+ cp = next + 1;
+ }
+ return 0;
+}
+
int read_directory(struct dir_struct *dir, const char *path, int len, const char **pathspec)
{
struct path_simplify *simplify;
@@ -786,6 +819,9 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
return dir->nr;
simplify = create_simplify(pathspec);
+ if (has_leading_ignored_dir(dir, path, len, simplify))
+ return dir->nr;
+
read_directory_recursive(dir, path, len, 0, simplify);
free_simplify(simplify);
qsort(dir->entries, dir->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 c65bca8..9e71260 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_success '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
* 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
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