* Re: [PATCH 1/4] Add testcase for ammending and fixing author in git commit.
From: Junio C Hamano @ 2007-11-02 20:07 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <1194017589-4669-1-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> ---
> t/t7501-commit.sh | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> index b151b51..3f2112a 100644
> --- a/t/t7501-commit.sh
> +++ b/t/t7501-commit.sh
> @@ -163,4 +163,14 @@ test_expect_success 'partial commit that involves removal (3)' '
>
> '
>
> +author="The Real Author <someguy@his.email.org>"
> +test_expect_success 'amend commit to fix author' '
> +
> + git reset --hard
> + git cat-file -p HEAD | sed -e "s/author.*>/author $author/" > expected &&
> + git commit --amend --author="$author" &&
> + git cat-file -p HEAD > current &&
> + diff expected current
> +
> +'
> test_done
This can't be right. How are you ignoring the differences in
committer dates?
By the way, I _think_ git-commit.sh allows fixing author name/email
without molesting the author timestamp (i.e. takes it from the
amended commit). That should probably be checked with the test
as well.
^ permalink raw reply
* [PATCH] New script: git-changelog.perl - revised
From: Ronald Landheer-Cieslak @ 2007-11-02 20:03 UTC (permalink / raw)
To: git
I just noticed that I'd been sending personal replies to each and
every one of the replies I got - sorry about that.
Anyway, after Nicolas' suggestion, I moved the script into the contrib
directory and removed it from the Makefile, having the following patch
as net effect.
This is also available through git at
git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
As for difference wrt git2cl:
* less complicated
* less dependencies
* short hash for the commits are output in the change log
* git-changelog calls git-log with the proper parameters itself (no
need for the user to call it with a given set of parameters).
rlc
diff --git a/contrib/git-changelog/git-changelog.perl
b/contrib/git-changelog/git-changelog.perl
new file mode 100755
index 0000000..bffa1ab
--- /dev/null
+++ b/contrib/git-changelog/git-changelog.perl
@@ -0,0 +1,68 @@
+#!/usr/bin/perl -w
+
+use strict;
+
+sub fetch_log {
+ my $command='git log --pretty=format:"%ai|%an|%h|%s" ';
+ foreach (@_) {
+ $command .= ' ' . $_;
+ }
+ $command .= " |";
+ my $fh;
+ open $fh, $command
+ or die "Failed to fetch logs";
+ # logs are presented as lines in which fields are separated by pipes.
+ # the fields are the date in ISO format (so the date as we
want it extends to the
+ # first space), the name of the author, the abbreviated SHA1
hash and the subject line
+ my $date_time;
+ my $date;
+ my $cruft;
+ my $author;
+ my $hash;
+ my $subject;
+ my $prev_date="";
+ my @cache; # a cache of the changes for the current date (i.e.
while $prev_date eq $date)
+ my %entry; # a cache entry; $entry{'author'} is the entry and
@$entry{'changes'} are the changes for the author in question
+ while (<$fh>) {
+ ($date_time, $author, $hash, $subject) = split(/\|/);
+ ($date, $cruft) = split(/\s/, $date_time, 2);
+ chomp $author;
+
+ if ($date ne $prev_date)
+ {
+ foreach (@cache)
+ {
+ # print out the line with the date and
the author
+ my $changes = $_->{'changes'};
+ print "\n" . $prev_date . "\t" .
$_->{'author'} . "\n" if ($#{$changes} != -1);
+ foreach (@{$changes})
+ {
+ print "\t" . $_->{'hash'} . ':
' . $_->{'subject'};
+ }
+ }
+ $prev_date = $date;
+ @cache = ();
+ }
+ # try to find an entry with the same author in the cache
+ my $found = -1;
+ my $i;
+ for ($i = 0; $i <= $#cache && $found == -1; $i++)
+ {
+ if ($cache[$i]->{'author'} eq $author)
+ {
+ $found = $i;
+ }
+ }
+ if ($found == -1)
+ {
+ my $changes = ();
+ push @cache, { 'author', $author, 'changes', $changes };
+ $found = $#cache;
+ }
+ push @{$cache[$found]->{'changes'}}, { 'hash', $hash,
'subject', $subject };
+ }
+}
+
+fetch_log @ARGV;
+
+
--
Ronald Landheer-Cieslak
Software Architect
http://www.landheer-cieslak.com/
New White Paper: "Three Good Reasons to Plan Ahead"
^ permalink raw reply related
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Blake Ramsdell @ 2007-11-02 20:03 UTC (permalink / raw)
To: David Symonds, Junio C Hamano; +Cc: git
In-Reply-To: <ee77f5c20711020423t6ce58818gcc5220b6427ded1@mail.gmail.com>
On 11/2/07, David Symonds <dsymonds@gmail.com> wrote:
> It would probably be most appropriate for the autoconf script. Now
> that I look at configure.ac, there's already a test for iconv in
> there; is it not used?
The crux of this problem is that the prototype for iconv in
/usr/include/iconv.h is different between OS X 10.4 and OS X 10.5. So
the "right thing" is definitely to determine what is in the function
prototype, and then act accordingly.
>From OS X 10.4.10:
#define _LIBICONV_VERSION 0x0109 /* version number: (major<<8) + minor */
...
extern size_t iconv (iconv_t cd, const char* * inbuf, size_t
*inbytesleft, char* * outbuf, size_t *outbytesleft);
>From OS X 10.5:
#define _LIBICONV_VERSION 0x010B /* version number: (major<<8) + minor */
...
size_t iconv (iconv_t /*cd*/,
char ** __restrict /*inbuf*/, size_t * __restrict /*inbytesleft*/,
char ** __restrict /*outbuf*/, size_t * __restrict /*outbytesleft*/);
So what happened in git is that someone put in OLD_ICONV to
dynamically adjust the const-ness of parameter 2 to the iconv
function, and the way they chose to do that is to identify the OS
(more accurately, the kernel), and then I went and furthered that by
identifying the version.
Now that I look at it further, it seems that yanking OLD_ICONV
altogether is a better approach, and to just check _LIBICONV_VERSION
to make sure it's "new enough". Now, I'm not sure what that comparison
would be, but we know that "later than 0x0109" is a good start. Based
on the version difference between OS X 10.4 and 10.5 I note that there
is only 0x010A intervening.
This strategy presumes that this const parameter was const all the way
up to a particular point, and then stopped being const, which is
probably a reasonable assumption.
Blake
--
Blake Ramsdell | http://www.blakeramsdell.com
^ permalink raw reply
* Re: [PATCH 1/2] Implement parsing for new core.whitespace.* options.
From: Junio C Hamano @ 2007-11-02 20:02 UTC (permalink / raw)
To: David Symonds; +Cc: git, Andreas Ericsson
In-Reply-To: <11940160932021-git-send-email-dsymonds@gmail.com>
David Symonds <dsymonds@gmail.com> writes:
> Each of the new core.whitespace.* options (enumerated below) can be set to one
> of:
> * okay (default): Whitespace of this type is okay
> * warn: Whitespace of this type should be warned about
> * error: Whitespace of this type should raise an error
> * autofix: Whitespace of this type should be automatically fixed
Many problems at the conceptual level (I haven't look at the
patch yet).
We call these options (nowarn,warn,error,strip) in
apply.whitespace. "strip" is a bit of misnomer, as we only
handled the trailing whitespace initially. We should add "fix"
as a synonym to "strip".
The intention is to define what is an anomaly with
core.whitespace and then define what to do with it with
apply.whitespace.
And that is a good distinction. You may usually use "fix", but
occasionally you would want to override it one-shot (when you do
want to have byte-to-byte identical application of the patch),
and the command line option "--whitespace=" lets you do so.
At least you need to extend --whitespace command line option
handling to allow these overridden.
Adding the "error" and "fix" to "diff" is a mistake --- there is
no error condition nor fixing there. That shows how the
approach of your patch is inappropriate by trying to mix what
core.whitespace (give the definition of what is an error) and
apply.whitespace (specify what to do with an error) are designed
to do.
Defaulting to "nowarn" is wrong. Trailing whitespace errors and
space before tab errors should be turned on by default as
before.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-11-02 19:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Tom Prince, Steffen Prohaska, git
In-Reply-To: <472B2B8F.1060203@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Tom Prince wrote:
>>
>> I haven't had occasion to use git-bisect much, but I was under the
>> impression that bisect could already handle merges, or any other shaped
>> history just fine.
>
> It appears the code supports your statement. I started writing on my
> hack-around about a year ago, and the merge-handling code got in with
> 1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007.
> Perhaps I shouldn't be so paranoid about useless merges anymore then.
> Hmm. I shall have to look into it. Perhaps Junio can clarify how it
> works? The man-page was terribly silent about how git-bisect handles
> merges.
Bisecting through merge is not a problem. Not at all, from the
very beginning of the bisect command.
Side note. The commit you quote does not change (let
alone fix) the semantics at all. It is a pure
optimization. The theory behind how bisect works, see
my OLS presentation (reachable from the gitwiki).
The real problem is what to do when the culprit turns out to be
a merge commit. How to spot what really is wrong, and figure
out how to fix. The problem is not for the tool but for the
human, and it is real.
Imagine this history.
---Z---o---X---...---o---A---C---D
\ /
o---o---Y---...---o---B
Suppose that on the upper development line, the meaning of one
of the functions existed at Z was changed at commit X. The
commits from Z leading to A change both the function's
implementation and all calling sites that existed at Z, as well
as new calling sites they add, to be consistent. There is no
bug at A.
Suppose in the meantime the lower development line somebody
added a new calling site for that function at commit Y. The
commits from Z leading to B all assume the old semantics of that
function and the callers and the callee are consistent with each
other. There is no bug at B, either.
You merge to create C. There is no textual conflict with this
three way merge, and the result merges cleanly. You bisect
this, because you found D is bad and you know Z was good. Your
bisect will find that C (merge) is broken. Understandably so,
as at C, the new calling site of the function added by the lower
branch is not converted to the new semantics, while all the
other calling sites that already existed at Z would have been
converted by the merge. The new calling site has semantic
adjustment needed, but you do not know that yet. You need to
find out that is the cause of the breakage by looking at the
merge commit C and the history leading to it.
How would you do that?
Both "git diff A C" and "git diff B C" would be an enormous patch.
Each of them essentially shows the whole change on each branch
since they diverged. The developers may have well behaved to
create good commits that follow the "commit small, commit often,
commit well contained units" mantra, and each individual commit
leading from Z to A and from Z to B may be easy to review and
understand, but looking at these small and easily reviewable
steps alone would not let you spot the breakage. You need to
have a global picture of what the upper branch did (and
among many, one of them is to change the semantics of that
particular function) and look first at the huge "diff A C"
(which shows the change the lower branch introduces), and see if
that huge change is consistent with what have been done between
Z and A.
If you linearlize the history by rebasing the lower branch on
top of upper, instead of merging, the bug becomes much easier to
find and understand. Your history would instead be:
---Z---o---X'--...---o---A---o---o---Y'--...---o---B'--D'
and there is a single commit Y' between A and B' that introduced
the new calling site that still uses the new semantics of the
function that was already in A. "git show Y'" will be a much
smaller patch than "git diff A C" and it is much easier to deal
with.
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: Andreas Ericsson @ 2007-11-02 19:22 UTC (permalink / raw)
To: Steven Grimm
Cc: Junio C Hamano, J. Bruce Fields, Johannes Schindelin,
Sergei Organov, git
In-Reply-To: <472B77AC.5080507@midwinter.com>
Steven Grimm wrote:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>
>>> Make "git rebase --skip" skip patches regardless of tree and index
>>> state,
>>> but still refuse to *start* with dirty tree or index. That way, there's
>>> no risk of losing anything that can't be re-created unless the user asks
>>> for it.
>>>
>>
>> Sounds like a plan.
>>
>
> I'm unclear how that helps the usability issue here at all, though it
> doesn't sound like an unreasonable change on its own merit.
>
Because 'git commit --skip' will not require the user to first edit the
tree so the index matches the upstream thing, and he doesn't have to
manually run 'git reset --hard' before --skip'ing.
It's a small improvement, but one that goes in the right direction.
Btw, the above sentence should've read "but still refuse to *start*
(as in, start a brand new rebase) with dirty tree or index"
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git rm --cached
From: Remi Vanicat @ 2007-11-02 16:13 UTC (permalink / raw)
To: git
In-Reply-To: <20071102021711.GA28703@fawkes.hq.digizenstudio.com>
Jing Xue <jingxue@digizenstudio.com> writes:
> In the following scenario, why do I have to run 'git reset' following
> 'git rm --cached 1.txt' to revert to exactly where I was before 'git add
> 1.txt'? Shouldn't 'git rm --cached' have done that already?
Observed behavior are exactly what I expected: 'git rm --cached' mark
the file in the index as been deleted without deleting it in the
working directories, it did not but the index it was before the
'git add 1.txt'.
You probably want to use git reset HEAD -- 1.txt to unstage
modification on 1.txt
--
Rémi Vanicat
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl
From: Jakub Narebski @ 2007-11-02 19:18 UTC (permalink / raw)
To: git
Subject: Re: [PATCH] New script: git-changelog.perl
From: "Ronald Landheer-Cieslak" <ronald@landheer-cieslak.com>
To: "Jakub Narebski" <jnareb@gmail.com>
On Nov 2, 2007 1:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> [Cc: Ronald Landheer-Cieslak <ronald@landheer-cieslak.com>,
> git@vger.kernel.org]
>
> Ronald Landheer-Cieslak wrote:
>
>> I've written a little script that will format the changes as reported
>> by git-log in a ChangeLog-like format. Entries look like this:
>> <date>\t<author>\n\t<sha1>: <subject>
>
> How it compares to existing git2cl tool?:
> http://josefsson.org/git2cl/
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
I must admit I didn't know about git2cl. The first difference I see is
that it's simpler and has less dependencies: my script doesn't use any
external modules (e.g. it doesn't parse the date) but just parses a
formatted output from git-log.
Other than that, there's not much difference: my output is a bit
sparser and my script invokes the proper git-log command by itself, so
you don't have to pipe through it (i.e. all you do is git-changelog >
ChangeLog to get your change log) but that's pretty much it.
If you want, you can have a look at it at
git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
rlc
--
Ronald Landheer-Cieslak
Software Architect
http://www.landheer-cieslak.com/
New White Paper: "Three Good Reasons to Plan Ahead"
^ permalink raw reply
* Re: [PATCH] Allow git-instaweb to be run from bare repositories
From: Junio C Hamano @ 2007-11-02 19:11 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20071102090922.GA10141@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
> git-instaweb.sh | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> On IRC yesterday, two were asking for this and it seems simply enough.
> Apparently, git-instaweb is a great way to see if you've set up a
> remote repository correctly.
>
> diff --git a/git-instaweb.sh b/git-instaweb.sh
> index 95c3e5a..14917ac 100755
> --- a/git-instaweb.sh
> +++ b/git-instaweb.sh
> @@ -6,6 +6,7 @@ USAGE='[--start] [--stop] [--restart]
> [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
> [--module-path=<path> (for Apache2 only)]'
>
> +SUBDIRECTORY_OK=Yes
> . git-sh-setup
>
> fqgitdir="$GIT_DIR"
I'd agree with the goal of the patch, and I would not doubt the
patch worked for you, but it somewhat feels wrong that you can
say "It is Ok to run this script from a subdirectory" and that
is the magic to allow something to work in a bare repository.
Care to share your insights on what is going on?
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: Junio C Hamano @ 2007-11-02 19:11 UTC (permalink / raw)
To: Andreas Ericsson
Cc: J. Bruce Fields, Johannes Schindelin, Sergei Organov, git
In-Reply-To: <472AF840.1070609@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>>
>> Now, we have established that this is a real problem worth
>> solving, what's next?
>
> Make "git rebase --skip" skip patches regardless of tree and index state,
> but still refuse to *start* with dirty tree or index. That way, there's
> no risk of losing anything that can't be re-created unless the user asks
> for it.
Sounds like a plan.
^ permalink raw reply
* Re: [PATCH] git-rev-list.txt: rev stands for revision, not reverse.
From: Ralf Wildenhues @ 2007-11-02 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6j9bv80.fsf@gitster.siamese.dyndns.org>
Hello Junio,
* Junio C Hamano wrote on Thu, Nov 01, 2007 at 08:51:11PM CET:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>
> > Yes, believe it or not, but I stumbled over the synopsis
> >
> > | git-rev-list - Lists commit objects in reverse chronological order
> >
> > asking myself whether rev could possibly mean "reverse".
> > I hope this helps avoid this pitfall for others.
>
> In addition to your patch,
>
> git-rev-list - List commits from most recent to older
>
> might be a good rewording?
Is the reverse chronological order the primary sorting key at all?
My clone of the git repo gives me
$ git rev-list --pretty=format:%ct master | grep -v ^commit >A
$ sort -k1nr A | diff -u - A
--- - 2007-11-02 18:06:00.115804000 +0100
+++ A 2007-11-02 18:05:37.000000000 +0100
@@ -8162,8 +8162,8 @@
1141461106
1141461098
1141461088
-1141457404
1141457396
+1141457404
1141453772
1141453757
1141453684
Interestingly, --date-order shows another inconsistency:
$ git rev-list --date-order --pretty=format:%ct master | grep -v ^commit >Ad
$ sort -k1nr Ad | diff -u - Ad
--- - 2007-11-02 18:27:18.091006000 +0100
+++ Ad 2007-11-02 18:25:46.000000000 +0100
@@ -653,8 +653,8 @@
1188812406
1188808117
1188770606
-1188716400
1188716027
+1188716400
1188677727
1188668216
1188644991
@@ -8162,8 +8162,8 @@
1141461106
1141461098
1141461088
-1141457404
1141457396
+1141457404
1141453772
1141453757
1141453684
This is "git version 1.5.3.5.474.g3e4bb", both repo and executables.
It looks like there is either a bug or the sorting criterion is subtly
different.
> "rev-list --reverse" reverses that usual order and we end up
> explaining double reversal if we use the phrase "reverse chronological
> order" to describe the normal order.
Well, I'd say the current synopsis would be fine if the default ordering
really were the commit date. The synopsis should be concise, it's good
enough if the Description clears potential doubts.
Cheers,
Ralf
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl
From: Nicolas Pitre @ 2007-11-02 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ronald Landheer-Cieslak, git
In-Reply-To: <Pine.LNX.4.64.0711021821410.4362@racer.site>
On Fri, 2 Nov 2007, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 2 Nov 2007, Ronald Landheer-Cieslak wrote:
>
> > I've written a little script that will format the changes as reported
> > by git-log in a ChangeLog-like format.
>
> Jakub already commented on the availability of git2cl, but I thought I'd
> clarify: once upon a time I even wrote some builtin to perform that
> transformation, and it was met with unilateral disgus^Wagreement not to
> include it into core git.
>
> Therefore I think it would be sanest to enhance git2cl until it does what
> you want to do.
The contrib directory is certainly a good place for such scripts as
well.
Nicolas
^ permalink raw reply
* Re: Bring parse_options to the shell
From: Pierre Habouzit @ 2007-11-02 18:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, gitster, git
In-Reply-To: <Pine.LNX.4.64.0711021818480.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]
On Fri, Nov 02, 2007 at 06:21:17PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 2 Nov 2007, Pierre Habouzit wrote:
>
> > On Fri, Nov 02, 2007 at 03:51:13PM +0000, Linus Torvalds wrote:
> >
> > > That command [rev-parse] was written exactly to parse a command line.
> > > This is really cheesy, and doesn't really work right (it splits up
> > > numbers too), but you get the idea..
> >
> > I get the idea, though parse-options is not incremental at all, this
> > could probably be done, but would complicate the API (we would need to
> > allocate a state object e.g.). And parseoptions checks that options
> > getting an argument have one, checks that options exists and so on. It
> > looks like to me that it's not easy to plumb into rev-parse without
> > being a brand new independant mode.
> >
> > We can do that, if we don't want yet-another-git-builtin/command, but
> > in the spirit it'll remain a brand new "thing".
> >
> > Though I'd be glad to hear about what others think about it.
>
> Yeah, rev-parse's only purpose in life is to help scripts. (Even if it is
> used sometimes -- even by myself -- to turn symbolic names into SHA-1s.)
>
> IMHO it makes tons of sense to put the functionality into that command,
> even if it is not incremental.
Okay so what do I do ? I create a new mode for git-rev-parse that does
what I do in git-parseopt ? I can do that, I don't like it a lot, but if
people it's better to work this way... It's also kind of counter
intuitive to have git *rev-parse* doing that but oh well, after all it's
plumbing
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* That new progress meter
From: Johannes Schindelin @ 2007-11-02 18:36 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
Hi Nico,
that new progress meter sure is amazing and useful!
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl
From: Johannes Schindelin @ 2007-11-02 18:27 UTC (permalink / raw)
To: Ronald Landheer-Cieslak; +Cc: git
In-Reply-To: <67837cd60711020855v5badf7a6o9b777f339df070f@mail.gmail.com>
Hi,
On Fri, 2 Nov 2007, Ronald Landheer-Cieslak wrote:
> I've written a little script that will format the changes as reported
> by git-log in a ChangeLog-like format.
Jakub already commented on the availability of git2cl, but I thought I'd
clarify: once upon a time I even wrote some builtin to perform that
transformation, and it was met with unilateral disgus^Wagreement not to
include it into core git.
Therefore I think it would be sanest to enhance git2cl until it does what
you want to do.
Ciao,
Dscho
^ permalink raw reply
* Re: Bring parse_options to the shell
From: Johannes Schindelin @ 2007-11-02 18:21 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, gitster, git
In-Reply-To: <20071102160925.GC27505@artemis.corp>
Hi,
On Fri, 2 Nov 2007, Pierre Habouzit wrote:
> On Fri, Nov 02, 2007 at 03:51:13PM +0000, Linus Torvalds wrote:
>
> > That command [rev-parse] was written exactly to parse a command line.
> > This is really cheesy, and doesn't really work right (it splits up
> > numbers too), but you get the idea..
>
> I get the idea, though parse-options is not incremental at all, this
> could probably be done, but would complicate the API (we would need to
> allocate a state object e.g.). And parseoptions checks that options
> getting an argument have one, checks that options exists and so on. It
> looks like to me that it's not easy to plumb into rev-parse without
> being a brand new independant mode.
>
> We can do that, if we don't want yet-another-git-builtin/command, but
> in the spirit it'll remain a brand new "thing".
>
> Though I'd be glad to hear about what others think about it.
Yeah, rev-parse's only purpose in life is to help scripts. (Even if it is
used sometimes -- even by myself -- to turn symbolic names into SHA-1s.)
IMHO it makes tons of sense to put the functionality into that command,
even if it is not incremental.
Ciao,
Dscho
^ permalink raw reply
* Re: New features in gitk
From: Johannes Schindelin @ 2007-11-02 18:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marco Costalba, Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.999.0711020828440.3342@woody.linux-foundation.org>
Hi,
On Fri, 2 Nov 2007, Linus Torvalds wrote:
> On Fri, 2 Nov 2007, Marco Costalba wrote:
> >
> > I have tried to overcome --topo-order in qgit but I found it very
> > difficult, too much for me.
> >
> > Lazily drawing the layout it doesn't mean that you lazy load the data
> > from git, indeed you load all the git-log output as soon as it
> > arrives.
>
> Would it be more palatable if I tried to write some
> visualization-specific front-end that acted kind of like "git rev-list",
> but would have some way of "resetting" its output?
Heh, Shawn and I were discussing this when we met in San Jose earlier this
month. The application we had in mind was a common backend for graphical
representation of the commit graph, which could be used by git gui to show
(part of) the history. The ultimate goal was a graphical rebase -i.
I would have _loved_ to implement this. Alas, as it appears my choice of
job was less than brilliant, and even when I have some spare moments at
the end of the day, I watch movies to forget the day, instead of
implementing this fascinating and useful feature.
Ciao,
Dscho
^ permalink raw reply
* Re: New features in gitk
From: Linus Torvalds @ 2007-11-02 18:16 UTC (permalink / raw)
To: Marco Costalba; +Cc: Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.999.0711020828440.3342@woody.linux-foundation.org>
On Fri, 2 Nov 2007, Linus Torvalds wrote:
>
> The thing is, I'm pretty sure I can feed you commits really quickly if I
> don't sort them, and if I don't do the full and careful "oops, this commit
> was reachable from a commit that was marked uninteresting", but while the
> fast-and-stupid approach will work well enough for most things, it will
> occasionally get the wrong answer.
Ok, I have a trial patch that doesn't do the replay yet, but at least
notices when it outputs a parent that has already been shown.
In the whole git archive, it happens three times.
In the kernel archive, it happens twelve times.
I'll try to get it into some kind of usable shape, and send out
experimental patches for people to play with.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: J. Bruce Fields @ 2007-11-02 17:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brian Downing
In-Reply-To: <7vwst15ceq.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 02, 2007 at 12:34:05AM -0700, Junio C Hamano wrote:
> This introduces core.whitespace configuration variable that lets
> you specify the definition of "whitespace error".
>
> Currently there are two kinds of whitespace errors defined:
>
> * trailing-space: trailing whitespaces at the end of the line.
>
> * space-before-tab: a SP appears immediately before HT in the
> indent part of the line.
The whitespace policy varies based on the project (and in some cases,
based on the file within that project). It shouldn't vary from user to
user or repo to repo. So the configuration variable mechanism seems a
poor match. Would it be possible to use something like gitattributes
instead? Then the whitespace policy would be associated with the
project itself, would automatically be propagated on clone, etc.
Thanks for working on this.
--b.
>
> You can specify the desired types of errors to be detected by
> listing their names (unique abbreviations are accepted)
> separated by comma. By default, these two errors are always
> detected, as that is the traditional behaviour. You can disable
> detection of a particular type of error by prefixing a '-' in
> front of the name of the error, like this:
>
> [core]
> whitespace = -trailing-space
>
> This patch teaches the code to output colored diff with
> DIFF_WHITESPACE color to highlight the detected whitespace
> errors to honor the new configuration.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> cache.h | 9 +++++++++
> config.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> diff.c | 13 ++++++++-----
> environment.c | 1 +
> 4 files changed, 70 insertions(+), 5 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index bfffa05..a6e5988 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -602,4 +602,13 @@ extern int diff_auto_refresh_index;
> /* match-trees.c */
> void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
>
> +/*
> + * whitespace rules.
> + * used by both diff and apply
> + */
> +#define WS_TRAILING_SPACE 01
> +#define WS_SPACE_BEFORE_TAB 02
> +#define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB)
> +extern unsigned whitespace_rule;
> +
> #endif /* CACHE_H */
> diff --git a/config.c b/config.c
> index dc3148d..ffb418c 100644
> --- a/config.c
> +++ b/config.c
> @@ -246,6 +246,53 @@ static unsigned long get_unit_factor(const char *end)
> die("unknown unit: '%s'", end);
> }
>
> +static struct whitespace_rule {
> + const char *rule_name;
> + unsigned rule_bits;
> +} whitespace_rule_names[] = {
> + { "trailing-space", WS_TRAILING_SPACE },
> + { "space-before-tab", WS_SPACE_BEFORE_TAB },
> +};
> +
> +static unsigned parse_whitespace_rule(const char *string)
> +{
> + unsigned rule = WS_DEFAULT_RULE;
> +
> + while (string) {
> + int i;
> + size_t len;
> + const char *ep;
> + int negated = 0;
> +
> + string = string + strspn(string, ", \t\n\r");
> + ep = strchr(string, ',');
> + if (!ep)
> + len = strlen(string);
> + else
> + len = ep - string;
> +
> + if (*string == '-') {
> + negated = 1;
> + string++;
> + len--;
> + }
> + if (!len)
> + break;
> + for (i = 0; i < ARRAY_SIZE(whitespace_rule_names); i++) {
> + if (strncmp(whitespace_rule_names[i].rule_name,
> + string, len))
> + continue;
> + if (negated)
> + rule &= ~whitespace_rule_names[i].rule_bits;
> + else
> + rule |= whitespace_rule_names[i].rule_bits;
> + break;
> + }
> + string = ep;
> + }
> + return rule;
> +}
> +
> int git_parse_long(const char *value, long *ret)
> {
> if (value && *value) {
> @@ -431,6 +478,11 @@ int git_default_config(const char *var, const char *value)
> return 0;
> }
>
> + if (!strcmp(var, "core.whitespace")) {
> + whitespace_rule = parse_whitespace_rule(value);
> + return 0;
> + }
> +
> /* Add other config variables here and to Documentation/config.txt. */
> return 0;
> }
> diff --git a/diff.c b/diff.c
> index a6aaaf7..2112353 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -508,7 +508,8 @@ static void emit_line_with_ws(int nparents,
> for (i = col0; i < len; i++) {
> if (line[i] == '\t') {
> last_tab_in_indent = i;
> - if (0 <= last_space_in_indent)
> + if ((whitespace_rule & WS_SPACE_BEFORE_TAB) &&
> + 0 <= last_space_in_indent)
> need_highlight_leading_space = 1;
> }
> else if (line[i] == ' ')
> @@ -540,10 +541,12 @@ static void emit_line_with_ws(int nparents,
> tail = len - 1;
> if (line[tail] == '\n' && i < tail)
> tail--;
> - while (i < tail) {
> - if (!isspace(line[tail]))
> - break;
> - tail--;
> + if (whitespace_rule & WS_TRAILING_SPACE) {
> + while (i < tail) {
> + if (!isspace(line[tail]))
> + break;
> + tail--;
> + }
> }
> if ((i < tail && line[tail + 1] != '\n')) {
> /* This has whitespace between tail+1..len */
> diff --git a/environment.c b/environment.c
> index b5a6c69..624dd96 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -35,6 +35,7 @@ int pager_in_use;
> int pager_use_color = 1;
> char *editor_program;
> int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
> +unsigned whitespace_rule = WS_DEFAULT_RULE;
>
> /* This is set by setup_git_dir_gently() and/or git_default_config() */
> char *git_work_tree_cfg;
> --
> 1.5.3.5.1452.ga93d
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] post-update hook: update working copy
From: Steven Grimm @ 2007-11-02 17:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Sam Vilain, git
In-Reply-To: <472AFD39.6000006@op5.se>
Andreas Ericsson wrote:
>> - Who guarantees that a human user is not actively editing the
>> work tree files without saving?
> There are times when one simply doesn't care.
>
> I realize that for my situation, a much simpler script can (and is)
> used, so
> I agree with your concerns. The idea that every git repo has a human
> hacking
> on it isn't true though, so doing things like this are sometimes useful,
> timesaving and a real help.
Yeah, that's absolutely true. My use cases would be twofold. First, a
public reference tree on a shared development server where people can
look over my corner of the code base without having to check the whole
thing out for themselves.
Second, a Web server with a bunch of static text/image files and PHP
scripts. If I can deploy by just pushing to a "current release" branch,
that saves me from having to first push then ssh to the machine and do
"git reset --hard".
Neither one of those things is impossible to do with vanilla git. They
just require extra busywork steps at the moment if you don't use an
"update the working copy on push" hook.
-Steve
^ permalink raw reply
* [PATCH] Documentation: quote commit messages consistently.
From: Sergei Organov @ 2007-11-02 17:12 UTC (permalink / raw)
To: git
Documentation quotes commit messages 14 times with double-quotes, and 7
times with single-quotes. The patch turns everything to double-quotes.
A nice side effect is that documentation becomes more Windoze-friendly
as AFAIK single quotes won't work there.
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/core-tutorial.txt | 8 ++++----
Documentation/everyday.txt | 4 ++--
Documentation/git-reset.txt | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 5df97a1..99817c5 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -828,7 +828,7 @@ that branch, and do some work there.
------------------------------------------------
$ git checkout mybranch
$ echo "Work, work, work" >>hello
-$ git commit -m 'Some work.' -i hello
+$ git commit -m "Some work." -i hello
------------------------------------------------
Here, we just added another line to `hello`, and we used a shorthand for
@@ -853,7 +853,7 @@ hasn't happened in the `master` branch at all. Then do
------------
$ echo "Play, play, play" >>hello
$ echo "Lots of fun" >>example
-$ git commit -m 'Some fun.' -i hello example
+$ git commit -m "Some fun." -i hello example
------------
since the master branch is obviously in a much better mood.
@@ -1607,8 +1607,8 @@ in both of them. You could merge in 'diff-fix' first and then
'commit-fix' next, like this:
------------
-$ git merge -m 'Merge fix in diff-fix' diff-fix
-$ git merge -m 'Merge fix in commit-fix' commit-fix
+$ git merge -m "Merge fix in diff-fix" diff-fix
+$ git merge -m "Merge fix in commit-fix" commit-fix
------------
Which would result in:
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 08c61b1..ce7c170 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -109,7 +109,7 @@ $ tar zxf frotz.tar.gz
$ cd frotz
$ git-init
$ git add . <1>
-$ git commit -m 'import of frotz source tree.'
+$ git commit -m "import of frotz source tree."
$ git tag v2.43 <2>
------------
+
@@ -300,7 +300,7 @@ $ git merge topic/one topic/two && git merge hold/linus <8>
$ git checkout maint
$ git cherry-pick master~4 <9>
$ compile/test
-$ git tag -s -m 'GIT 0.99.9x' v0.99.9x <10>
+$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
$ git push ko <12>
$ git push ko v0.99.9x <13>
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 15e3aca..87afa6f 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -157,7 +157,7 @@ need to get to the other branch for a quick bugfix.
------------
$ git checkout feature ;# you were working in "feature" branch and
$ work work work ;# got interrupted
-$ git commit -a -m 'snapshot WIP' <1>
+$ git commit -a -m "snapshot WIP" <1>
$ git checkout master
$ fix fix fix
$ git commit ;# commit with real log
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] New script: git-changelog.perl
From: Jakub Narebski @ 2007-11-02 17:07 UTC (permalink / raw)
To: git
In-Reply-To: <67837cd60711020855v5badf7a6o9b777f339df070f@mail.gmail.com>
[Cc: Ronald Landheer-Cieslak <ronald@landheer-cieslak.com>,
git@vger.kernel.org]
Ronald Landheer-Cieslak wrote:
> I've written a little script that will format the changes as reported
> by git-log in a ChangeLog-like format. Entries look like this:
> <date>\t<author>\n\t<sha1>: <subject>
How it compares to existing git2cl tool?:
http://josefsson.org/git2cl/
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
BTW. Do anyone has idea why on above wiki page table of contents does not
display some sections at all?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: New features in gitk
From: Marco Costalba @ 2007-11-02 16:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.999.0711020828440.3342@woody.linux-foundation.org>
On 11/2/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> But it will *notice* when it gets the wrong answer, though, and can reset
> and start over!
>
> IOW, I might be able to do something that
>
> - prints out the commit info per line
>
> - prepends each line with a line number
>
> - goes back to an earlier line 'n' when it notices that it needs to
> output a commit before a previous commit (or when it notices that a
> commit that it had already output was actually not supposed to show up)
>
> and with something like that, I could make git give you incremental
> output.
>
Yes. That's would be easier to implement. Better yet do not give line
numbers I already push back each revision sha in a vector according to
arrival order. It's a stack like storing.
So would be nice if 'git log --restarting' would work like this:
- Output the normal stream of commits according to git log arguments.
No line numbers, no fancy additional stuff.
- If '--topo-order' or something similar was given git log checks if a
wrong output occurs, as example because it founds a revisions that
should have been already put out say 'n' revisions before the last
outputted one.
- In the above case git log outputs a side-band data of "uhhuh, I screwed
up, I restart from 'n' revisions before the last one outputted".
- Then ouput _again_ the stream starting from 'n' revisions earlier.
Note that not only the new offending revision is trasmitted but *all
the revisions* from the out of order one to the remaining.
Given a vector of 'k' arrived revisions, for me it's far easier simply
to flush the 'n' tail items in the sha vector and restart again then
_insert_ in the vector the new out of order one.
This is because parsing alghoritm is based on an 'append new stuff'
approach, not 'insert in the middle', so better flush all the tail
also if probably the big part of retrasmitted revisions would remain
the same.
Marco
P.S: The out of bound information should be commit data aligned and
could take advantage of the fact that an sha always starts with an
alphanumeric char value [0..9 a..f]
IOW instead of the commit sha this signal could write something like
'Restarting from -12'
and parsing knows that an sha cannot start with an 'R'. Please note
that 'instead of the commit sha' it means in the _exact_ place where
sha is expected and this is not predefined but depends on the git-log
arguments, so that as example
$git log --with-restart
would output:
commit 6959893b0b65ebc68ce2fb524a8ec15a26ca4972
Merge: 452b800... d279fc1...
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Oct 31 23:53:55 2007 -0700
Merge branch 'sp/mergetool'
* sp/mergetool:
mergetool: avoid misleading message "Resetting to default..."
mergetool: add support for ECMerge
mergetool: use path to mergetool in config var mergetool.<tool>.path
commit Restart from -7
commit 3e4bb087a18435b12eb82116e93af2887578e816
Merge: 5fb1948... 136e631...
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Nov 1 17:09:08 2007 -0700
Merge branch 'maint'
while
$git log --with-restart --pretty=oneline
would output
6959893b0b65ebc68ce2fb524a8ec15a26ca4972 Merge branch 'sp/mergetool'
Restart from -7
3e4bb087a18435b12eb82116e93af2887578e816 Merge branch 'maint'
5fb19486e6f4b6d31f33f5a1eab970b244fa2d08 Merge branch 'bk/maint-cvsexportcommit'
In this way this side band info became compatible with _any_ git-log
output format as long as the format foreseens the output of the
revision sha.
^ permalink raw reply
* Re: [PATCH 3/4] Export launch_editor() and make it accept ':' as a no-op editor.
From: Kristian Høgsberg @ 2007-11-02 16:16 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <472B466E.8070805@op5.se>
On Fri, 2007-11-02 at 16:46 +0100, Andreas Ericsson wrote:
> Kristian Høgsberg wrote:
> >
> > + if (!strcmp(editor, ":"))
> > + return;
> > +
>
> Doesn't this make the change in 2/4 superfluous?
Yeah, but it's still a nice cleanup, I think.
Kristian
^ permalink raw reply
* Re: Bring parse_options to the shell
From: Pierre Habouzit @ 2007-11-02 16:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: gitster, git
In-Reply-To: <alpine.LFD.0.999.0711020844310.3342@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]
On Fri, Nov 02, 2007 at 03:51:13PM +0000, Linus Torvalds wrote:
>
>
> On Fri, 2 Nov 2007, Pierre Habouzit wrote:
>
> > On Fri, Nov 02, 2007 at 03:09:18PM +0000, Pierre Habouzit wrote:
> > > This is also something that itches me, so here is a proposal for a
> > > git-parseopt helper that can be used in shell scripts as an option
> > > normalizer like getopt(1) does.
> > >
> > > I migrated the discussed git-clean.sh to use it as a proof of concept.
> >
> > Needless to say, this is fetchable from
> > git://git.madism.org/git.git#ph/parseopt
>
> Hmm. Any reason why you didn't just extend on "git rev-parse"?
Because I wasn't aware of the fact it was used to massage arguments of a
function :) Though looking at the code git-rev-parse looks quite
complicated and does not works the proper way:
It show()s the arguments along the way, whereas you definitely need to
parse them first if you end up spitting out the usage. I could of course
plumb it as a new "mode" of git-rev-parse, but it sounds awkward.
> That command was written exactly to parse a command line. This is really
> cheesy, and doesn't really work right (it splits up numbers too), but you
> get the idea..
I get the idea, though parse-options is not incremental at all, this
could probably be done, but would complicate the API (we would need to
allocate a state object e.g.). And parseoptions checks that options
getting an argument have one, checks that options exists and so on. It
looks like to me that it's not easy to plumb into rev-parse without
being a brand new independant mode.
We can do that, if we don't want yet-another-git-builtin/command, but
in the spirit it'll remain a brand new "thing".
Though I'd be glad to hear about what others think about it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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