* Re: [gambit-list] Separating generated files?
From: Santi Béjar @ 2008-10-16 13:29 UTC (permalink / raw)
To: Christian Jaeger
Cc: Michael J Gruber, Matthieu Moy, Nguyen Thai Ngoc Duy,
Git Mailing List, Marc Feeley, Gambit List
In-Reply-To: <48F73463.2050902@pflanze.mine.nu>
On Thu, Oct 16, 2008 at 2:32 PM, Christian Jaeger
<christian@pflanze.mine.nu> wrote:
> Santi Béjar wrote:
>>
>> It looks like the html and man branches of git.git.
>>
>> http://git.kernel.org/?p=git/git.git;a=shortlog;h=html
>> http://git.kernel.org/?p=git/git.git;a=shortlog;h=man
>>
>> They are automatically generated when Junio pushes the branches to
>> kernel.org. Afterwards you can do a "make quick-install-html" and
>> install the preformated html pages from these branches. They are
>> generated with the dodoc.sh script from the todo branch in git.git
>> (look inside for instructions):
>>
>> http://git.kernel.org/?p=git/git.git;a=blob_plain;f=dodoc.sh;hb=todo
>
> This script only generates the html / man branches, it doesn't help find the
> right version for a given git version, right?
Right, one script to generate and one to get the right version.
>
> The differences are:
>
> - the html / man branches have a strictly linear history
Yes, because in this case it is not needed to replicate the whole
history, but it could be improved.
> and are centrally maintained. This solves the distribution issue for end users. But while
> developping the compiler, the developers may need to go back in the history
> of their own development (e.g. when the current compiler doesn't work
> anymore), and the suspected usefulness of being able to see and track
> differences in the generated code also isn't available for a strictly
> central approach.
So, you can divide the problem in two: (a) generated files in the
remote repositories (these can be generated automatically on the
server or in a dedicated server) (b) local generated files for local
commits. If both follow the same format to specify the original commit
you can use the same script to get it.
>
> - the script above is only for creating and committing the derived files, in
> a hook similar to the one I suggested in build/.git/hooks/commit-msg; this
> is the "cd build; git commit -m 'generated files for source repository
> commit
>> `git rev-parse HEAD`'" part; the more interesting part comes from
>> automatically finding the right commit in the generated branches for a given
>> source commit. This is what I intend to solve with the
>> "intergit-find-matching-commit-in" script. Said in a simpler way: the git
>> html / man branches do not offer automatically resolvable linking.
They offer this (Autogenerated HTML docs for v1.6.0.2-530-g67faa) but
there is no script around it.
My point was that there are other project keeping generated files (and
sometimes I would like it too), so you can see what they are doing. At
the end, maybe, you system could be usefull for them also.
Santi
^ permalink raw reply
* Rebasing Multiple branches at once...
From: Rick Moynihan @ 2008-10-16 12:17 UTC (permalink / raw)
To: git
Hi,
I have a master branch, a dev branch and a number of feature branches
from dev. And I was wondering if there was an easy way to rebase dev
and all of it's sub-branches onto master.
I know I can run this as a series of commands, and use --onto to do
this, but was wondering if there was an easier way. As running:
git rebase master
when on the dev branch only rebases dev and not it's dependent branches.
Thanks!
R.
^ permalink raw reply
* Re: Rebasing Multiple branches at once...
From: Miklos Vajna @ 2008-10-16 13:59 UTC (permalink / raw)
To: Rick Moynihan; +Cc: git
In-Reply-To: <48F730D0.9040008@calicojack.co.uk>
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
On Thu, Oct 16, 2008 at 01:17:20PM +0100, Rick Moynihan <rick@calicojack.co.uk> wrote:
> I have a master branch, a dev branch and a number of feature branches from
> dev. And I was wondering if there was an easy way to rebase dev and all of
> it's sub-branches onto master.
In general this is considered harmful. Why do you rebase your branch
from time to time? For example in git.git, topic branches are based on
master, then merged to master when they are ready, but they are never
rebased.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Rebasing Multiple branches at once...
From: David Kastrup @ 2008-10-16 13:59 UTC (permalink / raw)
To: git
In-Reply-To: <48F730D0.9040008@calicojack.co.uk>
Rick Moynihan <rick@calicojack.co.uk> writes:
> Hi,
>
> I have a master branch, a dev branch and a number of feature branches
> from dev. And I was wondering if there was an easy way to rebase dev
> and all of it's sub-branches onto master.
>
> I know I can run this as a series of commands, and use --onto to do
> this, but was wondering if there was an easier way. As running:
>
> git rebase master
>
> when on the dev branch only rebases dev and not it's dependent branches.
Rebasing has no relation to dependent branches. It creates a new branch
from the branch point. After it finishes, it just reseats HEAD of the
branch to the new one. There is no operation that would work implicitly
on originally dependent branches.
--
David Kastrup
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Jeff King @ 2008-10-16 14:18 UTC (permalink / raw)
To: Lars Hoss; +Cc: Johannes Sixt, Pedro Melo, Pieter de Bie, Git Mailinglist
In-Reply-To: <8199b7ae4c441c4311045141ddaaa36f.squirrel@webmail.highteq.net>
On Thu, Oct 16, 2008 at 02:30:00PM +0200, Lars Hoss wrote:
> The commit was on Jun 5, 14:47:50 by Marius Storm-Olsen and the relevant
> file is wt-status.c.
>
> Ok, I think I found the issue. I enabled showUntrackedFiles in my gitconfig:
>
> status.showUntrackedFiles = all
Ah, OK. I see what is going on. All code paths call the read_directory
infrastructure to find untracked files. If status.showUntrackedFiles is
"normal", then we set dir.show_other_directories, to indicate that we
want to see the directories, but not their constituent files.
If status.showuntrackedfiles is set to "all", then we don't set the
show_other_directories flag, because we want each file. But the code in
dir.c:treat_directory uses the "show_other_directories" flag to say "oh,
we're just interested in untracked files" and decide whether to ignore
gitlinks.
Meaning that we must still filter the results of read_directory based on
the cache. And indeed, this is what "git ls-files -o" does, as explained
in 5698454e (Fix some "git ls-files -o" fallout from gitlinks). It's
also what the code in wt_status_print_untracked is _supposed_ to do, but
it was never updated to handle this case when git-ls-files was. Which is
probably my fault a long time ago for cutting and pasting the 5 lines of
"is this thing in the cache" when writing wt-status.c.
So the quick fix is to re-cut-and-paste the code:
diff --git a/wt-status.c b/wt-status.c
index d2eac36..792d5f1 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -280,10 +280,14 @@ static void wt_status_print_untracked(struct wt_status *s)
/* check for matching entry, which is unmerged; lifted from
* builtin-ls-files:show_other_files */
struct dir_entry *ent = dir.entries[i];
- int pos = cache_name_pos(ent->name, ent->len);
+ int len, pos;
+ len = ent->len;
+ if (len && ent->name[len-1] == '/')
+ len--;
+ pos = cache_name_pos(ent->name, len);
struct cache_entry *ce;
if (0 <= pos)
- die("bug in wt_status_print_untracked");
+ continue;
pos = -pos - 1;
if (pos < active_nr) {
ce = active_cache[pos];
But the right solution is to refactor this so the code isn't duplicated.
And I'll post a patch for that in a second.
I do have to wonder, though, whether an even better solution would be to
more explicitly tell read_directory "I'm interested only in 'other'
files" rather than relying on guessing based on
dir.show_other_directories. Then we could just avoid ever passing these
gitlinks back to ls-files and status in the first place.
-Peff
^ permalink raw reply related
* Re: Rebasing Multiple branches at once...
From: Rick Moynihan @ 2008-10-16 14:48 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20081016135908.GI536@genesis.frugalware.org>
Miklos Vajna wrote:
> On Thu, Oct 16, 2008 at 01:17:20PM +0100, Rick Moynihan <rick@calicojack.co.uk> wrote:
>> I have a master branch, a dev branch and a number of feature branches from
>> dev. And I was wondering if there was an easy way to rebase dev and all of
>> it's sub-branches onto master.
>
> In general this is considered harmful. Why do you rebase your branch
> from time to time? For example in git.git, topic branches are based on
> master, then merged to master when they are ready, but they are never
> rebased.
Yes, but my understanding is that it's only harmful if you publish the
branch (or dependent branches) which are being rebased.
So rebasing is very bad in these circumstances, but I fail to see why
it's bad if these branches are kept private.
R.
^ permalink raw reply
* Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Junio C Hamano @ 2008-10-16 14:49 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linus Torvalds, Andrew Morton, david, Git Mailing List
In-Reply-To: <20081016072010.GA19188@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> Does your fix mean that all i have to do in the future is a hard reset
> back to HEAD, and that dangling files are not supposed to stay around?
As long as the index *somehow* knows about these new files, they are
removed.
The situation is:
(0) you start from a HEAD that does not have path xyzzy;
(1) you attempt to merge a rev that has path xyzzy;
(2) the merge conflicts, leaving higher staged index entries for the
path.
(3) you decide not to conclude the merge by saying "reset --hard".
The old logic for "reset" was to remove paths that exist in the index at
stage #0 (i.e. cleanly merged) and not in HEAD. The patch changes the
rule to remove paths that exist in the index at any stage (i.e. including
the ones that have conflicted and not resolved yet) and not in HEAD.
^ permalink raw reply
* Re: Rebasing Multiple branches at once...
From: Rick Moynihan @ 2008-10-16 14:57 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <8663nsfxoq.fsf@lola.quinscape.zz>
David Kastrup wrote:
> Rick Moynihan <rick@calicojack.co.uk> writes:
>
>> Hi,
>>
>> I have a master branch, a dev branch and a number of feature branches
>> from dev. And I was wondering if there was an easy way to rebase dev
>> and all of it's sub-branches onto master.
>>
>> I know I can run this as a series of commands, and use --onto to do
>> this, but was wondering if there was an easier way. As running:
>>
>> git rebase master
>>
>> when on the dev branch only rebases dev and not it's dependent branches.
>
> Rebasing has no relation to dependent branches. It creates a new branch
> from the branch point. After it finishes, it just reseats HEAD of the
> branch to the new one. There is no operation that would work implicitly
> on originally dependent branches.
This appears to be true of the current implementation, but shouldn't it
be possible to do this as a single operation?
e.g. when the situation is this with dev being the current branch.
o---o---o---o---o master
\
o---o---o---o---o dev (*)
\
o---o---o topic
Running the hypothetical command:
git rebase master --all
Would produce this:
o---o---o---o---o master
\
o---o---o---o---o dev (*)
\
o---o---o topic
I think this can be performed right now with a rebase followed by a
rebase --onto
I can see how if there were conflicts in the rebase from dev, then you
would need to resolve them all the way up your topic branches also. Is
there anything else that makes this a bad idea?
R.
^ permalink raw reply
* [PATCH] refactor handling of "other" files in ls-files and status
From: Jeff King @ 2008-10-16 14:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Lars Hoss, Johannes Sixt, Pedro Melo, Pieter de Bie,
Git Mailinglist
In-Reply-To: <20081016141812.GA30026@sigill.intra.peff.net>
When the "git status" display code was originally converted
to C, we copied the code from ls-files to discover whether a
pathname returned by read_directory was an "other", or
untracked, file.
Much later, 5698454e updated the code in ls-files to handle
some new cases caused by gitlinks. This left the code in
wt-status.c broken: it would display submodule directories
as untracked directories. Nobody noticed until now, however,
because unless status.showUntrackedFiles was set to "all",
submodule directories were not actually reported by
read_directory. So the bug was only triggered in the
presence of a submodule _and_ this config option.
This patch pulls the ls-files code into a new function,
cache_name_is_other, and uses it in both places. This should
leave the ls-files functionality the same and fix the bug
in status.
Signed-off-by: Jeff King <peff@peff.net>
---
On Thu, Oct 16, 2008 at 10:18:13AM -0400, Jeff King wrote:
> But the right solution is to refactor this so the code isn't duplicated.
> And I'll post a patch for that in a second.
Here it is.
> I do have to wonder, though, whether an even better solution would be to
> more explicitly tell read_directory "I'm interested only in 'other'
> files" rather than relying on guessing based on
> dir.show_other_directories. Then we could just avoid ever passing these
> gitlinks back to ls-files and status in the first place.
I was thinking such a change would get rid of the need for my patch,
since all files returned _would_ be "others". However, we would still
need to deal with the "unmerged entries" problem, so I think this
refactoring is worth it regardless.
builtin-ls-files.c | 33 ++-------------------------------
cache.h | 2 ++
read-cache.c | 27 +++++++++++++++++++++++++++
t/t7502-status.sh | 6 ++++++
wt-status.c | 15 ++-------------
5 files changed, 39 insertions(+), 44 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 068f424..b48327d 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -91,39 +91,10 @@ static void show_other_files(struct dir_struct *dir)
{
int i;
-
- /*
- * Skip matching and unmerged entries for the paths,
- * since we want just "others".
- *
- * (Matching entries are normally pruned during
- * the directory tree walk, but will show up for
- * gitlinks because we don't necessarily have
- * dir->show_other_directories set to suppress
- * them).
- */
for (i = 0; i < dir->nr; i++) {
struct dir_entry *ent = dir->entries[i];
- int len, pos;
- struct cache_entry *ce;
-
- /*
- * Remove the '/' at the end that directory
- * walking adds for directory entries.
- */
- len = ent->len;
- if (len && ent->name[len-1] == '/')
- len--;
- pos = cache_name_pos(ent->name, len);
- if (0 <= pos)
- continue; /* exact match */
- pos = -pos - 1;
- if (pos < active_nr) {
- ce = active_cache[pos];
- if (ce_namelen(ce) == len &&
- !memcmp(ce->name, ent->name, len))
- continue; /* Yup, this one exists unmerged */
- }
+ if (!cache_name_is_other(ent->name, ent->len))
+ continue;
show_dir_entry(tag_other, ent);
}
}
diff --git a/cache.h b/cache.h
index 991544c..ae6647e 100644
--- a/cache.h
+++ b/cache.h
@@ -277,6 +277,7 @@ static inline void remove_name_hash(struct cache_entry *ce)
#define ce_match_stat(ce, st, options) ie_match_stat(&the_index, (ce), (st), (options))
#define ce_modified(ce, st, options) ie_modified(&the_index, (ce), (st), (options))
#define cache_name_exists(name, namelen, igncase) index_name_exists(&the_index, (name), (namelen), (igncase))
+#define cache_name_is_other(name, namelen) index_name_is_other(&the_index, (name), (namelen))
#endif
enum object_type {
@@ -393,6 +394,7 @@ extern int add_to_index(struct index_state *, const char *path, struct stat *, i
extern int add_file_to_index(struct index_state *, const char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
+extern int index_name_is_other(const struct index_state *, const char *, int);
/* do stat comparison even if CE_VALID is true */
#define CE_MATCH_IGNORE_VALID 01
diff --git a/read-cache.c b/read-cache.c
index c229fd4..780f2c7 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1565,3 +1565,30 @@ int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
return !!data.add_errors;
}
+/*
+ * Returns 1 if the path is an "other" path with respect to
+ * the index; that is, the path is not mentioned in the index at all,
+ * either as a file, a directory with some files in the index,
+ * or as an unmerged entry.
+ *
+ * We helpfully remove a trailing "/" from directories so that
+ * the output of read_directory can be used as-is.
+ */
+int index_name_is_other(const struct index_state *istate, const char *name,
+ int namelen)
+{
+ int pos;
+ if (namelen && name[namelen - 1] == '/')
+ namelen--;
+ pos = index_name_pos(istate, name, namelen);
+ if (0 <= pos)
+ return 0; /* exact match */
+ pos = -pos - 1;
+ if (pos < istate->cache_nr) {
+ struct cache_entry *ce = istate->cache[pos];
+ if (ce_namelen(ce) == namelen &&
+ !memcmp(ce->name, name, namelen))
+ return 0; /* Yup, this one exists unmerged */
+ }
+ return 1;
+}
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
index 1905fb3..93f875f 100755
--- a/t/t7502-status.sh
+++ b/t/t7502-status.sh
@@ -292,6 +292,12 @@ test_expect_success 'status submodule summary is disabled by default' '
test_cmp expect output
'
+# we expect the same as the previous test
+test_expect_success 'status --untracked-files=all does not show submodule' '
+ git status --untracked-files=all >output &&
+ test_cmp expect output
+'
+
head=$(cd sm && git rev-parse --short=7 --verify HEAD)
cat >expect <<EOF
diff --git a/wt-status.c b/wt-status.c
index d2eac36..c3a9cab 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -277,20 +277,9 @@ static void wt_status_print_untracked(struct wt_status *s)
read_directory(&dir, ".", "", 0, NULL);
for(i = 0; i < dir.nr; i++) {
- /* check for matching entry, which is unmerged; lifted from
- * builtin-ls-files:show_other_files */
struct dir_entry *ent = dir.entries[i];
- int pos = cache_name_pos(ent->name, ent->len);
- struct cache_entry *ce;
- if (0 <= pos)
- die("bug in wt_status_print_untracked");
- pos = -pos - 1;
- if (pos < active_nr) {
- ce = active_cache[pos];
- if (ce_namelen(ce) == ent->len &&
- !memcmp(ce->name, ent->name, ent->len))
- continue;
- }
+ if (!cache_name_is_other(ent->name, ent->len))
+ continue;
if (!shown_header) {
s->workdir_untracked = 1;
wt_status_print_untracked_header(s);
--
1.6.0.2.710.gc3f34.dirty
^ permalink raw reply related
* Re: Rebasing Multiple branches at once...
From: Robin Burchell @ 2008-10-16 15:02 UTC (permalink / raw)
To: Rick Moynihan; +Cc: David Kastrup, git
In-Reply-To: <48F75657.6010308@calicojack.co.uk>
On Thu, Oct 16, 2008 at 3:57 PM, Rick Moynihan <rick@calicojack.co.uk> wrote:
>
> This appears to be true of the current implementation, but shouldn't it be
> possible to do this as a single operation?
>
> e.g. when the situation is this with dev being the current branch.
>
> o---o---o---o---o master
> \
> o---o---o---o---o dev (*)
> \
> o---o---o topic
>
> Running the hypothetical command:
>
> git rebase master --all
>
> Would produce this:
>
> o---o---o---o---o master
> \
> o---o---o---o---o dev (*)
> \
> o---o---o topic
>
> I think this can be performed right now with a rebase followed by a rebase
> --onto
>
> I can see how if there were conflicts in the rebase from dev, then you would
> need to resolve them all the way up your topic branches also. Is there
> anything else that makes this a bad idea?
>
> R.
Rebase is indeed useful IMHO in situations like this with multiple
related topic branches when needing to pull a single fix or two from
somewhere without messy merges (especially when that will end up with
rather a lot of merge commits in history - one or so for each branch,
which is not exactly desirable).
(resent after I learned how to use 'reply to all', sorry Rick)
^ permalink raw reply
* Re: [PATCH] refactor handling of "other" files in ls-files and status
From: Jeff King @ 2008-10-16 15:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailinglist
In-Reply-To: <20081016145916.GA31859@sigill.intra.peff.net>
On Thu, Oct 16, 2008 at 10:59:16AM -0400, Jeff King wrote:
> This patch pulls the ls-files code into a new function,
> cache_name_is_other, and uses it in both places. This should
> leave the ls-files functionality the same and fix the bug
> in status.
BTW, this is probably maint-worthy, but I prepared it on 'master'.
Unfortunately, there is a purely textual conflict when applying to
maint. For your convenience, here's a rebase to maint:
-- >8 --
refactor handling of "other" files in ls-files and status
When the "git status" display code was originally converted
to C, we copied the code from ls-files to discover whether a
pathname returned by read_directory was an "other", or
untracked, file.
Much later, 5698454e updated the code in ls-files to handle
some new cases caused by gitlinks. This left the code in
wt-status.c broken: it would display submodule directories
as untracked directories. Nobody noticed until now, however,
because unless status.showUntrackedFiles was set to "all",
submodule directories were not actually reported by
read_directory. So the bug was only triggered in the
presence of a submodule _and_ this config option.
This patch pulls the ls-files code into a new function,
cache_name_is_other, and uses it in both places. This should
leave the ls-files functionality the same and fix the bug
in status.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-ls-files.c | 33 ++-------------------------------
cache.h | 2 ++
read-cache.c | 28 ++++++++++++++++++++++++++++
t/t7502-status.sh | 6 ++++++
wt-status.c | 15 ++-------------
5 files changed, 40 insertions(+), 44 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 068f424..b48327d 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -91,39 +91,10 @@ static void show_other_files(struct dir_struct *dir)
{
int i;
-
- /*
- * Skip matching and unmerged entries for the paths,
- * since we want just "others".
- *
- * (Matching entries are normally pruned during
- * the directory tree walk, but will show up for
- * gitlinks because we don't necessarily have
- * dir->show_other_directories set to suppress
- * them).
- */
for (i = 0; i < dir->nr; i++) {
struct dir_entry *ent = dir->entries[i];
- int len, pos;
- struct cache_entry *ce;
-
- /*
- * Remove the '/' at the end that directory
- * walking adds for directory entries.
- */
- len = ent->len;
- if (len && ent->name[len-1] == '/')
- len--;
- pos = cache_name_pos(ent->name, len);
- if (0 <= pos)
- continue; /* exact match */
- pos = -pos - 1;
- if (pos < active_nr) {
- ce = active_cache[pos];
- if (ce_namelen(ce) == len &&
- !memcmp(ce->name, ent->name, len))
- continue; /* Yup, this one exists unmerged */
- }
+ if (!cache_name_is_other(ent->name, ent->len))
+ continue;
show_dir_entry(tag_other, ent);
}
}
diff --git a/cache.h b/cache.h
index 884fae8..76730ce 100644
--- a/cache.h
+++ b/cache.h
@@ -270,6 +270,7 @@ static inline void remove_name_hash(struct cache_entry *ce)
#define ce_match_stat(ce, st, options) ie_match_stat(&the_index, (ce), (st), (options))
#define ce_modified(ce, st, options) ie_modified(&the_index, (ce), (st), (options))
#define cache_name_exists(name, namelen, igncase) index_name_exists(&the_index, (name), (namelen), (igncase))
+#define cache_name_is_other(name, namelen) index_name_is_other(&the_index, (name), (namelen))
#endif
enum object_type {
@@ -382,6 +383,7 @@ extern int add_to_index(struct index_state *, const char *path, struct stat *, i
extern int add_file_to_index(struct index_state *, const char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
+extern int index_name_is_other(const struct index_state *, const char *, int);
/* do stat comparison even if CE_VALID is true */
#define CE_MATCH_IGNORE_VALID 01
diff --git a/read-cache.c b/read-cache.c
index 8f96fd1..4e067e4 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1480,3 +1480,31 @@ int read_index_unmerged(struct index_state *istate)
istate->cache_nr = dst - istate->cache;
return !!last;
}
+
+/*
+ * Returns 1 if the path is an "other" path with respect to
+ * the index; that is, the path is not mentioned in the index at all,
+ * either as a file, a directory with some files in the index,
+ * or as an unmerged entry.
+ *
+ * We helpfully remove a trailing "/" from directories so that
+ * the output of read_directory can be used as-is.
+ */
+int index_name_is_other(const struct index_state *istate, const char *name,
+ int namelen)
+{
+ int pos;
+ if (namelen && name[namelen - 1] == '/')
+ namelen--;
+ pos = index_name_pos(istate, name, namelen);
+ if (0 <= pos)
+ return 0; /* exact match */
+ pos = -pos - 1;
+ if (pos < istate->cache_nr) {
+ struct cache_entry *ce = istate->cache[pos];
+ if (ce_namelen(ce) == namelen &&
+ !memcmp(ce->name, name, namelen))
+ return 0; /* Yup, this one exists unmerged */
+ }
+ return 1;
+}
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
index c8e4c2e..187a13e 100755
--- a/t/t7502-status.sh
+++ b/t/t7502-status.sh
@@ -285,6 +285,12 @@ test_expect_success 'status submodule summary is disabled by default' '
test_cmp expect output
'
+# we expect the same as the previous test
+test_expect_success 'status --untracked-files=all does not show submodule' '
+ git status --untracked-files=all >output &&
+ test_cmp expect output
+'
+
head=$(cd sm && git rev-parse --short=7 --verify HEAD)
cat >expect <<EOF
diff --git a/wt-status.c b/wt-status.c
index 889e50f..64cedfc 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -275,20 +275,9 @@ static void wt_status_print_untracked(struct wt_status *s)
read_directory(&dir, ".", "", 0, NULL);
for(i = 0; i < dir.nr; i++) {
- /* check for matching entry, which is unmerged; lifted from
- * builtin-ls-files:show_other_files */
struct dir_entry *ent = dir.entries[i];
- int pos = cache_name_pos(ent->name, ent->len);
- struct cache_entry *ce;
- if (0 <= pos)
- die("bug in wt_status_print_untracked");
- pos = -pos - 1;
- if (pos < active_nr) {
- ce = active_cache[pos];
- if (ce_namelen(ce) == ent->len &&
- !memcmp(ce->name, ent->name, ent->len))
- continue;
- }
+ if (!cache_name_is_other(ent->name, ent->len))
+ continue;
if (!shown_header) {
s->workdir_untracked = 1;
wt_status_print_header(s, "Untracked files",
--
1.6.0.2.710.gc3f34.dirty
^ permalink raw reply related
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Brandon Casey @ 2008-10-16 15:21 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Arjen Laarhoven, Shawn O. Pearce,
Mike Ralphson
In-Reply-To: <20081016100805.GA20762@sigill.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 15, 2008 at 10:35:30AM -0500, Brandon Casey wrote:
>
>> 2) Do we want to stick with compat/regex on
>>
>> Darwin: Arjen
>> FreeBSD: Jeff
>> AIX: Mike
>>
>> now that the builtin funcname patterns have been converted to Extended
>> Regular Expressions?
>
> t4018 passes without compat/regex on FreeBSD. Is that a sufficient test?
I think so. t4018 makes sure all the patterns compile, and includes Arjen's test
for appropriate handling of the alternation operator.
Darwin, anyone?
-brandon
^ permalink raw reply
* Re: Usability of git stash
From: Brandon Casey @ 2008-10-16 15:22 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86vdvsg4up.fsf@lola.quinscape.zz>
David Kastrup wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Anders Melchiorsen wrote:
>>
>>> When trying to recover from that scenario, I do "git stash apply" as
>>> recommended by the "git stash" output. Now I still lost my index
>>> state, all changes are unstaged.
>> See the documentation, apply has a '--index' option.
>
> Still, the shoot-yourself-in-the-foot potential is quite larger than
> appropriate for what is mostly workflow porcelaine. It is even larger
> than appropriate for plumbing IMHO.
I think it is excessive to call the action taken by 'git stash', when it
is unwanted, "shoot[ing]-yourself-in-the-foot". More like stub-your-toe.
In exchange for allowing new users to stub their toe on new commands, the
work flow of more experienced users is made a little easier.
> I mean, even misspellings like
> git stash lisp
>
> cause action that is not easily reversible, and the given help output is
> misleading with regard to index state.
$ git stash lisp
Usage: git stash list [<options>]
or: git stash (show | drop | pop ) [<stash>]
or: git stash apply [--index] [<stash>]
or: git stash branch <branchname> [<stash>]
or: git stash [save [--keep-index] [<message>]]
or: git stash clear
Maybe you are referring to the long since changed behavior where
'git stash' == 'git stash save' and so "lisp" in your example
would have been taken as a stash description. This behavior existed
for less than 6 months, and has been changed now for over 10 months.
-brandon
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Thomas Rast @ 2008-10-16 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wsq7rt5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
You wrote:
> * tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
> + Documentation: Refer to git-rebase(1) to warn against rewriting
> + Documentation: new upstream rebase recovery section in git-rebase
>
> Shawn says that an update came in recently, but they are not here yet.
> I'd need to dig it up, but I haven't had time.
The one you commented on was the last iteration. I hope to find the
time to reroll the next (perhaps final) iteration this weekend.
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git and filesystem problems (ext3 and vfat)
From: Ian Brown @ 2008-10-16 16:03 UTC (permalink / raw)
To: git
Hello, ]
I have a diskOnKey which has a vfat filesystem.
I ran there:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
the I copied all the wireless-2.6 folder to an ext3 partition.
There I ran git diff.
I get many messages like these (probably on all files of the repository):
diff --git a/COPYING b/COPYING
deleted file mode 100644
index ca442d3..0000000
--- a/COPYING
+++ /dev/null
@@ -1,356 +0,0 @@
-
and then all the lines of the file with "-" in the beginning, as if
they are empty.
Why is it so ?
Is there any way to overcome it ?
Must I run "git clone" on an ext3 DiskOnKey only ?
Regards,
Ian
^ permalink raw reply related
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Pieter de Bie @ 2008-10-16 15:37 UTC (permalink / raw)
To: Brandon Casey
Cc: Jeff King, Junio C Hamano, git, Arjen Laarhoven, Shawn O. Pearce,
Mike Ralphson
In-Reply-To: <0my5lujnbpdG6sxrffMExwukINu2tasxBSH0E0xYQoe6y5yyFL0LNA@cipher.nrlssc.navy.mil>
On 16 okt 2008, at 17:21, Brandon Casey wrote:
> Darwin, anyone?
'maint' passes for me on Darwin (OS X Leopard) after removing the
regex stuff in Makefile
- Pieter
^ permalink raw reply
* Re: git and filesystem problems (ext3 and vfat)
From: Michael J Gruber @ 2008-10-16 16:17 UTC (permalink / raw)
To: Ian Brown; +Cc: git
In-Reply-To: <d0383f90810160903p6f8ffe77o86fdad5387f82481@mail.gmail.com>
Ian Brown venit, vidit, dixit 16.10.2008 18:03:
> Hello, ]
>
> I have a diskOnKey which has a vfat filesystem.
> I ran there:
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> the I copied all the wireless-2.6 folder to an ext3 partition.
How did you copy it?
> There I ran git diff.
>
> I get many messages like these (probably on all files of the repository):
>
> diff --git a/COPYING b/COPYING
> deleted file mode 100644
> index ca442d3..0000000
> --- a/COPYING
> +++ /dev/null
> @@ -1,356 +0,0 @@
> -
>
> and then all the lines of the file with "-" in the beginning, as if
> they are empty.
>
> Why is it so ?
> Is there any way to overcome it ?
> Must I run "git clone" on an ext3 DiskOnKey only ?
git diff gives you the difference between the index and the work tree.
The index is the one you copied from vfat; git doesn't see the files on
the ext3 work tree. Do you see them with ls?
One by one I would try
git status
git reset
git reset --hard
in order to reconcile your index with your checkout. You probably need
the last one.
Michael
^ permalink raw reply
* Re: git and filesystem problems (ext3 and vfat)
From: David Tweed @ 2008-10-16 16:22 UTC (permalink / raw)
To: Ian Brown; +Cc: git
In-Reply-To: <d0383f90810160903p6f8ffe77o86fdad5387f82481@mail.gmail.com>
On Thu, Oct 16, 2008 at 5:03 PM, Ian Brown <ianbrn@gmail.com> wrote:
> Hello, ]
>
> I have a diskOnKey which has a vfat filesystem.
> I ran there:
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> the I copied all the wireless-2.6 folder to an ext3 partition.
> There I ran git diff.
>
> I get many messages like these (probably on all files of the repository):
>
> diff --git a/COPYING b/COPYING
> deleted file mode 100644
> index ca442d3..0000000
> --- a/COPYING
> +++ /dev/null
> @@ -1,356 +0,0 @@
> -
>
> and then all the lines of the file with "-" in the beginning, as if
> they are empty.
The first question is what do the directories on the vfat and ext3
disks look like? Are the files like COPYING present in both directory
trees (so git is wrong at that point of the diff) or has something
gone wrong earlier?
> Why is it so ?
> Is there any way to overcome it ?
> Must I run "git clone" on an ext3 DiskOnKey only ?
I have certainly cloned onto a vfat partition with no problems,
although I've always done it with a --bare clone because a lot of my
repos have had case sensitive filenames and I've had some problems
with the "git dirent reading code reads back different case file names
than it wrote out and gets confused". If you're only transporting the
repo on the stick, I'd definitely do it via "git clone --bare" just to
reduce the potential for problems.
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
^ permalink raw reply
* Re: git and filesystem problems (ext3 and vfat)
From: Ian Brown @ 2008-10-16 16:23 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48F76936.3010801@drmicha.warpmail.net>
Hello,
Thanks for you quick answer.
ls shows the files.
git status shows:
fatal: Not a git repository
Regards,
IB
On Thu, Oct 16, 2008 at 6:17 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ian Brown venit, vidit, dixit 16.10.2008 18:03:
>> Hello, ]
>>
>> I have a diskOnKey which has a vfat filesystem.
>> I ran there:
>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
>> the I copied all the wireless-2.6 folder to an ext3 partition.
>
> How did you copy it?
>
>> There I ran git diff.
>>
>> I get many messages like these (probably on all files of the repository):
>>
>> diff --git a/COPYING b/COPYING
>> deleted file mode 100644
>> index ca442d3..0000000
>> --- a/COPYING
>> +++ /dev/null
>> @@ -1,356 +0,0 @@
>> -
>>
>> and then all the lines of the file with "-" in the beginning, as if
>> they are empty.
>>
>> Why is it so ?
>> Is there any way to overcome it ?
>> Must I run "git clone" on an ext3 DiskOnKey only ?
>
> git diff gives you the difference between the index and the work tree.
> The index is the one you copied from vfat; git doesn't see the files on
> the ext3 work tree. Do you see them with ls?
>
> One by one I would try
>
> git status
> git reset
> git reset --hard
>
> in order to reconcile your index with your checkout. You probably need
> the last one.
>
> Michael
>
^ permalink raw reply
* Re: git and filesystem problems (ext3 and vfat)
From: David Tweed @ 2008-10-16 16:33 UTC (permalink / raw)
To: Ian Brown; +Cc: Michael J Gruber, git
In-Reply-To: <d0383f90810160923m60ec95d8v8550a611f91176b6@mail.gmail.com>
On Thu, Oct 16, 2008 at 5:23 PM, Ian Brown <ianbrn@gmail.com> wrote:
> Hello,
> Thanks for you quick answer.
>
> ls shows the files.
I'm assuming this is on both the vfat and ext3 disks? All the
filenames' cases are correct?
> git status shows:
> fatal: Not a git repository
> Regards,
> IB
The error message unfortunately really means "git couldn't find
_everything_ needed to be a repository" without saying what precisely
it had problems finding. Educated guess: Have a look in the .git
directory on each disk. Is there a file called 'HEAD' or has its case
been changed?
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
^ permalink raw reply
* Re: git-svnimport.perl bug when copy source path has a revision
From: Karl Chen @ 2008-10-16 18:36 UTC (permalink / raw)
To: Pete Harlan; +Cc: Git mailing list
In-Reply-To: <48F6E29F.1050807@pcharlan.com>
>>>>> On 2008-10-15 23:43 PDT, Pete Harlan writes:
Pete> git svn init -T trunk -t tags $R git svn fetch git log
Pete> tags/mytag
Thanks for the pointer. I do know about git-svn and used it
to convert most of my repositories, but one particular repository
isn't converting with git-svn - it runs for hours before I cancel
it, whereas git-svnimport completes in minutes.
^ permalink raw reply
* Re: [Q] "status" of files in (a part of) the working tree
From: Jeff King @ 2008-10-16 18:44 UTC (permalink / raw)
To: Brian Foster; +Cc: Git Mailing List
In-Reply-To: <200810150953.42279.brian.foster@innova-card.com>
On Wed, Oct 15, 2008 at 09:53:42AM +0200, Brian Foster wrote:
> For every file in a directory of my working tree,
> I want to obtain a quick "status" summary (ideally,
> recursively, i.e. descending into each sub-directory):
> E.g., not-tracked, latest modification is not in
> the index, latest modification is in the index,
> not-modified, and so on. As a hypothetical example
> (`# comments' added to explain what the line means):
>
> $ git some-cmd
> ? foo # not-tracked
> - bar # tracked, not-modified
> M xyzzy # tracked, last modification not-in-index
> I plover # tracked, last modification in-the-index
> ...
> $
Check out this thread:
http://thread.gmane.org/gmane.comp.version-control.git/97830/focus=98041
Hopefully Shawn will unveil his tool soon, and I expect there may be
some discussion about the preferred format.
-Peff
^ permalink raw reply
* Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-16 18:17 UTC (permalink / raw)
To: git
Hi all,
We're a Subversion shop moving to git, and our git-fu is still pretty
weak. So I'd appreciate feedback on the setup I'm going to describe, in
addition to the specific issue I'm going to raise.
Our products involve extensive customization of various
externally-maintained code bases (mainly in FreeBSD, but also in a few
other projects too). We'd like to track the various external
repositories, to be able to bring their updates into our code base. We
don't normally push our own customizations back upstream (yes, not The
Way Things Should Be, please turn down the flamethrowers).
So we want our main code tree to be composed of our own code and an
assortment of modified external code:
main/
external1/
external2/
ourstuffA/
ourstuffB/
Our general approach for supporting this (remember, git novices here) is
to keep a local git mirror of each external code repository (say, with
git-svn for the FreeBSD tree). Then we incorporate the local mirrors
into our main repo, each under its own directory.
I've looked at two ways to do this: submodules and subtree merges, and
the latter looks better to me. The main complication with submodules is
branching and tagging. We need to branch or tag the entire main code
tree, including all the external code bases. With submodules that seems
like it would involve several steps to touch all the external mirror
repos as well as the main repo. Another complication is that we do a
lot of our work (50% or more) in the external code trees, and having to
update the main repo's submodule references as that code changes seems
rather fragile.
OTOH, a subtree merge nicely puts the external code into a specific spot
in our main tree, lets that spot get updated with a single command (git
pull -s subtree External2 master), and still let us branch and tag with
single commands in the main repo. Also, the changes we make to
externally-based code are plain old git pushes to the main repo. Clean
and simple. (BTW, what does braid add beyond just doing subtree merges
directly?)
So, first the general question: Anything braindead about the above? Any
better ways to do this?
Now for the specific issue, which has to do with managing the remotes
defined in the main repository. The subtree-merge approach calls for
the mirrored external repos to be "git remote add"-ed to the main repo.
But clones of that repo don't include the remote references (using git
1.5.4.3 for my testing here).
I think that makes sense in most cases: Usually a developer will only
want to clone the main repo and work with what's in there, ad not want
to bother with the external references. But when it comes time to pull
in updates from the external mirror repos the only place where that can
be done is on the main repo where the original "git remote add" commands
were issued.
That means merge work has to be done on the main repository's shared
host (not good) and that testing merged code has to involve committing
changes on the main shared repo (also not good, even in a branch) and
testing them on a different host (still no goodness here).
From this point of view (and please correct me if I'm wrong), it would
be good if "git clone" had an option to include a repo's remote
references in the clone. The clone's origin reference would point to
the original repo as usual, but all the other remotes would be in the clone.
Pushing and pulling would then also update (non-origin) the remote
references.
Does this make sense? Am I missing something here? (And thanks for
reading this far!)
Marc
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Jeff King @ 2008-10-16 19:17 UTC (permalink / raw)
To: Matt Draisey; +Cc: Junio C Hamano, git
In-Reply-To: <1224095087.5366.19.camel@localhost>
On Wed, Oct 15, 2008 at 02:24:47PM -0400, Matt Draisey wrote:
> If HEAD is a symlink rather than a "ref:" style link this is really
> bad.
Hmm. I don't think we have shipped with a symlink HEAD for quite a long
time. Using one obviously doesn't work with detached HEAD, but also
would fail with packed refs. I don't know if we ever deprecated it.
Still, this is a pretty nasty effect, in that it kills whatever was in
the existing ref. There is a fix below which refuses to lock any ref if
it is a symlink and we have requested not to dereference (actually, it
is overly cautious -- the symlink flag is triggered when we see a
symlink anywhere in the chain, though we need only prevent the situation
when the _first_ symref is a symlink. I don't know if it is worth
differentiating, since they are both "should never happen anymore"
situations, I think).
---
diff --git a/refs.c b/refs.c
index b680750..43568e7 100644
--- a/refs.c
+++ b/refs.c
@@ -447,7 +447,7 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
strcpy(ref_buffer, buffer);
ref = ref_buffer;
if (flag)
- *flag |= REF_ISSYMREF;
+ *flag |= REF_ISSYMREF | REF_ISSYMLINK;
continue;
}
}
@@ -817,6 +817,10 @@ static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char
}
ref = resolve_ref(orig_ref, lock->old_sha1, mustexist, &type);
}
+ if (type & REF_ISSYMLINK && flags & REF_NODEREF) {
+ error("unable to directly lock symbolic link '%s'", orig_ref);
+ goto error_return;
+ }
if (type_p)
*type_p = type;
if (!ref) {
diff --git a/refs.h b/refs.h
index 06ad260..6356a6a 100644
--- a/refs.h
+++ b/refs.h
@@ -12,6 +12,7 @@ struct ref_lock {
#define REF_ISSYMREF 01
#define REF_ISPACKED 02
+#define REF_ISSYMLINK 04
/*
* Calls the specified function for each ref file until it returns nonzero,
^ permalink raw reply related
* Re: Working with remotes; cloning remote references
From: Peter Harris @ 2008-10-16 19:20 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <48F7852F.109@xiplink.com>
On Thu, Oct 16, 2008 at 2:17 PM, Marc Branchaud wrote:
> From this point of view (and please correct me if I'm wrong), it would be
> good if "git clone" had an option to include a repo's remote references in
> the clone. The clone's origin reference would point to the original repo as
> usual, but all the other remotes would be in the clone.
"git clone" doesn't have this option, but you can turn it on
immediately after with something similar to:
git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
(which I use for fanning-out my git-svn repos)
See "git help fetch" for further documentation.
Peter Harris
^ 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