* Re: [PATCH 2/5] Add git-sequencer documentation
From: Stephan Beyer @ 2008-07-30 12:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.0807261623530.26810@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> > +-B::
> > +--batch::
> > + Run in batch mode. If unexpected user intervention is needed
> > + (e.g. a conflict or the need to run an editor), 'git-sequencer' fails.
>
> Does it abort, or leave a dirty tree?
It aborts.
Perhaps I should make this clear in the docs.
> > +--onto=<base>::
> > + Checkout given commit or branch before sequencing.
> > + If you provide a branch, sequencer will make the provided
> > + changes on the branch, i.e. the branch will be changed.
>
> Whoa, does that mean that
>
> $ git checkout my-private-branch
> $ git sequencer --onto=master
>
> will change _master_?
Exactly.
> > +--continue::
> > + Restart the sequencing process after having resolved a merge conflict.
>
> What about 'edit'? Does it restart the sequencing process after editing a
> file or commit message, too?
Yes. Thanks.
> > +If you nonetheless noticed that you made a mistake, you can
> > +overwrite `.git/sequencer/todo` with `.git/sequencer/todo.old` and
> > +rerun `git sequencer --edit`.
>
> Speaking of "todo": there was an explicit request to change that to
> "git-rebase-todo" for rebase -i, so that syntax highlighting could be
> switched on.
I'd not have a problem with that, though the name "rebase" is not
necessarily correct and the syntax files had to be extended
nevertheless.
> > +-v::
> > +--verbose::
> > + Be more verbose.
>
> More?
Hehe, the note that "more" has to be defined more accurately, has been
removed. But it is still true. ;)
> > +a branch in a way that can cause problems for anyone who already has
> > +a copy of the branch in their repository and tries to pull updates from
> > +you. You should understand the implications of using 'git-sequencer' on
> > +a repository that you share.
>
> How about this instead?
>
> Note that sequencing will rewrite the history of the branch.
It will not necessarily rewrite history of a branch. In case of the
rebase user command, it does, of course.
> This will cause problems if you published the branch prior to
> rewriting the history, as the former tip is no longer an
> ancestor of the new tip.
>
> In other words, if you rewrite an already published branch, users
> that pull from you _will_ get a bogus merge.
Yes, I can take that.
Well, I wanted only a short note and the user command that really
rewrites branches could have a more detailed warning.
> > +'git-sequencer' will usually be called by another git porcelain, like
>
> s/another git procelain/other git programs/
Ok, I use "other git commands", since this wording seems to be the leading
one in other documentation.
> > +TODO FILE FORMAT
> > +----------------
> > +
> > +The TODO file contains basically one instruction per line.
>
> s/basically //
Oh, this is from the times where we included some possible extensions,
like a trailing backslash.
> > +edit <commit>::
> > + Pick a commit and pause the sequencer process to let you
> > + make changes.
> > ++
> > +This is a short form for `pick <commit> and `pause` on separate lines.
>
> It might make sense to explain 'pick' before 'edit', then.
This is kept alphabetically.
When first writing that, I wondered if this makes sense:
a reference-like list should be sorted alphabetically, a tutorial-like
list should have some kind of logical structure.
I do not really care if we prefer this or that one. So I take your
reordering suggestion until somebody complains again :)
> > + --mainline=<n>;;
> > + Allow you to pick merge commits by specifying the
> > + parent number (beginning from 1) to let sequencer
> > + replay the changes relative to the specified parent.
>
> Why is this called "mainline", and not "parent"?
Because git-cherry-pick/git-revert has "--mainline" and I did not want
to rename this.
> > [talking about 'squash']
> >
> > + --collect-signoffs;;
> > + Collect the Signed-off-by: lines of each commit and
> > + add them to the squashed commit message.
> > + (Not yet implemented.)
>
> I really have to wonder how useful that is. Or how correct, for that
> matter.
This is just some kind of squashing Signed-off-by: lines.
It was requested by someone (Paolo?) in the RFC git-sequencer.txt thread.
The behavior is planned like this:
Instead of...
Message of commit 1
Signed-off-by: A
Message of commit 2
Signed-off-by: B
Message of commit 3
Signed-off-by: A
Signed-off-by: C
...the user gets...
Message of commit 1
Message of commit 2
Message of commit 3
Signed-off-by: A
Signed-off-by: B
Signed-off-by: C
using --collect-signoffs and no commit-message-changing options.
With --message="Foo" this will be:
Foo
Signed-off-by: A
Signed-off-by: B
Signed-off-by: C
For me this sounds like making sense and being useful, but I have not yet
digged so deep into the rules of signing off :)
> > + --include-merges;;
> > + Sanity check does not fail if you have merges
> > + between HEAD and <mark>.
>
> It may be a commit, too, right? And why does it make sense to check that
> there are no merges? I mean, it is just as if I did two cherry-picks, the
> second with -n, and then commit --amend it. Can make tons of sense...
I think I mean something different. With "merges" I am talking about
commits having more than one parent.
By this check I want to make sure, that the user really knows what he
does when he wants to squash the ones marked with ~ into one commit.
~~~~~~~~~~~~~
..-A---B---C---D---E---F
/
..-X---Y--
Yet I didn't really care what happens then and perhaps it should be:
..--A---S--F
/
..-X-Y-
In the prototype the squashing is done by soft-resetting to the
squash base and then commit. As I said, I did not really care if
my painted result really happens. In the builtin it will happen :)
> > +Here are some examples that shall ease the start with the TODO
> > +file format.
> > +Make sure you have understood the `pick` and perhaps the `patch` command.
> > +Those will not be explained further.
>
> This sentence is insulting. Strike it.
The "Make sure ..." sentence? It really is insulting?
Do you think it implies the assumption that the user will not grasp
patch/pick easily?
Thanks for your reply and your other notes. (The ones I didn't comment
are just ACKed.)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: H.Merijn Brand @ 2008-07-30 12:14 UTC (permalink / raw)
To: Pieter de Bie; +Cc: git
In-Reply-To: <8B01DD07-7A11-4855-94E6-822D901840E3@ai.rug.nl>
On Wed, 30 Jul 2008 14:03:59 +0200, Pieter de Bie <pdebie@ai.rug.nl>
wrote:
>
> On 30 jul 2008, at 13:38, H.Merijn Brand wrote:
>
> > I've talked about this with Arjen, and he suggested to put it here.
> > Please Cc me too, as I have little time to follow this quite busy
> > list.
> >
> > Suggestion
> >
> > Add a new command: 'git-hist' that will show a blame log of a
> > single file with each line `tagged' with the most recent tag
> > plus the number of changes since that tag.
>
> You can do something almost similar with a command like:
>
> git blame -l Makefile | git name-rev --stdin --tags
Very noisy compared to my script, but it indeed comes close to what I
need. This lacks the overview.
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: Pieter de Bie @ 2008-07-30 12:03 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20080730133859.368bbd92@pc09.procura.nl>
On 30 jul 2008, at 13:38, H.Merijn Brand wrote:
> I've talked about this with Arjen, and he suggested to put it here.
> Please Cc me too, as I have little time to follow this quite busy
> list.
>
> Suggestion
>
> Add a new command: 'git-hist' that will show a blame log of a
> single file with each line `tagged' with the most recent tag
> plus the number of changes since that tag.
You can do something almost similar with a command like:
git blame -l Makefile | git name-rev --stdin --tags
- Pieter
^ permalink raw reply
* Re: German translation of git man pages
From: Matthias Kestenholz @ 2008-07-30 11:55 UTC (permalink / raw)
To: Fabio Scotoni; +Cc: git
In-Reply-To: <1217408012.9486.13.camel@hydra.esse.ch>
On Wed, 2008-07-30 at 10:53 +0200, Fabio Scotoni wrote:
> Hello,
>
> I'm currently trying to translate the git man pages into german, as some
> of my co-developers want to stick with svn. Of course, I could use
> git-svn, but it's not what i want. Our svn server crashed two times and
> we lost the history two times.
>
> Our native language is german and they don't like to read english
> documentation. I already started translating but have some problems:
> Should i translate "branch" with the appropriate german word or keep it
> english? This is a Problem for "pull" "push" and the other actions as
> well. Basically it's possible to copy words, but that isn't very
> esthetical.
There was a long discussion some months ago on this list concering the
localization of git-gui into german. Maybe you'll find some inspiration
here:
http://git.kernel.org/?p=git/git.git;a=blob;f=git-gui/po/de.po;hb=HEAD
It would probably be very worthwile to follow the translations there
because users of git-gui will feel at home at once instead of having to
re-learn things.
Matthias
^ permalink raw reply
* Feature suggestion: git-hist
From: H.Merijn Brand @ 2008-07-30 11:38 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 6480 bytes --]
I've talked about this with Arjen, and he suggested to put it here.
Please Cc me too, as I have little time to follow this quite busy list.
Suggestion
Add a new command: 'git-hist' that will show a blame log of a
single file with each line `tagged' with the most recent tag
plus the number of changes since that tag.
Relationale.
Coming from SCCS, each file `keeps' a version in a keyword like
%R%.%L% which is included in the file when a release is made.
The unix command 'what' will show all SCCS id's when used on a
object, like
% what probev | head -10
probev:
$Revision: 92453-07 linker linker crt0.o B.11.60 070209$
probev.ic 5.27 [07/11/14]
Make info: HP-UX B.11.00 9000/800; 14 Jul 2008, 14:52; v04.3.6.04:v82BC anrs.ic 5.5 [07/04/10]
arsmon.ic 5.19 [08/07/09]
controle.ic 5.40 [2008-03-18]
goedmut.ic 5.19 [07/05/16]
gvh.ic 5.8 [06/06/13]
inw.ic 5.8 [06/06/12]
All software has bugs, so has ours, and we ship updates, just as
git makes updates available to the world. I just updated to the
most recent 1.5.6.4.
We make our updates available to our customers, but they
sometimes wait weeks or months to install the updates, but still
complain about bugs that already have been fixed and for which
they already received an update.
I can ask them what version they have, and I can then check if
the complaint was already addressed in an update that was
already released. In SCCS this was easy: they tell me the output
of the what command, I check if the bug was fixed in a newer
version and the answer is present. No such luck in git, as the
stamps are (non-sequitive) SHA id's. As we moved to git, we now
have to update those id's by hand, as the customers are used to
it. (At least we can now use readable date formats)
Implementation
Attached is my perl script git-hist, which is how I currently
use it, which will show the blame log of a file, with each line
prefixed with the tag plus changes since. So I can tell that if
the customer runs release version 0.34, the line in question has
been added before or after.
* Tag all releases with a version number like 5.10.0 or
5.10.1-RC2
(give or take the annoying quircks that git refuses some characters
in tag names, which changed without warning in the 1.5.x track so
I had to manually rename all my 'v 0.53' tags to loose the space)
* Count changes since last tag
# git-hist *pm | perl -ne'63..83 and print'
09d4472 2007-12-06 13:25:58 63: allow_loose_quotes => 0,
09d4472 2007-12-06 13:25:58 64: allow_loose_escapes => 0,
09d4472 2007-12-06 13:25:58 65: allow_whitespace => 0,
caf4798 2008-02-19 17:56:36 0.34 + 004 66: blank_is_undef => 0,
09d4472 2007-12-06 13:25:58 67: verbatim => 0,
09d4472 2007-12-06 13:25:58 68: types => undef,
09d4472 2007-12-06 13:25:58 69:
8648db0 2008-03-27 18:37:54 0.37 + 002 70:
09d4472 2007-12-06 13:25:58 71: _EOF => 0,
09d4472 2007-12-06 13:25:58 72: _STATUS => undef,
09d4472 2007-12-06 13:25:58 73: _FIELDS => undef,
09d4472 2007-12-06 13:25:58 74: _FFLAGS => undef,
09d4472 2007-12-06 13:25:58 75: _STRING => undef,
09d4472 2007-12-06 13:25:58 76: _ERROR_INPUT => undef,
2b95026 2008-04-04 11:10:09 0.37 + 006 77: _COLUMN_NAMES => undef,
ce53d02 2008-04-06 00:40:26 0.37 + 016 78: _BOUND_COLUMNS => undef,
09d4472 2007-12-06 13:25:58 79: );
caf4798 2008-02-19 17:56:36 0.34 + 004 80: my $last_new_err = "";
09d4472 2007-12-06 13:25:58 81:
09d4472 2007-12-06 13:25:58 82: sub new
09d4472 2007-12-06 13:25:58 83: {
Or for a perl file
# git-hist xsutils.c | perl -ne'30..50 and print'
02ca0a6 2005-04-21 17:38:30 perl-5.9.2 + 104 30: PERL_XS_EXPORT_C void XS_attributes_bootstrap(pTHX_ CV *cv);
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 31:
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 32:
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 33: /*
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 34: * Note that only ${pkg}::bootstrap definitions should go here.
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 35: * This helps keep down the start-up time, which is especially
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 36: * relevant for users who don't invoke any features which are
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 37: * (partially) implemented here.
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 38: *
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 39: * The various bootstrap definitions can take care of doing
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 40: * package-specific newXS() calls. Since the layout of the
2136f35 2000-02-04 05:58:57 perl-5.005 + 2832 41: * bundled *.pm files is in a version-specific directory,
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 42: * version checks in these bootstrap calls are optional.
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 43: */
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 44:
02d011f 2006-05-02 19:46:38 perl-5.9.3 + 950 45: static const char file[] = __FILE__;
02d011f 2006-05-02 19:46:38 perl-5.9.3 + 950 46:
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 47: void
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 48: Perl_boot_core_xsutils(pTHX)
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 49: {
d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 50: newXS("attributes::bootstrap", XS_attributes_bootstrap, file);
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
[-- Attachment #2: git-hist --]
[-- Type: application/octet-stream, Size: 1102 bytes --]
#!/pro/bin/perl
# git-hist file ...
# (c) 2008 H.Merijn Brand for PROCURA B.V.
use strict;
use warnings;
sub pr_time
{
my @d = @_;
sprintf "%4d-%02d-%02d %02d:%02d:%02d", 1900 + $d[5], ++$d[4], @d[3,2,1,0];
} # pr_time
my @hsh;
my %log;
{ local @ARGV = ("git-log --pretty=format:'%h %ct %s' |");
while (<>) {
my ($hsh, $time, $text) = (m/^(\S+)\s+([0-9]+)\s+(.*)/);
push @hsh, $hsh;
$log{$hsh} = [ "", $text, pr_time localtime $time ];
}
}
{ local @ARGV = ("git-show-ref --tags |");
while (<>) {
m{(\S{7}).*/(.*)} or next;
$log{$1}[0] = $2;
}
}
{ my $tag = "";
my $inc;
foreach my $hsh (reverse @hsh) {
if ($log{$hsh}[0]) {
$tag = $log{$hsh}[0];
$inc = "001";
}
elsif ($tag) {
$log{$hsh}[0] = sprintf "%-13s + %s", $tag, $inc++;
}
}
}
foreach my $file (@ARGV) {
open my $blame, "-|", "git-blame $file" or next;
while (<$blame>) {
my ($hsh, $lnr, $txt) =
m/^\^?([0-9a-f]{7}).*?\s+([0-9]+)\)(.*)/ or next;
printf "%.7s %s %-20s %5d:%s\n",
$hsh, $log{$hsh}[2], $log{$hsh}[0], $lnr, $txt;
}
}
^ permalink raw reply
* Re: German translation of git man pages
From: Mark Struberg @ 2008-07-30 11:21 UTC (permalink / raw)
To: Fabio Scotoni, Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730110602.GB20957@cuci.nl>
My personal opinion:
don't translate termini technici in technical documentations, but add a translated explanation of each in the preamble.
I've never read any german book or comment where e.g. 'a commit' has been translated to 'das Uebergebene'...
(Reminds me of some old Siemens BS2000 mainfraims back in the 80s. They translated really ALL terms to german, which was frankly completely unreadable)
LieGrü,
strub
--- Stephen R. van den Berg <srb@cuci.nl> schrieb am Mi, 30.7.2008:
> Von: Stephen R. van den Berg <srb@cuci.nl>
> Betreff: Re: German translation of git man pages
> An: "Fabio Scotoni" <fabio@esse.ch>
> CC: git@vger.kernel.org
> Datum: Mittwoch, 30. Juli 2008, 13:06
> Fabio Scotoni wrote:
> >Our native language is german and they don't like
> to read english
> >documentation. I already started translating but have
> some problems:
> >Should i translate "branch" with the
> appropriate german word or keep it
> >english? This is a Problem for "pull"
> "push" and the other actions as
> >well. Basically it's possible to copy words, but
> that isn't very
> >esthetical.
>
> A good translation will translate those words. However,
> since the
> commandline interface uses the English words, you'll be
> forced to
> re-explain that relationship a lot of times (using
> parenthesis, most
> likely).
__________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com
^ permalink raw reply
* [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Steve Haslam @ 2008-07-30 11:27 UTC (permalink / raw)
To: git; +Cc: Steve Haslam
If the user specified the full path to git-upload-pack as the -u option to
"git clone" when cloning a remote repository, and git was not on the default
PATH on the remote machine, git-upload-pack was failing to exec
git-pack-objects.
By making the argv[0] path (if any) available to setup_path(), this will
allow finding the "git" executable in the same directory as
"git-upload-pack". The default built in to exec_cmd.c is to look for "git"
in the ".../libexec/git-core" directory, but it is not installed there (any
longer).
Much the same applies to invoking git-receive-pack from a non-PATH location
using the "--exec" argument to "git push". Since both commands require the
same treatment, a single function has been added in exec_cmd.c to serve both.
Signed-off-by: Steve Haslam <shaslam@lastminute.com>
---
exec_cmd.c | 15 +++++++++++++--
exec_cmd.h | 2 +-
git.c | 20 +++++---------------
receive-pack.c | 3 +++
upload-pack.c | 3 +++
5 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index ce6741e..a2a6a0d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -17,9 +17,20 @@ const char *system_path(const char *path)
return path;
}
-void git_set_argv0_path(const char *path)
+const char *git_extract_argv0_path(const char *argv0)
{
- argv0_path = path;
+ const char *slash = argv0 + strlen(argv0);
+
+ do
+ --slash;
+ while (slash >= argv0 && !is_dir_sep(*slash));
+
+ if (slash >= argv0) {
+ argv0_path = xstrndup(argv0, slash - argv0);
+ return slash + 1;
+ }
+
+ return argv0;
}
void git_set_argv_exec_path(const char *exec_path)
diff --git a/exec_cmd.h b/exec_cmd.h
index 594f961..392e903 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,7 +2,7 @@
#define GIT_EXEC_CMD_H
extern void git_set_argv_exec_path(const char *exec_path);
-extern void git_set_argv0_path(const char *path);
+extern const char* git_extract_argv0_path(const char *path);
extern const char* git_exec_path(void);
extern void setup_path(void);
extern const char **prepare_git_cmd(const char **argv);
diff --git a/git.c b/git.c
index 37b1d76..b1eff4a 100644
--- a/git.c
+++ b/git.c
@@ -416,23 +416,13 @@ static void execv_dashed_external(const char **argv)
int main(int argc, const char **argv)
{
- const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help";
- char *slash = (char *)cmd + strlen(cmd);
+ const char *cmd;
int done_alias = 0;
- /*
- * Take the basename of argv[0] as the command
- * name, and the dirname as the default exec_path
- * if we don't have anything better.
- */
- do
- --slash;
- while (cmd <= slash && !is_dir_sep(*slash));
- if (cmd <= slash) {
- *slash++ = 0;
- git_set_argv0_path(cmd);
- cmd = slash;
- }
+ if (argv[0] && *argv[0])
+ cmd = git_extract_argv0_path(argv[0]);
+ else
+ cmd = "git-help";
/*
* "git-xxxx" is the same as "git xxxx", but we obviously:
diff --git a/receive-pack.c b/receive-pack.c
index d44c19e..3699b16 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -467,6 +467,9 @@ int main(int argc, char **argv)
int i;
char *dir = NULL;
+ if (argv[0] && *argv[0])
+ git_extract_argv0_path(argv[0]);
+
argv++;
for (i = 1; i < argc; i++) {
char *arg = *argv++;
diff --git a/upload-pack.c b/upload-pack.c
index c911e70..086eff6 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -616,6 +616,9 @@ int main(int argc, char **argv)
int i;
int strict = 0;
+ if (argv[0] && *argv[0])
+ git_extract_argv0_path(argv[0]);
+
for (i = 1; i < argc; i++) {
char *arg = argv[i];
--
1.5.6.3
^ permalink raw reply related
* Re: German translation of git man pages
From: Stephen R. van den Berg @ 2008-07-30 11:06 UTC (permalink / raw)
To: Fabio Scotoni; +Cc: git
In-Reply-To: <1217408012.9486.13.camel@hydra.esse.ch>
Fabio Scotoni wrote:
>Our native language is german and they don't like to read english
>documentation. I already started translating but have some problems:
>Should i translate "branch" with the appropriate german word or keep it
>english? This is a Problem for "pull" "push" and the other actions as
>well. Basically it's possible to copy words, but that isn't very
>esthetical.
A good translation will translate those words. However, since the
commandline interface uses the English words, you'll be forced to
re-explain that relationship a lot of times (using parenthesis, most
likely).
--
Sincerely,
Stephen R. van den Berg.
How many weeks are there in a lightyear?
^ permalink raw reply
* German translation of git man pages
From: Fabio Scotoni @ 2008-07-30 8:53 UTC (permalink / raw)
To: git
Hello,
I'm currently trying to translate the git man pages into german, as some
of my co-developers want to stick with svn. Of course, I could use
git-svn, but it's not what i want. Our svn server crashed two times and
we lost the history two times.
Our native language is german and they don't like to read english
documentation. I already started translating but have some problems:
Should i translate "branch" with the appropriate german word or keep it
english? This is a Problem for "pull" "push" and the other actions as
well. Basically it's possible to copy words, but that isn't very
esthetical.
And would there be interest in this project?
With best regards,
Fabio Scotoni
^ permalink raw reply
* git blame not respecting --find-copies-harder ?
From: Stephen R. van den Berg @ 2008-07-30 9:39 UTC (permalink / raw)
To: Git Mailinglist
git clone git://git.cuci.nl/pike
Both of this "git blame" commands return the same (erroneous) results
at the end of the files (the last lines are older, and are from the old
README file next to it).
git blame README-CVS
git blame --find-copies-harder README-CVS
However, when using git show with and without --find-copies-harder, we
see that git indeed finds the copy with a 76% similarity index.
git show 9eb55816
git show --find-copies-harder 9eb55816
Shouldn't it be expected that blame should also give the same difference
in result with and without that option?
On a related note, it doesn't seem possible to make --find-copies-harder
a default; is that intentional?
--
Sincerely,
Stephen R. van den Berg.
How many weeks are there in a lightyear?
^ permalink raw reply
* Re: [ANNOUNCE] GitStats development finished (WRT GSoC)
From: Sverre Rabbelier @ 2008-07-30 9:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailinglist, Johannes Schindelin, Jakub Narebski,
David Symonds, Shawn O. Pearce, Sam Vilain
In-Reply-To: <7vabfz97fl.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 30, 2008 at 09:07, Junio C Hamano <gitster@pobox.com> wrote:
> Can't wait running this, especially in conjunction with the "author" stuff
> ;-)
Hehe, don't expect too much of it yet though (the 'bug' module that
is), there won't be any "99% of the bugs come from Dscho" yet :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Alexander Gavrilov @ 2008-07-30 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7v7ib4hdpu.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 29, 2008 at 8:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Alexander Gavrilov <angavrilov@gmail.com> writes:
>> ++
>> +Note that these options were always accepted by git-fast-export,
>> +but before a certain version it silently produced wrong results.
>> +You should always check the git version before using them.
>> +
>
> I do not quite follow the mention of "before a certain version", but I
> think it is talking about the earlier "fast-export" that took any diff
> options but did not act differently upon renamed/copied entries. If that
> is the case, I think we can say something like this instead:
>
> Note that earlier versions of this command did not complain and
> produced incorrect results if you gave these options.
>
> because docs always talk about the current version. My reading of Dscho's
> original 'show_filemodify' suggests me that "wrong results" does not just
> mean missing rename/copy information but a renamed old entity did not get
> removed correctly, resulting in an incorrect tree in the commit, right?
> Maybe we would want to be a bit more explicit about what kind of breakage
> you are talking about here.
Yes, broken renames is what I've been thinking of when I wrote that.
As fast-export is mainly meant to be used by third-party conversion
scripts, which are not bundled together with git, unsuspecting users
might try to run them using an old git version. The main point of my
note is that scripts should always check the version if they want to
use these options. It probably should also specify the exact value to
compare to, e.g:
Note that before git 1.6 this command did not complain and produced
incorrect results if you gave these options. Your scripts should always
check the version before using them.
> If you see a copied or renamed entry, you emit "this old path to that old
> path" first, and then say that same path got modified. It appears from my
> quick glance of fast-import that touching the same path more than once in
> a same commit like this sequence does would work fine (it will involve two
> calls to tree_content_set() for the same path but that is not something it
> has to forbid, and the function doesn't).
I'm sorry, but I don't quite understand what are you suggesting by
this paragraph. Yes, fast-import understands double modification, and
my test includes a check for this case. Of course, conversion scripts
for dumber targets might need to do one-line lookahead to eliminate
non-100% copies.
>> diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
>> index f18eec9..bb595b7 100755
>> --- a/t/t9301-fast-export.sh
>> +++ b/t/t9301-fast-export.sh
>> @@ -162,4 +162,50 @@ test_expect_success 'submodule fast-export | fast-import' '
>>
>> '
>>
>> +export GIT_AUTHOR_NAME='A U Thor'
>> +export GIT_COMMITTER_NAME='C O Mitter'
>> +
>> +test_expect_success 'setup copies' '
>> +
>> + git config --unset i18n.commitencoding &&
>
> These are somewhat unusual. Was there any reason for these exports and
> config?
>
t9301-fast-export.sh earlier changes these parameters to test
automatic conversion to utf8. I reset them back before my test, in
order to be able to test the import by comparing SHA-1 (encoding
conversion changes it). There may be a better way to do it, though.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Jakub Narebski @ 2008-07-30 8:36 UTC (permalink / raw)
To: Roman Zippel; +Cc: Martin Langhoff, Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807291433430.6791@localhost.localdomain>
Roman Zippel <zippel@linux-m68k.org> writes:
> I don't quite understand what you're trying to say.
> To avoid further confusion it maybe helps to specify a few of the terms:
>
> - full history graph: produced by "git-log --full-history --parents"
> - compact history graph: the full history graph without without any
> repeated merges, this is what my example script produces.
> - full simplified history: output of "git-log --full-history"
> - short simplified history: standard output of "git-log"
[...]
> Keep in mind that e.g. git-web is using the full simplified history, so
> what I'm offering also has the potential to improve git-web performance...
The fact that gitweb is using --full-history for a 'history' view
is a historical reason, backwards compatibility with the view that
was shown before gitweb used "git rev-list [flags] -- <path>", see
commit cdd4037d
gitweb: optimize per-file history generation
The rev-list command that is recent enough can filter commits
based on paths they touch, so use it instead of generating the
full list and limiting it by passing it with diff-tree --stdin.
[jc: The patch originally came from Luben Tuikov but the it was
corrupt, but it was short enough to be applied by hand. I
added the --full-history to make the output compatible with the
original while doing so.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Removing '--parents' was put later, to remove unnecessary merges
from a view (there was long discussion on git mailing list about
--full-history with and without --parents), in 208b2dff
gitweb: We do longer need the --parents flag in rev-list.
We only want to know the direct parents of a given commit object,
these parents are available in the --header output of rev-list. If
--parents is supplied with --full-history the output includes merge
commits that aren't relevant.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Besides gitweb currently does not generate graphical history view,
so '--parents' are unnecessary.
But if it was done from the scratch, gitweb should definitely
use simplified history, instead of what you call "full simplified
history", perhaps with an option to use '--full-history' (there
is infractructure in gitweb for adding extra options).
(Nitpick: it is 'gitweb', not 'git-web'.)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* cvs diff -l equivalent?
From: Stephen R. van den Berg @ 2008-07-30 8:20 UTC (permalink / raw)
To: git
Someone popped this question on me. The closest I got was:
git diff .
But that still recurses. Any solutions without patching?
--
Sincerely,
Stephen R. van den Berg.
How many weeks are there in a lightyear?
^ permalink raw reply
* [PATCH] Fix merge name generation in "merge in C"
From: Junio C Hamano @ 2008-07-30 8:12 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna
When merging an early part of a branch, e.g. "git merge xyzzy~20", we were
supposed to say "branch 'xyzzy' (early part)", but it incorrectly said
"branch 'refs/heads/xy' (early part)" instead.
The logic was supposed to first strip away "~20" part to make sure that
what follows "~" is a non-zero posint, prefix it with "refs/heads/" and
ask resolve_ref() if it is a ref. If it is, then we know xyzzy was a
branch, and we can give the correct message.
However, there were a few bugs. First of all, the logic to build this
"true branch refname" did not count the characters correctly. At this
point of the code, "len" is the number of trailing, non-name part of the
given extended SHA-1 expression given by the user, i.e. number of bytes in
"~20" in the above example.
In addition, the message forgot to skip "refs/heads/" it prefixed from the
output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* It is a bit surprising that after beating merge-in-C to death, we
still find a minor breakage like this.
builtin-merge.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..dde0c7e 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -396,12 +396,12 @@ static void merge_name(const char *remote, struct strbuf *msg)
struct strbuf truname = STRBUF_INIT;
strbuf_addstr(&truname, "refs/heads/");
strbuf_addstr(&truname, remote);
- strbuf_setlen(&truname, len+11);
+ strbuf_setlen(&truname, truname.len - len);
if (resolve_ref(truname.buf, buf_sha, 0, 0)) {
strbuf_addf(msg,
"%s\t\tbranch '%s'%s of .\n",
sha1_to_hex(remote_head->sha1),
- truname.buf,
+ truname.buf + 11,
(early ? " (early part)" : ""));
return;
}
^ permalink raw reply related
* Re: [ANNOUNCE] GitStats development finished (WRT GSoC)
From: Junio C Hamano @ 2008-07-30 7:07 UTC (permalink / raw)
To: sverre
Cc: Git Mailinglist, Johannes Schindelin, Jakub Narebski,
Junio C Hamano, David Symonds, Shawn O. Pearce, Sam Vilain
In-Reply-To: <bd6139dc0807291511v2d70d549r3682291eb10a745d@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> ... As a
> result it is quite clear what GitStats will look like at the end of my
> GSoC. I am going to continue working on it though, I am especially
> interested in getting the '--follow' part of 'git log' working in such
> a way that it can be incorporated into GitStats. As such, here is a
> summary of what GitStat is at the moment. From the documentation:
Wonderful.
> syntax: stats.py bug <options>
>
> The purpose of the bug module is to gather statistics on
> bugfixes within the content, and to aggregate this
> information to provide with a report of the last N commits.
Can't wait running this, especially in conjunction with the "author" stuff
;-)
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Junio C Hamano @ 2008-07-30 6:24 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git
In-Reply-To: <20080730061727.GA1912@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> writes:
> I think it's nice if items in the description exactly match something
> in the synopsis. It gives me more confidence that someone didn't just
> forget to update one or the other.
Yup; queued. Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] builtin-help: make some internal functions available to other builtins
From: Junio C Hamano @ 2008-07-30 6:21 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <a2d2bc675801bb03e3035ec0102eb27f08f27f1b.1217372486.git.vmiklos@frugalware.org>
Thanks; all four patches queued.
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Abhijit Menon-Sen @ 2008-07-30 6:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsj49t27.fsf@gitster.siamese.dyndns.org>
At 2008-07-29 16:20:00 -0700, gitster@pobox.com wrote:
>
> The synopsis talks about the ability for you to specify zero or more
> of whatever is called <refspec>, and here we define what _A_ refspec
> is.
Yes. The thing is, many places say "<refspec>..." both in the synopsis
and in the description (e.g. add, am, apply, commit...), and doing it
differently in some places seems more likely to be confusing than not.
I think it's nice if items in the description exactly match something
in the synopsis. It gives me more confidence that someone didn't just
forget to update one or the other.
(If you've queued the original git-push.txt patch, I'm happy to leave
the others alone, or change them one way or another, as you wish.)
-- ams
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-30 6:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080730061012.GA4437@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Wed, Jul 30, 2008 00:03:44 +0200:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>> >> Alex, I ran the full test with this, but only on Linux boxes; obviously
>> >> not on any flavor of Windows. I think it is correct, and the "first line
>> >> of defence" fix is the same as your patch, so I'd assume it would work for
>> >> you as well. But extra eyeballs are always appreciated.
>> >
>> > Well, it works on Cygwin too. And I had my eyeballs on the code
>> > (wondered first if it will cause more fs accesses than before: it
>> > will, in the racy check. Which is correct, AFAICT)
>>
>> I thought racy check won't even trigger for gitlinks, no?
>>
>
> I didn't know. But now, come to think of it, there wouldn't be much
> point - the gitlinks are always compared by content, aren't they?
>
>> ce_modified_check_fs() has 3 call sites:
>>
>> - the call site in ie_match_stat() is protected with is_racy_timestamp()
>> that is always false for gitlinks;
>>
>> - the call site in ie_modified() we just took care of in the current
>> thread;
>>
>> - the other call site is in ce_smudge_racily_clean_entry(), which is
>> called from write_index() but it also is protected with
>> is_racy_timestamp() that is always false for gitlinks.
>
> So, the change in ce_modified_check_fs is not really needed, because
> the gitlink case is never executed?
That's what I meant by "futureproofing".
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Alex Riesen @ 2008-07-30 6:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyk0bb5r.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Wed, Jul 30, 2008 00:03:44 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
> >> Alex, I ran the full test with this, but only on Linux boxes; obviously
> >> not on any flavor of Windows. I think it is correct, and the "first line
> >> of defence" fix is the same as your patch, so I'd assume it would work for
> >> you as well. But extra eyeballs are always appreciated.
> >
> > Well, it works on Cygwin too. And I had my eyeballs on the code
> > (wondered first if it will cause more fs accesses than before: it
> > will, in the racy check. Which is correct, AFAICT)
>
> I thought racy check won't even trigger for gitlinks, no?
>
I didn't know. But now, come to think of it, there wouldn't be much
point - the gitlinks are always compared by content, aren't they?
> ce_modified_check_fs() has 3 call sites:
>
> - the call site in ie_match_stat() is protected with is_racy_timestamp()
> that is always false for gitlinks;
>
> - the call site in ie_modified() we just took care of in the current
> thread;
>
> - the other call site is in ce_smudge_racily_clean_entry(), which is
> called from write_index() but it also is protected with
> is_racy_timestamp() that is always false for gitlinks.
So, the change in ce_modified_check_fs is not really needed, because
the gitlink case is never executed?
^ permalink raw reply
* Re: [RFC/PATCH v4 1/2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Junio C Hamano @ 2008-07-30 6:00 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin, Miklos Vajna, Jakub Narebski
In-Reply-To: <20080730070414.f7b36eec.chriscool@tuxfamily.org>
Thanks; queued. Perhaps I'll add the test scirpt to demonstrate the
topology in the new documentation myself, and the merge-octupos update I
sent earlier to the list can come on top of this series.
^ permalink raw reply
* [PATCH] format-patch: Produce better output with --inline or --attach
From: Kevin Ballard @ 2008-07-30 5:49 UTC (permalink / raw)
To: git; +Cc: peff, Kevin Ballard, Junio C Hamano
In-Reply-To: <20080730052401.GC4034@sigill.intra.peff.net>
This patch makes two small changes to improve the output of --inline
and --attach.
The first is to write a newline preceding the boundary. This is needed because
MIME defines the encapsulation boundary as including the preceding CRLF (or in
this case, just LF), so we should be writing one. Without this, the last
newline in the pre-diff content is consumed instead.
The second change is to always write the line termination character
(default: newline) even when using --inline or --attach. This is simply to
improve the aesthetics of the resulting message. When using --inline an email
client should render the resulting message identically to the non-inline
version. And when using --attach this adds a blank line preceding the
attachment in the email, which is visually attractive.
Signed-off-by: Kevin Ballard <kevin@sb.org>
---
diff.c | 3 +--
log-tree.c | 2 +-
....format-patch_--attach_--stdout_initial..master | 6 ++++++
...format-patch_--attach_--stdout_initial..master^ | 4 ++++
...ff.format-patch_--attach_--stdout_initial..side | 2 ++
...tdout_--subject-prefix=TESTCASE_initial..master | 6 ++++++
....format-patch_--inline_--stdout_initial..master | 6 ++++++
...format-patch_--inline_--stdout_initial..master^ | 4 ++++
...ormat-patch_--inline_--stdout_initial..master^^ | 2 ++
...ff.format-patch_--inline_--stdout_initial..side | 2 ++
10 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index a07812c..cbf2547 100644
--- a/diff.c
+++ b/diff.c
@@ -3223,11 +3223,10 @@ void diff_flush(struct diff_options *options)
if (output_format & DIFF_FORMAT_PATCH) {
if (separator) {
+ putc(options->line_termination, options->file);
if (options->stat_sep) {
/* attach patch instead of inline */
fputs(options->stat_sep, options->file);
- } else {
- putc(options->line_termination, options->file);
}
}
diff --git a/log-tree.c b/log-tree.c
index 5505606..bd8b9e4 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -198,7 +198,7 @@ void log_write_email_headers(struct rev_info *opt, const char *name,
extra_headers = subject_buffer;
snprintf(buffer, sizeof(buffer) - 1,
- "--%s%s\n"
+ "\n--%s%s\n"
"Content-Type: text/x-patch;"
" name=\"%s.diff\"\n"
"Content-Transfer-Encoding: 8bit\n"
diff --git a/t/t4013/diff.format-patch_--attach_--stdout_initial..master b/t/t4013/diff.format-patch_--attach_--stdout_initial..master
index cf6891f..43346b9 100644
--- a/t/t4013/diff.format-patch_--attach_--stdout_initial..master
+++ b/t/t4013/diff.format-patch_--attach_--stdout_initial..master
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
@@ -122,6 +126,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--attach_--stdout_initial..master^ b/t/t4013/diff.format-patch_--attach_--stdout_initial..master^
index fe02587..d7490a9 100644
--- a/t/t4013/diff.format-patch_--attach_--stdout_initial..master^
+++ b/t/t4013/diff.format-patch_--attach_--stdout_initial..master^
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--attach_--stdout_initial..side b/t/t4013/diff.format-patch_--attach_--stdout_initial..side
index 9ff828e..38f7902 100644
--- a/t/t4013/diff.format-patch_--attach_--stdout_initial..side
+++ b/t/t4013/diff.format-patch_--attach_--stdout_initial..side
@@ -17,6 +17,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master b/t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master
index a8093be..fca5cce 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master
+++ b/t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
@@ -122,6 +126,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..master b/t/t4013/diff.format-patch_--inline_--stdout_initial..master
index aa110c0..6d6fac3 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_initial..master
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
@@ -122,6 +126,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^
index 95e9ea4..18a1110 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
index b8e81e1..4f258b8 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..side b/t/t4013/diff.format-patch_--inline_--stdout_initial..side
index 86ae923..e86dce6 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_initial..side
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..side
@@ -17,6 +17,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
--
1.6.0.rc1.166.gbbfa8
^ permalink raw reply related
* Re: [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
From: Shawn O. Pearce @ 2008-07-30 5:42 UTC (permalink / raw)
To: Murphy, John; +Cc: Abhijit Menon-Sen, git
In-Reply-To: <20080729164856.GB1730@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> "Murphy, John" <john.murphy@bankofamerica.com> wrote:
> > I have rebuilt git-gui with version 0.10.2.18.gc629 it is still not finding gitk.
> > I have done some debugging in proc _which
> > I have found the issue is with the following line:
> >
> > set p [file join $p $what$_search_exe]
> >
> > The variable $p = gitk.exe
> >
> > And there is no such animal
> >
> > When I copy gitk to gitk.exe in /usr/local/git/bin, it works fine.
>
> This is definately a git-gui bug.
And this should fix it.
--8<--
git-gui: Fix gitk search in $PATH to work on Windows
Back in 15430be5a1 ("Look for gitk in $PATH, not $LIBEXEC/git-core")
git-gui learned to use [_which gitk] to locate where gitk's script
is as Git 1.6 will install gitk to $prefix/bin (in $PATH) and all
of the other tools are in $gitexecdir.
This failed on Windows because _which adds the ".exe" suffix as it
searches for the program on $PATH, under the assumption that we can
only execute something from Tcl if it is a proper Windows executable.
When scanning for gitk on Windows we need to omit the ".exe" suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index ce941ad..14b2d9a 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -317,7 +317,7 @@ proc _git_cmd {name} {
return $v
}
-proc _which {what} {
+proc _which {what args} {
global env _search_exe _search_path
if {$_search_path eq {}} {
@@ -340,8 +340,14 @@ proc _which {what} {
}
}
+ if {[is_Windows] && [lsearch -exact $args -script] >= 0} {
+ set suffix {}
+ } else {
+ set suffix $_search_exe
+ }
+
foreach p $_search_path {
- set p [file join $p $what$_search_exe]
+ set p [file join $p $what$suffix]
if {[file exists $p]} {
return [file normalize $p]
}
@@ -1686,7 +1692,7 @@ proc do_gitk {revs} {
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
#
- set exe [_which gitk]
+ set exe [_which gitk -script]
set cmd [list [info nameofexecutable] $exe]
if {$exe eq {}} {
error_popup [mc "Couldn't find gitk in PATH"]
--
1.6.0.rc1.166.gbbfa8
--
Shawn.
^ permalink raw reply related
* Re: [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Steffen Prohaska @ 2008-07-30 5:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
In-Reply-To: <20080730052517.GF7225@spearce.org>
On Jul 30, 2008, at 7:25 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> Isn't only the computation of sharedir based on gitexecdir wrong?
>>
>>> ifndef sharedir
>>> sharedir := $(dir $(gitexecdir))share
>>
>> and could be replaced with this (instead of your patch):
>>
>> ifndef sharedir
>> +ifeq (git-core,$(notdir $(gitexecdir)))
>> + sharedir := $(dir $(patsubst %/,%,$(dir $(gitexecdir))))share
>> +else
>> sharedir := $(dir $(gitexecdir))share
>> endif
>> +endif
>
> Oh, damn good catch. Thanks.
>
> How about this then? Its your patch above, my message, and me
> forging your SOB...
looks good. SOB ok.
Thanks,
Steffen
^ 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