* [PATCH 5/5] Added diff hunk coloring to git-add--interactive
From: Dan Zwell @ 2007-11-22 10:56 UTC (permalink / raw)
To: Git Mailing List
Cc: Jeff King, Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <20071110180109.34febc3f@paradox.zwell.net>
Added and integrated method "color_diff_hunk", which colors
lines, and returns them in an array. Coloring bad whitespace is
not yet supported.
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
git-add--interactive.perl | 93 ++++++++++++++++++++++++++++++++++----------
1 files changed, 72 insertions(+), 21 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index f76f008..ba9430c 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -4,9 +4,12 @@ use strict;
use Git;
my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
+my ($diff_use_color, $new_color, $old_color, $fraginfo_color,
+ $metainfo_color, $whitespace_color);
{
my $repo = Git->repository();
+
# set interactive color options:
my $color_config = $repo->config('color.interactive');
$use_color = 0;
@@ -21,27 +24,55 @@ my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
$use_color = 1;
}
- if ($use_color) {
+ # set diff color options
+ my $diff_color_config = $repo->config('color.diff');
+ if (!defined $diff_color_config) {
+ $diff_use_color = 0;
+ }
+ elsif ($diff_color_config =~ /true|always/) {
+ $diff_use_color = 1;
+ }
+ elsif ($diff_color_config eq 'auto' && -t STDOUT &&
+ $ENV{'TERM'} ne 'dumb') {
+ $diff_use_color = 1;
+ }
+
+ # load color library if needed
+ if ($use_color || $diff_use_color) {
eval { require Term::ANSIColor; };
if ($@) {
# library did not load.
$use_color = 0;
+ $diff_use_color = 0;
}
- else { # set up colors
- # Grab the 3 main colors in git color string format, with sane
- # (visible) defaults:
- $prompt_color = Git::color_to_ansi_code(
- scalar $repo->config_default('color.interactive.prompt',
- 'bold blue'));
- $header_color = Git::color_to_ansi_code(
- scalar $repo->config_default('color.interactive.header',
- 'bold'));
- $help_color = Git::color_to_ansi_code(
- scalar $repo->config_default('color.interactive.help',
- 'red bold'));
+ }
- $normal_color = Git::color_to_ansi_code('normal');
- }
+ # convenience function:
+ sub get_color {
+ my ($key, $default) = @_;
+ return Git::color_to_ansi_code(
+ scalar $repo->config_default($key, $default));
+ }
+ # set interactive colors
+ if ($use_color) {
+ # Grab the 3 main colors in git color string format, with sane
+ # (visible) defaults:
+ $prompt_color = get_color('color.interactive.prompt', 'bold blue');
+ $header_color = get_color('color.interactive.header', 'bold');
+ $help_color = get_color('color.interactive.help', 'red bold');
+ $normal_color = Git::color_to_ansi_code('normal');
+ }
+
+ # set diff colors
+ if ($diff_use_color) {
+ $new_color = get_color('color.diff.new', 'green');
+ $old_color = get_color('color.diff.old', 'red');
+ $fraginfo_color = get_color('color.diff.frag', 'cyan');
+ $metainfo_color = get_color('color.diff.meta', 'bold');
+ $normal_color = Git::color_to_ansi_code('normal');
+ # Not implemented:
+ #$whitespace_color = get_color('color.diff.whitespace',
+ #'normal red');
}
}
@@ -410,6 +441,30 @@ sub parse_diff {
return @hunk;
}
+sub color_diff_hunk {
+ # return the colored text, so that it can be passed to print()
+ my ($text) = @_;
+ if (!$diff_use_color) {
+ return @$text;
+ }
+
+ my @ret;
+ for (@$text) {
+ if (/^\+/) {
+ push @ret, colored($new_color, $_);
+ } elsif (/^\-/) {
+ push @ret, colored($old_color, $_);
+ } elsif (/^\@/) {
+ push @ret, colored($fraginfo_color, $_);
+ } elsif (/^ /) {
+ push @ret, colored($normal_color, $_);
+ } else {
+ push @ret, colored($metainfo_color, $_);
+ }
+ }
+ return @ret;
+}
+
sub hunk_splittable {
my ($text) = @_;
@@ -632,9 +687,7 @@ sub patch_update_cmd {
my ($ix, $num);
my $path = $it->{VALUE};
my ($head, @hunk) = parse_diff($path);
- for (@{$head->{TEXT}}) {
- print;
- }
+ print color_diff_hunk($head->{TEXT});
$num = scalar @hunk;
$ix = 0;
@@ -676,9 +729,7 @@ sub patch_update_cmd {
if (hunk_splittable($hunk[$ix]{TEXT})) {
$other .= '/s';
}
- for (@{$hunk[$ix]{TEXT}}) {
- print;
- }
+ print color_diff_hunk($hunk[$ix]{TEXT});
print colored($prompt_color, "Stage this hunk [y/n/a/d$other/?]? ");
my $line = <STDIN>;
if ($line) {
--
1.5.3.5.565.gf0b83-dirty
^ permalink raw reply related
* Re: Temporary directories getting errantly added into trees
From: Martin Langhoff @ 2007-11-22 11:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711221052280.27959@racer.site>
On Nov 22, 2007 11:55 PM, Johannes Schindelin > While we're at it,
could we change the name so that it is .git/rebase, and
> not .dotest or .git/.dotest-merge?
+1 on that
> ... And indeed, I see no reason why a tool should access
> .dotest, except for accessing .dotest/patch, and then it will be very
> obvious where it fails.
when it comes to .dotest/patch, it must be reasonably accessible. When
git-am refuses to apply a patch, and I am resolving things by hand, I
need it pretty handy. I also sometimes edit .dotest/msg-clean.
cheers,
m
^ permalink raw reply
* Re: [PATCH 3/4] Teach builtin-add to pass multiple paths to git-add--interactive
From: Wincent Colaiuta @ 2007-11-22 11:02 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20071122103339.GA12692@sigill.intra.peff.net>
El 22/11/2007, a las 11:33, Jeff King escribió:
> On Thu, Nov 22, 2007 at 11:28:17AM +0100, Wincent Colaiuta wrote:
>
>>>> + memcpy((void *)args + sizeof(const char *), argv, sizeof(const
>>>> char *) *
>>>> argc);
>>>
>>> The source for the memcpy (argv) is sometimes NULL. The standard
>>> forbids
>>> this, even when the size field is 0. I have no idea if any
>>> reasonable
>>> implementations actually care.
>>
>> Good point. I've now conditionalized the memcpy with an "if (argc >
>> 0)".
>> While I was at it I also got rid of the unneeded cast to void *.
>
> I don't think you need it if you do the other cleanup (since you will
> always be passing a valid argv pointer).
True, argv will never be NULL. We'll still be doing a zero-byte memcpy
though, which I guess is not a big deal here. I'll drop the conditional.
Cheers,
Wincent
^ permalink raw reply
* [PATCH 4/5] Let git-add--interactive read colors from configuration
From: Dan Zwell @ 2007-11-22 10:56 UTC (permalink / raw)
To: Git Mailing List
Cc: Jeff King, Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <20071110180109.34febc3f@paradox.zwell.net>
Colors are specified in color.interactive.{prompt,header,help}.
They are specified as git color strings as described in the
documentation. The method color_to_ansi_code() in Git.pm parses
these strings and returns ANSI color codes (using
Term::ANSIColor).
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
Documentation/config.txt | 7 ++++
git-add--interactive.perl | 20 ++++++++---
perl/Git.pm | 80 ++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 100 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3712d6a..47c1ab2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -388,6 +388,13 @@ color.interactive::
`auto`, use colors only when the output is to the
terminal. Defaults to false.
+color.interactive.<slot>::
+ Use customized color for `git add --interactive`
+ output. `<slot>` may be `prompt`, `header`, or `help`, for
+ three distinct types of normal output from interactive
+ programs. The values of these variables may be specified as
+ in color.branch.<slot>.
+
color.pager::
A boolean to enable/disable colored output when the pager is in
use (default is true).
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 2b5559f..f76f008 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -6,8 +6,8 @@ use Git;
my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
{
- # set color options:
my $repo = Git->repository();
+ # set interactive color options:
my $color_config = $repo->config('color.interactive');
$use_color = 0;
if (!defined $color_config) {
@@ -28,11 +28,19 @@ my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
$use_color = 0;
}
else { # set up colors
- # Sane (visible) defaults:
- $prompt_color = Term::ANSIColor::color('blue bold');
- $header_color = Term::ANSIColor::color('bold');
- $help_color = Term::ANSIColor::color('red bold');
- $normal_color = Term::ANSIColor::color('reset');
+ # Grab the 3 main colors in git color string format, with sane
+ # (visible) defaults:
+ $prompt_color = Git::color_to_ansi_code(
+ scalar $repo->config_default('color.interactive.prompt',
+ 'bold blue'));
+ $header_color = Git::color_to_ansi_code(
+ scalar $repo->config_default('color.interactive.header',
+ 'bold'));
+ $help_color = Git::color_to_ansi_code(
+ scalar $repo->config_default('color.interactive.help',
+ 'red bold'));
+
+ $normal_color = Git::color_to_ansi_code('normal');
}
}
}
diff --git a/perl/Git.pm b/perl/Git.pm
index 7327300..18ef6b4 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -515,7 +515,6 @@ sub config {
};
}
-
=item config_bool ( VARIABLE )
Retrieve the bool configuration C<VARIABLE>. The return value
@@ -578,6 +577,85 @@ sub config_default {
}
}
+=item color_to_ansi_code ( COLOR )
+
+Converts a git-style color string, like "underline blue white" to
+an ANSI color code. The code is generated by Term::ANSIColor,
+after the string is parsed into the format that is accepted by
+that module. Used as follows:
+
+ print color_to_ansi_code("underline blue white");
+ print "some text";
+ print color_to_ansi_code("normal");
+
+color_to_ansi_code('') returns the empty string, and should do
+nothing when printed.
+
+=cut
+
+sub color_to_ansi_code {
+ my ($git_string) = @_;
+ my @ansi_words;
+ my %git_to_perl_color = (
+ 'bold' => 'bold',
+ 'ul' => 'underline',
+ 'blink' => 'blink',
+ 'reverse' => 'reverse'
+ # not supported by Term::ANSIColor:
+ #'dim' => ''
+ );
+ my %valid_color = map { $_ => 1 } qw(black red green yellow
+ blue magenta cyan white);
+
+ my ($fg_done, $token);
+ foreach $token (split /\s+/, $git_string) {
+ $token = lc($token);
+
+ if ($token eq 'normal') {
+ $fg_done = 1;
+ }
+ elsif (exists $valid_color{$token}) {
+ # is a color.
+ if ($fg_done) {
+ # this is the background
+ push @ansi_words, 'on_' . $token;
+ }
+ else {
+ # this is foreground
+ $fg_done = 1;
+ push @ansi_words, $token;
+ }
+ }
+ else {
+ # this is an attribute, not a color.
+ if ($git_to_perl_color{$token}) {
+ push(@ansi_words,
+ $git_to_perl_color{$token});
+ }
+ else {
+ print STDERR 'Warning: bad color or attribute: ';
+ print STDERR "\"$token\". Check git configuration.\n";
+ }
+ }
+ }
+
+ # decide what to return--return color codes, 'clear' code, or
+ # the empty string, depending on the input we were passed /
+ # what we have processed:
+ if (@ansi_words) {
+ return Term::ANSIColor::color(join(' ', @ansi_words));
+ }
+ else {
+ if ($fg_done) {
+ # the git attrib 'normal' was processed
+ return Term::ANSIColor::color('clear');
+ }
+ else {
+ return '';
+ }
+ }
+}
+
=item ident ( TYPE | IDENTSTR )
=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
--
1.5.3.5.565.gf0b83-dirty
^ permalink raw reply related
* Re: Addendum to "MaintNotes"
From: Jeff King @ 2007-11-22 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Ping Yin
In-Reply-To: <7vve7u5zoz.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 22, 2007 at 02:42:20AM -0800, Junio C Hamano wrote:
> Heh, thanks. I am hoping somebody do grammartical copyediting
> and throw back a patch to add it in Documentation/howto.
I just read it over and that was the only error I noticed (though there
might be conceptual errors or confusing things that others could point
out better -- I actually knew a lot of this information already. At
least I'm one extra pair of eyes).
Patch is below. Besides the intro, the diff from your original is:
@@ -90,7 +99,7 @@ by doing the following:
This step is done with "git am".
- $ git checkout maint ;# or "git checkout maint"
+ $ git checkout master ;# or "git checkout maint"
$ git am -3 -s mailbox
$ make test
@@ -168,7 +177,8 @@ by doing the following:
- Update "What's cooking" message to review the updates to
existing topics, newly added topics and graduated topics.
- This step is helped with Meta/UWC script.
+ This step is helped with Meta/UWC script (where Meta/ contains
+ a checkout of the 'todo' branch).
- Merge topics to 'next'. For each branch whose tip is not
merged to 'next', one of three things can happen:
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Add "how to maintain git" document. Foreward by Jeff King.
---
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
new file mode 100644
index 0000000..159a0a3
--- /dev/null
+++ b/Documentation/howto/maintain-git.txt
@@ -0,0 +1,278 @@
+How to maintain git
+===================
+
+Imagine that git development is racing along as usual, when our friendly
+neighborhood maintainer is struck down by a wayward bus. Out of the
+hordes of suckers^W loyal developers, you have been tricked^W chosen to
+step up as the new maintainer. This howto will show you "how to" do it.
+
+-- >8 --
+The maintainer's git time is spent on three activities.
+
+ - Communication (60%)
+
+ Mailing list discussions on general design, fielding user
+ questions, diagnosing bug reports; reviewing, commenting on,
+ suggesting alternatives to, and rejecting patches.
+
+ - Integration (30%)
+
+ Applying new patches from the contributors while spotting and
+ correcting minor mistakes, shuffling the integration and
+ testing branches, pushing the results out, cutting the
+ release, and making announcements.
+
+ - Own development (10%)
+
+ Scratching my own itch and sending proposed patch series out.
+
+The policy on Integration is informally mentioned in "A Note
+from the maintainer" message, which is periodically posted to
+this mailing list after each feature release is made.
+
+The policy.
+
+ - Feature releases are numbered as vX.Y.Z and are meant to
+ contain bugfixes and enhancements in any area, including
+ functionality, performance and usability, without regression.
+
+ - Maintenance releases are numbered as vX.Y.Z.W and are meant
+ to contain only bugfixes for the corresponding vX.Y.Z feature
+ release and earlier maintenance releases vX.Y.Z.V (V < W).
+
+ - 'master' branch is used to prepare for the next feature
+ release. In other words, at some point, the tip of 'master'
+ branch is tagged with vX.Y.Z.
+
+ - 'maint' branch is used to prepare for the next maintenance
+ release. After the feature release vX.Y.Z is made, the tip
+ of 'maint' branch is set to that release, and bugfixes will
+ accumulate on the branch, and at some point, the tip of the
+ branch is tagged with vX.Y.Z.1, vX.Y.Z.2, and so on.
+
+ - 'next' branch is used to publish changes (both enhancements
+ and fixes) that (1) have worthwhile goal, (2) are in a fairly
+ good shape suitable for everyday use, (3) but have not yet
+ demonstrated to be regression free. New changes are tested
+ in 'next' before merged to 'master'.
+
+ - 'pu' branch is used to publish other proposed changes that do
+ not yet pass the criteria set for 'next'.
+
+ - The tips of 'master', 'maint' and 'next' branches will always
+ fast forward, to allow people to build their own
+ customization on top of them.
+
+ - Usually 'master' contains all of 'maint', 'next' contains all
+ of 'master' and 'pu' contains all of 'next'.
+
+ - The tip of 'master' is meant to be more stable than any
+ tagged releases, and the users are encouraged to follow it.
+
+ - The 'next' branch is where new action takes place, and the
+ users are encouraged to test it so that regressions and bugs
+ are found before new topics are merged to 'master'.
+
+
+A typical git day for the maintainer implements the above policy
+by doing the following:
+
+ - Scan mailing list and #git channel log. Respond with review
+ comments, suggestions etc. Kibitz. Collect potentially
+ usable patches from the mailing list. Patches about a single
+ topic go to one mailbox (I read my mail in Gnus, and type
+ \C-o to save/append messages in files in mbox format).
+
+ - Review the patches in the saved mailboxes. Edit proposed log
+ message for typofixes and clarifications, and add Acks
+ collected from the list. Edit patch to incorporate "Oops,
+ that should have been like this" fixes from the discussion.
+
+ - Classify the collected patches and handle 'master' and
+ 'maint' updates:
+
+ - Obviously correct fixes that pertain to the tip of 'maint'
+ are directly applied to 'maint'.
+
+ - Obviously correct fixes that pertain to the tip of 'master'
+ are directly applied to 'master'.
+
+ This step is done with "git am".
+
+ $ git checkout master ;# or "git checkout maint"
+ $ git am -3 -s mailbox
+ $ make test
+
+ - Merge downwards (maint->master):
+
+ $ git checkout master
+ $ git merge maint
+ $ make test
+
+ - Review the last issue of "What's cooking" message, review the
+ topics scheduled for merging upwards (topic->master and
+ topic->maint), and merge.
+
+ $ git checkout master ;# or "git checkout maint"
+ $ git merge ai/topic ;# or "git merge ai/maint-topic"
+ $ git log -p ORIG_HEAD.. ;# final review
+ $ git diff ORIG_HEAD.. ;# final review
+ $ make test ;# final review
+ $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"
+
+ - Merge downwards (maint->master) if needed:
+
+ $ git checkout master
+ $ git merge maint
+ $ make test
+
+ - Merge downwards (master->next) if needed:
+
+ $ git checkout next
+ $ git merge master
+ $ make test
+
+ - Handle the remaining patches:
+
+ - Anything unobvious that is applicable to 'master' (in other
+ words, does not depend on anything that is still in 'next'
+ and not in 'master') is applied to a new topic branch that
+ is forked from the tip of 'master'. This includes both
+ enhancements and unobvious fixes to 'master'. A topic
+ branch is named as ai/topic where "ai" is typically
+ author's initial and "topic" is a descriptive name of the
+ topic (in other words, "what's the series is about").
+
+ - An unobvious fix meant for 'maint' is applied to a new
+ topic branch that is forked from the tip of 'maint'. The
+ topic is named as ai/maint-topic.
+
+ - Changes that pertain to an existing topic are applied to
+ the branch, but:
+
+ - obviously correct ones are applied first;
+
+ - questionable ones are discarded or applied to near the tip;
+
+ - Replacement patches to an existing topic are accepted only
+ for commits not in 'next'.
+
+ The above except the "replacement" are all done with:
+
+ $ git am -3 -s mailbox
+
+ while patch replacement is often done by:
+
+ $ git format-patch ai/topic~$n..ai/topic ;# export existing
+
+ then replace some parts with the new patch, and reapplying:
+
+ $ git reset --hard ai/topic~$n
+ $ git am -3 -s 000*.txt
+
+ The full test suite is always run for 'maint' and 'master'
+ after patch application; for topic branches the tests are run
+ as time permits.
+
+ - Update "What's cooking" message to review the updates to
+ existing topics, newly added topics and graduated topics.
+
+ This step is helped with Meta/UWC script (where Meta/ contains
+ a checkout of the 'todo' branch).
+
+ - Merge topics to 'next'. For each branch whose tip is not
+ merged to 'next', one of three things can happen:
+
+ - The commits are all next-worthy; merge the topic to next:
+
+ $ git checkout next
+ $ git merge ai/topic ;# or "git merge ai/maint-topic"
+ $ make test
+
+ - The new parts are of mixed quality, but earlier ones are
+ next-worthy; merge the early parts to next:
+
+ $ git checkout next
+ $ git merge ai/topic~2 ;# the tip two are dubious
+ $ make test
+
+ - Nothing is next-worthy; do not do anything.
+
+ - Rebase topics that do not have any commit in next yet. This
+ step is optional but sometimes is worth doing when an old
+ series that is not in next can take advantage of low-level
+ framework change that is merged to 'master' already.
+
+ $ git rebase master ai/topic
+
+ This step is helped with Meta/git-topic.perl script to
+ identify which topic is rebaseable. There also is a
+ pre-rebase hook to make sure that topics that are already in
+ 'next' are not rebased beyond the merged commit.
+
+ - Rebuild "pu" to merge the tips of topics not in 'next'.
+
+ $ git checkout pu
+ $ git reset --hard next
+ $ git merge ai/topic ;# repeat for all remaining topics
+ $ make test
+
+ This step is helped with Meta/PU script
+
+ - Push four integration branches to a private repository at
+ k.org and run "make test" on all of them.
+
+ - Push four integration branches to /pub/scm/git/git.git at
+ k.org. This triggers its post-update hook which:
+
+ (1) runs "git pull" in $HOME/git-doc/ repository to pull
+ 'master' just pushed out;
+
+ (2) runs "make doc" in $HOME/git-doc/, install the generated
+ documentation in staging areas, which are separate
+ repositories that have html and man branches checked
+ out.
+
+ (3) runs "git commit" in the staging areas, and run "git
+ push" back to /pub/scm/git/git.git/ to update the html
+ and man branches.
+
+ (4) installs generated documentation to /pub/software/scm/git/docs/
+ to be viewed from http://www.kernel.org/
+
+ - Fetch html and man branches back from k.org, and push four
+ integration branches and the two documentation branches to
+ repo.or.cz
+
+
+Some observations to be made.
+
+ * Each topic is tested individually, and also together with
+ other topics cooking in 'next'. Until it matures, none part
+ of it is merged to 'master'.
+
+ * A topic already in 'next' can get fixes while still in
+ 'next'. Such a topic will have many merges to 'next' (in
+ other words, "git log --first-parent next" will show many
+ "Merge ai/topic to next" for the same topic.
+
+ * An unobvious fix for 'maint' is cooked in 'next' and then
+ merged to 'master' to make extra sure it is Ok and then
+ merged to 'maint'.
+
+ * Even when 'next' becomes empty (in other words, all topics
+ prove stable and are merged to 'master' and "git diff master
+ next" shows empty), it has tons of merge commits that will
+ never be in 'master'.
+
+ * In principle, "git log --first-parent master..next" should
+ show nothing but merges (in practice, there are fixup commits
+ and reverts that are not merges).
+
+ * Commits near the tip of a topic branch that are not in 'next'
+ are fair game to be discarded, replaced or rewritten.
+ Commits already merged to 'next' will not be.
+
+ * Being in the 'next' branch is not a guarantee for a topic to
+ be included in the next feature release. Being in the
+ 'master' branch typically is.
^ permalink raw reply related
* Re: Addendum to "MaintNotes"
From: Jeff King @ 2007-11-22 11:09 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, Git Mailing List, Ping Yin
In-Reply-To: <85pry2ftee.fsf@lola.goethe.zz>
On Thu, Nov 22, 2007 at 11:48:09AM +0100, David Kastrup wrote:
> > Now I've written this down, I can sleep well at night, knowing
> > that I can safely be hit by a bus any day ;-)
>
> So regarding git development, a bus error will no longer imply a core
> dump?
I'm slightly ashamed to admit to laughing at that.
-Peff
^ permalink raw reply
* Re: [PATCH v2] builtin-commit: Include the diff in the commit message when verbose.
From: Jeff King @ 2007-11-22 11:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kristian Høgsberg, gitster, git
In-Reply-To: <Pine.LNX.4.64.0711221049350.27959@racer.site>
On Thu, Nov 22, 2007 at 10:52:04AM +0000, Johannes Schindelin wrote:
> > + /* Sigh, the entire diff machinery is hardcoded to output to
> > + * stdout. Do the dup-dance...*/
>
> I wonder how much effort it would be to change that. Not that it would
> help too much, since we want the output in a strbuf anyway.
An "emit"-type callback would be nice and elegant. The biggest trick is
that there are a lot of formatting calls, so you'd need your callback
signature to be a variadic function. But it's probably do-able.
-Peff
^ permalink raw reply
* Re: [PATCH] Add path-limiting to git-add--interactive
From: Wincent Colaiuta @ 2007-11-22 11:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff
In-Reply-To: <7vpry27id0.fsf@gitster.siamese.dyndns.org>
El 22/11/2007, a las 10:13, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> @@ -56,9 +56,14 @@ sub list_modified {
>> my ($only) = @_;
>> my (%data, @return);
>> my ($add, $del, $adddel, $file);
>> + my @tracked = grep {
>> + defined run_cmd_pipe(qw(git ls-files
>> + --exclude-standard --), $_)
>> + } @ARGV;
>> + return if $#tracked == -1 && $#ARGV != -1;
>
> Eek. why?
>
> Did you mean to say:
>
> my @tracked = run_cmd_pipe(gw(git ls-files --exclude-standard --)
> @ARGV);
Bah, indeed that will work. I mistakenly (stupidly?) thought I had to
check each path in @ARGV one at a time; didn't realize that I could
pass in all at once and that it would do the right thing.... I've
incorporated the suggested change.
> It would also make sense to use --error-unmatch and perhaps --with-
> tree=HEAD
> like git-commit.sh does.
My reading of the run_cmd_pipe function indicates that those options
won't have any effect at all because run_cmd_pipe doesn't check the
exit status of the command.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] rebase -i: move help to end of todo file
From: Johannes Schindelin @ 2007-11-22 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk8q7hzg.fsf@gitster.siamese.dyndns.org>
Many editors start in the first line, so the 9-line help text was an
annoyance. So move it to the end.
Requested by Junio.
While at it, add a hint how to abort the rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Thu, 22 Nov 2007, Junio C Hamano wrote:
> Could we please reorder the lines so that list of initial
> "pick"s come first and have the help comment lines at the very
> end?
How about this? I am hesitant to remove _everything_, since quite
a few people seem to be allergic to man pages, so they fire up
rebase -i without any clue.
git-rebase--interactive.sh | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a6dc72a..aca2fbb 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -480,20 +480,23 @@ do
SHORTHEAD=$(git rev-parse --short $HEAD)
SHORTONTO=$(git rev-parse --short $ONTO)
cat > "$TODO" << EOF
-# Rebasing $SHORTUPSTREAM..$SHORTHEAD onto $SHORTONTO
-#
+# Rebasing $SHORTUPSTREAM..$SHORTHEAD onto $SHORTONTO (see end for help)
+EOF
+ git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
+ --abbrev=7 --reverse --left-right --cherry-pick \
+ $UPSTREAM...$HEAD | \
+ sed -n "s/^>/pick /p" >> "$TODO"
+ cat >> "$TODO" << EOF
+
# Commands:
# pick = use commit
# edit = use commit, but stop for amending
# squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
+# However, if you remove everything, the rebase will be aborted.
#
EOF
- git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --cherry-pick \
- $UPSTREAM...$HEAD | \
- sed -n "s/^>/pick /p" >> "$TODO"
has_action "$TODO" ||
die_abort "Nothing to do"
--
1.5.3.6.1977.g54d30
^ permalink raw reply related
* Re: Temporary directories getting errantly added into trees
From: Jeff King @ 2007-11-22 11:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711221052280.27959@racer.site>
On Thu, Nov 22, 2007 at 10:55:00AM +0000, Johannes Schindelin wrote:
> While we're at it, could we change the name so that it is .git/rebase, and
> not .dotest or .git/.dotest-merge?
I totally agree.
> Yes, I know, existing tools could rely on the location. But then, I do
> not think that tools should be allowed to be _that_ married to particular
> implementations. And indeed, I see no reason why a tool should access
> .dotest, except for accessing .dotest/patch, and then it will be very
> obvious where it fails.
Another reason might be something like:
test -d .dotest && die "rebase or am already in progress"
which some of the git tools do, and which third party scripts might care
about.
-Peff
^ permalink raw reply
* [PATCH] rebase -i: give rerere a chance
From: Johannes Schindelin @ 2007-11-22 11:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk8q7hzg.fsf@gitster.siamese.dyndns.org>
Like non-interactive rebase, interactive mode now calls rerere when
appropriate.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
While I was working with rebase -i yesterday, I realised that it
did not call rerere at all. And sure enough, there was a
NEEDSWORK in rebase -i for that.
Now, I _hope_ I got all the locations where the rerere should be
cleared, but this could use a few pairs of eyeballs.
git-rebase--interactive.sh | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index ead7da7..a6dc72a 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -81,6 +81,7 @@ make_patch () {
die_with_patch () {
make_patch "$1"
+ git rerere
die "$2"
}
@@ -166,13 +167,13 @@ pick_one_preserving_merges () {
msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
# No point in merging the first parent, that's HEAD
new_parents=${new_parents# $first_parent}
- # NEEDSWORK: give rerere a chance
if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
output git merge $STRATEGY -m "$msg" \
$new_parents
then
+ git rerere
printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
die Error redoing merge $sha1
fi
@@ -360,6 +361,7 @@ do
--abort)
comment_for_reflog abort
+ git rerere clear
test -d "$DOTEST" || die "No interactive rebase running"
HEADNAME=$(cat "$DOTEST"/head-name)
@@ -376,6 +378,7 @@ do
--skip)
comment_for_reflog skip
+ git rerere clear
test -d "$DOTEST" || die "No interactive rebase running"
output git reset --hard && do_rest
--
1.5.3.6.1977.g54d30
^ permalink raw reply related
* [PATCH 1/5] Added basic color support to git add --interactive
From: Dan Zwell @ 2007-11-22 10:54 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Git Mailing List, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <20071110180109.34febc3f@paradox.zwell.net>
Added function "colored()" that prints text with a color that
is passed in. Converted many calls to "print" to being calls to
"print colored()".
The prompt, the header, and the help output are the 3 types of
colorized output, and each has its own color.
Colorization is done through Term::ANSIColor, which is included
with modern versions of perl. This is optional, and should not
need to be present if color.interactive is not turned on.
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
Documentation/config.txt | 6 ++++
git-add--interactive.perl | 66 ++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 65 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8d5d200..3712d6a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -382,6 +382,12 @@ color.diff.<slot>::
whitespace). The values of these variables may be specified as
in color.branch.<slot>.
+color.interactive::
+ When true (or `always`), always use colors in `git add
+ --interactive`. When false (or `never`), never. When set to
+ `auto`, use colors only when the output is to the
+ terminal. Defaults to false.
+
color.pager::
A boolean to enable/disable colored output when the pager is in
use (default is true).
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index ac598f8..2b5559f 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,6 +1,58 @@
#!/usr/bin/perl -w
use strict;
+use Git;
+
+my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
+
+{
+ # set color options:
+ my $repo = Git->repository();
+ my $color_config = $repo->config('color.interactive');
+ $use_color = 0;
+ if (!defined $color_config) {
+ $use_color = 0;
+ }
+ elsif ($color_config =~ /true|always/) {
+ $use_color = 1;
+ }
+ elsif ($color_config eq 'auto' && -t STDOUT &&
+ $ENV{'TERM'} ne 'dumb') {
+ $use_color = 1;
+ }
+
+ if ($use_color) {
+ eval { require Term::ANSIColor; };
+ if ($@) {
+ # library did not load.
+ $use_color = 0;
+ }
+ else { # set up colors
+ # Sane (visible) defaults:
+ $prompt_color = Term::ANSIColor::color('blue bold');
+ $header_color = Term::ANSIColor::color('bold');
+ $help_color = Term::ANSIColor::color('red bold');
+ $normal_color = Term::ANSIColor::color('reset');
+ }
+ }
+}
+
+sub colored {
+ my $color = shift;
+ my $string = join('', @_);
+
+ if ($use_color) {
+ # Put a color code at the beginning of each line, a reset at the end
+ # color after newlines that are not at the end of the string
+ $string =~ s/(\n+)(.)/$1$color$2/g;
+ # reset before newlines
+ $string =~ s/(\n+)/$normal_color$1/g;
+ # codes at beginning and end (if necessary):
+ $string =~ s/^/$color/;
+ $string =~ s/$/$normal_color/ unless $string =~ /\n$/;
+ }
+ return $string;
+}
sub run_cmd_pipe {
if ($^O eq 'MSWin32') {
@@ -175,7 +227,7 @@ sub list_and_choose {
if (!$opts->{LIST_FLAT}) {
print " ";
}
- print "$opts->{HEADER}\n";
+ print colored($header_color, "$opts->{HEADER}\n");
}
for ($i = 0; $i < @stuff; $i++) {
my $chosen = $chosen[$i] ? '*' : ' ';
@@ -205,7 +257,7 @@ sub list_and_choose {
return if ($opts->{LIST_ONLY});
- print $opts->{PROMPT};
+ print colored($prompt_color, $opts->{PROMPT});
if ($opts->{SINGLETON}) {
print "> ";
}
@@ -544,7 +596,7 @@ sub coalesce_overlapping_hunks {
}
sub help_patch_cmd {
- print <<\EOF ;
+ print colored($help_color, <<\EOF );
y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks
@@ -619,7 +671,7 @@ sub patch_update_cmd {
for (@{$hunk[$ix]{TEXT}}) {
print;
}
- print "Stage this hunk [y/n/a/d$other/?]? ";
+ print colored($prompt_color, "Stage this hunk [y/n/a/d$other/?]? ");
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
@@ -673,8 +725,8 @@ sub patch_update_cmd {
elsif ($other =~ /s/ && $line =~ /^s/) {
my @split = split_hunk($hunk[$ix]{TEXT});
if (1 < @split) {
- print "Split into ",
- scalar(@split), " hunks.\n";
+ print colored($header_color, "Split into ",
+ scalar(@split), " hunks.\n");
}
splice(@hunk, $ix, 1,
map { +{ TEXT => $_, USE => undef } }
@@ -766,7 +818,7 @@ sub quit_cmd {
}
sub help_cmd {
- print <<\EOF ;
+ print colored($help_color, <<\EOF );
status - show paths with changes
update - add working tree state to the staged set of changes
revert - revert staged set of changes back to the HEAD version
--
1.5.3.5.565.gf0b83-dirty
^ permalink raw reply related
* [PATCH 2/5] Don't return 'undef' in case called in a vector context.
From: Dan Zwell @ 2007-11-22 10:55 UTC (permalink / raw)
To: Git Mailing List
Cc: Jeff King, Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <20071110180109.34febc3f@paradox.zwell.net>
Previously, the Git->repository()->config('non-existent.key')
evaluated to as true in a vector context. Call 'return' with
no argument, instead.
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
This isn't color related, but the next change I make to Git.pm
depends on this.
perl/Git.pm | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index dca92c8..6603762 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -508,7 +508,7 @@ sub config {
my $E = shift;
if ($E->value() == 1) {
# Key not found.
- return undef;
+ return;
} else {
throw $E;
}
--
1.5.3.5.565.gf0b83-dirty
^ permalink raw reply related
* Re: Adding push configuration to .git/config
From: Johannes Schindelin @ 2007-11-22 11:23 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, Nico -telmich- Schottelius, git
In-Reply-To: <7E8CB606-6CBD-4736-A2CB-0A1E1BD219D3@zib.de>
Hi,
On Thu, 22 Nov 2007, Steffen Prohaska wrote:
> git checkout -b foo origin/master
> work work work
> git checkout -b bar origin/master
> work work work
> git checkout foo
> git pull # or git fetch; git rebase
> git push
> git checkout bar
> git branch -d foo
> work work, ... and later push bar, too
I have to say that I slowly grow an antipathy for "git push" without
parameters. _All_ of the confusions with push that I saw stem from being
too lazy to say where and what you want to push. (Okay, there is this
other thing where people say "git push origin master:master" and I still
do not know where they got _that_ from.)
I would _never_ teach people to be sloppy here. Even if you introduce
whatever appears convenient to you. IMHO this is not only giving rope,
but close to putting the noose around the neck.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
From: Jeff King @ 2007-11-22 11:24 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git
In-Reply-To: <887C3CB1-D21B-4143-8D4E-BF37709FA102@wincent.com>
On Thu, Nov 22, 2007 at 11:44:54AM +0100, Wincent Colaiuta wrote:
> So I don't think the proposal to add "-p" (jump to "patch" subcommand) and
> "-a" (jump to "add untracked" subcommand) are a very good idea, seeing as we
> already have builtin-add for adding entire files.
I agree that "git-add -i untracked_file" is a bit useless. I think it
might be more useful if you could split the one giant hunk (which
git-add--interactive does not currently allow) into smaller hunks, and
then just add parts of them (so conceptually treat it like it had been a
tracked file with empty contents, and go to the patch menu). Of course,
there is currently no way to usefully split a hunk that has consecutive
added lines, so that would have to be figured out, too.
So I think it is not so much "this other thing is useful right now" as
"do we want to paint ourselves in a corner for making it (or other
things) useful later on?" And assuming that having arguments means
"start the patch menu on these files" doesn't leave room for changes
later.
-Peff
^ permalink raw reply
* [PATCH 3/5] Added config_default($key, $default) to Git.pm
From: Dan Zwell @ 2007-11-22 10:55 UTC (permalink / raw)
To: Git Mailing List
Cc: Jeff King, Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <20071110180109.34febc3f@paradox.zwell.net>
Method returns a configuration value if defined, or the default
value that was passed in, otherwise.
The main purpose of this method is to allow the empty string to
be a valid configuration option, and to replace the following
construct:
$val = $repo->config('my.key') || $default_val
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
perl/Git.pm | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 6603762..7327300 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -549,6 +549,34 @@ sub config_bool {
};
}
+=item config_default ( VARIABLE, DEFAULT )
+
+Fetches a configuration option C<VARIABLE>, returning its
+value if it is defined (it is valid to return the empty string,
+if that is its value). Otherwise, C<DEFAULT>, a default
+value, is returned. This method may be a replacement for
+
+ my $value = $repo->config('my.key') || 'default val';
+
+in situations where the empty string is an acceptable return value.
+This method may also be called in a vector context, when expecting
+multivars.
+
+ my @value = $repo->config_default('my.multivar', \@default_vals);
+
+=cut
+
+sub config_default {
+ my ($self, $var, $default) = @_;
+ if (wantarray) {
+ my @value = $self->config($var);
+ return @value ? @value : @$default;
+ }
+ else {
+ my $value = $self->config($var);
+ return (defined $value) ? $value : $default;
+ }
+}
=item ident ( TYPE | IDENTSTR )
--
1.5.3.5.565.gf0b83-dirty
^ permalink raw reply related
* Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
From: Junio C Hamano @ 2007-11-22 11:29 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Jeff King, git
In-Reply-To: <887C3CB1-D21B-4143-8D4E-BF37709FA102@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> If I wanted to add entire files I would have just typed:
>
> git add foo
>
> So I don't think the proposal to add "-p" (jump to "patch" subcommand)
> and "-a" (jump to "add untracked" subcommand) are a very good idea,
> seeing as we already have builtin-add for adding entire files.
It is quite valid for users to run:
git add -i \*.sh
and be able to choose from a list which paths to stage (as a
whole), as well as choose from a list which files to run the
per-hunk staging interface. "git add \*.sh" won't give you any
chance to choose which ones to stage, and that's what we have
"-i" (interactive) mode in "git add" for.
I think you can massage "git add --partial foo" given by the
user internally into "git-add--interactive -i --patch foo". I
strongly suspect that "direct to patch subcommand" mode needs
more than just initially jumping into the subcommand (for
example, you would want to exit when the patch selection
interaction ends, without going back to the main menu), and we
would want a signal stronger than mere presense of pathspecs to
trigger such a specialized behaviour.
By the way, the arguments on the command line to git commands
after "--" are generally pathspecs, iow, patterns to specify
groups of files. Please do not introduce unnecessary
inconsistencies to the UI by requiring them to be exact pathname
only in this particular mode of the command and nowhere else.
There was one funny thing I fixed up. The arguments to the
interactive_add() function in builtin-add.c was like this:
int interactive_add(const char **argv, int argc)
Anybody who writes a function with such a signature and do not
notice its craziness before sending it out either (1) has never
programmed in C, (2) did not review the code before submitting,
or (3) worked too hard and was too tired.
I suspect, judging from the timestamp of your message, it was
(3) this time. The collaborative development is not a race ---
don't work too hastily and too hard; please relax and review
after a good night's sleep before sending things out.
^ permalink raw reply
* Re: Temporary directories getting errantly added into trees
From: Johannes Schindelin @ 2007-11-22 11:30 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <46a038f90711220301o1cbb16b7g79eea541f8ca5e58@mail.gmail.com>
Hi,
On Fri, 23 Nov 2007, Martin Langhoff wrote:
> On Nov 22, 2007 11:55 PM, Johannes Schindelin
>
> > ... And indeed, I see no reason why a tool should access .dotest,
> > except for accessing .dotest/patch, and then it will be very obvious
> > where it fails.
>
> when it comes to .dotest/patch, it must be reasonably accessible. When
> git-am refuses to apply a patch, and I am resolving things by hand, I
> need it pretty handy. I also sometimes edit .dotest/msg-clean.
Maybe install a .dotest/ symlink for a few "git eons", i.e. some 6 months?
Although this will not work on Windows, I see not much problems in it,
since Windows users are not big in scripting (at least the git
type) anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: Temporary directories getting errantly added into trees
From: Johannes Schindelin @ 2007-11-22 11:32 UTC (permalink / raw)
To: Jeff King; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <20071122111600.GF10389@sigill.intra.peff.net>
Hi.
On Thu, 22 Nov 2007, Jeff King wrote:
> On Thu, Nov 22, 2007 at 10:55:00AM +0000, Johannes Schindelin wrote:
>
> > Yes, I know, existing tools could rely on the location. But then, I
> > do not think that tools should be allowed to be _that_ married to
> > particular implementations. And indeed, I see no reason why a tool
> > should access .dotest, except for accessing .dotest/patch, and then it
> > will be very obvious where it fails.
>
> Another reason might be something like:
>
> test -d .dotest && die "rebase or am already in progress"
>
> which some of the git tools do, and which third party scripts might care
> about.
Yep, for example this nice bash-completion addendum which changes the
prompt according to the current repository's state.
I hope that a symlink .dotest -> .git/rebase (as I suggested in a reply to
Martin) would help that, but in the long run I'd appreciate losing even
that.
Ciao,
Dscho
P.S.: note that even a symlink would already help the situation described
by Sam.
^ permalink raw reply
* Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
From: Jeff King @ 2007-11-22 11:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, git
In-Reply-To: <7vlk8q5xj4.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 22, 2007 at 03:29:03AM -0800, Junio C Hamano wrote:
> There was one funny thing I fixed up. The arguments to the
> interactive_add() function in builtin-add.c was like this:
>
> int interactive_add(const char **argv, int argc)
>
> Anybody who writes a function with such a signature and do not
> notice its craziness before sending it out either (1) has never
> programmed in C, (2) did not review the code before submitting,
> or (3) worked too hard and was too tired.
Heh. I looked the patch over, noticed a subtle memcpy issue, and didn't
even notice the craziness. I claim 3, also.
-Peff
^ permalink raw reply
* Re: [PATCH] Add path-limiting to git-add--interactive
From: Wincent Colaiuta @ 2007-11-22 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff
In-Reply-To: <7vd4u27gvn.fsf@gitster.siamese.dyndns.org>
El 22/11/2007, a las 10:45, Junio C Hamano escribió:
> the attached patch teaches [p]atch subcommand to take multiple
> selections. With these, you can do:
>
> $ git add -i 'u*.h'
> What now> p
> staged unstaged path
> 1: unchanged +1/-0 unpack-trees.h
> 2: unchanged +1/-0 utf8.h
> Patch update>> *
> diff --git a/unpack-trees.h b/unpack-trees.h
> ...
> Stage this hunk [y/n/a/d/?]? y
> ...
> diff --git a/utf8.h b/utf8.h
> ...
>
> -- >8 --
Nice usability improvement.
Cheers,
Wincent
^ permalink raw reply
* Re: Temporary directories getting errantly added into trees
From: Junio C Hamano @ 2007-11-22 11:37 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Schindelin, Sam Vilain, Git Mailing List
In-Reply-To: <46a038f90711220301o1cbb16b7g79eea541f8ca5e58@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> when it comes to .dotest/patch, it must be reasonably accessible. When
> git-am refuses to apply a patch, and I am resolving things by hand, I
> need it pretty handy. I also sometimes edit .dotest/msg-clean.
Any serious "am" user shares the habit to edit .dotest/patch and
it would be VERY painful to change this, I suspect.
I do not mind shipping .dotest in the sample templates/info--exclude
file, though.
^ permalink raw reply
* Re: [PATCH 3/4] Teach builtin-add to pass multiple paths to git-add--interactive
From: Jeff King @ 2007-11-22 11:37 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, gitster
In-Reply-To: <43664C66-59F9-4B12-B5FD-86011938EC07@wincent.com>
On Thu, Nov 22, 2007 at 12:02:17PM +0100, Wincent Colaiuta wrote:
> True, argv will never be NULL. We'll still be doing a zero-byte memcpy
> though, which I guess is not a big deal here. I'll drop the conditional.
Right. And zero-byte memcpy _is_ allowed by the standard, so it will
already internally have some form of that conditional.
-Peff
^ permalink raw reply
* [PATCH] Adjust t3404 to ignore empty lines in the todo file
From: Johannes Schindelin @ 2007-11-22 11:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711221113360.27959@racer.site>
---
... and this fixes the tests again. I changed the single "#"
line after the commits to an empty line, since it made things
more readable to this developer. The test expected "#", though.
Please amend.
t/t3404-rebase-interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index f1039d1..907c7f9 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -149,7 +149,8 @@ test_expect_success 'stop on conflicting pick' '
diff -u expect .git/.dotest-merge/patch &&
diff -u expect2 file1 &&
test 4 = $(grep -v "^#" < .git/.dotest-merge/done | wc -l) &&
- test 0 = $(grep -v "^#" < .git/.dotest-merge/git-rebase-todo | wc -l)
+ test 0 = $(grep -ve "^#" -e "^$" < .git/.dotest-merge/git-rebase-todo |
+ wc -l)
'
test_expect_success 'abort' '
--
1.5.3.6.1977.g54d30
^ permalink raw reply related
* gitk's copy pasteboard doesn't persist after it quits
From: Jonathan del Strother @ 2007-11-22 11:44 UTC (permalink / raw)
To: git
On OS X, if I load gitk, copy a sha1, then quit, the sha1 isn't put
into the system-wide pasteboard. It's definitely copied - I can paste
it back into the sha1 field - but it seems to be some sort of local
pasteboard that's specific to gitk
If I switch to another app, the sha1 is stored in the pasteboard
correctly, and I can then quit gitk and still have it available. I'm
guessing that gitk (or Tcl/Tk) is syncing with the system-wide
pasteboard on focus change, but not on quit.
I'm using the version of gitk in 388afe7881b, and Tcl 8.4.7
Any suggestions on fixing / working around this?
Jon
^ 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