* 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: 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
* [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: [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
* 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: 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: [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: [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
* 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: 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
* 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
* 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: 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
* 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: 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: 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: [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Johannes Schindelin @ 2008-07-30 13:51 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano, Miklos Vajna, Jakub Narebski
In-Reply-To: <200807300652.41404.chriscool@tuxfamily.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2107 bytes --]
Hi,
On Wed, 30 Jul 2008, Christian Couder wrote:
> Le lundi 28 juillet 2008, Johannes Schindelin a écrit :
>
> > On Mon, 28 Jul 2008, Christian Couder wrote:
> > > + rev = xmalloc((argc - 1) * sizeof(*rev));
> > > +
> > > + do {
> > > + struct commit *r = get_commit_reference(argv[1]);
> > > + if (!r)
> > > + return 1;
> > > + rev[rev_nr++] = r;
> > > + argc--; argv++;
> > > + } while (argc > 1);
> > > +
> > > + return show_merge_base(rev, rev_nr, show_all);
> >
> > rev = xmalloc((argc - 1) * sizeof(*rev));
> >
> > for (rev_nr = 0; rev_nr + 1 < argc; rev_nr++) {
> > rev[rev_nr] = get_commit_reference(argv[rev_nr + 1]);
> > if (!rev[rev_nr])
> > return !!error("Does not refer to a commit: '%s'",
> > argv[rev_nr + 1]);
> > }
> >
> > return show_merge_base(rev, rev_nr, show_all);
> >
> > I do not know about you, but I think this is not only shorter (in spite
> > of adding a helpful error message), but also simpler to understand (not
> > using convoluted do { } while logic), and therefore superior.
>
> In my last version the loop is reduced to:
>
> + do {
> + rev[rev_nr++] = get_commit_reference(argv[1]);
> + argc--; argv++;
> + } while (argc > 1);
>
> so it's very simple.
>
> And the stop condition is simpler in my version.
Does not matter. The logic is convoluted, i.e. not how (most) humans
think. And you cheat by putting the argc and argv statements in one line.
And you do not use argc and argv after the loop, so those statements are
pointless.
And you cheat by not needing that die() anymore because you posted a
(good!) patch _after_ I sent my version.
So it could e as short as this:
while (++rev_nr < argc)
rev[rev_nr - 1] = get_commit_reference(argv[rev_nr]);
I would contend that the for() version is more readable.
> > Your performance argument is weak IMHO, as this is not a big
> > performance hit, and command line parameter parsing is definitely not
> > performance critical.
>
> It feels a bit sloppy though.
Sure.
If you think that obviousness in a command line parsing is less important
than performance.
Ciao,
Dscho
^ permalink raw reply
* [StGit] stg import documentation incorrect.
From: Jurko Gospodnetić @ 2008-07-30 13:52 UTC (permalink / raw)
To: git; +Cc: catalin.marinas
Hi.
StGIT 'stg import' documentation at
http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial states that this
command is equivalent to:
> "stg new" followed by "patch -i <file>", then "stg refresh -e"
However, 'stg refresh' does not accept the -e option (which most
likely has something to do with calling an external editor to edit the a
log message).
Hope this helps.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Johannes Schindelin @ 2008-07-30 13:53 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730082030.GA12555@cuci.nl>
Hi,
On Wed, 30 Jul 2008, Stephen R. van den Berg wrote:
> Someone popped this question on me.
I do not know cvs that well anymore. So I do not know what -l does. Care
to explain?
> How many weeks are there in a lightyear?
That is easy. 52 light ones.
Ciao,
Dscho
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: H.Merijn Brand @ 2008-07-30 13:58 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git
In-Reply-To: <20080730133334.GB31192@lars.home.noschinski.de>
On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
<lars-2008-1@usenet.noschinski.de> wrote:
> * 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"?
If you come from a SCCS environment, the developers are used to see the
version of a single file, not of the id of a fix. One of the reasons we
moved from SCCS to git, is that we now can commit a group of files as a
single commit, and later look at the complete picture.
We are not used to working with $SHA's, and IMHO from the end-user pov,
a $SHA is less user friendly than a release number or a file version. I
can remember a version, but I cannot remember a SHA.
The end user only has the application, which is (or at least should be)
able to spit out its release version. That is all we can go by when we
dig back into the history to see where we changed things.
One (very) big disadvantage of SCCS is that commits are on a per-file
basis, and only in a single directory. This drawback still haunts me in
git, as my first attempts to convert were successful in a single folder
and git cannot merge folders into a single project.
Say I now have
/work/src/project/.git
/work/src/project/module_a/.git
/work/src/project/module_b/.git
/work/src/project/module_c/.git
Which are all converted repos from SCCS, I'd like to merge the three
module_# repos into the top level repo.
--
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: cvs diff -l equivalent?
From: Thomas Rast @ 2008-07-30 14:00 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730082030.GA12555@cuci.nl>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Stephen R. van den Berg wrote:
> Someone popped this question on me. The closest I got was:
>
> git diff .
>
> But that still recurses. Any solutions without patching?
Maybe a scripted version? For just 'git diff .', this should work:
git diff $(git ls-files . | grep -v /)
That will still do the wrong thing if you diff against an older commit
with a different list of files. In that case you need the list of
files in the other side of the diff too:
git diff HEAD^.. -- $(git ls-files . | grep -v /; git ls-tree HEAD^ | cut -f2)
- Thomas
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: German translation of git man pages
From: Fabio Scotoni @ 2008-07-30 14:05 UTC (permalink / raw)
To: git
Hello,
On Wed, 2008-07-30 at 14:25 +0200, Stephan Beyer wrote:
> 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
I think we should follow this Glossary. Git-gui users should not be
forced to learn again. Learning git is already enough work.
On Wed, 2008-07-30 at 13:18 +0200, David Soria Parra wrote:
> You might want to provide a public repository, which we can pull from
> and send you patches.
Of course. Here it is: git://repo.or.cz/srv/git/gitman-de.git
(You may blame me now for using a public repository.)
I did create the mob user ( http://repo.or.cz/mob.html ) and it's
branch. Pushing only over ssh.
I used the repository of git from yesterday.
The only translated file at the moment is gittutorial-de.txt.
Every file without -de at its end is the original English file.
DO NOT MODIFY them.
If files with -de at their end have English passages or are completely
English means, they haven't been translated.
Note: You should fix any Eszett errors, I'm Swiss, so i was unable to
insert any Eszetts.
On Wed, 2008-07-30 at 13:06 +0200, Stephen R. van den Berg wrote:
> 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).
I think we should avoid this. It just makes the text more unclear and
harder to understand. Instead, we should provide something like
"gitglossary-de.1", so interested users can look up our translations of
English words.
On Wed, 2008-07-30 at 11:21 +0000, Mark Struberg wrote:
> (Reminds me of some old Siemens BS2000 mainfraims back in the 80s.
> They translated really ALL terms to german, which was frankly
> completely unreadable)
Yes, I exactly know what you mean and I would like to keep some terms,
but they were translated to German and so I feel forced to copy the
glossary of git-gui.
With best regards,
Fabio Scotoni
^ permalink raw reply
* Re: [PATCH] 64bit issue in test-parse-options.c
From: Pierre Habouzit @ 2008-07-30 14:05 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20080730144452.797d8686@pc09.procura.nl>
[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]
On Wed, Jul 30, 2008 at 12:44:52PM +0000, H.Merijn Brand wrote:
> 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.
That is because OPT_DATE indeed expect a long (why not a time_t I don't
know btw... but time_t is a long on linux so it doesn't change things a
lot).
The proper fix is to let integer be an *INT* (long integer is bogus
anyways) and to put the date in a long using static unsigned long date,
and make OPT_DATE use this long.
--
·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: [PATCH 2/5] Add git-sequencer documentation
From: Johannes Schindelin @ 2008-07-30 14:06 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <20080730121454.GA8767@leksak.fem-net>
Hi,
On Wed, 30 Jul 2008, Stephan Beyer wrote:
> 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.
No, just leave it as is. The users can always ask you on the mailing
list. So my comment was totally unfounded.
> > > +--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.
/me does not like that. I could see a new porcelain doing that, but not
the thing that will be called by rebase.
> > > + --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.
Yes, I read "merges" the same way. My comment still stands.
> Thanks for your reply and your other notes. (The ones I didn't comment
> are just ACKed.)
The ones that _I_ did not comment on I do not necessarily agree with, but
then, I do not have the time to argue about them.
Ciao,
Dscho
^ permalink raw reply
* Re: git sequencer prototype
From: Johannes Schindelin @ 2008-07-30 14:07 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <20080730121458.GB8767@leksak.fem-net>
Hi,
On Wed, 30 Jul 2008, Stephan Beyer wrote:
> 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 ;-)
So why is it just so fast? Does it do things completely different than
the shell prototype you presented?
Still puzzled,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox