* Re: Gitweb: Provide Git links in project list?
From: Fredrik Skolmli @ 2008-07-30 13:02 UTC (permalink / raw)
To: Robert Richter; +Cc: git
In-Reply-To: <20080730125743.GY15356@erda.amd.com>
On Wed, Jul 30, 2008 at 02:57:43PM +0200, Robert Richter wrote:
> The Gitweb on git.kernel.org povides links to the Git repository for
> each project (git <git://...>). However, I did not find this feature
> in the current implementation of git_project_list_body(). Does
> somebody know if there is a patch available for this and if this could
> be added to gitweb?
Is putting the address in .git/cloneurl giving the behaviour you're looking for?
- F
--
Regards,
Fredrik Skolmli
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: Lars Noschinski @ 2008-07-30 13:33 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20080730133859.368bbd92@pc09.procura.nl>
* H.Merijn Brand <h.m.brand@xs4all.nl> [08-07-30 13:38]:
> 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)
Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?
^ permalink raw reply
* Re: Git Community Book
From: Bart Trojanowski @ 2008-07-30 13:31 UTC (permalink / raw)
To: git list
In-Reply-To: <7v1w1cb940.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [080729 18:48]:
> I'd very strongly second this. If somebody is really into screencasts
> (and especially from the Ruby circle, I would guess), this may be worth
> a look:
>
> http://excess.org/article/2008/07/ogre-git-tutorial/
BTW, if anyone is interested in the SVGs used for the slides...
git clone git://tachyon.jukie.net/intro-to-git.git/
You will need inkscape and latex-beamer to build the PDF.
Feel free to use them as you wish with attribution. Although my may
want to wait till I fix the mistakes that Junio mentioned.
-Bart
--
WebSig: http://www.jukie.net/~bart/sig/
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Fredrik Skolmli @ 2008-07-30 13:29 UTC (permalink / raw)
To: Robert Richter; +Cc: git
In-Reply-To: <20080730131357.GZ15356@erda.amd.com>
On Wed, Jul 30, 2008 at 03:13:57PM +0200, Robert Richter wrote:
> At git.kernel.org there is additional '... | git' with a link to the
> Git repository.
Ah, sorry. I had a look before sending the mail, but apparently missed that
little detail.
--
Regards,
Fredrik Skolmli
^ permalink raw reply
* markdown 2 man, was Re: Git Community Book
From: Johannes Schindelin @ 2008-07-30 13:27 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, Scott Chacon, Petr Baudis, git list
In-Reply-To: <Pine.LNX.4.64.0807291957410.1779@reaper.quantumfyre.co.uk>
Hi,
On Tue, 29 Jul 2008, Julian Phillips wrote:
> there does exist at least one tool that claims to be able
> to convert from markdown to man: http://johnmacfarlane.net/pandoc/
Just want to mention that it is written in Haskell, so chances are that it
is even harder to install than asciidoc (I am thinking about non-Linux,
of course).
Note also that Markdown cannot create TOCs automatically, AFAICT. So
probably it would be not all that easy to convert the User Manual to that
format.
If at all, I would have preferred a format switch to Wiki syntax so that
we can use the same source on the Git wiki as in our Documentation/
directory. But such a switch could only come after a consensus of the
Community anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: Git Community Book
From: Bart Trojanowski @ 2008-07-30 13:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v1w1cb940.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [080729 18:48]:
> I'd very strongly second this. If somebody is really into screencasts
> (and especially from the Ruby circle, I would guess), this may be worth
> a look:
>
> http://excess.org/article/2008/07/ogre-git-tutorial/
Thank you very much for the plug, Junio.
> I saw a couple of technical inaccuracies in the presentation (I do not
> expect any presentation or screencast to be perfect; I've never seen one
> without any technical error anyway, perhaps other than my own at OLS a few
> years ago)
Could you let me know what the biggest inaccuracies were? I would like
to correct my mistakes and update the slides.
Cheers,
-Bart
--
WebSig: http://www.jukie.net/~bart/sig/
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Robert Richter @ 2008-07-30 13:13 UTC (permalink / raw)
To: Fredrik Skolmli; +Cc: git
In-Reply-To: <20080730130257.GB28566@frsk.net>
On 30.07.08 15:02:57, Fredrik Skolmli wrote:
> On Wed, Jul 30, 2008 at 02:57:43PM +0200, Robert Richter wrote:
>
> > The Gitweb on git.kernel.org povides links to the Git repository for
> > each project (git <git://...>). However, I did not find this feature
> > in the current implementation of git_project_list_body(). Does
> > somebody know if there is a patch available for this and if this could
> > be added to gitweb?
>
> Is putting the address in .git/cloneurl giving the behaviour you're looking for?
Yes, I did change this and in the project summary I get "URL git://...".
That I mean is the main page, that lists the projects. I only have:
... summary | shortlog | log | tree
At git.kernel.org there is additional '... | git' with a link to the
Git repository.
The current source of gitweb seems not to provide this.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com
^ permalink raw reply
* Gitweb: Provide Git links in project list?
From: Robert Richter @ 2008-07-30 12:57 UTC (permalink / raw)
To: git
The Gitweb on git.kernel.org povides links to the Git repository for
each project (git <git://...>). However, I did not find this feature
in the current implementation of git_project_list_body(). Does
somebody know if there is a patch available for this and if this could
be added to gitweb?
Thanks,
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com
^ permalink raw reply
* Re: [PATCH] 64bit issue in test-parse-options.c
From: H.Merijn Brand @ 2008-07-30 12:44 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20080730123713.GA31392@artemis.madism.org>
On Wed, 30 Jul 2008 14:37:13 +0200, Pierre Habouzit
<madcoder@debian.org> wrote:
> On Wed, Jul 30, 2008 at 12:16:56PM +0000, H.Merijn Brand wrote:
> > git-1.5.6.4 - HP-UX 11.23 64bit compile
> >
> > * expecting success:
> > test-parse-options -s123 -b -i 1729 -b -vv -n > output 2> output.err &&
> > test_cmp expect output &&
> > test ! -s output.err
> >
> > --- expect 2008-07-30 11:52:05 +0000
> > +++ output 2008-07-30 11:52:05 +0000
> > @@ -1,5 +1,5 @@
> > boolean: 2
> > -integer: 1729
> > +integer: 7425998454784
> > string: 123
> > abbrev: 7
> > verbose: 2
> > * FAIL 2: short options
> >
> > I'm sure you can come up with a more sensible change, but the current
> > code is definitely wrong
> >
> >
> > --8<---
> > --- test-parse-options.c.org 2008-07-30 11:57:16 +0000
> > +++ test-parse-options.c 2008-07-30 12:08:56 +0000
> > @@ -2,6 +2,7 @@
> > #include "parse-options.h"
> >
> > static int boolean = 0;
> > +static unsigned int int_integer = 0;
> > static unsigned long integer = 0;
>
> long is wrong in the first place, parse-opt only uses ints.
If I change it to int, the date parsing goes bogus.
--
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: [PATCH] 64bit issue in test-parse-options.c
From: Pierre Habouzit @ 2008-07-30 12:37 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20080730141656.41ce02ec@pc09.procura.nl>
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]
On Wed, Jul 30, 2008 at 12:16:56PM +0000, H.Merijn Brand wrote:
> git-1.5.6.4 - HP-UX 11.23 64bit compile
>
> * expecting success:
> test-parse-options -s123 -b -i 1729 -b -vv -n > output 2> output.err &&
> test_cmp expect output &&
> test ! -s output.err
>
> --- expect 2008-07-30 11:52:05 +0000
> +++ output 2008-07-30 11:52:05 +0000
> @@ -1,5 +1,5 @@
> boolean: 2
> -integer: 1729
> +integer: 7425998454784
> string: 123
> abbrev: 7
> verbose: 2
> * FAIL 2: short options
>
> I'm sure you can come up with a more sensible change, but the current
> code is definitely wrong
>
>
> --8<---
> --- test-parse-options.c.org 2008-07-30 11:57:16 +0000
> +++ test-parse-options.c 2008-07-30 12:08:56 +0000
> @@ -2,6 +2,7 @@
> #include "parse-options.h"
>
> static int boolean = 0;
> +static unsigned int int_integer = 0;
> static unsigned long integer = 0;
long is wrong in the first place, parse-opt only uses ints.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: German translation of git man pages
From: Stephan Beyer @ 2008-07-30 12:33 UTC (permalink / raw)
To: Fabio Scotoni; +Cc: git
In-Reply-To: <1217408012.9486.13.camel@hydra.esse.ch>
Hi,
Fabio Scotoni wrote:
> Hello,
>
> I'm currently trying to translate the git man pages into german,
[...]
> And would there be interest in this project?
Yes, I think your work can benefit the German git users that are like
your colleagues or that do not understand English properly.
So even if localized manual pages won't be included into git, there may
be some Linux distributions that include them.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: German translation of git man pages
From: Stephan Beyer @ 2008-07-30 12:25 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Fabio Scotoni, git
In-Reply-To: <1217418938.6924.2.camel@localhost>
Hi,
Matthias Kestenholz wrote:
> 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.
The link is:
http://thread.gmane.org/gmane.comp.version-control.git/80936/focus=81031
The selected mail also has two further pointers with some discussion.
> 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.
The glossary may also be a good help:
http://git.kernel.org/?p=git/git.git;a=blob;f=git-gui/po/glossary/de.po
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 5/5] Migrate rebase-i to sequencer
From: Stephan Beyer @ 2008-07-30 12:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.0807261652050.26810@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 26 Jul 2008, Stephan Beyer wrote:
>
> > For git-rebase-i -p (preserving merges) merges should be
> > rewritten. For this, the sequencer instructions "mark", "merge"
> > and "reset" are used.
>
> Ah, the ugliness returns.
Yet I have not seen a way that is as flexible and clean as using
mark/merge/reset and imho this is not ugly.
(I know the discussion of the Joerg Sommer patches that introduced mark,
merge and reset.)
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* [PATCH] 64bit issue in test-parse-options.c
From: H.Merijn Brand @ 2008-07-30 12:16 UTC (permalink / raw)
To: git
git-1.5.6.4 - HP-UX 11.23 64bit compile
* expecting success:
test-parse-options -s123 -b -i 1729 -b -vv -n > output 2> output.err &&
test_cmp expect output &&
test ! -s output.err
--- expect 2008-07-30 11:52:05 +0000
+++ output 2008-07-30 11:52:05 +0000
@@ -1,5 +1,5 @@
boolean: 2
-integer: 1729
+integer: 7425998454784
string: 123
abbrev: 7
verbose: 2
* FAIL 2: short options
I'm sure you can come up with a more sensible change, but the current
code is definitely wrong
--8<---
--- test-parse-options.c.org 2008-07-30 11:57:16 +0000
+++ test-parse-options.c 2008-07-30 12:08:56 +0000
@@ -2,6 +2,7 @@
#include "parse-options.h"
static int boolean = 0;
+static unsigned int int_integer = 0;
static unsigned long integer = 0;
static int abbrev = 7;
static int verbose = 0, dry_run = 0, quiet = 0;
@@ -29,9 +30,9 @@ int main(int argc, const char **argv)
OPT_BIT('4', "or4", &boolean,
"bitwise-or boolean with ...0100", 4),
OPT_GROUP(""),
- OPT_INTEGER('i', "integer", &integer, "get a integer"),
- OPT_INTEGER('j', NULL, &integer, "get a integer, too"),
- OPT_SET_INT(0, "set23", &integer, "set integer to 23", 23),
+ OPT_INTEGER('i', "integer", &int_integer, "get a integer"),
+ OPT_INTEGER('j', NULL, &int_integer, "get a integer, too"),
+ OPT_SET_INT(0, "set23", &int_integer, "set integer to 23", 23),
OPT_DATE('t', NULL, &integer, "get timestamp of <time>"),
OPT_CALLBACK('L', "length", &integer, "str",
"get length of <str>", length_callback),
@@ -53,7 +54,9 @@ int main(int argc, const char **argv)
};
int i;
+ integer = 0x12345678;
argc = parse_options(argc, argv, options, usage, 0);
+ if (integer == 0x12345678) integer = int_integer;
printf("boolean: %d\n", boolean);
printf("integer: %lu\n", integer);
-->8---
--
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: git sequencer prototype
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.0807261617010.26810@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> > In the last patchset I mentioned the issue, that the prototype is slow
> > as hell. I know some bottlenecks, but I have not even tried to change
> > that, because this is no issue for the builtin.
>
> Why is it no issue for the builtin? Is it so much different from the
> prototype?
As Sverre pointed out and as my "experiments" tried to show: the builtin
is just fast ;-)
> Personally, I think if the prototype is so much slower, there is no sense
> applying it into git.git,
Right.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* 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
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