* Re: is gitosis secure?
From: Tait @ 2008-12-15 21:28 UTC (permalink / raw)
To: git
In-Reply-To: <20081215071737.GA32387@glandium.org>
> But ssh itself allows you to do proxying. See ProxyCommand in
> ssh_config's manpage.
I think that's exactly the point David Lang is making.
For the security-paranoid, maybe the approach gitosis should take
is to develop an ssh subserver (like sftp). The possibilities for
restricted access and configuration are greatly expanded by such an
approach. One could configure "sgit" to chroot into some account-specific
subdirectory. The sshd configuration can be tweaked to allow sgit access
but not terminal or exec request (or port forwarding) access, perhaps
dependent on group membership.
^ permalink raw reply
* Re: [PATCH] gc: make --prune useful again by accepting an optional parameter
From: Brandon Casey @ 2008-12-15 21:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <j2kXTHA5qGwfTMznJutKnr1RHH7prDrQbr4BYlw-pt2V9gVgqTSERQ@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> When --no-prune is used, not only will packed loose objects not be pruned,
> but the cleanup of temporary files that git-prune performs will not be done.
I forgot that the temporary file cleanup also honors --expire, so there will
still be no cleanup of temporary files if prune_expire = "never". I think the
rest of my remarks are still valid.
-brandon
^ permalink raw reply
* Re: [PATCH] gc: make --prune useful again by accepting an optional parameter
From: Brandon Casey @ 2008-12-15 21:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0812152121260.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> With this patch, "git gc --no-prune" will not prune any loose (and
> dangling) object, and "git gc --prune=5.minutes.ago" will prune
> all loose objects older than 5 minutes.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
<snip>
> diff --git a/builtin-gc.c b/builtin-gc.c
> index bbc41ac..078c5b3 100644
> --- a/builtin-gc.c
> +++ b/builtin-gc.c
> @@ -199,14 +199,15 @@ static int need_to_gc(void)
>
> int cmd_gc(int argc, const char **argv, const char *prefix)
> {
> - int prune = 0;
> int aggressive = 0;
> int auto_gc = 0;
> int quiet = 0;
> char buf[80];
>
> struct option builtin_gc_options[] = {
> - OPT_BOOLEAN(0, "prune", &prune, "prune unreferenced objects (deprecated)"),
> + { OPTION_STRING, 0, "prune", &prune_expire, "date",
> + "prune unreferenced objects (deprecated)",
The help string still contains "deprecated".
> + PARSE_OPT_OPTARG, NULL, (intptr_t)prune_expire },
> OPT_BOOLEAN(0, "aggressive", &aggressive, "be more thorough (increased runtime)"),
> OPT_BOOLEAN(0, "auto", &auto_gc, "enable auto-gc mode"),
> OPT_BOOLEAN('q', "quiet", &quiet, "suppress progress reports"),
> @@ -255,9 +256,11 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
> if (run_command_v_opt(argv_repack, RUN_GIT_CMD))
> return error(FAILED_RUN, argv_repack[0]);
>
> - argv_prune[2] = prune_expire;
> - if (run_command_v_opt(argv_prune, RUN_GIT_CMD))
> - return error(FAILED_RUN, argv_prune[0]);
> + if (prune_expire) {
> + argv_prune[2] = prune_expire;
> + if (run_command_v_opt(argv_prune, RUN_GIT_CMD))
> + return error(FAILED_RUN, argv_prune[0]);
> + }
When --no-prune is used, not only will packed loose objects not be pruned,
but the cleanup of temporary files that git-prune performs will not be done.
Maybe this should be relaxed from "will not prune _any_ loose object" to "will
not prune any unreferenced object".
If something like:
if (!prune_expire)
prune_expire = "never";
is added after option parsing, then I think this will satisfy people's requests
and it will also apply nicely on top of Nico's patch to avoid unpacking objects
when prune_expire == "now".
-brandon
^ permalink raw reply
* [PATCH] fast-import: close pack before unlinking it
From: Johannes Schindelin @ 2008-12-15 21:11 UTC (permalink / raw)
To: spearce, Johannes Sixt, gitster, git
This is sort of a companion patch to 4723ee9(Close files opened by
lock_file() before unlinking.): on Windows, you cannot delete what
is still open.
This makes test 9300-fast-import pass on Windows for me; quite a few
fast-imports leave temporary packs until the test "blank lines not
necessary after other commands" actually tests for the number of files
in .git/objects/pack/, which has a few temporary packs now.
I guess that 8b4eb6b(Do not perform cross-directory renames when
creating packs) was "responsible" for the breakage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
fast-import.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 3276d5d..201d4ff 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -983,8 +983,10 @@ static void end_packfile(void)
pack_id++;
}
- else
+ else {
+ close(old_p->pack_fd);
unlink(old_p->pack_name);
+ }
free(old_p);
/* We can't carry a delta across packfiles. */
--
1.6.1.rc3.368.g63acc
^ permalink raw reply related
* Re: git log --numstat disagrees with git apply --numstat
From: Jeff King @ 2008-12-15 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vhc55yd58.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 15, 2008 at 01:57:07AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > BTW, I got a little confused looking at the parameters to xdi_diff_outf,
> > since ecb gets passed in full of random garbage. I don't know if this
> > cleanup is worth applying:
>
> I think this makes sense, but let's do this after 1.6.1 final. It does
> not fix anything, and I'd rather avoid distraction.
Agreed. I will re-post both patches after 1.6.1 is released.
-Peff
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Daniel Barkalow @ 2008-12-15 20:31 UTC (permalink / raw)
To: Łukasz Lew; +Cc: Alexander Potashev, Nick Andrew, git
In-Reply-To: <c55009e70812140848j79202b0aqc6ffbfecfff50757@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3783 bytes --]
On Sun, 14 Dec 2008, Łukasz Lew wrote:
> Hi Alexander,
>
> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:
> > Hello, Łukasz!
> >
> > On 16:38 Sun 14 Dec , Łukasz Lew wrote:
> >> Thanks Nick, thats really helpful (and surprisingly simple).
> >> I have a couple more questions:
> >>
> >> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
> >> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
> >> >> I don't know how to make such a scenario work:
> >> >> - two repositories: pub, priv
> >> >> - priv is clone/branch of pub
> >> >> - there is some constant developement both in pub and priv
> >> >> - there are regular syncs with pub in priv
> >> >>
> >> >> Problem:
> >> >> Occasionally I want to push some changes from priv to pub.
> >> >> Then after syncing with pub I want to get as few conflicts as possible.
> >> >>
> >> >> Is it possible to do with git?
> >> >
> >> > Git can do almost anything. One should instead ask "How to do this
> >> > with git?" :-)
> >>
> >> So I've heard, but not yet experienced it myself. I'm thrilled to try.
> >>
> >> >
> >> > If I understand your problem, you could solve it with git cherry-pick
> >> > and rebase. On priv, make a for-public branch from a pub branch. Then
> >> > cherry-pick the commits you want from your private branch into the
> >> > for-public branch.
> >>
> >> That almost works. Can I somehow split existing commits just like in git-add -p?
> > It's, however, better to make more commits to not experience the need of
> > commit splitting.
>
> Indeed good advice and best practice, but another best practice is to
> not commit not compiling state.
In your private branches, it's actually good practice to commit all sorts
of junk. That way, when you mess up badly while trying to get it to
compile, you won't have lost your work. Of course, that means your commits
are going to need more cleanup before going public.
> My common scenario is that I code a big change in priv repository, and
> after that I find that some of its parts can and should be moved to
> pub.
I usually end up with my private branch containing the public branch, plus
a bunch of commits that introduce: bugs, later fixed; mixed improvements;
and debugging cruft. I want to generate nice commits that are individual
improvements. I generally do:
$ git checkout -b submit origin/master (the first time, to set it up)
$ git checkout submit
$ git diff submit mixed-work
look at it for good changes, find some in file1 and file2
$ git diff submit mixed-work -- file1 file2 | git apply
Sometimes, clean up bits that aren't ideal
$ git add -i
Add the good parts
$ git checkout . (revert the working tree to the index)
$ make test (did I extract the change correctly?)
$ git commit
Write a good message, sign off, etc
$ git checkout mixed-work
$ git rebase -i submit
Often, resolve easy conflicts where my mixed-work branch introduced bugs
that I fixed later and have now adopted the fixed code
Then I repeat until I don't have any more good changes in mixed-work
(either I have nothing, only debugging cruft, or only stuff I haven't
gotten to work yet). If there's nothing but cruft, I've fully merged the
topic, and I delete the branch.
Eventually, I'm satisfied with what I've cleaned up, and I do:
$ git push origin submit:master
Also, I generally have a bunch of "mixed-work" branches, each containing
different stuff that isn't ready. I'll periodicly go through all of them
and rebase onto "submit" or "origin/master" (or, sometimes, give up on
them and delete them).
(One thing that would be nice to have is a "git apply --interactive" which
applies the user's choice of hunks, like "git add -i" adds them)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] gc: make --prune useful again by accepting an optional parameter
From: Johannes Schindelin @ 2008-12-15 20:22 UTC (permalink / raw)
To: git, gitster
With this patch, "git gc --no-prune" will not prune any loose (and
dangling) object, and "git gc --prune=5.minutes.ago" will prune
all loose objects older than 5 minutes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Not meant for 1.6.1, obviously.
Documentation/git-gc.txt | 9 ++++++++-
builtin-gc.c | 13 ++++++++-----
t/t5304-prune.sh | 20 ++++++++++++++++++++
3 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 7086eea..fcef5fb 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
-'git gc' [--aggressive] [--auto] [--quiet]
+'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date>]
DESCRIPTION
-----------
@@ -59,6 +59,13 @@ are consolidated into a single pack by using the `-A` option of
'git-repack'. Setting `gc.autopacklimit` to 0 disables
automatic consolidation of packs.
+--prune=<date>::
+ Prune loose objects older than date (default is 2 weeks ago).
+ This option is on by default.
+
+--no-prune::
+ Do not prune any loose objects.
+
--quiet::
Suppress all progress reports.
diff --git a/builtin-gc.c b/builtin-gc.c
index bbc41ac..078c5b3 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -199,14 +199,15 @@ static int need_to_gc(void)
int cmd_gc(int argc, const char **argv, const char *prefix)
{
- int prune = 0;
int aggressive = 0;
int auto_gc = 0;
int quiet = 0;
char buf[80];
struct option builtin_gc_options[] = {
- OPT_BOOLEAN(0, "prune", &prune, "prune unreferenced objects (deprecated)"),
+ { OPTION_STRING, 0, "prune", &prune_expire, "date",
+ "prune unreferenced objects (deprecated)",
+ PARSE_OPT_OPTARG, NULL, (intptr_t)prune_expire },
OPT_BOOLEAN(0, "aggressive", &aggressive, "be more thorough (increased runtime)"),
OPT_BOOLEAN(0, "auto", &auto_gc, "enable auto-gc mode"),
OPT_BOOLEAN('q', "quiet", &quiet, "suppress progress reports"),
@@ -255,9 +256,11 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (run_command_v_opt(argv_repack, RUN_GIT_CMD))
return error(FAILED_RUN, argv_repack[0]);
- argv_prune[2] = prune_expire;
- if (run_command_v_opt(argv_prune, RUN_GIT_CMD))
- return error(FAILED_RUN, argv_prune[0]);
+ if (prune_expire) {
+ argv_prune[2] = prune_expire;
+ if (run_command_v_opt(argv_prune, RUN_GIT_CMD))
+ return error(FAILED_RUN, argv_prune[0]);
+ }
if (run_command_v_opt(argv_rerere, RUN_GIT_CMD))
return error(FAILED_RUN, argv_rerere[0]);
diff --git a/t/t5304-prune.sh b/t/t5304-prune.sh
index 771c0a0..2e9c4a9 100755
--- a/t/t5304-prune.sh
+++ b/t/t5304-prune.sh
@@ -112,4 +112,24 @@ test_expect_success 'prune: do not prune heads listed as an argument' '
'
+test_expect_success 'gc --no-prune && gc --prune=<date>' '
+
+ before=$(git count-objects | sed "s/ .*//") &&
+ BLOB=$(echo aleph_0 | git hash-object -w --stdin) &&
+ BLOB_FILE=.git/objects/$(echo $BLOB | sed "s/^../&\//") &&
+ test $((1 + $before)) = $(git count-objects | sed "s/ .*//") &&
+ test -f $BLOB_FILE &&
+ test-chmtime =-$((86400*5001)) $BLOB_FILE &&
+ git gc --no-prune &&
+ test 1 = $(git count-objects | sed "s/ .*//") &&
+ test -f $BLOB_FILE &&
+ git gc --prune=5002.days.ago &&
+ test 1 = $(git count-objects | sed "s/ .*//") &&
+ test -f $BLOB_FILE &&
+ git gc --prune=5000.days.ago &&
+ test 0 = $(git count-objects | sed "s/ .*//") &&
+ test ! -f $BLOB_FILE
+
+'
+
test_done
--
1.6.0.4.1189.g8876f
^ permalink raw reply related
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Daniel Barkalow @ 2008-12-15 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i632mg9.fsf@gitster.siamese.dyndns.org>
On Sun, 14 Dec 2008, Junio C Hamano wrote:
> [On Hold]
>
> * nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
> - wt-status: show sparse checkout info
> - Introduce default sparse patterns (core.defaultsparse)
> - checkout: add new options to support sparse checkout
> - clone: support sparse checkout with --sparse-checkout option
> - unpack_trees(): add support for sparse checkout
> - unpack_trees(): keep track of unmerged entries
> - Introduce "sparse patterns"
> - Merge branch 'master' into nd/narrow
> + t2104: touch portability fix
> + grep: skip files outside sparse checkout area
> + checkout_entry(): CE_NO_CHECKOUT on checked out entries.
> + Prevent diff machinery from examining worktree outside sparse
> checkout
I think this patch (slightly reframed) would be good to have independantly
of the series; it also means that we won't do weird things if someone
changes a file in the worktree which is marked as CE_VALID, and may well
may CE_VALID sufficient for the index representation of paths outside the
checkout.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [usability bug] git branch -a does not disambiguate remote and local branches
From: Boyd Stephen Smith Jr. @ 2008-12-15 19:21 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Constantine Plotnikov
In-Reply-To: <alpine.DEB.1.00.0812152005490.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Monday 2008 December 15 13:09:16 Johannes Schindelin wrote:
>IMHO it is better to be nice to the many users who do not try to shoot
>themselves in the foot, by showing them the nice short names that will
>work.
It should be possible to support both. Short names when they are unique,
longer names when the short names are ambiguous.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Theodore Tso @ 2008-12-15 19:38 UTC (permalink / raw)
To: Jakub Narebski
Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <m3vdtlcqp6.fsf@localhost.localdomain>
On Mon, Dec 15, 2008 at 09:07:39AM -0800, Jakub Narebski wrote:
>
> There was an idea to have "git gc --prune" run "git prune"
> unconditionally, i.e. without grace period for dangling loose objects.
>
That doesn't help that much, since (temporarily) you still need all of
the disk space for the exploded, unpacked objects. As Brandon Casey
pointed out, the key is "git repack -a -d -l" vs "git repack -A -d
-l". If there is going to be a git-gc option, it would need to change
the options sent to git-repack. Or, I suppose the answer is to tell
people who run into this problem use a plumbing command, manually.
The question is how common is the use case of needing to gc a
repository like linux-next, I suppose.
- Ted
^ permalink raw reply
* [PATCH] Force t5302 to use a single thread
From: Johannes Schindelin @ 2008-12-15 19:44 UTC (permalink / raw)
To: Nicolas Pitre, git
If the packs are made using multiple threads, they are no longer identical
on the 4-core Xeon I tested on.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
... or did I do something wrong?
t/t5302-pack-index.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 884e242..e6f70d4 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
@@ -10,6 +10,7 @@ test_expect_success \
'setup' \
'rm -rf .git
git init &&
+ git config pack.threads 1 &&
i=1 &&
while test $i -le 100
do
--
1.6.0.4.1189.g8876f
^ permalink raw reply related
* Re: New script to convert p4 repositories to git - git-p4c version 1.
From: Pete Wyckoff @ 2008-12-15 19:30 UTC (permalink / raw)
To: John Chapman; +Cc: Git Mailing List
In-Reply-To: <1228818317.5504.23.camel@localhost>
thestar@fussycoder.id.au wrote on Tue, 09 Dec 2008 21:25 +1100:
> I couldn't use git-p4 on my system because I kept running out of memory,
> and I didn't like the workflow it imposed.
> Also, it had various other issues with the repo I was trying to use,
> mainly because it is not an ideal repository, however those are
> (generally) the fault of the particular repo I was using, and not
> git-p4. (Which is an excellent script by itself).
>
> This script is severely crippled in that it doesn't (yet) allow one to
> contribute changesets back to perforce, however it manages to read from
> perforce with:
> * No need to rebase.
> * Mangling of file names. (Especially with regards to case sensitivity).
> * Tagging of revisions with the perforce changesets.
> * Ability to handle branches with spaces in the name.
> * Ability to pretend that perforce doesn't exist. (That's the plan,
> anyway).
> * Be extremely memory efficient. It does NOT require as much memory as
> does git-p4, even when the size of the change is large.
> * Be easy to manually modify the repository, particularly if bad things
> happen.
I like how your script imports one change at a time, as the initial
import using git-p4 here does indeed get close to exhasting virtual
memory, but I'm running into a different limitation with p4c.
The command:
p4 -G changes -l -t
is adminstratively limited to a paltry six-digit number, and
produces only an error message.
The other feature I need is the ability to use a client
specification. We merge together 40-odd different chunks of //depot
into a single checked-out client, and use some other number of
"-//depot/..." rules to exclude some parts of the full depot.
If I hack p4c to limit the changes with "-m 10" or so, then things
are a bit better in that I get two objects (changesets) but no
diffs. Had to hack the on_branch() code somewhat, in that no form
of --branches seemed to produce an "interesting" changeset by your
definition. Could be my lack of understanding here.
If you think you want to handle client specifications, and can think
of a way around the "p4 changes" limitation, I'll be happy to poke
at your next version. Perhaps I'm not in your target audience,
though. I don't necessarily need to have a full git history of the
entire p4, but this seems to be a fundamental part of your approach.
-- Pete
^ permalink raw reply
* Re: [usability bug] git branch -a does not disambiguate remote and local branches
From: Lars Hjemli @ 2008-12-15 19:24 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812151015t4d5bc2b8p4ea53a0e4ad25e64@mail.gmail.com>
On Mon, Dec 15, 2008 at 19:15, Constantine Plotnikov
<constantine.plotnikov@gmail.com> wrote:
> After this scenario is executed, git branch -a will give the following output:
> master
> * origin/master
> origin/master
>
> Note that there is two origin/master entries, but it is not clear
> which is remote is and which is the local.
You can use `git branch -a --color` to see the difference (issue `git
config --global color.branch true` to use --color automatically).
--
larsh
^ permalink raw reply
* Re: [usability bug] git branch -a does not disambiguate remote and local branches
From: Constantine Plotnikov @ 2008-12-15 19:15 UTC (permalink / raw)
To: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.00.0812152005490.30769@pacific.mpi-cbg.de>
On Mon, Dec 15, 2008 at 10:09 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
>
>> Let's consider the following scenario:
>>
>> mkdir bare.git
>> mkdir local
>> cd bare.git
>> git --bare init
>> cd ../local
>> git init
>> echo test > test.txt
>> git add test.txt
>> git commit -m test
>> git remote add origin `pwd`/../bare.git
>> git push --all
>> git checkout -b origin/master master
>> echo updated > test.txt
>> git add test.txt
>> git commit -m updated
>>
>> Note that that in this scenario, the user has created local branch in
>> the folder with the same name as a remote branch. While the supposed
>> user here is apparently shooting itself in the foot, the scenario is
>> still supported by git, and might happen as a result of more logical
>> git operations (like git fetch).
>
> It is only half-supported, and Git will complain, saying that there are
> ambiguous branches.
>
> IMHO it is better to be nice to the many users who do not try to shoot
> themselves in the foot, by showing them the nice short names that will
> work.
>
> The others are warned when they use the ambiguous short names anyway.
>
It is possible to be nice to to both categories showing shortest
disambiguated output like:
master
* heads/origin/master
remotes/origin/master
Constantine
^ permalink raw reply
* Re: [usability bug] git branch -a does not disambiguate remote and local branches
From: Johannes Schindelin @ 2008-12-15 19:09 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812151015t4d5bc2b8p4ea53a0e4ad25e64@mail.gmail.com>
Hi,
On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
> Let's consider the following scenario:
>
> mkdir bare.git
> mkdir local
> cd bare.git
> git --bare init
> cd ../local
> git init
> echo test > test.txt
> git add test.txt
> git commit -m test
> git remote add origin `pwd`/../bare.git
> git push --all
> git checkout -b origin/master master
> echo updated > test.txt
> git add test.txt
> git commit -m updated
>
> Note that that in this scenario, the user has created local branch in
> the folder with the same name as a remote branch. While the supposed
> user here is apparently shooting itself in the foot, the scenario is
> still supported by git, and might happen as a result of more logical
> git operations (like git fetch).
It is only half-supported, and Git will complain, saying that there are
ambiguous branches.
IMHO it is better to be nice to the many users who do not try to shoot
themselves in the foot, by showing them the nice short names that will
work.
The others are warned when they use the ambiguous short names anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] pack-objects: don't use too many threads with few objects
From: Mike Ralphson @ 2008-12-15 18:38 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0812131456040.30035@xanadu.home>
2008/12/13 Nicolas Pitre <nico@cam.org>
>
> If there are few objects to deltify, they might be split amongst threads
> so that there is simply no other objects left to delta against within
> the same thread. Let's use the same 2*window treshold as used for the
> final load balancing to allow extra threads to be created.
>
> This fixes the benign t5300 test failure.
Even with this I'm seeing failures in t5302 which I think are probably
related to 43cc2b42
I was trying to bisect it (test runs take forever on this platform -
AIX 5.3) but I hit the t5300 failure, which I hadn't seen on the last
automatic build.
Please shout if I've snipped the vital lines (...)
Initialized empty Git repository in /usr/local/src/gitbuild/t/trash
directory.t5302-pack-index/.git/
* expecting success: rm -rf .git
git init &&
i=1 &&
while test $i -le 100
do
iii=`printf %03i $i`
test-genrandom "bar" 200 > wide_delta_$iii &&
test-genrandom "baz $iii" 50 >> wide_delta_$iii &&
test-genrandom "foo"$i 100 > deep_delta_$iii &&
test-genrandom "foo"`expr $i + 1` 100 >> deep_delta_$iii &&
test-genrandom "foo"`expr $i + 2` 100 >> deep_delta_$iii &&
echo $iii >file_$iii &&
test-genrandom "$iii" 8192 >>file_$iii &&
git update-index --add file_$iii deep_delta_$iii wide_delta_$iii &&
i=`expr $i + 1` || return 1
done &&
{ echo 101 && test-genrandom 100 8192; } >file_101 &&
git update-index --add file_101 &&
tree=`git write-tree` &&
commit=`git commit-tree $tree </dev/null` && {
echo $tree &&
git ls-tree $tree | sed -e "s/.* \\([0-9a-f]*\\) .*/\\1/"
} >obj-list &&
git update-ref HEAD $commit
Initialized empty Git repository in /usr/local/src/gitbuild/t/trash
directory.t5302-pack-index/.git/
* ok 1: setup
* expecting success: pack1=$(git pack-objects --index-version=1 test-1
<obj-list) &&
git verify-pack -v "test-1-${pack1}.pack"
0106e17481932f5c223fafadc1d26abc6adf40d6 blob 57 90 850703 1
69e0b8ef8cda369575b6801c6ed47daf09aa3c62
...
fff3a3a92d2268a464dbdcd00fc055885ee3cba9 blob 8196 8210 187576
chain length = 1: 110 objects
chain length = 2: 11 objects
chain length = 3: 11 objects
chain length = 4: 10 objects
chain length = 5: 9 objects
chain length = 6: 9 objects
chain length = 7: 9 objects
chain length = 8: 9 objects
chain length = 9: 9 objects
test-1-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: ok
* ok 2: pack-objects with index version 1
* expecting success: pack2=$(git pack-objects --index-version=2 test-2
<obj-list) &&
git verify-pack -v "test-2-${pack2}.pack"
0106e17481932f5c223fafadc1d26abc6adf40d6 blob 57 90 850531 1
69e0b8ef8cda369575b6801c6ed47daf09aa3c62
...
fff3a3a92d2268a464dbdcd00fc055885ee3cba9 blob 8196 8210 187404
chain length = 1: 109 objects
chain length = 2: 10 objects
chain length = 3: 10 objects
chain length = 4: 10 objects
chain length = 5: 10 objects
chain length = 6: 10 objects
chain length = 7: 10 objects
chain length = 8: 10 objects
chain length = 9: 9 objects
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: ok
* ok 3: pack-objects with index version 2
* expecting success: cmp "test-1-${pack1}.pack" "test-2-${pack2}.pack"
test-1-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack differ: char
10236, line 32
* FAIL 4: both packs should be identical
cmp "test-1-${pack1}.pack" "test-2-${pack2}.pack"
* expecting success: ! cmp "test-1-${pack1}.idx" "test-2-${pack2}.idx"
test-1-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx differ: char 1,
line 1
* ok 5: index v1 and index v2 should be different
* expecting success: git index-pack --index-version=1 -o 1.idx
"test-1-${pack1}.pack"
9108b6dfd43bf36ccbfc2839fe62d1503bf84292
* ok 6: index-pack with index version 1
* expecting success: git index-pack --index-version=2 -o 2.idx
"test-1-${pack1}.pack"
9108b6dfd43bf36ccbfc2839fe62d1503bf84292
* ok 7: index-pack with index version 2
* expecting success: cmp "test-1-${pack1}.idx" "1.idx" &&
cmp "test-2-${pack2}.idx" "2.idx"
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx 2.idx differ: char
7273, line 23
* FAIL 8: index-pack results should match pack-objects ones
cmp "test-1-${pack1}.idx" "1.idx" &&
cmp "test-2-${pack2}.idx" "2.idx"
* expecting success: pack3=$(git pack-objects
--index-version=2,0x40000 test-3 <obj-list)
* ok 9: index v2: force some 64-bit offsets with pack-objects
* expecting success: git verify-pack -v "test-3-${pack3}.pack"
0106e17481932f5c223fafadc1d26abc6adf40d6 blob 57 90 850531 1
69e0b8ef8cda369575b6801c6ed47daf09aa3c62
...
fff3a3a92d2268a464dbdcd00fc055885ee3cba9 blob 8196 8210 187404
chain length = 1: 109 objects
chain length = 2: 10 objects
chain length = 3: 10 objects
chain length = 4: 10 objects
chain length = 5: 10 objects
chain length = 6: 10 objects
chain length = 7: 10 objects
chain length = 8: 10 objects
chain length = 9: 9 objects
test-3-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: ok
* ok 10: index v2: verify a pack with some 64-bit offsets
* expecting success: ! cmp "test-2-${pack2}.idx" "test-3-${pack3}.idx"
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx
test-3-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx differ: char 8281,
line 24
* ok 11: 64-bit offsets: should be different from previous index v2 results
* expecting success: git index-pack --index-version=2,0x40000 -o 3.idx
"test-1-${pack1}.pack"
9108b6dfd43bf36ccbfc2839fe62d1503bf84292
* ok 12: index v2: force some 64-bit offsets with index-pack
* expecting success: cmp "test-3-${pack3}.idx" "3.idx"
test-3-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx 3.idx differ: char
7273, line 23
* FAIL 13: 64-bit offsets: index-pack result should match pack-objects one
cmp "test-3-${pack3}.idx" "3.idx"
* expecting success: git index-pack --index-version=1 --stdin <
"test-1-${pack1}.pack" &&
git prune-packed &&
git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
cmp "test-1-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"
pack 9108b6dfd43bf36ccbfc2839fe62d1503bf84292
Removing duplicate objects: 25% (65/256)
Removing duplicate objects: 26% (68/256)
Removing duplicate objects: 27% (71/256)
Removing duplicate objects: 28% (74/256)
Removing duplicate objects: 30% (79/256)
Removing duplicate objects: 31% (81/256)
Removing duplicate objects: 32% (83/256)
Removing duplicate objects: 33% (85/256)
Removing duplicate objects: 34% (88/256)
Removing duplicate objects: 35% (90/256)
Removing duplicate objects: 36% (93/256)
Removing duplicate objects: 37% (95/256)
Removing duplicate objects: 38% (98/256)
Removing duplicate objects: 39% (100/256)
Removing duplicate objects: 40% (103/256)
Removing duplicate objects: 41% (106/256)
Removing duplicate objects: 42% (108/256)
Removing duplicate objects: 43% (112/256)
Removing duplicate objects: 44% (114/256)
Removing duplicate objects: 45% (116/256)
Removing duplicate objects: 46% (118/256)
Removing duplicate objects: 47% (121/256)
Removing duplicate objects: 48% (124/256)
Removing duplicate objects: 50% (130/256)
Removing duplicate objects: 51% (132/256)
Removing duplicate objects: 52% (134/256)
Removing duplicate objects: 53% (136/256)
Removing duplicate objects: 54% (140/256)
Removing duplicate objects: 55% (141/256)
Removing duplicate objects: 56% (144/256)
Removing duplicate objects: 57% (146/256)
Removing duplicate objects: 57% (147/256)
Removing duplicate objects: 58% (149/256)
Removing duplicate objects: 60% (154/256)
Removing duplicate objects: 61% (157/256)
Removing duplicate objects: 62% (159/256)
Removing duplicate objects: 63% (163/256)
Removing duplicate objects: 64% (164/256)
Removing duplicate objects: 65% (167/256)
Removing duplicate objects: 66% (169/256)
Removing duplicate objects: 67% (172/256)
Removing duplicate objects: 68% (175/256)
Removing duplicate objects: 69% (177/256)
Removing duplicate objects: 70% (180/256)
Removing duplicate objects: 71% (182/256)
Removing duplicate objects: 72% (185/256)
Removing duplicate objects: 73% (187/256)
Removing duplicate objects: 74% (190/256)
Removing duplicate objects: 75% (192/256)
Removing duplicate objects: 76% (195/256)
Removing duplicate objects: 77% (198/256)
Removing duplicate objects: 78% (201/256)
Removing duplicate objects: 79% (204/256)
Removing duplicate objects: 80% (206/256)
Removing duplicate objects: 81% (208/256)
Removing duplicate objects: 82% (210/256)
Removing duplicate objects: 83% (215/256)
Removing duplicate objects: 84% (217/256)
Removing duplicate objects: 85% (218/256)
Removing duplicate objects: 86% (222/256)
Removing duplicate objects: 87% (223/256)
Removing duplicate objects: 88% (226/256)
Removing duplicate objects: 89% (228/256)
Removing duplicate objects: 90% (231/256)
Removing duplicate objects: 91% (233/256)
Removing duplicate objects: 92% (236/256)
Removing duplicate objects: 93% (240/256)
Removing duplicate objects: 94% (241/256)
Removing duplicate objects: 95% (245/256)
Removing duplicate objects: 96% (246/256)
Removing duplicate objects: 97% (249/256)
Removing duplicate objects: 98% (251/256)
Removing duplicate objects: 99% (254/256)
Removing duplicate objects: 100% (256/256)
Removing duplicate objects: 100% (256/256), done.
* ok 14: [index v1] 1) stream pack to repository
* expecting success: # This test assumes file_101 is a delta smaller
than 16 bytes.
# It should be against file_100 but we substitute its base for file_099
sha1_101=`git hash-object file_101` &&
sha1_099=`git hash-object file_099` &&
offs_101=`index_obj_offset 1.idx $sha1_101` &&
nr_099=`index_obj_nr 1.idx $sha1_099` &&
chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($offs_101 + 1)) \
if=".git/objects/pack/pack-${pack1}.idx" \
skip=$((4 + 256 * 4 + $nr_099 * 24)) \
bs=1 count=20 conv=notrunc &&
git cat-file blob $sha1_101 > file_101_foo1
20+0 records in
20+0 records out
* ok 15: [index v1] 2) create a stealth corruption in a delta base reference
* expecting success: test -f file_101_foo1 && ! cmp file_101 file_101_foo1
file_101 file_101_foo1 differ: char 5, line 2
* ok 16: [index v1] 3) corrupted delta happily returned wrong data
* expecting success: test_must_fail git fsck --full $commit
error: .git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
SHA1 checksum mismatch
error: packed 0b968294884af115eb5a1b941b3dabd48470c3bb from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
is corrupt
error: sha1 mismatch 0b968294884af115eb5a1b941b3dabd48470c3bb
error: 0b968294884af115eb5a1b941b3dabd48470c3bb: object corrupt or missing
* ok 17: [index v1] 4) confirm that the pack is actually corrupted
* expecting success: pack4=$(git pack-objects test-4 <obj-list) &&
test -f "test-4-${pack1}.pack"
* ok 18: [index v1] 5) pack-objects happily reuses corrupted data
* expecting success: test_must_fail git verify-pack -v "test-4-${pack1}.pack"
error: packed 0b968294884af115eb5a1b941b3dabd48470c3bb from
test-4-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack is corrupt
test-4-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: bad
* ok 19: [index v1] 6) newly created pack is BAD !
* expecting success: rm -f .git/objects/pack/* &&
git index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git prune-packed &&
git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
cmp "test-2-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"
pack 9108b6dfd43bf36ccbfc2839fe62d1503bf84292
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx
differ: char 7273, line 23
* FAIL 20: [index v2] 1) stream pack to repository
rm -f .git/objects/pack/* &&
git index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git prune-packed &&
git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
cmp "test-2-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"
* expecting success: # This test assumes file_101 is a delta smaller
than 16 bytes.
# It should be against file_100 but we substitute its base for file_099
sha1_101=`git hash-object file_101` &&
sha1_099=`git hash-object file_099` &&
offs_101=`index_obj_offset 1.idx $sha1_101` &&
nr_099=`index_obj_nr 1.idx $sha1_099` &&
chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($offs_101 + 1)) \
if=".git/objects/pack/pack-${pack1}.idx" \
skip=$((8 + 256 * 4 + $nr_099 * 20)) \
bs=1 count=20 conv=notrunc &&
git cat-file blob $sha1_101 > file_101_foo2
20+0 records in
20+0 records out
* ok 21: [index v2] 2) create a stealth corruption in a delta base reference
* expecting success: test -f file_101_foo2 && ! cmp file_101 file_101_foo2
file_101 file_101_foo2 differ: char 5, line 2
* ok 22: [index v2] 3) corrupted delta happily returned wrong data
* expecting success: test_must_fail git fsck --full $commit
error: .git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
SHA1 checksum mismatch
error: index CRC mismatch for object
0b968294884af115eb5a1b941b3dabd48470c3bb from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
at offset 844376
error: packed 0b968294884af115eb5a1b941b3dabd48470c3bb from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
is corrupt
error: sha1 mismatch 0b968294884af115eb5a1b941b3dabd48470c3bb
error: 0b968294884af115eb5a1b941b3dabd48470c3bb: object corrupt or missing
* ok 23: [index v2] 4) confirm that the pack is actually corrupted
* expecting success: test_must_fail git pack-objects test-5 <obj-list &&
test_must_fail git pack-objects --no-reuse-object test-6 <obj-list
error: bad packed object CRC for 0b968294884af115eb5a1b941b3dabd48470c3bb
error: bad packed object CRC for 0b968294884af115eb5a1b941b3dabd48470c3bb
error: failed to read object 0b968294884af115eb5a1b941b3dabd48470c3bb
at offset 844376 from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
fatal: object 0b968294884af115eb5a1b941b3dabd48470c3bb is corrupted
error: bad packed object CRC for 0b968294884af115eb5a1b941b3dabd48470c3bb
error: failed to read object 0b968294884af115eb5a1b941b3dabd48470c3bb
at offset 844376 from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
fatal: object 0b968294884af115eb5a1b941b3dabd48470c3bb is corrupted
* ok 24: [index v2] 5) pack-objects refuses to reuse corrupted data
* expecting success: rm -f .git/objects/pack/* &&
git index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git verify-pack ".git/objects/pack/pack-${pack1}.pack" &&
obj=`git hash-object file_001` &&
nr=`index_obj_nr ".git/objects/pack/pack-${pack1}.idx" $obj` &&
chmod +w ".git/objects/pack/pack-${pack1}.idx" &&
dd if=/dev/zero of=".git/objects/pack/pack-${pack1}.idx" conv=notrunc \
bs=1 count=4 seek=$((8 + 256 * 4 + `wc -l <obj-list` * 20 + $nr * 4)) &&
( while read obj
do git cat-file -p $obj >/dev/null || exit 1
done <obj-list ) &&
err=$(test_must_fail git verify-pack \
".git/objects/pack/pack-${pack1}.pack" 2>&1) &&
echo "$err" | grep "CRC mismatch"
pack 9108b6dfd43bf36ccbfc2839fe62d1503bf84292
4+0 records in
4+0 records out
error: index CRC mismatch for object
1297547aab30f952af805d38f6f1c1930cb3117b from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
at offset 23376
* ok 25: [index v2] 6) verify-pack detects CRC mismatch
* expecting success:
rm -f .git/objects/pack/* &&
cp test-1-${pack1}.pack .git/objects/pack/pack-${pack1}.pack &&
(
cd .git/objects/pack
git index-pack pack-${pack1}.pack
) &&
test -f .git/objects/pack/pack-${pack1}.idx
9108b6dfd43bf36ccbfc2839fe62d1503bf84292
* ok 26: running index-pack in the object store
* failed 4 among 26 test(s)
^ permalink raw reply
* [usability bug] git branch -a does not disambiguate remote and local branches
From: Constantine Plotnikov @ 2008-12-15 18:15 UTC (permalink / raw)
To: git
Let's consider the following scenario:
mkdir bare.git
mkdir local
cd bare.git
git --bare init
cd ../local
git init
echo test > test.txt
git add test.txt
git commit -m test
git remote add origin `pwd`/../bare.git
git push --all
git checkout -b origin/master master
echo updated > test.txt
git add test.txt
git commit -m updated
Note that that in this scenario, the user has created local branch in
the folder with the same name as a remote branch. While the supposed
user here is apparently shooting itself in the foot, the scenario is
still supported by git, and might happen as a result of more logical
git operations (like git fetch).
After this scenario is executed, git branch -a will give the following output:
master
* origin/master
origin/master
Note that there is two origin/master entries, but it is not clear
which is remote is and which is the local. I think that "git branch
-a" should print unambiguous names, qualifying them if needed.
Constantine
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Brandon Casey @ 2008-12-15 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Markus Heidelberg, gitster, git
In-Reply-To: <20081214111939.GC6499@coredump.intra.peff.net>
Jeff King wrote:
> On Sun, Dec 14, 2008 at 12:17:07PM +0100, Johannes Schindelin wrote:
>
>>> Which annoyingly has no discussion about _why_ it no longer has an
>>> effect. But I suspect it has something to do with 25ee973 (gc: call
>>> "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
>> Oops.
>>
>> But I thought that git gc --prune does expire _all_ dangling loose
>> objects _now_, not with --expire 2.weeks.ago.
>
> Nope, see 25ee973. You explicitly wrote:
>
> Note that this new behaviour makes "--prune" be a no-op.
>
> That being said, I think that is perhaps a reasonable thing for --prune
> to do (and I don't think there is any conflict with the name, because
> that is what it _used_ to do before becoming a no-op). But nobody has
> actually implemented it.
Maybe --mrproper would be a more appropriate name.
-brandon
^ permalink raw reply
* [PATCH 2/2] bash completion: Sync config variables with its man page
From: Lee Marlow @ 2008-12-15 17:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
In-Reply-To: <1229363149-37757-1-git-send-email-lee.marlow@gmail.com>
Add 'normal' to config color options.
Add 'mergeoptions' to branch config options.
Add 'proxy' and 'mirror' to remote config options.
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 87 +++++++++++++++++++++++++++++---
1 files changed, 80 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 79cbed5..e004549 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1155,7 +1155,7 @@ _git_config ()
;;
color.*.*)
__gitcomp "
- black red green yellow blue magenta cyan white
+ normal black red green yellow blue magenta cyan white
bold dim ul blink reverse
"
return
@@ -1179,7 +1179,7 @@ _git_config ()
branch.*.*)
local pfx="${cur%.*}."
cur="${cur##*.}"
- __gitcomp "remote merge" "$pfx" "$cur"
+ __gitcomp "remote merge mergeoptions" "$pfx" "$cur"
return
;;
branch.*)
@@ -1192,7 +1192,7 @@ _git_config ()
local pfx="${cur%.*}."
cur="${cur##*.}"
__gitcomp "
- url fetch push skipDefaultUpdate
+ url proxy fetch push mirror skipDefaultUpdate
receivepack uploadpack tagopt
" "$pfx" "$cur"
return
@@ -1206,6 +1206,8 @@ _git_config ()
esac
__gitcomp "
apply.whitespace
+ branch.autosetupmerge
+ branch.autosetuprebase
clean.requireForce
color.branch
color.branch.current
@@ -1220,46 +1222,95 @@ _git_config ()
color.diff.old
color.diff.plain
color.diff.whitespace
+ color.interactive
+ color.interactive.header
+ color.interactive.help
+ color.interactive.prompt
color.pager
color.status
color.status.added
color.status.changed
color.status.header
+ color.status.nobranch
color.status.untracked
+ color.status.updated
+ color.ui
+ commit.template
+ core.autocrlf
+ core.bare
core.compression
+ core.deltaBaseCacheLimit
+ core.editor
+ core.excludesfile
core.fileMode
+ core.fsyncobjectfiles
core.gitProxy
+ core.ignoreCygwinFSTricks
core.ignoreStat
core.logAllRefUpdates
core.loosecompression
core.packedGitLimit
core.packedGitWindowSize
+ core.pager
core.preferSymlinkRefs
+ core.preloadindex
+ core.quotepath
core.repositoryFormatVersion
+ core.safecrlf
core.sharedRepository
+ core.symlinks
+ core.trustctime
core.warnAmbiguousRefs
+ core.whitespace
+ core.worktree
+ diff.autorefreshindex
+ diff.external
+ diff.mnemonicprefix
diff.renameLimit
+ diff.renameLimit.
diff.renames
fetch.unpackLimit
format.headers
- format.subjectprefix
+ format.numbered
+ format.pretty
+ format.suffix
+ gc.aggressiveWindow
+ gc.auto
+ gc.autopacklimit
gc.packrefs
+ gc.pruneexpire
gc.reflogexpire
gc.reflogexpireunreachable
gc.rerereresolved
gc.rerereunresolved
gitcvs.allbinary
+ gitcvs.dbTableNamePrefix
gitcvs.dbdriver
gitcvs.dbname
gitcvs.dbpass
- gitcvs.dbtablenameprefix
gitcvs.dbuser
gitcvs.enabled
gitcvs.logfile
+ gitcvs.usecrlfattr
+ gui.blamehistoryctx
+ gui.commitmsgwidth
+ gui.copyblamethreshold
+ gui.diffcontext
+ gui.encoding
+ gui.fastcopyblame
+ gui.matchtrackingbranch
+ gui.newbranchtemplate
+ gui.pruneduringfetch
+ gui.spellingdictionary
+ gui.trustmtime
+ help.autocorrect
+ help.browser
+ help.format
http.lowSpeedLimit
http.lowSpeedTime
http.maxRequests
http.noEPSV
+ http.proxy
http.sslCAInfo
http.sslCAPath
http.sslCert
@@ -1267,27 +1318,49 @@ _git_config ()
http.sslVerify
i18n.commitEncoding
i18n.logOutputEncoding
+ instaweb.browser
+ instaweb.httpd
+ instaweb.local
+ instaweb.modulepath
+ instaweb.port
+ log.date
log.showroot
- merge.summary
+ man.viewer
+ merge.conflictstyle
+ merge.log
+ merge.renameLimit
+ merge.stat
merge.tool
merge.verbosity
+ mergetool.keepBackup
pack.compression
pack.deltaCacheLimit
pack.deltaCacheSize
pack.depth
+ pack.indexVersion
+ pack.packSizeLimit
+ pack.threads
pack.window
pack.windowMemory
pull.octopus
pull.twohead
+ receive.denyCurrentBranch
+ receive.denyDeletes
receive.denyNonFastForwards
+ receive.fsckObjects
receive.unpackLimit
- repack.useDeltaBaseOffset
+ repack.usedeltabaseoffset
+ rerere.autoupdate
+ rerere.enabled
showbranch.default
+ status.relativePaths
+ status.showUntrackedFiles
tar.umask
transfer.unpackLimit
user.email
user.name
user.signingkey
+ web.browser
branch. remote.
"
}
--
1.6.1.rc2.20.gde0d
^ permalink raw reply related
* [PATCH 1/2] bash completion: Sort config completion variables
From: Lee Marlow @ 2008-12-15 17:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Sort the config variables to make sync-ing them with
Documents/config.txt easier in the future.
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 77 ++++++++++++++++---------------
1 files changed, 40 insertions(+), 37 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c79c98f..79cbed5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1206,84 +1206,87 @@ _git_config ()
esac
__gitcomp "
apply.whitespace
- core.fileMode
- core.gitProxy
- core.ignoreStat
- core.preferSymlinkRefs
- core.logAllRefUpdates
- core.loosecompression
- core.repositoryFormatVersion
- core.sharedRepository
- core.warnAmbiguousRefs
- core.compression
- core.packedGitWindowSize
- core.packedGitLimit
clean.requireForce
color.branch
color.branch.current
color.branch.local
- color.branch.remote
color.branch.plain
+ color.branch.remote
color.diff
- color.diff.plain
- color.diff.meta
+ color.diff.commit
color.diff.frag
- color.diff.old
+ color.diff.meta
color.diff.new
- color.diff.commit
+ color.diff.old
+ color.diff.plain
color.diff.whitespace
color.pager
color.status
- color.status.header
color.status.added
color.status.changed
+ color.status.header
color.status.untracked
+ core.compression
+ core.fileMode
+ core.gitProxy
+ core.ignoreStat
+ core.logAllRefUpdates
+ core.loosecompression
+ core.packedGitLimit
+ core.packedGitWindowSize
+ core.preferSymlinkRefs
+ core.repositoryFormatVersion
+ core.sharedRepository
+ core.warnAmbiguousRefs
diff.renameLimit
diff.renames
fetch.unpackLimit
format.headers
format.subjectprefix
- gitcvs.enabled
- gitcvs.logfile
- gitcvs.allbinary
- gitcvs.dbname gitcvs.dbdriver gitcvs.dbuser gitcvs.dbpass
- gitcvs.dbtablenameprefix
gc.packrefs
gc.reflogexpire
gc.reflogexpireunreachable
gc.rerereresolved
gc.rerereunresolved
- http.sslVerify
- http.sslCert
- http.sslKey
- http.sslCAInfo
- http.sslCAPath
- http.maxRequests
+ gitcvs.allbinary
+ gitcvs.dbdriver
+ gitcvs.dbname
+ gitcvs.dbpass
+ gitcvs.dbtablenameprefix
+ gitcvs.dbuser
+ gitcvs.enabled
+ gitcvs.logfile
http.lowSpeedLimit
http.lowSpeedTime
+ http.maxRequests
http.noEPSV
+ http.sslCAInfo
+ http.sslCAPath
+ http.sslCert
+ http.sslKey
+ http.sslVerify
i18n.commitEncoding
i18n.logOutputEncoding
log.showroot
- merge.tool
merge.summary
+ merge.tool
merge.verbosity
- pack.window
- pack.depth
- pack.windowMemory
pack.compression
- pack.deltaCacheSize
pack.deltaCacheLimit
+ pack.deltaCacheSize
+ pack.depth
+ pack.window
+ pack.windowMemory
pull.octopus
pull.twohead
+ receive.denyNonFastForwards
+ receive.unpackLimit
repack.useDeltaBaseOffset
showbranch.default
tar.umask
transfer.unpackLimit
- receive.unpackLimit
- receive.denyNonFastForwards
- user.name
user.email
+ user.name
user.signingkey
branch. remote.
"
--
1.6.1.rc2.20.gde0d
^ permalink raw reply related
* Re: [PATCH v3] <-- really v4
From: Marcel M. Cary @ 2008-12-15 17:38 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt
In-Reply-To: <1229362477-22538-1-git-send-email-marcel@oak.homeunix.org>
I guess I'm really on v4, sorry.
Marcel
^ permalink raw reply
* [PATCH] objects to be pruned immediately don't have to be loosened
From: Nicolas Pitre @ 2008-12-15 17:38 UTC (permalink / raw)
To: Theodore Tso; +Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3331 bytes --]
When there is no grace period before pruning unreferenced objects, it is
pointless to push those objects in their loose form just to delete them
right away.
Also be more explicit about the possibility of using "now" in the
gc.pruneexpire config variable (needed for the above behavior to
happen).
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Mon, 15 Dec 2008, Theodore Tso wrote:
> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
> > so that git prune can drop them. And git gc invokes git prune so that
> > only unreachable objects older than 2 weeks are dropped.
>
> To be even more explicit, "git gc" will **unpack** objects that have
> become unreachable and were currently in packs. As a result, the
> amount of disk space used by a git repository can actually go **up**
> dramatically after a "git gc" operation, which could be surprising for
> someone who is running close to full on their filesystem, deletes a
> number of branches from a tracking repository, and then does a "git
> gc" may get a very unpleasant surprise.
>
> A really good repository which shows this is linux-next, since it is
> constantly getting rewound, and old branches are reserved via a tag
> such as next-20081204. If you update the your local copy of the
> linux-next repository every day, you will accumulate a large number of
> these old branch tags. If you then delete a whole series of them, and
> run git-gc, the operation will take quite a while, and the number of
> blocks and inodes used will grow significantly. They will disappear
> after a "git prune", but when I do this housekeeping operation, I've
> often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
> just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
> option to "git gc".
What about this?
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 21ea165..ca45e71 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -702,7 +702,9 @@ gc.packrefs::
gc.pruneexpire::
When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
- Override the grace period with this config variable.
+ Override the grace period with this config variable. The value
+ "now" may be used to disable this grace period and always prune
+ unreachable objects immediately.
gc.reflogexpire::
'git-reflog expire' removes reflog entries older than
diff --git a/builtin-gc.c b/builtin-gc.c
index 781df60..f8eae4a 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -188,7 +188,9 @@ static int need_to_gc(void)
* there is no need.
*/
if (too_many_packs())
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
else if (!too_many_loose_objects())
return 0;
@@ -243,7 +245,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
"run \"git gc\" manually. See "
"\"git help gc\" for more information.\n");
} else
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
return error(FAILED_RUN, argv_pack_refs[0]);
^ permalink raw reply related
* [PATCH v3] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-12-15 17:34 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <7v4p174diu.fsf@gitster.siamese.dyndns.org>
I want directories of my working tree to be linked to from various
paths on my filesystem where third-party components expect them, both
in development and production environments. A build system's install
step could solve this, but I develop scripts and web pages that don't
need to be built. Git's submodule system could solve this, but we
tend to develop, branch, and test those directories all in unison, so
one big repository feels more natural. We prefer to edit and commit
on the symlinked paths, not the canonical ones, and in that setting,
"git pull" fails to find the top-level directory of the repository
while other commands work fine.
"git pull" fails because POSIX shells have a notion of current working
directory that is different from getcwd(). The shell stores this path
in PWD. As a result, "cd ../" can be interpreted differently in a
shell script than chdir("../") in a C program. The shell interprets
"../" by essentially stripping the last textual path component from
PWD, whereas C chdir() follows the ".." link in the current directory
on the filesystem. When PWD is a symlink, these are different
destinations. As a result, Git's C commands find the correct
top-level working tree, and shell scripts do not.
Changes:
* When interpreting a relative upward (../) path in cd_to_toplevel,
prepend the cwd without symlinks, given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus contrasting scenarios
that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
> > I also removed the "pwd -P" from the unit test.
>
> Hmm, really...?
Ouch. Removing just one occurrence won't help much, will it.
> > Do you think these test cases should run all the time here?
>
> I'd say so. Your supporting argument could be "See, push works just
> fine with this layout, but pull doesn't because it is a shell script
> that can be fooled, and this change is to fix the inconsistencies
> between them."
Ok, removed those cases from test_debug and emphasized in the first
paragraph of the commit message that other commands support this kind
of "sideways jumping."
> But whether it is inside test_debug or not, the test should check
> not just the exit status from 'git push' but also check what
> happened to the receiving repository at least to make sure it is
> pushing to the location you are expecting it to.
Ok, I did this by adding an additional file each time and checking the
same path in the other repository.
git-sh-setup.sh | 23 ++++++++++++-
t/t2300-cd-to-toplevel.sh | 37 +++++++++++++++++++++
t/t5521-pull-symlink.sh | 78 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 136 insertions(+), 2 deletions(-)
create mode 100755 t/t2300-cd-to-toplevel.sh
create mode 100755 t/t5521-pull-symlink.sh
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbdf209..f07d96b 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -85,8 +85,27 @@ cd_to_toplevel () {
cdup=$(git rev-parse --show-cdup)
if test ! -z "$cdup"
then
- cd "$cdup" || {
- echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
+ case "$cdup" in
+ /*)
+ # Not quite the same as if we did "cd -P '$cdup'" when
+ # $cdup contains ".." after symlink path components.
+ # Don't fix that case at least until Git switches to
+ # "cd -P" across the board.
+ phys="$cdup"
+ ;;
+ ..|../*|*/..|*/../*)
+ # Interpret $cdup relative to the physical, not logical, cwd.
+ # Probably /bin/pwd is more portable than passing -P to cd or pwd.
+ phys="$(/bin/pwd)/$cdup"
+ ;;
+ *)
+ # There's no "..", so no need to make things absolute.
+ phys="$cdup"
+ ;;
+ esac
+
+ cd "$phys" || {
+ echo >&2 "Cannot chdir to $phys, the toplevel of the working tree"
exit 1
}
fi
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
new file mode 100755
index 0000000..beddb4e
--- /dev/null
+++ b/t/t2300-cd-to-toplevel.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='cd_to_toplevel'
+
+. ./test-lib.sh
+
+test_cd_to_toplevel () {
+ test_expect_success "$2" '
+ (
+ cd '"'$1'"' &&
+ . git-sh-setup &&
+ cd_to_toplevel &&
+ [ "$(/bin/pwd)" = "$TOPLEVEL" ]
+ )
+ '
+}
+
+TOPLEVEL="$(/bin/pwd)/repo"
+mkdir -p repo/sub/dir
+mv .git repo/
+SUBDIRECTORY_OK=1
+
+test_cd_to_toplevel repo 'at physical root'
+
+test_cd_to_toplevel repo/sub/dir 'at physical subdir'
+
+ln -s repo symrepo
+test_cd_to_toplevel symrepo 'at symbolic root'
+
+ln -s repo/sub/dir subdir-link
+test_cd_to_toplevel subdir-link 'at symbolic subdir'
+
+cd repo
+ln -s sub/dir internal-link
+test_cd_to_toplevel internal-link 'at internal symbolic subdir'
+
+test_done
diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh
new file mode 100755
index 0000000..5672b51
--- /dev/null
+++ b/t/t5521-pull-symlink.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+
+test_description='pulling from symlinked subdir'
+
+. ./test-lib.sh
+
+# The scenario we are building:
+#
+# trash\ directory/
+# clone-repo/
+# subdir/
+# bar
+# subdir-link -> clone-repo/subdir/
+#
+# The working directory is subdir-link.
+
+mkdir subdir
+echo file >subdir/file
+git add subdir/file
+git commit -q -m file
+git clone -q . clone-repo
+ln -s clone-repo/subdir/ subdir-link
+
+
+# Demonstrate that things work if we just avoid the symlink
+#
+test_expect_success 'pulling from real subdir' '
+ (
+ echo real >subdir/file &&
+ git commit -m real subdir/file &&
+ cd clone-repo/subdir/ &&
+ git pull &&
+ test real = $(cat file)
+ )
+'
+
+# From subdir-link, pulling should work as it does from
+# clone-repo/subdir/.
+#
+# Instead, the error pull gave was:
+#
+# fatal: 'origin': unable to chdir or not a git archive
+# fatal: The remote end hung up unexpectedly
+#
+# because git would find the .git/config for the "trash directory"
+# repo, not for the clone-repo repo. The "trash directory" repo
+# had no entry for origin. Git found the wrong .git because
+# git rev-parse --show-cdup printed a path relative to
+# clone-repo/subdir/, not subdir-link/. Git rev-parse --show-cdup
+# used the correct .git, but when the git pull shell script did
+# "cd `git rev-parse --show-cdup`", it ended up in the wrong
+# directory. A POSIX shell's "cd" works a little differently
+# than chdir() in C; "cd -P" is much closer to chdir().
+#
+test_expect_success 'pulling from symlinked subdir' '
+ (
+ echo link >subdir/file &&
+ git commit -m link subdir/file &&
+ cd subdir-link/ &&
+ git pull &&
+ test link = $(cat file)
+ )
+'
+
+# Prove that the remote end really is a repo, and other commands
+# work fine in this context. It's just that "git pull" breaks.
+#
+test_expect_success 'pushing from symlinked subdir' '
+ (
+ cd subdir-link/ &&
+ echo push >file &&
+ git commit -m push ./file &&
+ git push
+ ) &&
+ test push = $(git show HEAD:subdir/file)
+'
+
+test_done
--
1.6.0.3
^ permalink raw reply related
* Re: [PATCH v2] git-branch: display sha1 on branch deletion
From: Brandon Casey @ 2008-12-15 17:23 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20081213063104.GA8480@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Dec 12, 2008 at 05:20:07PM -0600, Brandon Casey wrote:
>
>> Make it easier to recover from a mistaken branch deletion by displaying the
>> sha1 of the branch's tip commit.
>
> This version looks fine to me, but one nit:
>
>> - test "$(git branch -d my7 2>&1)" = "Deleted branch my7."'
>> + sha1=$(git rev-parse my7 | cut -c 1-7) &&
>> + test "$(git branch -d my7 2>&1)" = "Deleted branch my7 ($sha1)."'
>
> There is a very very small chance that this sha1 might require more
> than 7 characters to be unique (small because we have such a tiny number
> of objects in the trash repo).
Yeah I was counting on the smallness of that chance to let me be lazy and
not think about how to get the proper abbreviated sha1.
> Maybe:
>
> sha1=$(git log --pretty=format:%h -1 my7)
>
> is better (though I have to admit, if I were writing the test originally
> I would have tested the exit value of "git branch" instead of the
> message).
My feelings won't be hurt if you want to change it.
-brandon
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Brandon Casey @ 2008-12-15 17:11 UTC (permalink / raw)
To: Theodore Tso; +Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
Theodore Tso wrote:
> I've
> often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
> just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
> option to "git gc".
repack -a -d -l
Notice the lowercase 'a'.
git-gc calls repack with uppercase 'A' which is what causes the unreachable
objects to be unpacked. Little 'a', is for people who know what they are
doing, and want git to just drop unreachable objects.
-brandon
^ 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