* [PATCH 2/5] wt-status: refactor initial commit printing
From: Jeff King @ 2008-11-12 8:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <20081112081609.GA3720@coredump.intra.peff.net>
When we showed the initial commit, we had no reference to
diff against, so we went through the cache manually.
Nowadays, however, we have a virtual empty tree commit, so
we can simply diff against that to get the same results.
Signed-off-by: Jeff King <peff@peff.net>
---
I ran across this when I realized I could do the same trick for the
verbose diff (which I will do in the next patch). I think it is a
worthwhile cleanup. Not only does it remove a lot of lines, but it gives
a single codepath for printing, which will be helpful if that codepath
ever changes (e.g., with the alternate status formats we talked about a
few weeks ago).
This could be made even simpler by setting s->reference to the empty
tree when we are on the initial commit, but I think that is a little
messy. The caller may have set s->reference to an arbitrary pointer,
including one which needs free()d, and we would be overwriting that.
As it happens, with the current callers there is no problem, but it
seems like a bad interface.
wt-status.c | 28 +++-------------------------
1 files changed, 3 insertions(+), 25 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 6a7645e..c78588e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -185,31 +185,12 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
wt_status_print_trailer(s);
}
-static void wt_status_print_initial(struct wt_status *s)
-{
- int i;
- struct strbuf buf = STRBUF_INIT;
-
- if (active_nr) {
- s->commitable = 1;
- wt_status_print_cached_header(s);
- }
- for (i = 0; i < active_nr; i++) {
- color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
- color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
- quote_path(active_cache[i]->name, -1,
- &buf, s->prefix));
- }
- if (active_nr)
- wt_status_print_trailer(s);
- strbuf_release(&buf);
-}
-
static void wt_status_print_updated(struct wt_status *s)
{
struct rev_info rev;
init_revisions(&rev, NULL);
- setup_revisions(0, NULL, &rev, s->reference);
+ setup_revisions(0, NULL, &rev,
+ s->is_initial ? EMPTY_TREE_SHA1_HEX : s->reference);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = wt_status_print_updated_cb;
rev.diffopt.format_callback_data = s;
@@ -360,12 +341,9 @@ void wt_status_print(struct wt_status *s)
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "# Initial commit");
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
- wt_status_print_initial(s);
- }
- else {
- wt_status_print_updated(s);
}
+ wt_status_print_updated(s);
wt_status_print_changed(s);
if (wt_status_submodule_summary)
wt_status_print_submodule_summary(s);
--
1.6.0.4.883.g4593ee.dirty
^ permalink raw reply related
* [PATCH 3/5] status: show "-v" diff even for initial commit
From: Jeff King @ 2008-11-12 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <20081112081609.GA3720@coredump.intra.peff.net>
Since we can use the same "diff against empty tree" trick as
we do for the non-initial case, it is trivial to make this
work.
Signed-off-by: Jeff King <peff@peff.net>
---
I ran across this while writing my test cases for the later patches. I
don't see any reason why it shouldn't behave this way, and I suspect the
reason was just that the original author saw how we did
"wt_status_print_initial" and didn't want to have to do the equivalent
for generating diff output.
t/t7507-commit-verbose.sh | 29 +++++++++++++++++++++++++++++
wt-status.c | 5 +++--
2 files changed, 32 insertions(+), 2 deletions(-)
create mode 100755 t/t7507-commit-verbose.sh
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
new file mode 100755
index 0000000..94b12e9
--- /dev/null
+++ b/t/t7507-commit-verbose.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+test_description='verbose commit template'
+. ./test-lib.sh
+
+cat >check-for-diff <<EOF
+#!$SHELL_PATH
+exec grep '^diff --git' "\$1"
+EOF
+chmod +x check-for-diff
+test_set_editor "$PWD/check-for-diff"
+
+cat >message <<'EOF'
+subject
+
+body
+EOF
+
+test_expect_success 'setup' '
+ echo content >file &&
+ git add file &&
+ git commit -F message
+'
+
+test_expect_success 'initial commit shows verbose diff' '
+ git commit --amend -v
+'
+
+test_done
diff --git a/wt-status.c b/wt-status.c
index c78588e..3edae43 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -279,7 +279,8 @@ static void wt_status_print_verbose(struct wt_status *s)
struct rev_info rev;
init_revisions(&rev, NULL);
- setup_revisions(0, NULL, &rev, s->reference);
+ setup_revisions(0, NULL, &rev,
+ s->is_initial ? EMPTY_TREE_SHA1_HEX : s->reference);
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
rev.diffopt.detect_rename = 1;
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
@@ -352,7 +353,7 @@ void wt_status_print(struct wt_status *s)
else if (s->commitable)
fprintf(s->fp, "# Untracked files not listed (use -u option to show untracked files)\n");
- if (s->verbose && !s->is_initial)
+ if (s->verbose)
wt_status_print_verbose(s);
if (!s->commitable) {
if (s->amend)
--
1.6.0.4.883.g4593ee.dirty
^ permalink raw reply related
* [PATCH 4/5] commit: loosen pattern for matching "-v" diff
From: Jeff King @ 2008-11-12 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <20081112081609.GA3720@coredump.intra.peff.net>
When a user asks to see the diff to be applied via "git
commit -v", the diff ends up in the commit template, and we
must later remove it.
To detect the start of the included diff, we used to search
for a line beginning with "diff --git a/". However, in the
face of diff.mnemonicprefix, that will actually be "diff
--git i/".
So let's just loosen the pattern a bit to handle either
case.
Signed-off-by: Jeff King <peff@peff.net>
---
And this is the fix from before, with a test case.
builtin-commit.c | 2 +-
t/t7507-commit-verbose.sh | 16 ++++++++++++++++
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 93ca496..a721990 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1015,7 +1015,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
/* Truncate the message just before the diff, if any. */
- p = strstr(sb.buf, "\ndiff --git a/");
+ p = strstr(sb.buf, "\ndiff --git ");
if (p != NULL)
strbuf_setlen(&sb, p - sb.buf + 1);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 94b12e9..be70166 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -26,4 +26,20 @@ test_expect_success 'initial commit shows verbose diff' '
git commit --amend -v
'
+check_message() {
+ git log -1 --pretty=format:%s%n%n%b >actual &&
+ test_cmp "$1" actual
+}
+
+test_expect_success 'verbose diff is stripped out' '
+ git commit --amend -v &&
+ check_message message
+'
+
+test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
+ git config diff.mnemonicprefix true &&
+ git commit --amend -v &&
+ check_message message
+'
+
test_done
--
1.6.0.4.883.g4593ee.dirty
^ permalink raw reply related
* [PATCH 5/5] commit: only strip diff from message in verbose mode
From: Jeff King @ 2008-11-12 8:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <20081112081609.GA3720@coredump.intra.peff.net>
When the "-v" option is given, we put diff of what is to be
committed into the commit template, and then strip it back
out again after the user has edited it.
We guess at the location of the diff by searching for the
"diff --git" header. This means that if the user puts their
own diff in the message (e.g., as a sample output), then we
will accidentally trigger the pattern, removing part of
their output.
We can avoid doing this stripping altogether if the user
didn't use "-v" in the first place, so we know that any
match we find will be a false positive.
Signed-off-by: Jeff King <peff@peff.net>
---
Obviously this doesn't solve the problem entirely, but it at least makes
a reasonable rule: if we accidentally eat your sample diff output with
"-v", then try without it. :)
But more importantly, I suspect "-v" is used infrequently, so in
practice this should fix most cases.
builtin-commit.c | 8 +++++---
t/t7507-commit-verbose.sh | 21 +++++++++++++++++++++
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index a721990..591d16b 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1015,9 +1015,11 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
/* Truncate the message just before the diff, if any. */
- p = strstr(sb.buf, "\ndiff --git ");
- if (p != NULL)
- strbuf_setlen(&sb, p - sb.buf + 1);
+ if (verbose) {
+ p = strstr(sb.buf, "\ndiff --git ");
+ if (p != NULL)
+ strbuf_setlen(&sb, p - sb.buf + 1);
+ }
if (cleanup_mode != CLEANUP_NONE)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index be70166..2a3ea7a 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -42,4 +42,25 @@ test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
check_message message
'
+cat >diff <<'EOF'
+This is an example commit message that contains a diff.
+
+diff --git c/file i/file
+new file mode 100644
+index 0000000..f95c11d
+--- /dev/null
++++ i/file
+@@ -0,0 +1 @@
++this is some content
+EOF
+
+test_expect_success 'diff in message is retained without -v' '
+ git commit --amend -F diff &&
+ check_message diff
+'
+
+test_expect_failure 'diff in message is retained with -v' '
+ git commit --amend -F diff -v &&
+ check_message diff
+'
test_done
--
1.6.0.4.883.g4593ee.dirty
^ permalink raw reply related
* Re: [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Johannes Sixt @ 2008-11-12 8:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Alexander Gavrilov, git
In-Reply-To: <18714.36964.666759.654975@cargo.ozlabs.ibm.com>
Paul Mackerras schrieb:
> Johannes Sixt writes:
>> Alexander Gavrilov schrieb:
>>> Transient windows cause problems on these platforms:
>> ...
>>> diff --git a/gitk b/gitk
>>> index 9b2a6e5..e6aafe8 100755
>> I'd appreciate if you could make it a habit to base your patches on
>> versions of gitk etc. that are available from a public repository
>
> You mean, like, git://git.kernel.org/pub/scm/gitk/gitk.git, for
> instance? :) That is the primary repository for gitk and it seems to
> be what Alexander bases his patches on.
Yes, I mean exactly this repository. It doesn't have 9b2a6e5:
$ git fetch gitk
$ git show 9b2a6e5 --
fatal: bad revision '9b2a6e5'
I assume that Alexander has another patch applied in addition to the one
that he submitted, which, therefore, is no longer "based on a publically
available version".
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/5] commit: only strip diff from message in verbose mode
From: Jeff King @ 2008-11-12 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <20081112082552.GE3751@coredump.intra.peff.net>
On Wed, Nov 12, 2008 at 03:25:52AM -0500, Jeff King wrote:
> +test_expect_success 'diff in message is retained without -v' '
> + git commit --amend -F diff &&
> + check_message diff
> +'
> +
> +test_expect_failure 'diff in message is retained with -v' '
> + git commit --amend -F diff -v &&
> + check_message diff
> +'
I put in this expect_failure to remind us that we could be doing better.
The solution you proposed would fix this test. Another idea I had was to
use a bogus diff header, and match on that. Something like:
diff --git --verbose-commit a/file b/file
and searching for "diff --git --verbose-commit", which would not trigger
on any diffs (unless, of course, you were trying to explain how the
verbose mode worked in your commit message :) ).
But that doesn't cover any other special input (i.e., lines beginning
with '#'), and would probably require an ugly hack to the diff machinery
(some diff option for "add these bogus diff command line options").
-Peff
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-12 8:33 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Björn Steinbrink, Johannes Schindelin,
David Symonds, git, Stephan Beyer
In-Reply-To: <32541b130811102004n54a47331v48ba8d299039897f@mail.gmail.com>
On Mon, Nov 10, 2008 at 11:04:42PM -0500, Avery Pennarun wrote:
> Speaking just for myself, I would find this all a lot less confusing
> if "staged" were a refspec of some sort, not an option at all.
>
> git diff HEAD..STAGED
> git diff STAGED..WORKTREE
> git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --
> path/to/files
I agree that such a thing is reasonably intuitive. I have thought about
"magic" refspecs before; my local git has an "EMPTY" refspec which
points to the empty tree for diffing. However, that was trivial to
implement (since it turns into a sha1), and yours is very hard (since
you will have to pass these "pretend" objects around).
So I think it is a neat idea, but I am not volunteering to work on it.
:)
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Document "git log --source"
From: Santi Béjar @ 2008-11-12 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vbpwlvkfh.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 1:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks; will queue this one, but Santi said he'll work on a replacement
> for 2/2 so I'll drop 2/2 from you for now.
Oh, please, for me you can apply 2/2, as it is clearly an improvement
and follows the style in the section. I can work on top of it.
Santi
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-11-12 8:44 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <f73f7ab80811111644y14f0e0ccweed44440356a6508@mail.gmail.com>
On Tue, Nov 11, 2008 at 07:44:06PM -0500, Kyle Moffett wrote:
> Hmm, I wonder if it would be possible to also add a "detach" variant;
> which would create a detached-HEAD at the current commit when
> automatically receiving a push to the working branch. I have a
> post-receive script that does so right now on a couple repositories.
> It's still a little confusing to someone actively working in the
> repository being pushed to, but it's much easier to explain than the
> current default behavior.
A neat idea, but I'm not sure what workflow that is meant to support.
Before you had:
1. git push non-bare-remote theirHEAD
2a. echo Oops, I've just screwed myself.
3a. ssh remote 'git reset --soft HEAD@{1}'
2b. echo Oops, I just screwed somebody else.
3b. echo sorry | mail somebody.else
With "refuse" you have:
1. git push non-bare-remote theirHEAD
2. echo Oops, rejected.
3. git push non-bare-remote theirHEAD:elsewhere
4a. ssh remote 'git merge elsewhere'
4b. echo 'please merge elsewhere' | mail somebody.else
which is an improvement. With "detach" you have:
1. git push non-bare-remote theirHEAD
2. echo Oh, now we've detached on the remote.
3a. ssh remote 'git checkout theirHEAD'
3b. echo 'please merge theirHEAD. BTW, you have been detached without
realizing it, so make sure you didn't lose any commits.' |
mail somebody.else
So I think in the case that you are working by yourself, you haven't
really saved much effort (you didn't have to repeat your push, but you
still have to go to the remote and checkout instead of merge). But if
you are pushing into somebody _else_'s repo, you have just mightily
confused them as they start to make commits on top of the detached HEAD.
Still, there may be some instances where moving to the detached HEAD is
preferable. But, like the "try to merge if we can" strategy, I think it
is better implemented by setting denyCurrentBranch to ignore and using a
hook for those instances. And if either hook becomes ubiquitous, maybe
it will be worth implementing within git itself (but I doubt it for
either, as the desired behavior is highly dependent on your personal
workflow).
-Peff
^ permalink raw reply
* hosting git on a nfs
From: Thomas Koch @ 2008-11-12 9:29 UTC (permalink / raw)
To: git; +Cc: dabe
Hi,
finally I managed to convince a critical mass of developers (our chief
dev :-) in our company so that we are starting to migrate to GIT.
The final question is, whether GIT will life peacefully on our cluster
fileservers. The GIT repository dir (/var/cache/git) should be mounted
via NFS via PAN on top of DRBD (so I was told).
Are there any known problems with this setup? We're asking, because
there are problems with SVN on such a setup[1].
[1] http://subversion.tigris.org/faq.html#nfs
Best regards,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Catalin Marinas @ 2008-11-12 10:02 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20081112080103.GA25454@diana.vm.bytemark.co.uk>
2008/11/12 Karl Hasselström <kha@treskal.com>:
> On 2008-11-11 17:59:02 +0000, Catalin Marinas wrote:
>> Could be related to this - if I run 'stg goto some-patch' and it
>> fails with a conflict, the HEAD points to the previous patch though
>> the stack has the conflicting patch as empty (which is normal) and
>> the conflicts in the index. Anything after that says HEAD and top
>> not equal and 'stg repair' is needed.
>
> Ah, yes, that could definitely be the same problem, since those two
> things end up calling the same functions to handle the conflict.
I think it's just a matter of updating HEAD on the "merge_conflict"
path but I'm still not fully confident in modifying the new lib
infrastructure.
> I'll build a test case for that as well.
We test the conflicts quite a lot in the "push" tests but this command
hasn't been converted to the new infrastructure yet.
--
Catalin
^ permalink raw reply
* Re: hosting git on a nfs
From: Julian Phillips @ 2008-11-12 10:10 UTC (permalink / raw)
To: Thomas Koch; +Cc: git, dabe
In-Reply-To: <200811121029.34841.thomas@koch.ro>
On Wed, 12 Nov 2008, Thomas Koch wrote:
> Hi,
>
> finally I managed to convince a critical mass of developers (our chief
> dev :-) in our company so that we are starting to migrate to GIT.
>
> The final question is, whether GIT will life peacefully on our cluster
> fileservers. The GIT repository dir (/var/cache/git) should be mounted
> via NFS via PAN on top of DRBD (so I was told).
>
> Are there any known problems with this setup? We're asking, because
> there are problems with SVN on such a setup[1].
>
> [1] http://subversion.tigris.org/faq.html#nfs
I've been running git on NFS for years (though it's only NFS exported
software RAID), and the only issue I've encountered is that it's not quite
as blisteringly fast as running git on a local disk.
--
Julian
---
There's something different about us -- different from people of Europe,
Africa, Asia ... a deep and abiding belief in the Easter Bunny.
-- G. Gordon Liddy
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Karl Hasselström @ 2008-11-12 10:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <b0943d9e0811120202wae88381j9fbc9f919b49dce5@mail.gmail.com>
On 2008-11-12 10:02:10 +0000, Catalin Marinas wrote:
> I think it's just a matter of updating HEAD on the "merge_conflict"
> path but I'm still not fully confident in modifying the new lib
> infrastructure.
You're probably right.
I'll do it, but you're welcome to beat me to it if you like; I promise
to read your patch extra carefully if you do.
(I'll drop you a mail when I start attacking this, to prevent any
duplicated work.)
> 2008/11/12 Karl Hasselström <kha@treskal.com>:
>
> > I'll build a test case for that as well.
>
> We test the conflicts quite a lot in the "push" tests but this
> command hasn't been converted to the new infrastructure yet.
Yes. As soon as we convert push and/or pop, this will be caught by the
test suite. But that just means the test suite needs extending ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* git integration with monodevelop
From: Andreas Ericsson @ 2008-11-12 10:22 UTC (permalink / raw)
To: Git Mailing List, Shawn Pearce, monodevelop-list,
Michael Hutchinson
Recently, I've started learning C#. More for fun than anything else,
but one of the mono core devs sniffed me out and said they've been
thinking of porting jgit to C# to get a working IDE integration in
monodevelop. Currently, the only option available (with IDE
integration anyways) to the poor C# devs is either Microsoft's
crappy VSS, or the less crappy but still far from fantastic
Subversion.
So in an effort to learn C#, I've decided to play along with this
(hopefully with some help from the MonoDevelop team), but it seems
to me that the best place to start is the fledgling libgit2 and link
that with git-sharp. The primary reason for this is ofcourse that I
think it'd be a terrible waste to have yet another from-scratch
implementation of git in a new language (ruby, java, C#, C...). The
secondary reason is that it would be neat to have more OSS projects
use my favourite scm.
Besides, getting something to rely on libgit2 early on is probably
the best way to get more people interested in making development of
it proceed rapidly.
Thoughts anyone?
Please reply-to-all as this goes cross-list
(currently, Cc ae@op5.se, spearce@spearce.org, git@vger.kernel.org,
m.j.hutchinson@gmail.com, in case monodevelop-list uses reply-to
header).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git integration with monodevelop
From: Andreas Ericsson @ 2008-11-12 10:31 UTC (permalink / raw)
To: Git Mailing List, Shawn Pearce, Michael Hutchinson
In-Reply-To: <491AAE6D.8030304@op5.se>
Andreas Ericsson wrote:
> Recently, I've started learning C#. More for fun than anything else,
> but one of the mono core devs sniffed me out and said they've been
> thinking of porting jgit to C# to get a working IDE integration in
> monodevelop. Currently, the only option available (with IDE
> integration anyways) to the poor C# devs is either Microsoft's
> crappy VSS, or the less crappy but still far from fantastic
> Subversion.
>
> So in an effort to learn C#, I've decided to play along with this
> (hopefully with some help from the MonoDevelop team), but it seems
> to me that the best place to start is the fledgling libgit2 and link
> that with git-sharp. The primary reason for this is ofcourse that I
> think it'd be a terrible waste to have yet another from-scratch
> implementation of git in a new language (ruby, java, C#, C...). The
> secondary reason is that it would be neat to have more OSS projects
> use my favourite scm.
>
> Besides, getting something to rely on libgit2 early on is probably
> the best way to get more people interested in making development of
> it proceed rapidly.
>
> Thoughts anyone?
>
> Please reply-to-all as this goes cross-list
> (currently, Cc ae@op5.se, spearce@spearce.org, git@vger.kernel.org,
> m.j.hutchinson@gmail.com, in case monodevelop-list uses reply-to
> header).
>
Ouch. Scratch monodevelop-list from that Cc list. It appears to be
members-only (although not listed as such on their list-server).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Alexander Gavrilov @ 2008-11-12 10:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, git
In-Reply-To: <491A9398.1060100@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 524 bytes --]
On Wed, Nov 12, 2008 at 11:28 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> I assume that Alexander has another patch applied in addition to the one
> that he submitted, which, therefore, is no longer "based on a publically
> available version".
I'm sorry, it is indeed applied over another patch (attached because I
only have access to Gmail Web UI right now). These patches eventually
come from two ends of one long series that has been gradually applied
over the time, so I still think of them as a unit.
Alexander
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gitk-Add-accelerators-to-frequently-used-menu-comma.patch --]
[-- Type: text/x-patch; name=0001-gitk-Add-accelerators-to-frequently-used-menu-comma.patch, Size: 3355 bytes --]
From fc6b3728e15483734ee44a35d5023660a7da8882 Mon Sep 17 00:00:00 2001
From: Alexander Gavrilov <angavrilov@gmail.com>
Date: Sun, 9 Nov 2008 13:00:45 +0300
Subject: [PATCH] gitk: Add accelerators to frequently used menu commands.
This commit documents keyboard accelerators used for menu
commands in the menu, as it is usually done, and adds some
more, e.g. F4 to invoke Edit View.
The changes include a workaround for handling Shift-F4 on
systems where XKB binds special XF86_Switch_VT_* symbols
to Ctrl-Alt-F* combinations. Tk often receives these codes
when Shift-F* is pressed, so it is necessary to bind the
relevant actions to them as well.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 36 +++++++++++++++++++++++++++++-------
1 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/gitk b/gitk
index 18d153e..9b2a6e5 100755
--- a/gitk
+++ b/gitk
@@ -1801,6 +1801,11 @@ proc setoptions {} {
# command to invoke for command, or {variable value} for radiobutton
proc makemenu {m items} {
menu $m
+ if {[tk windowingsystem] eq {aqua}} {
+ set Meta1 Cmd
+ } else {
+ set Meta1 Ctrl
+ }
foreach i $items {
set name [mc [lindex $i 1]]
set type [lindex $i 2]
@@ -1826,7 +1831,9 @@ proc makemenu {m items} {
-value [lindex $thing 1]
}
}
- eval $m add $params [lrange $i 4 end]
+ set tail [lrange $i 4 end]
+ regsub -all {\yMeta1\y} $tail $Meta1 tail
+ eval $m add $params $tail
if {$type eq "cascade"} {
makemenu $m.$submenu $thing
}
@@ -1860,17 +1867,17 @@ proc makewindow {} {
makemenu .bar {
{mc "File" cascade {
{mc "Update" command updatecommits -accelerator F5}
- {mc "Reload" command reloadcommits}
+ {mc "Reload" command reloadcommits -accelerator Meta1-F5}
{mc "Reread references" command rereadrefs}
- {mc "List references" command showrefs}
- {mc "Quit" command doquit}
+ {mc "List references" command showrefs -accelerator F2}
+ {mc "Quit" command doquit -accelerator Meta1-Q}
}}
{mc "Edit" cascade {
{mc "Preferences" command doprefs}
}}
{mc "View" cascade {
- {mc "New view..." command {newview 0}}
- {mc "Edit view..." command editview -state disabled}
+ {mc "New view..." command {newview 0} -accelerator Shift-F4}
+ {mc "Edit view..." command editview -state disabled -accelerator F4}
{mc "Delete view" command delview -state disabled}
{xx "" separator}
{mc "All files" radiobutton {selectedview 0} -command {showview 0}}
@@ -2232,7 +2239,12 @@ proc makewindow {} {
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
bindkey f nextfile
- bindkey <F5> updatecommits
+ bind . <F5> updatecommits
+ bind . <$M1B-F5> reloadcommits
+ bind . <F2> showrefs
+ bind . <Shift-F4> {newview 0}
+ catch { bind . <Shift-Key-XF86_Switch_VT_4> {newview 0} }
+ bind . <F4> edit_or_newview
bind . <$M1B-q> doquit
bind . <$M1B-f> {dofind 1 1}
bind . <$M1B-g> {dofind 1 0}
@@ -3624,6 +3636,16 @@ proc decode_view_opts {n view_args} {
set newviewopts($n,args) [shellarglist $oargs]
}
+proc edit_or_newview {} {
+ global curview
+
+ if {$curview > 0} {
+ editview
+ } else {
+ newview 0
+ }
+}
+
proc editview {} {
global curview
global viewname viewperm newviewname newviewopts
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-12 10:43 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811111112o5449c12elfc571e46e607cfd0@mail.gmail.com>
On Tue, Nov 11, 2008 at 10:12:46PM +0300, Constantine Plotnikov wrote:
> is encoded using Windows-1251 and the second one using UTF-8. However
> in the description of the %s %b options nothing is said about which
> encoding is used and implied behavior is that they are affected by
> --encoding option.
>
> I suggest documenting that the placeholders %s and %b use native
> commit encoding and introducing the placeholders %S and %B options
> that use encoding specified on the command line or the default log
> encoding.
I don't actually use any encodings except UTF-8, so maybe there is some
subtle reason not to do so that I don't understand, but I would have
expected all of the format placeholders to respect any --encoding
parameter.
If that is the desired behavior, this should not be too hard to make a
patch for:
1. in pretty_print_commit, move the code path for userformat to just
after the re-encoding
2. pass the re-encoded buffer to format_commit_message, where it will
be put into the context struct
3. use the re-encoded buffer in parse_commit_header
Maybe it would make a good exercise for somebody who wants to dig into
git a little deeper? Volunteers?
> I also suggest adding %g and %G placeholders (%m placeholder is
> already occupied) that print the entire commit message instead of just
> the subject or the body. Currently the tools have to join the entire
> message from two parts when they are just interested in the entire
> message.
This actually annoyed me earlier today. What got me was that '%s%n%n%b'
doesn't necessarily give you the exact commit message; if it's a
one-liner (i.e., body is blank), then you end up with an extra newline.
Again, this should be a pretty easy exercise to add. Volunteers?
-Peff
^ permalink raw reply
* [PATCH] Doc: Add a simplified help on top of the "History Simplification"
From: Santi Béjar @ 2008-11-12 10:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nanako Shiraishi
Signed-off-by: Santi Béjar <santi@agolina.net>
---
Hi,
This is conceptually on top of:
[PATCH 2/2] Document "git log --simplify-by-decoration"
from Nanako. I do not touch the detailed help, I only add a simplified one at the top.
Santi
Documentation/rev-list-options.txt | 48 ++++++++++++++++++++++++++++++++++-
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 68a253f..8adce65 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -285,8 +285,52 @@ See also linkgit:git-reflog[1].
History Simplification
~~~~~~~~~~~~~~~~~~~~~~
-When optional paths are given, 'git rev-list' simplifies commits with
-various strategies, according to the options you have selected.
+Sometimes you are only interested in part of the history, for example the
+commits modifying a particular <paths>. But there are two parts of
+'History Simplification', one part is selecting the commits and the other
+is how to do it, as there are various strategies to simplify the history.
+
+The following options select the commits to be shown:
+
+<paths>::
+
+ Commits modifying the given <paths> are selected.
+
+--simplify-by-decoration::
+
+ Commits that are referred by some branch or tag are selected.
+
+Note that extra commits can be shown to give a meaningful history.
+
+The following options affect the way the simplification is performed:
+
+Default mode::
+
+ Simplifies the history to the simplest history explaining the
+ final state of the tree. Simplest because it prunes some side
+ branches if the end result is the same (i.e. merging branches
+ with the same content)
+
+--full-history::
+
+ As the default mode but does not prune some history.
+
+--dense::
+
+ Only the selected commits are shown, plus some to have a
+ meaningful history.
+
+--sparse::
+
+ All commits in the simplified history are shown.
+
+--simplify-merges::
+
+ Additional option to '--full-history' to remove some needless
+ merges from the resulting history, as there are no selected
+ commits contributing to this merge.
+
+A more detailed explanation follows.
Suppose you specified `foo` as the <paths>. We shall call commits
that modify `foo` !TREESAME, and the rest TREESAME. (In a diff
--
1.6.0.rc1.27.g9b6bf
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Johannes Schindelin @ 2008-11-12 11:10 UTC (permalink / raw)
To: Jeff King
Cc: Avery Pennarun, Junio C Hamano, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <20081112083353.GB3817@coredump.intra.peff.net>
Hi,
On Wed, 12 Nov 2008, Jeff King wrote:
> On Mon, Nov 10, 2008 at 11:04:42PM -0500, Avery Pennarun wrote:
>
> > Speaking just for myself, I would find this all a lot less confusing
> > if "staged" were a refspec of some sort, not an option at all.
> >
> > git diff HEAD..STAGED
> > git diff STAGED..WORKTREE
> > git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --
> > path/to/files
>
> I agree that such a thing is reasonably intuitive. I have thought about
> "magic" refspecs before; my local git has an "EMPTY" refspec which
> points to the empty tree for diffing. However, that was trivial to
> implement (since it turns into a sha1), and yours is very hard (since
> you will have to pass these "pretend" objects around).
>
> So I think it is a neat idea, but I am not volunteering to work on it.
> :)
Just in case anybody thought about creating tree objects on the fly and
use their SHA-1s: that won't fly, as you can have unmerged entries in the
index. So STAGED.. is a _fundamentally_ different thing from HEAD^..
Maybe we could play tricks with a special staged_commit (pretending to be
a commit with SHA-1 000000... so that git log STAGED.. would do the same
as plain git log, the rationale being that STAGED is no commit, so ^STAGED
should be a nop).
"git diff" would then have some special handling for the case that there
are exactly two revs, exactly one of them negative, and exactly one of
them being the staged_commit, passing off to the respective diff backends.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-12 11:06 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Avery Pennarun, Junio C Hamano, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0811121205100.30769@pacific.mpi-cbg.de>
On Wed, Nov 12, 2008 at 12:10:57PM +0100, Johannes Schindelin wrote:
> Just in case anybody thought about creating tree objects on the fly and
> use their SHA-1s: that won't fly, as you can have unmerged entries in the
> index. So STAGED.. is a _fundamentally_ different thing from HEAD^..
I thought about that at first, too, but the working tree is even more
painful. You would have to hash every changed file on the filesystem to
create the tree object.
-Peff
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-12 11:26 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811120311q7bc5451x7c084fd2a7864177@mail.gmail.com>
[re-adding list to the cc]
On Wed, Nov 12, 2008 at 02:11:46PM +0300, Constantine Plotnikov wrote:
> > I don't actually use any encodings except UTF-8, so maybe there is some
> > subtle reason not to do so that I don't understand, but I would have
> > expected all of the format placeholders to respect any --encoding
> > parameter.
> >
> Even if this is the bug, it would be better to leave the old behavior
> for backward compatibility reasons and introduce new placeholders.
> Currently tools have to decode messages according to the commit
> encoding, and changing behavior of options will break these tools
> that have implemented workaround for this problem.
Are there such tools? I assumed they would have complained about this as
a bug before writing their own encoding conversion tools. And this is,
AFAIK, the first bug report.
I don't mind playing it safe to avoid breaking other people's tools, but
I'm also not excited about adding a second, "respect encoding" version
of many placeholders (and it's not just %s and %b; I think you would
need author and committer names and emails, too).
-Peff
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Karl Hasselström @ 2008-11-12 12:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20081112080103.GA25454@diana.vm.bytemark.co.uk>
On 2008-11-12 09:01:03 +0100, Karl Hasselström wrote:
> On 2008-11-11 17:59:02 +0000, Catalin Marinas wrote:
>
> > 2008/11/7 Karl Hasselström <kha@treskal.com>:
> >
> > > On 2008-11-04 08:37:24 -0500, Jon Smirl wrote:
> > >
> > > > I hit a case when refreshing a buried patch that needed a
> > > > merge conflict sorted out. I'm unable to recover out of the
> > > > state.
> > >
> > > Hmm, so what you're saying is basically that you did something
> > > with "stg refresh -p" that caused a merge conflict, and that
> > > messed things up so that you needed to run "stg repair". Is that
> > > right?
> >
> > Could be related to this - if I run 'stg goto some-patch' and it
> > fails with a conflict, the HEAD points to the previous patch
> > though the stack has the conflicting patch as empty (which is
> > normal) and the conflicts in the index. Anything after that says
> > HEAD and top not equal and 'stg repair' is needed.
>
> Ah, yes, that could definitely be the same problem, since those two
> things end up calling the same functions to handle the conflict.
OK, I just got this error with goto. :-)
FWIW, the convenient way to recover is
$ git reset --soft $(stg id $(stg top))
This will point your branch head to the correct commit. stg repair
would pop the top patch, which is much less convenient in this case.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Farrukh Najmi @ 2008-11-12 12:51 UTC (permalink / raw)
To: git
In-Reply-To: <2c6b72b30811111401i3c995889n54407243a1072599@mail.gmail.com>
The jgit team, rocks! You guys are simply awesome in your
responsiveness. Thanks for a great project.
Please let me know if I can help with any maven related issues. Here is
a couple of
links I use to evangelize use of maven in OS projects:
Why Maven Rocks:
<http://farrukhnajmi.blogspot.com/2008/02/why-maven-rocks-in-beginning-there-was.html>
Why Maven - Wiki Page:
<http://ebxmlrr.wiki.sourceforge.net/whymaven>
Here are the main resources I use as reference for maven:
Maven Official Docs:
<http://maven.apache.org/guides/index.html>
Better Builds With Maven:
<http://www.topazproject.org/trac/attachment/wiki/MavenInfo/BetterBuildsWithMaven.pdf?format=raw>
I think it is great that the project supports maven at least partially
today.
I would suggest the project consider maven for all its
build/configuration management at some point in future.
It takes a little learning curve initially (most for dev team members
not users) but pays off handsomely very quickly.
Jonas Fonseca wrote:
...
> On Tue, Nov 11, 2008 at 22:44, Shawn O. Pearce <spearce@spearce.org> wrote:
>
>> Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>>
>>> I would also like to have a public available maven repository for
>>> JGit. If Shawn or Robin acks, I can look into hosting one in the SVN
>>> area of the Google Code project page. Given the lack of a real release
>>> cycle it probably only makes sense to have a snapshot repository.
>>>
...
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Arafangion @ 2008-11-12 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon Hausmann, Han-Wen Nienhuys, git
In-Reply-To: <7vzlk5u5rq.fsf@gitster.siamese.dyndns.org>
Thanks for making those patches more visible, however I do feel the need
to mention one thing I expected to have been raised during patch review:
1) The memory optimisation may cause significant slowdown, which wasn't
a big issue on my machine, perhaps because I'm _still_ trying to get it
to work on my particular repo. (It's still using too much memory), and I
have a very fast machine. It switches git-p4 from a RAM-intensive app
to a somewhat-less-RAM-intensive app at the cost of also becomming much
more CPU-intensive.
On Tue, 2008-11-11 at 16:50 -0800, Junio C Hamano wrote:
> Simon Hausmann <simon@lst.de> writes:
>
> > On Sunday 09 November 2008 Junio C Hamano, wrote:
> >> These are patches to fast-import/git-p4, which you two seem to in charge
> >> of.
> >>
> >> From: John Chapman <thestar@fussycoder.id.au>
> >> Subject: [PATCH 1/2] Added support for purged files and also optimised
> >> memory usage. Date: Sat, 8 Nov 2008 14:22:48 +1100
> >> Message-Id: <1226114569-8506-1-git-send-email-thestar@fussycoder.id.au>
> >>
> >> From: John Chapman <thestar@fussycoder.id.au>
> >> Subject: [PATCH 2/2] Cached the git configuration, which is now
> >> noticibly faster on windows. Date: Sat, 8 Nov 2008 14:22:49 +1100
> >> Message-Id: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>
> >>
> >> It was unfortunately not immediately obvious from the Subject: line what
> >> these patches are about, and I am guessing you missed them because of that.
> >
> > Ack on both patches. The second one could be done better, as suggested
> > in the follow-ups, but both are clearly an improvement :)
>
> Thanks, both of you. Will apply.
>
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Constantine Plotnikov @ 2008-11-12 13:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081112112654.GA20640@coredump.intra.peff.net>
On Wed, Nov 12, 2008 at 2:26 PM, Jeff King <peff@peff.net> wrote:
> [re-adding list to the cc]
>
> On Wed, Nov 12, 2008 at 02:11:46PM +0300, Constantine Plotnikov wrote:
>
>> > I don't actually use any encodings except UTF-8, so maybe there is some
>> > subtle reason not to do so that I don't understand, but I would have
>> > expected all of the format placeholders to respect any --encoding
>> > parameter.
>> >
>> Even if this is the bug, it would be better to leave the old behavior
>> for backward compatibility reasons and introduce new placeholders.
>> Currently tools have to decode messages according to the commit
>> encoding, and changing behavior of options will break these tools
>> that have implemented workaround for this problem.
>
> Are there such tools? I assumed they would have complained about this as
> a bug before writing their own encoding conversion tools. And this is,
> AFAIK, the first bug report.
>
> I don't mind playing it safe to avoid breaking other people's tools, but
> I'm also not excited about adding a second, "respect encoding" version
> of many placeholders (and it's not just %s and %b; I think you would
> need author and committer names and emails, too).
>
The reason for the request was that for IDE integration (I'm working
on the IDEA plugin), we need to work with past versions of the git as
well. However we could write that this is known git bug that will be
fixed in some future version and just to show incorrect data in
history view when non-UTF-8 encoding is used for a while. I hope that
non-UTF-8 encoding for commits is indeed a rare case, so users will
not complain much.
BTW for some reason --pretty=raw is affected by encoding option on the
command line. And this is a bit surprising as from description of the
raw format it looks like it should not be affected, because the
re-encoded commit is not "the entire commit exactly as stored in the
commit object". Possibly the man page should be updated to clarify
this.
Regards,
Constantine
^ 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