* Extra pair of double quotes in "git commit" output?
From: Nanako Shiraishi @ 2008-11-25 21:49 UTC (permalink / raw)
To: git
While I think the way recent "git commit" displays the commit you just created is very helpful, I often find the double quotes around the message unnecessary and sometimes even confusing. I just made a commit and saw this message:
[master]: created d9a5491: "Show "standard deviation" column in table 3"
The colon after the shortened commit SHA1 is enough to signal that it will talk about a different piece of information on the rest of the line. I think the extra double quotes can be dropped safely:
[master]: created d9a5491: Show "standard deviation" column in table 3
and it will make the output shorter by two columns, more pretty, and does not lose the clarity.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: Junio C Hamano @ 2008-11-25 22:02 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20081126064906.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> While I think the way recent "git commit" displays the commit you just created is very helpful, I often find the double quotes around the message unnecessary and sometimes even confusing. I just made a commit and saw this message:
>
> [master]: created d9a5491: "Show "standard deviation" column in table 3"
>
> The colon after the shortened commit SHA1 is enough to signal that it will talk about a different piece of information on the rest of the line. I think the extra double quotes can be dropped safely:
>
> [master]: created d9a5491: Show "standard deviation" column in table 3
>
> and it will make the output shorter by two columns, more pretty, and does not lose the clarity.
[offtopic. Please wrap your text at a reasonable width around 70 columns]
Like this?
It might break some existing tests (I didn't check), but I think that is a
sensible thing to do.
builtin-commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git c/builtin-commit.c w/builtin-commit.c
index 591d16b..654bfbe 100644
--- c/builtin-commit.c
+++ w/builtin-commit.c
@@ -881,7 +881,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
{
struct rev_info rev;
struct commit *commit;
- static const char *format = "format:%h: \"%s\"";
+ static const char *format = "format:%h: %s";
unsigned char junk_sha1[20];
const char *head = resolve_ref("HEAD", junk_sha1, 0, NULL);
^ permalink raw reply related
* Re: git svn rebase creates some commits with empty author, commiter and date fields
From: Eric Wong @ 2008-11-25 22:06 UTC (permalink / raw)
To: Peter Kirk; +Cc: git
In-Reply-To: <200811181121.18264.peter.kirk@gmx.de>
Peter Kirk <peter.kirk@gmx.de> wrote:
> Hi there,
>
> I am using git version 1.6.0.3, which I compiled myself from sources on my
> linux/amd64 box which runns kubuntu 8.10.
>
> Now, when I do "git svn clone" to retrieve the entire history from the svn
> server then everything works fine. Then I start working with this, commit some
> myself, and run "git svn rebase" frequently. What happens (and I don't see the
> pattern) is that *some* commits that are retrieved via "git svn rebase" are
> broken...they don't contain a valid author field, the date is at 1970 and, most
> importantly (for me) the commit message is empty except for the "git-svn-id:"
> line that "git svn" adds automatically. The diff is fine, and I can still use
> the checkout fine...but I cannot view the log-message/author/date of some
> commits, which becomes tiresome quickly.
> The only way to "fix" these broken commits is to do a clean "git svn clone",
> but as new commits are pulled via "git svn rebase", my repository will again
> become polluted with broken commits.
Weird.
Does this happen on other repositories you may use as well? Do you know
of any strange hooks or otherwise non-standard setup with the SVN
server?
Which version of the SVN perl bindings are you using?
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/4] builtin-clone: fix a memory leak in cmd_clone()
From: Miklos Vajna @ 2008-11-25 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabbpok6v.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
On Sun, Nov 23, 2008 at 07:51:36PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Can't this be done much earlier? This variable can potentially be
> assigned to work_tree, but after we set up the atexit handler neither dir
> nor work_tree are not used (it is a bit hard to see as this function
> itself is a bit too big to be maintainable).
Hm, reading the code again I think you should just drop 1/4.
work_tree is a pointer to dir, and junk_work_tree is a pointer to
work_tree. junk_work_tree is used in the signal handler, so it has to be
allocated during the whole clone.
I guess it was just an accident that my patch passed the tests.
Sorry for the mistake.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-svn and svn branches
From: Eric Wong @ 2008-11-25 23:08 UTC (permalink / raw)
To: Ryan Phillips; +Cc: git
In-Reply-To: <20081121195835.GA12141@athena.lan>
Ryan Phillips <ryan@trolocsis.com> wrote:
> I followed the following instructions on adding a remote svn branch to my
> local git-svn repository. http://www.dmo.ca/blog/20070608113513
>
> Are these still accurate?
>
> I started the repository with
> # git svn init [url/trunk]`
> # cd project.git
> # git svn fetch -r[HEAD revision]
> which works fine. I added something like Snippet 1 to the .git/config and
> issued a `git svn fetch -r[HEAD revision of the branch]` and nothing
> happens. It takes git-svn a few seconds to run, but the git-remote svn
> branch doesn't get initialized.
>
> Does this procedure only work with a full mirror of a git-svn repository?
> or perhaps I'm doing something wrong. Any help would be appreciated.
>
> Thanks,
> Ryan
>
> Snippet 1
> =========
>
> [svn-remote "svn34"]
> url = svn+ssh://your-server/home/svn/project-name/branches/3.4.x
> fetch = :refs/remotes/git-svn-3.4
Try this:
git svn fetch -i svn34
It's been a while since I've used this, but I believe a test
case covers it so it probably still works :)
--
Eric Wong
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: Jeff King @ 2008-11-25 23:25 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20081126064906.6117@nanako3.lavabit.com>
On Wed, Nov 26, 2008 at 06:49:06AM +0900, Nanako Shiraishi wrote:
> While I think the way recent "git commit" displays the commit you just
> created is very helpful, I often find the double quotes around the
> message unnecessary and sometimes even confusing. I just made a
> commit and saw this message:
>
> [master]: created d9a5491: "Show "standard deviation" column in table 3"
While I do think that typographically the embedded quotes look awful, I
find that the quotes do help separate the commit subject from the other
text when there are colons in the subject. IOW, I think that
[master]: created d9a5491: foo: bar
is harder to read than
[master]: created d9a5491: "foo: bar"
And 47% of commits in git.git have a colon (only 7% have a double
quote).
So I sympathize with the desire to remove the quotes, as they look bad
and are obviously not too rare. But I'd like to find a solution which
maintains a better visual separation between the subject and the other
text than simply removing them.
-Peff
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-25 23:39 UTC (permalink / raw)
To: Miklos Vajna
Cc: Michael J Gruber, Git Mailing List, Fabian Seoane,
Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <20081125204108.GF4746@genesis.frugalware.org>
On Tue, Nov 25, 2008 at 9:41 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Nov 25, 2008 at 06:31:41PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> I don't know, I just noticed that turning on rename and copy detection
>> makes git-fast-import crash, which shouldn't happen either. Something's
>> not right here. CC'ing the authors of im- and export.
>
> Could you please write a testcase that reproduces your problem?
>
>> Why export|import directly to git?
>
> I guess he did not know about filter-branch. :)
I know about filter-branch (but I am not sure it can do what I want).
I made a mistake of not explaining what I want, instead I suggested (a
possibly wrong) solution. I want to export the whole git repository as
a set of human readable patches, that can be assembled back into a git
repository (with the same hashes as the original one) if needed. The
reason I want that is that if we later decide to switch to another
VCS, we have all the information to reproduce the repository. Another
reason is to be sure that we know all the sources that are needed to
construct the repository, e.g. that there are no binary blobs
(possibly containing malicious code). Another reason I want that is to
be able to rewrite the history, in particular, we have one Mercurial
repository with some old history and another Mercurial history with a
newer history and I just want to concatenate them together into one
git repository.
In each case I know several workarounds, but if there is a way to just
convert the whole git repository into a set of patches and (and be
able to convert everything back including the same hashes), then it'd
be awesome.
See also this thread why people want this (and I assumed git can do
this from this thread):
http://groups.google.com/group/sage-devel/browse_thread/thread/7b116d902ee20d9c/
Thanks,
Ondrej
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-25 23:44 UTC (permalink / raw)
To: Michael J Gruber
Cc: Git Mailing List, Fabian Seoane, Shawn O. Pearce,
Johannes Schindelin
In-Reply-To: <492C367D.3030209@drmicha.warpmail.net>
On Tue, Nov 25, 2008 at 6:31 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ondrej Certik venit, vidit, dixit 25.11.2008 17:44:
>> Hi,
>>
>> I would like to export our whole git repository to patches, and then
>> reconstruct it again from scratch. Following the man page of "git
>> fast-export":
>>
>> $ git clone git://git.sympy.org/sympy-full-history-20081023.git
>> $ cd sympy-full-history-20081023
>> $ git fast-export --all --export-marks=marks > patches
>> $ cd ..
>> $ mkdir sympy-new
>> $ cd sympy-new
>> $ git init
>> $ git fast-import --export-marks=marks < ../sympy-full-history-20081023/patches
>> git-fast-import statistics:
>> ---------------------------------------------------------------------
>> Alloc'd objects: 25000
>> Total objects: 21355 ( 144 duplicates )
>> blobs : 8009 ( 0 duplicates 4529 deltas)
>> trees : 10627 ( 144 duplicates 9189 deltas)
>> commits: 2719 ( 0 duplicates 0 deltas)
>> tags : 0 ( 0 duplicates 0 deltas)
>> Total branches: 21 ( 26 loads )
>> marks: 1048576 ( 10728 unique )
>> atoms: 726
>> Memory total: 2880 KiB
>> pools: 2098 KiB
>> objects: 781 KiB
>> ---------------------------------------------------------------------
>> pack_report: getpagesize() = 4096
>> pack_report: core.packedGitWindowSize = 33554432
>> pack_report: core.packedGitLimit = 268435456
>> pack_report: pack_used_ctr = 40706
>> pack_report: pack_mmap_calls = 2791
>> pack_report: pack_open_windows = 1 / 2
>> pack_report: pack_mapped = 26177739 / 35513414
>> ---------------------------------------------------------------------
>>
>>
>>
>> However, the repository is very different to the original one. It
>> contains only 191 patches:
>>
>> $ git log --pretty=oneline | wc -l
>> 191
>>
>> and it only contains couple files. Compare this with the original repository:
>>
>> $ git log --pretty=oneline | wc -l
>> 2719
>
> I get the same stats (with the dups) but a perfect rev count, when I use
> git log --all. The reason is that the history in the imported repo is
> disconnected at various places (at tagging commits)! Your command counts
> only the revs backwards to the first "disconnection".
You are right! I didn't know about "git log --all".
>
> So, the real issue is: Why has the result these cuts in the history?
Yes, I would like to know this too. E.g. if it is a problem with our
repository, or a problem in git, or whether it is just not supposed to
work.
> I don't know, I just noticed that turning on rename and copy detection
> makes git-fast-import crash, which shouldn't happen either. Something's
> not right here. CC'ing the authors of im- and export.
>
> BTW: Maybe you can accomplish what you want with different means? Why
> export|import directly to git?
I just answered this in my other email. Basically there are
workarounds, but I would feel safe if I can (correctly) reconstruct
the whole git repository from a human readable patches.
Ondrej
^ permalink raw reply
* Re: [PATCH] Invoke "gc --auto" from git commit
From: Johannes Schindelin @ 2008-11-25 23:57 UTC (permalink / raw)
To: Jean-Luc Herren; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <492C24B9.6090200@gmx.ch>
Hi,
On Tue, 25 Nov 2008, Jean-Luc Herren wrote:
> This feature was lost during the port of git commit to C.
See http://article.gmane.org/gmane.comp.version-control.git/82125
Ciao,
Dscho
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: david @ 2008-11-25 23:53 UTC (permalink / raw)
To: Ondrej Certik
Cc: Miklos Vajna, Michael J Gruber, Git Mailing List, Fabian Seoane,
Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <85b5c3130811251539n6cb175b4p185d37385bf43d1e@mail.gmail.com>
On Wed, 26 Nov 2008, Ondrej Certik wrote:
> On Tue, Nov 25, 2008 at 9:41 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> On Tue, Nov 25, 2008 at 06:31:41PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>>> I don't know, I just noticed that turning on rename and copy detection
>>> makes git-fast-import crash, which shouldn't happen either. Something's
>>> not right here. CC'ing the authors of im- and export.
>>
>> Could you please write a testcase that reproduces your problem?
>>
>>> Why export|import directly to git?
>>
>> I guess he did not know about filter-branch. :)
>
> I know about filter-branch (but I am not sure it can do what I want).
> I made a mistake of not explaining what I want, instead I suggested (a
> possibly wrong) solution. I want to export the whole git repository as
> a set of human readable patches, that can be assembled back into a git
> repository (with the same hashes as the original one)
the same hashes on the file is easy, the same hashes on the commits is
extremely hard. which is it that you are looking for.
that being said, the test of being able to do a export|import is a good
one to test that the export format and import format actually match.
David Lang
> if needed. The
> reason I want that is that if we later decide to switch to another
> VCS, we have all the information to reproduce the repository. Another
> reason is to be sure that we know all the sources that are needed to
> construct the repository, e.g. that there are no binary blobs
> (possibly containing malicious code). Another reason I want that is to
> be able to rewrite the history, in particular, we have one Mercurial
> repository with some old history and another Mercurial history with a
> newer history and I just want to concatenate them together into one
> git repository.
>
> In each case I know several workarounds, but if there is a way to just
> convert the whole git repository into a set of patches and (and be
> able to convert everything back including the same hashes), then it'd
> be awesome.
>
> See also this thread why people want this (and I assumed git can do
> this from this thread):
>
> http://groups.google.com/group/sage-devel/browse_thread/thread/7b116d902ee20d9c/
>
> Thanks,
> Ondrej
> --
> 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: git fast-export | git fast-import doesn't work
From: Johannes Schindelin @ 2008-11-26 0:14 UTC (permalink / raw)
To: Ondrej Certik; +Cc: Git Mailing List, Fabian Seoane
In-Reply-To: <85b5c3130811250844u498fbb97m9d1aef6e1397b8c7@mail.gmail.com>
Hi,
On Tue, 25 Nov 2008, Ondrej Certik wrote:
> I would like to export our whole git repository to patches, and then
> reconstruct it again from scratch. Following the man page of "git
> fast-export":
>
> [...]
>
> However, the repository is very different to the original one. It
> contains only 191 patches:
Can you try again with a Git version that contains the commit
2075ffb5(fast-export: use an unsorted string list for extra_refs)?
Ciao,
Dscho
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: Santi Béjar @ 2008-11-26 0:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, git
In-Reply-To: <20081125232521.GC30942@coredump.intra.peff.net>
On Wed, Nov 26, 2008 at 12:25 AM, Jeff King <peff@peff.net> wrote:
[...]
>
> So I sympathize with the desire to remove the quotes, as they look bad
> and are obviously not too rare. But I'd like to find a solution which
> maintains a better visual separation between the subject and the other
> text than simply removing them.
Maybe just use the output of "git branch -v":
master d9a5491 foo: bar
or even literally:
* master d9a5491 [ahead 1] foo: bar
or to make the separation more evident:
[master d9a5491] foo: bar
Santi
^ permalink raw reply
* Re: [PATCH] Invoke "gc --auto" from git commit
From: Jean-Luc Herren @ 2008-11-26 1:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0811260056480.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> On Tue, 25 Nov 2008, Jean-Luc Herren wrote:
>> This feature was lost during the port of git commit to C.
>
> See http://article.gmane.org/gmane.comp.version-control.git/82125
Oh, I missed that. But then the only commands ever invoking git
gc --auto would be git rebase -i, git merge, git svn and git am.
I don't know if some people have repositories where they never use
any of those, but I certainly have repositories where I only ever
use git rebase -i and never any of the other. 'git commit' is
something everyone is bound to use and thus it would be the best
place for running 'git gc --auto'.
As for the performance impact, on my machine 'git gc --auto' runs
500 times per second in a loop on the git repository (it won't
call the hook unless repacking is necessary). I suppose any
script calling git commit in a loop would do substantially more
work than git gc --auto itself. And if that bit of performance
really matters, it could be invoked by git commit only if (rand()
% 20 == 0).
My two cents anyway.
jlh
^ permalink raw reply
* [PATCH] send-email: Fix Pine address book parsing
From: Trent Piepho @ 2008-11-26 2:55 UTC (permalink / raw)
To: git; +Cc: Trent Piepho, gitster
See: http://www.washington.edu/pine/tech-notes/low-level.html
Entries with a fcc or comment field after the address weren't parsed
correctly.
Continuation lines, identified by leading spaces, were also not handled.
Distribution lists which had ( ) around a list of addresses did not have
the parenthesis removed.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
---
git-send-email.perl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94ca5c8..007e2c6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -345,10 +345,13 @@ my %parse_alias = (
# spaces delimit multiple addresses
$aliases{$1} = [ split(/\s+/, $2) ];
}}},
- pine => sub { my $fh = shift; while (<$fh>) {
- if (/^(\S+)\t.*\t(.*)$/) {
+ pine => sub { my $fh = shift; my $f='\t[^\t]*';
+ for (my $x = ''; defined($x); $x = $_) {
+ chomp $x;
+ $x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
+ $x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
$aliases{$1} = [ split(/\s*,\s*/, $2) ];
- }}},
+ }},
gnus => sub { my $fh = shift; while (<$fh>) {
if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
$aliases{$1} = [ $2 ];
--
1.5.4.1
^ permalink raw reply related
* Problem deleting remote branches
From: Jeff Mitchell @ 2008-11-26 4:04 UTC (permalink / raw)
To: git
I'm running into a problem where it seems that you can't delete branches
from a remote WebDAV/HTTP repository (at least, not using the methods
you would use for a git protocol-based repo). It seems to be looking
for the wrong ref head.
Here's a log of running the commands against github, using the native
git protocol:
$ git checkout --track -b gittest jefferai
Branch gittest set up to track local branch refs/heads/jefferai.
Switched to a new branch "gittest"
$ git push origin gittest
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:jefferai/portage.git
* [new branch] gittest -> gittest
$ git checkout jefferai
Switched to branch "jefferai"
$ git branch -d -r origin/gittest
Deleted remote branch origin/gittest.
$ git push origin :gittest
To git@github.com:jefferai/portage.git
- [deleted] gittest
Here's the same (near as I could get it) commands against my http-based
server. Note that because of some other weirdness, I delete the local
branch that I push up, then re-fetch it as a remote tracking branch,
then try to do the delete:
$ git checkout --track -b gittest jefferai
Branch gittest set up to track local branch refs/heads/jefferai.
Switched to a new branch "gittest"
$ git push myremote gittest
Fetching remote heads...
refs/
refs/tags/
refs/heads/
updating 'refs/heads/gittest'
from 0000000000000000000000000000000000000000
to a4641f663ae86739b623a4b5bba7b284e5999549
done
Updating remote server info
$ git checkout jefferai
Switched to branch "jefferai"
$ git branch -d gittest
Deleted branch gittest.
$ git fetch myremote
From https://[my,server.com]/amarok
* [new branch] gittest -> myremote/gittest
$ git checkout --track -b gittest myremote/gittest
Branch gittest set up to track remote branch refs/remotes/myremote/gittest.
Switched to a new branch "gittest"
$ git checkout jefferai
Switched to branch "jefferai"
$ git branch -r -d myremote/gittest
Deleted branch gittest.
$ git push myremote :gittest
Fetching remote heads...
refs/
refs/tags/
refs/heads/
fatal: Couldn't get https://[my.server.com]/amarok.git/refs/heads/master
for remote symref
The requested URL returned error: 404
error: failed to push some refs to 'https://[my.server.com]/amarok.git'
Note the third to last line:
Couldn't get https://[my.server.com]/amarok.git/refs/heads/master
On my webserver, in the repository, I have the following in refs/heads:
bookcase amarok.git # ls refs/heads/
gittest jefferai
I do have a "master" branch -- that's where the "jefferai" branch was
spawned from, which the "gittest" branch was spawned from -- but I have
no idea why it's looking for it.
My remote ref for github looks like:
[remote "origin"]
url = git@github.com:jefferai/portage.git
fetch = +refs/heads/*:refs/remotes/origin/*
and my remote ref for my server looks like:
[remote "myremote"]
url = https://[my.server.com]/amarok.git
fetch = +refs/heads/*:refs/remotes/myremote/*
This smells like a bug, unless there's something I'm doing wrong that I
can't figure out.
Help much appreciated.
Thanks,
Jeff
^ permalink raw reply
* Re: [PATCH] send-email: Fix Pine address book parsing
From: Junio C Hamano @ 2008-11-26 4:58 UTC (permalink / raw)
To: Trent Piepho; +Cc: git, gitster
In-Reply-To: <1227668100-5563-1-git-send-email-tpiepho@freescale.com>
Trent Piepho <tpiepho@freescale.com> writes:
> See: http://www.washington.edu/pine/tech-notes/low-level.html
>
> Entries with a fcc or comment field after the address weren't parsed
> correctly.
>
> Continuation lines, identified by leading spaces, were also not handled.
>
> Distribution lists which had ( ) around a list of addresses did not have
> the parenthesis removed.
> + pine => sub { my $fh = shift; my $f='\t[^\t]*';
> + for (my $x = ''; defined($x); $x = $_) {
> + chomp $x;
> + $x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
> + $x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
Hmm, so you chomp each continuation line with /^ +(.*)$/ and concatenate
that to the hold buffer ($x) as long as you see continuation lines,
a non-continuation line that you read ahead is given to the next round
(the third part of for(;;) control), checked if you hit an EOF and then
chomped. Which means the complicated regexp about the parentheses is
applied to a logical single line in $x that does not have any newline in
it, right?
I wonder what this does:
$x .= $1 while (defined($_ = <$fh>) && /^ +(.*)$/);
when you have "a b" in $x and feed " c\n d\ne\n" to it. When it leaves
the loop, you would have "e\n" in $_ for the next round, and "a bcd" (note
that "bcd" becomes one word) in $x, which I suspect may not be what you
want.
But I do not use Pine nor its aliases file.
^ permalink raw reply
* Re: [RFC/PATCH] bisect: teach "skip" to accept special arguments like "A..B"
From: Junio C Hamano @ 2008-11-26 5:42 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, git, H. Peter Anvin
In-Reply-To: <20081123220249.2e7f30a5.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> The current "git bisect skip" syntax is "git bisect skip [<rev>...]"
> so it's already possible to skip a range of revisions using
> something like:
>
> $ git bisect skip $(git rev-list A..B)
>
> where A and B are the bounds of the range we want to skip.
>
> This patch teaches "git bisect skip" to accept:
>
> $ git bisect skip A..B
>
> as an abbreviation for the former command.
Although I fully realize that the established semantics of A..B in git is
bottom-exclusive, top-inclusive, and this suggestion breaks the UI
uniformity by deviating from that convention, I have to wonder if it would
be more useful if you let the bottom commit (A in your example) also be
skipped.
I would suspect that it would be more useful than the "replace" one, but
that is a separate issue.
^ permalink raw reply
* Re: [PATCH] send-email: Fix Pine address book parsing
From: Trent Piepho @ 2008-11-26 5:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod03hyna.fsf@gitster.siamese.dyndns.org>
On Tue, 25 Nov 2008, Junio C Hamano wrote:
> Trent Piepho <tpiepho@freescale.com> writes:
>> See: http://www.washington.edu/pine/tech-notes/low-level.html
>>
>> Entries with a fcc or comment field after the address weren't parsed
>> correctly.
>>
>> Continuation lines, identified by leading spaces, were also not handled.
>>
>> Distribution lists which had ( ) around a list of addresses did not have
>> the parenthesis removed.
>
>> + pine => sub { my $fh = shift; my $f='\t[^\t]*';
>> + for (my $x = ''; defined($x); $x = $_) {
>> + chomp $x;
>> + $x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
>> + $x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
>
> Hmm, so you chomp each continuation line with /^ +(.*)$/ and concatenate
> that to the hold buffer ($x) as long as you see continuation lines,
> a non-continuation line that you read ahead is given to the next round
> (the third part of for(;;) control), checked if you hit an EOF and then
> chomped. Which means the complicated regexp about the parentheses is
> applied to a logical single line in $x that does not have any newline in
> it, right?
Yes. The previous regex would just grab the email address with (\S+)$, but
that's not right. There can be email address with spaces in them, like
"John Doe <jdoe@anon.org>". And the email address isn't always the last
field. So each field has to be put in the regex and \S+ and \s* have to
become [^\t]* and \t to count fields properly. That's why the regex got so
complex.
> I wonder what this does:
>
> $x .= $1 while (defined($_ = <$fh>) && /^ +(.*)$/);
>
> when you have "a b" in $x and feed " c\n d\ne\n" to it. When it leaves
> the loop, you would have "e\n" in $_ for the next round, and "a bcd" (note
> that "bcd" becomes one word) in $x, which I suspect may not be what you
> want.
The tech docs I linked to just say pine continues lines with leading space,
but not how many spaces exactly. From what I can see it appears to usually
use three spaces, but sometimes it uses one space when wrapping a very long
comment field. It also appears to only split lines between whitespace and
non-whitespace. So if "a b c d\n" were to be wrapped, it would be something
like "a b \n c \n d\n". If I didn't eat the leading spaces in the
continuations, it would be re-assembled as "a b c d". This might cause
an address to become "John Doe <jdoe@anon.org>"
^ permalink raw reply
* Re: [PATCH] send-email: Fix Pine address book parsing
From: Junio C Hamano @ 2008-11-26 6:44 UTC (permalink / raw)
To: Trent Piepho; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0811252137250.5161@t2.domain.actdsltmp>
Trent Piepho <tpiepho@freescale.com> writes:
> The tech docs I linked to just say pine continues lines with leading space,
> but not how many spaces exactly.
My reading of the wording "spaces" it uses is that any number. I agree it
is underspecified what would happen to them.
> It also appears to only split lines between whitespace and
> non-whitespace. ...
> ... like "a b \n c \n d\n". If I didn't eat the leading spaces in the
> continuations, it would be re-assembled as "a b c d". This might cause
> an address to become "John Doe <jdoe@anon.org>"
Which would still work. If you had two addresses a and b and smashed them
together into ab on the other hand it wouldn't. That is why I asked.
If you know for sure (e.g. by reading the Pine source) that it only splits
a line at a whitespace to non-whitespace transition, that it keeps the
whitespace at the end of the first line, and that the non-whitespace and
everything after that on the second line (prefixed by extra unspecified
number of spaces as the continuation sign), then I think what you had in
your patch is exactly what we want. I just wanted to make sure you know
what you are doing, as I do not use Pine nor its address book myself.
^ permalink raw reply
* [PATCH (Eek!)] git diff does not honor --no-ext-diff
From: Nazri Ramliy @ 2008-11-26 7:12 UTC (permalink / raw)
To: git
Hello list,
git-diff does not honor the --no-ext-diff option in both cases when the external
diff program is set via diff.external and gitattributes.
Is this intentional? If not the following patch seems to fix it.
I think there must be a cleaner way of fixing this than doing it by
`hand' hence the Eek!
Nazri.
builtin-diff.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 7ceceeb..4ac7e15 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -290,6 +290,19 @@ int cmd_diff(int argc, const char **argv, const
char *prefix)
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
+ /*
+ * Do we have --no-ext-diff and have external diff setup via either
+ * gitconfig or gitattributes, then clear ALLOW_EXTERNAL by hand. Eek.
+ */
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!strcmp(arg, "--"))
+ break;
+ else if (!strcmp(arg, "--no-ext-diff"))
+ DIFF_OPT_CLR(&rev.diffopt, ALLOW_EXTERNAL);
+ }
+
if (nongit)
die("Not a git repository");
argc = setup_revisions(argc, argv, &rev, NULL);
@@ -298,7 +311,6 @@ int cmd_diff(int argc, const char **argv, const
char *prefix)
if (diff_setup_done(&rev.diffopt) < 0)
die("diff_setup_done failed");
}
- DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
^ permalink raw reply related
* Re: git svn rebase creates some commits with empty author, commiter and date fields
From: Peter Kirk @ 2008-11-26 7:36 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20081125220617.GA21644@mayonaise>
On Tuesday 25 November 2008 23:06:17 Eric Wong wrote:
> Weird.
>
> Does this happen on other repositories you may use as well? Do you know
> of any strange hooks or otherwise non-standard setup with the SVN
> server?
This is the only svn server I use with git-svn with, so I don't know if this
would happen on other servers.
About "strange hooks"...there is a pre-commit hook verifying that the
svn:eolstyle is set properly on text files, but since git > 1.6.0 can do
"autoproperties" like svn that has never failed for me. Then there is a post-
commit hook which sends out a commit mail and scans the commit message for
certain commands which trigger the software to be built.
Since that other post I linked was related to the "authors" file, I added a
text file which maps all the svn users to git users, and that works (I can see
the assigned names instead of the svn names for commits that aren't broken),
but it hasn't helped reduce/eliminate the frequency of broken commits.
>
> Which version of the SVN perl bindings are you using?
I am using the SVN perl bindings that came with my distribution (ubuntu), the
version string reads: 1.5.1dfsg1-1ubuntu2, might this be the problem?
Peter
^ permalink raw reply
* Re: [PATCH (Eek!)] git diff does not honor --no-ext-diff
From: Junio C Hamano @ 2008-11-26 7:52 UTC (permalink / raw)
To: Nazri Ramliy; +Cc: git
In-Reply-To: <544dda350811252312u7ef5533bwb20b37640d861487@mail.gmail.com>
"Nazri Ramliy" <ayiehere@gmail.com> writes:
> git-diff does not honor the --no-ext-diff option in both cases when the external
> diff program is set via diff.external and gitattributes.
>
> Is this intentional?
Judging from 72909be (Add diff-option --ext-diff, 2007-06-30), I think
this was intended in the sense that --ext-diff and --no-ext-diff were
meant to be no-op for "diff" itself when they were introduced.
Having said that, I do not know if I agree with the original intention.
It looks more like an oversight that came from focusing only on what a new
behaviour for the "log" family should be, than a logical design decision
to exclude "diff" from this codepath.
Wouldn't this be a better patch?
builtin-diff.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git c/builtin-diff.c w/builtin-diff.c
index 7ceceeb..b90d8bc 100644
--- c/builtin-diff.c
+++ w/builtin-diff.c
@@ -290,6 +290,9 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
+ /* Default to let external be used */
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
+
if (nongit)
die("Not a git repository");
argc = setup_revisions(argc, argv, &rev, NULL);
@@ -298,7 +301,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
if (diff_setup_done(&rev.diffopt) < 0)
die("diff_setup_done failed");
}
- DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
+
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
^ permalink raw reply related
* Re: [PATCH (Eek!)] git diff does not honor --no-ext-diff
From: René Scharfe @ 2008-11-26 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nazri Ramliy, git
In-Reply-To: <7vprkihqk6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "Nazri Ramliy" <ayiehere@gmail.com> writes:
>
>> git-diff does not honor the --no-ext-diff option in both cases when the external
>> diff program is set via diff.external and gitattributes.
>>
>> Is this intentional?
>
> Judging from 72909be (Add diff-option --ext-diff, 2007-06-30), I think
> this was intended in the sense that --ext-diff and --no-ext-diff were
> meant to be no-op for "diff" itself when they were introduced.
>
> Having said that, I do not know if I agree with the original intention.
> It looks more like an oversight that came from focusing only on what a new
> behaviour for the "log" family should be, than a logical design decision
> to exclude "diff" from this codepath.
>
> Wouldn't this be a better patch?
Yes. And feel free to squash in the following. :)
diff --git a/t/t4020-diff-external.sh b/t/t4020-diff-external.sh
index dfe3fbc..ec787b4 100755
--- a/t/t4020-diff-external.sh
+++ b/t/t4020-diff-external.sh
@@ -43,6 +43,13 @@ test_expect_success 'GIT_EXTERNAL_DIFF environment should apply only to diff' '
'
+test_expect_success 'GIT_EXTERNAL_DIFF environment and --no-ext-diff' '
+
+ GIT_EXTERNAL_DIFF=echo git diff --no-ext-diff |
+ grep "^diff --git a/file b/file"
+
+'
+
test_expect_success 'diff attribute' '
git config diff.parrot.command echo &&
@@ -68,6 +75,13 @@ test_expect_success 'diff attribute should apply only to diff' '
'
+test_expect_success 'diff attribute and --no-ext-diff' '
+
+ git diff --no-ext-diff |
+ grep "^diff --git a/file b/file"
+
+'
+
test_expect_success 'diff attribute' '
git config --unset diff.parrot.command &&
@@ -94,6 +108,13 @@ test_expect_success 'diff attribute should apply only to diff' '
'
+test_expect_success 'diff attribute and --no-ext-diff' '
+
+ git diff --no-ext-diff |
+ grep "^diff --git a/file b/file"
+
+'
+
test_expect_success 'no diff with -diff' '
echo >.gitattributes "file -diff" &&
git diff | grep Binary
^ permalink raw reply related
* Re: French git user
From: Nicolas Morey-Chaisemartin @ 2008-11-26 8:02 UTC (permalink / raw)
To: devel; +Cc: Jean-Francois Veillette, git
In-Reply-To: <492C2F2E.2050200@morey-chaisemartin.com>
Nicolas Morey-Chaisemartin a écrit :
> Christian MICHON a écrit :
>
>> On Tue, Nov 25, 2008 at 2:38 PM, Jean-Francois Veillette
>> <jean_francois_veillette@yahoo.ca> wrote:
>>
>>
>>> I'll probably need to do the same here (Montréal, Qc), so if you can share
>>> your slides (or else), that would be nice.
>>>
>>> Merci ! (thanks),
>>>
>>> - jfv
>>>
>>>
>>>
>> you'll need to ask Nicolas. what I did was to provide feedback to his
>> slides only (done).
>> it's up to him to share his work or not.
>>
>>
>>
>
> I'd gladly share it, I just have to check my company policy.
> I asked my boss tonight so I'll get an answer by tomorrow and post it on
> a ftp somewhere, if I can share it
>
> Nicolas
>
> --
> 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
>
>
>
I've been allowed to share my presentation:
http://nicolas.morey-chaisemartin.com/git_tuto.pdf
Please send me any feedback, I'm always glad to imrpove my work.
Regards
Nicolas Morey-Chaisemartin
^ permalink raw reply
* git svn dcommit crashed -- how do I resume?
From: Jens Neuhalfen @ 2008-11-26 8:22 UTC (permalink / raw)
To: git
Hi,
I am using git as a frontend to my SVN-Repository. When I tried to
"git svn dcommit" several changes from my local git-repository, git
crashed (SEGFAULT, AFAIR).
Now I have a working copy (master branch) that points "somewhere in
the past" (at least my files are old). I have a git-svn remote branch
that points to the same SHA1.
$ git branch -a
dokument-zusammenfuehren
* master
git-svn
I cannot dcommit
$ git svn dcommit
Cannot dcommit with a dirty index. Commit your changes first, or
stash them with `git stash'.
at /Users/jens/libexec/git-core/git-svn line 415
And, indeed, the index is dirty.
I am confused (an slightly panicked), because my old commits seem to
be "gone", my WC does not contain the most recent files and there
seems to be no "backup-branch" with my old HEAD.
Any idea, how I might get my data back and how to 'resume' the dead
dcommit? Google did not turn up anything usefull, unfortunally.
BTW: I am currently using git version 1.6.0.rc0.24.gf45e0.dirty.
Jens
^ 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