* Re: [PATCH] Don't allow newlines to occur in $Id:$ collapse
From: Andy Parkins @ 2007-05-25 13:50 UTC (permalink / raw)
To: git; +Cc: Joshua N Pritikin
In-Reply-To: <20070525132800.GH6667@always.joy.eth.net>
On Friday 2007 May 25, Joshua N Pritikin wrote:
> That's better but I would error out instead of silently ignoring it.
> Your choice.
We can't error out on checking a file out - that file is in the repository
already, if it's got problems - so be it, it's got to be possible to check it
out.
One could even argue that it's not actually an error, if we define keywords to
be such that they are not allowed to contain newlines, then the fact that
someone has written "$Id:" in their file, with no closing "$" just means that
it's not a keyword; and like every other non-keyword bit of data in the file
it should be left untouched.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Don't allow newlines to occur in $Id:$ collapse
From: Nicolas Pitre @ 2007-05-25 13:47 UTC (permalink / raw)
To: Joshua N Pritikin; +Cc: Andy Parkins, git
In-Reply-To: <20070525132800.GH6667@always.joy.eth.net>
On Fri, 25 May 2007, Joshua N Pritikin wrote:
> On Fri, May 25, 2007 at 02:13:42PM +0100, Andy Parkins wrote:
> > If a newline ever made it into an repository-side expanded $Id$ field,
> > the keyword would still be detected as a keyword and collapsed, before
> > rexpansion, e.g.
> >
> > $Id: all of this text would be removed, even if there
> > were a newline in the middle of it$
> >
> > This patch catches newlines in this case and abandons treating this as a
> > keyword expansion, this text would be left untouched in the working
> > checkout.
>
> That's better but I would error out instead of silently ignoring it.
> Your choice.
Erroring out in such a case would simply make the system too obnoxious.
I don't think it is really worth aborting a commit just because you have
a bad $Id:$ in one of your file.
Nicolas
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Lars Hjemli @ 2007-05-25 13:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0705251157450.4648@racer.site>
On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 25 May 2007, Lars Hjemli wrote:
>
> > There is currently no way to override the mappings in the .gitmodules
> > file, except by manually creating the subproject repository.
>
> I think that is okay. We can add that easily at a later stage, and the
> script is much easier without that logic.
Yes. And it is sort of a feature: if you've cloned the submodule using
a different (aka local) url, 'git submodule --init' will leave it
alone.
>
> > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
>
> Looks good here, I checked with asciidoc.
Thanks.
>
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > new file mode 100755
> > index 0000000..c4a1cc3
> > --- /dev/null
> > +++ b/git-submodule.sh
> > @@ -0,0 +1,163 @@
> > +#!/bin/sh
> > +#
> > +# git-submodule.sh: init, update or list git submodules
> > +#
> > +# Copyright (c) 2007 Lars Hjemli
> > +
> > +USAGE='[-i | --init | -u | --update] [-q | --quiet] [--cached] <path>...'
> > +. git-sh-setup
> > +require_work_tree
> > +
> > +init=
> > +update=
> > +quiet=
> > +cached=
> > +
> > +#
> > +# print stuff on stdout unless -q was specified
> > +#
> > +say()
> > +{
> > + if test -z "$quiet"
> > + then
> > + echo -e "$@"
> > + fi
> > +}
> > +
> > +#
> > +# Find all (requested) submodules, run clone + checkout on missing paths
> > +#
> > +# $@ = requested paths (default to all)
> > +#
> > +modules_init()
> > +{
> > + git ls-files --stage -- $@ | grep -e '^160000 ' |
>
> Any reason you read in the stage? It does not seem that you use it.
Are there any other way to get the mode info?
>
> > + while read mode sha1 stage path
> > + do
> > + test -d "$path/.git" && continue
> > +
> > + if test -d "$path"
> > + then
> > + rmdir "$path" 2>/dev/null ||
> > + die "Directory '$path' exist, but not as a submodule"
> > + fi
> > +
> > + test -e "$path" &&
> > + die "A file already exist at path '$path'"
> > +
> > + url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
>
> I like that command ;-)
>
> > + test -z "$url" &&
> > + die "No url found for submodule '$path' in .gitmodules"
> > +
> > + git-clone "$url" "$path" ||
> > + die "Clone of submodule '$path' failed"
> > +
> > + $(cd "$path" && git-checkout -q "$sha1") ||
> > + die "Checkout of submodule '$path' failed"
> > +
> > + say "Submodule '$path' initialized"
> > + done
> > +}
> > +
> > +#
> > +# Checkout correct revision of each initialized submodule
> > +#
> > +# $@ = requested paths (default to all)
> > +#
> > +modules_update()
> > +{
> > + git ls-files --stage -- $@ | grep -e '^160000 ' |
>
> Same here.
>
> > + while read mode sha1 stage path
> > + do
> > + if ! test -d "$path/.git"
> > + then
> > + say "Submodule '$path' not initialized"
> > + continue;
> > + fi
> > + subsha1=$(cd "$path" && git-rev-parse --verify HEAD) ||
>
> Maybe it would be a better idea to use "git --git-dir="$path" rev-parse
> ..."? Just in case somebody calls this with GIT_DIR overridden...
>
> Or, unset GIT_DIR explicitely.
Hmm, that's annoying (overridden GIT_DIR). I guess 'git --git-dir
$path/.git' would be the easiest solution.
>
> > + die "Unable to find current revision of submodule '$path'"
> > +
> > + if test "$subsha1" != "$sha1"
> > + then
> > + $(cd "$path" && git-fetch && git-checkout -q "$sha1") ||
>
> This will make a detached HEAD, right? Do you want that? (I am not really
> interested in submodules myself, so I haven't thought about it, and I
> haven't followed that monster discussion.)
Well, we might want to be smarter about this, but on the other hand:
if the user cares, he can always do 'cd $path && git checkout
$branch', since 'git submodule -u' will skip submodules with the
correct commit checked out.
>
> > + die "Unable to checkout revision $sha1 of submodule '$path'"
> > +
> > + say "Submodule '$path' reset to revision $sha1"
>
> I'd rather not say "reset", since this has a different meaning in Git, but
> rather "set to revision $sha1".
Ok.
>
> > + fi
> > + done
> > +}
> > +
> > +#
> > +# List all registered submodules, prefixed with:
> > +# - submodule not initialized
> > +# + different version checked out
> > +#
> > +# If --cached was specified the revision in the index will be printed
> > +# instead of the currently checked out revision.
> > +#
> > +# $@ = requested paths (default to all)
> > +#
> > +modules_list()
> > +{
> > + git ls-files --stage -- $@ | grep -e '^160000 ' |
> > + while read mode sha1 stage path
> > + do
> > + if ! test -d "$path/.git"
> > + then
> > + say "-$sha1 $path"
> > + continue;
> > + fi
> > + revname=$(cd "$path" && git-describe $sha1)
> > + if git diff-files --quiet -- "$path"
> > + then
> > + say " $sha1 $path\t($revname)"
> > + else
> > + if test -z "$cached"
> > + then
> > + sha1=$(cd "$path" && git-rev-parse --verify HEAD)
> > + revname=$(cd "$path" && git-describe $sha1)
> > + fi
> > + say "+$sha1 $path\t($revname)"
> > + fi
> > + done
> > +}
> > +
> > +
> > +while case "$#" in 0) break ;; esac
> > +do
> > + case "$1" in
> > + -i|--init)
> > + init=1
> > + ;;
> > + -u|--update)
> > + update=1
> > + ;;
> > + -q|--quiet)
> > + quiet=1
> > + ;;
> > + --cached)
> > + cached=1
> > + ;;
> > + --)
> > + break
> > + ;;
> > + -*)
> > + usage
> > + ;;
> > + *)
> > + break
> > + ;;
> > + esac
> > + shift
> > +done
> > +
> > +
> > +if test "$init" = "1"
> > +then
> > + modules_init $@
> > +elif test "$update" = "1"
> > +then
> > + modules_update $@
> > +else
> > + modules_list $@
> > +fi
>
> I'll let Junio comment on that command line parsing...
Heh, I'm a shell illiterate...
>
> All in all, I like it: it is short, to the point, and it should do the job
> (maybe with a few enhancements like "--update" without arguments means
> _all_ submodules).
Well, it does (or should) update all initialized submodules, but maybe
that's not what you meant?
Thanks for the review!
--
larsh
^ permalink raw reply
* Re: [PATCH] Enhance unpack-objects for extracting large objects
From: Nicolas Pitre @ 2007-05-25 13:41 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46569C37.5000201@gmail.com>
On Fri, 25 May 2007, Dana How wrote:
>
> Nicolas Pitre wrote:
> > I wouldn't mind a _separate_ tool that would load a pack index,
> > determine object sizes from it, and then extract big objects to write
> > them as loose objects ...
>
> Below we add two new options to git-unpack-objects:
>
> --min-blob-size=<n>:: Unpacking is only done for objects
> larger than or equal to n kB (uncompressed size by Junio).
>
> --force:: Loose objects will be created even if they
> already exist in the repository packed. This is an option
> I've wanted before for other reasons.
>
> This passes the tests in "t" but has not yet been used on my large repos.
> Based on "next" but should apply to "master" as well.
>
> Signed-off-by: Dana L. How <danahow@gmail.com>
This is clever, and the --force option is a nice thing to have. Not
that I find it particularly useful (I'd personally pack large objects
together rather than keeping them loose), but at least having the option
to explode any pack even in a live repository is a good thing to have at
the plumbing level given the simplicity of the patch.
ACK.
> ---
> Documentation/git-unpack-objects.txt | 17 +++++++++++++----
> builtin-unpack-objects.c | 20 ++++++++++++++++++--
> cache.h | 2 ++
> sha1_file.c | 11 +++++++++--
> 4 files changed, 42 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt
> index ff6184b..4513d8d 100644
> --- a/Documentation/git-unpack-objects.txt
> +++ b/Documentation/git-unpack-objects.txt
> @@ -8,7 +8,7 @@ git-unpack-objects - Unpack objects from a packed archive
>
> SYNOPSIS
> --------
> -'git-unpack-objects' [-n] [-q] [-r] <pack-file
> +'git-unpack-objects' [-n] [-q] [-r] [--force] [--min-blob-size=N] <pack-file
>
>
> DESCRIPTION
> @@ -17,9 +17,10 @@ Read a packed archive (.pack) from the standard input, expanding
> the objects contained within and writing them into the repository in
> "loose" (one object per file) format.
>
> -Objects that already exist in the repository will *not* be unpacked
> -from the pack-file. Therefore, nothing will be unpacked if you use
> -this command on a pack-file that exists within the target repository.
> +By default, objects that already exist in the repository will *not*
> +be unpacked from the pack-file. Therefore, nothing will be unpacked
> +if you use this command on a pack-file that exists within the target
> +repository, unless you specify --force.
>
> Please see the `git-repack` documentation for options to generate
> new packs and replace existing ones.
> @@ -40,6 +41,14 @@ OPTIONS
> and make the best effort to recover as many objects as
> possible.
>
> +--force::
> + Allow loose objects to be created in the same repository that
> + contains the packfile.
> +
> +--min-blob-size=<n>::
> + Smallest loose object to create, expressed in kB.
> + Blobs smaller than this will not be unpacked. Default is 0.
> +
>
> Author
> ------
> diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
> index a6ff62f..a42bf0d 100644
> --- a/builtin-unpack-objects.c
> +++ b/builtin-unpack-objects.c
> @@ -10,13 +10,16 @@
> #include "progress.h"
>
> static int dry_run, quiet, recover, has_errors;
> -static const char unpack_usage[] = "git-unpack-objects [-n] [-q] [-r] < pack-file";
> +static const char unpack_usage[] =
> +"git-unpack-objects [-n] [-q] [-r] [--force] [--min-blob-size=N] < pack-file";
>
> /* We always read in 4kB chunks. */
> static unsigned char buffer[4096];
> static unsigned int offset, len;
> static off_t consumed_bytes;
> static SHA_CTX ctx;
> +static int force = 0;
> +uint32_t min_blob_size;
>
> /*
> * Make sure at least "min" bytes are available in the buffer, and
> @@ -131,7 +134,9 @@ static void added_object(unsigned nr, enum object_type type,
> static void write_object(unsigned nr, enum object_type type,
> void *buf, unsigned long size)
> {
> - if (write_sha1_file(buf, size, typename(type), obj_list[nr].sha1) < 0)
> + int force2 = size < min_blob_size ? -1 : force;
> + if (write_sha1_file_maybe(buf, size, typename(type),
> + force2, obj_list[nr].sha1) < 0)
> die("failed to write object");
> added_object(nr, type, buf, size);
> }
> @@ -361,6 +366,17 @@ int cmd_unpack_objects(int argc, const char **argv, const char *prefix)
> recover = 1;
> continue;
> }
> + if (!strcmp(arg, "--force")) {
> + force = 1;
> + continue;
> + }
> + if (!prefixcmp(arg, "--min-blob-size=")) {
> + char *end;
> + min_blob_size = strtoul(arg+16, &end, 0) * 1024;
> + if (!arg[16] || *end)
> + usage(unpack_usage);
> + continue;
> + }
> if (!prefixcmp(arg, "--pack_header=")) {
> struct pack_header *hdr;
> char *c;
> diff --git a/cache.h b/cache.h
> index ec85d93..d0c3030 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -343,6 +343,8 @@ extern int sha1_object_info(const unsigned char *, unsigned long *);
> extern void * read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size);
> extern int hash_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *sha1);
> extern int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *return_sha1);
> +extern int write_sha1_file_maybe(void *buf, unsigned long len, const char *type,
> + int ignore, unsigned char *return_sha1);
> extern int pretend_sha1_file(void *, unsigned long, enum object_type, unsigned char *);
>
> extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned long size, const char *type);
> diff --git a/sha1_file.c b/sha1_file.c
> index 12d2ef2..68b8db8 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1979,7 +1979,8 @@ int hash_sha1_file(const void *buf, unsigned long len, const char *type,
> return 0;
> }
>
> -int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *returnsha1)
> +int write_sha1_file_maybe(void *buf, unsigned long len, const char *type,
> + int ignore, unsigned char *returnsha1)
> {
> int size, ret;
> unsigned char *compressed;
> @@ -1997,7 +1998,7 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
> filename = sha1_file_name(sha1);
> if (returnsha1)
> hashcpy(returnsha1, sha1);
> - if (has_sha1_file(sha1))
> + if (ignore < 0 || !ignore && has_sha1_file(sha1))
> return 0;
> fd = open(filename, O_RDONLY);
> if (fd >= 0) {
> @@ -2062,6 +2063,12 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
> return move_temp_to_file(tmpfile, filename);
> }
>
> +int write_sha1_file(void *buf, unsigned long len, const char *type,
> + unsigned char *returnsha1)
> +{
> + return write_sha1_file_maybe(buf, len, type, 0, returnsha1);
> +}
> +
> /*
> * We need to unpack and recompress the object for writing
> * it out to a different file.
> --
> 1.5.2.762.gd8c6-dirty
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Nicolas
^ permalink raw reply
* Re: [PATCH] Don't allow newlines to occur in $Id:$ collapse
From: Joshua N Pritikin @ 2007-05-25 13:28 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705251413.42389.andyparkins@gmail.com>
On Fri, May 25, 2007 at 02:13:42PM +0100, Andy Parkins wrote:
> If a newline ever made it into an repository-side expanded $Id$ field,
> the keyword would still be detected as a keyword and collapsed, before
> rexpansion, e.g.
>
> $Id: all of this text would be removed, even if there
> were a newline in the middle of it$
>
> This patch catches newlines in this case and abandons treating this as a
> keyword expansion, this text would be left untouched in the working
> checkout.
That's better but I would error out instead of silently ignoring it.
Your choice.
^ permalink raw reply
* [PATCH] Don't allow newlines to occur in $Id:$ collapse
From: Andy Parkins @ 2007-05-25 13:13 UTC (permalink / raw)
To: git
In-Reply-To: <200705251412.06196.andyparkins@gmail.com>
If a newline ever made it into an repository-side expanded $Id$ field,
the keyword would still be detected as a keyword and collapsed, before
rexpansion, e.g.
$Id: all of this text would be removed, even if there
were a newline in the middle of it$
This patch catches newlines in this case and abandons treating this as a
keyword expansion, this text would be left untouched in the working
checkout.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
convert.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/convert.c b/convert.c
index 3c44e3d..051366c 100644
--- a/convert.c
+++ b/convert.c
@@ -547,12 +547,14 @@ static char *ident_to_worktree(const char *path, const char *src, unsigned long
ch = *cp;
if (ch == '$')
break;
+ if (ch == '\n')
+ break;
cp++;
rem--;
} while (rem);
/* If the above finished because it ran out of characters, then
* this is an incomplete keyword, so don't run the expansion */
- if (!rem)
+ if (!rem || ch == '\n')
continue;
} else if (src[2] == '$')
cp = src + 2;
--
1.5.2.763.g8c5e-dirty
^ permalink raw reply related
* Re: [PATCH] Fix mishandling of $Id$ expanded in the repository copy in convert.c
From: Andy Parkins @ 2007-05-25 13:12 UTC (permalink / raw)
To: git; +Cc: Joshua N Pritikin
In-Reply-To: <20070525105836.GG6667@always.joy.eth.net>
On Friday 2007 May 25, Joshua N Pritikin wrote:
> Can this loop throw away newlines? Removing newlines seems like a bad
> idea.
It can and does. My patch is only a bug fix though, not a change in
functionality.
It's probably not likely that they will appear inside the $Id: XXXXX $
expansion, and even less likely that that expansion will make it into the
repository copy; however it's easily fixed ... patch to follow.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-25 12:44 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Linus Torvalds, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <200705251427.46903.Josef.Weidendorfer@gmx.de>
Hi,
On Fri, 25 May 2007, Josef Weidendorfer wrote:
> On Thursday 24 May 2007, Linus Torvalds wrote:
> >
> > On Thu, 24 May 2007, Junio C Hamano wrote:
> > >
> > > Why does this have to be out-of-tree and unversioned to begin
> > > with?
> >
> > I _really_ think that the right approach is to
> >
> > - have the submodules information under version control (and I'd
> > personally call it the ".gitmodules" file, but whatever)
> >
> > This gives you the defaults, and the ability to change them.
>
> Sorry to repeat the obvious.
>
> I assume you talk about a versioned .gitmodules file tied to the
> superproject history, and any fetch/pull would look into this
> file from the current working directory to lookup the default URL.
>
> Wouldn't this have the problem that when you check out an old
> revision of the superproject you get out-of-date URLs, so that
> a fetch does not work (without local overrides)?
If you check out an old revision, wouldn't you have that _already_, so it
does not matter what URL is given in .gitmodules?
Ciao,
Dscho
^ permalink raw reply
* Re: HTTP trees trailing GIT trees
From: Johannes Schindelin @ 2007-05-25 12:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f36g7l$2oe$1@sea.gmane.org>
Hi,
On Fri, 25 May 2007, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Thu, 24 May 2007, Panagiotis Issaris wrote:
> >
> >> So, we're asking for /ffmpeg/info/refs, and the server is returning
> >> c30fa8391812..., but, using GitWeb one can see that c30fa839812... is
> >> not the last commit, this one is:
> >> http://git.mplayerhq.hu/?p=ffmpeg;a=commit;
> >> h=47d7dcb5a7d89f413064e7ef1b54d77e59fb8375
> >
> > So, info/refs is still old. This file should have been updated by
> > git-update-server-info. I am not sure how this repo is updated, but I
> > suspect that the wrong hook contains the call to update-server-info, or
> > that the correct hook is not activated, or it does not have write
> > permission.
>
> If you push to repository (it is the usual setup for public
> repositories), it would be enough to simply enable default
> 'post-update' hook (make it executable).
>
> If you however for example commit to this public repository directly,
> you would need to put call to git-update-server-info in the 'post-commit'
> hook.
I have the slight suspicion that this repo is only updated via git-svn.
And I am still new enough to git-svn to not know which hook it executes,
if any.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-25 12:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f36k4v$f7s$1@sea.gmane.org>
Hi,
On Fri, 25 May 2007, Jakub Narebski wrote:
> Johannes Schindelin wrote:
> > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> >> On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
> >>> On Thu, 24 May 2007, Sven Verdoolaege wrote:
>
> >>>> OK... so what should git-update-server-info put in this file for submodules?
> >>>> Or, equivalently, what should be the output of ls-remote?
> >>>>
> >>>> Right now its a list of pairs of revs(sha1) and refs.
> >>>> For submodules we want a connection between a submodule name
> >>>> and one or more URLs where the submodule can be found.
> >>>> How are you going to squeeze that into info/refs without confusing
> >>>> older versions of git?
> >>>
> >>> I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
> >>> to the URL, or "sub:URL" or something.
> >>
> >> Just to be clear, would it look like the following?
> >>
> >> e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
> >> c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
> >> 3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule
> >> /home/sverdool/public_html/cloog.git cloog^{URL}
> >> http://www.liacs.nl/~sverdool/cloog.git cloog^{URL}
> >
> > I was more thinking about something like this:
> > 3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
> >
> > But then, I haven't really thought about it deeply.
>
> I was thinking about the following:
>
> ref: refs/heads/master HEAD
> e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
> c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
> 3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/master:submodule/path
> URL: /home/sverdool/public_html/cloog.git refs/heads/master:submodule/path^{URL}
> URL: http://www.liacs.nl/~sverdool/cloog.git refs/heads/master:submodule/path^{URL}
>
> By the way, it would be nice if git-show-refs --deferefence used TAB
> between sha1 and ref name, like in git-ls-remote / git-peek-remote,
> otherwise I think git-show-refs output parsers would fail on [proposed]
> "current branch" extension.
Well, I always hinted at it, and now officially retract my proposal. IMHO
.gitmodules is a much better place for that. It _belongs_ in the
repository, not just the config.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Josef Weidendorfer @ 2007-05-25 12:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Lars Hjemli, Johannes Schindelin, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <alpine.LFD.0.98.0705241030440.26602@woody.linux-foundation.org>
On Thursday 24 May 2007, Linus Torvalds wrote:
>
> On Thu, 24 May 2007, Junio C Hamano wrote:
> >
> > Why does this have to be out-of-tree and unversioned to begin
> > with?
>
> I _really_ think that the right approach is to
>
> - have the submodules information under version control (and I'd
> personally call it the ".gitmodules" file, but whatever)
>
> This gives you the defaults, and the ability to change them.
Sorry to repeat the obvious.
I assume you talk about a versioned .gitmodules file tied to the
superproject history, and any fetch/pull would look into this
file from the current working directory to lookup the default URL.
Wouldn't this have the problem that when you check out an old
revision of the superproject you get out-of-date URLs, so that
a fetch does not work (without local overrides)?
IMHO we really need 2 kinds of submodule config:
(1) One bound to the superproject history
(2) One bound _not_ to the superproject history.
However, (2) could be put into its own, seperate history/branch,
similar to the "todo" branch in the git repository. The tip of the
submodule config history, (2) above, would e.g. be available as
"ref/submodulesconfig" (and could be checked out by "git-clone" into
a separate place like .git/submodulesconfig of the superproject for easy
editing).
Any "git-fetch" of the superproject would also fetch any changed defaults
in the submodulesconfig history.
This even allows to override any URL defaults for downstream clones
of a superproject repository, by commiting such changes as new
revision in the refs/submodulesconfig history.
Perhaps I am missing something obvious, but a history for project
configuration, completely separate from the project history itself,
seems useful in general to me.
Josef
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Johannes Schindelin @ 2007-05-25 12:24 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano
In-Reply-To: <11800866643203-git-send-email-hjemli@gmail.com>
Hi,
On Fri, 25 May 2007, Lars Hjemli wrote:
> There is currently no way to override the mappings in the .gitmodules
> file, except by manually creating the subproject repository.
I think that is okay. We can add that easily at a later stage, and the
script is much easier without that logic.
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
Looks good here, I checked with asciidoc.
> diff --git a/git-submodule.sh b/git-submodule.sh
> new file mode 100755
> index 0000000..c4a1cc3
> --- /dev/null
> +++ b/git-submodule.sh
> @@ -0,0 +1,163 @@
> +#!/bin/sh
> +#
> +# git-submodule.sh: init, update or list git submodules
> +#
> +# Copyright (c) 2007 Lars Hjemli
> +
> +USAGE='[-i | --init | -u | --update] [-q | --quiet] [--cached] <path>...'
> +. git-sh-setup
> +require_work_tree
> +
> +init=
> +update=
> +quiet=
> +cached=
> +
> +#
> +# print stuff on stdout unless -q was specified
> +#
> +say()
> +{
> + if test -z "$quiet"
> + then
> + echo -e "$@"
> + fi
> +}
> +
> +#
> +# Find all (requested) submodules, run clone + checkout on missing paths
> +#
> +# $@ = requested paths (default to all)
> +#
> +modules_init()
> +{
> + git ls-files --stage -- $@ | grep -e '^160000 ' |
Any reason you read in the stage? It does not seem that you use it.
> + while read mode sha1 stage path
> + do
> + test -d "$path/.git" && continue
> +
> + if test -d "$path"
> + then
> + rmdir "$path" 2>/dev/null ||
> + die "Directory '$path' exist, but not as a submodule"
> + fi
> +
> + test -e "$path" &&
> + die "A file already exist at path '$path'"
> +
> + url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
I like that command ;-)
> + test -z "$url" &&
> + die "No url found for submodule '$path' in .gitmodules"
> +
> + git-clone "$url" "$path" ||
> + die "Clone of submodule '$path' failed"
> +
> + $(cd "$path" && git-checkout -q "$sha1") ||
> + die "Checkout of submodule '$path' failed"
> +
> + say "Submodule '$path' initialized"
> + done
> +}
> +
> +#
> +# Checkout correct revision of each initialized submodule
> +#
> +# $@ = requested paths (default to all)
> +#
> +modules_update()
> +{
> + git ls-files --stage -- $@ | grep -e '^160000 ' |
Same here.
> + while read mode sha1 stage path
> + do
> + if ! test -d "$path/.git"
> + then
> + say "Submodule '$path' not initialized"
> + continue;
> + fi
> + subsha1=$(cd "$path" && git-rev-parse --verify HEAD) ||
Maybe it would be a better idea to use "git --git-dir="$path" rev-parse
..."? Just in case somebody calls this with GIT_DIR overridden...
Or, unset GIT_DIR explicitely.
> + die "Unable to find current revision of submodule '$path'"
> +
> + if test "$subsha1" != "$sha1"
> + then
> + $(cd "$path" && git-fetch && git-checkout -q "$sha1") ||
This will make a detached HEAD, right? Do you want that? (I am not really
interested in submodules myself, so I haven't thought about it, and I
haven't followed that monster discussion.)
> + die "Unable to checkout revision $sha1 of submodule '$path'"
> +
> + say "Submodule '$path' reset to revision $sha1"
I'd rather not say "reset", since this has a different meaning in Git, but
rather "set to revision $sha1".
> + fi
> + done
> +}
> +
> +#
> +# List all registered submodules, prefixed with:
> +# - submodule not initialized
> +# + different version checked out
> +#
> +# If --cached was specified the revision in the index will be printed
> +# instead of the currently checked out revision.
> +#
> +# $@ = requested paths (default to all)
> +#
> +modules_list()
> +{
> + git ls-files --stage -- $@ | grep -e '^160000 ' |
> + while read mode sha1 stage path
> + do
> + if ! test -d "$path/.git"
> + then
> + say "-$sha1 $path"
> + continue;
> + fi
> + revname=$(cd "$path" && git-describe $sha1)
> + if git diff-files --quiet -- "$path"
> + then
> + say " $sha1 $path\t($revname)"
> + else
> + if test -z "$cached"
> + then
> + sha1=$(cd "$path" && git-rev-parse --verify HEAD)
> + revname=$(cd "$path" && git-describe $sha1)
> + fi
> + say "+$sha1 $path\t($revname)"
> + fi
> + done
> +}
> +
> +
> +while case "$#" in 0) break ;; esac
> +do
> + case "$1" in
> + -i|--init)
> + init=1
> + ;;
> + -u|--update)
> + update=1
> + ;;
> + -q|--quiet)
> + quiet=1
> + ;;
> + --cached)
> + cached=1
> + ;;
> + --)
> + break
> + ;;
> + -*)
> + usage
> + ;;
> + *)
> + break
> + ;;
> + esac
> + shift
> +done
> +
> +
> +if test "$init" = "1"
> +then
> + modules_init $@
> +elif test "$update" = "1"
> +then
> + modules_update $@
> +else
> + modules_list $@
> +fi
I'll let Junio comment on that command line parsing...
All in all, I like it: it is short, to the point, and it should do the job
(maybe with a few enhancements like "--update" without arguments means
_all_ submodules).
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Jakub Narebski @ 2007-05-25 12:22 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705241315290.4648@racer.site>
Johannes Schindelin wrote:
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
>> On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
>>> On Thu, 24 May 2007, Sven Verdoolaege wrote:
>>>> OK... so what should git-update-server-info put in this file for submodules?
>>>> Or, equivalently, what should be the output of ls-remote?
>>>>
>>>> Right now its a list of pairs of revs(sha1) and refs.
>>>> For submodules we want a connection between a submodule name
>>>> and one or more URLs where the submodule can be found.
>>>> How are you going to squeeze that into info/refs without confusing
>>>> older versions of git?
>>>
>>> I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
>>> to the URL, or "sub:URL" or something.
>>
>> Just to be clear, would it look like the following?
>>
>> e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
>> c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
>> 3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule
>> /home/sverdool/public_html/cloog.git cloog^{URL}
>> http://www.liacs.nl/~sverdool/cloog.git cloog^{URL}
>
> I was more thinking about something like this:
> 3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
>
> But then, I haven't really thought about it deeply.
I was thinking about the following:
ref: refs/heads/master HEAD
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/master:submodule/path
URL: /home/sverdool/public_html/cloog.git refs/heads/master:submodule/path^{URL}
URL: http://www.liacs.nl/~sverdool/cloog.git refs/heads/master:submodule/path^{URL}
By the way, it would be nice if git-show-refs --deferefence used TAB
between sha1 and ref name, like in git-ls-remote / git-peek-remote,
otherwise I think git-show-refs output parsers would fail on [proposed]
"current branch" extension.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: StGIT and conflicts
From: Karl Hasselström @ 2007-05-25 12:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Yann Dirson, git
In-Reply-To: <b0943d9e0705250300o419d1d7ld175b273dbed2429@mail.gmail.com>
On 2007-05-25 11:00:33 +0100, Catalin Marinas wrote:
> On 24/05/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > The current behavior of StGIT is to not use the index for
> > conflicts like git does. What advantages does this have that are
> > great enough to motivate a deviation from the git behavior?
>
> I don't think there are any advantages in deviating from the git
> behaviour, only that when I first implementing it, git didn't have
> any smarter behaviour and I used diff3 (or other external merger,
> which can be used right now as well).
>
> I'm not sure if git-diff still works when there are conflicts in the
> index. The current stg behaviour is to reset the index to the base
> of the patch and a stg diff would show the diff (including the
> config markers) to the base. I find this quite handy.
To be honest, I'm not very well versed in how git handles merge
conflicts -- with all the nontrivial projects I touch, I use StGIT for
everything that can conflict. :-) Grepping for "conflict" in the user
manual brings up a very good explanation, though; and to answer your
question: it seems to work very well indeed, surprise surprise. You
can make the diff show anything you want, including between the patch
base and the working dir. Though, as the manual points out, the most
important view is probably between index and working tree, which shows
you just the not-yet-fixed conflicts.
Step one would be to simply stop messing with the index after merges,
and just let "stg resolved" mean "git add".
Step two (somewhat more ambitious) might be to stop trying to hide the
index, by providing a flag to "stg refresh" to make it refresh only
what's in the index, and not everything -- that is, to make it do what
"git commit" does when _not_ given the -a flag. And once we stop
hiding the index, there's no point in having StGIT commands to do
things like add, remove, and so on -- we could just use what git
provides.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: How do we import patches from non-git sources?
From: Jakub Narebski @ 2007-05-25 11:24 UTC (permalink / raw)
To: git
In-Reply-To: <20070524212202.GW19253@nan92-1-81-57-214-146.fbx.proxad.net>
[Cc: Yann Dirson <ydirson@altern.org>, git@vger.kernel.org]
Yann Dirson wrote:
> I have written a patch-application tool as part of the (otherwise
> stalled) ArcheoloGIT project, clonable from
> http://ydirson.free.fr/soft/git/argit.git/.
By the way, have you considered adding a mirror of this repository
to http://repo.or.cz ? This way you would have gitweb interface, and
other protocols support.
Could you edit description file, and add README if it does not exists?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: HTTP trees trailing GIT trees
From: Jakub Narebski @ 2007-05-25 11:15 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705241456080.4648@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 24 May 2007, Panagiotis Issaris wrote:
>
>> So, we're asking for /ffmpeg/info/refs, and the server is returning
>> c30fa8391812..., but, using GitWeb one can see that c30fa839812... is
>> not the last commit, this one is:
>> http://git.mplayerhq.hu/?p=ffmpeg;a=commit;
>> h=47d7dcb5a7d89f413064e7ef1b54d77e59fb8375
>
> So, info/refs is still old. This file should have been updated by
> git-update-server-info. I am not sure how this repo is updated, but I
> suspect that the wrong hook contains the call to update-server-info, or
> that the correct hook is not activated, or it does not have write
> permission.
If you push to repository (it is the usual setup for public
repositories), it would be enough to simply enable default
'post-update' hook (make it executable).
If you however for example commit to this public repository directly,
you would need to put call to git-update-server-info in the 'post-commit'
hook.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Sixt @ 2007-05-25 11:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705251113280.4648@racer.site>
Johannes Schindelin wrote:
> On Fri, 25 May 2007, Johannes Sixt wrote:
> > * perl scripts like git-remote contain a hard-coded path to the
> > installation directory and don't work for this reason.
>
> GITPERLLIB should be set from the wrapper script, I think.
The clean way is certainly to derive the directory from $0:
use lib $0 =~ /^(.*)([\/\\]+[^\/\\]*){2}$/ ? ("$1/lib") : ();
(although I'm not sure whether this would work during 'make test').
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix mishandling of $Id$ expanded in the repository copy in convert.c
From: Joshua N Pritikin @ 2007-05-25 10:58 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705251150.09439.andyparkins@gmail.com>
On Fri, May 25, 2007 at 11:50:08AM +0100, Andy Parkins wrote:
> + /*
> + * Throw away characters until either
> + * - we reach a "$"
> + * - we run out of bytes (rem == 0)
> + */
> do {
> - ch = *cp++;
> + ch = *cp;
> if (ch == '$')
> break;
> + cp++;
> rem--;
> } while (rem);
Can this loop throw away newlines? Removing newlines seems like a bad
idea.
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Johannes Schindelin @ 2007-05-25 10:57 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano
In-Reply-To: <11800866643203-git-send-email-hjemli@gmail.com>
Hi,
On Fri, 25 May 2007, Lars Hjemli wrote:
> On 5/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 24 May 2007, Lars Hjemli wrote:
> > > What I think would be nice is some porcelain support to manually init,
> > > update and see the checked out version of selected subprojects, but as
> > > standalone commands.
> >
> > Yes, a la git-remote. I'd be much happier with that, too, especially since
> > I think that this can be a relatively small and easy-to-review script.
>
> So, here it is. Please be kind :)
Thank you very much! And it looks small enough that I will review it right
away.
> Btw: I've never managed to get asciidoc working on my machine, so the doc
> isn't checked in any other format than plain text.
No problem, I will check that.
Ciao,
Dscho
^ permalink raw reply
* Re: just fetching HEAD of repository
From: Jakub Narebski @ 2007-05-25 10:56 UTC (permalink / raw)
To: git
In-Reply-To: <566574ef0705210201wc5c0adbmaa22d197b16bf72d@mail.gmail.com>
Stian Haklev wrote:
> After checking all the docs, I am still wondering if there is a way to
> get only the last commit from a given git repository. Sometimes I
> really just want the latest code so I can compile it - and let's say
> they are not running gitweb, or it is not convenient to go to gitweb
> and ask for a tar package to be made? This is especially relevant in
> countries with slow internet connection - here in Indonesia it takes
> me an hour to clone the git repository for example, never mind let's
> say the Linux kernel.
Depending on what you want, try either:
$ git clone --depth=1 <repository URL>
or
$ git archive --remote=<repository URL> HEAD
(if the remote side supports it)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Fix mishandling of $Id$ expanded in the repository copy in convert.c
From: Andy Parkins @ 2007-05-25 10:50 UTC (permalink / raw)
To: git
If the repository contained an expanded ident keyword (i.e. $Id:XXXX$),
then the wrong bytes were discarded, and the Id keyword was not
expanded. The fault was in convert.c:ident_to_worktree().
Previously, when a "$Id:" was found in the repository version,
ident_to_worktree() would search for the next "$" after this, and
discarded everything it found until then. That was done with the loop:
do {
ch = *cp++;
if (ch == '$')
break;
rem--;
} while (rem);
The above loop left cp pointing one character _after_ the final "$"
(because of ch = *cp++). This was different from the non-expanded case,
were cp is left pointing at the "$", and was different from the comment
which stated "discard up to but not including the closing $". This
patch fixes that by making the loop:
do {
ch = *cp;
if (ch == '$')
break;
cp++;
rem--;
} while (rem);
That is, cp is tested _then_ incremented.
This loop exits if it finds a "$" or if it runs out of bytes in the
source. After this loop, if there was no closing "$" the expansion is
skipped, and the outer loop is allowed to continue leaving this
non-keyword as it was. However, when the "$" is found, size is
corrected, before running the expansion:
size -= (cp - src);
This is wrong; size is going to be corrected anyway after the expansion,
so there is no need to do it here. This patch removes that redundant
correction.
To help find this bug, I heavily commented the routine; those comments
are included here as a bonus.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
You wouldn't believe that I managed to get a file into the repository
with $Id$ stored expanded would you? :-)
Anyway, it's fortunate that I did, because it revealed the above bugs
in the ident_to_worktree() code.
I've included the comments I wrote while debugging in this patch, which
I'm sure will annoy you, because you'd rather the fix and the comments
separately. I'll supply that if you wish - just holler.
convert.c | 39 +++++++++++++++++++++++++++++++++++++--
1 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 4b26b1a..3c44e3d 100644
--- a/convert.c
+++ b/convert.c
@@ -509,36 +509,71 @@ static char *ident_to_worktree(const char *path, const char *src, unsigned long
for (dst = buf; size; size--) {
const char *cp;
+ /* Fetch next source character, move the pointer on */
char ch = *src++;
+ /* Copy the current character to the destination */
*dst++ = ch;
+ /* If the current character is "$" or there are less than three
+ * remaining bytes or the two bytes following this one are not
+ * "Id", then simply read the next character */
if ((ch != '$') || (size < 3) || memcmp("Id", src, 2))
continue;
+ /*
+ * Here when
+ * - There are more than 2 bytes remaining
+ * - The current three bytes are "$Id$"
+ * with
+ * - ch == "$"
+ * - src[0] == "I"
+ */
+ /*
+ * It's possible that an expanded Id has crept its way into the
+ * repository, we cope with that by stripping the expansion out
+ */
if (src[2] == ':') {
+ /* Expanded keywords have "$Id:" at the front */
+
/* discard up to but not including the closing $ */
unsigned long rem = size - 3;
+ /* Point at first byte after the ":" */
cp = src + 3;
+ /*
+ * Throw away characters until either
+ * - we reach a "$"
+ * - we run out of bytes (rem == 0)
+ */
do {
- ch = *cp++;
+ ch = *cp;
if (ch == '$')
break;
+ cp++;
rem--;
} while (rem);
+ /* If the above finished because it ran out of characters, then
+ * this is an incomplete keyword, so don't run the expansion */
if (!rem)
continue;
- size -= (cp - src);
} else if (src[2] == '$')
cp = src + 2;
else
+ /* Anything other than "$Id:XXX$" or $Id$ and we skip the
+ * expansion */
continue;
+ /* cp is now pointing at the last $ of the keyword */
+
memcpy(dst, "Id: ", 4);
dst += 4;
memcpy(dst, sha1_to_hex(sha1), 40);
dst += 40;
*dst++ = ' ';
+
+ /* Adjust for the characters we've discarded */
size -= (cp - src);
src = cp;
+
+ /* Copy the final "$" */
*dst++ = *src++;
size--;
}
--
1.5.2.763.g8c5e-dirty
^ permalink raw reply related
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-25 10:20 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4656A304.AF39A0B6@eudaptics.com>
Hi,
On Fri, 25 May 2007, Johannes Sixt wrote:
> * I personally think that the files should go into
>
> $PROGRAMFILES/Git/{bin,share,lib}
> instead of
> $PROGRAMFILES/Git/usr/{bin,share,lib}
Agree. It is trivial, but it will help others. It might also be a good
idea to have a shortcut in "$PF/Git/Git Gui.lnk" to the git gui (once it
is working, that is).
> * git-gui and gitk don't work out of the box because they have the path
> to wish hardcoded. They can't be started from CMD at all. I have written
> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
>
> @echo off
> start wish84 D:/MSYS/1.0/git/bin/gitk %*
>
> But as you can see, the path is still hard-coded (but it is good enough
> for me for the moment).
I'd also like to see bash, perl and wish bundled with the install (Windows
lusers are so used to one big install package, so it is an _advantage_ to
have a bigger download).
> * perl scripts like git-remote contain a hard-coded path to the
> installation directory and don't work for this reason.
GITPERLLIB should be set from the wrapper script, I think.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Jakub Narebski @ 2007-05-25 10:06 UTC (permalink / raw)
To: git
In-Reply-To: <20070524154833.GL5412@admingilde.org>
Martin Waitz wrote:
> On Tue, May 22, 2007 at 09:37:06PM +0200, Jan Hudec wrote:
>> Including the same project several times is indeed interesting. Maybe the
>> subprojects should be "light checkouts" (I believe something like this was
>> already discussed on the list sometime). Those would be .git dirs, that would
>> only have HEAD and pointer to another .git dir with everything else.
>
> Well, even if they might share a lot of objects they might be included
> for completely different reasons and so might need to work with
> different communities (remote entries, branches, etc.).
>
> So sharing objects makes sense, sharing the rest of .git is not
> neccessary.
One of the final ideas for "lightweight checkout" was having in
.git/config the location of "true" $GIT_DIR (or parts of it:
GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY), and "shadowing" the rest
of "true $GIT_DIR" with what is present in .git. It means that
you can have .git/index and .git/HEAD, and if you don't find
appropriate .git/refs/heads/master file you look to "true $GIT_DIR".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: StGIT and conflicts
From: Catalin Marinas @ 2007-05-25 10:00 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, git
In-Reply-To: <20070524164038.GA27661@diana.vm.bytemark.co.uk>
On 24/05/07, Karl Hasselström <kha@treskal.com> wrote:
> The current behavior of StGIT is to not use the index for conflicts
> like git does. What advantages does this have that are great enough to
> motivate a deviation from the git behavior?
I don't think there are any advantages in deviating from the git
behaviour, only that when I first implementing it, git didn't have any
smarter behaviour and I used diff3 (or other external merger, which
can be used right now as well).
I'm not sure if git-diff still works when there are conflicts in the
index. The current stg behaviour is to reset the index to the base of
the patch and a stg diff would show the diff (including the config
markers) to the base. I find this quite handy.
--
Catalin
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-25 10:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Lars Hjemli, Shawn O. Pearce, git, Martin Waitz,
Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241908040.4648@racer.site>
I'm obviously not going to stop anyone from putting URLs in .gitmodules
and I can see that it would be useful in practice, but I still think
that it doesn't matter where the submodule was located at any
given point in history (from the point of view of the superproject).
It only matters where the submodule is located now.
You may be bisecting a problem and you may need to clone a submodule
for a point in history when the submodule was placed somewhere else.
(You may not have had a need to checkout the submodule before,
or it may simply not be used in the current version of the supermodule.)
So, I think it would still be useful to have an optional additional
out-of-tree mechanism of getting usable URLs if the URLs in .gitmodules
or your local config don't work.
On Thu, May 24, 2007 at 07:11:31PM +0100, Johannes Schindelin wrote:
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > If you allow an override, then I don't see how having the initial
> > information in the tree is any better.
>
> Isn't that obvious? _Most_ people will _not_ override the information.
You may be asked to.
"Please clone from a mirror close to you and after cloning,
please change the URLs of these 54 submodules to a mirror
close to you."
> Plus, it is an easy solution to your problem, without having to touch a
> lot of real core parts of Git. Simple is beautiful. And less buggy.
I'll take your word for it.
> > He needs to modify .gitmodules, but when the changes go upstream,
> > this .gitmodules changes get merged as well.
>
> If you change the superproject, that is.
That's what I meant. Plus, other users may want to pull from such forks too.
skimo
^ 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