* Re: git hooks to run something
From: Jeff King @ 2009-03-25 11:25 UTC (permalink / raw)
To: Alf Clement; +Cc: git
In-Reply-To: <556d90580903250333l496520ao5fde64fb08faf9ae@mail.gmail.com>
[re-adding git@vger to cc; please keep questions on-list so that others
can also help to answer]
On Wed, Mar 25, 2009 at 11:33:39AM +0100, Alf Clement wrote:
> is there a way to push a modified hook script with the repository when
> I push it to a server?
> And how to get it with pull?
No; for security reasons, no code (including hooks) from remote
repositories is automatically run. The usual method is to include the
hook in your repository and copy it into place after cloning.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Jeff King @ 2009-03-25 11:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <1237978720-2500-1-git-send-email-pclouds@gmail.com>
On Wed, Mar 25, 2009 at 09:58:40PM +1100, Nguyễn Thái Ngọc Duy wrote:
> -'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
> +'git init' [-q | --quiet] [--bare] [--template=<template_directory>]
> + [--shared[=<permissions>]] [-m|--import [<message>]]
What happened to --import=? Whether or not "--import <arg>" works, the
--long-opt= form should always work.
> + else if (!strcmp(arg, "--import") || !strcmp(arg, "-m")) {
> + if (i+1 >= argc)
> + import_message = "Initial commit";
> + else {
> + import_message = argv[2];
> + i++;
> + argv++;
> + }
> + }
This is the wrong way to do optional arguments. It means that
git init --template=foo --import
is different from
git init --import --template=foo
I think what you want is:
else if (!strcmp(arg, "-m")) {
if (i+1 >= argc)
die("-m requires an import message");
import_message = argv[2];
i++;
argv++;
}
else if (!strcmp(arg, "--import"))
import_message = "Initial commit";
else if (!prefixcmp(arg, "--import="))
import_message = arg+9;
That is, --import has a message or not depending on the '=', and "-m"
always has a message. If you want "-m" to optionally have a message then
it must be used as
git init -mfoo
-Peff
^ permalink raw reply
* [TopGit PATCH] hooks/pre-commit.sh: fix it again
From: Bert Wesarg @ 2009-03-25 11:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Bert Wesarg, git, martin f krafft, u.kleine-koenig
First I think the '#' is a leftover, second this is now a bashism.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
hooks/pre-commit.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hooks/pre-commit.sh b/hooks/pre-commit.sh
index a12cfa6..edf2932 100644
--- a/hooks/pre-commit.sh
+++ b/hooks/pre-commit.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
# TopGit - A different patch queue manager
# (c) Petr Baudis <pasky@suse.cz> 2008
# GPLv2
@@ -20,7 +20,7 @@ tg_util
if head_=$(git symbolic-ref -q HEAD); then
case "$head_" in
refs/heads/*)
- git rev-parse -q --verify "${head_/#refs\/heads/refs\/top-bases}" >/dev/null || exit 0;;
+ git rev-parse -q --verify "${head_/refs\/heads/refs\/top-bases}" >/dev/null || exit 0;;
*)
exit 0;;
esac
--
tg: (fcb488d..) bw/fix-hook-again (depends on: master)
^ permalink raw reply related
* git + eclipse on windows
From: Native @ 2009-03-25 11:50 UTC (permalink / raw)
To: git
Hello!
I try clone the repository via Eclipse plugin on Windows. After successful
connecting and choosing of branch, I obtain such message:
D:\EclipseProjects\example\exapp\:q (The filename, directory name, or volume
label syntax is incorrect)
D:\EclipseProjects\example\exapp\:q (The filename, directory name, or volume
label syntax is incorrect)
Help, pls
--
View this message in context: http://www.nabble.com/git-%2B-eclipse-on-windows-tp22700038p22700038.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Memory of past repositories in git remote?
From: Christophe de Dinechin @ 2009-03-25 11:47 UTC (permalink / raw)
To: git; +Cc: Christophe de Dinechin
I ran into a peculiar issue running git 1.6.1.2 on HP-UX: it looks
like something has remembered an old repository and insists on
providing that to "git fetch" instead of the new repository. Appending
"/." at the end of the remote repository fixes the problem.
Here are the details. I created a git repository in /home/ddd/vmm,
impored some Subversion history, and started working with that. I
created a few branches, e.g. one called "perrier". Then, I realized
that there was a better way to track Subversion changes, and so I
moved the old repository as /home/ddd/vmm.git, and created a new one
that I populated with "git svn clone svn+ssh://path/to/repot -T trunk -
b branches -t users". That new repository has no branch named
"perrier" in it.
Now, when I'm on another machine, create a new repository with the
same "git svn clone", then do a "git remote add ddd ssh://name@mymachine/home/ddd/vmm
", I would expect to pick up the repository that is actually under /
home/ddd/vmm on mymachine. But when I do a "git svn fetch", the output
contains:
warning: no common commits
remote: Counting objects: 66874, done.
remote: Compressing objects: 100% (14626/14626), done.
remote: Total 66874 (delta 51668), reused 66589 (delta 51418)
Receiving objects: 100% (66874/66874), 96.41 MiB | 187 KiB/s, done
Resolving deltas: 100% (51668/51668), done.
From ssh://name@mymachine/home/ddd/vmm
* [new branch] perrier -> ddd/perrier
...
as well as all branches from /home/ddd/vmm.git (not /home/ddd/vmm). I
tried doing an "ssh name@mymachine ls /home/ddd/vmm" to check that
this was indeed the new repository. If instead of "/home/ddd/vmm", I
specify "/home/ddd/vmm/.", then I do get the branches in the new
repository, e.g in that case I get:
* [new branch] tot -> ddd-good/tot
This is not just a name dependency, though, because if I specify /
home/./ddd/vmm, then I get the old repository again. So what seems to
matter is the dot at the end of the repository name.
I'm really puzzled by this behavior, and I have been unable to find
anything in the git documentation explaining it. I tried to find
references to vmm.git anywhere on either machines, but I couldn't.
This is easily reproduced, so I'm willing to run experiments to try
and debug the problem.
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Santi Béjar @ 2009-03-25 11:56 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Johannes Schindelin, Jeff King
In-Reply-To: <1237978720-2500-1-git-send-email-pclouds@gmail.com>
2009/3/25 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> +-m <message>::
> +--import <message>::
> +
> +Commit everything to the newly initialized repository. This is equivalent to:
> +
> +----------------
> +$ git init
> +$ git add .
> +$ git commit -q -m <message>
> +----------------
> +
> +If no message is given, "Initial commit" will be used.
Why a default message and not running the editor?
Santi
^ permalink raw reply
* Re: Memory of past repositories in git remote?
From: Santi Béjar @ 2009-03-25 12:05 UTC (permalink / raw)
To: Christophe de Dinechin; +Cc: git, Christophe de Dinechin
In-Reply-To: <784F93DB-2D7C-4F48-88E8-BF56F01CD1E2@dinechin.org>
2009/3/25 Christophe de Dinechin <christophe.de.dinechin@gmail.com>:
> Here are the details. I created a git repository in /home/ddd/vmm, impored
> some Subversion history, and started working with that. I created a few
> branches, e.g. one called "perrier". Then, I realized that there was a
> better way to track Subversion changes, and so I moved the old repository as
> /home/ddd/vmm.git, and created a new one that I populated with "git svn
> clone svn+ssh://path/to/repot -T trunk -b branches -t users". That new
> repository has no branch named "perrier" in it.
Git tries different url: $url/.git, $url.git and $url (I'm not sure
about the order).
So having $url and $url.git is asking for problems. I don't know if it
is documented somewhere.
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] avoid possible overflow in delta size filtering computation
From: Kjetil Barvik @ 2009-03-25 12:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0903241535010.26337@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On a 32-bit system, the maximum possible size for an object is less than
> 4GB, while 64-bit systems may cope with larger objects. Due to this
> limitation, variables holding object sizes are using an unsigned long
> type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).
>
> When large objects are encountered, and/or people play with large delta
> depth values, it is possible for the maximum allowed delta size
> computation to overflow, especially on a 32-bit system. When this
> occurs, surviving result bits may represent a value much smaller than
> what it is supposed to be, or even zero. This prevents some objects
> from being deltified although they do get deltified when a smaller depth
> limit is used. Fix this by always performing a 64-bit multiplication.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
I added this patch and rerun the 2 test cases form the table where
--depth is 20000 and 95000, and got the following result:
--depth=20000 => file size: 19126077 delta: 73814
--depth=95000 => file size: 19126087 delta: 73814
So, it seems that this patch almost fixed the issue. But notice that
the pack file was 10 bytes larger for the --depth=95000 case.
I made a small perl script to compare the output from 'git verify-pack
-v' of the 2 idx/pack files, and found the following difference(1)
(first line from --depth=20000 case, second from --depth=95000):
fe0a6f3e971373590714dbafd087b235ea60ac00 tree 9 19 18921247 731 96a3ec5789504e6d0f90c99fb1937af1ebd58e2d
fe0a6f3e971373590714dbafd087b235ea60ac00 tree 20 29 18921247 730 12e560f7fb28558b15e3a2008fba860f9a4b2222
'git show fe0a6f3e971373590714dbafd087b235ea60ac00' =>
tree fe0a6f3e971373590714dbafd087b235ea60ac00
Makefile
t0000-basic.sh
test-lib.sh
'git show 96a3ec5789504e6d0f90c99fb1937af1ebd58e2d' =>
tree 96a3ec5789504e6d0f90c99fb1937af1ebd58e2d
Makefile
t0000-basic.sh
t0100-environment-names.sh
t0200-update-cache.sh
t0400-ls-files.sh
t0500-ls-files.sh
t1000-checkout-cache.sh
t1001-checkout-cache.sh
test-lib.sh
'git show 12e560f7fb28558b15e3a2008fba860f9a4b2222' =>
tree 12e560f7fb28558b15e3a2008fba860f9a4b2222
Makefile
t0000-basic.sh
t0100-environment-names.sh
t0200-update-cache.sh
t0400-ls-files.sh
t0500-ls-files.sh
t1000-checkout-cache.sh
t1001-checkout-cache.sh
test-lib.sh
-- kjetil
1) there was lots of lines with different offsets, all of which was 10
larger in the --depth=95000 case.
^ permalink raw reply
* Re: [TopGit PATCH] hooks/pre-commit.sh: fix it again
From: Uwe Kleine-König @ 2009-03-25 12:20 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Petr Baudis, git, martin f krafft
In-Reply-To: <1237981384-7857-1-git-send-email-bert.wesarg@googlemail.com>
On Wed, Mar 25, 2009 at 12:43:04PM +0100, Bert Wesarg wrote:
> First I think the '#' is a leftover, second this is now a bashism.
according to bash(1):
If pattern begins with #, it must match at the beginning of the
expanded value of parameter.
And I noticed, too, that this is a bashism. Using dash it fails, even
with your patch.
I would prefer to really fix it now.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [TopGit PATCH] hooks/pre-commit.sh: fix it again
From: Bert Wesarg @ 2009-03-25 12:24 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Petr Baudis, git, martin f krafft
In-Reply-To: <20090325122027.GB30873@pengutronix.de>
2009/3/25 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> On Wed, Mar 25, 2009 at 12:43:04PM +0100, Bert Wesarg wrote:
>> First I think the '#' is a leftover, second this is now a bashism.
> according to bash(1):
>
> If pattern begins with #, it must match at the beginning of the
> expanded value of parameter.
That is obviously true, I first removed this # and than switch to bash
(after it stills failed), so this was just thinking not testing.
>
> And I noticed, too, that this is a bashism. Using dash it fails, even
> with your patch.
>
> I would prefer to really fix it now.
Thanks. I intended this patch as a bug report.
Bert
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Johannes Schindelin @ 2009-03-25 12:38 UTC (permalink / raw)
To: Santi Béjar; +Cc: Nguyễn Thái Ngọc Duy, git, Jeff King
In-Reply-To: <adf1fd3d0903250456l3c14a863pd6ee00c0025100c4@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 538 bytes --]
Hi,
On Wed, 25 Mar 2009, Santi Béjar wrote:
> 2009/3/25 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> > +-m <message>::
> > +--import <message>::
> > +
> > +Commit everything to the newly initialized repository. This is equivalent to:
> > +
> > +----------------
> > +$ git init
> > +$ git add .
> > +$ git commit -q -m <message>
> > +----------------
> > +
> > +If no message is given, "Initial commit" will be used.
>
> Why a default message and not running the editor?
Because I would say "Initial commit" anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Jeff King @ 2009-03-25 12:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Nguyễn Thái Ngọc Duy, git
In-Reply-To: <alpine.DEB.1.00.0903251338130.26370@intel-tinevez-2-302>
On Wed, Mar 25, 2009 at 01:38:30PM +0100, Johannes Schindelin wrote:
> > > +If no message is given, "Initial commit" will be used.
> >
> > Why a default message and not running the editor?
>
> Because I would say "Initial commit" anyway.
Agreed. This feature is about convenience. If you really want to say
something more exciting, then use "git commit" directly. Heck, you can
even "git commit --amend" it afterwards.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Santi Béjar @ 2009-03-25 12:49 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Nguyễn Thái Ngọc, git
In-Reply-To: <20090325124219.GA5307@coredump.intra.peff.net>
2009/3/25 Jeff King <peff@peff.net>:
> On Wed, Mar 25, 2009 at 01:38:30PM +0100, Johannes Schindelin wrote:
>
>> > > +If no message is given, "Initial commit" will be used.
>> >
>> > Why a default message and not running the editor?
>>
>> Because I would say "Initial commit" anyway.
And I would say "Commit inicial".
>
> Agreed. This feature is about convenience.
... for project in english.
> If you really want to say
> something more exciting, then use "git commit" directly. Heck, you can
> even "git commit --amend" it afterwards.
I can. But then it is no longer "convenience".
But anyway, it is like the "Merge branch..." commit message for
merges. So nothing new.
Santi
^ permalink raw reply
* Re: [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: Sverre Rabbelier @ 2009-03-25 13:04 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Git List, spearce
In-Reply-To: <20090324231900.GB14967@zoy.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 178 bytes --]
Heya,
On Wed, Mar 25, 2009 at 00:19, Sam Hocevar <sam@zoy.org> wrote:
> ---
> ¨x¨y¨z¨{¨|¨}¨~¨€
I'm curious, where'd this come from?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH JGIT 1/2] Calculate CRC32 on Pack Index v2
From: Marek Zawirski @ 2009-03-25 13:31 UTC (permalink / raw)
To: Daniel Cheng (aka SDiZ); +Cc: Shawn O. Pearce, git
In-Reply-To: <1237962115-22709-1-git-send-email-j16sdiz+freenet@gmail.com>
Hi,
Thanks for spotting this bug.
Daniel Cheng (aka SDiZ) wrote:
(...)
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
> index 601ce71..d8b50e6 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
> @@ -687,11 +687,13 @@ public class PackWriter {
>
> assert !otp.isWritten();
>
> + countingOut.resetCRC32();
> otp.setOffset(countingOut.getCount());
> if (otp.isDeltaRepresentation())
> writeDeltaObject(otp);
> else
> writeWholeObject(otp);
> + otp.setCRC((int) countingOut.getCRC32());
>
>
Huh, now it appears that you made CRC32 really computed;)
I just wonder if it is sensible to compute it always regardless of used
index version (outputVersion) - for index v1 we don't really need CRC32
to be computed. I don't have a good idea how can it be avoided in truly
elegant way, as we cannot rely on the outputVersion checking in this
code - currently it may became changed after writing pack, but before
writing index. But maybe it's not so important issue, as AFAIR v2 is
already default version for index.
> }
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java b/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java
> index b0b5f7d..b4ae915 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java
> @@ -40,12 +40,16 @@ package org.spearce.jgit.util;
> import java.io.FilterOutputStream;
> import java.io.IOException;
> import java.io.OutputStream;
> +import java.util.zip.CRC32;
>
> /**
> - * Counting output stream decoration. Counts bytes written to stream.
> + * Counting output stream decoration. Counts bytes written to stream and
> + * calculate CRC32 checksum.
>
IMO it would be better to make CRC32 computation in another decorator
class, but that's just me.
> */
> public class CountingOutputStream extends FilterOutputStream {
> private long count;
> +
> + private CRC32 crc;
>
> /**
> * Create counting stream being decorated to provided real output stream.
> @@ -55,6 +59,7 @@ public class CountingOutputStream extends FilterOutputStream {
> */
> public CountingOutputStream(OutputStream out) {
> super(out);
> + crc = new CRC32();
> }
>
> @Override
> @@ -79,10 +84,35 @@ public class CountingOutputStream extends FilterOutputStream {
> return count;
> }
>
> + /**
> + * Resets CRC-32 to initial value.
> + */
> + public void resetCRC32() {
> + crc.reset();
> + }
> +
> + /**
> + * Returns CRC-32 value.
> + * @return CRC32
> + */
> + public long getCRC32() {
> + return crc.getValue();
> + }
> +
> +
> /**
> * Reset counter to zero value.
> */
> public void reset() {
> count = 0;
> + crc.reset();
> + }
> +
> + /**
> + * {@inheritDoc}
> + */
> + public void close() throws IOException {
> + crc = null;
> + super.close();
> }
> }
>
Have you tested that code? It seems that CRC32 updates is missing in
write() method... or did I slept too short this night?:)
Best,
Marek
^ permalink raw reply
* Re: Memory of past repositories in git remote?
From: Michael J Gruber @ 2009-03-25 14:22 UTC (permalink / raw)
To: Christophe de Dinechin; +Cc: git, Christophe de Dinechin, Santi Béjar
In-Reply-To: <784F93DB-2D7C-4F48-88E8-BF56F01CD1E2@dinechin.org>
Christophe de Dinechin venit, vidit, dixit 25.03.2009 12:47:
> I ran into a peculiar issue running git 1.6.1.2 on HP-UX: it looks
> like something has remembered an old repository and insists on
> providing that to "git fetch" instead of the new repository. Appending
> "/." at the end of the remote repository fixes the problem.
>
> Here are the details. I created a git repository in /home/ddd/vmm,
> impored some Subversion history, and started working with that. I
> created a few branches, e.g. one called "perrier". Then, I realized
> that there was a better way to track Subversion changes, and so I
> moved the old repository as /home/ddd/vmm.git, and created a new one
> that I populated with "git svn clone svn+ssh://path/to/repot -T trunk -
> b branches -t users". That new repository has no branch named
> "perrier" in it.
>
> Now, when I'm on another machine, create a new repository with the
> same "git svn clone", then do a "git remote add ddd ssh://name@mymachine/home/ddd/vmm
> ", I would expect to pick up the repository that is actually under /
> home/ddd/vmm on mymachine. But when I do a "git svn fetch", the output
> contains:
>
> warning: no common commits
> remote: Counting objects: 66874, done.
> remote: Compressing objects: 100% (14626/14626), done.
> remote: Total 66874 (delta 51668), reused 66589 (delta 51418)
> Receiving objects: 100% (66874/66874), 96.41 MiB | 187 KiB/s, done
> Resolving deltas: 100% (51668/51668), done.
> From ssh://name@mymachine/home/ddd/vmm
> * [new branch] perrier -> ddd/perrier
> ...
>
> as well as all branches from /home/ddd/vmm.git (not /home/ddd/vmm). I
> tried doing an "ssh name@mymachine ls /home/ddd/vmm" to check that
> this was indeed the new repository. If instead of "/home/ddd/vmm", I
> specify "/home/ddd/vmm/.", then I do get the branches in the new
> repository, e.g in that case I get:
>
> * [new branch] tot -> ddd-good/tot
>
> This is not just a name dependency, though, because if I specify /
> home/./ddd/vmm, then I get the old repository again. So what seems to
> matter is the dot at the end of the repository name.
>
> I'm really puzzled by this behavior, and I have been unable to find
> anything in the git documentation explaining it. I tried to find
> references to vmm.git anywhere on either machines, but I couldn't.
>
> This is easily reproduced, so I'm willing to run experiments to try
> and debug the problem.
Given %s, git looks for existence of "%s.git/.git",
* "%s/.git", "%s.git", "%s" in this order. So it's intentional
behavior, not a bug.
The idea is that non-bare repos should be chosen over bare ones, and
bare ones are usually named something.git. One may argue whether %s/.git
should come before %s.git/.git.
Michael
^ permalink raw reply
* Re: Memory of past repositories in git remote?
From: Christophe de Dinechin @ 2009-03-25 14:51 UTC (permalink / raw)
To: Santi Béjar; +Cc: Christophe de Dinechin, Christophe de Dinechin, git
In-Reply-To: <adf1fd3d0903250505o38e0ac54jcf07f4425eee0a6@mail.gmail.com>
Yep, that was it. I didn't realize that $url.git was being tested first.
Thanks
Christophe
On 25 mars 09, at 13:05, Santi Béjar wrote:
> 2009/3/25 Christophe de Dinechin <christophe.de.dinechin@gmail.com>:
>> Here are the details. I created a git repository in /home/ddd/vmm,
>> impored
>> some Subversion history, and started working with that. I created a
>> few
>> branches, e.g. one called "perrier". Then, I realized that there
>> was a
>> better way to track Subversion changes, and so I moved the old
>> repository as
>> /home/ddd/vmm.git, and created a new one that I populated with "git
>> svn
>> clone svn+ssh://path/to/repot -T trunk -b branches -t users". That
>> new
>> repository has no branch named "perrier" in it.
>
> Git tries different url: $url/.git, $url.git and $url (I'm not sure
> about the order).
>
> So having $url and $url.git is asking for problems. I don't know if it
> is documented somewhere.
>
> HTH,
> Santi
^ permalink raw reply
* Re: [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: Sam Hocevar @ 2009-03-25 15:23 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e0903250604t2909e9bbg66c6dab82dcf3333@mail.gmail.com>
On Wed, Mar 25, 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Mar 25, 2009 at 00:19, Sam Hocevar <sam@zoy.org> wrote:
> > ---
> > ▁▂▃▄▅▆▇█
>
> I'm curious, where'd this come from?
Just a few characters from the "Block Elements" Unicode block.
For some reason, even though my locale is en_GB.UTF-8, Mutt insists
on converting my messages to iso8859-1 when doing so does not lose
information, resulting in corrupted patches, hence my addition of the
above characters.
By the way, your own mailer seems to be mangling those Unicode
characters when answering.
Cheers,
--
Sam.
^ permalink raw reply
* Re: [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: Sverre Rabbelier @ 2009-03-25 15:26 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Git List
In-Reply-To: <20090325152338.GD30959@zoy.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 995 bytes --]
Heya,
On Wed, Mar 25, 2009 at 16:23, Sam Hocevar <sam@zoy.org> wrote:
> On Wed, Mar 25, 2009, Sverre Rabbelier wrote:
>> Heya,
>>
>> On Wed, Mar 25, 2009 at 00:19, Sam Hocevar <sam@zoy.org> wrote:
>> > ---
>> > ¨x¨y¨z¨{¨|¨}¨~¨€
>>
>> I'm curious, where'd this come from?
>
> Just a few characters from the "Block Elements" Unicode block.
> For some reason, even though my locale is en_GB.UTF-8, Mutt insists
> on converting my messages to iso8859-1 when doing so does not lose
> information, resulting in corrupted patches, hence my addition of the
> above characters.
Aaah, similar to the <3 in the other git-gui translation patch.
> By the way, your own mailer seems to be mangling those Unicode
> characters when answering.
Yeah, GMail is not that good about encoding and stuff, good thing I
never really need it do be :P. (The main downside is that I sometimes
get base-64 encoded emails as a bunch of unreadable text).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: Mike Hommey @ 2009-03-25 15:27 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Git List
In-Reply-To: <20090325152338.GD30959@zoy.org>
On Wed, Mar 25, 2009 at 04:23:38PM +0100, Sam Hocevar <sam@zoy.org> wrote:
> On Wed, Mar 25, 2009, Sverre Rabbelier wrote:
> > Heya,
> >
> > On Wed, Mar 25, 2009 at 00:19, Sam Hocevar <sam@zoy.org> wrote:
> > > ---
> > > ▁▂▃▄▅▆▇█
> >
> > I'm curious, where'd this come from?
>
> Just a few characters from the "Block Elements" Unicode block.
> For some reason, even though my locale is en_GB.UTF-8, Mutt insists
> on converting my messages to iso8859-1 when doing so does not lose
> information, resulting in corrupted patches, hence my addition of the
> above characters.
echo 'set send_charset="utf-8"' >> $HOME/.mutt/muttrc
Mike
^ permalink raw reply
* Re: [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: David Kastrup @ 2009-03-25 15:28 UTC (permalink / raw)
To: git
In-Reply-To: <20090325152338.GD30959@zoy.org>
Sam Hocevar <sam@zoy.org> writes:
> On Wed, Mar 25, 2009, Sverre Rabbelier wrote:
>> Heya,
>>
>> On Wed, Mar 25, 2009 at 00:19, Sam Hocevar <sam@zoy.org> wrote:
>> > ---
>> > ▁▂▃▄▅▆▇█
>>
>> I'm curious, where'd this come from?
>
> Just a few characters from the "Block Elements" Unicode block.
> For some reason, even though my locale is en_GB.UTF-8, Mutt insists
> on converting my messages to iso8859-1 when doing so does not lose
> information, resulting in corrupted patches, hence my addition of the
> above characters.
>
> By the way, your own mailer seems to be mangling those Unicode
> characters when answering.
No, he just chose to encode them using GB2312 rather than utf-8. But
that is not prohibited.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: Samuel Tardieu @ 2009-03-25 15:34 UTC (permalink / raw)
To: sam; +Cc: Git List
In-Reply-To: <20090325152338.GD30959@zoy.org>
>>>>> "Sam" == Sam Hocevar <sam@zoy.org> writes:
Sam> On Wed, Mar 25, 2009, Sverre Rabbelier wrote:
>> Heya,
>>
>> On Wed, Mar 25, 2009 at 00:19, Sam Hocevar <sam@zoy.org> wrote:
>> > --- > ▁▂▃▄▅▆▇█
>>
>> I'm curious, where'd this come from?
Sam> Just a few characters from the "Block Elements" Unicode block.
Sam> For some reason, even though my locale is en_GB.UTF-8, Mutt
Sam> insists on converting my messages to iso8859-1 when doing so does
Sam> not lose information, resulting in corrupted patches, hence my
Sam> addition of the above characters.
In what way would patches get corrupted if there is no loss of
information?
Alternately, you could use
set send_charset="utf-8"
to have mutt send mails in utf-8 only (in your .muttrc).
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: Johannes Schindelin @ 2009-03-25 15:44 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Sverre Rabbelier, Git List
In-Reply-To: <20090325152338.GD30959@zoy.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 703 bytes --]
Hi,
On Wed, 25 Mar 2009, Sam Hocevar wrote:
> On Wed, Mar 25, 2009, Sverre Rabbelier wrote:
> > Heya,
> >
> > On Wed, Mar 25, 2009 at 00:19, Sam Hocevar <sam@zoy.org> wrote:
> > > ---
> > > ▁▂▃▄▅▆▇█
> >
> > I'm curious, where'd this come from?
>
> Just a few characters from the "Block Elements" Unicode block.
> For some reason, even though my locale is en_GB.UTF-8, Mutt insists
> on converting my messages to iso8859-1 when doing so does not lose
> information, resulting in corrupted patches, hence my addition of the
> above characters.
>
> By the way, your own mailer seems to be mangling those Unicode
> characters when answering.
Works correctly here.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] format-patch: add arbitrary email headers
From: Michael Hendricks @ 2009-03-25 15:58 UTC (permalink / raw)
To: git, gitster; +Cc: Michael Hendricks
format-patch supports the format.headers configuration for adding
arbitrary email headers to the patches it outputs. This patch adds
support for a --header argument which makes the same feature available
from the command line. This is useful when the content of custom
email headers must change from branch to branch.
This patch has been sponsored by Grant Street Group
Signed-off-by: Michael Hendricks <michael@ndrix.org>
---
Documentation/git-format-patch.txt | 5 +++++
builtin-log.c | 2 ++
t/t4014-format-patch.sh | 15 +++++++++++++++
3 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..e6fe7f3 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -161,6 +161,11 @@ if that is not set.
Add a "Cc:" header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
+--header=<header>::
+ Add an arbitrary header to the email headers. This is in addition
+ to any configured headers, and may be used multiple times.
+ For example, --header="Organization: git-foo"
+
--cover-letter::
In addition to the patches, generate a cover letter file
containing the shortlog and the overall diffstat. You can
diff --git a/builtin-log.c b/builtin-log.c
index c7a5772..35701a7 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -918,6 +918,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
cover_letter = 1;
else if (!strcmp(argv[i], "--no-binary"))
no_binary_diff = 1;
+ else if (!prefixcmp(argv[i], "--header="))
+ add_header( argv[i] + 9 );
else
argv[j++] = argv[i];
}
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index f187d15..5f8d9b4 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -128,6 +128,21 @@ test_expect_success 'additional command line cc' '
grep "^ *S. E. Cipient <scipient@example.com>$" patch5
'
+test_expect_success 'command line headers' '
+
+ git config --unset-all format.headers &&
+ git format-patch --header="Cc: R. E. Cipient <rcipient@example.com>" --stdout master..side | sed -e "/^$/q" >patch6 &&
+ grep "^Cc: R. E. Cipient <rcipient@example.com>$" patch6
+'
+
+test_expect_success 'configuration headers and command line headers' '
+
+ git config --replace-all format.headers "Cc: R. E. Cipient <rcipient@example.com>" &&
+ git format-patch --header="Cc: S. E. Cipient <scipient@example.com>" --stdout master..side | sed -e "/^$/q" >patch7 &&
+ grep "^Cc: R. E. Cipient <rcipient@example.com>,$" patch7 &&
+ grep "^ *S. E. Cipient <scipient@example.com>$" patch7
+'
+
test_expect_success 'multiple files' '
rm -rf patches/ &&
--
1.6.2.1.318.ged85d
^ permalink raw reply related
* Re: [BUG] Infinite loop in git send-email if ran non-interactively.
From: Jay Soffian @ 2009-03-25 16:03 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqiqlyj64o.fsf@bauges.imag.fr>
On Wed, Mar 25, 2009 at 5:36 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> I think, non-interactive runs of send-email should assume "yes"
Hmm, probably.
> instead of prompting. In any case, it should not do infinite loop (I
> guess I don't have to argue for this ;-) )
Right, I'll followup with a fix.
> Can someone more fluent in perl than me add a
>
> if(session-is-interactive) {
> ...
> }
>
> around this confirmation prompt?
>
> (side-note : there is indeed some code to handle the cases where the
> terminal doesn't work with readline, added by Junio in 280242d1, but
> the FakeTerm part doesn't seem to be executed in my case:
>
> my $term = eval {
> $ENV{"GIT_SEND_EMAIL_NOTTY"}
> ? new Term::ReadLine 'git-send-email', \*STDIN, \*STDOUT
> : new Term::ReadLine 'git-send-email';
> };
> if ($@) {
> $term = new FakeTerm "$@: going non-interactive";
> }
> )
>
> (in the meantime, I'll add --confirm never to my script)
Actually, FakeTerm is only triggered if Term::ReadLine is not
available. The "going non-interactive" message is misleading in this
case, as it has nothing to do with whether stdin is a tty or not.
j.
^ 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