* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 23:02 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111514j75d1ae6dl3c3f5dbfb55961c7@mail.gmail.com>
Hi,
On Sat, 12 Jul 2008, Sverre Rabbelier wrote:
> On Sat, Jul 12, 2008 at 12:11 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > The mechanism is this: you look up the email in .mailmap (actually you
> > parse that once, but the idea stays the same), and if there is a name for
> > it, you use that _instead of_ the given author name.
>
> Ah, so you suggest changing "format:%ae" to "format:%ae %an" and
> falling back to the latter id specified on that line if the former is
> not in .mailmap? That would work I guess, I'll put it on my TODO list
> :).
Hmm. I missed the fact that you used pretty formats. Seems like %an does
not respect .mailmap; I'm on it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-rebase.sh: Display error output from git-checkout when detaching HEAD fails.
From: Junio C Hamano @ 2008-07-11 22:57 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <1215811619-28512-1-git-send-email-robertshearman@gmail.com>
Robert Shearman <robertshearman@gmail.com> writes:
> The "git checkout" command executed could fail if, for example, upstream contains a file that would overrwrite a local, untracked file. The output redirection didn't work as stderr was redirected to /dev/null, as was stdout. This appears to be not what was intended so the order of redirections is fixed so that stderr is redirected to stdout instead.
Very long lines, lacks sign-off.
> ---
> git-rebase.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase.sh b/git-rebase.sh
> index e2d85ee..0da2210 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -376,7 +376,7 @@ fi
>
> # Detach HEAD and reset the tree
> echo "First, rewinding head to replay your work on top of it..."
> -git checkout "$onto^0" >/dev/null 2>&1 ||
I think this very much is done deliberately by somebody who knows the
shell to discard everything.
> +git checkout "$onto^0" 2>&1 >/dev/null ||
And if it is beneficial to show the error, you just do not touch fd #2,
like this:
git checkout "$onto^0" >/dev/null
As I do not see any reason to send the error message to stdout like you
did.
I also suspect that this part of the script predates 6124aee (add a quiet
option to git-checkout, 2007-02-01) where the command learned to be more
quiet during the normal operation. Perhaps you can replace the line with
git checkout -q "$onto^0"
and be done with it. I haven't tested it, though.
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-11 22:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807112257450.8950@racer>
On Sat, Jul 12, 2008 at 12:07 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> On Fri, Jul 11, 2008 at 11:22 PM, Johannes Schindelin
>> Yeah, I wish 'git log -C -C -M --numstat --sacrifice-chicken
>> --pretty=format:%ae --' would take care of that... That is, a git-blame
>> like mechanism that would detect such moves on a per-commit basis and
>> report them would be very useful to me.
>
> Well, the chicken (or better, a goat) should be sacrificed by you... The
> option I would call "--code-moves".
If you suggest I write up a patch to 'git log' I am afraid that would
require quite a bit more skill && knowledge of 'git log' than I have
(which is about Null :P).
> But the semantics of that need to be sorted out in a shell script first;
> maybe like I outlined (if that was not coherent, please say so).
Python is one big shell script :P, so if you meant that it should be
part of GitStats (instead of part of 'git log', which I commented on
above), python would be just fine :). The concept was clear enough
though, I think I understand what you mean.
> Well, it is not a matter of getting it right, but it is a matter of
> changes. For example, everytime we move code from one program into the
> library, and create a file for that, code changes.
<snip>
Yes, that's true, with what you described it makes sense :).
>> Very much so, but the former I figure can be easily done with 'git log
>> -C -C -M' I discovered (I need to parse it's output though, and also
>> determine what to do with moves statistics wise. Should changes made
>> due to moves just be ignored?)
>
> That is not very interesting, as we often move so small parts (think "one
> function") that -C -C -M does not trigger.
Right, why aim for the stuff when there's much more interesting fun
out there? If there was a --code-moves I agree with you that it would
be a lot more interesting to have than going with the current approach
and throwing in '-C -C -M'.
>> That sounds interesting, I won't need to actually do that though, I
>> already have a diff parser that gives me the lines added VS lines
>> deleted on a hunk-by-hunk basis. If it is a true move (e.g., code
>> removed in file X and added in file Y) it should be trivial to detect
>> that.
>> Something along the lines of:
>> for hunk in added:
>> if hunk in deleted:
>> print("Over here!!")
>
> I think that is not enough, as a code move can mean that part of a
> function was refactored into a function. The consequence is often a
> reindent, and possibly rewrapping.
Mhhh, such would be beyond the scope of implementing manually indeed,
and should be left to the likes of a diff tool instead in order to
prevent reinventing the wheel :).
> And it can mean that some lines have to be inserted here and there. I
> still would count that as a code move "with touch-ups".
True, true, so it turns out that the most interesting data is the most
difficult to mine, how typical.
> So I'd like to see something like
>
> <number-of-commits>: <lines-added> <lines-removed> \
> <lines-moved-from> <lines-moved-to> <filename>
Ah, I like the idea of recording moved-from and moved-to seperately
instead of ignoring it, why throw away such a perfectly useful
statistic. It would be really nice if I could get this data from 'git
log' (e.g., the lines-moved-from and lines-moved-to) instead of having
to calculate it myself.
> BTW I realized something else: your
> http://alturin.googlepages.com/full_activity.txt lists only
> "gitk-git/po/es.po" under git-git/po/. And it has as many added as
> deleted lines.
Correct, that's because that is what 'git log' tells me. Have a look at:
$ git log --pretty=format:%ae --numstat HEAD --
And grep for "\.po", you'll see that it lists the other po files under
"/po/de.po"
> So I suspect that "po/*" really lists both gitk's as well as git-gui's .po
> files, but merged together.
Feasible, if I use '-C -C -M' then the behavior on a directory rename
should be to take the found statistics under that directory and move
them too. That could be expensive though, what with having to search
all the keys whether they are affected and so.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: EGIT, was Re: [PATCH] Fix nullpointer exceptions in Quickdiff
From: Robin Rosenberg @ 2008-07-11 22:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
In-Reply-To: <alpine.DEB.1.00.0807112249010.8950@racer>
fredagen den 11 juli 2008 23.50.07 skrev Johannes Schindelin:
> Hi Andreas,
>
> On Fri, 11 Jul 2008, Robin Rosenberg wrote:
>
> >
> > ---
> > I saw some problem when resources were no longer in the worspace, such as during a bisectg.
> > This one should probably just be squashed into patch 1.
>
> This patch is for egit, before you ask.
>
> But be prepared for a lot of unmarked Windows discussion, somebody wants
> to shift msysGit's mail list payload to git@vger ;-)
Aaaaaaaaaaa.... I've take a leave now .)
-- robin
^ permalink raw reply
* Re: git cherry-pick before archive
From: Junio C Hamano @ 2008-07-11 22:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Denis Bueno, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111649290.8950@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Fri, 11 Jul 2008, Denis Bueno wrote:
>
>> I'm trying to use git archive to create a kind of "release" tarball of
>> my source. I've got a patch (a commit) that I'd like to apply to the
>> tree before I call git archive on HEAD. Currently my command is:
>>
>> git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
>>
>> If I were to actually modify my tree & history, I'd change the command to:
>>
>> git cherry-pick 97a1235ce674f7cf4df3129cd0ab1ae0793db392
>> git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
>> git reset --hard HEAD^
>>
>> But I'd rather not modify my history, if it's possible. (This will
>> create a bunch of dangling commit objects over time, no?)
>
> $ git cherry-pick -n <bla>
> $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
> $ git reset
That will create a bunch of dangling tree objects over time, yes.
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Junio C Hamano @ 2008-07-11 22:14 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: Linus Torvalds, Steffen Prohaska, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807112037220.8950@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 11 Jul 2008, Linus Torvalds wrote:
>
>> - It may well be good to explain to the _real_ git people (eg me) what
>> the problems in Windows land are, so that we get a first-hand view
>> into hell, and can maybe take it into account when we make changes
>> for other things.
>
> Wow. I did not think that you were a masochist.
It is not being masochist, but being practical by trying to know what to
avoid in advance.
>> IOW, I think that since 1.6.0 is supposed to have native support for
>> windows, we should have patches discussed on the regular git list. The
>> ghetto that is windows can be useful for _user_ discussions, where a lot
>> of the core git people simply cannot help. But having development
>> discussions there is bad, I think.
>
> We do have development discussions there that do not belong to git@vger.
Hannes did a great job with help from msysGit people to contain platform
specific stuff in compat/ layer. A good rule of thumb to decide what not
to talk about here is:
- If it is purely about implementation inside compat/ layer, such as
creating spawn() using Windows specific API, it is probably better done
on the msysGit list, where presumably more people whose has expertise
on the particular platform would hang around;
- If it is about "I downloaded msysgit prepackaged binary and this and
that does not work as I expect, I haven't bothered trying to build it
from source on POSIX systems and see if it is broken in the upstream",
the RFH does not belong here but platform specific forum. This applies
not just to Windows but to various distro binary distributions on Linux
as well.
On the other hand, even if it is related to porting to Windows, discussing
what the compat/ abstraction should look like is very relevant to this
list.
For example, I like is_absolute_path() abstraction you and Hannes pushed
for, but I have a slight distaste against has_dos_drive_prefix(). Some
uses of that macro is about telling if a string is a local file pathname
(e.g. connect()), and some other uses of that macro is about the fact that
on Windows you cannot necessarily make one path relative to another but
our code largely assume that any path can be made relative to any other
path (i.e. on traditional UNIX without "//", you can always make a path
relative by prefixing enough number of "../" to go up, even to root if
needed, but you cannot make C:\foo relative to D:\bar). We may be able to
find a better abstraction than what has_dos_drive_prefix() offers, and I
think that discussion belongs to here.
Another example that has already happened was our move away from direct
use of fork/exec but abstracting it out to run_command() layer. This
would not have settled in a shape usable by both Windows and POSIX if
people from both camps did not participate in the design and review.
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-11 22:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807112310140.8950@racer>
On Sat, Jul 12, 2008 at 12:11 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> The mechanism is this: you look up the email in .mailmap (actually you
> parse that once, but the idea stays the same), and if there is a name for
> it, you use that _instead of_ the given author name.
Ah, so you suggest changing "format:%ae" to "format:%ae %an" and
falling back to the latter id specified on that line if the former is
not in .mailmap? That would work I guess, I'll put it on my TODO list
:).
> Otherwise you use the given author name, and typos be damned.
Fair enough :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 22:11 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111455s127c5a35hfd3f01cc75614f65@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Sverre Rabbelier wrote:
> On Fri, Jul 11, 2008 at 11:39 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > something else I just realized: you might want to use .mailmap, e.g.
> > to coalesce the changes of Shawn "O." Pearce correctly.
>
> Ah, hmmm, but I'm not sure how, as not nearly every developer is in
> the .mailmap file and many devs use different e-mails while most use
> the same name. A similar file containing developer aliases maybe?
> E.g.:
> "Shawn Pearce = Shawn O. Pearce"?
The mechanism is this: you look up the email in .mailmap (actually you
parse that once, but the idea stays the same), and if there is a name for
it, you use that _instead of_ the given author name.
Otherwise you use the given author name, and typos be damned.
Ciao,
Dscho
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 22:10 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111505j36c42b6blec299d25d8c0ac9a@mail.gmail.com>
Hi,
On Sat, 12 Jul 2008, Sverre Rabbelier wrote:
> On Fri, Jul 11, 2008 at 11:55 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Fri, 11 Jul 2008, Johannes Schindelin wrote:
> >
> >> something else I just realized: you might want to use .mailmap, e.g.
> >> to coalesce the changes of Shawn "O." Pearce correctly.
> >
> > Yet another thing: while it is true that git-gui is usually pulled in
> > (with the subtree strategy), some parts were changed in git.git
> > directly, so you will need to cope with the wholesale rename with
> > every merge.
>
> I think I understand the cause, but I'm not sure I understand the
> consequences? Will some files at some times appear to be located at
> /path/to/file.txt and at other times at /subdir/path/to/file.txt? If
> so, how could I possibly handle that? How do I know that when it says
> /path/to/file.txt it means /subdir/path/to/file.txt instead?
>
> > Besides, it is slightly distracting to see the file names differently
> > from what they are in HEAD^{tree}. But that may be just me.
>
> Different how? In that it shows the contents of subdirs? For at least
> my repo this is a Very Good Thing (tm) as all my source-code is in a
> /src directory. If all changes to subdirs were aggregated I wouldn't
> get any useful metrics at all. Or am I misunderstanding the difference
> between the current output and that of HEAD^{tree}?
What I meant is this: you list "git-gui.sh", while I would have expected
"git-gui/git-gui.sh".
So you might need to rename the keys of your aggregating dict (I haven't
looked at the code, but suspect that's how you do it) with renaming
commits (including the merge commits).
Ciao,
Dscho
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 22:07 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111452x778759d4jd6ac71338974018e@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Sverre Rabbelier wrote:
> On Fri, Jul 11, 2008 at 11:22 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Fri, 11 Jul 2008, Sverre Rabbelier wrote:
> >
> > I think quite a lot of our changes do code moves; this should be
> > accounted for differently.
>
> Yeah, I wish 'git log -C -C -M --numstat --sacrifice-chicken
> --pretty=format:%ae --' would take care of that... That is, a git-blame
> like mechanism that would detect such moves on a per-commit basis and
> report them would be very useful to me.
Well, the chicken (or better, a goat) should be sacrificed by you... The
option I would call "--code-moves".
But the semantics of that need to be sorted out in a shell script first;
maybe like I outlined (if that was not coherent, please say so).
> >> For some reason you people can't seem to make up your mind about a
> >> file that's not even 1500 lines in size ;).
> >
> > Heh. We might need to change it once or twice, in the future.
>
> *chuckles*, I'm curious why the Makefile is such a hard file to get
> right :).
Well, it is not a matter of getting it right, but it is a matter of
changes. For example, everytime we move code from one program into the
library, and create a file for that, code changes.
Everytime we realize that we need to set some special settings for a
platform, the Makefile needs to be changed.
Everytime a shell script is added, or converted to a builtin, the Makefile
needs to be changed.
We are lucky that our maintainer is such a good shell hacker, otherwise
every version number change, you guessed it, would need the Makefile to be
changed.
> >> A note is in order here, this data was mined with "git log
> >> --num-stat" so things like moving files and copying files are not
> >> accounted for.
> >
> > In my opinion it would be even more interesting to see code moves
> > (i.e. not whole files). For example, we moved some stuff from
> > builtins into the library. The real change here is not in the lines
> > added and deleted.
>
> Very much so, but the former I figure can be easily done with 'git log
> -C -C -M' I discovered (I need to parse it's output though, and also
> determine what to do with moves statistics wise. Should changes made
> due to moves just be ignored?)
That is not very interesting, as we often move so small parts (think "one
function") that -C -C -M does not trigger.
> >> I thought about using git-blame to gather this info before, but it is
> >> not the right tool for the job. If anyone else has any idea's on what
> >> would be better please let me know and I'll happily dig into it :).
> >
> > I think that you need to analyze the diff directly. One possible (quick
> > 'n dirty) way would be to cut out long consecutive "+" parts of the hunks,
> > replace the "-" by "+", and use "git diff --no-index" to do the hard part
> > of searching for that code in the "-" part of the original diff.
>
> That sounds interesting, I won't need to actually do that though, I
> already have a diff parser that gives me the lines added VS lines
> deleted on a hunk-by-hunk basis. If it is a true move (e.g., code
> removed in file X and added in file Y) it should be trivial to detect
> that.
> Something along the lines of:
> for hunk in added:
> if hunk in deleted:
> print("Over here!!")
I think that is not enough, as a code move can mean that part of a
function was refactored into a function. The consequence is often a
reindent, and possibly rewrapping.
And it can mean that some lines have to be inserted here and there. I
still would count that as a code move "with touch-ups".
So I'd like to see something like
<number-of-commits>: <lines-added> <lines-removed> \
<lines-moved-from> <lines-moved-to> <filename>
BTW I realized something else: your
http://alturin.googlepages.com/full_activity.txt lists only
"gitk-git/po/es.po" under git-git/po/. And it has as many added as
deleted lines.
So I suspect that "po/*" really lists both gitk's as well as git-gui's .po
files, but merged together.
Ciao,
Dscho
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-11 22:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807112252250.8950@racer>
On Fri, Jul 11, 2008 at 11:55 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 11 Jul 2008, Johannes Schindelin wrote:
>
>> something else I just realized: you might want to use .mailmap, e.g. to
>> coalesce the changes of Shawn "O." Pearce correctly.
>
> Yet another thing: while it is true that git-gui is usually pulled in
> (with the subtree strategy), some parts were changed in git.git directly,
> so you will need to cope with the wholesale rename with every merge.
I think I understand the cause, but I'm not sure I understand the
consequences? Will some files at some times appear to be located at
/path/to/file.txt and at other times at /subdir/path/to/file.txt? If
so, how could I possibly handle that? How do I know that when it says
/path/to/file.txt it means /subdir/path/to/file.txt instead?
> Besides, it is slightly distracting to see the file names differently from
> what they are in HEAD^{tree}. But that may be just me.
Different how? In that it shows the contents of subdirs? For at least
my repo this is a Very Good Thing (tm) as all my source-code is in a
/src directory. If all changes to subdirs were aggregated I wouldn't
get any useful metrics at all. Or am I misunderstanding the difference
between the current output and that of HEAD^{tree}?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-11 21:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807112238350.8950@racer>
Heya,
On Fri, Jul 11, 2008 at 11:39 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> something else I just realized: you might want to use .mailmap, e.g. to
> coalesce the changes of Shawn "O." Pearce correctly.
Ah, hmmm, but I'm not sure how, as not nearly every developer is in
the .mailmap file and many devs use different e-mails while most use
the same name. A similar file containing developer aliases maybe?
E.g.:
"Shawn Pearce = Shawn O. Pearce"?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 21:55 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807112238350.8950@racer>
Hi,
On Fri, 11 Jul 2008, Johannes Schindelin wrote:
> something else I just realized: you might want to use .mailmap, e.g. to
> coalesce the changes of Shawn "O." Pearce correctly.
Yet another thing: while it is true that git-gui is usually pulled in
(with the subtree strategy), some parts were changed in git.git directly,
so you will need to cope with the wholesale rename with every merge.
Besides, it is slightly distracting to see the file names differently from
what they are in HEAD^{tree}. But that may be just me.
Ciao,
Dscho
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-11 21:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807112215050.8950@racer>
On Fri, Jul 11, 2008 at 11:22 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 11 Jul 2008, Sverre Rabbelier wrote:
>
>> I temporarily modified the code to output %04d instead of %4d so that I
>> could do the following:
>>
>> $ stats.py author -a > full_activity_sortable.txt
>
> You might be delighted to read up on the "-n" switch to sort(1).
Heh, yes, very much so :). I probably shouldof known there is such an
option, but having the source at hand the change to '%4d' was the
first thing that came to mind.
>> A few highlights from the sorted file:
>>
>> $ cat full_activity_sortable.txt | sort | tail -n 20
>
> More intuitive would have been "sort -r | head -n 20", I guess.
Since that wouldof put the 'number one' at the top? Yeah, I guess it
wouldof, nice one.
>> 0170: 2721+ 1060- = refs.c
>
> I guess that 170 is the total number of commit touching that file, the "+"
> and "-" numbers the changes respectively?
Correct, I probably should have explain that. The +es are how many
lines were added and the -es are the total amount of lines that were
deleted, yup.
> I think quite a lot of our changes do code moves; this should be accounted
> for differently.
Yeah, I wish 'git log -C -C -M --numstat --sacrifice-chicken
--pretty=format:%ae --' would take care of that... That is, a
git-blame like mechanism that would detect such moves on a per-commit
basis and report them would be very useful to me.
>> For some reason you people can't seem to make up your mind about a
>> file that's not even 1500 lines in size ;).
>
> Heh. We might need to change it once or twice, in the future.
*chuckles*, I'm curious why the Makefile is such a hard file to get right :).
>> A note is in order here, this data was mined with "git log --num-stat"
>> so things like moving files and copying files are not accounted for.
>
> In my opinion it would be even more interesting to see code moves (i.e.
> not whole files). For example, we moved some stuff from builtins into the
> library. The real change here is not in the lines added and deleted.
Very much so, but the former I figure can be easily done with 'git log
-C -C -M' I discovered (I need to parse it's output though, and also
determine what to do with moves statistics wise. Should changes made
due to moves just be ignored?)
>> I thought about using git-blame to gather this info before, but it is
>> not the right tool for the job. If anyone else has any idea's on what
>> would be better please let me know and I'll happily dig into it :).
>
> I think that you need to analyze the diff directly. One possible (quick
> 'n dirty) way would be to cut out long consecutive "+" parts of the hunks,
> replace the "-" by "+", and use "git diff --no-index" to do the hard part
> of searching for that code in the "-" part of the original diff.
That sounds interesting, I won't need to actually do that though, I
already have a diff parser that gives me the lines added VS lines
deleted on a hunk-by-hunk basis. If it is a true move (e.g., code
removed in file X and added in file Y) it should be trivial to detect
that.
Something along the lines of:
for hunk in added:
if hunk in deleted:
print("Over here!!")
> Just an idea,
Much appreciated! I will look into this.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* EGIT, was Re: [PATCH] Fix nullpointer exceptions in Quickdiff
From: Johannes Schindelin @ 2008-07-11 21:50 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <200807112334.47552.robin.rosenberg@dewire.com>
Hi Andreas,
On Fri, 11 Jul 2008, Robin Rosenberg wrote:
>
> ---
> I saw some problem when resources were no longer in the worspace, such as during a bisectg.
> This one should probably just be squashed into patch 1.
This patch is for egit, before you ask.
But be prepared for a lot of unmarked Windows discussion, somebody wants
to shift msysGit's mail list payload to git@vger ;-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix nullpointer exceptions in Quickdiff
From: Robin Rosenberg @ 2008-07-11 21:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Marek Zawirski
In-Reply-To: <1215729672-26906-2-git-send-email-robin.rosenberg@dewire.com>
---
I saw some problem when resources were no longer in the worspace, such as during a bisectg.
This one should probably just be squashed into patch 1.
-- robin
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
index ebed0cf..3724304 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
@@ -43,7 +43,10 @@ class GitDocument extends Document implements RepositoryListener {
void populate() throws IOException {
set("");
final IProject project = resource.getProject();
- final String gitPath = RepositoryMapping.getMapping(project).getRepoRelativePath(resource);
+ RepositoryMapping mapping = RepositoryMapping.getMapping(project);
+ if (mapping == null)
+ return;
+ final String gitPath = mapping.getRepoRelativePath(resource);
final Repository repository = getRepository();
repository.addRepositoryChangedListener(this);
String baseline = GitQuickDiffProvider.baseline.get(repository);
@@ -63,7 +66,9 @@ class GitDocument extends Document implements RepositoryListener {
}
void dispose() {
- getRepository().removeRepositoryChangedListener(this);
+ Repository repository = getRepository();
+ if (repository != null)
+ repository.removeRepositoryChangedListener(this);
}
public void refsChanged(final RefsChangedEvent e) {
@@ -81,6 +86,8 @@ class GitDocument extends Document implements RepositoryListener {
private Repository getRepository() {
IProject project = resource.getProject();
RepositoryMapping mapping = RepositoryMapping.getMapping(project);
- return mapping.getRepository();
+ if (mapping != null)
+ return mapping.getRepository();
+ return null;
}
}
--
1.5.6.2.220.g44701
^ permalink raw reply related
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 21:39 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807112215050.8950@racer>
Hi,
something else I just realized: you might want to use .mailmap, e.g. to
coalesce the changes of Shawn "O." Pearce correctly.
Ciao,
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 21:38 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Linus Torvalds, Johannes Sixt, Junio C Hamano, msysGit,
Git Mailing List
In-Reply-To: <0E93411E-745C-4858-999E-F0B7487B48B1@zib.de>
Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> On Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote:
>
> >On Fri, 11 Jul 2008, Linus Torvalds wrote:
> >
> > >- It may well be good to explain to the _real_ git people (eg me)
> > > what the problems in Windows land are, so that we get a first-hand
> > > view into hell, and can maybe take it into account when we make
> > > changes for other things.
> >
> >Wow. I did not think that you were a masochist.
> >
> > >IOW, I think that since 1.6.0 is supposed to have native support for
> > >windows, we should have patches discussed on the regular git list.
> > >The ghetto that is windows can be useful for _user_ discussions,
> > >where a lot of the core git people simply cannot help. But having
> > >development discussions there is bad, I think.
> >
> >We do have development discussions there that do not belong to
> >git@vger. For example, when Hannes reimplemented the utterly broken
> >spawn() implementation of Microsoft's "Run" time library.
> >
> >That is not something you need to see, want to see, or can help with.
>
> The separation is not always that clear. For example, the discussion
> of issue 130 might benefit from "a first-hand view into hell",
Maybe I am overly cautious, but you remember what drove me away from
msysGit? Exactly, people, and issues, took out all the fun.
Let's not inflict upon git@vger what they did not deserve to suffer.
And if the separation is not always that clear, why not discuss those
things on msysGit first, and then come to git@vger with our minds (and
possibly our patches) made up?
> Another example is the discussion about GIT_EXEC_PATH, see
>
> http://thread.gmane.org/gmane.comp.version-control.msysgit/2633
This is a particularly good example that does not matter for Linux,
MacOSX, Solaris or the BSDs (Git's principal platforms!) at all.
And once this patch hits git@vger, it is still visible to other platforms.
> A last example is the crash of gitk that was observed on Windows and is
> now buried in the msysGit issue tracker, although I am pretty sure that
> is it not windows-specific, see
>
> http://code.google.com/p/msysgit/issues/detail?id=125
So? If it did not hit other platforms, it is the duty of that guy to find
out what it is. And if it _does_ turn out to be a Windows-specific bug,
which might very well be the case, we do not need to add to the volume of
git@vger.
> >Likewise, I think it has nothing to do with the git@vger list when we
> >add work-arounds until some better solution is found, and then discuss
> >whether the workaround is still needed.
> >
> >I cannot help to see the benefit, at least.
> >
> >Once things are sorted out, I agree, it has to be sent to the git list.
> >
> >Before that, however, allow us to work on another list.
>
> Personally, I'd find it easier to work on a single list.
Sure the benefit is undisputed.
Now let's look at the downsides: we take away time, and possibly fun, from
many more people than one or two persons.
It's like spam. Asking somebody to "just hit the delete button" stops
being funny very quickly.
> MinGW support is mature enough and workarounds should now be avoid. If
> we tested git during the official release cycle, we would have
> sufficient time to find and solve problems on Windows and prepare
> patches that have sufficient quality to be discuss on git@vger.
I am not so sure.
Your experience should match mine, that the patches coming in through
msysGit are of a substantial lower quality than what we are used to on
git@vger.
If you want to force those patches unfiltered onto the readers of
git@vger, it would only be fair that you have to clean the readers' latest
lunch out of their keyboards.
Ciao,
Dscho "who has a fata morgana of windmills"
^ permalink raw reply
* Re: [StGIT] Failure to install on RHELWS4
From: Catalin Marinas @ 2008-07-11 21:35 UTC (permalink / raw)
To: Miklos Vajna
Cc: Thomas Rast, Petr Baudis, Git Mailing List, Karl Hasselström
In-Reply-To: <20080711200735.GK10347@genesis.frugalware.org>
2008/7/11 Miklos Vajna <vmiklos@frugalware.org>:
> On Fri, Jul 11, 2008 at 09:26:29PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
>> > pyver = '.'.join(str(n) for n in sys.version_info)
>> > ^
>> [...]
>> > Python version is 2.3.4
>>
>> That is indeed too old. Generator expressions like the above were
>> introduced in 2.4:
>>
>> http://www.python.org/dev/peps/pep-0289/
>
> So obviously it's a bad idea to use generators for such a version check.
Yes, I agree.
> Also, setup.py would try to import stgit.run before the version check.
>
> I'm sending two patches, which restore the wished "Python version 2.4 or
> newer required. Found 2.2.1.final.0" error message.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] git-rebase.sh: Display error output from git-checkout when detaching HEAD fails.
From: Robert Shearman @ 2008-07-11 21:26 UTC (permalink / raw)
To: git; +Cc: Robert Shearman
The "git checkout" command executed could fail if, for example, upstream contains a file that would overrwrite a local, untracked file. The output redirection didn't work as stderr was redirected to /dev/null, as was stdout. This appears to be not what was intended so the order of redirections is fixed so that stderr is redirected to stdout instead.
---
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..0da2210 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -376,7 +376,7 @@ fi
# Detach HEAD and reset the tree
echo "First, rewinding head to replay your work on top of it..."
-git checkout "$onto^0" >/dev/null 2>&1 ||
+git checkout "$onto^0" 2>&1 >/dev/null ||
die "could not detach HEAD"
# git reset --hard "$onto^0"
--
1.5.6.2.225.g4596.dirty
^ permalink raw reply related
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 21:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111404y1d3dd48ao6d2903da4cd1aa56@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Sverre Rabbelier wrote:
> I temporarily modified the code to output %04d instead of %4d so that I
> could do the following:
>
> $ stats.py author -a > full_activity_sortable.txt
You might be delighted to read up on the "-n" switch to sort(1).
> A few highlights from the sorted file:
>
> $ cat full_activity_sortable.txt | sort | tail -n 20
More intuitive would have been "sort -r | head -n 20", I guess.
> 0170: 2721+ 1060- = refs.c
I guess that 170 is the total number of commit touching that file, the "+"
and "-" numbers the changes respectively?
I think quite a lot of our changes do code moves; this should be accounted
for differently.
> 0172: 4369+ 2004- = builtin-pack-objects.c
> 0177: 345+ 233- = GIT-VERSION-GEN
> 0178: 2855+ 2121- = commit.c
> 0178: 4779+ 2227- = fast-import.c
> 0179: 2677+ 1400- = read-cache.c
> 0185: 5661+ 2056- = builtin-apply.c
> 0186: 3269+ 1255- = revision.c
> 0213: 1884+ 460- = Documentation/config.txt
> 0232: 2257+ 1621- = Documentation/git.txt
> 0236: 3990+ 1991- = contrib/fast-import/git-p4
> 0281: 2753+ 2220- = git.c
> 0333: 10259+ 7150- = git-gui.sh
> 0338: 11337+ 6187- = git-svn.perl
> 0338: 5755+ 3159- = sha1_file.c
> 0397: 10230+ 9599- = diff.c
> 0412: 23248+ 20257- = gitk
> 0432: 10580+ 4502- = gitweb/gitweb.perl
> 0490: 1412+ 619- = cache.h
> 0977: 4703+ 2705- = Makefile
>
> $ cat Makefile | wc -l
> 1482
>
> For some reason you people can't seem to make up your mind about a
> file that's not even 1500 lines in size ;).
Heh. We might need to change it once or twice, in the future.
> A note is in order here, this data was mined with "git log --num-stat"
> so things like moving files and copying files are not accounted for.
In my opinion it would be even more interesting to see code moves (i.e.
not whole files). For example, we moved some stuff from builtins into the
library. The real change here is not in the lines added and deleted.
> I thought about using git-blame to gather this info before, but it is
> not the right tool for the job. If anyone else has any idea's on what
> would be better please let me know and I'll happily dig into it :).
I think that you need to analyze the diff directly. One possible (quick
'n dirty) way would be to cut out long consecutive "+" parts of the hunks,
replace the "-" by "+", and use "git diff --no-index" to do the hard part
of searching for that code in the "-" part of the original diff.
If that turns out to be useful, we can still think about a proper API
using xdiff.
Just an idea,
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Steffen Prohaska @ 2008-07-11 21:10 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Johannes Sixt, Junio C Hamano, msysGit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807112037220.8950@racer>
On Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote:
> On Fri, 11 Jul 2008, Linus Torvalds wrote:
>
>> - It may well be good to explain to the _real_ git people (eg me)
>> what
>> the problems in Windows land are, so that we get a first-hand view
>> into hell, and can maybe take it into account when we make changes
>> for other things.
>
> Wow. I did not think that you were a masochist.
>
>> IOW, I think that since 1.6.0 is supposed to have native support for
>> windows, we should have patches discussed on the regular git list.
>> The
>> ghetto that is windows can be useful for _user_ discussions, where
>> a lot
>> of the core git people simply cannot help. But having development
>> discussions there is bad, I think.
>
> We do have development discussions there that do not belong to
> git@vger.
> For example, when Hannes reimplemented the utterly broken spawn()
> implementation of Microsoft's "Run" time library.
>
> That is not something you need to see, want to see, or can help with.
The separation is not always that clear. For example, the discussion
of issue 130 might benefit from "a first-hand view into hell", see
http://thread.gmane.org/gmane.comp.version-control.msysgit/2653/focus=2682
Another example is the discussion about GIT_EXEC_PATH, see
http://thread.gmane.org/gmane.comp.version-control.msysgit/2633
It might be triggered by msysGit's need to freely move a git
installation
in the filesystem. The resulting feature might however be interesting
on
other platforms, too.
A last example is the crash of gitk that was observed on Windows and is
now buried in the msysGit issue tracker, although I am pretty sure that
is it not windows-specific, see
http://code.google.com/p/msysgit/issues/detail?id=125
> Likewise, I think it has nothing to do with the git@vger list when
> we add
> work-arounds until some better solution is found, and then discuss
> whether
> the workaround is still needed.
>
> I cannot help to see the benefit, at least.
>
> Once things are sorted out, I agree, it has to be sent to the git
> list.
>
> Before that, however, allow us to work on another list.
Personally, I'd find it easier to work on a single list. MinGW support
is mature enough and workarounds should now be avoid. If we tested git
during the official release cycle, we would have sufficient time to find
and solve problems on Windows and prepare patches that have sufficient
quality to be discuss on git@vger.
Steffen
^ permalink raw reply
* [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-11 21:04 UTC (permalink / raw)
To: Git Mailinglist; +Cc: David Symonds
In-Reply-To: <bd6139dc0807090621n308b0159n92d946c165d3a5dd@mail.gmail.com>
[I sent this mail earlier, but I think vger rejected it due to the
size of the attachments, I have uploaded them instead now, they can be
found at:
http://alturin.googlepages.com/activity_per_author.txt
http://alturin.googlepages.com/full_activity.txt ]
Heya,
Today I sat down and finished the activity aggregation code. Now it is
possible to generate the attached files with the following commands:
$ stats.py author -e --id=an > activity_per_author.txt
$ stats.py author -a > full_activity.txt
The first one calculates the activity of all developers on a per-file
basis and dumps it into the file. The "--id=an" switch sets the
grouping field to "%an" (see man git-log), since the default (%ae) is
not that helpful for git.git (I don't know people by their e-mail, I
know them by their name). This was already possible (with "author
-d"), but before one had to pick a specific developer, now it will
show for _all_ developers.This is interesting stuff, although for a
huge project like git it's a bit much to take in. What is probably
more interesting is the second command, it shows how much change a
file has had in it's existence.
I temporarily modified the code to output %04d instead of %4d so that
I could do the following:
$ stats.py author -a > full_activity_sortable.txt
A few highlights from the sorted file:
$ cat full_activity_sortable.txt | sort | tail -n 20
0170: 2721+ 1060- = refs.c
0172: 4369+ 2004- = builtin-pack-objects.c
0177: 345+ 233- = GIT-VERSION-GEN
0178: 2855+ 2121- = commit.c
0178: 4779+ 2227- = fast-import.c
0179: 2677+ 1400- = read-cache.c
0185: 5661+ 2056- = builtin-apply.c
0186: 3269+ 1255- = revision.c
0213: 1884+ 460- = Documentation/config.txt
0232: 2257+ 1621- = Documentation/git.txt
0236: 3990+ 1991- = contrib/fast-import/git-p4
0281: 2753+ 2220- = git.c
0333: 10259+ 7150- = git-gui.sh
0338: 11337+ 6187- = git-svn.perl
0338: 5755+ 3159- = sha1_file.c
0397: 10230+ 9599- = diff.c
0412: 23248+ 20257- = gitk
0432: 10580+ 4502- = gitweb/gitweb.perl
0490: 1412+ 619- = cache.h
0977: 4703+ 2705- = Makefile
$ cat Makefile | wc -l
1482
For some reason you people can't seem to make up your mind about a
file that's not even 1500 lines in size ;). With almost a thousand
edits so far, it's been edited so many times it could've been written
from scratch three times (except that the amount of lines deleted
doesn't match). Also interesting to note is that the "external" files
such as gitweb, gitk, git-gui and git-svn make up the bulk of all
changes. The two contenders from the native git camp are diff.c and
sha1_file.c which both have a lot of LOC. This information is
interesting for GitStats as it might help determine which files have
had a lot of change, and which files are not touched a lot.
A note is in order here, this data was mined with "git log --num-stat"
so things like moving files and copying files are not accounted for. I
thought about using git-blame to gather this info before, but it is
not the right tool for the job. If anyone else has any idea's on what
would be better please let me know and I'll happily dig into it :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Install GIT?
From: Petr Baudis @ 2008-07-11 21:00 UTC (permalink / raw)
To: mike zheng; +Cc: git
In-Reply-To: <5c9cd53b0807111355u7a346dafne6a3b7bd75d5100e@mail.gmail.com>
Hi,
On Fri, Jul 11, 2008 at 04:55:12PM -0400, mike zheng wrote:
> is there any document on how to compile and install git? Which package
> shall I download from http://www.kernel.org/pub/software/scm/git/?
get the latest version. ;-) That is,
http://www.kernel.org/pub/software/scm/git/git-1.5.6.2.tar.bz2
right now.
> What is the steps to compile each of them?
It is described in the INSTALL file at the project root:
http://repo.or.cz/w/git.git?a=blob;f=INSTALL
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Install GIT?
From: mike zheng @ 2008-07-11 20:55 UTC (permalink / raw)
To: git
hello,
is there any document on how to compile and install git? Which package
shall I download from http://www.kernel.org/pub/software/scm/git/?
What is the steps to compile each of them?
thanks in advance,
mike
^ 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