* Re: [PATCH] Add pretty format %aN which gives the author name, respecting .mailmap
From: Johannes Schindelin @ 2008-07-11 23:42 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: gitster, Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111630j306f0225m90b501296a508552@mail.gmail.com>
Hi,
On Sat, 12 Jul 2008, Sverre Rabbelier wrote:
> On Sat, Jul 12, 2008 at 1:28 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > The pretty format %an does not respect .mailmap, but gives the exact
> > author name recorded in the commit. Sometimes it is more desirable,
> > however, to look if the email has another name mapped to it in
> > .mailmap.
> >
> > This commit adds %aN (and %cN for the committer name) to do exactly
> > that.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
>
> Whoah, that's fast ;).
Heh. The price is that my patches are usually more buggy than other
contributors' patches.
> I'm not sure what to do though, if I use this new %cN GitStats will
> only work with the latest git version... :(
Yes, that is correct. But my impression was that GitStats was never meant
as a pure add-on, but rather some integral part of Git, no? IOW at least
contrib/ stuff.
Ciao,
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Linus Torvalds @ 2008-07-11 23:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Steffen Prohaska, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807120033490.8950@racer>
On Sat, 12 Jul 2008, Johannes Schindelin wrote:
>
> I think that is a perfect example, since Hannes worked on it in mingw.git.
> AFAIR a few comments came through msysGit, and were incorporated. When
> everything was good for a first go at git@vger, it was sent, and the
> interface finalized.
Umm. Dscho - that was before the thing was merged.
Now that the basic mingw support is part of standard git, the situation
has changed.
That's the main issue here - if mingw support is in standard git (and it
is), then mingw issues that touch any non-mingw code should be discussed
where all the git developers are.
Can't you see the difference between the pre-merge and the post-merge
situation?
Linus
^ permalink raw reply
* [PATCHv2] Fix backwards-incompatible handling of core.sharedRepository
From: Petr Baudis @ 2008-07-11 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Heikki Orsila
The 06cbe8550324e0fd2290839bf3b9a92aa53b70ab core.sharedRepository
handling extension broke backwards compatibility; before, shared=1 meant
that Git merely ensured the repository is group-writable, not that it's
_only_ group-writable, which is the current behaviour. Thus, with umask 002,
Git creates repository with /rw.rw.--./, this patch fixes it back to
/rw.rw.r-./.
Maybe it makes sense to provide the current semantics in some way too,
but that cannot be done at the expense of ditching backwards
compatibility; this bug has just wasted me two hours and broke
repo.or.cz pushing for several hours.
Cc: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Petr Baudis <pasky@rover.dkm.cz>
---
The patch description is clarified and a test is added to t1301.
path.c | 2 +-
t/t1301-shared-repo.sh | 19 +++++++++++++++++++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/path.c b/path.c
index 5983255..75c5915 100644
--- a/path.c
+++ b/path.c
@@ -269,7 +269,7 @@ int adjust_shared_perm(const char *path)
mode = st.st_mode;
if (shared_repository) {
- int tweak = shared_repository;
+ int tweak = (mode & 0777) | shared_repository;
if (!(mode & S_IWUSR))
tweak &= ~0222;
mode = (mode & ~0777) | tweak;
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index 6c78c8b..d26191b 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -17,6 +17,25 @@ test_expect_success 'shared = 0400 (faulty permission u-w)' '
test $ret != "0"
'
+test_expect_success 'shared=1 does not override sane umask' '
+ mkdir sub &&
+ cd sub &&
+ umask 002 &&
+ git init --shared=1 &&
+ test 1 = $(git config core.sharedrepository) &&
+ actual="$(ls -l .git/HEAD)" &&
+ rm -rf sub &&
+ case "$actual" in
+ -rw-rw-r--*)
+ : happy
+ ;;
+ *)
+ echo Oops, .git/HEAD is not 0664 but $actual
+ false
+ ;;
+ esac
+'
+
test_expect_success 'shared=all' '
mkdir sub &&
cd sub &&
^ permalink raw reply related
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 23:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steffen Prohaska, Linus Torvalds, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <7vmykohvfy.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 11 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > 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?
>
> I know you mean well, but my impression from reading the kernel list is
> that often a message that says "we already debated this issue on our
> list to death and here is our conclusion, take it or leave it" to the
> audience is not accepted warmly, and more central kernel people may even
> say "do not hide the discussion in the subsystem list, do it in the
> open, discussion on the subsystem list does not matter".
I never meant on insisting that we find the final solution on the msysGit
list, and I would _never_ suggest that anything sent to git@vger is final.
It is always subject to discussion.
Anyway, enough said (since I think that you and me are in agreement here),
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 23:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Steffen Prohaska, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <7v4p6wjcgm.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 11 Jul 2008, Junio C Hamano wrote:
> 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.
I think that is a perfect example, since Hannes worked on it in mingw.git.
AFAIR a few comments came through msysGit, and were incorporated. When
everything was good for a first go at git@vger, it was sent, and the
interface finalized.
And I agree that it is a pretty beautiful interface.
Ciao,
Dscho
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 23:33 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111550w1f4a9e5fl636df73572bd27de@mail.gmail.com>
Hi,
On Sat, 12 Jul 2008, Sverre Rabbelier wrote:
> 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).
If you were suspecting that I would write the patch once the semantics are
finalized, you would be absolutely correct.
> > 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.
Fair enough. As long as you use a language that is easy to prototype
quickly and dirtily in. Such as Python.
> >> 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'.
Let's go for it, then!
> >> 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 :).
That is why I was suggesting using the diff tool with munged input to find
out what works best.
When that is done, I'll turn it into C.
> > 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.
I suspect that one big "git log" will not tell you enough. You probably
need to make your tool aware (at least a little) about merges, just as you
probably made it aware about parent/child relationships (to track the
changes along renames)...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add pretty format %aN which gives the author name, respecting .mailmap
From: Sverre Rabbelier @ 2008-07-11 23:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807120027330.8950@racer>
On Sat, Jul 12, 2008 at 1:28 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> The pretty format %an does not respect .mailmap, but gives the exact
> author name recorded in the commit. Sometimes it is more desirable,
> however, to look if the email has another name mapped to it in .mailmap.
>
> This commit adds %aN (and %cN for the committer name) to do exactly that.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Whoah, that's fast ;).
I'm not sure what to do though, if I use this new %cN GitStats will
only work with the latest git version... :(
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Add pretty format %aN which gives the author name, respecting .mailmap
From: Johannes Schindelin @ 2008-07-11 23:28 UTC (permalink / raw)
To: Sverre Rabbelier, gitster; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807120000580.8950@racer>
The pretty format %an does not respect .mailmap, but gives the exact
author name recorded in the commit. Sometimes it is more desirable,
however, to look if the email has another name mapped to it in .mailmap.
This commit adds %aN (and %cN for the committer name) to do exactly that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 12 Jul 2008, Johannes Schindelin wrote:
> 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.
Documentation/pretty-formats.txt | 2 ++
pretty.c | 27 +++++++++++++++++++++++++--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 69e6d2f..c11d495 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -101,6 +101,7 @@ The placeholders are:
- '%P': parent hashes
- '%p': abbreviated parent hashes
- '%an': author name
+- '%aN': author name (respecting .mailmap)
- '%ae': author email
- '%ad': author date
- '%aD': author date, RFC2822 style
@@ -108,6 +109,7 @@ The placeholders are:
- '%at': author date, UNIX timestamp
- '%ai': author date, ISO 8601 format
- '%cn': committer name
+- '%cN': committer name (respecting .mailmap)
- '%ce': committer email
- '%cd': committer date
- '%cD': committer date, RFC2822 style
diff --git a/pretty.c b/pretty.c
index 8eb39e9..862364b 100644
--- a/pretty.c
+++ b/pretty.c
@@ -3,6 +3,8 @@
#include "utf8.h"
#include "diff.h"
#include "revision.h"
+#include "path-list.h"
+#include "mailmap.h"
static char *user_format;
@@ -288,6 +290,25 @@ static char *logmsg_reencode(const struct commit *commit,
return out;
}
+static int mailmap_name(struct strbuf *sb, const char *email)
+{
+ static struct path_list *mail_map;
+ char buffer[1024];
+
+ if (!mail_map) {
+ mail_map = xcalloc(1, sizeof(*mail_map));
+ read_mailmap(mail_map, ".mailmap", NULL);
+ }
+
+ if (!mail_map->nr)
+ return -1;
+
+ if (!map_email(mail_map, email, buffer, sizeof(buffer)))
+ return -1;
+ strbuf_addstr(sb, buffer);
+ return 0;
+}
+
static size_t format_person_part(struct strbuf *sb, char part,
const char *msg, int len)
{
@@ -309,10 +330,12 @@ static size_t format_person_part(struct strbuf *sb, char part,
if (end >= len - 2)
goto skip;
- if (part == 'n') { /* name */
+ if (part == 'n' || part == 'N') { /* name */
while (end > 0 && isspace(msg[end - 1]))
end--;
- strbuf_add(sb, msg, end);
+ if (part != 'N' || !msg[end] || !msg[end + 1] ||
+ mailmap_name(sb, msg + end + 2) < 0)
+ strbuf_add(sb, msg, end);
return placeholder_len;
}
start = ++end; /* save email start position */
--
1.5.6.2.509.g109edf
^ permalink raw reply related
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Junio C Hamano @ 2008-07-11 23:06 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Linus Torvalds, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807112226190.8950@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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?
I know you mean well, but my impression from reading the kernel list is
that often a message that says "we already debated this issue on our list
to death and here is our conclusion, take it or leave it" to the audience
is not accepted warmly, and more central kernel people may even say "do
not hide the discussion in the subsystem list, do it in the open,
discussion on the subsystem list does not matter".
Taking that lesson from the other community, I'd suggest that it is
probably a good idea to start discussion on your list, but once (some)
people in the discussion think the topic is releavant here, move it here
sooner rather than later.
^ permalink raw reply
* 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
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