headers
Theodore Ts'o | 1 Jun 2007 01:00
Picon
Picon
Favicon
Gravatar

[PATCH] Fix minor grammatical typos in the git-gc man page

Signed-off-by: "Theodore Ts'o" <tytso <at> mit.edu>
---
 Documentation/git-gc.txt |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 4ac839f..c7742ca 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
 <at>  <at>  -37,10 +37,10  <at>  <at>  OPTIONS

 --aggressive::
 	Usually 'git-gc' runs very quickly while providing good disk
-	space utilization and performance.   This option will cause
-	git-gc to more aggressive optimize the repository at the expense
+	space utilization and performance.  This option will cause
+	git-gc to more aggressively optimize the repository at the expense
 	of taking much more time.  The effects of this optimization are
-	persistent, so this option only needs to be sporadically; every
+	persistent, so this option only needs to be used occasionally; every
 	few hundred changesets or so.

 Configuration
--

-- 
1.5.2.136.g322bc
Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Jun 2007 01:43
Picon
Picon

Re: [PATCH] Let .git/config specify the url for submodules

"Lars Hjemli" <hjemli <at> gmail.com> writes:

> On 5/28/07, Lars Hjemli <hjemli <at> gmail.com> wrote:
>> This changes git-submodule in a few ways:
>
> Please don't apply the "Let .git/config specify the url for
> submodules" patch, I'm having second thoughts ;-)
>
> Your design outline in
> http://article.gmane.org/gmane.comp.version-control.git/48287 is
> obviously superior, and I'd like to take a stab at it with something
> like this:
>
> 1. 'git-submodule init' saves submodule name and suggested url from
> .gitmodules into .git/config (submodule.$name.url)
>
> 2. 'git-submodule update' keeps the work tree updated for submodules
> with five separate (and optional) operations:
>  a) git-clone --bare $url .git/submodules/$name.git
>  b) git-clone -l -s .git/submodules/$name.git $path
>  c) cd .git/submodules/$name.git && git-fetch
>  d) cd $path && git-fetch
>  e) cd $path && git-checkout $sha1
>
> 3) 'git-submodule push' runs something like 'cd $path && git push
> origin $branch', where $branch is found in .gitmodules
> (path.$path.branch).
>
> A remaining issue is how to detect if step 2b is necessary if a
> submodule is already checked out at the submodule path, but I guess
(Continue reading)

Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Jun 2007 01:46
Picon
Picon

Re: [PATCH] Introduce git version --list-features for porcelain use

"Shawn O. Pearce" <spearce <at> spearce.org> writes:

> As a porcelain author I'm finding it difficult to keep track of
> what features I can use in git-gui.  Newer versions of Git have
> newer capabilities but they don't always immediately get newer
> version numbers that I can easily test for.
>
> This is a simple plumbing option that lets a porcelain ask the
> plumbing for its capabilities, at which point the porcelain can
> work around anything missing, or recommend to the user that they
> upgrade their plumbing layer.
>
> Signed-off-by: Shawn O. Pearce <spearce <at> spearce.org>
> ---
>
> 	Johannes Schindelin <Johannes.Schindelin <at> gmx.de> wrote:
> 	>
> 	> On Wed, 30 May 2007, Alex Riesen wrote:
> 	>
> 	> > git-version --features?
> 	>
> 	> Melikes.
>
> 	Good?

Hmmm.  I am not sure if you want list-features in the features
list -- how are you going to test for it?

Also I still do not understand why you want redirect-stderr.
Are you writing for a shell-less environment?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Junio C Hamano | 1 Jun 2007 01:53
Picon
Picon

Re: git-p4import.py robustness changes

Scott Lamb <slamb <at> slamb.org> writes:

> There's a logfile option, but that's a poor excuse for no error
> handling. I'd like to fix it. A couple questions, though:

Good to have somebody who has access to p4.

> First, is it acceptable to switch from os.popen to the subprocess
> module? I ask because the latter was only introduced with Python 2.4
> on. The subprocess module does work with earlier versions of Python
> (definitely 2.3) and is GPL-compatible, so maybe it could be thrown
> into the distribution if desired.

We actually did ship with our own copy after clearing the
licensing situation with Python people, although we removed it
when it lost the last script that used it.  I do not think
resurrecting it is a problem.

> Second, this crowd seems to want sequences of tiny patches. How does
> this sound?
>
> * patch 1 - use subprocess to make git_command.git() and p4_command.p4
> () throw properly-typed exceptions on error, fix caller exception
> handling to match.
>
> * patch 2 - remove the use of the shell and pipelines (fix some
> escaping problems).
>
> * patch 3 - use lists instead of space separation for the commandline
> arguments (fix more escaping problems).
(Continue reading)

Permalink | Reply | 20 comments |
headers
Dana How | 1 Jun 2007 02:01
Picon

Re: [PATCH] fix repack with --max-pack-size

On 5/30/07, Nicolas Pitre <nico <at> cam.org> wrote:
> Two issues here:
>
> 1) git-repack -a --max-pack-size=10 on the GIT repo dies pretty quick.
>    There is a lot of confusion about deltas that were suposed to be
>    reused from another pack but that get stored undeltified due to pack
>    limit and object size doesn't match entry->size anymore.  This test
>    is not really worth the complexity for determining when it is valid
>    so get rid of it.

