* Re: Problem with git-svn
From: Pascal Obry @ 2007-12-20 20:33 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20071220183007.GA26767@untitled>
Eric,
> Ah, oops, I was off-by-one with the revision number. But git-svn does
> look to be doing the right thing here, because it followed history into
> /importfromcvs/trunk/ and file.el was part of it.
Yes part of it but before the creation of the /importfromcvs/trunk/ that
was moved later as /trunk/PROJ.
In /importfromcvs/trunk/ there was many projects imported. One per one,
each time moving it into /trunk/PROJ.
If I look at history of /trunk/PROJ:
$ svn log svn+ssh://myserver/trunk/PROJ
The last revision is 45775, so I think git-svn should not look past this
revision. So I'm very surprised by the current behavior and think it is
a bug to import file.el at revision 9458. Note that the workaround for
me is to use:
$ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD
But it would be lot cleaner to have git-svn handling this properly I think.
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] Make git send-email accept $EDITOR with arguments
From: Luciano Rocha @ 2007-12-20 20:32 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git, gitster
In-Reply-To: <1198181646-28632-1-git-send-email-hendeby@isy.liu.se>
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
On Thu, Dec 20, 2007 at 09:14:06PM +0100, Gustaf Hendeby wrote:
<snip>
> I'm not completely satisfied with the problem with embedded spaces,
> but my Perl skills aren't good enough to do anything about it. If
> anyone have any suggestions on how to do it, it would be greatly
> appreciated. None-the-less, even with this shortcoming, I think this
> is a step in the right direction.
>
> git-send-email.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 248d035..47ae77c 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -400,7 +400,7 @@ EOT
> close(C);
>
> my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
> - system($editor, $compose_filename);
> + system((split ' ', $editor), $compose_filename);
That should be enough. Use system("$editor $compose_filename") to use
perl's implicit split or, in case of meta-characters in the string,
external sh -c.
Or always use the shell:
$shell = $ENV{SHELL} || "/bin/sh";
system($shell, "-c", "$editor $compose_filename");
BTW, maybe add a check for the return code?
system(...) == 0 or die "editor failed\n";
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Make git send-email accept $EDITOR with arguments
From: Gustaf Hendeby @ 2007-12-20 20:14 UTC (permalink / raw)
To: git; +Cc: gitster, Gustaf Hendeby
Currently git send-email does not accept $EDITOR with arguments, eg,
emacs -nw, when starting an editor to produce a cover letter. This fixes
this in the simplest way possible, assume all spaces separates either
the command from the first argument, or two arguments. This should
work in most cases, but will break with quoted strings embedded spaces.
An example of a problematic case is when there is a space in the path
to the command.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
---
This is related to the problems recently observed in the built in git
commit and git tag. I guess the behavior of git send-email has been
the same from the start, but having it treat $EDITOR substantially
different from that of git commit and git tag seems like bug or at
least something that should be avoided.
I'm not completely satisfied with the problem with embedded spaces,
but my Perl skills aren't good enough to do anything about it. If
anyone have any suggestions on how to do it, it would be greatly
appreciated. None-the-less, even with this shortcoming, I think this
is a step in the right direction.
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 248d035..47ae77c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -400,7 +400,7 @@ EOT
close(C);
my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
- system($editor, $compose_filename);
+ system((split ' ', $editor), $compose_filename);
open(C2,">",$compose_filename . ".final")
or die "Failed to open $compose_filename.final : " . $!;
--
1.5.4.rc1.3.gc641f
^ permalink raw reply related
* Re: Problem with git-svn
From: Eric Wong @ 2007-12-20 18:30 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <47690031.7090409@obry.net>
Pascal Obry <pascal.obry@gmail.com> wrote:
> Hi Eric,
>
> > Can you show me the output of `svn log -v -r9458 svn+ssh://myserver/'?
>
> $ svn log -v -r9458 svn+ssh://myserver/
> ------------------------------------------------------------------------
> r9458 | (no author) | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 1 line
> Changed paths:
> A /importfromcvs
> A /importfromcvs/branches
> A /importfromcvs/tags
> A /importfromcvs/trunk
>
> New repository initialized by cvs2svn.
> ------------------------------------------------------------------------
>
> > So did svn+ssh://importfromcvs/trunk/file.el at r9458? If so, git-svn
> > is behaving as expected. If not, can you tell me where "file.el" was at
> > r9458?
>
> file.el was not imported at r9458 but at r9459, just after the creation
> of the /importfromcvs directories above.
>
> ------------------------------------------------------------------------
> r9459 | author | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 2 lines
> Changed paths:
> A /importfromcvs/trunk/file.el
>
> Initial revision
>
> ------------------------------------------------------------------------
Ah, oops, I was off-by-one with the revision number. But git-svn does
look to be doing the right thing here, because it followed history into
/importfromcvs/trunk/ and file.el was part of it.
--
Eric Wong
^ permalink raw reply
* Re: Question about git-svn import
From: Jörg Sommer @ 2007-12-20 16:52 UTC (permalink / raw)
To: git list
In-Reply-To: <476A98BB.8000900@obry.net>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
Pascal Obry schrieb am Thu 20. Dec, 17:30 (+0100):
> # Rewrite post/trunk on top of pre/trunk into merged-master
> $ git checkout post/trunk
> $ git checkout -b merged-master
> $ git-filter-branch --tag-name-filter cat --parent-filter "sed -e
> 's/^$/-p $(git rev-parse pre/trunk)/'" merged-master
>
> The problem is that at this point I cannot "git svn rebase". Looks like
> the filter-branch command did break the link between the Subversion
> repository and the git svn one:
>
> $ git svn rebase
> Unable to determine upstream SVN information from working tree history
>
> Is there a way around that ?
According to http://duncan.mac-vicar.com/blog/archives/282 it should help
to do something like:
git update-ref refs/remotes/git-svn master
find -name .rev_db* | xargs rm
I didn't had this problem, because I did a one‐time import.
Bye, Jörg.
--
Die zehn Gebote Gottes enthalten 172 Wörter, die amerikanische
Unabhängigkeitserklärung 300 Wörter, die Verordnung der europäischen
Gemeinschaft über den Import von Karamelbonbons exakt 25911 Wörter.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Commit a series of patches to SVN without rebase
From: Jörg Sommer @ 2007-12-20 16:40 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
Hi,
I've a number of patches in git I want to send to a SVN repository. git
svn dcommit does a rebase after each commit which makes the whole commit
takes very long. Is it possible to skip the rebase? All patches are in
one branch without merges, a simple chain. Is it save to use --no-rebase
in this case?
Bye, Jörg
--
Der Klügere gibt so lange nach bis er der Dumme ist.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Question about git-svn import
From: Pascal Obry @ 2007-12-20 16:30 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git list
In-Reply-To: <20071218153159.GA12549@alea.gnuu.de>
Jörg,
I have at least one remaining problem.
# Import old trunk into pre/master
$ git svn init svn+ssh://myserver --prefix=pre/ --trunk=importfromcvs/trunk
$ git svn fetch --revision=9458:10242
# Import new trunk into post/master
$ git config svn-remote.svn.fetch trunk/PROJ:refs/remotes/post/trunk
$ git svn fetch --revision=11058:11066
# Rewrite post/trunk on top of pre/trunk into merged-master
$ git checkout post/trunk
$ git checkout -b merged-master
$ git-filter-branch --tag-name-filter cat --parent-filter "sed -e
's/^$/-p $(git rev-parse pre/trunk)/'" merged-master
The problem is that at this point I cannot "git svn rebase". Looks like
the filter-branch command did break the link between the Subversion
repository and the git svn one:
$ git svn rebase
Unable to determine upstream SVN information from working tree history
Is there a way around that ?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* git-svn: pulling from local mirror but committing via svn+ssh
From: Mike Frysinger @ 2007-12-20 16:21 UTC (permalink / raw)
To: git
i have local (fast) mirrors of the svn trees i use, so i normally keep
everything pointing at those. when i need to commit, i use `svn
switch --relocate ...` to flip to the svn+ssh master, and then flop
back to the local mirror. it actually works out nicely.
my reading of git-svn(1) seems to indicate that git-svn cant really
handle switching of repository URLs on the fly ?
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
i tried tweaking my .git/config and changing the url to my svn+ssh,
but it seems any modification in the URL just causes errors ...
vapier@G5[ppc] git $ git-svn dcommit
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-svn line 384.
Committing to ...
Unable to determine upstream SVN information from HEAD history
guess i'll have to bite the bullet and just clone the svn+ssh repo :/
(i'm using 1.5.3.7 over here)
-mike
^ permalink raw reply
* Re: Git-to-svn convert
From: Thomas Harning @ 2007-12-20 15:12 UTC (permalink / raw)
To: Andrew McMillan; +Cc: Martin Langhoff, Junio C Hamano, git
In-Reply-To: <1198128721.24580.78.camel@hippy.mcmillan.net.nz>
Andrew McMillan wrote:
> My code is an embarrasingly ugly, gruesome hack, but it (sort of)
> works...
>
> I use it to keep the SVN and CVS trees up to date on Sourceforge for
> DAViCal ( http://rscds.sf.net/ ) from the Git tree.
>
> Cheers,
> Andrew
Where might I find the code? I checked out git.catalyst.net.nz ... but
I couldn't find anything that seemed to be a sync tool... I figure I'd
give it a try before manually rebasing or progressively cherry-picking a
new tree...
^ permalink raw reply
* [PATCH] everyday: replace 'prune' with 'gc --prune'
From: Miklos Vajna @ 2007-12-20 14:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <20071219225618.GA7378@genesis.frugalware.org>
This document is for newcomers, so it's good to mention gc for housekeeping
tasks instead of running prune manually.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/everyday.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index ce7c170..a09c1d9 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -30,8 +30,6 @@ Everybody uses these commands to maintain git repositories.
* gitlink:git-fsck[1] to check the repository for errors.
- * gitlink:git-prune[1] to remove unused objects in the repository.
-
* gitlink:git-repack[1] to pack loose objects for efficiency.
* gitlink:git-gc[1] to do common housekeeping tasks such as
@@ -56,13 +54,13 @@ disk space is wasted by not repacking.
<3> without `-a` repacks incrementally. repacking every 4-5MB
of loose objects accumulation may be a good rule of thumb.
<4> it is easier to use `git gc` than individual housekeeping commands
-such as `prune` and `repack`. This runs `repack -a -d`.
+such as `prune` and `repack`.
Repack a small project into single pack.::
+
------------
$ git repack -a -d <1>
-$ git prune
+$ git gc --prune
------------
+
<1> pack all the objects reachable from the refs into one pack,
@@ -189,7 +187,7 @@ $ git pull <3>
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
$ git reset --hard ORIG_HEAD <6>
-$ git prune <7>
+$ git gc --prune <7>
$ git fetch --tags <8>
------------
+
--
1.5.4.rc0.67.gf9c5-dirty
^ permalink raw reply related
* [PATCH] everyday: replace 'repack' with 'gc'
From: Miklos Vajna @ 2007-12-20 14:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <20071219225618.GA7378@genesis.frugalware.org>
Most users don't want to run git repack manually, so suggest using gc instead.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/everyday.txt | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index a09c1d9..f1993e2 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -30,8 +30,6 @@ Everybody uses these commands to maintain git repositories.
* gitlink:git-fsck[1] to check the repository for errors.
- * gitlink:git-repack[1] to pack loose objects for efficiency.
-
* gitlink:git-gc[1] to do common housekeeping tasks such as
repack and prune.
@@ -43,23 +41,20 @@ Check health and remove cruft.::
------------
$ git fsck <1>
$ git count-objects <2>
-$ git repack <3>
-$ git gc <4>
+$ git gc <3>
------------
+
<1> running without `\--full` is usually cheap and assures the
repository health reasonably well.
<2> check how many loose objects there are and how much
disk space is wasted by not repacking.
-<3> without `-a` repacks incrementally. repacking every 4-5MB
-of loose objects accumulation may be a good rule of thumb.
-<4> it is easier to use `git gc` than individual housekeeping commands
-such as `prune` and `repack`.
+<3> repacks the local repository and performs other housekeeping tasks. Running
+without `--prune` is a safe operation even while other ones are in progress.
Repack a small project into single pack.::
+
------------
-$ git repack -a -d <1>
+$ git gc <1>
$ git gc --prune
------------
+
--
1.5.4.rc0.67.gf9c5-dirty
^ permalink raw reply related
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-20 13:08 UTC (permalink / raw)
To: René Scharfe; +Cc: Alex Riesen, git
In-Reply-To: <476A5DFF.40803@lsrfire.ath.cx>
On Dec 20, 2007 12:20 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Jonathan del Strother schrieb:
> > On Dec 19, 2007 11:23 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> >> Just a shot in the dark: does this patch on top of master make a difference?
> > No luck with that, I'm afraid.
>
> And how is this one?
>
> The first chunk is the same as in the last try -- it guards against commit
> messages ending with a NUL without a prior \n _and_ being followed by a \n
> (in memory which shouldn't be accessed by us at all as it doesn't belong to
> the commit message). I guess that's quite rare.
>
> The second chunk keeps the body offset from being incremented by the for
> loop if we've already found a terminating NUL.
>
> diff --git a/pretty.c b/pretty.c
> index 9db75b4..5b1078b 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)
> if (i == eol) {
> state++;
> /* strip empty lines */
> - while (msg[eol + 1] == '\n')
> + while (msg[eol] == '\n' && msg[eol + 1] == '\n')
> eol++;
> } else if (!prefixcmp(msg + i, "author ")) {
> context->author.off = i + 7;
> @@ -425,6 +425,8 @@ static void parse_commit_header(struct format_commit_context *context)
> context->encoding.len = eol - i - 9;
> }
> i = eol;
> + if (!msg[i])
> + break;
> }
> context->body_off = i;
> context->commit_header_parsed = 1;
>
Winnar!
Yep, that seems to have fixed things. Wonder how I managed to get the
null into the commit message...
^ permalink raw reply
* [PATCH] Remove old generated files from .gitignore.
From: Charles Bailey @ 2007-12-20 13:00 UTC (permalink / raw)
To: git
Some entries in .gitignore are obselete. These should be cleaned up
just for the sake of general tidiness and so that any developers who
have a working tree that was moved forward without a clean know that
they have old stuff in their work tree.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
.gitignore | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/.gitignore b/.gitignore
index dab5bc2..7f8421d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,7 +41,6 @@ git-fetch
git-fetch--tool
git-fetch-pack
git-filter-branch
-git-findtags
git-fmt-merge-msg
git-for-each-ref
git-format-patch
@@ -59,7 +58,6 @@ git-index-pack
git-init
git-init-db
git-instaweb
-git-local-fetch
git-log
git-lost-found
git-ls-files
@@ -120,10 +118,6 @@ git-show
git-show-branch
git-show-index
git-show-ref
-git-ssh-fetch
-git-ssh-pull
-git-ssh-push
-git-ssh-upload
git-stash
git-status
git-stripspace
--
1.5.4.rc0
^ permalink raw reply related
* Re: Serious bug with pretty format strings & empty bodies?
From: Johannes Schindelin @ 2007-12-20 12:37 UTC (permalink / raw)
To: René Scharfe; +Cc: Jonathan del Strother, Alex Riesen, git
In-Reply-To: <476A5DFF.40803@lsrfire.ath.cx>
Hi,
On Thu, 20 Dec 2007, Ren? Scharfe wrote:
> The second chunk keeps the body offset from being incremented by the for
> loop if we've already found a terminating NUL.
Ah! I missed that one *writethisdownintothebook*
Thanks,
Dscho
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: Johannes Schindelin @ 2007-12-20 12:34 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: René Scharfe, Alex Riesen, git
In-Reply-To: <57518fd10712200338m19c1def9n747dc9353ae41615@mail.gmail.com>
Hi,
On Thu, 20 Dec 2007, Jonathan del Strother wrote:
> I ended up trying to filter-branch my repository, see if I could come
> up with a version stripped of all our private code, suitable for
> making public. Disappointingly, filter-branch magically fixes all the
> commits, even when simply run as "git filter-branch HEAD".
>
> However, looking at the rewritten repository vs the original, they
> share a lot of commits, then diverge halfway through their history. I
> can't see anything notable about the commit where they diverge, with
> the exception that the rewritten commit has a newline after the
> subject and the original doesn't. Neither has a commit message body.
I do not see how Rene's patch could _not_ have fixed that problem.
As it is, I cannot even reproduce without that patch. This is what I was
trying:
-- snip --
diff --git a/t/t4025-pretty-format.sh b/t/t4025-pretty-format.sh
new file mode 100644
index 0000000..2826bcb
--- /dev/null
+++ b/t/t4025-pretty-format.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+test_description='git pretty formats'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ : > file &&
+ git add file &&
+ tree=$(git write-tree) &&
+ commit=$(echo No newlin | tr "\\012" e | git commit-tree $tree) &&
+ git update-ref HEAD $commit
+
+'
+
+test_expect_success 'format:%b' '
+
+ test -z "$(git log -1 --pretty=format:%b)"
+
+'
+
+test_done
-- snap --
Seems I cannot help any more, but at least this is a starting point to
try to reproduce.
Ciao,
Dscho
^ permalink raw reply related
* Re: gitk font configuration
From: Charles Bailey @ 2007-12-20 12:26 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712201318270.27181@ds9.cixit.se>
On Thu, Dec 20, 2007 at 01:19:54PM +0100, Peter Karlsson wrote:
> Hi!
>
> I can configure git gui's fonts through its preferences, but gitk does
> not have font settings. And I can't find any documentation on how to
> change the fonts either in the gitk or git-config manual pages. Is
> there any way to change them? I'd really love getting rid of Courier...
gitk creates a .gitk file in your home directory. If you point your
editor at that file it should be fairly obvious how to change the
fonts.
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: René Scharfe @ 2007-12-20 12:20 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alex Riesen, git
In-Reply-To: <57518fd10712200244o656c7f44j426cc71c89515de3@mail.gmail.com>
Jonathan del Strother schrieb:
> On Dec 19, 2007 11:23 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>> Just a shot in the dark: does this patch on top of master make a difference?
> No luck with that, I'm afraid.
And how is this one?
The first chunk is the same as in the last try -- it guards against commit
messages ending with a NUL without a prior \n _and_ being followed by a \n
(in memory which shouldn't be accessed by us at all as it doesn't belong to
the commit message). I guess that's quite rare.
The second chunk keeps the body offset from being incremented by the for
loop if we've already found a terminating NUL.
diff --git a/pretty.c b/pretty.c
index 9db75b4..5b1078b 100644
--- a/pretty.c
+++ b/pretty.c
@@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)
if (i == eol) {
state++;
/* strip empty lines */
- while (msg[eol + 1] == '\n')
+ while (msg[eol] == '\n' && msg[eol + 1] == '\n')
eol++;
} else if (!prefixcmp(msg + i, "author ")) {
context->author.off = i + 7;
@@ -425,6 +425,8 @@ static void parse_commit_header(struct format_commit_context *context)
context->encoding.len = eol - i - 9;
}
i = eol;
+ if (!msg[i])
+ break;
}
context->body_off = i;
context->commit_header_parsed = 1;
^ permalink raw reply related
* gitk font configuration
From: Peter Karlsson @ 2007-12-20 12:19 UTC (permalink / raw)
To: git
Hi!
I can configure git gui's fonts through its preferences, but gitk does
not have font settings. And I can't find any documentation on how to
change the fonts either in the gitk or git-config manual pages. Is
there any way to change them? I'd really love getting rid of Courier...
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Draft release notes for 1.5.4 as of -rc1
From: Jeff King @ 2007-12-20 12:12 UTC (permalink / raw)
To: Georgi Chorbadzhiyski; +Cc: Junio C Hamano, git
In-Reply-To: <4769DDC9.1030108@unixsol.org>
On Thu, Dec 20, 2007 at 05:13:13AM +0200, Georgi Chorbadzhiyski wrote:
> > * "git peek-remote" is deprecated, as "git ls-remote" was written in C
> > and works for all transports, and will be removed in the future.
>
> For me it is not clear from the above which command will be removed. If
> I understand it correctly probably this should sound better:
>
> * "git peek-remote" is deprecated and will be removed in the future.
> The command was replaced by "git ls-remote" which works for all
> transports.
Agreed. A rewording is in the patch I just sent.
-Peff
^ permalink raw reply
* [PATCH] clean up 1.5.4 release notes
From: Jeff King @ 2007-12-20 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhciers0o.fsf@gitster.siamese.dyndns.org>
Mostly typo and small grammatical fixes with one or two rewordings for
clarity. But note the important fix for status.relativepaths.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/RelNotes-1.5.4.txt | 33 +++++++++++++++++----------------
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index cd79124..4a5d060 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -14,28 +14,28 @@ Removal
Deprecation notices
-------------------
- * Next feature release of git (this change is scheduled for v1.6.0)
+ * The next feature release of git (this change is scheduled for v1.6.0)
will by default install dashed form of commands (e.g. "git-commit")
outside of users' normal $PATH, and will install only selected
commands ("git" itself, and "gitk") in $PATH. This implies:
- - Using dashed form of git commands (e.g. "git-commit") from the
+ - Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
- dashless form (e.g. "git commit") instead.
+ dashless forms (e.g. "git commit") instead.
- - Using dashed from from your scripts, without first prepending the
+ - Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- - Use of dashed form with "PATH=$(git --exec-path):$PATH; export
+ - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Users are strongly encouraged to adjust their habits and scripts now
to prepare for this.
* The post-receive hook was introduced in March 2007 to supersede
- post-update hook, primarily to overcome the command line length
+ the post-update hook, primarily to overcome the command line length
limitation of the latter. Use of post-update hook will be deprecated
in future versions of git, starting from v1.6.0.
@@ -43,10 +43,11 @@ Deprecation notices
option, and will be removed in the future.
* "git peek-remote" is deprecated, as "git ls-remote" was written in C
- and works for all transports, and will be removed in the future.
+ and works for all transports; "git peek-remote" will be removed in
+ the future.
* From v1.6.0, the repack.usedeltabaseoffset config option will default
- to true, which will give denser packfile (i.e. more efficient storage).
+ to true, which will give denser packfiles (i.e. more efficient storage).
The downside is that git older than version 1.4.4 will not be able
to directly use a repository packed using this setting.
@@ -67,7 +68,7 @@ Updates since v1.5.3
* gitk is now merged as a subdirectory of git.git project, in
preparation for its i18n.
- * progress display from many commands are a lot nicer to the eye.
+ * progress displays from many commands are a lot nicer to the eye.
Transfer commands show throughput data.
* many commands that pay attention to per-directory .gitignore now do
@@ -76,12 +77,12 @@ Updates since v1.5.3
* Output processing for '--pretty=format:<user format>' has been
optimized.
- * Rename detection of diff family, while detecting exact matches, has
+ * Rename detection of diff family while detecting exact matches has
been greatly optimized.
- * Rename detection of diff family tries to make more naturally looking
- pairing. Earlier if more than one identical rename sources were
- found in the preimage, they were picked pretty much at random.
+ * Rename detection of diff family tries to make more natural looking
+ pairing. Earlier, if multiple identical rename sources were
+ found in the preimage, the source used was picked pretty much at random.
* Value "true" for color.diff and color.status configuration used to
mean "always" (even when the output is not going to a terminal).
@@ -114,7 +115,7 @@ Updates since v1.5.3
* "git rebase --interactive" mode can now work on detached HEAD.
- * Other minor to serious bugs in "git rebase -i" has been fixed.
+ * Other minor to serious bugs in "git rebase -i" have been fixed.
* "git rebase" now detaches head during its operation, so after a
successful "git rebase" operation, the reflog entry branch@{1} for
@@ -245,7 +246,7 @@ Updates since v1.5.3
* The format "git show" outputs an annotated tag has been updated to
include "Tagger: " and "Date: " lines from the tag itself. Strictly
speaking this is a backward incompatible change, but this is a
- reasonable usability fix and people's script shouldn't have been
+ reasonable usability fix and people's scripts shouldn't have been
relying on the exact output from "git show" Porcelain anyway.
* "git cvsexportcommit" learned -w option to specify and switch to the
@@ -281,7 +282,7 @@ Updates since v1.5.3
makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
traditional behaviour to show the full path relative to the top of
the work tree can be had by setting status.relativepaths
- configuration variable to true.
+ configuration variable to false.
* "git blame" kept text for each annotated revision in core needlessly;
this has been corrected.
--
1.5.4.rc1.1095.g7251f
^ permalink raw reply related
* Re: [PATCH v2] builtin-tag.c: allow arguments in $EDITOR
From: Luciano Rocha @ 2007-12-20 12:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712201255510.14355@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
On Thu, Dec 20, 2007 at 12:58:59PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 20 Dec 2007, Luciano Rocha wrote:
>
> > The previous sh version of git-commit evaluated the value of the defined
> > editor, thus allowing arguments.
> >
> > Make the builtin version work the same, by adding an explicit check for
> > arguments in the editor command, and extract them to an additional
> > argument.
>
> Anything wrong with that patch?
>
> http://article.gmane.org/gmane.comp.version-control.git/68444
No, I just missed it in the mailing list. That patch also supports any
number of whitespace/arguments.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] builtin-tag.c: allow arguments in $EDITOR
From: Johannes Schindelin @ 2007-12-20 11:58 UTC (permalink / raw)
To: Luciano Rocha; +Cc: git
In-Reply-To: <20071220095706.GA9685@bit.office.eurotux.com>
Hi,
On Thu, 20 Dec 2007, Luciano Rocha wrote:
> The previous sh version of git-commit evaluated the value of the defined
> editor, thus allowing arguments.
>
> Make the builtin version work the same, by adding an explicit check for
> arguments in the editor command, and extract them to an additional
> argument.
Anything wrong with that patch?
http://article.gmane.org/gmane.comp.version-control.git/68444
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Mention git-shell's "cvs" substitution in the RelNotes
From: Johannes Schindelin @ 2007-12-20 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhciers0o.fsf@gitster.siamese.dyndns.org>
git shell became much more powerful for existing CVS setups. Tis is a
benefit that we should not hide from those people who only read release
notes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index cd79124..fb521c3 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -175,7 +175,9 @@ Updates since v1.5.3
* "git remote" learned "rm" subcommand.
- * "git cvsserver" can be run via "git shell".
+ * "git cvsserver" can be run via "git shell". Also, "cvs" is
+ recognized as a synonym for "git cvsserver", so that CVS users
+ can be switched to git just by changing their login shell.
* "git cvsserver" acts more like receive-pack by running post-receive
and post-update hooks.
^ permalink raw reply related
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-20 11:38 UTC (permalink / raw)
To: René Scharfe; +Cc: Alex Riesen, git
In-Reply-To: <4769A7FB.1070904@lsrfire.ath.cx>
I ended up trying to filter-branch my repository, see if I could come
up with a version stripped of all our private code, suitable for
making public. Disappointingly, filter-branch magically fixes all the
commits, even when simply run as "git filter-branch HEAD".
However, looking at the rewritten repository vs the original, they
share a lot of commits, then diverge halfway through their history. I
can't see anything notable about the commit where they diverge, with
the exception that the rewritten commit has a newline after the
subject and the original doesn't. Neither has a commit message body.
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Johannes Schindelin @ 2007-12-20 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dana How, Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <7vr6hirx5l.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 19 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > diff --git a/cache.h b/cache.h
> > index 39331c2..83a2c31 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -225,6 +225,7 @@ extern char *get_index_file(void);
> > extern char *get_graft_file(void);
> > extern int set_git_dir(const char *path);
> > extern const char *get_git_work_tree(void);
> > +extern const char *get_current_prefix(void);
> >
> > #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
> >
> > diff --git a/setup.c b/setup.c
> > index b59dbe7..fb9b680 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -3,6 +3,12 @@
> >
> > static int inside_git_dir = -1;
> > static int inside_work_tree = -1;
> > +static const char *current_prefix;
> > +
> > +const char *get_current_prefix()
> > +{
> > + return current_prefix;
> > +}
>
> Didn't you just make libification harder?
Well, yes.
Actually, no:
- I marked this explicitely not ready for application,
- it is not entirely clear if a libgit.a user would not want to
set a default prefix, and
- I decided that I will not be the only one who tries to make
libification easy. ;-)
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