* Re: [PATCH] Update bash completion to ignore some more plumbing commands
From: Shawn O. Pearce @ 2007-05-21 6:12 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Junio C Hamano
In-Reply-To: <20070519213521.GA32221@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
> contrib/completion/git-completion.bash | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
OK, sorry this missed 1.5.2. I've applied it into my fastimport
master branch, I guess it will be in the next 1.5.2 based release.
;-)
> I am not sure if it is OK to exclude checkout-index as it is
> the only method of exporting the source as a directory. Also,
It might make sense to exclude checkout-index as plumbing, but I
use it myself so often (and tab complete it too) that I want to
keep it in. So I deleted that one line out of your patch when I
applied it.
> I don't understand why git-diff-* is not excluded.
Because I personally also use git diff-tree a lot. The others
(diff-files, diff-index) I *never* use directly so I'm thinking
maybe they should get flagged as plumbing and get removed from
the completion.
--
Shawn.
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Shawn O. Pearce @ 2007-05-21 6:02 UTC (permalink / raw)
To: René Scharfe
Cc: git, Junio C Hamano, Frank Lichtenheld, Johan Herland,
Thomas Glanzmann, Michael Gernoth
In-Reply-To: <46502EF7.6000708@lsrfire.ath.cx>
Ren?? Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Shawn O. Pearce schrieb:
> >
> > git-describe is more human-friendly than a SHA-1...
>
> Yes, and the Makefile does even more than that: it adds a version file,
> a spec file and another version file for git-gui.
>
> The first two are probably useful for most projects that actually do
> versioned releases. We could have a simple parser that reads a
> template, replaces @@VERSION@@ with a git-describe output string and
> adds the result as a synthetic file to the archive. It's not exactly
> trivial -- e.g., how to specify git-describe options, template file and
> synthetic name, all in one command line parameter? -- but it's doable.
Maybe something just as simple as allowing the user to specify a
shell script in-tree that we unpack and run for them? That script
prints to stdout the content of the file to include.
> I'm not sure how the git-gui version file fits in. I guess it's just a
> special case and doesn't need git-archive support?
Well, if you look at git-gui's own version script it really just
wants to do `git-describe` like git.git's script, but it cannot as
when its hosted in git.git `git-describe` gives us back Git's version
number, not git-gui's version number. So we get cute and look for
the merge commit, and take the second parent, and describe that.
That's (by convention of how Junio works) always a true git-gui
commit.
In other words, git-gui.git gets a little whacky when Junio
distributes it in git.git. git-gui really needs to become
a subproject. When that happens its git-describe will become
much easier.
So now we're also really talking about, what should git-archive
do for a subproject? Sometimes you really do want to repackage
and redistribute the subproject as part of the superproject's
tarball. Sometimes you don't. I think in the case of git.git and
git-gui.git we want to include the subproject. ;-)
--
Shawn.
^ permalink raw reply
* Re: git log -S problem
From: Johannes Sixt @ 2007-05-21 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, j.sixt
In-Reply-To: <7vy7jjjjdm.fsf@assigned-by-dhcp.cox.net>
On Sunday 20 May 2007 23:05, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > 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.
But is this how -S is *designed* to work?
Hm, the documentation says (diff-options.txt):
-S<string>::
Look for differences that contain the change in <string>.
which can be interpreted both to match my expectations as well as the current
implementation.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-pack-objects: cache small deltas between big objects
From: Junio C Hamano @ 2007-05-21 4:54 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <11796954641778-git-send-email-mkoegler@auto.tuwien.ac.at>
Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> 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(-)
This is an interesting idea.
> 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
> ...
> @@ -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;
> }
Care to justify this arithmetic? Why isn't it for example like
this?
((src_size + trg_size) >> 10) > delta_size
I am puzzled by the shifts on both ends, and differences between
20 and 21.
^ permalink raw reply
* Re: [PATCH] git-pack-objects: cache small deltas between big objects
From: Dana How @ 2007-05-21 4:35 UTC (permalink / raw)
To: Martin Koegler; +Cc: Junio C Hamano, git, danahow
In-Reply-To: <11796954641778-git-send-email-mkoegler@auto.tuwien.ac.at>
On 5/20/07, Martin Koegler <mkoegler@auto.tuwien.ac.at> wrote:
> Creating deltas between big blobs is a CPU and memory intensive task.
> In the writing phase, all (not reused) deltas are redone.
Actually, just the ones selected, which is approx 1/window.
Do you have any numbers describing the effects on runtime
and memory size for a known repo like linux-2.6?
> 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.
Your limit is applied per-object, and there is no overall limit
on the amount of memory not freed in the delta phase.
I suspect this caching would be disastrous for the large repo
with "megablobs" I'm trying to wrestle with at the moment.
> @@ -1294,10 +1302,17 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
> 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;
> }
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: RFC: submodule terminology
From: Eric Lesh @ 2007-05-21 0:32 UTC (permalink / raw)
To: Martin Waitz; +Cc: Johan Herland, git
In-Reply-To: <20070520233913.GT5412@admingilde.org>
On Mon, 2007-05-21 at 01:39 +0200, Martin Waitz wrote:
> hoi :)
>
> On Mon, May 21, 2007 at 01:16:24AM +0200, Johan Herland wrote:
> > The term "gitlink" is ambiguous/confusing? I didn't know. What's the
> > other meaning of gitlink?
>
> there was some talk about lightweight checkouts using some .gitlink
> file instead of a .git directory.
>
This was my project, but if I end up trying to do lightweight checkouts
I'll avoid a .gitlink file most likely (and go with something
in .git/config instead). Gitlink is therefore quite safe.
-Eric
^ permalink raw reply
* [PATCH] Remove USE_PAGER from git-pickaxe
From: Andrew Ruder @ 2007-05-21 3:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
git-blame (and friends) specifically leave the pager turned
off in the case that --incremental is specified as this isn't
for human consumption. git-pickaxe will turn it on itself
otherwise.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index eeb2c0c..2f25807 100644
--- a/git.c
+++ b/git.c
@@ -267,7 +267,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "mv", cmd_mv, RUN_SETUP | NOT_BARE },
{ "name-rev", cmd_name_rev, RUN_SETUP },
{ "pack-objects", cmd_pack_objects, RUN_SETUP },
- { "pickaxe", cmd_blame, RUN_SETUP | USE_PAGER },
+ { "pickaxe", cmd_blame, RUN_SETUP },
{ "prune", cmd_prune, RUN_SETUP },
{ "prune-packed", cmd_prune_packed, RUN_SETUP },
{ "push", cmd_push, RUN_SETUP },
--
1.5.2.15.g56fe-dirty
^ permalink raw reply related
* Re: [PATCH] Teach mailsplit about Maildir's
From: Junio C Hamano @ 2007-05-21 3:15 UTC (permalink / raw)
To: Fernando J. Pereda; +Cc: Git Mailing List
In-Reply-To: <20070520181447.GA10638@ferdyx.org>
"Fernando J. Pereda" <ferdy@gentoo.org> writes:
> - ret = split_mbox(argp, dir, allow_bare, nr_prec, nr);
> + while (*argp) {
> + const char *arg = *argp++;
> + struct stat argstat;
> +
> + if (arg[0] == '-' && arg[1] == 0) {
> + ret |= split_mbox(arg, dir, allow_bare, nr_prec, nr);
> + continue;
> + }
> +
> + if (stat(arg, &argstat) == -1) {
> + error("cannot stat %s (%s)", arg, strerror(errno));
> + return 1;
> + }
> +
> + if (S_ISDIR(argstat.st_mode))
> + ret |= split_maildir(arg, dir, nr_prec, nr);
> + else
> + ret |= split_mbox(arg, dir, allow_bare, nr_prec, nr);
> + }
> +
> if (ret != -1)
> printf("%d\n", ret);
>
No kidding. ret |= stuff and then printf("%d\n", ret) would not
give us the number of commit e-mails on the standard output.
^ permalink raw reply
* [TRIVIAL PATCH 1/1] Make git-annotate use RUN_SETUP
From: Andrew Ruder @ 2007-05-21 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The USE_PAGER was unnecessary as git-blame/git-annotate specifically
setup the pager when --incremental is not specified.
Prior to this patch git annotate somefileinasubdirectory.c would fail
(while git blame somefileinasubdirectory.c would succeed).
Signed-off-by: Andrew Ruder <andy@aeruder.net>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index f200907..eeb2c0c 100644
--- a/git.c
+++ b/git.c
@@ -225,7 +225,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
int option;
} commands[] = {
{ "add", cmd_add, RUN_SETUP | NOT_BARE },
- { "annotate", cmd_annotate, USE_PAGER },
+ { "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply },
{ "archive", cmd_archive },
{ "blame", cmd_blame, RUN_SETUP },
--
1.5.2.14.g45bde-dirty
^ permalink raw reply related
* [PATCH] Make sure an autogenerated version has at least four parts
From: Sam Vilain @ 2007-05-21 2:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
Otherwise, a custom "v1.5.2.42.gd00b" is considered newer than a
"v1.5.2.1.69.gcafe".
Warning: contains awk.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
GIT-VERSION-GEN | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 06c360b..5eb58c3 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -18,7 +18,7 @@ elif test -d .git &&
v[0-9]*) : happy ;;
esac
then
- VN=$(echo "$VN" | sed -e 's/-/./g');
+ VN=$(echo "$VN" | awk -F- 'X=$1 { Y=$2; Z=$3; while (!(X ~ /\..*\..*\./)) { X = X ".0" } print X ( Y ? "." Y : "" ) ( Z ? "." Z : "" ) }');
else
VN="$DEF_VER"
fi
--
1.5.1.1.175.g31e4
^ permalink raw reply related
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Jakub Narebski @ 2007-05-21 1:10 UTC (permalink / raw)
To: git
In-Reply-To: <20070519125055.GQ942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege wrote:
> On Fri, May 18, 2007 at 02:08:04PM +0300, Michael S. Tsirkin wrote:
>> How about an ability for git-daemon to get commands with git-config?
>
> You mean something like dump-config ?
Why not use tags, e.g. refs/tags/config tag to blob, or lightweight
tag to blob?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] t9400: Add test cases for config file handling
From: Junio C Hamano @ 2007-05-21 0:57 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Martin Langhoff
In-Reply-To: <11797003182642-git-send-email-frank@lichtenheld.de>
This part seems to fail for me and gets an "unexpected cvs success".
+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'
+
I think the per-method enablement logic is not quite right.
-- >8 --
git-cvsserver: ignore global config when per-method config disables an access.
When the per-method enable logic disables the access, we should
not even look at the global one.
git-cvsserver.perl | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index fcfb99d..1de5177 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -192,11 +192,9 @@ sub req_Root
}
}
- unless ( ($cfg->{gitcvs}{$state->{method}}{enabled}
- and $cfg->{gitcvs}{$state->{method}}{enabled} =~ /^\s*(1|true|yes)\s*$/i)
- or ($cfg->{gitcvs}{enabled}
- and $cfg->{gitcvs}{enabled} =~ /^\s*(1|true|yes)\s*$/i) )
- {
+ my $enabled = ($cfg->{gitcvs}{$state->{method}}{enabled}
+ || $cfg->{gitcvs}{enabled});
+ unless ($enabled && $enabled =~ /^\s*(1|true|yes)\s*$/i) {
print "E GITCVS emulation needs to be enabled on this repo\n";
print "E the repo config file needs a [gitcvs] section added, and the parameter 'enabled' set to 1\n";
print "E \n";
^ permalink raw reply related
* Re: [RFC] Third round of support for cloning submodules
From: Steven Grimm @ 2007-05-21 0:39 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070520195930.GX942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege wrote:
> 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.
>
Can I take this to mean that you intend the default behavior to be to
check out all subprojects, with individual ones suppressed via
configuration as needed?
Picture a corporate development environment with a common build system,
a couple common libraries, and a bunch of separate products. Product
developers will want to check out the build system (which would perhaps
be in the superproject), the libraries they need, and their own product.
They will rarely want to check out the other products, which could
account for the vast majority of the subprojects, and certainly won't
want to have to keep track of which new subprojects are appearing so
they can add those to the exclude list.
In other words, "I want the superproject and these four subprojects and
nothing else" should be a well-supported mode of operation. In many
cases developers will already know at clone time exactly what they want.
If I'm misunderstanding your intent, then never mind. :)
-Steve
^ permalink raw reply
* Re: RFC: submodule terminology
From: Martin Waitz @ 2007-05-20 23:39 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200705210116.25079.johan@herland.net>
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]
hoi :)
On Mon, May 21, 2007 at 01:16:24AM +0200, Johan Herland wrote:
> The term "gitlink" is ambiguous/confusing? I didn't know. What's the
> other meaning of gitlink?
there was some talk about lightweight checkouts using some .gitlink
file instead of a .git directory.
--
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: Martin Waitz @ 2007-05-20 23:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, skimo, git
In-Reply-To: <20070520225810.GH25462@steel.home>
[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]
hoi :)
On Mon, May 21, 2007 at 12:58:10AM +0200, Alex Riesen wrote:
> Martin Waitz, Mon, May 21, 2007 00:14:55 +0200:
> > > - 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.
>
> Strange. The very same reason I heard when I tried to explain why
> branches are good. The people found them confusing, just like you now.
> They preach Perforce, too.
Sorry, you lost me.
I didn't say that branches are bad but that guessing branch names based on
their tip is bad.
> > Either use one special branch or detach.
>
> Why not just detach always?
Which is just another name for "unnamed special branch" ;-)
When you give it a name you can actually use it even after you switched
to another one.
> > > - 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.
>
> This is called tree-level merge. Done by -m option (it does more than
> that, yes, but this one too). While at it we can do file-level merge
> as well, why not?
It's not that easy, for submodules we have different levels of dirty:
* submodule HEAD matches supermodule index, but submodule working
directory is dirty.
If the submodule update would touch any modified file then it should
fail.
If used with -m (or perhaps another option? after all this merge
is in a submodule) then it could do the file-level merge for dirty
files.
* submodule HEAD does not match supermodule index
normal checkout should error out if it would touch the submodule.
checkout -m has to merge submodule HEAD
And of course:
* index entry of submodule does not match the entry in supermodule HEAD.
Same as for files.
> > When we have a special managed-by-supermodule branch and the submodule
> > has another branch currently checked out we can entirely ignore this
> > issue.
>
> Detached head isn't special enough?
it's too special ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RFC: submodule terminology
From: Johan Herland @ 2007-05-20 23:16 UTC (permalink / raw)
To: git; +Cc: Martin Waitz
In-Reply-To: <20070520230352.GQ5412@admingilde.org>
On Monday 21 May 2007, Martin Waitz wrote:
> hoi :)
>
> On Mon, May 21, 2007 at 12:06:47AM +0200, Johan Herland wrote:
> > 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.
>
> it may be developed independently but for the sake of the more important
> bigger ("the top level project") it really is only one small part.
> That and the fact that "module" is already an established term
> in software makes me prefer "submodule".
> For me the project is always the top-level one: the project you
> currently work for.
"The project you currently work for" depends on your POV. But I agree
that using the term "project" alone might be confusing. That's why I'd
rather talk about "superproject" and "subproject". That way, there's
no ambiguity at all.
> > 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.
>
> The only problem I have with gitlink is that there already was
> a lot of discussion about some entirely different "gitlink", so
> choosing a different name is not that bad.
> Aside from that I prefer gitlink, too.
The term "gitlink" is ambiguous/confusing? I didn't know. What's the
other meaning of gitlink?
(Unless you're talking about gitlink as in "gitlink:git[7]" which
appears all over our asciidoc documentation, but I don't think that
counts...)
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFC] Implementing git config handling in Git.pm
From: Petr Baudis @ 2007-05-20 23:14 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20070520225953.GK4085@planck.djpig.de>
Hi,
On Mon, May 21, 2007 at 12:59:54AM CEST, Frank Lichtenheld wrote:
> Possible Solutions:
> 1) Call git-config.
> Pro: Easy to implement
> Contra: Violates at least target 2. Neither git-config --get nor
> git-config --list offer a complete and safe view on the config
> file. Just try including = in a subsection name (--list) or newlines in
> a value (both) to see what I mean.
> 2) Extend git-config to give a machine parsable output and then
> proceed with solution 1
> Pro: Still reasonably easy to implement (?). Would benefit
> other scripts, too.
> Contra: Neither the fastest nor the most flexible
> solution.
Yes, this might be fine for you. The argument for 4 (implementing our
own in Perl) is that we would like it to be _real_ fast for gitweb
(especially the summary page needs to look at each repository). But it
would be a question of a benchmark to look really how much would calling
git-config slow us down. So as at least a proof-of-concept and initial
implementation I think this is more than fine, and we can proceed to
implement our own parser only when it's clearly needed.
> 3) Try to use the C code from config.c directly.
> Pro: Probably the fastest solution due to avoiding the
> forks.
> Contra: Probably a bit more complex (any XS experts here?),
> both to implement and to maintain.
There was various trouble with XS in the past, and I think the general
feel was that we want to get back to using XS again sometime, but only
when Git will be reasonably libified (to support multiple repositories
at once, etc.).
> 4) Implement an own git config parser in Perl
> Pro: Might be actually easier than 3 and faster than 2
> Contra: See target 3
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-20 23:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070520230248.GI25462@steel.home>
[-- Attachment #1: Type: text/plain, Size: 538 bytes --]
hoi :)
On Mon, May 21, 2007 at 01:02:48AM +0200, Alex Riesen wrote:
> > If the user did commit and then you do a supermodule checkout -m you
> > will get a merge.
>
> Only if the user continue to use the last branch (or the detached
> head) the subproject was on. He don't have to, he can even return to
> the commit which does not conflict, unless he have to complicate
> things.
just curious:
so you want to differenciate between a subproject HEAD which was
set by the superproject and other ones?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RFC: submodule terminology
From: Johan Herland @ 2007-05-20 23:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Martin Waitz
In-Reply-To: <7v3b1rje45.fsf@assigned-by-dhcp.cox.net>
On Monday 21 May 2007, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
>
> > 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.
>
> I was wondering if we can get away by just calling them
> "projects", "projects containd in the superproject", etc., as I
> tend to agree with Linus, who used the term "superproject
> support" in his talk, that this is not really about creating
> "subproject" which are somehow different from ordinary projects,
> but more about supporting superprojects that can contain/point
> at other projects, which we did not have before 1.5.2 happened.
I agree that superproject is probably the best term of all. However,
I think it's a good idea to be explicit so as to avoid unnecessary
confusion. My vote therefore goes to "superproject/subproject"
rather than "superproject/project".
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: RFC: submodule terminology
From: Martin Waitz @ 2007-05-20 23:03 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200705210006.47266.johan@herland.net>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
hoi :)
On Mon, May 21, 2007 at 12:06:47AM +0200, Johan Herland wrote:
> 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.
it may be developed independently but for the sake of the more important
bigger ("the top level project") it really is only one small part.
That and the fact that "module" is already an established term
in software makes me prefer "submodule".
For me the project is always the top-level one: the project you
currently work for.
> 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.
The only problem I have with gitlink is that there already was
a lot of discussion about some entirely different "gitlink", so
choosing a different name is not that bad.
Aside from that I prefer gitlink, too.
--
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 23:02 UTC (permalink / raw)
To: Martin Waitz; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070520225521.GP5412@admingilde.org>
Martin Waitz, Mon, May 21, 2007 00:55:22 +0200:
> hoi :)
>
> On Mon, May 21, 2007 at 12:24:10AM +0200, Alex Riesen wrote:
> > 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.
>
> If the user did commit and then you do a supermodule checkout -m you
> will get a merge.
>
Only if the user continue to use the last branch (or the detached
head) the subproject was on. He don't have to, he can even return to
the commit which does not conflict, unless he have to complicate
things.
^ permalink raw reply
* [RFC] Implementing git config handling in Git.pm
From: Frank Lichtenheld @ 2007-05-20 22:59 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Petr Baudis
Hi.
A week ago or so when I presented my GITCVS::config patch I mentioned
that we should better implement most of it in Git.pm. I would like to
do so but get a bit of input first on how to implement it.
Targets:
1) We should offer to parse the config only once since that is
a huge performance gain if the caller wants to use several
values from it.
2) The parsing should be complete and safe.
3) If at all possible, we should not have to implement a
complete parser in Perl, since that is just needless
code to maintain.
Possible Solutions:
1) Call git-config.
Pro: Easy to implement
Contra: Violates at least target 2. Neither git-config --get nor
git-config --list offer a complete and safe view on the config
file. Just try including = in a subsection name (--list) or newlines in
a value (both) to see what I mean.
2) Extend git-config to give a machine parsable output and then
proceed with solution 1
Pro: Still reasonably easy to implement (?). Would benefit
other scripts, too.
Contra: Neither the fastest nor the most flexible
solution.
3) Try to use the C code from config.c directly.
Pro: Probably the fastest solution due to avoiding the
forks.
Contra: Probably a bit more complex (any XS experts here?),
both to implement and to maintain.
4) Implement an own git config parser in Perl
Pro: Might be actually easier than 3 and faster than 2
Contra: See target 3
I would go for solution 2. Any reason to prefer one of the
others (or one I didn't even think of)?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: RFC: submodule terminology
From: Junio C Hamano @ 2007-05-20 22:59 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Martin Waitz
In-Reply-To: <200705210006.47266.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> 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.
I was wondering if we can get away by just calling them
"projects", "projects containd in the superproject", etc., as I
tend to agree with Linus, who used the term "superproject
support" in his talk, that this is not really about creating
"subproject" which are somehow different from ordinary projects,
but more about supporting superprojects that can contain/point
at other projects, which we did not have before 1.5.2 happened.
> As for the low-level concept, I personally prefer "gitlink", but
> I don't have any strong feelings.
+1
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Alex Riesen @ 2007-05-20 22:58 UTC (permalink / raw)
To: Martin Waitz; +Cc: Junio C Hamano, skimo, git
In-Reply-To: <20070520221455.GN5412@admingilde.org>
Martin Waitz, Mon, May 21, 2007 00:14:55 +0200:
> > - 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.
Strange. The very same reason I heard when I tried to explain why
branches are good. The people found them confusing, just like you now.
They preach Perforce, too.
> Either use one special branch or detach.
Why not just detach always?
> > - 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.
This is called tree-level merge. Done by -m option (it does more than
that, yes, but this one too). While at it we can do file-level merge
as well, why not?
> When we have a special managed-by-supermodule branch and the submodule
> has another branch currently checked out we can entirely ignore this
> issue.
Detached head isn't special enough?
> > - 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.
The directory of the submodule will be back by the next
git-checkout-index (in the current implementation).
Not the .git's, so yes it is a fine way to express user's wish: he
just initialize the subprojects he wants (by whatever way).
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-20 22:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070520222410.GF25462@steel.home>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
hoi :)
On Mon, May 21, 2007 at 12:24:10AM +0200, Alex Riesen wrote:
> 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.
If the user did commit and then you do a supermodule checkout -m you
will get a merge.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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;
as well as URLs for NNTP newsgroup(s).