This is very real.  A smaller fix would have been the hunk
 <at>  <at>  -408,7 +407,7  <at>  <at>  static unsigned long write_object(struct sha1file *f,
>               buf = read_sha1_file(entry->sha1, &type, &size);
>               if (!buf)
>                       die("unable to read %s", sha1_to_hex(entry->sha1));
>-               if (size != entry->size)
>+               if (size != entry->size && type == obj_type)
>                       die("object %s size inconsistency (%lu vs %lu)",
>                           sha1_to_hex(entry->sha1), size, entry->size);
>               if (usable_delta) {
from the max-blob-size patch that hasn't converged yet.

Both pack splitting and blob-size limiting could cause a delta base
not to appear in the pack containing a delta using the base.
Then you get the size mismatch Nicolas discussed
when the real object must be used and its size doesn't match
the delta sized stored in the size field.
I first saw this with max-blob-size,  but only realized recently
that it also applied to max-pack-size.  Sorry I didn't post a patch;
we are swamped at the moment.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Jun 2007 02:12
Picon
Picon

Re: [PATCH] Make the installation targets a little less chatty

Alex Riesen <raa.lkml <at> gmail.com> writes:

> by default. V=1 works as usual.
>
> Signed-off-by: Alex Riesen <raa.lkml <at> gmail.com>
> ---
>
> Now it quite quiet. I tried top show every installed file, but it
> wasn't an improvement at all so I decided to just show what's being
> done.

I agree that the long single line that installs the commands to $(bindir)
may be somewhat annoying.

Cleaning up compilation step is one thing; by tidying up the
output it makes compiler warnings stand out.

But I do not like playing games like this in general in
installation rule.  An excerpt from your patch:

> +	 <at> echo installing programs
> +	$(QUIET)$(foreach p,$(BUILT_INS), rm -f ...

This would not even let you see what got installed.  At least,
less verbose compilation step we have these days lets you see
what is being built.  I certainly would not object if the output
would look like this, though:

	CC builtin-cat-file.o
        ...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Langhoff | 1 Jun 2007 02:37
Picon
Gravatar

Re: Fetch from remote A, push to remote B

On 5/31/07, Martin Langhoff <martin.langhoff <at> gmail.com> wrote:
>   # on cron do
>   GIT_DIR=bla-transfer.git git-fetch git+ssh://host-a/bla.git
>   GIT_DIR=bla-transfer.git git-push --all git+ssh://host-b/bla.git

Actually -- this doesn't quite work - the fetch grabs the new objects
properly but doesn't update the local heads on a bare repo.

cheers,

m
Permalink | Reply | 2 comments |
headers
Greg KH | 1 Jun 2007 03:29
Gravatar

Re: [ANNOUNCE] tig 0.7

On Thu, May 31, 2007 at 11:55:08PM +0200, Jonas Fonseca wrote:
> Steven Grimm <koreth <at> midwinter.com> wrote Thu, May 31, 2007:
> > This doesn't build on OS X out of the box, FYI. It needs the following 
> > tweaks (which break the build on Linux, so I'm not suggesting you apply 
> > this -- looks like you might need a configure script or at least some 
> > conditionals in the Makefile.) The change to tig.c cleans up a compiler 
> > warning, but it does build fine without that change.
> 
> I am aware of this and your suggestion is already in the TODO file.
> However, for 0.7 I ended up needing the new status view feature more
> than working on fixing that.

Which is fricken nice to have, thank you very much for adding this, I'm
already using it.

greg "welded to the command line" k-h
Permalink | Reply | 0 comments |
headers
Martin Langhoff | 1 Jun 2007 03:52
Picon
Gravatar

Re: Fetch from remote A, push to remote B

On 6/1/07, Martin Langhoff <martin.langhoff <at> gmail.com> wrote:
> On 5/31/07, Martin Langhoff <martin.langhoff <at> gmail.com> wrote:
> >   # on cron do
> >   GIT_DIR=bla-transfer.git git-fetch git+ssh://host-a/bla.git
> >   GIT_DIR=bla-transfer.git git-push --all git+ssh://host-b/bla.git
>
> Actually -- this doesn't quite work - the fetch grabs the new objects
> properly but doesn't update the local heads on a bare repo.

Should this work?

GIT_DIR=bla-transfer.git git-fetch git+ssh://host-a/bla.git
+refs/heads/*:refs/heads/*

Earlier discussions about mirroring tools (and Pasky's git-mirror)
finished with this being the recommended technique. Only - it does on
me with

* refusing to create funny ref 'heads/*' locally

cheers,

martin
Permalink | Reply | 1 comment |
headers
Shawn O. Pearce | 1 Jun 2007 05:02
Gravatar

Re: [PATCH] Make the installation target of git-gui a little less chatty

Alex Riesen <raa.lkml <at> gmail.com> wrote:
> Signed-off-by: Alex Riesen <raa.lkml <at> gmail.com>
> ---

I have the exact same reaction as Junio had to the same change in
git.git...  I'll apply it if you resend according to his guidelines.

> The patch is hand-tuned to start in git-gui, so that it can be applied
> in git-gui repo.

Hand-tuning the patch isn't necessary, just making the change its
own patch is all that is required.  Git has these nifty flags for
git-am like -p2 and -3 that make editing filenames in the patch
completely unnecessary.  ;-)

--

-- 
Shawn.
Permalink | Reply | 2 comments |

Gmane