* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Alex Riesen @ 2007-06-06 11:27 UTC (permalink / raw)
To: J Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vps495uvs.fsf@assigned-by-dhcp.cox.net>
On 6/6/07, J Junio C Hamano <gitster@pobox.com> wrote:
> > Which one was fetched when? /home/user/a or /home/user/a.git?
>
> I am half tempted to say that this is very close to "doctor, it
> confuses me when I have both of them". Imagine the case where
> the source were a remote repository _and_ there was no way other
> than interacting with it via git protocol. You cannot really
> tell (well, you can tell half, by trying both and if a worked
> but a.git didn't you can tell that a.git does not exist) nor you
> do not really care.
Of course you can! Just print the path to the remote EXACTLY
how the user entered it!
> > Besides, I just noticed git-clone is broken WRT the .git
> > as well: I can clone a "a.git" into "b" (and it ignores -l and -s!),
> > but I can't fetch the "a" (aka "origin") being in "b". And of
> > course, "origin" in "b" is setup as "/path/a", not "/path/a.git".
>
> This probably is worth fixing, independent from what the message
> says before or after your patch.
And "probably" means: it is broken, but this is ok?
^ permalink raw reply
* Re: [PATCH] Accept dates before 2000/01/01 when specified as seconds since the epoch
From: Johannes Sixt @ 2007-06-06 10:42 UTC (permalink / raw)
To: git
In-Reply-To: <7vtztl5vvb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I vaguely recall hitting the same issue soon after date.c was
> done, and sending in a patch in the same spirit but with
> different implementation (I essentially duplicated that "seconds
> since epoch" without any cutoff as the last ditch fallback) long
> time ago (this was before I took git over; the patch was rejected).
>
> It almost makes me wonder if it is better to introduce a special
> syntax to denote "seconds since epoch plus timezone offset" for
> our Porcelain use, instead of keeping this arbitrary cut-off
> date which nobody can agree on and which forces us to roll back
> from time to time. For one thing, such a syntax would allow us
> to talk about a timestamp before the epoch.
>
> Perhaps
>
> "epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]
>
> ?
OTOH, the previous limit 2000/01/01 was completely arbitrary, while the
new limit 100000000secs has some justification: Numbers with fewer
digits could be mistaken as dates.
-- Hannes
^ permalink raw reply
* [PATCH] [RFC] Generational repacking
From: Sam Vilain @ 2007-06-06 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
This is a quick hack at generational repacking. The idea is that you
successively do larger repack runs as the number of packs accumulates.
The commandline interface for this should be considered development
grade only, and of course there are no tests and very verbose output
:)
The useful invocation of this is git-repack -d -g
The -a option then becomes a degenerate case of generative repacking.
The intention is that this should end up light enough to be triggered
automatically whenever the (approximate) count of loose objects hits a
threshold, like 100 or 1000 - making git repositories "maintenance
free".
---
git-repack.sh | 79 ++++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 67 insertions(+), 12 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 8c32724..b26ca2a 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,19 +3,21 @@
# Copyright (c) 2005 Linus Torvalds
#
-USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--depth=N]'
+USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [-g] [--max-pack-size=N] [--window=N] [--depth=N]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
-no_update_info= all_into_one= remove_redundant=
-local= quiet= no_reuse= extra=
+no_update_info= generations= remove_redundant=
+local= quiet= no_reuse= extra= generation_width=
while case "$#" in 0) break ;; esac
do
case "$1" in
-n) no_update_info=t ;;
- -a) all_into_one=t ;;
+ -a) generations=0 ;;
-d) remove_redundant=t ;;
-q) quiet=-q ;;
+ -g) generations=3 generation_width=10 ;;
+ -G) generations=$2; generation_width=5; shift ;;
-f) no_reuse=--no-reuse-object ;;
-l) local=--local ;;
--max-pack-size=*) extra="$extra $1" ;;
@@ -40,24 +42,74 @@ PACKTMP="$GIT_OBJECT_DIRECTORY/.tmp-$$-pack"
rm -f "$PACKTMP"-*
trap 'rm -f "$PACKTMP"-*' 0 1 2 3 15
+generation=
+redundant=
+
# There will be more repacking strategies to come...
-case ",$all_into_one," in
+case ",$generations," in
,,)
args='--unpacked --incremental'
;;
-,t,)
+,*,)
if [ -d "$PACKDIR" ]; then
+ max_gen=0
+ echo "Scanning for packs... generations: $generations, generation_width: $generation_width"
for e in `cd "$PACKDIR" && find . -type f -name '*.pack' \
| sed -e 's/^\.\///' -e 's/\.pack$//'`
do
+ echo -n "what about $e ? "
if [ -e "$PACKDIR/$e.keep" ]; then
: keep
+ echo "keep it - .keep exists"
else
- args="$args --unpacked=$e.pack"
existing="$existing $e"
+ if [ -e "$PACKDIR/$e.gen" ]; then
+ gen=`cat $PACKDIR/$e.gen`
+ else
+ echo -n "assuming "
+ gen=1
+ fi
+ echo "generation $gen"
+ [ "$max_gen" -lt $gen ] && max_gen=$gen
+ eval "gen_${gen}=\"\$gen_${gen} $e\"";
+ eval "c_gen_${gen}=\$((\$c_gen_${gen} + 1))";
fi
done
+ i=$max_gen
+ packing=
+ while [ $i -gt 0 ]
+ do
+ c_gen=`eval "echo \\\$c_gen_$i"`
+ packs=`eval "echo \\\$gen_$i"`
+ if [ -n "$c_gen" -a $i -gt "$generations" ]
+ then
+ echo "saw $c_gen packs at generation $i"
+ echo "therefore, repacking everything"
+ packing=1
+ [ -z "$generation" ] && generation=$(($i + 1))
+ elif [ -n "$c_gen" -a "$c_gen" -ge "$generation_width" -a "$i" -lt "$generations" ]
+ then
+ echo -n "generation $i has too many packs "
+ echo "($c_gen >= $generation_width)"
+ echo "repacking at this level and below"
+ packing=1
+ [ -z "$generation" ] && generation=$(($i + 1))
+ fi
+ if [ -n "$packing" ]
+ then
+ for x in $packs; do
+ args="$args --unpacked=$x.pack"
+ redundant="$redundant $x"
+ done
+ fi
+ i=$(($i - 1))
+ done
+ if [ -n "$generation" ]; then
+ [ "$generation" -gt "$generations" ] && generation=$generations
+ [ "$generation" -eq 0 ] && generation=1
+ fi
fi
+
[ -z "$args" ] && args='--unpacked --incremental'
;;
esac
@@ -95,20 +147,23 @@ for name in $names ; do
exit 1
}
rm -f "$PACKDIR/old-pack-$name.pack" "$PACKDIR/old-pack-$name.idx"
+ [ -n "$generation" ] && echo $generation > "$PACKDIR/pack-$name.gen"
done
if test "$remove_redundant" = t
then
- # We know $existing are all redundant.
- if [ -n "$existing" ]
+ echo "removing redundant packs"
+ # We know $redundant are all redundant.
+ if [ -n "$redundant" ]
then
sync
( cd "$PACKDIR" &&
- for e in $existing
+ for e in $redundant
do
case " $fullbases " in
- *" $e "*) ;;
- *) rm -f "$e.pack" "$e.idx" "$e.keep" ;;
+ *" $e "*) echo "ignoring $e" ;;
+ *) echo "removing $e.pack etc";
+ rm -f "$e.pack" "$e.idx" "$e.keep" ;;
esac
done
)
--
1.5.2.0.45.gfea6d-dirty
^ permalink raw reply related
* Re: [PATCH 1/2] Show html help with git-help --html
From: Nguyen Thai Ngoc Duy @ 2007-06-06 11:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm3e9lui.fsf@assigned-by-dhcp.cox.net>
On 6/5/07, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
> > This patch was inspired by ClearCase command 'ct man',...
>
> > diff --git a/help.c b/help.c
> > index 6a9af4d..78b1023 100644
> > --- a/help.c
> > +++ b/help.c
> > @@ -9,6 +9,14 @@
> > #include "common-cmds.h"
> > #include <sys/ioctl.h>
> >
> > +#ifndef HTML_DIR
> > +#define HTML_DIR "/usr/share/html/"
> > +#endif
> > +
> > +#ifndef HTML_PROGRAM
> > +#define HTML_PROGRAM "xdg-open"
> > +#endif
> > +
> > /* most GUI terminals set COLUMNS (although some don't export it) */
> > static int term_columns(void)
> > {
> > @@ -183,6 +191,145 @@ static void show_man_page(const char *git_cmd)
> > execlp("man", "man", page, NULL);
> > }
> >
> > +static void show_html_page(const char *git_cmd)
> > +{
> > + const char *html_dir;
> > + int len, ret, nr_quotes;
> > + char *p, *p2;
> > + const char *cp, *cp2;
> > + struct stat st;
> > + char *quoted_git_cmd;
> > + char *default_command = NULL;
> > + const char *command;
> >...
> > + /* append %p if there is not any %x */
> > + if (!strchr(command, '%')) {
> > + len = strlen(command);
> > + default_command = xmalloc(len + 3 + 1); /* space %p */
> > + strcpy(default_command, command);
> > + strcat(default_command, " %p");
> > + command = default_command;
> > + }
> > +
> > + /* first pass, calculate command length */
> > ...
>
> Hmmm. Makes one wonder why interpolate is not used....
Sorry for my ignorant. I have no idea where to use interpolate :( Did
you mean to pretend adding %p to command without alloc new buffer
(default_command) ?
--
Duy
^ permalink raw reply
* Re: [PATCH] git-mergetool: Make default smarter by considering user's desktop environment and editor
From: David Kastrup @ 2007-06-06 9:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vabvd5u7t.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Junio C Hamano <junkio@cox.net> writes:
>>
>>> Josh Triplett <josh@freedesktop.org> writes:
>>>
>>>> Make git-mergetool prefer meld under GNOME, and kdiff3 under KDE. When
>>>> considering emerge and vimdiff, check $VISUAL and $EDITOR to see which the
>>>> user might prefer.
>>>>
>>>> Signed-off-by: Josh Triplett <josh@freedesktop.org>
>>>
>>> The basic idea is sound. However...
>>>
>>> (1) I wonder if we can get rid of the horribly long if .. elif
>>> chain by using shell function and then iterate a list of them;
>>>
>>> (2) echo "${VISUAL-$EDITOR}" | grep '^emacs'???
>>>
>>> Some people may have explicit path (/home/me/bin/emacs),
>>> and/or runs a variant of emacs called 'xemacs'. Same for
>>> vim.
>>
>> Actually, a lot of people run as editor a program called "emacsclient"
>> or "gnuclient": this one connects to an existing Emacs session and
>> passes its arguments to it. And of course, this is what git-mergetool
>> should then also do.
>
> I do that too, but that is covered by the prefix rule Josh has,
> so it is Ok.
Another note: in my usual Emacs session, EDITOR is set to
/usr/local/emacs-22/bin/emacsclient
which would not be covered... So that should probably be
useemacs=0
for i in ${VISUAL-$EDITOR}
do
case "`basename $i`" in [xX][eE]macs*|[eE]macs*|gnuclient*)
useemacs=1
esac
break
done
This should work even when we are talking about something like
EDITOR="C:\My Programs\XEmacs\gnuclient.exe" -n "C:\My Programs\XEmacs\XEmacs"
And it does not require starting grep for something which the shell
can perfectly well handle on its own. Yes, it does need basename. I
don't see a good way to avoid that.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 3/6] git-fsck: Do thorough verification of tag objects.
From: Junio C Hamano @ 2007-06-06 10:35 UTC (permalink / raw)
To: Johan Herland; +Cc: Matthias Lederhofer, git
In-Reply-To: <200706061226.00689.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> I also noticed that a number of the early tags in the kernel repo use the
> ancient format, and would thus fail fsck.
>
> <stroke-of-madness>
> Could we replace the v0.99 tag (and other ancient tags) with "correct"
> versions, and then encourage users who have already cloned to delete their
> v0.99 tag and re-pull? New clones would of course never see the old tag at
> all. This sure as hell sounds similar to inserting foot into mouth before
> shooting oneself in said foot, but it might still be worth considering...
> </stroke-of-madness>
I actually think that is not too bad. In the course of git
development, the kernel folks had to do the wholesale repository
conversion twice (once when the order of hashing and compression
was swapped, another when the flat tree was made hierarchical),
I think. Compared to that, tags are not referred to by other
entities, so it's much easier to "convert" (iow, re-sign).
^ permalink raw reply
* Re: [PATCH 3/6] git-fsck: Do thorough verification of tag objects.
From: Johan Herland @ 2007-06-06 10:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git
In-Reply-To: <7vwsyh4ewh.fsf@assigned-by-dhcp.cox.net>
On Wednesday 06 June 2007, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Johan Herland <johan@herland.net> writes:
> > ...
> >> Or would you rather switch around the "verbose" and the
> >> "parse_and_verify_tag_buffer()" (i.e. not even attempt the thorough
> >> verification unless in verbose mode)?
> >
> > Actually I was thinking about doing something like this.
> >
> > - if (parse_and_verify_tag_buffer(0, data, size, 1) && verbose)
> > + if (parse_and_verify_tag_buffer(0, data, size, verbose))
>
> Well, after running fsck with --verbose, I take the whole
> suggestion back. I think it is a good idea to do the "thorough"
> tag validation in general, and it should not be buried under the
> verbose output, which is almost useless unless in a very narrow
> special case that you are really trying to see which exact
> object is corrupt.
Take your pick among my patches or feel free to roll your own. :)
> So I think your original patch to signal error on thorough tag
> validation failure is probably a good approach in general.
> People need to know that in git.git fsck would return non-zero
> because of v0.99 tag, but the people who get hit/annoyed by this
> ought to be minority. It may be the case that a major portion
> of git users currently are the ones who futz with the git.git
> repository, but there would be a serious problem if it continues
> to be the case ;-)
I also noticed that a number of the early tags in the kernel repo use the
ancient format, and would thus fail fsck.
<stroke-of-madness>
Could we replace the v0.99 tag (and other ancient tags) with "correct"
versions, and then encourage users who have already cloned to delete their
v0.99 tag and re-pull? New clones would of course never see the old tag at
all. This sure as hell sounds similar to inserting foot into mouth before
shooting oneself in said foot, but it might still be worth considering...
</stroke-of-madness>
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] git-branch: cleanup config file when deleting branches
From: Gerrit Pape @ 2007-06-06 10:09 UTC (permalink / raw)
To: Junio C Hamano, git
When deleting branches, remove the sections referring to these branches
from the config file.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
builtin-branch.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index a5b6bbe..3a70a7d 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -85,6 +85,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
unsigned char sha1[20];
char *name = NULL;
const char *fmt, *remote;
+ char section[PATH_MAX];
int i;
int ret = 0;
@@ -152,9 +153,13 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
error("Error deleting %sbranch '%s'", remote,
argv[i]);
ret = 1;
- } else
+ } else {
printf("Deleted %sbranch %s.\n", remote, argv[i]);
-
+ snprintf(section, sizeof(section), "branch.%s",
+ argv[i]);
+ if (git_config_rename_section(section, NULL) < 0)
+ warning("Update of config-file failed");
+ }
}
if (name)
--
1.5.2
^ permalink raw reply related
* [PATCH] Add git-index-pack -l to list objects in a pack
From: Sam Vilain @ 2007-06-06 9:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
I couldn't figure out how to make git-unpack-objects -n work.
But it seems to be easy in the loop in index-pack
---
index-pack.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index 82c8da3..f657db7 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -45,6 +45,7 @@ static int nr_resolved_deltas;
static int from_stdin;
static int verbose;
+static int list_objects;
static struct progress progress;
@@ -717,6 +718,8 @@ int main(int argc, char **argv)
if (*c)
die("bad %s", arg);
input_len = sizeof(*hdr);
+ } else if (!strcmp(arg, "-l")) {
+ list_objects = 1;
} else if (!strcmp(arg, "-v")) {
verbose = 1;
} else if (!strcmp(arg, "-o")) {
@@ -802,8 +805,11 @@ int main(int argc, char **argv)
free(deltas);
idx_objects = xmalloc((nr_objects) * sizeof(struct pack_idx_entry *));
- for (i = 0; i < nr_objects; i++)
+ for (i = 0; i < nr_objects; i++) {
idx_objects[i] = &objects[i].idx;
+ if (list_objects)
+ printf("%s\n", sha1_to_hex(idx_objects[i]->sha1));
+ }
curr_index = write_idx_file(index_name, idx_objects, nr_objects, sha1);
free(idx_objects);
--
1.5.2.0.45.gfea6d-dirty
^ permalink raw reply related
* Re: [PATCH 3/6] git-fsck: Do thorough verification of tag objects.
From: Junio C Hamano @ 2007-06-06 9:21 UTC (permalink / raw)
To: Johan Herland; +Cc: Matthias Lederhofer, git
In-Reply-To: <7vejkp5ua1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Johan Herland <johan@herland.net> writes:
> ...
>> Or would you rather switch around the "verbose" and the
>> "parse_and_verify_tag_buffer()" (i.e. not even attempt the thorough
>> verification unless in verbose mode)?
>
> Actually I was thinking about doing something like this.
>
> - if (parse_and_verify_tag_buffer(0, data, size, 1) && verbose)
> + if (parse_and_verify_tag_buffer(0, data, size, verbose))
Well, after running fsck with --verbose, I take the whole
suggestion back. I think it is a good idea to do the "thorough"
tag validation in general, and it should not be buried under the
verbose output, which is almost useless unless in a very narrow
special case that you are really trying to see which exact
object is corrupt.
So I think your original patch to signal error on thorough tag
validation failure is probably a good approach in general.
People need to know that in git.git fsck would return non-zero
because of v0.99 tag, but the people who get hit/annoyed by this
ought to be minority. It may be the case that a major portion
of git users currently are the ones who futz with the git.git
repository, but there would be a serious problem if it continues
to be the case ;-)
^ permalink raw reply
* [PATCH 1/2] git-submodule: move cloning into a separate function
From: Lars Hjemli @ 2007-06-06 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vira15uon.fsf@assigned-by-dhcp.cox.net>
This is just a simple refactoring of modules_init() with no change in
functionality.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
On 6/6/07, Junio C Hamano <junkio@cox.net> wrote:
> This seems to be WS munged by your mailer.
Ouch, I didn't notice...
git-submodule.sh | 44 ++++++++++++++++++++++++++++----------------
1 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 6ed5a6c..a89ea88 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -25,6 +25,33 @@ say()
fi
}
+
+#
+# Clone a submodule
+#
+module_clone()
+{
+ path=$1
+ url=$2
+
+ # If there already is a directory at the submodule path,
+ # expect it to be empty (since that is the default checkout
+ # action) and try to remove it.
+ # Note: if $path is a symlink to a directory the test will
+ # succeed but the rmdir will fail. We might want to fix this.
+ if test -d "$path"
+ then
+ rmdir "$path" 2>/dev/null ||
+ die "Directory '$path' exist, but is neither empty nor a git repository"
+ fi
+
+ test -e "$path" &&
+ die "A file already exist at path '$path'"
+
+ git-clone -n "$url" "$path" ||
+ die "Clone of submodule '$path' failed"
+}
+
#
# Run clone + checkout on missing submodules
#
@@ -40,20 +67,6 @@ modules_init()
# repository
test -d "$path"/.git && continue
- # If there already is a directory at the submodule path,
- # expect it to be empty (since that is the default checkout
- # action) and try to remove it.
- # Note: if $path is a symlink to a directory the test will
- # succeed but the rmdir will fail. We might want to fix this.
- if test -d "$path"
- then
- rmdir "$path" 2>/dev/null ||
- die "Directory '$path' exist, but is neither empty nor a git repository"
- fi
-
- test -e "$path" &&
- die "A file already exist at path '$path'"
-
url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
test -z "$url" &&
die "No url found for submodule '$path' in .gitmodules"
@@ -69,8 +82,7 @@ modules_init()
# logical modulename (if present) as key. But this would need
# another fallback mechanism if the module wasn't named.
- git-clone -n "$url" "$path" ||
- die "Clone of submodule '$path' failed"
+ module_clone "$path" "$url" || exit
(unset GIT_DIR && cd "$path" && git-checkout -q "$sha1") ||
die "Checkout of submodule '$path' failed"
--
1.5.2.841.gc9eafb
^ permalink raw reply related
* [PATCH 2/2] git-submodule: clone during update, not during init
From: Lars Hjemli @ 2007-06-06 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <863f2ca67857bc2d09f46f1a5ef6f653d16d5256.1181034736.git.hjemli@gmail.com>
This teaches 'git-submodule init' to register submodule paths and urls in
.git/config instead of actually cloning them. The cloning is now handled
as part of 'git-submodule update'.
With this change it is possible to specify preferred/alternate urls for
the submodules in .git/config before the submodules are cloned.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/git-submodule.txt | 16 +++++++-------
git-submodule.sh | 41 ++++++++++++++++----------------------
t/t7400-submodule-basic.sh | 38 ++++++++++++++++++++++++-----------
3 files changed, 51 insertions(+), 44 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cb0424f..f8fb80f 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -23,15 +23,15 @@ status::
repository. This command is the default command for git-submodule.
init::
- Initialize the submodules, i.e. clone the git repositories specified
- in the .gitmodules file and checkout the submodule commits specified
- in the index of the containing repository. This will make the
- submodules HEAD be detached.
+ Initialize the submodules, i.e. register in .git/config each submodule
+ path and url found in .gitmodules. The key used in git/config is
+ `submodule.$path.url`. This command does not alter existing information
+ in .git/config.
update::
- Update the initialized submodules, i.e. checkout the submodule commits
- specified in the index of the containing repository. This will make
- the submodules HEAD be detached.
+ Update the registered submodules, i.e. clone missing submodules and
+ checkout the commit specified in the index of the containing repository.
+ This will make the submodules HEAD be detached.
OPTIONS
@@ -50,7 +50,7 @@ OPTIONS
FILES
-----
-When cloning submodules, a .gitmodules file in the top-level directory
+When initializing submodules, a .gitmodules file in the top-level directory
of the containing repository is used to find the url of each submodule.
This file should be formatted in the same way as $GIR_DIR/config. The key
to each submodule url is "module.$path.url".
diff --git a/git-submodule.sh b/git-submodule.sh
index a89ea88..e7b6978 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -53,7 +53,7 @@ module_clone()
}
#
-# Run clone + checkout on missing submodules
+# Register submodules in .git/config
#
# $@ = requested paths (default to all)
#
@@ -62,37 +62,23 @@ modules_init()
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
- # Skip submodule paths that already contain a .git directory.
- # This will also trigger if $path is a symlink to a git
- # repository
- test -d "$path"/.git && continue
+ # Skip already registered paths
+ url=$(git-config submodule."$path".url)
+ test -z "$url" || continue
url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
test -z "$url" &&
die "No url found for submodule '$path' in .gitmodules"
- # MAYBE FIXME: this would be the place to check GIT_CONFIG
- # for a preferred url for this submodule, possibly like this:
- #
- # modname=$(GIT_CONFIG=.gitmodules git-config module."$path".name)
- # alturl=$(git-config module."$modname".url)
- #
- # This would let the versioned .gitmodules file use the submodule
- # path as key, while the unversioned GIT_CONFIG would use the
- # logical modulename (if present) as key. But this would need
- # another fallback mechanism if the module wasn't named.
+ git-config submodule."$path".url "$url" ||
+ die "Failed to register url for submodule '$path'"
- module_clone "$path" "$url" || exit
-
- (unset GIT_DIR && cd "$path" && git-checkout -q "$sha1") ||
- die "Checkout of submodule '$path' failed"
-
- say "Submodule '$path' initialized"
+ say "Submodule '$path' registered with url '$url'"
done
}
#
-# Checkout correct revision of each initialized submodule
+# Update each submodule path to correct revision, using clone and checkout as needed
#
# $@ = requested paths (default to all)
#
@@ -101,14 +87,21 @@ modules_update()
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
- if ! test -d "$path"/.git
+ url=$(git-config submodule."$path".url)
+ if test -z "$url"
then
# Only mention uninitialized submodules when its
# path have been specified
test "$#" != "0" &&
say "Submodule '$path' not initialized"
- continue;
+ continue
fi
+
+ if ! test -d "$path"/.git
+ then
+ module_clone "$path" "$url" || exit
+ fi
+
subsha1=$(unset GIT_DIR && cd "$path" &&
git-rev-parse --verify HEAD) ||
die "Unable to find current revision of submodule '$path'"
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 6274729..3940433 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -40,7 +40,7 @@ test_expect_success 'Prepare submodule testing' '
git-add a lib z &&
git-commit -m "super commit 1" &&
mv lib .subrepo &&
- GIT_CONFIG=.gitmodules git-config module.lib.url ./.subrepo
+ GIT_CONFIG=.gitmodules git-config module.lib.url git://example.com/lib.git
'
test_expect_success 'status should only print one line' '
@@ -52,41 +52,55 @@ test_expect_success 'status should initially be "missing"' '
git-submodule status | grep "^-$rev1"
'
-test_expect_success 'init should fail when path is used by a file' '
+test_expect_success 'init should register submodule url in .git/config' '
+ git-submodule init &&
+ url=$(git-config submodule.lib.url) &&
+ if test "$url" != "git://example.com/lib.git"
+ then
+ echo "[OOPS] init succeeded but submodule url is wrong"
+ false
+ elif ! git-config submodule.lib.url ./.subrepo
+ then
+ echo "[OOPS] init succeeded but update of url failed"
+ false
+ fi
+'
+
+test_expect_success 'update should fail when path is used by a file' '
echo "hello" >lib &&
- if git-submodule init
+ if git-submodule update
then
- echo "[OOPS] init should have failed"
+ echo "[OOPS] update should have failed"
false
elif test -f lib && test "$(cat lib)" != "hello"
then
- echo "[OOPS] init failed but lib file was molested"
+ echo "[OOPS] update failed but lib file was molested"
false
else
rm lib
fi
'
-test_expect_success 'init should fail when path is used by a nonempty directory' '
+test_expect_success 'update should fail when path is used by a nonempty directory' '
mkdir lib &&
echo "hello" >lib/a &&
- if git-submodule init
+ if git-submodule update
then
- echo "[OOPS] init should have failed"
+ echo "[OOPS] update should have failed"
false
elif test "$(cat lib/a)" != "hello"
then
- echo "[OOPS] init failed but lib/a was molested"
+ echo "[OOPS] update failed but lib/a was molested"
false
else
rm lib/a
fi
'
-test_expect_success 'init should work when path is an empty dir' '
+test_expect_success 'update should work when path is an empty dir' '
rm -rf lib &&
mkdir lib &&
- git-submodule init &&
+ git-submodule update &&
head=$(cd lib && git-rev-parse HEAD) &&
if test -z "$head"
then
@@ -99,7 +113,7 @@ test_expect_success 'init should work when path is an empty dir' '
fi
'
-test_expect_success 'status should be "up-to-date" after init' '
+test_expect_success 'status should be "up-to-date" after update' '
git-submodule status | grep "^ $rev1"
'
--
1.5.2.841.gc9eafb
^ permalink raw reply related
* Re: [PATCH] git-mergetool: Make default smarter by considering user's desktop environment and editor
From: Junio C Hamano @ 2007-06-06 9:05 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86tztljwgk.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Josh Triplett <josh@freedesktop.org> writes:
>>
>>> Make git-mergetool prefer meld under GNOME, and kdiff3 under KDE. When
>>> considering emerge and vimdiff, check $VISUAL and $EDITOR to see which the
>>> user might prefer.
>>>
>>> Signed-off-by: Josh Triplett <josh@freedesktop.org>
>>
>> The basic idea is sound. However...
>>
>> (1) I wonder if we can get rid of the horribly long if .. elif
>> chain by using shell function and then iterate a list of them;
>>
>> (2) echo "${VISUAL-$EDITOR}" | grep '^emacs'???
>>
>> Some people may have explicit path (/home/me/bin/emacs),
>> and/or runs a variant of emacs called 'xemacs'. Same for
>> vim.
>
> Actually, a lot of people run as editor a program called "emacsclient"
> or "gnuclient": this one connects to an existing Emacs session and
> passes its arguments to it. And of course, this is what git-mergetool
> should then also do.
I do that too, but that is covered by the prefix rule Josh has,
so it is Ok.
^ permalink raw reply
* Re: [PATCH 3/6] git-fsck: Do thorough verification of tag objects.
From: Junio C Hamano @ 2007-06-06 9:03 UTC (permalink / raw)
To: Johan Herland; +Cc: Matthias Lederhofer, git
In-Reply-To: <200706061006.33139.johan@herland.net>
Johan Herland <johan@herland.net> writes:
>> This won't practically be problem in newer repositories, but it
>> is somewhat annoying. Perhaps do this only under the new -v
>> option to git-fsck, say "warning" not "error", and not exit with
>> non-zero because of this?
>
> Like this?
>
> Or would you rather switch around the "verbose" and the
> "parse_and_verify_tag_buffer()" (i.e. not even attempt the thorough
> verification unless in verbose mode)?
Actually I was thinking about doing something like this.
- if (parse_and_verify_tag_buffer(0, data, size, 1) && verbose)
+ if (parse_and_verify_tag_buffer(0, data, size, verbose))
^ permalink raw reply
* Re: [PATCH 1/2] git-submodule: move cloning into a separate function
From: Junio C Hamano @ 2007-06-06 8:55 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Sixt, git@vger.kernel.org
In-Reply-To: <op.ttf34qd99pspc6@localhost>
"Lars Hjemli" <hjemli@gmail.com> writes:
> This is just a simple refactoring of modules_init() with no change in
> functionality.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
>
> On Tue, 05 Jun 2007 12:40:50 +0200, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
>
>> Lars Hjemli wrote:
>>> + module_clone "$path" "$url" || exit $?
>>
>> Minor nit: The idiom that is commonly used in situations like this (see
>> other git-* shell scripts):
>>
>> module_clone "$path" "$url" || exit
>>
>> because exit without argument uses the code of the last command
>> executed.
>>
>
> Thanks, I'll follow up with matching changes to [patch 2/2].
>
This seems to be WS munged by your mailer.
> ...
> + die "Clone of submodule '$path' failed"
> +}
> +
> #
> # Run clone + checkout on missing submodules
> #
> @@ -40,20 +67,6 @@ modules_init()
> # repository
^ permalink raw reply
* Re: [PATCH] git-mergetool: Make default smarter by considering user's desktop environment and editor
From: David Kastrup @ 2007-06-06 8:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vabvd7bfg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Josh Triplett <josh@freedesktop.org> writes:
>
>> Make git-mergetool prefer meld under GNOME, and kdiff3 under KDE. When
>> considering emerge and vimdiff, check $VISUAL and $EDITOR to see which the
>> user might prefer.
>>
>> Signed-off-by: Josh Triplett <josh@freedesktop.org>
>
> The basic idea is sound. However...
>
> (1) I wonder if we can get rid of the horribly long if .. elif
> chain by using shell function and then iterate a list of them;
>
> (2) echo "${VISUAL-$EDITOR}" | grep '^emacs'???
>
> Some people may have explicit path (/home/me/bin/emacs),
> and/or runs a variant of emacs called 'xemacs'. Same for
> vim.
Actually, a lot of people run as editor a program called "emacsclient"
or "gnuclient": this one connects to an existing Emacs session and
passes its arguments to it. And of course, this is what git-mergetool
should then also do.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: J Junio C Hamano @ 2007-06-06 8:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0706060142h2df41f11pa0157a360831736@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 6/6/07, Junio C Hamano <gitster@pobox.com> wrote:
>> I suspect the above misses the point.
>
> Depends on the point. I mean to say: the path in the output
> of the command does not exist anywhere.
>
>> The test "ls /home/user/linux" is not relevant. Ability to say
>> "git fetch /home/user/linux" is.
>
> This is still ambiguous:
Yup, there is an ambiguity. Always has been.
> Which one was fetched when? /home/user/a or /home/user/a.git?
I am half tempted to say that this is very close to "doctor, it
confuses me when I have both of them". Imagine the case where
the source were a remote repository _and_ there was no way other
than interacting with it via git protocol. You cannot really
tell (well, you can tell half, by trying both and if a worked
but a.git didn't you can tell that a.git does not exist) nor you
do not really care.
> Besides, I just noticed git-clone is broken WRT the .git
> as well: I can clone a "a.git" into "b" (and it ignores -l and -s!),
> but I can't fetch the "a" (aka "origin") being in "b". And of
> course, "origin" in "b" is setup as "/path/a", not "/path/a.git".
This probably is worth fixing, independent from what the message
says before or after your patch.
^ permalink raw reply
* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Alex Riesen @ 2007-06-06 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v3b157b4j.fsf@assigned-by-dhcp.cox.net>
On 6/6/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > Otherwise ".git" is removed from every remote name which has it:
> >
> > $ git fetch -v
> > * refs/heads/origin: same as branch 'master' of /home/user/linux
> > commit: 5ecd310
> > $ ls /home/user/linux
> > ls: /home/user/linux: No such file or directory
> > $ ls /home/user/linux.git
> > HEAD objects packed-refs ...
>
> I suspect the above misses the point.
Depends on the point. I mean to say: the path in the output
of the command does not exist anywhere.
> The test "ls /home/user/linux" is not relevant. Ability to say
> "git fetch /home/user/linux" is.
This is still ambiguous:
$ git fetch -v /home/user/a
* fetched /home/user/a
commit: b85c140
$ git fetch -v /home/user/a.git
* fetched /home/user/a
commit: b85c140
Which one was fetched when? /home/user/a or /home/user/a.git?
No imagine you don't see the command (as if git fetch is called
in some frontend). Would you be able to distinguish the sources?
Besides, I just noticed git-clone is broken WRT the .git
as well: I can clone a "a.git" into "b" (and it ignores -l and -s!),
but I can't fetch the "a" (aka "origin") being in "b". And of
course, "origin" in "b" is setup as "/path/a", not "/path/a.git".
^ permalink raw reply
* Re: [ANNOUNCE] qgit new "smart browsing" feature
From: Andy Parkins @ 2007-06-06 8:30 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, Pavel Roskin, Jan Hudec
In-Reply-To: <e5bfff550706051148v57715bb1q88987e3fc6410899@mail.gmail.com>
On Tuesday 2007 June 05, Marco Costalba wrote:
> I've just pushed a patch series that implements your tab widget idea.
I like it a lot. I also like having the settings. I always appreciate
software that lets me work how I like.
> Have fun and let me know!
I've experienced a few occasions when the wheel scroll goes a bit strange.
I've not figured exactly what I did to trigger it, but it was something like
this: when scrolling up and down a lot, and causing the page flip to the
message view, suddenly the scroll didn't work for normal upward scrolling. I
flipped pages again and it started working.
I'll try and narrow down exactly what I'm doing and be more precise.
For now, latest qgit is in /usr/local/bin, so will be getting daily use.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Accept dates before 2000/01/01 when specified as seconds since the epoch
From: Junio C Hamano @ 2007-06-06 8:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <11811175153355-git-send-email-johannes.sixt@telecom.at>
I vaguely recall hitting the same issue soon after date.c was
done, and sending in a patch in the same spirit but with
different implementation (I essentially duplicated that "seconds
since epoch" without any cutoff as the last ditch fallback) long
time ago (this was before I took git over; the patch was rejected).
It almost makes me wonder if it is better to introduce a special
syntax to denote "seconds since epoch plus timezone offset" for
our Porcelain use, instead of keeping this arbitrary cut-off
date which nobody can agree on and which forces us to roll back
from time to time. For one thing, such a syntax would allow us
to talk about a timestamp before the epoch.
Perhaps
"epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]
?
^ permalink raw reply
* Re: git-svn fetch hangs or gives broken pipe on a specific "branch"
From: Eric Wong @ 2007-06-06 8:27 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <689181.83891.qm@web55015.mail.re4.yahoo.com>
Bill Priest <priestwilliaml@yahoo.com> wrote:
> I downloaded the latest release of git 1.5.2 and built
> it on RHEL box. Subversion version is 1.4.2. The
> repository and the git working directory are on the
> same machine (taking networking out of the picture).
> mkdir git_test
> cd git_test
> git-svn init -t tags -b branches -T trunk "my URL"
> Initialized empty Git repository in .git/
> git-svn fetch
> all tags were processed w/o error AFAICT; the first
> branch it tries to work on causes either a hang or a
> "Broken Pipe". I changed from an http:// to svn:// on
> the git-svn init and everything worked correctly.
> This would seem to indicate some type of problem w/
> apache/httpd problem. I looked in the httpd logs and
> didn't see any errors.
> Is this a known problem?
No. Is it reproducible? In my experience, http(s):// has been much
less problematic than svn:// repositories (because I mainly access
https:// ones).
Also, are you certain the git-svn you're running is 1.5.2? When you
say that it processed all tags before hitting a branch, that
sounds like the behavior of a pre-1.5.1 git-svn. Run git-svn --version
just to be sure :)
git-svn 1.5.1+ fetches trunk, tags, and branches in chronological order.
Of course, your project may have never created a branch before any of
your tags are created...
Any details on the branch that caused it to fail would be appreciated,
thanks.
--
Eric Wong
^ permalink raw reply
* [PATCH] git-merge: record merge strategy in the log message on auto resolved merges
From: Gerrit Pape @ 2007-06-06 8:24 UTC (permalink / raw)
To: Junio C Hamano, git
If a strategy module auto resolved the merge cleanly, record the used
strategy in the log message, e.g.:
Merge branch 'maint' using strategy ours
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
I personally find this useful especially for the 'ours' strategy.
git-merge.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 981d69d..b661f74 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -440,7 +440,8 @@ done
if test '' != "$result_tree"
then
parents=$(git-show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
- result_commit=$(printf '%s\n' "$merge_msg" | git-commit-tree $result_tree $parents) || exit
+ result_commit=$(printf '%s\n' "$merge_msg using strategy $wt_strategy" |
+ git-commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge made by $wt_strategy."
dropsave
exit 0
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] Add git-filter-branch
From: Junio C Hamano @ 2007-06-06 8:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <466665AD.CF5B85DF@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Johannes Schindelin wrote:
>> Okay, then. Are you okay with keeping the same options? (See proposed
>> patch below.)
>
> I can live with it. But what do you think of this in addtion? It
> replaces -k, -r, -s in favor of rev-list arguments.
> ...
> A subset of commits in a branch used to be specified by options (-k, -r)
> as well as the branch tip itself (-s). It is more natural (for git users)
> to specify revision ranges like 'master..next' instead. This makes it so.
> If no range is specified it defaults to 'HEAD'.
FWIW, I find this much more sensible and gittish ;-)
^ permalink raw reply
* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Junio C Hamano @ 2007-06-06 8:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0706060045k4098eb05tc596214f8d9673bf@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> Otherwise ".git" is removed from every remote name which has it:
>
> $ git fetch -v
> * refs/heads/origin: same as branch 'master' of /home/user/linux
> commit: 5ecd310
> $ ls /home/user/linux
> ls: /home/user/linux: No such file or directory
> $ ls /home/user/linux.git
> HEAD objects packed-refs ...
I suspect the above misses the point.
The test "ls /home/user/linux" is not relevant. Ability to say
"git fetch /home/user/linux" is.
^ permalink raw reply
* [PATCH] Accept dates before 2000/01/01 when specified as seconds since the epoch
From: Johannes Sixt @ 2007-06-06 8:11 UTC (permalink / raw)
To: git, junkio; +Cc: Johannes Sixt
Tests with git-filter-branch on a repository that was converted from
CVS and that has commits reaching back to 1999 revealed that it is
necessary to parse dates before 2000/01/01 when they are specified
as seconds since 1970/01/01. There is now still a limit, 100000000,
which is 1973/03/03 09:46:40 UTC, in order to allow that dates are
represented as 8 digits.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
date.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/date.c b/date.c
index a9b59a2..4690371 100644
--- a/date.c
+++ b/date.c
@@ -414,9 +414,11 @@ static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt
num = strtoul(date, &end, 10);
/*
- * Seconds since 1970? We trigger on that for anything after Jan 1, 2000
+ * Seconds since 1970? We trigger on that for any numbers with
+ * more than 8 digits. This is because we don't want to rule out
+ * numbers like 20070606 as a YYYYMMDD date.
*/
- if (num > 946684800) {
+ if (num >= 100000000) {
time_t time = num;
if (gmtime_r(&time, tm)) {
*tm_gmt = 1;
--
1.5.2.1.120.gd732
^ 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