* git-diff should not fire up $PAGER if there is no diff
From: jidanni @ 2008-12-16 0:21 UTC (permalink / raw)
To: git
git-diff should not fire up $PAGER if there is no diff output.
Just exit. The man page doesn't even mention $PAGER too.
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-16 0:16 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, johannes.schindelin, raa.lkml
In-Reply-To: <20081215230205.GA19538@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> I strongly disagree. With the suggested behavior I would have to
> double-check every single untracked file in my tree for conflicts before
> trying a throw-away merge followed by git reset --hard, for example.
AFAICS, that's not "suggested behaviour" for merge, but it is the
behaviour that has been true for eternity.
You can suggest to fix "reset --hard", though.
^ permalink raw reply
* git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: jidanni @ 2008-12-15 23:53 UTC (permalink / raw)
To: git
The git-clone manpage should mention how to determine how much disk
space will be used.
You see we beginners (who haven't learned git yet, so no patches
forthcoming, thank you) are often told "Just do git-clone
git://git.example.org/bla/ to get started!". Being smart, we read up on
--depth 1 to limit potential disk occupation, but we still have no
idea of how much disk space we will need. We cant just use HEAD(1)
because this is not HTTP.
Therefore the git-clone man page, one of the main entry points for the
beginner, should say how to determine how much disk space we will need
for git-clone or git-clone --depth 1 etc.
And don't tell us to just figure it out from the progress messages
after the download begins, and hit ^C if we don't like it.
Let's take a look at those messages while were at it,
$ git-clone --depth 1 git://git.sv.gnu.org/coreutils/
Initialized empty Git repository in /usr/local/src/jidanni/coreutils/.git/
remote: Counting objects: 26240, done.
remote: Compressing objects: 100% (14001/14001), done.
remote: Total 26240 (delta 21577), reused 15354 (delta 12095)
Receiving objects: 100% (26240/26240), 15.76 MiB | 26 KiB/s, done.
Resolving deltas: 100% (21577/21577), done.
$ du -sh
27M .
Nope, nowhere does it directly say "You Holmes, are in for 27
Megabytes (on your piddly modem)". There obviously is math involved to
figure it out... math!
Also add examples of how one first probes a remote tree one has been
told about, determines what parts of it he might want, and then
finally git-clones just those parts.
Also document what --depth 0 or even -1 will do.
^ permalink raw reply
* Re: New script to convert p4 repositories to git - git-p4c version 1.
From: John Chapman @ 2008-12-15 21:52 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Git Mailing List
In-Reply-To: <20081215193058.GA5098@osc.edu>
On Mon, 2008-12-15 at 14:30 -0500, Pete Wyckoff wrote:
<snip>
> 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.
Hmm, I'm not sure how to resolve this, the repo I use this with so far
only uses 6 digit numbers, will have to review the p4 client documents
on this.
>
> 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.
Modifying the on_branch code is the right place to do what you want,
however I was hoping that specifying your 'interesting' branches by
regexp would be sufficient? All those places that do not get matched
are effectively ignored and do not become part of the git repo.
There is a bug in which the case of the branch name sometimes seems to
change in my repo, and thus my newer version always lower-cases the
names.
Do you need to use a client spec here, or is it possible to just use
regexps? I'd like to try and avoid the need to parse the clientspec,
that's all.
> 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.
I'm not sure about client specifications, but I definetly do want to
think of a way around the p4 changes limitation.
I'll get a new version out to you soon (Which includes several bug
fixes), however before I go, I should mention that a deliberate design
decision was to allow the git administrator maximum flexibility.
The script does try to import the full history, however it starts that
history only at the most recent change, which is defined as a tag.
Thus, if your main branch is 'trunk', then you should be able to
manually import your changes, tag it as 'trunk/102388', to indicate
that's p4's revision 102388 of trunk, and the script should then begin
checking out changeset 102389. I haven't had a chance to test that
theory yet, but it should work.
Thankyou for your valuable feedback.
>
> -- Pete
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Clemens Buchacher @ 2008-12-15 23:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.schindelin, raa.lkml
In-Reply-To: <7vej09w0hy.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 15, 2008 at 02:13:13PM -0800, Junio C Hamano wrote:
> 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.
I strongly disagree. With the suggested behavior I would have to
double-check every single untracked file in my tree for conflicts before
trying a throw-away merge followed by git reset --hard, for example. The
file could even be ignored! Whatever happened to git reset doesn't touch
untracked files?
I would even prefer breaking t6023 (until we can properly implement this
feature) in order to avoid that.
^ permalink raw reply
* Re: ETA for release of gjit 0.4?
From: Farrukh Najmi @ 2008-12-15 22:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
In-Reply-To: <493D4CDB.2010100@wellfleetsoftware.com>
Hi Shawn,
I was wondering if there are any updates on my question on whether we
can have a 0.4 release of jgit (no SNAPSHOT).
I am ready to release my software but maven wont let me release it
because its dependency jgit is a SNAPSHOT release.
As I recall you had planned to release 0.4 and make it available on the
maven repo at:
<http://egit.googlecode.com/svn/maven/snapshot-repository/org/spearce/jgit>
I do not see it there yet. Any chance of getting that today? Thanks.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH] gitweb: make feature_blame return a list
From: Giuseppe Bilotta @ 2008-12-15 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <7v7i61w06k.fsf@gitster.siamese.dyndns.org>
On Monday 15 December 2008 23:20, Junio C Hamano wrote:
> 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?
It's formally more correct and makes the blame feature fit with the
general feature framework, although the feature works correctly even
without the (). I was actually going to send a similar patch myself,
having missed it during the cleanup and get/check splitup patchset.
Matt's patch gets my Ack, for what it's worth.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* 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
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