* Re: [PATCH 4/4] diff.c: convert builtin funcname patterns to extended regular expressions
From: Gustaf Hendeby @ 2008-09-18 10:15 UTC (permalink / raw)
To: Johan Herland
Cc: Brandon Casey, Junio C Hamano, Git Mailing List, Giuseppe Bilotta
In-Reply-To: <200809181039.46954.johan@herland.net>
On 09/18/2008 10:39 AM, Johan Herland wrote:
> On Thursday 18 September 2008, Brandon Casey wrote:
>> This is a blind conversion removing \\ before ( and { etc.
>> and adding \\ before naked ( and { etc.
>>
>> I hope the authors who last touched these patterns will help with
>> testing:
>>
>> bibtex: Johan Herland
>
> This was moved by Junio when he applied my patch; the line was originally
> written by Gustaf Hendeby in 23b5beb28fdadbb1d80ebf686a35385609f7a180
I'm on the road the rest of this week and don't have access to a
suitable machine for testing until I get back. Will put testing this on
the list of things to do for Monday. The patch looks good, though, but
I haven't actually tested it.
/Gustaf
^ permalink raw reply
* Re: [PATCH] diff/diff-files: do not use --cc too aggressively
From: Johannes Sixt @ 2008-09-18 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v7i99zuqh.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Textual diff output for unmerged paths was too eager to give condensed
> combined diff. This has two problems:
>
> (1) "diff --base/--ours/--theirs" (and "diff-files -p" with the same) is
> a request to compare with the named stage. We showed "-c -p" output
> instead;
I cannot reproduce what you describe here. "diff --base/--ours/--theirs"
works as expected with and without this patch.
> (2) "diff -c" (and "diff-files -c -p") is a request to view combined diff
> without condensing (otherwise the user would have explicitly asked
> for --cc, not -c). We showed "--cc" output anyway.
The patch fixes this:
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
-- Hannes
^ permalink raw reply
* [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Jeff King @ 2008-09-18 9:21 UTC (permalink / raw)
To: sverre; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20080916062105.GA12708@coredump.intra.peff.net>
The "--root" option generally means "treat any commits
without parents as a big creation event". This extends the
meaning to make an index comparison against a non-existant
HEAD into a big creation event. In other words, "if this
index _were_ to become a commit, this is how we would show
it with --root."
Specifically, we cover the case of
git diff --cached --root
to show either the diff between the index and HEAD, or if
there is no HEAD, show the diff against the empty tree.
This can simplify calling scripts which must otherwise
special-case the initial commit when showing the index
status.
We intentionally don't cover:
- git diff --cached --root HEAD
The user has specifically asked for HEAD, which doesn't
exist.
- git diff-index
The user is required to specify a tree-ish to
diff-index; if that tree-ish doesn't exist, we should
report an error.
Signed-off-by: Jeff King <peff@peff.net>
---
On Tue, Sep 16, 2008 at 02:21:05AM -0400, Jeff King wrote:
> Right, that was what I meant by "incomplete". I think there are several
> other cases where giving "--root" would have expected behavior but is
> currently ignored. I'll take a closer look, but I probably won't have
> time for a few days.
Actually, I wasn't able to find any more cases. I don't think it makes
sense to override the behavior when an explicit tree-ish is given, so
that cuts out the two places mentioned above. Though I think
that scripts using this might prefer the plumbing
diff-index, so maybe there is a better way to support this
(e.g., if --root is specified without a tree-ish, assume
HEAD or empty tree).
diff-tree already handles --root itself. And there is no way to my
knowledge to provoke the same kind of "show the diff against its parent"
behavior via git-diff, since a single tree-ish there means "diff against
the working tree".
And of course for diff-files, such an option makes no sense.
Can you think of any other cases?
builtin-diff.c | 7 +++++--
revision.c | 17 ++++++++++++++---
revision.h | 1 +
t/t4030-diff-root.sh | 21 +++++++++++++++++++++
4 files changed, 41 insertions(+), 5 deletions(-)
create mode 100755 t/t4030-diff-root.sh
diff --git a/builtin-diff.c b/builtin-diff.c
index 037c303..0a1efb5 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -315,8 +315,11 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
break;
else if (!strcmp(arg, "--cached")) {
add_head_to_pending(&rev);
- if (!rev.pending.nr)
- die("No HEAD commit to compare with (yet)");
+ if (!rev.pending.nr) {
+ if (!rev.show_root_diff)
+ die("No HEAD commit to compare with (yet)");
+ add_empty_to_pending(&rev);
+ }
break;
}
}
diff --git a/revision.c b/revision.c
index 499f0e0..de0fd89 100644
--- a/revision.c
+++ b/revision.c
@@ -145,16 +145,27 @@ void add_pending_object(struct rev_info *revs, struct object *obj, const char *n
add_pending_object_with_mode(revs, obj, name, S_IFINVALID);
}
-void add_head_to_pending(struct rev_info *revs)
+static void add_to_pending_by_name(struct rev_info *revs, const char *name)
{
unsigned char sha1[20];
struct object *obj;
- if (get_sha1("HEAD", sha1))
+ if (get_sha1(name, sha1))
return;
obj = parse_object(sha1);
if (!obj)
return;
- add_pending_object(revs, obj, "HEAD");
+ add_pending_object(revs, obj, name);
+}
+
+void add_head_to_pending(struct rev_info *revs)
+{
+ add_to_pending_by_name(revs, "HEAD");
+}
+
+void add_empty_to_pending(struct rev_info *revs)
+{
+ add_to_pending_by_name(revs,
+ "4b825dc642cb6eb9a060e54bf8d69288fbee4904");
}
static struct object *get_reference(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags)
diff --git a/revision.h b/revision.h
index fc23522..108f43d 100644
--- a/revision.h
+++ b/revision.h
@@ -151,6 +151,7 @@ extern void add_object(struct object *obj,
extern void add_pending_object(struct rev_info *revs, struct object *obj, const char *name);
extern void add_head_to_pending(struct rev_info *);
+extern void add_empty_to_pending(struct rev_info *);
enum commit_action {
commit_ignore,
diff --git a/t/t4030-diff-root.sh b/t/t4030-diff-root.sh
new file mode 100755
index 0000000..e5174b7
--- /dev/null
+++ b/t/t4030-diff-root.sh
@@ -0,0 +1,21 @@
+#!/bin/sh
+
+test_description='diff --root allows comparison between index and root'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo content >file &&
+ git add file
+'
+
+test_expect_success 'diff --cached (without --root)' '
+ test_must_fail git diff --cached --name-only
+'
+
+test_expect_success 'diff --cached (with --root)' '
+ echo file >expect &&
+ git diff --cached --name-only --root >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
1.6.0.2.249.g97d7f.dirty
^ permalink raw reply related
* failure doing massive revert
From: Mike Galbraith @ 2008-09-18 9:09 UTC (permalink / raw)
To: git
Greetings,
For reasons I'd rather not go into, I decided to create a merge free
tree to try to bisect. I did this yesterday for a smaller range, and it
worked fine, and I was able to revert the reverts to re-apply. Trying
to revert everything from v2.6.26..today croaked.
for i in `git rev-list --no-merges v2.6.26..HEAD`; do git revert $i < /dev/null; done
Got this far...
Author: Mike Galbraith <efault@gmx.de> 2008-09-18 10:50:58
Committer: Mike Galbraith <efault@gmx.de> 2008-09-18 10:50:58
Parent: 6753354a5984745b0121f7853e4e7a392e25adc7 (Revert "[ARM] 5185/1: Fix spi num_chipselect for lubbock")
Child: 0000000000000000000000000000000000000000 (Local uncommitted changes, not checked in to index)
Branch: master
Follows: v2.6.27-rc6
Precedes:
Revert "pktgen: multiqueue etc."
This reverts commit e6fce5b916cd7f7f79b2b3e53ba74bbfc1d7cf8b.
...then began spewing fatal: Dirty index: cannot revert. Probably me
being git-ignorant, but figured I'd mention it just in case. I started
by whacking all source, followed by checkout -f master, so have no idea
what git means by local changes.
-Mike
^ permalink raw reply
* [PATCH] diff/diff-files: do not use --cc too aggressively
From: Junio C Hamano @ 2008-09-18 9:08 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Sixt
In-Reply-To: <48D203B3.90807@viscovery.net>
Textual diff output for unmerged paths was too eager to give condensed
combined diff. This has two problems:
(1) "diff --base/--ours/--theirs" (and "diff-files -p" with the same) is
a request to compare with the named stage. We showed "-c -p" output
instead;
(2) "diff -c" (and "diff-files -c -p") is a request to view combined diff
without condensing (otherwise the user would have explicitly asked
for --cc, not -c). We showed "--cc" output anyway.
0fe7c1d (built-in diff: assorted updates, 2006-04-29) claimed to be
careful about doing this, but its breakage was hidden because back then
"git diff" was still a shell script that did not use the codepath it
introduced fully.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-diff-files.c | 7 ++++++-
builtin-diff.c | 8 +++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/builtin-diff-files.c b/builtin-diff-files.c
index 9bf10bb..2b578c7 100644
--- a/builtin-diff-files.c
+++ b/builtin-diff-files.c
@@ -50,7 +50,12 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)
3 < rev.max_count)
usage(diff_files_usage);
- if (rev.max_count == -1 &&
+ /*
+ * "diff-files --base -p" should not combine merges because it
+ * was not asked to. "diff-files -c -p" should not densify
+ * (the user should ask with "diff-files --cc" explicitly).
+ */
+ if (rev.max_count == -1 && !rev.combine_merges &&
(rev.diffopt.output_format & DIFF_FORMAT_PATCH))
rev.combine_merges = rev.dense_combined_merges = 1;
diff --git a/builtin-diff.c b/builtin-diff.c
index 037c303..d5fe775 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -223,7 +223,13 @@ static int builtin_diff_files(struct rev_info *revs, int argc, const char **argv
argv++; argc--;
}
- if (revs->max_count == -1 &&
+ /*
+ * "diff --base" should not combine merges because it was not
+ * asked to. "diff -c" should not densify (if the user wants
+ * dense one, --cc can be explicitly asked for, or just rely
+ * on the default).
+ */
+ if (revs->max_count == -1 && !revs->combine_merges &&
(revs->diffopt.output_format & DIFF_FORMAT_PATCH))
revs->combine_merges = revs->dense_combined_merges = 1;
--
1.6.0.2.412.g0bc80
^ permalink raw reply related
* Re: [PATCH 4/4] diff.c: convert builtin funcname patterns to extended regular expressions
From: Johan Herland @ 2008-09-18 8:39 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Git Mailing List, Giuseppe Bilotta,
Gustaf Hendeby
In-Reply-To: <-f-gqL4SkA8Uh7hSuKT-JDY0g26jHn3fDQCE24MB1nKWUMLZWuSseg@cipher.nrlssc.navy.mil>
On Thursday 18 September 2008, Brandon Casey wrote:
> This is a blind conversion removing \\ before ( and { etc.
> and adding \\ before naked ( and { etc.
>
> I hope the authors who last touched these patterns will help with
> testing:
>
> bibtex: Johan Herland
This was moved by Junio when he applied my patch; the line was originally
written by Gustaf Hendeby in 23b5beb28fdadbb1d80ebf686a35385609f7a180
> html: Johan Herland
Works fine!
> tex: Johan Herland
This was moved by Junio when he applied my patch; the line was last
rewritten by Giuseppe Bilotta in 807d86945336f676c9f650a6cbae9baa3191aaec
...I just became a BIG fan of "git gui blame" ;)
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Help planning a git repo layout
From: Leevi Graham @ 2008-09-18 8:37 UTC (permalink / raw)
To: git
Hey everyone,
I'm after some advice on how to layout my git repo(s).
Here's my current situation:
I am developing 10 different ExpressionEngine addons that all live
inside one ExpressionEngine installation. A simplified EE installation
has the following folders (all cruft removed):
|-root
|-ee-admin
|---extensions
|---language
|---modules
|-themes
|---site_themes
My addons are a combination of files located in the extensions,
language, modules and themes folders. An simple extension may look like:
|-root
|-ee-admin
|---extensions
|-----ext.lg_data_matrix.php
|---language
|-----english
|---------lang.lg_data_matrix.php
|---modules
|-themes
|---site_themes
The extension above contains two files:
- /ee-admin/extensions/ext.lg_data_matrix.php
- /ee-admin/language/english/ext.lg_data_matrix.php
I will be developing multiple extensions in the one EE install to make
sure they all work with the core and do not conflict with each other.
So my directory will have more than one addon in it:
|-root
|-ee-admin
|---extensions
|-----ext.lg_data_matrix.php
|-----ext.lg_minify.php
|-----ext.lg_better_meta_ext.php
|---language
|-----english
|---------lang.lg_data_matrix.php
|---------lang.lg_minify.php
|---------lang.lg_better_meta.php
|---------lang.lg_better_meta_ext.php
|---modules
|-----lg_better_meta
|---------mcp.lg_better_meta.php
|---------mod.lg_better_meta.php
|-themes
|---site_themes
My problem comes when I want to tag and release an individual addon
which is a collection of files in multiple folders.
Just say I wanted to tag and release LG Better Meta. Ideally I would
like to export a folder structure like:
- /ee-admin/extensions/ext.lg_better_meta.php
- /ee-admin/language/english/ext.lg_better_meta.php
- /ee-admin/language/english/ext.lg_better_meta_ext.php
- /ee-admin/modules/lg_better_meta/mcp.lg_better_meta.php
- /ee-admin/modules/lg_better_meta/mod.lg_better_meta.php
I would also like to give people the ability to clone each of the
addons either as a full repo or part thereof.
Any advice would be greatly appreciated.
Cheers Leevi
^ permalink raw reply
* Re: [PATCH 2/4] diff.c: associate a flag with each pattern and use it for compiling regex
From: Junio C Hamano @ 2008-09-18 8:35 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Brandon Casey, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Boyd Lynn Gerber, Git Mailing List
In-Reply-To: <48D20C04.1020703@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
> ...
> I think it makes perfect sense to use whatever we pass when compiling
> the regex. I wouldn't dare try to hack up something that pre-mangles
> a regular expression and assume it gets it right everywhere anyway, so
> I'm quite happy with leaving it all to regcomp(3) and friends.
Oh, I never meant pre-mangling or anything funky like that.
What I was envisioning we might want to make more flexible was what we
build on top of regexp, such as the way how these multi-line stuff is
treated for example. Currently more than one positive regexp concatenated
with "\n" are ANDed together and the captured string from the last one is
used, but it is plausible we might want to say "first positive capturing
match yields result for this pattern string", or something like that.
>> Thanks --- I am bit under the weather and not thinking quite straight.
>
> Mix 2cc's of 7yo Havana Club into a large cup of tea. Drink one such
> cup every hour and eat a fresh fruit with it. I haven't been ill a day
> in my life since I came up with that most excellent cure for absolutely
> everything. If nothing else, it makes it a bit less boring to be ill.
Heh, unfortunately I happen to live in the US.
^ permalink raw reply
* Re: [RFC] log(n)-transmissions common commit handshake
From: Thomas Rast @ 2008-09-18 8:18 UTC (permalink / raw)
To: git
In-Reply-To: <200809180100.32626.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
I wrote:
> * Impact/clever use of refs
>
> For some reason, current git sends all refs to the server, even if
> the server should already know about lots of them. For example, in
> git.git, emitting v1.6.0.2 covers almost all tags in the repository
> by simple ancestor scanning.
>
> Is there a reason for this behaviour? Otherwise it would be better
> to emit them in date order and intelligently handle commons. (In
> fact this does not depend on the discussed change.)
As an addendum, I think the following would be a good way to cleverly
use refs to reduce work:
Cache a "reduced" DAG which just maps the ref'd commit relationships,
i.e., shows the reachability of refs only. This needs to be written
out to disk between invocations.
At the start of the protocol, the server announces all its refs. We
can use the reduced DAG to infer the minimal set of ref heads we need
to announce to have the server know all common ones. We can also mark
all the other refs as "common but not announced yet", so that the
backwards marking and searching routines know to stop there.
This should reduce the number of refs listed back to the server to
only a handful, and at the same time, stop the client from searching
backwards through _all_ history (which can take a bit of time, and is
one of the weaknesses of my proposal) in most cases.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] diff.c: associate a flag with each pattern and use it for compiling regex
From: Andreas Ericsson @ 2008-09-18 8:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Boyd Lynn Gerber, Git Mailing List
In-Reply-To: <7vod2myljk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> Junio C Hamano wrote:
>> ...
>>>> static struct funcname_pattern {
>>>> char *name;
>>>> char *pattern;
>>>> + int cflags;
>>> What does "C" stand for?
>> "compile". It's the same name as regcomp(3) uses for the flags being
>> used to compile the regular expression. The full mnemonic name would
>> be regex_compile_flag, which is a bit unwieldy. Perhaps regcomp_flags
>> would be a good compromise?
>
> Ah, I see.
>
> When I saw that new field for the first time, I didn't think it will be
> used to store the bare flag values regcomp/regexec library would accept
> directly (I expected we would see #define or enum to tweak our own set of
> features, not limiting ourselves EXTENDED/ICASE etc. that regcomp/regexec
> library supports)
>
> IOW, it just did not click for me to look at "man 3 regcomp" which says:
>
> int regcomp(regex_t *preg, const char *regex, int cflags);
>
> So unless others feel that we might get a better layering separation by
> not storing REG_EXTENDED and stuff directly in that field (which was my
> initial reaction without looking at 4/4 which does store REG_EXTENDED
> there without our own enums), cflag is perfectly a good name here.
>
I think it makes perfect sense to use whatever we pass when compiling
the regex. I wouldn't dare try to hack up something that pre-mangles
a regular expression and assume it gets it right everywhere anyway, so
I'm quite happy with leaving it all to regcomp(3) and friends.
> Thanks --- I am bit under the weather and not thinking quite straight.
>
Mix 2cc's of 7yo Havana Club into a large cup of tea. Drink one such
cup every hour and eat a fresh fruit with it. I haven't been ill a day
in my life since I came up with that most excellent cure for absolutely
everything. If nothing else, it makes it a bit less boring to be ill.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/4] diff.c: convert builtin funcname patterns to extended regular expressions
From: Junio C Hamano @ 2008-09-18 7:31 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Brandon Casey, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Boyd Lynn Gerber, Git Mailing List, Avery Pennarun,
Johan Herland, Kirill Smelkov, Giuseppe Bilotta
In-Reply-To: <48D200D7.9080800@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Can we issue a deprecation heads-up for the current "funcname"
> along with a "call for patterns" and then have "funcname" and
> "ereg_funcname" mean the same for a while until we obsolete
> ereg_funcname in favour of funcname, perhaps? I can't imagine
> anyone wanting to use posix regular expressions if extended
> ones are available everywhere.
I prefer not to obsolete anything, and that is one of the larger reasons
that I did not object to xfuncname at all. It's shorter to spell than
ereg_funcname (and sweeter to the eye).
Even when in some future _everybody_ uses xfuncname and nobody you and I
know personally uses funcname anymore, I do not think it is worth the
hassle to change the semantics of "funcname".
For one thing, "xfuncname" is _not_ that ugly that people would wish they
could spell it just "funcname".
This reminds me of what Eric did to "commit" vs "dcommit". "commit" was
renamed to "set-tree", and a command with a better semantics is called
"dcommit". Perhaps not many people use "set-tree" and everybody keeps
typing "dcommit" these days, but it is not worth renaming it to "commit",
ever.
^ permalink raw reply
* Re: combined diff, but not condensed, howto?
From: Johannes Sixt @ 2008-09-18 7:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vskryym24.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> It is very much Ok and useful for "git diff" to default to "--cc -p", and
> it may be fine for "git diff-files -p" to default to "--cc".
>
> But I think ideally an explicit "git diff -c" and "git diff-files -c -p"
> should not turn the "dense combined" mode on.
>
> The commonality of these two functions is striking and calls for proper
> refactoring, but aside from that, I think a patch like this should be
> applied. What do you think?
This makes a lot of sense. As I mention in my initial post, I was
wondering why 'diff -c' was the same as 'diff --cc'.
> diff --git i/builtin-diff-files.c w/builtin-diff-files.c
> index 9bf10bb..2b578c7 100644
> --- i/builtin-diff-files.c
> +++ w/builtin-diff-files.c
> @@ -50,7 +50,12 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)
> 3 < rev.max_count)
> usage(diff_files_usage);
>
> - if (rev.max_count == -1 &&
> + /*
> + * "diff-files --base -p" should not combine merges because it
> + * was not asked to. "diff-files -c -p" should not densify
> + * (the user should ask with "diff-files --cc" explicitly).
> + */
> + if (rev.max_count == -1 && !rev.combine_merges &&
> (rev.diffopt.output_format & DIFF_FORMAT_PATCH))
> rev.combine_merges = rev.dense_combined_merges = 1;
Hm... In my tests, a bare 'git diff-files --cc' produces a combined diff,
but 'git diff-files -c' does not.
> diff --git i/builtin-diff.c w/builtin-diff.c
> index 037c303..9fb30c6 100644
> --- i/builtin-diff.c
> +++ w/builtin-diff.c
> @@ -223,7 +223,12 @@ static int builtin_diff_files(struct rev_info *revs, int argc, const char **argv
> argv++; argc--;
> }
>
> - if (revs->max_count == -1 &&
> + /*
> + * "diff --base" should not combine merges because it was not
> + * asked to. "diff -c" should not densify (the user should ask
> + * with "diff --cc" explicitly.
I don't see why you add "the user should ask with 'diff --cc'" when this
becomes the default anyway.
> + */
> + if (revs->max_count == -1 && !revs->combine_merges &&
> (revs->diffopt.output_format & DIFF_FORMAT_PATCH))
> revs->combine_merges = revs->dense_combined_merges = 1;
-- Hannes
^ permalink raw reply
* Re: Project organisation and structure
From: Boaz Harrosh @ 2008-09-18 7:30 UTC (permalink / raw)
To: k wayne; +Cc: git
In-Reply-To: <bcf9fe2c0809170649x3f377c7erecc9f69a4a664d52@mail.gmail.com>
k wayne wrote:
> Hello,
> I'm new to git, and I hope this is the right mailinglist for what I'm
> going to ask; it was the only one I found on http://git.or.cz. Sorry
> if it's not or my question is remarkably stupid. I've read the git
> documentation, of course, but it wasn't always easy to wrap my head
> around all the concepts, so I might have missed an obvious solution to
> my problem.
>
> Currently, I've got a tree of self-written C++ source code for which I
> don't use any SCM, and I'd like to start using git on it. However,
> I've run into issues with my directory layout I cannot resolve on my
> own.
> I have a collection of libraries and programs, which aren't coupled
> too much, but aren't really independent either; for example, library X
> depends on Y, program Z on lib A and so forth. Since all of these libs
> and programs are logically connected to each other in some way, I
> would like to have them all in one central repository.
> So I heard that I could create kind of a "meta-repository" for the
> whole project, and have submodules for each library or program, which
> sounds exactly like what I want. However, I've been told that my
> current directory layout will not work this way with git.
>
> This is how my project root directory (say it's ~) looks like:
> ~/build - Build files which apply for the whole project, like doxygen
> build files.
> ~/include/$submodule - Each library/program has an own directory here,
> in which all header files go.
> ~/projects/$submodule - Files related to an individual project, like
> makefiles etc.
> ~/src/$submodule - Like the above two, but for source files.
> ~/test/$submodule - Again, a directory for each library/program,
> containing files for (unit)tests.
> ~/doc - Documentation files for the project as a whole.
> ~/doc/$submodule - Documentation files for individual libraries/programs.
>
> These are the directories I would like git to track for me. There are
> some other dirs not listed here (e.g. for object files,) but I can
> easily add them to .gitignore.
>
> So, the git structure as I imagine it would look like this: ~/.git
> contains the "meta-repository," in which all the submodules reside.
> Each submodule would have its .git directory in ~/projects/$submodule.
> Alternatively, ~/.git for the meta-repo and ~/.git-$subproject or
> something like this would be okay too.
>
> However, I have been told I cannot go to ~/projects/$submodule and do
> a "git add ../../{include,src,test,doc}/$submodule" there. I could add
> symlinks in ~/projects/$submodule to each of these dirs and add that
> link, but this would not work with windows, I guess (would it work
> with git, anyway?)
>
> So, how can I manage my code without having to restructure my tree?
>
> I'd like to keep it that way, because it is convenient to have only
> one directory to pass to the compiler as an additional include dir,
> and can include my header files as "submodule/someheader.hpp" which
> is, in my opinion, helpful in organizing the code.
>
> If there should be no way I can keep my directory setup the way it is
> with the current git, would a feature request be a good idea (and
> possibly implemented), or does my directory tree have a serious flaw I
> haven't stumbled across yet, which makes it unusable anyways?
>
> Thank you in advance.
> --
Your directory structure is common and intuitive in the sense that thats
what happens, you start coding then add stuff along the way. You don't
know from the start what will the tree look like.
Git is well suited for your tree and will eat it with out solt
Do not use subprojects these are used with two separately developed
projects that are dependent (one on the other not two ways).
For example I have a GUI app that uses wxWidgets. Instead of instructing
my users on where to get it and what exact version to use, with what
version of my program, I mirror it in a submodule and this is all done
automatically for me and my cloners.
What you need is topic branches. Not all branches need have all the
same files. In fact they can have nothing in common. The only thing
with git is that at a certain checkout in time only these files will
be present on disk.
So lets say you have:
/include/lib4foobar
/include/lib4bar
/src/lib4foobar
/src/lib4bar
/src/foo
/src/bar
Lets complicate it and say lib4bar is also dependent on lib4foobar
then you have these branches: lib4foobar lib4bar foo bar
When you work on a library/app you take your foo-maintainer hat and
push patches to your subtree branch. When it is time for integration,
checkout master and merge all the branches in.
Simple as hell. And faster then you ever imagine.
Additionally you can have working branches that, lets say
did-of-the-day, where you save work to 3 topics /src/bar
/src/lib4bar /src/lib4foobar. Once you are happy. You can
push them through the project branches, and delete the
working branch, or you can merge that directly into master
and when you pull master into the topic branches after a big
merge, they will have it automatically.
This is all very similar to Linux. With the subject maintainers
and all, just with fewer people.
PS: Don't forget to have a very first patch with nothing but
a common root file like GPLv2 or README. The first patch is
hard to work with.
Just my $0.017
Boaz
^ permalink raw reply
* Re: [PATCH 4/4] diff.c: convert builtin funcname patterns to extended regular expressions
From: Andreas Ericsson @ 2008-09-18 7:18 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Boyd Lynn Gerber, Git Mailing List, Avery Pennarun,
Johan Herland, Kirill Smelkov, Giuseppe Bilotta
In-Reply-To: <-f-gqL4SkA8Uh7hSuKT-JDY0g26jHn3fDQCE24MB1nKWUMLZWuSseg@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
>
>
> This is a blind conversion removing \\ before ( and { etc.
> and adding \\ before naked ( and { etc.
>
> I hope the authors who last touched these patterns will help with testing:
>
> bibtex: Johan Herland
> html: Johan Herland
> java: Junio Hamano, Jeff King
> pascal: Avery Pennarun
> php: Andreas Ericsson
> python: Kirill Smelkov
> ruby: Giuseppe Bilotta
> tex: Johan Herland
>
The PHP one seems to work just fine.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Nicely done, although I'd rather have "ereg_funcname" instead of
"xfuncname", but I don't care very much for myself, as I'll
rather submit my patterns upstream than add them to .git/config ;-)
Junio:
Can we issue a deprecation heads-up for the current "funcname"
along with a "call for patterns" and then have "funcname" and
"ereg_funcname" mean the same for a while until we obsolete
ereg_funcname in favour of funcname, perhaps? I can't imagine
anyone wanting to use posix regular expressions if extended
ones are available everywhere.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/4] diff.c: associate a flag with each pattern and use it for compiling regex
From: Junio C Hamano @ 2008-09-18 7:12 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Brandon Casey, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Boyd Lynn Gerber, Git Mailing List
In-Reply-To: <48D1F80C.5030502@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
> ...
>>> static struct funcname_pattern {
>>> char *name;
>>> char *pattern;
>>> + int cflags;
>>
>> What does "C" stand for?
>
> "compile". It's the same name as regcomp(3) uses for the flags being
> used to compile the regular expression. The full mnemonic name would
> be regex_compile_flag, which is a bit unwieldy. Perhaps regcomp_flags
> would be a good compromise?
Ah, I see.
When I saw that new field for the first time, I didn't think it will be
used to store the bare flag values regcomp/regexec library would accept
directly (I expected we would see #define or enum to tweak our own set of
features, not limiting ourselves EXTENDED/ICASE etc. that regcomp/regexec
library supports)
IOW, it just did not click for me to look at "man 3 regcomp" which says:
int regcomp(regex_t *preg, const char *regex, int cflags);
So unless others feel that we might get a better layering separation by
not storing REG_EXTENDED and stuff directly in that field (which was my
initial reaction without looking at 4/4 which does store REG_EXTENDED
there without our own enums), cflag is perfectly a good name here.
Thanks --- I am bit under the weather and not thinking quite straight.
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Karl Hasselström @ 2008-09-18 7:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809170909j4fce34acr8f0b844d0cb5281d@mail.gmail.com>
On 2008-09-17 17:09:46 +0100, Catalin Marinas wrote:
> I'm still confused by this and I don't think your new flag would
> help. The meaning of stop_before_conflict is that it won't push the
> conflicting patch but actually leave the stack with several patches
> pushed or popped.
>
> What I want for sink (and float afterwards) is by default to cancel
> the whole transaction if there is a conflict and revert the stack to
> it's original state prior to the "stg sink" command.
Ah, OK. Then I think you want something like this:
try:
trans.reorder_patches(applied, unapplied, hidden, iw)
except transaction.TransactionHalted:
if not options.conflict:
trans.abort(iw)
raise common.CmdException(
'Operation rolled back -- would result in conflicts')
return trans.run(iw)
But with a better error message ...
StackTransaction.abort() doesn't have much in the way of
documentation, unfortunately, but what it does is to check out the
tree we started with. (Nothing else is necessary, since we never touch
any refs and stuff until the end of StackTransaction.run(). And the
only case where we touch the tree is when we need to fall back to
merge-recursive.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: combined diff, but not condensed, howto?
From: Junio C Hamano @ 2008-09-18 7:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <48D1F426.4040208@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
> ...
>> It all happens inside combine-diff.c::make_hunks(). If you pass dense==0,
>> you should be able to get all the uninteresting hunks, I think.
>>
>> Perhaps
>>
>> $ git diff --base -c
>
> Yes, that does it!
It may do so, but I do not necessarily agree with the logic.
It is very much Ok and useful for "git diff" to default to "--cc -p", and
it may be fine for "git diff-files -p" to default to "--cc".
But I think ideally an explicit "git diff -c" and "git diff-files -c -p"
should not turn the "dense combined" mode on.
The commonality of these two functions is striking and calls for proper
refactoring, but aside from that, I think a patch like this should be
applied. What do you think?
---
builtin-diff-files.c | 7 ++++++-
builtin-diff.c | 7 ++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git i/builtin-diff-files.c w/builtin-diff-files.c
index 9bf10bb..2b578c7 100644
--- i/builtin-diff-files.c
+++ w/builtin-diff-files.c
@@ -50,7 +50,12 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)
3 < rev.max_count)
usage(diff_files_usage);
- if (rev.max_count == -1 &&
+ /*
+ * "diff-files --base -p" should not combine merges because it
+ * was not asked to. "diff-files -c -p" should not densify
+ * (the user should ask with "diff-files --cc" explicitly).
+ */
+ if (rev.max_count == -1 && !rev.combine_merges &&
(rev.diffopt.output_format & DIFF_FORMAT_PATCH))
rev.combine_merges = rev.dense_combined_merges = 1;
diff --git i/builtin-diff.c w/builtin-diff.c
index 037c303..9fb30c6 100644
--- i/builtin-diff.c
+++ w/builtin-diff.c
@@ -223,7 +223,12 @@ static int builtin_diff_files(struct rev_info *revs, int argc, const char **argv
argv++; argc--;
}
- if (revs->max_count == -1 &&
+ /*
+ * "diff --base" should not combine merges because it was not
+ * asked to. "diff -c" should not densify (the user should ask
+ * with "diff --cc" explicitly.
+ */
+ if (revs->max_count == -1 && !revs->combine_merges &&
(revs->diffopt.output_format & DIFF_FORMAT_PATCH))
revs->combine_merges = revs->dense_combined_merges = 1;
^ permalink raw reply related
* Re: [PATCH] Add git-svn branch to allow branch creation in SVN repositories
From: Eric Wong @ 2008-09-18 6:55 UTC (permalink / raw)
To: Florian Ragwitz; +Cc: git
In-Reply-To: <1221142839-29624-1-git-send-email-rafl@debian.org>
Florian Ragwitz <rafl@debian.org> wrote:
> Signed-off-by: Florian Ragwitz <rafl@debian.org>
Hi Florian, Sorry I haven't checked the list (nor a good chunk email) in
a bit.
The patch looks good, but can you add a test for this functionality?
It'll make maintenance easier when other people (myself included)
introduce changes that can potentially break something. Thanks.
> ---
> Documentation/git-svn.txt | 24 +++++++++++++++++++++++-
> git-svn.perl | 43 ++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 65 insertions(+), 2 deletions(-)
>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Andreas Ericsson @ 2008-09-18 6:50 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Miklos Vajna, git, Johannes.Schindelin
In-Reply-To: <57518fd10809171214u3b5b3b96yc432c1c410faf8b4@mail.gmail.com>
Jonathan del Strother wrote:
> On Wed, Sep 17, 2008 at 4:55 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> On Wed, Sep 17, 2008 at 04:31:17PM +0100, Jonathan del Strother <maillist@steelskies.com> wrote:
>>> I was changing it to match the style in the existing java pattern (and
>>> my objc pattern). You think the java one should be changed to match
>>> the pascal one, then?
>> The point is that it's unrelated, so you should not change that part in
>> the same patch. Send a separate patch if you want to do something
>> unrelated to Objective-C.
>
> Johannes already convinced me to do it as a separate patch. Andreas
> seems to think that even if that change were in a separate patch, it
> is pure nonsense. I think it's pretty subjective - I was just making
> things consistent.
My apologies. I started writing that reply before Dscho's one got to the
list. Then it was lunch-time, so I didn't send it until Dscho's reply
was already answered by you.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Karl Hasselström @ 2008-09-18 7:10 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809170901o15027408w439af4436cfea67c@mail.gmail.com>
On 2008-09-17 17:01:22 +0100, Catalin Marinas wrote:
> 2008/9/17 Karl Hasselström <kha@treskal.com>:
>
> > Have you tried the benchmarks I committed a while back?
>
> No, I wanted to see how some real patches behave and I'm pretty
> pleased with the result.
In addition to the synthetic patch series you seem to have in mind,
there is also a more than 1000 patches long series from the kernel
history. Try running the setup.sh and take a look (it takes a few
minutes to run, but you'll only have to do it once because the
performance test script is careful not to wreck the repo it works on).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-svn: do a partial rebuild if rev_map is out-of-date
From: Eric Wong @ 2008-09-18 6:38 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20080917031304.GA2505@riemann.deskinm.fdns.net>
Deskin Miller <deskinm@umich.edu> wrote:
> This commit will have git-svn do a partial rebuild of the rev_map to
> match the true state of the branch, if it ever is used to fetch again.
>
> This will only work for projects not using either noMetadata or
> useSvmProps configuration options; if you are using these options,
> git-svn will fall back to the previous behaviour.
>
> Signed-off-by: Deskin Miller <deskinm@umich.edu>
> ---
Hi Deskin,
This seems to break the following test case for me:
*** t9107-git-svn-migrate.sh ***
* ok 1: setup old-looking metadata
* ok 2: git-svn-HEAD is a real HEAD
* ok 3: initialize old-style (v0) git svn layout
* ok 4: initialize a multi-repository repo
* ok 5: multi-fetch works on partial urls + paths
* ok 6: migrate --minimize on old inited layout
* FAIL 7: .rev_db auto-converted to .rev_map.UUID
I haven't had time to diagnose it. Also, can you add a test that
demonstrates this functionality (and ensures things keeps working when
future work is done on git-svn?)
Thanks.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: Always create a new RA when calling do_switch for svn://
From: Eric Wong @ 2008-09-18 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alec Berryman
In-Reply-To: <1221426856-2652-1-git-send-email-alec@thened.net>
Alec Berryman <alec@thened.net> wrote:
>
> This was reported as Debian bug #464713. An example repository can be
> found at svn://svn.debian.org/chinese/packages/lunar-applet. When I try
> to clone it with 1.6.0.2.229.g1293c or 1.5.6.5, both using 1.5.1
> libraries, I see the following:
>
> r158 = 1107cff6309c979751e0841d40b9e2e471694b26 (git-svn@159)
> M debian/changelog
> M debian/rules
> r159 = 010d0b481753bd32ce0255ce433d63e14114d3b6 (git-svn@159)
> Found branch parent: (git-svn) 010d0b481753bd32ce0255ce433d63e14114d3b6
> Following parent with do_switch
> Malformed network data: Malformed network data at /home/alec/local/git/libexec/git-core//git-svn line 2360
>
> It looks like the user made several commits and decided to undo them by
> removing the directory and copying an older version in its place.
>
> This appears to only affect access via svn:// and svn+ssh://; I tried
> with file:// but not with http://.
>
> The first patch is a minor refactoring of some test code, and the second
> one actually fixes the issue for me.
Thanks Alec, and sorry for the latency.
This series is:
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/4] diff.c: associate a flag with each pattern and use it for compiling regex
From: Andreas Ericsson @ 2008-09-18 6:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Boyd Lynn Gerber, Git Mailing List
In-Reply-To: <7vod2m1464.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> This is in preparation for allowing extended regular expression patterns.
>> ...
>> @@ -100,10 +100,11 @@ static int parse_lldiff_command(const char *var, const char *ep, const char *val
>> static struct funcname_pattern {
>> char *name;
>> char *pattern;
>> + int cflags;
>
> What does "C" stand for?
"compile". It's the same name as regcomp(3) uses for the flags being
used to compile the regular expression. The full mnemonic name would
be regex_compile_flag, which is a bit unwieldy. Perhaps regcomp_flags
would be a good compromise?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: combined diff, but not condensed, howto?
From: Johannes Sixt @ 2008-09-18 6:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vy71qyo9d.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Junio C Hamano schrieb:
>>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>>
>>>> After a merge conflict, 'git diff' shows a combined diff, which presents
>>>> only the parts that conflicted or where there are near-by changes from
>>>> different parents (potential conflicts). Is there a command line switch so
>>>> that *all* changes are shown, even non-conflicting ones?
>>> Like "git diff HEAD"?
>> No. Something that produces
> ...
>
> Ah, I see what you mean.
>
> It all happens inside combine-diff.c::make_hunks(). If you pass dense==0,
> you should be able to get all the uninteresting hunks, I think.
>
> Perhaps
>
> $ git diff --base -c
Yes, that does it!
Thanks,
-- Hannes
^ permalink raw reply
* Re: Editing Git Log
From: Matthias Kestenholz @ 2008-09-18 6:21 UTC (permalink / raw)
To: Piet Delaney; +Cc: Git Mailing List
In-Reply-To: <48D1ECB4.9080808@tensilica.com>
On Thu, Sep 18, 2008 at 7:52 AM, Piet Delaney
<piet.delaney@tensilica.com> wrote:
> I think I recall reading that a feature of git was the prevention of the git
> commits
> from being changed. I noticed today that a couple of us have checked in
> files
> without our customary [XTENSA] architecture prefixed to the 1st line of our
> Commit Messages.
>
> I couldn't find a way to do this, other than our reverting back to a earlier
> repository
> and recommitting (each?) change with the slightly changed Commit Message;
> not an attractive investment of our time.
>
> Any suggestions?
>
You have to create new commits, but you do not have to do it by hand. See
filter-branch[1]
The example given in the manpage removes the git-svn identifiers:
git filter-branch --msg-filter '
sed -e "/^git-svn-id:/d"
'
You can probably modify the sed expression and use it nearly as is (of course
you would not want to filter the whole history, only the handful commits that
came from you or your team.
[1]: http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html
^ 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