* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Junio C Hamano @ 2008-12-15 22:21 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1229352709-4663-2-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> The boolean feature subroutines were identical except for the name of
> the configuration option, so make that a parameter and unify them.
I think this makes sense but unfortunately it comes after the other one
that I do not know what its point is...
^ permalink raw reply
* Re: [PATCH] gitweb: make feature_blame return a list
From: Junio C Hamano @ 2008-12-15 22:20 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1229352709-4663-1-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> The feature defaults are expected to be a list, but feature_blame was
> returning a scalar. This change makes it consistent with the other
> boolean feature subroutines.
>
> Signed-off-by: Matt Kraai <kraai@ftbfs.org>
> ---
> gitweb/gitweb.perl | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 6eb370d..145e712 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -367,12 +367,12 @@ sub feature_blame {
> my ($val) = git_get_project_config('blame', '--bool');
>
> if ($val eq 'true') {
> - return 1;
> + return (1);
> } elsif ($val eq 'false') {
> - return 0;
> + return (0);
> }
>
> - return $_[0];
> + return ($_[0]);
> }
My Perl may be getting rusty, but does the above make any difference?
How?
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-15 22:13 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, johannes.schindelin, raa.lkml
In-Reply-To: <7vskopwxej.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
>> On Sun, Dec 14, 2008 at 07:34:46PM -0800, Junio C Hamano wrote:
>>> merge-recursive: do not clobber untracked working tree garbage
>>>
>>> When merge-recursive wanted to create a new file in the work tree (either
>>> as the final result, or a hint for reference purposes while delete/modify
>>> conflicts), it unconditionally overwrote an untracked file in the working
>>> tree. Be careful not to lose whatever the user has that is not tracked.
>>
>> This leaves the index in an unmerged state, however, so that a subsequent
>> git reset --hard still kills the file. And I just realized that the same
>> goes for merge-resolve. So I'd prefer to abort the merge, leave everything
>> unchanged and tell the user to clean up first.
>
> That is unfortunately asking for a moon, I am afraid.
>
> It needs a major restructuring of the code so that the recursive works
> more like the way resolve works, namely, changing the final "writeout"
> into two phase thing (the first phase making sure nothing is clobbered in
> the work tree, and then the second phase actually touching the work tree).
Actually, the more I think about it, I do not think this is not something
we would even want to do.
By this, I do not mean the restructuring to bring some sanity to
merge-recursive. That is necessary. What I do not think is unnecessary
is the issue you raise about "git reset --hard".
You can do a merge inside a dirty work tree, and the merge will fail
without clobbering your work tree files that are dirty when it needs to be
able to overwrite to do its job. The set of "dirty files" in this
sentence of course includes paths that are modified since HEAD, but it
also includes also paths that do not exist in HEAD (i.e. "new files").
But we already caution users that you need to know what you are doing when
working in such a dirty work tree. Namely, after a failed merge, your
next "git reset --hard" will blow away your local modifications. And
local modifications in this context includes the files you could have
added to the index but you haven't.
By the way, I think the patch I sent earlier is too complex and
suboptimal for an entirely different reason.
The only reason the codepath for delete/modify in process_entry() wants to
leave the modified side in the result is because the internal merge done
when the algorithm is coming up with a merged merge bases _must_ be fully
resolved. There is no such requirement for the final round of the merge
whose result is written out to the work tree. Whether the path that was
involved in delete/modify conflict was originally in the index or not, we
should just leave it alone in the work tree. The logic I implemented as
the would_lose_untracked() function is just overkill.
^ permalink raw reply
* 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
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