* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Jakub Narebski @ 2008-07-01 12:47 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Ingo Molnar, Bruce Stephens, git
In-Reply-To: <20080701114149.GB6662@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> how about displaying the current branch in the command prompt?
>
> >From contrib/completion/git-completion.bash:
>
> # 4) Consider changing your PS1 to also show the current branch:
> # PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
> #
> # The argument to __git_ps1 will be displayed only if you
> # are currently in a git repository. The %s token will be
> # the name of the current branch.
Because I alos use StGit, I have added to my prompt visual
differentiation if the branch is under StGit control.
But I have my own git prompt function, based on git-completion.bash
but different. It shows current branch (or "HEAD" if on detached
HEAD), current repository, and current working directory. It laso has
number of command in history, the same as in my ordinary prompt.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Mikael Magnusson @ 2008-07-01 12:46 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Junio C Hamano, git
In-Reply-To: <20080701100725.GE31309@elte.hu>
2008/7/1 Ingo Molnar <mingo@elte.hu>:
> * Junio C Hamano <gitster@pobox.com> wrote:
>
>> Ingo Molnar <mingo@elte.hu> writes:
>>
>> > i recently switched to 1.5.6.1.89.gd5446 and i'm getting this:
>> >
>> > Switched to branch "master"
>> > Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
>> >
>> > it's a very useful detail! It's especially useful when two branches
>> > diverge in a non-trivial way.
>> > ...
>> > but having a reminder at checkout time is even better (and faster as
>> > well). Kudos.
[snippy]
> There's a small detail i was thinking about: is there a way to get this
> extra output without actually switching branches? Right now i do this:
>
> earth4:~/tip> git-checkout tip; git-checkout master
> Checking out files: 100% (2437/2437), done.
> Switched to branch "tip"
> Switched to branch "master"
> Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
>
> (Which is an admitted lame solution but the best i could figure.)
{14:44:16|~code/git}% git checkout master
Checking out files: 100% (180/180), done.
Switched to branch "master"
{14:44:24|~code/git}% git shard HEAD\~5
HEAD is now at 8e69d78 Merge branch 'maint'
{14:44:28|~code/git}% git checkout HEAD
Your branch is behind the tracked remote branch 'origin/master' by 6 commits,
and can be fast-forwarded.
--
Mikael Magnusson
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Jakub Narebski @ 2008-07-01 12:44 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Ingo Molnar, git
In-Reply-To: <80iqvq2bw0.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > i recently switched to 1.5.6.1.89.gd5446 and i'm getting this:
> >
> > Switched to branch "master"
> > Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
> >
> > it's a very useful detail! It's especially useful when two branches
> > diverge in a non-trivial way.
>
> I agree, it's a really nice little feature. Indeed, I occasionally do
> "git checkout master" just to get the message (to see where I am).
>
> It feels logical for "git status" to offer the same information (when
> the information is appropriate).
I agree that having this information in git-status would be useful,
especially that it would make having this reminder in buffer/editor
when editing commit message.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 13/14] git-commit-tree: make it usable from other builtins
From: Miklos Vajna @ 2008-07-01 12:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <7vbq1irw3q.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
On Mon, Jun 30, 2008 at 10:50:49PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > This patch is against master, you need to pull from me or first rebase
> > mv/merge-in-c against current master.
>
> That's a bad practice. It makes it much harder to review the incremental
> changes from the previous round.
Sorry. I just did this way because in my patch I wanted to let
cmd_commit_tree() use a commit_list and I saw Dscho already did it, and
I saw that the patch is already in master.
> I'll cope, though.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] git-add--interactive: manual hunk editing mode
From: Thomas Rast @ 2008-07-01 11:44 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Thomas Rast
In-Reply-To: <20080701101114.GA6379@sigill.intra.peff.net>
Adds a new option 'e' to the 'add -p' command loop that lets you edit
the current hunk in your favourite editor.
If the resulting patch applies cleanly, the edited hunk will
immediately be marked for staging. If it does not apply cleanly, you
will be given an opportunity to edit again. If all lines of the hunk
are removed, then the edit is aborted and the hunk is left unchanged.
Applying the changed hunk(s) relies on Johannes Schindelin's new
--recount option for git-apply.
Note that the "real patch" test intentionally uses
(echo e; echo n; echo d) | git add -p
even though the 'n' and 'd' are superfluous at first sight. They
serve to get out of the interaction loop if git add -p wrongly
concludes the patch does not apply.
Many thanks to Jeff King <peff@peff.net> for lots of help and
suggestions.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Jeff King wrote:
> Now that this is in next, maybe it is a good time to repost the
> add--interactive patch (it should be independent of Dscho's 2/2 "add -e"
> patch).
It is independent, so I suppose you're right. (Dscho mentioned in
passing he might repost "add -e" himself.)
- Thomas
Documentation/git-add.txt | 1 +
git-add--interactive.perl | 124 +++++++++++++++++++++++++++++++++++++++++++-
t/t3701-add-interactive.sh | 67 ++++++++++++++++++++++++
3 files changed, 191 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index c6de028..1d8d209 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -246,6 +246,7 @@ patch::
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
+ e - manually edit the current hunk
? - print help
+
After deciding the fate for all hunks, if there is any hunk
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..6bb117a 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -2,6 +2,7 @@
use strict;
use Git;
+use File::Temp;
my $repo = Git->repository();
@@ -18,6 +19,18 @@ my ($fraginfo_color) =
$diff_use_color ? (
$repo->get_color('color.diff.frag', 'cyan'),
) : ();
+my ($diff_plain_color) =
+ $diff_use_color ? (
+ $repo->get_color('color.diff.plain', ''),
+ ) : ();
+my ($diff_old_color) =
+ $diff_use_color ? (
+ $repo->get_color('color.diff.old', 'red'),
+ ) : ();
+my ($diff_new_color) =
+ $diff_use_color ? (
+ $repo->get_color('color.diff.new', 'green'),
+ ) : ();
my $normal_color = $repo->get_color("", "reset");
@@ -770,6 +783,104 @@ sub coalesce_overlapping_hunks {
return @out;
}
+sub color_diff {
+ return map {
+ colored((/^@/ ? $fraginfo_color :
+ /^\+/ ? $diff_new_color :
+ /^-/ ? $diff_old_color :
+ $diff_plain_color),
+ $_);
+ } @_;
+}
+
+sub edit_hunk_manually {
+ my ($oldtext) = @_;
+
+ my $t = File::Temp->new(
+ TEMPLATE => $repo->repo_path . "/git-hunk-edit.XXXXXX",
+ SUFFIX => '.diff'
+ );
+ print $t "# Manual hunk edit mode -- see bottom for a quick guide\n";
+ print $t @$oldtext;
+ print $t <<EOF;
+# ---
+# To remove '-' lines, make them ' ' lines (context).
+# To remove '+' lines, delete them.
+# Lines starting with # will be removed.
+#
+# If the patch applies cleanly, the edited hunk will immediately be
+# marked for staging. If it does not apply cleanly, you will be given
+# an opportunity to edit again. If all lines of the hunk are removed,
+# then the edit is aborted and the hunk is left unchanged.
+EOF
+ close $t;
+
+ my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
+ || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+ system('sh', '-c', $editor.' "$@"', $editor, $t);
+
+ open my $fh, '<', $t
+ or die "failed to open hunk edit file for reading: " . $!;
+ my @newtext = grep { !/^#/ } <$fh>;
+ close $fh;
+
+ # Abort if nothing remains
+ if (!grep { /\S/ } @newtext) {
+ return undef;
+ }
+
+ # Reinsert the first hunk header if the user accidentally deleted it
+ if ($newtext[0] !~ /^@/) {
+ unshift @newtext, $oldtext->[0];
+ }
+ return \@newtext;
+}
+
+sub diff_applies {
+ my $fh;
+ open $fh, '| git apply --recount --cached --check';
+ for my $h (@_) {
+ print $fh @{$h->{TEXT}};
+ }
+ return close $fh;
+}
+
+sub prompt_yesno {
+ my ($prompt) = @_;
+ while (1) {
+ print colored $prompt_color, $prompt;
+ my $line = <STDIN>;
+ return 0 if $line =~ /^n/i;
+ return 1 if $line =~ /^y/i;
+ }
+}
+
+sub edit_hunk_loop {
+ my ($head, $hunk, $ix) = @_;
+ my $text = $hunk->[$ix]->{TEXT};
+
+ while (1) {
+ $text = edit_hunk_manually($text);
+ if (!defined $text) {
+ return undef;
+ }
+ my $newhunk = { TEXT => $text, USE => 1 };
+ if (diff_applies($head,
+ @{$hunk}[0..$ix-1],
+ $newhunk,
+ @{$hunk}[$ix+1..$#{$hunk}])) {
+ $newhunk->{DISPLAY} = [color_diff(@{$text})];
+ return $newhunk;
+ }
+ else {
+ prompt_yesno(
+ 'Your edited hunk does not apply. Edit again '
+ . '(saying "no" discards!) [y/n]? '
+ ) or return undef;
+ }
+ }
+}
+
sub help_patch_cmd {
print colored $help_color, <<\EOF ;
y - stage this hunk
@@ -781,6 +892,7 @@ J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
+e - manually edit the current hunk
? - print help
EOF
}
@@ -846,6 +958,7 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ my $need_recount = 0;
while (1) {
my ($prev, $next, $other, $undecided, $i);
@@ -885,6 +998,7 @@ sub patch_update_file {
if (hunk_splittable($hunk[$ix]{TEXT})) {
$other .= '/s';
}
+ $other .= '/e';
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
@@ -949,6 +1063,13 @@ sub patch_update_file {
$num = scalar @hunk;
next;
}
+ elsif ($line =~ /^e/) {
+ my $newhunk = edit_hunk_loop($head, \@hunk, $ix);
+ if (defined $newhunk) {
+ splice @hunk, $ix, 1, $newhunk;
+ $need_recount = 1;
+ }
+ }
else {
help_patch_cmd($other);
next;
@@ -1002,7 +1123,8 @@ sub patch_update_file {
if (@result) {
my $fh;
- open $fh, '| git apply --cached';
+ open $fh, '| git apply --cached'
+ . ($need_recount ? ' --recount' : '');
for (@{$head->{TEXT}}, @result) {
print $fh $_;
}
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index fae64ea..e95663d 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -66,6 +66,73 @@ test_expect_success 'revert works (commit)' '
grep "unchanged *+3/-0 file" output
'
+cat >expected <<EOF
+EOF
+cat >fake_editor.sh <<EOF
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'dummy edit works' '
+ (echo e; echo a) | git add -p &&
+ git diff > diff &&
+ test_cmp expected diff
+'
+
+cat >patch <<EOF
+@@ -1,1 +1,4 @@
+ this
++patch
+-doesn't
+ apply
+EOF
+echo "#!$SHELL_PATH" >fake_editor.sh
+cat >>fake_editor.sh <<\EOF
+mv -f "$1" oldpatch &&
+mv -f patch "$1"
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'bad edit rejected' '
+ git reset &&
+ (echo e; echo n; echo d) | git add -p >output &&
+ grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+this patch
+is garbage
+EOF
+test_expect_success 'garbage edit rejected' '
+ git reset &&
+ (echo e; echo n; echo d) | git add -p >output &&
+ grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+@@ -1,0 +1,0 @@
+ baseline
++content
++newcontent
++lines
+EOF
+cat >expected <<EOF
+diff --git a/file b/file
+index b5dd6c9..f910ae9 100644
+--- a/file
++++ b/file
+@@ -1,4 +1,4 @@
+ baseline
+ content
+-newcontent
++more
+ lines
+EOF
+test_expect_success 'real edit works' '
+ (echo e; echo n; echo d) | git add -p &&
+ git diff >output &&
+ test_cmp expected output
+'
+
if test "$(git config --bool core.filemode)" = false
then
say 'skipping filemode tests (filesystem does not properly support modes)'
--
1.5.4.5
^ permalink raw reply related
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: SZEDER Gábor @ 2008-07-01 11:41 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Bruce Stephens, git
In-Reply-To: <20080701101414.GG31309@elte.hu>
Hi Ingo,
On Tue, Jul 01, 2008 at 12:14:15PM +0200, Ingo Molnar wrote:
> i have a tip-curr (shortcut: 'tc') scriptlet to answer the "where I am
> amongst 100+ branches" question:
>
> earth4:~/tip> tc
> tip/master 200a86b: Merge branch 'x86/unify-setup'
>
> which is just a thin wrapper around git-log:
>
> earth4:~/tip> cat ~/bin/tip/tip-curr
> #!/bin/bash
>
> . ~/bin/tip/tip-lib
>
> echo "tip/"$(get_current_branch)" "$(git log -1 --pretty=format:"%h: %s")
how about displaying the current branch in the command prompt?
>From contrib/completion/git-completion.bash:
# 4) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
# are currently in a git repository. The %s token will be
# the name of the current branch.
Regards,
Gábor
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Miklos Vajna @ 2008-07-01 11:41 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Junio C Hamano, git
In-Reply-To: <20080701112235.GC11809@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Tue, Jul 01, 2008 at 01:22:35PM +0200, Ingo Molnar <mingo@elte.hu> wrote:
> [ Oh, and i could switch between git versions without having to rebuild
> ;-) ]
I remember about a mail from Junio where he wrote he has a lot of
versions installed under ~/git/git-version. So usually he has git from
next as default and he can try ~/git/git-1.5.4/git if he want 1.5.4,
etc.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.6.1
From: Steffen Prohaska @ 2008-07-01 11:29 UTC (permalink / raw)
To: msysGit, Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <7v3an0u367.fsf@gitster.siamese.dyndns.org>
On Jun 26, 2008, at 8:21 AM, Junio C Hamano wrote:
> The latest maintenance release GIT 1.5.6.1 is available at the
> usual places:
The msysgit release is available at
http://code.google.com/p/msysgit/downloads
Besides GIT 1.5.6.1, the installer also brings an updated
msys-1.0.dll that works on Vista.
Steffen
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Ingo Molnar @ 2008-07-01 11:22 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20080701111601.GT4729@genesis.frugalware.org>
* Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Jul 01, 2008 at 12:07:25PM +0200, Ingo Molnar <mingo@elte.hu> wrote:
> > !! You have installed git-* commands to new gitexecdir.
> > !! Old version git-* commands still remain in bindir.
> > !! Mixing two versions of Git will lead to problems.
> > !! Please remove old version commands in bindir now.
> >
> > that's an easily overlooked detail.
>
> There is a 10-lines-length note about this in RelNotes, but I think
> removing the old version is a task of the package manager. At least
> till the git Makefile does not have an 'uninstall' target.
random (likely stupid) idea: perhaps git could use ... a separate Git
repo to track gitexecdir installations in $HOME/bin/? That could be
tagged appropriately so you'd always know what to uninstall and whether
there are clashes or incompatibilities.
[ Oh, and i could switch between git versions without having to rebuild
;-) ]
Ingo
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Miklos Vajna @ 2008-07-01 11:16 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Junio C Hamano, git
In-Reply-To: <20080701100725.GE31309@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
On Tue, Jul 01, 2008 at 12:07:25PM +0200, Ingo Molnar <mingo@elte.hu> wrote:
> !! You have installed git-* commands to new gitexecdir.
> !! Old version git-* commands still remain in bindir.
> !! Mixing two versions of Git will lead to problems.
> !! Please remove old version commands in bindir now.
>
> that's an easily overlooked detail.
There is a 10-lines-length note about this in RelNotes, but I think
removing the old version is a task of the package manager. At least till
the git Makefile does not have an 'uninstall' target.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Ingo Molnar @ 2008-07-01 10:14 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git
In-Reply-To: <80iqvq2bw0.fsf@tiny.isode.net>
* Bruce Stephens <bruce.stephens@isode.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > i recently switched to 1.5.6.1.89.gd5446 and i'm getting this:
> >
> > Switched to branch "master"
> > Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
> >
> > it's a very useful detail! It's especially useful when two branches
> > diverge in a non-trivial way.
>
> I agree, it's a really nice little feature. Indeed, I occasionally do
> "git checkout master" just to get the message (to see where I am).
>
> It feels logical for "git status" to offer the same information (when
> the information is appropriate).
>
> [...]
i have a tip-curr (shortcut: 'tc') scriptlet to answer the "where I am
amongst 100+ branches" question:
earth4:~/tip> tc
tip/master 200a86b: Merge branch 'x86/unify-setup'
which is just a thin wrapper around git-log:
earth4:~/tip> cat ~/bin/tip/tip-curr
#!/bin/bash
. ~/bin/tip/tip-lib
echo "tip/"$(get_current_branch)" "$(git log -1 --pretty=format:"%h: %s")
Ingo
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2008-07-01 10:11 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <7v3amv1e8n.fsf@gitster.siamese.dyndns.org>
On Mon, Jun 30, 2008 at 02:08:56AM -0700, Junio C Hamano wrote:
> * js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
> + Allow git-apply to recount the lines in a hunk (AKA recountdiff)
>
> A good ingredient for implementing "apply --edit".
Thomas,
Now that this is in next, maybe it is a good time to repost the
add--interactive patch (it should be independent of Dscho's 2/2 "add -e"
patch).
-Peff
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Ingo Molnar @ 2008-07-01 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk0mne5d.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > i recently switched to 1.5.6.1.89.gd5446 and i'm getting this:
> >
> > Switched to branch "master"
> > Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
> >
> > it's a very useful detail! It's especially useful when two branches
> > diverge in a non-trivial way.
> > ...
> > but having a reminder at checkout time is even better (and faster as
> > well). Kudos.
>
> Thanks for a rare positive usability feedback. When I started reading
> your message, I almost expected that I'd hear you say "I am getting
> this useless cruft and it wastes extra cycles."
Git usability is certainly very good. (And what matters even more to me
than absolute usability, Git's usability is improving in a monotonic
way.)
[ You normally only hear from me if i find one of those rare outliers
that confuse me somewhere. So by reading my feedback you must be
getting an impression of problems only - that is far from the truth :) ]
> Somebody must have had a very bright idea that day in late February
> this year.
:)
There's a small detail i was thinking about: is there a way to get this
extra output without actually switching branches? Right now i do this:
earth4:~/tip> git-checkout tip; git-checkout master
Checking out files: 100% (2437/2437), done.
Switched to branch "tip"
Switched to branch "master"
Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
(Which is an admitted lame solution but the best i could figure.)
Also, and let me hijack this thread, i sometimes feel adventurous and
try out git/pu for kicks. I tried it two days ago and it was quite OK,
with some fallout:
- the git-dash changes broke half of our scripts around git. (We've got
about 50 tip-* scripts around various git details, about 2200 lines).
I did a mass changeover:
31 files changed, 150 insertions(+), 150 deletions(-)
... and that broke things too - see the two fixes below. I can
understand your desire for a git-dash-less world though, but it's
causing some pain :-) Also, i kept typoing "git-" commands all the time
so i switched back to git/master. Maybe there should be a transition
period where the dash scripts warn if used interactively? Dunno.
[ and there's also a git-rerere Heisenbug i have been fighting with a
lot with git-1.5.5. It's quite hard to reproduce and unfortunately i
cannot create a reproducer: but it resulted in git-rerere confusing
conflict resolutions and putting arch/x86/kernel/process_64.c
postimage entry into the entry for arch/x86/kernel/process_32.c's
postimage file, corrupting the integration run on the _next_ run.
Was there a bug in this area fixed recently that would show up with
such symptoms? The weirdness first showed up when i did a git-rerere
after having done a git-add arch/x86/kernel/process_64.c, git-rerere
printed that it added a new resolution for
arch/x86/kernel/process_32.c. ]
and i like this warning at the end of master/pu make install:
!! You have installed git-* commands to new gitexecdir.
!! Old version git-* commands still remain in bindir.
!! Mixing two versions of Git will lead to problems.
!! Please remove old version commands in bindir now.
that's an easily overlooked detail.
Ingo
--------------->
commit e87616175691dd7154cad049aae2b1bc1385bb7a
Author: Ingo Molnar <mingo@elte.hu>
Date: Mon Jun 30 09:29:36 2008 +0200
- fix more git-dash fallout
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff --git a/.tip/bin/tip-backup b/.tip/bin/tip-backup
index edd7991..682d68d 100755
--- a/.tip/bin/tip-backup
+++ b/.tip/bin/tip-backup
@@ -7,7 +7,7 @@ check_master
echo "backing up the full -tip repo ..."
mkdir -p ~/tip-backups || exit -1
-FILE=~/tip-backups/tip-git $(get_date_for_tag).tar.bz2
+FILE=~/tip-backups/tip-git-$(get_date_for_tag).tar.bz2
tar cjf $FILE .git || exit -1
commit 1bcce26cf0ba00ea62c051772f66d3e1c616e165
Author: H. Peter Anvin <hpa@zytor.com>
Date: Fri Jun 27 17:05:59 2008 -0700
tip-sync-remote: quote multiword commands in variables
When assigning a multiword command to a variable, it needs to be
quoted.
diff --git a/.tip/bin/tip-sync-remote b/.tip/bin/tip-sync-remote
index 6421e55..aeeb883 100755
--- a/.tip/bin/tip-sync-remote
+++ b/.tip/bin/tip-sync-remote
@@ -65,9 +65,9 @@ do
then
echo "Branch "$B" has local modifications"
echo "Rebasing local modifications to remote"
- CMD=git rebase
+ CMD='git rebase'
else
- CMD=git merge
+ CMD='git merge'
fi
$CMD origin/$B || {
^ permalink raw reply related
* Re: Multiple remote.<...>.fetch and .push patterns
From: Michael J Gruber @ 2008-07-01 9:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vprpynech.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 01.07.2008 11:27:
> Michael J Gruber <michaeljgruber+gmane@fastmail.fm> writes:
>
>> The files under remotes are the old way of configuring remotes (see
>> git help push). The new are config lines in the remotes section, as
>> written by "git remote". I don't think "git remote" can write the
>> lines you want, so I'd suggest:
>>
>> git config remote.ko.url kernel.org:/pub/scm/git/git.git
>> git config remote.ko.fetch refs/heads/master:refs/tags/ko-master
>> git config --add remote.ko.fetch refs/heads/next:refs/tags/ko-next
>> git config --add remote.ko.fetch refs/heads/maint:refs/tags/ko-maint
>
> I'd actually suggest:
>
> $ edit .git/config
Sure, it just seemed OP wanted cut-n-paste commands for his co-workers
(or ko-workers).
> and create this section:
>
> [remote "ko"]
> url = master.kernel.org:/pub/scm/git/git.git/
> fetch = +refs/heads/*:refs/remotes/ko/*
I think that's what OP wanted to avoid.
> push = heads/master
> push = heads/next
> push = +heads/pu
> push = heads/maint
>
> (I used to say ko-master but these days I say ko/master).
OK, that would make it ko/workers above ;)
Seriously: I found the info about those config keys in "git-push.1";
it's also in "git-{pull,fetch}.1". I would expect that info to be in
"git-{remote,config}.1". The latter points to it, the former not really.
Michael
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jeff King @ 2008-07-01 9:51 UTC (permalink / raw)
To: Adam Brewster; +Cc: git, Jakub Narebski
In-Reply-To: <c376da900806301549r6044cd35r5a23baa405570808@mail.gmail.com>
On Mon, Jun 30, 2008 at 06:49:25PM -0400, Adam Brewster wrote:
> Git-basis is a perl script that remembers bases for use by git-bundle.
> Code from rev-parse was borrowed to allow git-bundle to handle --stdin.
I don't use bundles myself, so I can't comment on how useful this is for
a bundle-based workflow. But it seems like a sensible idea in general.
A few comments:
> --- a/bundle.c
> +++ b/bundle.c
> @@ -227,8 +227,26 @@ int create_bundle(struct bundle_header *header,
> const char *path,
>
> /* write references */
> argc = setup_revisions(argc, argv, &revs, NULL);
> - if (argc > 1)
> - return error("unrecognized argument: %s'", argv[1]);
> +
> + for (i = 1; i < argc; i++) {
> + if ( !strcmp(argv[i], "--stdin") ) {
When a new feature depends on other, more generic improvements
to existing code, it is usually split into two patches. E.g.,
1/2: add --stdin to git-bundle
2/2: add git-basis
with the advantages that:
- it is slightly easier to review each change individually
- it is easier for other features to build on the generic improvement
without requiring part 2, especially if part 2 is questionable
As it happens in this case, I think in this case the change was already
easy to read, being logically separated by file, so I am nitpicking
somewhat. But splitting changes is a good habit to get into.
> + if (len && line[len - 1] == '\n')
> + line[--len] = 0;
Style: we usually spell NUL as '\0'.
> diff --git a/git-basis b/git-basis
> new file mode 100755
This should be git-basis.perl, with accompanying Makefile changes.
> +if ( ! -d "$d/bases" ) {
> + system( "mkdir '$d/bases'" );
> +}
Yikes. This fails if $d contains an apostrophe. You'd want to use
quotemeta to properly shell out. But there's no need at all to shell out
here, since perl has its own mkdir call.
> +if ( $#ARGV == -1 ) {
> + print "usage: git-basis [--update] basis1...\n";
> + exit;
Usage should probably go to STDERR.
> + my %new = ();
> + while (<STDIN>) {
> + if (!/^^?([a-z0-9]{40})/) {next;}
> + $new{$1} = 1;
> + }
Why make a hash when the only thing we ever do with it is "keys %new"?
Shouldn't an array suffice?
> + foreach my $f (@ARGV) {
> + my %these = ();
> + open F, "<$d/bases/$f" || die "Can't open bases/$f: $!";
Style: I know we are not consistent within git, but it is usually better
to use local variables for filehandles these days. I.e.,
open my $fh, "<$d/bases/$f"
> + open F, ">>$d/bases/$f" || die "Can't open bases/$f: $!";
So the basis just grows forever? That is, each time we do a bundle and
basis update, we add a line for every changed ref, and we never delete
any lines. But having a commit implies having all of its ancestors, so
in the normal case (i.e., no rewind or rebase) we can simply replace old
objects if we know they are a subset of the new ones (which you can
discover with git-merge-base). For the rewind/rebase case, probably
these lists should get pruned eventually for non-existent objects.
But maybe it is not worth worrying about this optimization at first, and
we can see if people complain. In that case, it is perhaps worth a note
in the 'Bugs' section (or 'Discussion' section) of the manpage.
> + print F "\#" . `date`;
I don't think there are any portability issues with 'date' (especially
since it appears to be just a comment here, so we don't really care
about the format), but in general I think it is nicer to use perl's date
functions just for consistency's sake.
> --
> 1.5.5.1.211.g65ea3.dirty
Notably absent: any tests.
-Peff
^ permalink raw reply
* [PATCH?] Fix 'git show' on signed tag of signed tag of commit
From: Thomas Rast @ 2008-07-01 9:47 UTC (permalink / raw)
To: git; +Cc: gitster, Thomas Rast
The cmd_show loop resolves tags by showing them, then pointing the
object to the 'tagged' member. However, this object is not fully
initialized; it only contains the SHA1. (This resulted in a segfault
if there were two levels of tags.) We apply parse_object to get a
full object.
Noticed by Kalle Olavi Niemitalo on IRC.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I'm not 100% sure this is the right fix; I just had a quick stab at
the code, made a fix and tested it. It probably leaks memory too, not
sure if this is a problem.
- Thomas
builtin-log.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 9817d6f..9979e37 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -360,7 +360,7 @@ int cmd_show(int argc, const char **argv, const char *prefix)
t->tag,
diff_get_color_opt(&rev.diffopt, DIFF_RESET));
ret = show_object(o->sha1, 1, &rev);
- objects[i].item = (struct object *)t->tagged;
+ objects[i].item = parse_object(t->tagged->sha1);
i--;
break;
}
--
1.5.6.1.246.g5fc88.dirty
^ permalink raw reply related
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Bruce Stephens @ 2008-07-01 9:26 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080701091347.GA11817@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> i recently switched to 1.5.6.1.89.gd5446 and i'm getting this:
>
> Switched to branch "master"
> Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
>
> it's a very useful detail! It's especially useful when two branches
> diverge in a non-trivial way.
I agree, it's a really nice little feature. Indeed, I occasionally do
"git checkout master" just to get the message (to see where I am).
It feels logical for "git status" to offer the same information (when
the information is appropriate).
[...]
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Junio C Hamano @ 2008-07-01 9:32 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080701091347.GA11817@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> i recently switched to 1.5.6.1.89.gd5446 and i'm getting this:
>
> Switched to branch "master"
> Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
>
> it's a very useful detail! It's especially useful when two branches
> diverge in a non-trivial way.
> ...
> but having a reminder at checkout time is even better (and faster as
> well). Kudos.
Thanks for a rare positive usability feedback. When I started reading
your message, I almost expected that I'd hear you say "I am getting this
useless cruft and it wastes extra cycles."
Somebody must have had a very bright idea that day in late February this
year.
^ permalink raw reply
* Re: Multiple remote.<...>.fetch and .push patterns
From: Junio C Hamano @ 2008-07-01 9:27 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g4croa$3eu$1@ger.gmane.org>
Michael J Gruber <michaeljgruber+gmane@fastmail.fm> writes:
> The files under remotes are the old way of configuring remotes (see
> git help push). The new are config lines in the remotes section, as
> written by "git remote". I don't think "git remote" can write the
> lines you want, so I'd suggest:
>
> git config remote.ko.url kernel.org:/pub/scm/git/git.git
> git config remote.ko.fetch refs/heads/master:refs/tags/ko-master
> git config --add remote.ko.fetch refs/heads/next:refs/tags/ko-next
> git config --add remote.ko.fetch refs/heads/maint:refs/tags/ko-maint
I'd actually suggest:
$ edit .git/config
and create this section:
[remote "ko"]
url = master.kernel.org:/pub/scm/git/git.git/
fetch = +refs/heads/*:refs/remotes/ko/*
push = heads/master
push = heads/next
push = +heads/pu
push = heads/maint
(I used to say ko-master but these days I say ko/master).
^ permalink raw reply
* Re: [PATCH] Teach "git apply" to prepend a prefix with "--root=<root>"
From: Junio C Hamano @ 2008-07-01 9:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: H. Peter Anvin, git
In-Reply-To: <alpine.DEB.1.00.0807010043440.9925@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With "git apply --root=<root>", all file names in the patch are prepended
> with <root>. If a "-p" value was given, the paths are stripped _before_
> prepending <root>.
> @@ -182,6 +182,10 @@ behavior:
> by inspecting the patch (e.g. after editing the patch without
> adjusting the hunk headers appropriately).
>
> +--root=<root>::
> + Prepend <root> to all filenames. If a "-p" argument was passed, too,
> + it is applied before prepending the new root.
> +
I looked for precedence of this concept outside git but did not find
anything that exactly matched.
The -p<num> came from patch where it is also called --strip=num. This new
option --root is about the reverse operation and it is about inserting at
the beginning --- it is rerooting, in other words, but then --root is good
enough and shorter. mkisofs uses the word "graft" when it allows tree
shifting (enabled with --graft-points), but the word "graft" means a
totally different thing to us, so we would not want to use that word.
I am not complaining (--root is fine by me), but just thinking aloud,
hoping somebody's brainwave is provoked while reading this babbling and
comes up with a better wording ;-).
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 9fcfe39..d56d913 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -58,6 +58,8 @@ static int whitespace_error;
> @@ -3240,6 +3252,18 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
> options |= RECOUNT;
> continue;
> }
> + if (!strncmp(arg, "--root=", strlen("--root="))) {
prefixcmp()?
> + arg += strlen("--root=");
> + root_len = strlen(arg);
> + if (root_len && arg[root_len + 1] != '/') {
Ah, being nice not to force trailing slash on users --- how unlike you ;-)
but I think you meant "arg[root_len - 1]" there...
Other than that, the change looks fine. Thanks.
^ permalink raw reply
* [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Ingo Molnar @ 2008-07-01 9:13 UTC (permalink / raw)
To: git
i recently switched to 1.5.6.1.89.gd5446 and i'm getting this:
Switched to branch "master"
Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
it's a very useful detail! It's especially useful when two branches
diverge in a non-trivial way.
I used to have ad-hoc scripts to discover this in the past:
earth4:~/tip> tip-compare-remote
master : differs from remote (-50 commits)
tip : differs from remote (-1 commits)
x86/ptrace : differs from remote (-1 commits)
x86/unify-setup : differs from remote (-2 commits)
x86/xen-64bit : differs from remote (-1 commits)
but having a reminder at checkout time is even better (and faster as
well). Kudos.
Ingo
^ permalink raw reply
* Re: [RFC] Single system account for multiple git users
From: Melchior FRANZ @ 2008-07-01 8:55 UTC (permalink / raw)
To: git
In-Reply-To: <20080630151113.GO5737@dpotapov.dyndns.org>
* Dmitry Potapov -- Monday 30 June 2008:
> [...] but it requres that every Git user has a separate system
> account on the server, which is often frowned upon by system
> administrators, who would prefer to have a single system account
> for access to Git repo.
Indeed. This is AFAIK the main reason why git might not be used
by a project where I'm contributor. gitosis could help here, but
I guess that a built-in solution would be preferred. An external
addon looks a bit like band-aid. ;-)
m.
^ permalink raw reply
* Re: Multiple remote.<...>.fetch and .push patterns
From: Michael J Gruber @ 2008-07-01 9:00 UTC (permalink / raw)
To: git
In-Reply-To: <308083c30806301252l25f072anafbc457f48c6b19e@mail.gmail.com>
Adr3nal D0S venit, vidit, dixit 30.06.2008 21:52:
> In reference to my question about .git/remotes/ko, Jon Loeliger
> <jdl@freescale.com> wrote:
>
>> You can have both Push: and Pull: lines for a remote there.
>>
>> Or have I misunderstood your question here?
>
> I know that I can create files in .git/remotes that look like Linus'
> ko sample. But I was wondering if this could be done with git-config.
> I have some developers that are new to SCMs in general and git in
> particular. They are a little nervous playing in the git directory.
>
> Also, I was uncertain how settings in .git/remotes files interact with
> git-config ...fetch and ...push settings, if at all.
The files under remotes are the old way of configuring remotes (see git
help push). The new are config lines in the remotes section, as written
by "git remote". I don't think "git remote" can write the lines you
want, so I'd suggest:
git config remote.ko.url kernel.org:/pub/scm/git/git.git
git config remote.ko.fetch refs/heads/master:refs/tags/ko-master
git config --add remote.ko.fetch refs/heads/next:refs/tags/ko-next
git config --add remote.ko.fetch refs/heads/maint:refs/tags/ko-maint
You can add similar lines for push with the key remote.ko.push. Note
that you have to use "--add" if you want to have multiple lines for the
same key in config. Also, you can add a "+" in front of the refspec, but
I'm a bit surprised you want that on pushing to ko.
Cheers,
Michael
^ permalink raw reply
* Re: git sequencer prototype
From: Junio C Hamano @ 2008-07-01 8:51 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Johannes Schindelin
In-Reply-To: <1214879914-17866-1-git-send-email-s-beyer@gmx.net>
Stephan Beyer <s-beyer@gmx.net> writes:
> I'm using sequencer-based git-am and git-rebase-i and also git-sequencer
> itself for around 2-3 weeks now. So, for me, it is reality-proven, but
> I'm curious about your opinions/suggestions in usage and source.
Thanks.
> The migration patches are a little hard to code-review in the diff-form,
> but feel free to apply, test, and then look at the code ;)
Heh, these three typically come in different order. Look at the log
message and docs to see if the design is sound, then look at the code, and
if things overall look Ok, then finally apply and test.
I unfortunately ran out of time tonight and will look at them probably
Thursday evening. It seems that another GSoC topic is finally nearing
completion and I can shift my attention to other topics now.
By the way Christian is not CC'ed?
^ permalink raw reply
* Re: [PATCH 0/7] Some superficial documentation changes
From: Junio C Hamano @ 2008-07-01 8:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Christian Couder, Nguyen Thai Ngoc Duy, Jon Loeliger
In-Reply-To: <Pine.GSO.4.62.0806301650530.7190@harper.uchicago.edu>
Jonathan Nieder <jrnieder@uchicago.edu> writes:
> But at least I was able to check that patch 6/7 (which redistributes the
> dashes in the world) doesn't touch anything but spaces and hyphens.
> Hopefully that should make this easier to review.
Yes, the earlier "line break adjustments" patch really helped.
I've queued all of them to 'pu' while reading them over, except for the
last one. I did not look very carefully, but the parts I did look at made
sense.
In general, I've always preferred to see command names "git-foo" typeset
in teletype face, consistent with examples (also typeset in tt), because
they are both something the end users are expected to type. With this
transition, we are however making "git-foo" not something users are
expected to type, which means that the use of a typeface that is different
from the body text to spell command names is now strictly for making them
stand out in context. In that sense, I share your hesitation about the
last one to use tt for command names. It probably is better to use italic
now.
On my next git day (coming Wednesday, if nothing goes wrong at day job),
I'll merge all except the last one to 'master' so that the HTML version of
the manual page k.org serves to the general public is updated and we can
get a wider exposure to looking for conversion errors more easily. If you
also prefer 'italics' and list agrees, it might be a better idea to also
apply that patch when I do so, as that step is the most error prone one
and benefits from more eyeballs.
Thanks.
^ 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