* Re: [PATCH] Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
From: Marco Costalba @ 2007-05-20 20:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vd50vl30r.fsf@assigned-by-dhcp.cox.net>
On 5/20/07, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> >> > if (offset >= 0) {
> >> > +
> >> > + if (desc->size - oldsize - offset == 0) /* end of file? */
> >> > + newsize -= trailing_added_lines;
> >> > +
> >> > int diff = newsize - oldsize;
> >> > unsigned long size = desc->size + diff;
> >> > unsigned long alloc = desc->alloc;
> >>
>
> Sorry I forgot to mention that that is "trivial" so there is no
> reason to resend. I don't expect me doing much git stuff for
> the rest of the day, but you'll hear from me about this patch
> later (hopefully it would appear on 'next' -- we'll see).
>
Ok. Thanks for your help.
P.S: I don't find a trivial way to avoid adding more lines then
removed, the shortest trick I can find is
int eof = (desc->size - oldsize - offset == 0);
int diff = newsize - oldsize - eof * trailing_added_lines;
unsigned long size = desc->size + diff;
unsigned long alloc = desc->alloc;
newsize -= eof * trailing_added_lines;
But is not as elegant as the original.
^ permalink raw reply
* Re: [PATCH] allow commands to be executed in submodules
From: Alex Riesen @ 2007-05-20 20:59 UTC (permalink / raw)
To: Martin Waitz; +Cc: Junio C Hamano, git
In-Reply-To: <20070520204801.GH5412@admingilde.org>
Martin Waitz, Sun, May 20, 2007 22:48:02 +0200:
> Do we really have so many places where we want to execute commands
> in a different directory or with different environment? Is it worth
> keeping run-command generic and having to introduce knowledge about
> how to run submodule commands in multiple places?
Is there multiple places? Is it hard to create a specific function out
of a generic one? (which can be used from other places and your
specific can't and we would need the generic one anyway).
"Generic" is not about "multiple places". Generic is about "general"
as opposite to "specific". Gives you flexibility and wider application
range.
^ permalink raw reply
* Re: git log -S problem
From: Junio C Hamano @ 2007-05-20 21:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200705202115.39325.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> There is something odd with -S of git log. Try this in your git.git:
>
> $ git log --pretty=oneline -Sbuiltin-merge-base -- Makefile
> 71dfbf224ff980f4085f75868dc409118418731e Make merge-base a built-in.
>
> $ git log --pretty=oneline -Smerge-base -- Makefile
> e468305a954d95a26bfcdec3bc6e4bd477d95676 [PATCH] Remove the explicit ...
> a3df180138b85a603656582bde6df757095618cf Rename git core commands ...
> cef661fc799a3a13ffdea4a3f69f1acd295de53d Add support for alternate ...
> e590d694ead8d50c2afc7086161d4ddc5d907655 Add more header dependencies.
> 6683463ed6b2da9eed309c305806f9393d1ae728 Do a very simple "merge-base"...
>
> $ git version
> git version 1.5.2
>
> I had expected that the set of commits found by the second search string are a
> proper superset of those found by the first one. What's wrong here? Why does
> a search for 'merge-base' not find occurences of 'builtin-merge-base'?
71dfbf224 removes one line that has "git-merge-base$X" and adds
one line that has "builtin-merge-base.o". If you count the
number of occurences of substring "builtin-merge-base" in the
preimage and the postimage, you see one addition. If you count
the same for substring "merge-base", the net difference is 0.
^ permalink raw reply
* Re: [PATCH] allow commands to be executed in submodules
From: Martin Waitz @ 2007-05-20 21:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20070520205933.GD25462@steel.home>
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
hoi :)
On Sun, May 20, 2007 at 10:59:33PM +0200, Alex Riesen wrote:
> Is there multiple places? Is it hard to create a specific function out
> of a generic one? (which can be used from other places and your
> specific can't and we would need the generic one anyway).
you can add a specific new function for submodules, dropping the
nice property of child_process that you only have to initialize a few
fields and then can run the command.
> "Generic" is not about "multiple places". Generic is about "general"
> as opposite to "specific". Gives you flexibility and wider application
> range.
Generic code and abstractions only make sense when they are _useful_.
Lets not overengineer it. If we later see that we need more, then
so be it. KISS.
But now lets go on and don't discuss about such details.
I'm happy if I can run commands in submodules and don't care about the
actual code.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-20 21:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20070520205444.GC25462@steel.home>
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
> > > I am very worried about this big red switch that says "all
> > > subprojects to be cloned and checked out, or nothing". I think
> > > this would not work well with projects that truly need
> > > superproject support (i.e. very large ones, where most people
> > > would not want to clone and check out every single subproject).
> >
> > It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
> > Since the subcloning only happens at checkout, you could set these
> > before doing a checkout.
>
> And set them back after doing the checkout?
What do you mean? Why would you set them back?
I guess I'm missing something.
> Me too. I actually believe it is the only way to do it. How can you
> checkout a subproject to something else (to what a branch may point)
> and to what the tree of superproject has? On the other side (in
> subproject) - why are you, the superproject, allowed to screw the
> references of the subproject?! It is independent, isn't it?!
Well... the subproject as a whole is independent of the superproject,
but the checkout in the superproject is not entirely independent.
> > > - What would we do when the subproject working tree is not
> > > clean?
> >
> > I was planning on adding a --dry-run to git-checkout.
> > The superproject would run this in each subproject before
> > doing the actual checkout of the superproject.
>
> Why not do exactly what we do now? Pass "-m" down to it, if it was
> given to the top-level git-checkout.
We want to be sure that all (selected) subprojects can be updated before
updating any, no?
skimo
^ permalink raw reply
* [PATCH] git-pack-objects: cache small deltas between big objects
From: Martin Koegler @ 2007-05-20 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Creating deltas between big blobs is a CPU and memory intensive task.
In the writing phase, all (not reused) deltas are redone.
This patch adds support for caching deltas from the deltifing phase, so
that that the writing phase is faster.
The caching is limited to small deltas to avoid increasing memory usage very much.
The implemented limit is (memory needed to create the delta)/1024.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
builtin-pack-objects.c | 35 +++++++++++++++++++++++++----------
1 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index d165f10..13429d0 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -35,6 +35,7 @@ struct object_entry {
struct object_entry *delta_sibling; /* other deltified objects who
* uses the same base as me
*/
+ void *delta_data; /* cached delta (uncompressed) */
unsigned long delta_size; /* delta data size (uncompressed) */
enum object_type type;
enum object_type in_pack_type; /* could be delta */
@@ -380,17 +381,24 @@ static unsigned long write_object(struct sha1file *f,
*/
if (!to_reuse) {
- buf = read_sha1_file(entry->sha1, &type, &size);
- if (!buf)
- die("unable to read %s", sha1_to_hex(entry->sha1));
- if (size != entry->size)
- die("object %s size inconsistency (%lu vs %lu)",
- sha1_to_hex(entry->sha1), size, entry->size);
- if (entry->delta) {
- buf = delta_against(buf, size, entry);
+ if (entry->delta_data) {
+ buf = entry->delta_data;
size = entry->delta_size;
obj_type = (allow_ofs_delta && entry->delta->offset) ?
- OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ } else {
+ buf = read_sha1_file(entry->sha1, &type, &size);
+ if (!buf)
+ die("unable to read %s", sha1_to_hex(entry->sha1));
+ if (size != entry->size)
+ die("object %s size inconsistency (%lu vs %lu)",
+ sha1_to_hex(entry->sha1), size, entry->size);
+ if (entry->delta) {
+ buf = delta_against(buf, size, entry);
+ size = entry->delta_size;
+ obj_type = (allow_ofs_delta && entry->delta->offset) ?
+ OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ }
}
/*
* The object header is a byte of 'type' followed by zero or
@@ -1294,10 +1302,17 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
if (!delta_buf)
return 0;
+ if (trg_entry->delta_data)
+ free (trg_entry->delta_data);
+ trg_entry->delta_data = 0;
trg_entry->delta = src_entry;
trg_entry->delta_size = delta_size;
trg_entry->depth = src_entry->depth + 1;
- free(delta_buf);
+ /* cache delta, if objects are large enough compared to delta size */
+ if ((src_size >> 20) + (trg_size >> 21) > (delta_size >> 10))
+ trg_entry->delta_data = delta_buf;
+ else
+ free(delta_buf);
return 1;
}
--
1.5.2.rc3.802.g4b4b7
^ permalink raw reply related
* Re: [PATCH 09/15] entry.c: optionally checkout submodules
From: Martin Waitz @ 2007-05-20 21:18 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <11796842892490-git-send-email-skimo@liacs.nl>
[-- Attachment #1: Type: text/plain, Size: 284 bytes --]
hoi :)
have you seen my patch to checkout submodules?
The submodule checkout should really check that the requested commit
is really available and have some other path for creating submodules
which are not currently checked out / able to be checked out.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'
From: Robin Rosenberg @ 2007-05-20 21:22 UTC (permalink / raw)
To: catalin.marinas; +Cc: ydirson, git
In-Reply-To: <20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1520 bytes --]
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
söndag 20 maj 2007 skrev Yann Dirson:
> Note that "tail -1" gives a warning with newer versions, "tail -n 1"
> should be the proper call.
My man page doesn't mention -N being deprecated, but ok since -n 1 seems
to work here too.
> Also I'm not sure it is a good way to look at "applied" file, since
> Karl IIRC has plans to change this. Better call "stg top" and not
> touch that again :)
Calling stg is too slow to be be used here. I that command in my first draft
for this function and people complained (see the thread named "Bash snippet
to show branch and patch in bash prompt"). It takes ~ 0.15s on here which is
very noticable, barely below my pain threshold.
We'll update the prompt when and if Karl breaks this.
It'd probably drain my battery too :/
-- robin
contrib/stgbashprompt.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh
index 16bb39b..f4817a1 100755
--- a/contrib/stgbashprompt.sh
+++ b/contrib/stgbashprompt.sh
@@ -8,8 +8,8 @@ if [ "$PS1" ]; then
git_dir=$(git-rev-parse --git-dir 2> /dev/null) || return
ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
br=${ref#refs/heads/}
- top=$(cat $git_dir/patches/$br/current 2>/dev/null) \
- && top="/$top"
+ top=$(tail -n 1 $git_dir/patches/$br/applied 2>/dev/null) \
+ && top="/$top";
echo "[$br$top]"
}
PS1='\u@\h:$(__prompt_git)\W\$ '
^ permalink raw reply related
* Re: [PATCH 06/15] git-read-tree: take --submodules option
From: Martin Waitz @ 2007-05-20 21:24 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <11796842893584-git-send-email-skimo@liacs.nl>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
hoi :)
what really is the motivation to suppress submodule checkout at this
level? I can see that we need some per-submodule option for checkout,
but this should influence the actual checkout process and not
read-tree.
At least we really want to always update the index correctly and a
read-tree --no-submodules which updates the index for submodules but
doesn't go into existing submodules just feels wrong.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Alex Riesen @ 2007-05-20 21:24 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070520210954.GB942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege, Sun, May 20, 2007 23:09:54 +0200:
> On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> > Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
> > > > I am very worried about this big red switch that says "all
> > > > subprojects to be cloned and checked out, or nothing". I think
> > > > this would not work well with projects that truly need
> > > > superproject support (i.e. very large ones, where most people
> > > > would not want to clone and check out every single subproject).
> > >
> > > It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
> > > Since the subcloning only happens at checkout, you could set these
> > > before doing a checkout.
> >
> > And set them back after doing the checkout?
>
> What do you mean? Why would you set them back?
Why should I set them before doing a checkout?
> I guess I'm missing something.
"checkout" is an operation which is done often. It never had to be
configured before.
> > Me too. I actually believe it is the only way to do it. How can you
> > checkout a subproject to something else (to what a branch may point)
> > and to what the tree of superproject has? On the other side (in
> > subproject) - why are you, the superproject, allowed to screw the
> > references of the subproject?! It is independent, isn't it?!
>
> Well... the subproject as a whole is independent of the superproject,
> but the checkout in the superproject is not entirely independent.
>
Junio was talking about branch in subproject, wasn't he?
> > > > - What would we do when the subproject working tree is not
> > > > clean?
> > >
> > > I was planning on adding a --dry-run to git-checkout.
> > > The superproject would run this in each subproject before
> > > doing the actual checkout of the superproject.
> >
> > Why not do exactly what we do now? Pass "-m" down to it, if it was
> > given to the top-level git-checkout.
>
> We want to be sure that all (selected) subprojects can be updated before
> updating any, no?
>
I guess passing "-m" to git-checkout _is_ an explicit permission from
the operator to perform a merge. Besides, it's visible: merge prints
something, user sees the "-m" in command history (or in script code).
Calling git-checkout twice even if we don't have to... it is kind of
ugly. Still need some dry-run this for normal case (checkout can be
modified to do this by default, I think).
^ permalink raw reply
* [PATCH 2/2] Don't use / as separatar since it is common i branch names
From: Robin Rosenberg @ 2007-05-20 21:24 UTC (permalink / raw)
To: catalin.marinas; +Cc: ydirson, git
In-Reply-To: <20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net>
Don't use / as separatar since it is common i branch names
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh
index f4817a1..5927e67 100755
--- a/contrib/stgbashprompt.sh
+++ b/contrib/stgbashprompt.sh
@@ -9,8 +9,8 @@ if [ "$PS1" ]; then
ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
br=${ref#refs/heads/}
top=$(tail -n 1 $git_dir/patches/$br/applied 2>/dev/null) \
- && top="/$top";
- echo "[$br$top]"
+ top=${top:-(none)}
+ echo "[$top@$br]"
}
PS1='\u@\h:$(__prompt_git)\W\$ '
fi
^ permalink raw reply related
* Re: [PATCH 1/6] Remove whitespace breakage from *.c files
From: Junio C Hamano @ 2007-05-20 21:36 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <4650222D.4070707@gmail.com>
Your MUA seem to have munged all your patches in this series;
and the breakage seems also to be in the "let apply eat the new
trailing blank lines" patch.
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-20 21:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070520205444.GC25462@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
hoi :)
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> Me too. I actually believe it is the only way to do it. How can you
> checkout a subproject to something else (to what a branch may point)
> and to what the tree of superproject has? On the other side (in
> subproject) - why are you, the superproject, allowed to screw the
> references of the subproject?! It is independent, isn't it?!
right. except when you have some managed-by-superproject branch
which is known to be special ;-)
After all the submodule checkout is independent from its parent
repository, too -- so you don't screw anything *g*.
> > > - What would we do when the subproject working tree is not
> > > clean?
> >
> > I was planning on adding a --dry-run to git-checkout.
> > The superproject would run this in each subproject before
> > doing the actual checkout of the superproject.
>
> Why not do exactly what we do now? Pass "-m" down to it, if it was
> given to the top-level git-checkout.
sounds good.
With submodules we have to consider one extra level of merging.
-m in the supermodule also means that an automatic merge of the
dirlink entry should be done. Which would execute git-merge in the
submodule. And merging in a dirty tree is a challenge of its own.
So if local changes conflict with the checkout we should just error out.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RFC: submodule terminology
From: Martin Waitz @ 2007-05-20 21:44 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
hoi :)
I think we should agree to one name for what currently is named
submodule / subproject / dirlink / gitlink.
Or use one name for the low-level plumbing (have a tree entry
which points to another commit): dirlink or gitlink and another
one for the high-level UI think: submodule or subproject.
But then we should use those names consequently.
Oppinions?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-20 21:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20070520212432.GE25462@steel.home>
On Sun, May 20, 2007 at 11:24:32PM +0200, Alex Riesen wrote:
> Sven Verdoolaege, Sun, May 20, 2007 23:09:54 +0200:
> > On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> > > Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
> > > > > I am very worried about this big red switch that says "all
> > > > > subprojects to be cloned and checked out, or nothing". I think
> > > > > this would not work well with projects that truly need
> > > > > superproject support (i.e. very large ones, where most people
> > > > > would not want to clone and check out every single subproject).
> > > >
> > > > It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
> > > > Since the subcloning only happens at checkout, you could set these
> > > > before doing a checkout.
> > >
> > > And set them back after doing the checkout?
> >
> > What do you mean? Why would you set them back?
>
> Why should I set them before doing a checkout?
>
> > I guess I'm missing something.
>
> "checkout" is an operation which is done often. It never had to be
> configured before.
There is going to have to be *some* way of selecting which
subprojects you want to check out. A config option that you
have to set only once (or not at all if you are happy with
the default) seems to be the easiest way. You can have git-gui
set them for you if you want.
How would _you_ specify which subprojects to checkout ?
> > Well... the subproject as a whole is independent of the superproject,
> > but the checkout in the superproject is not entirely independent.
> >
>
> Junio was talking about branch in subproject, wasn't he?
That's a local thing.
skimo
^ permalink raw reply
* Re: [PATCH 06/15] git-read-tree: take --submodules option
From: Sven Verdoolaege @ 2007-05-20 21:50 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <20070520212404.GK5412@admingilde.org>
On Sun, May 20, 2007 at 11:24:04PM +0200, Martin Waitz wrote:
> hoi :)
>
> what really is the motivation to suppress submodule checkout at this
> level? I can see that we need some per-submodule option for checkout,
> but this should influence the actual checkout process and not
> read-tree.
It's only used with update is set.
> At least we really want to always update the index correctly and a
> read-tree --no-submodules which updates the index for submodules but
> doesn't go into existing submodules just feels wrong.
It doesn't do that.
skimo
^ permalink raw reply
* Re: [PATCH 09/15] entry.c: optionally checkout submodules
From: Sven Verdoolaege @ 2007-05-20 21:51 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <20070520211850.GJ5412@admingilde.org>
On Sun, May 20, 2007 at 11:18:50PM +0200, Martin Waitz wrote:
> hoi :)
>
> have you seen my patch to checkout submodules?
Not yet. I'll look for it in the morning.
skimo
^ permalink raw reply
* Re: [PATCH 02/15] git-config: add --remote option for reading config from remote repo
From: Frank Lichtenheld @ 2007-05-20 22:03 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <20070520194448.GW942MdfPADPa@greensroom.kotnet.org>
On Sun, May 20, 2007 at 09:44:48PM +0200, Sven Verdoolaege wrote:
> On Sun, May 20, 2007 at 08:11:55PM +0200, Frank Lichtenheld wrote:
> > On Sun, May 20, 2007 at 08:04:35PM +0200, skimo@liacs.nl wrote:
> > > From: Sven Verdoolaege <skimo@kotnet.org>
> > >
> > > Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
> > > ---
> > > Documentation/git-config.txt | 33 +++++++++++++++++++++---------
> >
> > All my old suggestions and corrections for the documentation
> > part still apply... should I repeat them?
>
> I did the [scope] thing, but it seems I inadvertedly threw it out.
> I guess I'll have to do it again.
>
> Was there anything else?
You list --remote for all variants while it is not really supported for
them. Although this problem probably implicetly goes away if you use
scope and later explain what that means.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: RFC: submodule terminology
From: Johan Herland @ 2007-05-20 22:06 UTC (permalink / raw)
To: git; +Cc: Martin Waitz
In-Reply-To: <20070520214417.GM5412@admingilde.org>
On Sunday 20 May 2007, Martin Waitz wrote:
> hoi :)
>
> I think we should agree to one name for what currently is named
> submodule / subproject / dirlink / gitlink.
>
> Or use one name for the low-level plumbing (have a tree entry
> which points to another commit): dirlink or gitlink and another
> one for the high-level UI think: submodule or subproject.
> But then we should use those names consequently.
>
> Oppinions?
For the high-level concept, "subproject" seems to me the best
alternative. I think it is much better than "submodule" at
describing that the subproject is a stand-alone project/repo in
itself.
As for the low-level concept, I personally prefer "gitlink", but
I don't have any strong feelings. The fact that "gitlink" seems
to already be used in the code (as in resolve_gitlink_ref() etc.),
coupled with "dirlink" being somewhat ambiguous (i.e. may also be
interpreted as "(sym)link to directory") makes the case for me.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] t1300: Add tests for git-config --bool --get
From: Frank Lichtenheld @ 2007-05-20 22:12 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
Noticed that there were only tests for --int, but not
for --bool. Add some.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t1300-repo-config.sh | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index a1d777c..3f3fd2d 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -436,6 +436,40 @@ test_expect_success numbers '
test z1048576 = "z$m"
'
+cat > expect << EOF
+true
+false
+true
+false
+true
+false
+true
+false
+EOF
+
+test_expect_success bool '
+
+ git-config bool.true1 01 &&
+ git-config bool.true2 -1 &&
+ git-config bool.true3 YeS &&
+ git-config bool.true4 true &&
+ git-config bool.false1 000 &&
+ git-config bool.false2 "" &&
+ git-config bool.false3 nO &&
+ git-config bool.false4 FALSE &&
+ rm -f result &&
+ for i in 1 2 3 4
+ do
+ git-config --bool --get bool.true$i >>result
+ git-config --bool --get bool.false$i >>result
+ done &&
+ cmp expect result'
+
+test_expect_failure 'invalid bool' '
+
+ git-config bool.nobool foobar &&
+ git-config --bool --get bool.nobool'
+
rm .git/config
git-config quote.leading " test"
--
1.5.2-rc3.GIT
^ permalink raw reply related
* [PATCH] git-config: Correct asciidoc documentation for --int/--bool
From: Frank Lichtenheld @ 2007-05-20 22:12 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
In-Reply-To: <11796991783280-git-send-email-frank@lichtenheld.de>
The asciidoc documentation seemed to indicate that type specifiers
are honoured on writing operations which they aren't. Make this
more clear.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-config.txt | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 280ef20..827a499 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -9,15 +9,15 @@ git-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
-'git-config' [--system | --global] [type] name [value [value_regex]]
-'git-config' [--system | --global] [type] --add name value
-'git-config' [--system | --global] [type] --replace-all name [value [value_regex]]
+'git-config' [--system | --global] name [value [value_regex]]
+'git-config' [--system | --global] --add name value
+'git-config' [--system | --global] --replace-all name [value [value_regex]]
'git-config' [--system | --global] [type] --get name [value_regex]
'git-config' [--system | --global] [type] --get-all name [value_regex]
-'git-config' [--system | --global] [type] --unset name [value_regex]
-'git-config' [--system | --global] [type] --unset-all name [value_regex]
-'git-config' [--system | --global] [type] --rename-section old_name new_name
-'git-config' [--system | --global] [type] --remove-section name
+'git-config' [--system | --global] --unset name [value_regex]
+'git-config' [--system | --global] --unset-all name [value_regex]
+'git-config' [--system | --global] --rename-section old_name new_name
+'git-config' [--system | --global] --remove-section name
'git-config' [--system | --global] -l | --list
DESCRIPTION
@@ -36,7 +36,8 @@ prepend a single exclamation mark in front (see EXAMPLES).
The type specifier can be either '--int' or '--bool', which will make
'git-config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
-a "true" or "false" string for bool). If no type specifier is passed,
+a "true" or "false" string for bool). Type specifiers currently only
+take effect for reading operations. If no type specifier is passed,
no checks or transformations are performed on the value.
This command will fail if:
--
1.5.2-rc3.GIT
^ permalink raw reply related
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-20 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, git
In-Reply-To: <7vhcq7l3ar.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]
hoi :)
On Sun, May 20, 2007 at 12:10:04PM -0700, Junio C Hamano wrote:
> The more important issue I think is at what point in the
> superproject operation does a recursive checkout in a subproject
> should happen, and how we should do the checkout.
we should really move from our big clone thing to a simple
fetch+checkout wrapper.
And then integrate all the submodule logic into the actual checkout
step where it belongs.
We might also want to expand fetch to also fetch newly reachable
submodule commits (of a configurable subset of modules).
> Issues I can think of offhand are (no way exhaustive):
>
> - Do we checkout a branch? if so which one?
At least no off-the-shelf branch from the upstream repository of
the submodule.
To use some special branch allows to use normal git methods in
the submodule, too -- but I haven't been able to convince everybody
yet... So let's get it to a state where people can play with it
in real projects and let's see.
> - Do we detach HEAD if the commit named by the superproject
> tree is not at the tip of the current branch of subproject?
> do we detach always even if the commit is at the tip?
We must not mess with random upstream branches of the submodule
just because they happen to reference the same tip.
That would be too confusing.
Either use one special branch or detach.
> - What would we do when the subproject working tree is not
> clean?
The same as with normal files:
error out if something is changed which conflicts with the requested
update.
When we have a special managed-by-supermodule branch and the submodule
has another branch currently checked out we can entirely ignore this
issue.
This really allows the user to deliberately keep one module in an
unclean state.
> - How can a user decide which subproject to descend into and
> which subproject to ignore, and how does git remember the
> earlier decision made by the user without asking the same
> again, and how does a user express "now I want to also track
> that subproject I've ignored so far" and "now I am not
> interested in following that subproject anymore"?
I'd simply use explicit checkout of a submodule and removal of
the submodule to be a fine way to express the user's wish.
Of course we also need some way to say: populate everything
below "src/target" or similar. But that is independent from
the rest.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Alex Riesen @ 2007-05-20 22:24 UTC (permalink / raw)
To: Martin Waitz; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070520214026.GL5412@admingilde.org>
Martin Waitz, Sun, May 20, 2007 23:40:26 +0200:
> > > > - What would we do when the subproject working tree is not
> > > > clean?
> > >
> > > I was planning on adding a --dry-run to git-checkout.
> > > The superproject would run this in each subproject before
> > > doing the actual checkout of the superproject.
> >
> > Why not do exactly what we do now? Pass "-m" down to it, if it was
> > given to the top-level git-checkout.
>
> sounds good.
> With submodules we have to consider one extra level of merging.
> -m in the supermodule also means that an automatic merge of the
> dirlink entry should be done. Which would execute git-merge in the
> submodule. And merging in a dirty tree is a challenge of its own.
But it is not a merge. It is a checkout. Being another operation it
may even be disallow merges of subprojects. Just plainly tell user
that this checkout is not possible because there are changes in
subprojects and in the pointer to this subproject in the upper level
superproject, and that the user should think about committing in
subproject first.
> So if local changes conflict with the checkout we should just error out.
On account of it being too complex. Always a good reason.
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Alex Riesen @ 2007-05-20 22:26 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070520214732.GC942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege, Sun, May 20, 2007 23:47:32 +0200:
>
> How would _you_ specify which subprojects to checkout ?
>
Aren't the ones which already have .git in them are kind of specified?
^ permalink raw reply
* [PATCH 1/3] t9400: Add test cases for config file handling
From: Frank Lichtenheld @ 2007-05-20 22:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Martin Langhoff, Frank Lichtenheld
Add a few test cases for the config file parsing
done by git-cvsserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t9400-git-cvsserver-server.sh | 69 +++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
Note that this currently has one failing test. This will need
to be fixed in git-cvsserver though.
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index d406a88..1b63435 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -47,6 +47,75 @@ test_expect_success 'basic checkout' \
'GIT_CONFIG="$git_config" cvs -Q co -d cvswork master &&
test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"'
+#--------------
+# CONFIG TESTS
+#--------------
+
+test_expect_success 'gitcvs.enabled = false' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
+ if GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1
+ then
+ echo unexpected cvs success
+ false
+ else
+ true
+ fi &&
+ cat cvs.log | grep -q "GITCVS emulation disabled" &&
+ test ! -d cvswork2'
+
+rm -fr cvswork2
+test_expect_success 'gitcvs.ext.enabled = true' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
+ GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2'
+
+rm -fr cvswork2
+test_expect_success 'gitcvs.ext.enabled = false' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled false &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ if GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1
+ then
+ echo unexpected cvs success
+ false
+ else
+ true
+ fi &&
+ cat cvs.log | grep -q "GITCVS emulation disabled" &&
+ test ! -d cvswork2'
+
+rm -fr cvswork2
+test_expect_success 'gitcvs.dbname' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs.%a.%m.sqlite &&
+ GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2 &&
+ test -f "$SERVERDIR/gitcvs.ext.master.sqlite" &&
+ cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs.ext.master.sqlite"'
+
+rm -fr cvswork2
+test_expect_success 'gitcvs.ext.dbname' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite &&
+ GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2 &&
+ test -f "$SERVERDIR/gitcvs1.ext.master.sqlite" &&
+ test ! -f "$SERVERDIR/gitcvs2.ext.master.sqlite" &&
+ cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs1.ext.master.sqlite"'
+
+
+#------------
+# CVS UPDATE
+#------------
+
+rm -fr "$SERVERDIR"
+cd "$WORKDIR" &&
+git clone -q --local --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
+GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+GIT_DIR="$SERVERDIR" git config --bool gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
+exit 1
+
test_expect_success 'cvs update (create new file)' \
'echo testfile1 >testfile1 &&
git add testfile1 &&
--
1.5.2-rc3.GIT
^ permalink raw reply related
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