* Re: auto gc
From: Jens Axboe @ 2007-11-15 8:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071115082004.GL14735@spearce.org>
On Thu, Nov 15 2007, Shawn O. Pearce wrote:
> Jens Axboe <jens.axboe@oracle.com> wrote:
> ...
> > Packing your repository for optimum performance. You may also
> > run "git gc" manually. See "git help gc" for more information.
> > Generating pack...
> > [...]
> >
> > This is extremely annoying behaviour! If I'm on battery or just in a bit
> > of a hurry, I defeinitely don't want git second guessing me and deciding
> > that it's time to run git gc.
> >
> > I'd suggest just printing a hint that running git gc would increase
> > performance, doing it automatically is definitely bad style (even more
> > so when then yet again changed git refs layout even breaks old scripts,
> > when git gc has run).
>
> Set the following and it won't run automatically anymore for you:
>
> git config --global gc.auto 0
> git config --global gc.autopacklimit 0
OK
> More recently this message has been changed to:
>
> Packing your repository for optimum performance. You may also
> run "git gc" manually. See "git help gc" for more information.
Great, that's a lot more appropriate in my opinion. I'll just update to
a later git.
Thanks!
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] Bisect reset: remove bisect refs that may have been packed.
From: Johannes Sixt @ 2007-11-15 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7vwssj6hw8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> + git for-each-ref --format='%(refname) %(objectname)' refs/bisect/\* refs/heads/bisect |
> + while read ref hash
If you also swap %(refname) and %(objectname), then this is also not prone
to whitespace in refnames. (Yes, I know, there shouldn't be such, but...)
-- Hannes
^ permalink raw reply
* Re: auto gc
From: Shawn O. Pearce @ 2007-11-15 8:20 UTC (permalink / raw)
To: Jens Axboe; +Cc: git
In-Reply-To: <20071115081025.GC638@kernel.dk>
Jens Axboe <jens.axboe@oracle.com> wrote:
...
> Packing your repository for optimum performance. You may also
> run "git gc" manually. See "git help gc" for more information.
> Generating pack...
> [...]
>
> This is extremely annoying behaviour! If I'm on battery or just in a bit
> of a hurry, I defeinitely don't want git second guessing me and deciding
> that it's time to run git gc.
>
> I'd suggest just printing a hint that running git gc would increase
> performance, doing it automatically is definitely bad style (even more
> so when then yet again changed git refs layout even breaks old scripts,
> when git gc has run).
Set the following and it won't run automatically anymore for you:
git config --global gc.auto 0
git config --global gc.autopacklimit 0
More recently this message has been changed to:
Packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
The two options noted above are described in the manual for git-gc.
-
Shawn.
^ permalink raw reply
* Re: [PATCH v2] Bisect reset: remove bisect refs that may have been packed.
From: Junio C Hamano @ 2007-11-15 8:18 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Sixt
In-Reply-To: <20071115081807.06fe092b.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> If refs were ever packed in the middle of bisection, the bisect
> refs were not removed from the "packed-refs" file.
>
> This patch fixes this problem by using "git update-ref -d $ref $hash"
> in "bisect_clean_state".
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Thanks. Just a few nits.
On top of your patch...
- You forgot to remove one "removal of filesystem refs";
- for-each-ref takes more than one patterns.
git-bisect.sh | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 584906f..21ed02f 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -350,17 +350,12 @@ bisect_reset() {
}
bisect_clean_state() {
- rm -fr "$GIT_DIR/refs/bisect"
-
# There may be some refs packed during bisection.
- git for-each-ref --format='%(refname) %(objectname)' \
- "refs/bisect/*" | while read ref hash
+ git for-each-ref --format='%(refname) %(objectname)' refs/bisect/\* refs/heads/bisect |
+ while read ref hash
do
git update-ref -d $ref $hash
done
-
- hash=$(git show-ref --hash refs/heads/bisect)
- test -n "$hash" && git update-ref -d refs/heads/bisect $hash
rm -f "$GIT_DIR/BISECT_LOG"
rm -f "$GIT_DIR/BISECT_NAMES"
rm -f "$GIT_DIR/BISECT_RUN"
^ permalink raw reply related
* Re: [Discussion] cherry-picking a merge
From: Shawn O. Pearce @ 2007-11-15 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3av86iqa.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> You can replay the change between A and M (in other words, the
> effect of merging B into A) on top of C to create a new commit,
> with:
>
> $ git cherry-pick -m 1 M
>
> In the current implementation, the resulting commit has a single
> parent C. This is quite similar to a squash merge of B into C.
>
> When you think about it, as long as the topological relationship
> between A and B is very similar to that of C and B (iow,
> "merge-base A B" and "merge-base C B" are the same), the effect
> should be the same as a real merge between B and C, shouldn't it?
>
> ---o---o---C---A---M
> \ \ /
> o---o---\---B
> \ \
> `---X
>
> I am wondering if it makes sense to record the result of
> "cherry-pick -m" as a real merge between the current HEAD and
> all the other parents of the cherry-picked merge except the one
> that is named with the <parent-number>.
Yes.
Then `rebase -i` might be able to learn how to "pick" merge commits.
And then my coworkers can stop bothering me about that. And just
do it themselves.
I used to think of merges as something special. I now really only
look at them as being special *during* the merge process, as you
may need to generate that recursive base. But otherwise its just
"diff M^1..M". So why isn't it?
:-)
--
Shawn.
^ permalink raw reply
* Re: How to change a submodue as a subdirectory?
From: Ping Yin @ 2007-11-15 8:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711150614380.4362@racer.site>
On Nov 15, 2007 2:16 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Provided you do not kill the repository of the submodule (you have some
> public repo for that, right?) you will not lose anything, since the
> history of the superproject has pointers to the submodule.
>
> But I guess that you want something different... You probably want to
> rewrite history as if the submodule had not been a submodule at all,
> right?
Yeah, this actually what i want. Now i find a way:
1. move submodule subB outside
mv subB /newpath/to/subB
git-commit subB
2. git-filter-branch to rename all files in subA repository to subB
directory (say subB/subB).
cd newpath/to/subB &&
git filter-branch --index-filter \
'git ls-files -s | sed "s-\t-&subB/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
3. in directory of super project superA, git-fetch repository subB to
branch subB
cd path/to/superA && git-fetch /newpath/to/subB master:subB
4. git-cherry-pick each commit (except the root commit) of branch
subB to the super project superA
git-cherry HEAD subB | awk '{print $2}' | sed -n '2,$ p' | while
read name; do git cherry-pick $name; done
>
> Ciao,
> Dscho
>
>
--
Ping Yin
^ permalink raw reply
* auto gc
From: Jens Axboe @ 2007-11-15 8:10 UTC (permalink / raw)
To: git
Hi,
I've noticed that recent git versions, in a supposedly helpful fashion,
run garbage collection automatically after a pull if it deems it
necessary:
[...]
Resolving 556 deltas...
100% (556/556) done
Updating 9418d5d..99fee6d
Fast forward
Packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Generating pack...
[...]
This is extremely annoying behaviour! If I'm on battery or just in a bit
of a hurry, I defeinitely don't want git second guessing me and deciding
that it's time to run git gc.
I'd suggest just printing a hint that running git gc would increase
performance, doing it automatically is definitely bad style (even more
so when then yet again changed git refs layout even breaks old scripts,
when git gc has run).
--
Jens Axboe
^ permalink raw reply
* [Discussion] cherry-picking a merge
From: Junio C Hamano @ 2007-11-15 8:00 UTC (permalink / raw)
To: git
Earlier "git cherry-pick" learned the "-m <parent-number>"
option to allow cherry-picking a merge commit.
When you have this history:
---o---o---C---A---M
\ /
o---o-------B
You can replay the change between A and M (in other words, the
effect of merging B into A) on top of C to create a new commit,
with:
$ git cherry-pick -m 1 M
In the current implementation, the resulting commit has a single
parent C. This is quite similar to a squash merge of B into C.
When you think about it, as long as the topological relationship
between A and B is very similar to that of C and B (iow,
"merge-base A B" and "merge-base C B" are the same), the effect
should be the same as a real merge between B and C, shouldn't it?
---o---o---C---A---M
\ \ /
o---o---\---B
\ \
`---X
I am wondering if it makes sense to record the result of
"cherry-pick -m" as a real merge between the current HEAD and
all the other parents of the cherry-picked merge except the one
that is named with the <parent-number>.
^ permalink raw reply
* Re: Integrating with hooks
From: Johannes Sixt @ 2007-11-15 7:57 UTC (permalink / raw)
To: Todd A. Jacobs; +Cc: git
In-Reply-To: <20071115011837.GD32746@penguin.codegnome.org>
Todd A. Jacobs schrieb:
> On Wed, Nov 14, 2007 at 12:07:29AM +0100, Jakub Narebski wrote:
>
>> Take a look at gitattributes(5), namely 'filter' attribute.
>
> Thanks, I took a look at the man page you suggested. The "ident" feature
> almost does what I want, but doesn't seem to take any sort of format
> string. So, I thought I'd explore "filter," but can't really find any
> examples of how to implement the smudge and clean commands, which seem
> to be what I'm really trying to do here.
A clean and smudge filter processes one file at a time. It reads the old
content from stdin and writes the result to stdout.
There is a tiny example in the test suite, t/t0021-conversion.sh, look for
rot13.sh.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Unify the use of standard set of exclude files
From: Junio C Hamano @ 2007-11-15 7:41 UTC (permalink / raw)
To: git; +Cc: shunichi fuji, Pierre Habouzit, Andreas Ericsson,
Johannes Schindelin
In-Reply-To: <7v4pfo813i.fsf_-_@gitster.siamese.dyndns.org>
By the way, I think the way in which excluded() is called inside
ls-files for --cached, --staged, --deleted and --modified is
totally bogus, and as a result, ls-files does not honor
per-directory exclude files properly.
This is because dir.c:excluded() needs to be called after
setting up the exclude_list stack properly, just like how
dir.c:read_directory() and unpack-trees.c:unpack_trees_rec()
do. The directory traversal should look like this:
- Call push_exclude_per_directory() upon entering a directory.
This reads the per directory exclude file (.gitignore) from
the directory, and push it into the existing stack. This
way, the patterns from the file is set up to override the
existing patterns from the .gitignore files of higher level
directories.
- Ask excluded() if your paths in that directory matches, and
do whatever you want to happen.
- Call pop_exclude_per_directory() when leaving the directory,
to free the patterns read from the .gitignore file there.
Because the codepaths in question just iterate over the cache
entries without telling the per-directory exclude file stack
which set of .gitignore files should apply to the inquiry using
push/pop mechanism, I _think_ excluded(dir, "a/b") calls in the
codepaths do not honor .gitignore nor a/.gitignore file when
checking if "a/b" is to be ignored.
The push/pop mechanism was designed to be used in read_directory()
and it was a good match to the code structure to make recursive
calls to read_directory_recursive(). Because the paths are
sorted in the pathname order, we can make appropriate calls to
push/pop while iterating over the cache in these codepaths to
fix this issue.
As a longer term fix, I think it makes more sense to make
excluded() automatically push/pop the per directory exclude file
stack, just like the gitattributes mechanism maintains the
attribute stack to match and cache the last checked path.
^ permalink raw reply
* Re: [PATCH] Grammar fixes for gitattributes documentation
From: Jeff King @ 2007-11-15 7:27 UTC (permalink / raw)
To: David Symonds; +Cc: Wincent Colaiuta, Junio C Hamano, Git Mailing List
In-Reply-To: <ee77f5c20711142320x1a070b21xf00f0853fe09e34c@mail.gmail.com>
On Thu, Nov 15, 2007 at 06:20:10PM +1100, David Symonds wrote:
> > >>> +A `filter` attribute can be set to a string value which names a
> > >>> filter driver specified in the configuration.
>
> "that" should be used to introduce restrictive clauses (as you point
> out), and this use should be a restrictive clause, since you can't set
> the attribute to just any value--you need to set it to the value
> *that* names the desired filter driver.
I don't see it as restrictive, but I can see how one would. I think it
is not a case of "this wording is correct" but rather "this wording
means one thing, and the other wording means another."
But the two meanings are likely to be interpreted the same way, so I
think it isn't a big deal (although "which" without a comma _is_ wrong
:) ).
-Peff
^ permalink raw reply
* Re: [PATCH] Grammar fixes for gitattributes documentation
From: David Symonds @ 2007-11-15 7:20 UTC (permalink / raw)
To: Jeff King; +Cc: Wincent Colaiuta, Junio C Hamano, Git Mailing List
In-Reply-To: <20071115071558.GE10185@sigill.intra.peff.net>
On Nov 15, 2007 6:15 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 14, 2007 at 10:04:25AM +0100, Wincent Colaiuta wrote:
>
> >>> +A `filter` attribute can be set to a string value which names a
> >>> filter driver specified in the configuration.
> >>
> >> Will we get the canned "which vs that" discussion on this change?
> >
> > Perhaps. Neither would be incorrect, although technically "that" is a
> > tighter match.
>
> Really? I would think "which" works better, in that it is not
> restrictive. I.e., "The filter attribute is set to a string. This
> string, btw, names a filter driver" (which) rather than "The filter
> attribute is set to a string, and from the set of strings, it is set to
> the particular string that names a filter driver" (that).
"that" should be used to introduce restrictive clauses (as you point
out), and this use should be a restrictive clause, since you can't set
the attribute to just any value--you need to set it to the value
*that* names the desired filter driver.
Dave.
... writing a thesis, so has grammar on the brain.
^ permalink raw reply
* Re: [PATCH] Grammar fixes for gitattributes documentation
From: Jeff King @ 2007-11-15 7:15 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <3461FD6E-1C46-4278-9EB0-5D730BB99084@wincent.com>
On Wed, Nov 14, 2007 at 10:04:25AM +0100, Wincent Colaiuta wrote:
>>> +A `filter` attribute can be set to a string value which names a
>>> filter driver specified in the configuration.
>>
>> Will we get the canned "which vs that" discussion on this change?
>
> Perhaps. Neither would be incorrect, although technically "that" is a
> tighter match.
Really? I would think "which" works better, in that it is not
restrictive. I.e., "The filter attribute is set to a string. This
string, btw, names a filter driver" (which) rather than "The filter
attribute is set to a string, and from the set of strings, it is set to
the particular string that names a filter driver" (that).
But in the non-restrictive case, it should be in a parenthetical phrase:
A `filter` attribute can be set to a string value, which names a
filter driver specified in the configuration.
I think either is readable, though. :)
-Peff
^ permalink raw reply
* Re: Problem in our test setup
From: Junio C Hamano @ 2007-11-15 7:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711150618300.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Because my prefix is the default prefix, which is $HOME/bin, and which is
> not turned off in the tests. So git finds "runstatus", because it is
> still installed.
Yes, we have a problem.
We could solve this for commands issued in "git foo" form by not
looking for "git-foo" anywhere other than in git_exec_path. The
scripts and tests only prepend GIT_EXEC_PATH to their PATH and
run "git foo" or "git-foo", but if we replace all of them to the
non-dash form, wouldn't that solve the issue as well?
^ permalink raw reply
* [PATCH v2] Bisect reset: remove bisect refs that may have been packed.
From: Christian Couder @ 2007-11-15 7:18 UTC (permalink / raw)
To: Junio Hamano; +Cc: git, Johannes Sixt
If refs were ever packed in the middle of bisection, the bisect
refs were not removed from the "packed-refs" file.
This patch fixes this problem by using "git update-ref -d $ref $hash"
in "bisect_clean_state".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 11 ++++++++++-
t/t6030-bisect-porcelain.sh | 12 ++++++++++++
2 files changed, 22 insertions(+), 1 deletions(-)
Ooops, there was a problem with the previous patch
if "git bisect reset" was used when not bisecting.
Sorry.
diff --git a/git-bisect.sh b/git-bisect.sh
index 1ed44e5..584906f 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -351,7 +351,16 @@ bisect_reset() {
bisect_clean_state() {
rm -fr "$GIT_DIR/refs/bisect"
- rm -f "$GIT_DIR/refs/heads/bisect"
+
+ # There may be some refs packed during bisection.
+ git for-each-ref --format='%(refname) %(objectname)' \
+ "refs/bisect/*" | while read ref hash
+ do
+ git update-ref -d $ref $hash
+ done
+
+ hash=$(git show-ref --hash refs/heads/bisect)
+ test -n "$hash" && git update-ref -d refs/heads/bisect $hash
rm -f "$GIT_DIR/BISECT_LOG"
rm -f "$GIT_DIR/BISECT_NAMES"
rm -f "$GIT_DIR/BISECT_RUN"
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 53956c0..f09db62 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -71,6 +71,18 @@ test_expect_success 'bisect start with one bad and good' '
git bisect next
'
+test_expect_success 'bisect reset removes packed refs' '
+ git bisect reset &&
+ git bisect start &&
+ git bisect good $HASH1 &&
+ git bisect bad $HASH3 &&
+ git pack-refs --all --prune &&
+ git bisect next &&
+ git bisect reset &&
+ test -z "$(git for-each-ref "refs/bisect/*")" &&
+ test -z "$(git for-each-ref "refs/heads/bisect")"
+'
+
# $HASH1 is good, $HASH4 is bad, we skip $HASH3
# but $HASH2 is bad,
# so we should find $HASH2 as the first bad commit
--
1.5.3.5.722.g789fd-dirty
^ permalink raw reply related
* Re: [PATCH] Unify the use of standard set of exclude files
From: Jeff King @ 2007-11-15 7:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, shunichi fuji, Pierre Habouzit, Andreas Ericsson,
Johannes Schindelin
In-Reply-To: <7v4pfo813i.fsf_-_@gitster.siamese.dyndns.org>
On Wed, Nov 14, 2007 at 10:38:41PM -0800, Junio C Hamano wrote:
> This teaches "git ls-files" to read the standard set of exclude
> files when no exclude patterns nor files is given from the
> command line. We used to error out in such a case.
Is that really the case, or is this _just_ when we have asked to include
ignored files in the output? Or maybe I am missing something fundamental
here.
git-add--interactive:list_untracked needs something like this, but I
don't think your patch will work. We need something more like this (also
on maint because your standard exclude patch is):
-- >8 --
git-ls-files: add --exclude-standard
This provides a way for scripts to get at the new standard exclude
function.
---
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 9e454f0..2ec0c0d 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -15,6 +15,7 @@ SYNOPSIS
[-x <pattern>|--exclude=<pattern>]
[-X <file>|--exclude-from=<file>]
[--exclude-per-directory=<file>]
+ [--exclude-standard]
[--error-unmatch] [--with-tree=<tree-ish>]
[--full-name] [--abbrev] [--] [<file>]\*
@@ -77,6 +78,10 @@ OPTIONS
read additional exclude patterns that apply only to the
directory and its subdirectories in <file>.
+--exclude-standard::
+ Add the standard git exclusions: .git/info/exclude, .gitignore
+ in each directory, and the user's global exclusion file.
+
--error-unmatch::
If any <file> does not appear in the index, treat this as an
error (return 1).
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 171d449..da97278 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -401,8 +401,8 @@ static void overlay_tree(const char *tree_name, const char *prefix)
static const char ls_files_usage[] =
"git-ls-files [-z] [-t] [-v] (--[cached|deleted|others|stage|unmerged|killed|modified])* "
"[ --ignored ] [--exclude=<pattern>] [--exclude-from=<file>] "
- "[ --exclude-per-directory=<filename> ] [--full-name] [--abbrev] "
- "[--] [<file>]*";
+ "[ --exclude-per-directory=<filename> ] [--exclude-standard] "
+ "[--full-name] [--abbrev] [--] [<file>]*";
int cmd_ls_files(int argc, const char **argv, const char *prefix)
{
@@ -510,6 +510,11 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
dir.exclude_per_dir = arg + 24;
continue;
}
+ if (!strcmp(arg, "--exclude-standard")) {
+ exc_given = 1;
+ setup_standard_excludes(&dir);
+ continue;
+ }
if (!strcmp(arg, "--full-name")) {
prefix_offset = 0;
continue;
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index ac598f8..0317ad9 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -37,10 +37,7 @@ sub list_untracked {
chomp $_;
$_;
}
- run_cmd_pipe(qw(git ls-files --others
- --exclude-per-directory=.gitignore),
- "--exclude-from=$GIT_DIR/info/exclude",
- '--', @_);
+ run_cmd_pipe(qw(git ls-files --others --exclude-standard --), @_);
}
my $status_fmt = '%12s %12s %s';
^ permalink raw reply related
* Re: [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
From: Steffen Prohaska @ 2007-11-15 6:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1194984306-3181-12-git-send-email-johannes.sixt@telecom.at>
On Nov 13, 2007, at 9:05 PM, Johannes Sixt wrote:
> If ETC_GITCONFIG is not an absolute path, interpret it relative to
> --exec-dir. This makes the installed binaries relocatable because the
> prefix is not compiled-in.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> config.c | 13 ++++++++++++-
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/config.c b/config.c
> index dd7e9ad..9f014bb 100644
> --- a/config.c
> +++ b/config.c
> @@ -6,6 +6,7 @@
> *
> */
> #include "cache.h"
> +#include "exec_cmd.h"
>
> #define MAXNAME (256)
>
> @@ -454,7 +455,17 @@ int git_config_from_file(config_fn_t fn, const
> char *filename)
>
> const char *git_etc_gitconfig(void)
> {
> - return ETC_GITCONFIG;
> + static const char *system_wide;
> + if (!system_wide) {
> + system_wide = ETC_GITCONFIG;
> + if (!is_absolute_path(system_wide)) {
> + /* interpret path relative to exec-dir */
> + const char *exec_path = git_exec_path();
> + system_wide = prefix_path(exec_path, strlen(exec_path),
> + system_wide);
> + }
> + }
> + return system_wide;
> }
When I first stumbled over this code in msysgit I didn't
understand how to use it for making git relocatable. Maybe
I didn't appreciate the clue about the relative path, which
indicates to change the Makefile to provide ETC_GITCONFIG
starting with "..".
I think I stumbled over the idea to build a path by starting
with an absolute path to exec_path and than go up with
".." before going down again to etc/gitconfig. So, a paths
would for example be "C:/msysgit/bin/../etc/gitconfig".
Hence I wrote a function git_install_prefix(), which directly
points to "C:/msysgit". It is used in the following way:
----
system_wide = prefix_path(exec_path, strlen(exec_path),
system_wide);
}
+#if __MINGW32__
+ /*
+ * If it is an absolute Unix path it is prefixed with
+ * the git_install_prefix().
+ */
+ else if (system_wide[0] == '/') {
+ const char* prefix = git_install_prefix();
+ system_wide = prefix_path(prefix, strlen(prefix),
+ system_wide);
+ }
+#endif
}
return system_wide;
}
----
This is not very portable. Prefixing _every_ absolute Unix path
makes sense for MINGW to map the fake unix root to its real
location in the Windows filesystem. But this probably doesn't
make sense on Unix at all. And it's probably not needed at
all. I should have just read your code more carefully ;)
Your solution provides a sensible way to handle the issue.
Now I'm wondering if we could make path relocation a bit more
explicit. How about doing something like.
system_wide = relocate_path(ETC_GITCONFIG);
and relocate_path(const char *) would expand a format
string in path. At this point I see only a single %s
that would be expanded with the install prefix. If
ETC_GITCONFIG is "%s/etc/gitconfig" relocate path will return
"C:/msysgit/bin/etc/gitconfig" for my above example. It is
basically a printf with the install prefix path.
This would support three cases:
- absolute path
- relative path
- paths that will be relocated. The path includes a '%s'
to indicate relocation.
I'm not sure if we ever need to support relative paths
without relocating them.
What do you think? If my comments make any sense to you,
I could code a patch next weekend.
BTW, if we changed PATCH 11/11 we'd obviously change PATCH
9/11, too.
Steffen
> int git_config(config_fn_t fn)
> --
> 1.5.3.5.1592.g0d6db
^ permalink raw reply
* [PATCH] Unify the use of standard set of exclude files
From: Junio C Hamano @ 2007-11-15 6:38 UTC (permalink / raw)
To: git; +Cc: shunichi fuji, Pierre Habouzit, Andreas Ericsson,
Johannes Schindelin
In-Reply-To: <7vsl39l0b7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> We probably could change git-ls-files to use the standard set
> when no excludes are specified from the command line, or
> something like that, but this will be a change in semantics that
> would affect the scripts in a subtle way. I am somewhat
> reluctant to make such a change.
So here it is.
This teaches "git ls-files" to read the standard set of exclude
files when no exclude patterns nor files is given from the
command line. We used to error out in such a case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-ls-files.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index e0b856f..50dcb89 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -542,11 +542,8 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
ps_matched = xcalloc(1, num);
}
- if (dir.show_ignored && !exc_given) {
- fprintf(stderr, "%s: --ignored needs some exclude pattern\n",
- argv[0]);
- exit(1);
- }
+ if (dir.show_ignored && !exc_given)
+ setup_standard_excludes(&dir);
/* With no flags, we default to showing the cached files */
if (!(show_stage | show_deleted | show_others | show_unmerged |
^ permalink raw reply related
* Re: [PATCH] Bisect visualize: use "for-each-ref" to list all good refs.
From: Christian Couder @ 2007-11-15 6:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <7voddxkzzw.fsf@gitster.siamese.dyndns.org>
Le mercredi 14 novembre 2007, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > In bisect_visualize, "cd $GIT_DIR/refs && echo bisect/good-*" was
> > still used instead of "git for-each-ref". This patch fix it.
>
> Heh, it still uses
>
> echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
>
> So we are still _very_ much tied to refs on the filesystem not
> in packed-refs.
Yes, but someone (guess who) started to modernize git-bisect by
using "for-each-ref":
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=6fecf1915c5fd0b14e2ca2ec9e1a6b620abfb5c2
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=0a5280a9f444c33b0e4ebf2f073df5899c112cf8
so I thought it would be fine to finish this modernization work.
> Even worse is that bisect_clean_state uses
>
> rm -fr "$GIT_DIR/refs/bisect"
>
> so if you ever pack your refs in the middle of bisection and
> then clean the state, you will still carry the old good set of
> commits that are somewhat hard to cull.
Thanks for reminding me of this problem. I just posted a patch that should
fix it.
Best regards,
Christian.
^ permalink raw reply
* [PATCH] Bisect reset: remove bisect refs that may have been packed.
From: Christian Couder @ 2007-11-15 6:40 UTC (permalink / raw)
To: Junio Hamano; +Cc: git, Johannes Sixt
If refs were ever packed in the middle of bisection, the bisect
refs were not removed from the "packed-refs" file.
This patch fixes this problem by using "git update-ref -d $ref $hash"
in "bisect_clean_state".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 11 ++++++++++-
t/t6030-bisect-porcelain.sh | 12 ++++++++++++
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 3aac816..73a4da2 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -352,7 +352,16 @@ bisect_reset() {
bisect_clean_state() {
rm -fr "$GIT_DIR/refs/bisect"
- rm -f "$GIT_DIR/refs/heads/bisect"
+
+ # There may be some refs packed during bisection.
+ git for-each-ref --format='%(refname) %(objectname)' \
+ "refs/bisect/*" | while read ref hash
+ do
+ git update-ref -d $ref $hash
+ done
+
+ hash=$(git show-ref --hash refs/heads/bisect)
+ git update-ref -d refs/heads/bisect $hash
rm -f "$GIT_DIR/BISECT_LOG"
rm -f "$GIT_DIR/BISECT_NAMES"
rm -f "$GIT_DIR/BISECT_RUN"
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 53956c0..f09db62 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -71,6 +71,18 @@ test_expect_success 'bisect start with one bad and good' '
git bisect next
'
+test_expect_success 'bisect reset removes packed refs' '
+ git bisect reset &&
+ git bisect start &&
+ git bisect good $HASH1 &&
+ git bisect bad $HASH3 &&
+ git pack-refs --all --prune &&
+ git bisect next &&
+ git bisect reset &&
+ test -z "$(git for-each-ref "refs/bisect/*")" &&
+ test -z "$(git for-each-ref "refs/heads/bisect")"
+'
+
# $HASH1 is good, $HASH4 is bad, we skip $HASH3
# but $HASH2 is bad,
# so we should find $HASH2 as the first bad commit
--
1.5.3.5.1728.g34b3e-dirty
^ permalink raw reply related
* [PATCH for kh/commit] Replace "runstatus" with "status" in the tests
From: Johannes Schindelin @ 2007-11-15 6:27 UTC (permalink / raw)
To: git, gitster
We no longer have "runstatus", but running "status" is no longer that
expensive anyway; it is a builtin.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t3001-ls-files-others-exclude.sh | 2 +-
t/t4001-diff-rename.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
index ae0639d..e25b255 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -86,7 +86,7 @@ EOF
git config core.excludesFile excludes-file
-git runstatus | grep "^# " > output
+git status | grep "^# " > output
cat > expect << EOF
# .gitignore
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 063e792..877c1ea 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -71,10 +71,10 @@ test_expect_success 'favour same basenames over different ones' '
git rm path1 &&
mkdir subdir &&
git mv another-path subdir/path1 &&
- git runstatus | grep "renamed: .*path1 -> subdir/path1"'
+ git status | grep "renamed: .*path1 -> subdir/path1"'
test_expect_success 'favour same basenames even with minor differences' '
git show HEAD:path1 | sed "s/15/16/" > subdir/path1 &&
- git runstatus | grep "renamed: .*path1 -> subdir/path1"'
+ git status | grep "renamed: .*path1 -> subdir/path1"'
test_done
--
1.5.3.5.1785.g714b8
^ permalink raw reply related
* Problem in our test setup
From: Johannes Schindelin @ 2007-11-15 6:24 UTC (permalink / raw)
To: git
Hi,
I just realised that our test setup has a serious problem. In my
semi-private builtin-commit branch, there is no runstatus anymore. Now,
I got a new toy yesterday, and installed git on it (my fork, including
builtin-commit), and all of a sudden tests were failing.
The failing tests were t3001 and t4001, because they call runstatus, and
runstatus is no longer there in the builtin-commit branch.
So why did I not catch this earlier?
Because my prefix is the default prefix, which is $HOME/bin, and which is
not turned off in the tests. So git finds "runstatus", because it is
still installed.
Now, things get worse if you install to /usr/bin/, which I do sometimes,
too, because you _cannot_ remove that from the PATH.
Okay, so removing a command is not all that common, but that means that we
have to be extra careful when we do so.
Ciao,
Dscho
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Jeff King @ 2007-11-15 6:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sergei Organov, Matthieu Moy, Johannes Schindelin, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <7vfxz8hbcf.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 14, 2007 at 11:32:32AM -0800, Junio C Hamano wrote:
> We already spent quite a lot of time on this thread, and at
> least to me I feel that my time would have been better spent if
> instead I were looking at patches on some other topics, or
> working on cleaning up cherry-pick/revert implementation.
Personally, I think cloning empty repositories should be allowed, but
there are many more interesting things to be working on right now.
However, I think the current behavior of not printing anything is quite
bad, so here is a productive email that didn't take too long to write.
-- >8 --
git-clone: print an error message when trying to clone empty repo
Previously, cloning an empty repository looked like this:
$ (mkdir parent && cd parent && git --bare init)
$ git-clone parent child
Initialized empty Git repository in /home/peff/clone/child/.git/
$ cd child
-bash: cd: child: No such file or directory
$ echo 'wtf?' | mail git@vger.kernel.org
Now we at least report that the clone was not successful.
---
diff --git a/git-clone.sh b/git-clone.sh
index 18003ab..e2b7a9c 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -278,7 +278,8 @@ yes)
find objects -type f -print | sed -e 1q)
# objects directory should not be empty because
# we are cloning!
- test -f "$repo/$sample_file" || exit
+ test -f "$repo/$sample_file" ||
+ die "fatal: cannot clone empty repository"
if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
then
rm -f "$GIT_DIR/objects/sample"
^ permalink raw reply related
* Re: How to change a submodue as a subdirectory?
From: Johannes Schindelin @ 2007-11-15 6:16 UTC (permalink / raw)
To: Ping Yin; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <46dff0320711142136r2c70d698vd380c02188f95507@mail.gmail.com>
Hi,
On Thu, 15 Nov 2007, Ping Yin wrote:
> On Nov 15, 2007 4:26 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> > Ping Yin, Wed, Nov 14, 2007 15:37:57 +0100:
> > > I have a super project superA, and a submodue subB. Now i decide to
> > > switch subB from submodule to sub directory. Any good way to do that
> > > and not losing any history?
> >
> > $ mv subB sub
> > $ git add sub
> > $ git update-index --force-remove subB
> > $ git commit
> >
> > Which history were you afraid of losing?
> >
> I want to keep the history of the submodule
Provided you do not kill the repository of the submodule (you have some
public repo for that, right?) you will not lose anything, since the
history of the superproject has pointers to the submodule.
But I guess that you want something different... You probably want to
rewrite history as if the submodule had not been a submodule at all,
right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Extend cat-file to take multiple arguments or read input from stdin.
From: Junio C Hamano @ 2007-11-15 6:09 UTC (permalink / raw)
To: hanwen; +Cc: git, Adam Roben
In-Reply-To: <fhgitt$b8d$1@ger.gmane.org>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> I know, and that's what I was thinking. However, I was hoping someone else
> would pick up the hint :-)
>
> I suppose fast-export would just be cat-file with a different name and
> slightly saner interface. How about
>
> type <sha1> <newline>
> size <sha1> <newline>
> dump <type> <sha1> <newline>
I wondered why that looked so familiar ;-)
http://thread.gmane.org/gmane.comp.version-control.git/62295/focus=62441
Adam Roben CC'ed.
^ 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