* [PATCH 3/3] git-add--interactive: manual hunk editing mode
From: Thomas Rast @ 2008-07-02 22:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <1215035984-26263-1-git-send-email-trast@student.ethz.ch>
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>
---
Documentation/git-add.txt | 1 +
git-add--interactive.perl | 119 ++++++++++++++++++++++++++++++++++++++++++++
t/t3701-add-interactive.sh | 67 +++++++++++++++++++++++++
3 files changed, 187 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 011a743..46dd56c 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -236,6 +236,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 a4234d3..801d7c0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -18,6 +18,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");
@@ -683,6 +695,105 @@ sub split_hunk {
}
+sub color_diff {
+ return map {
+ colored((/^@/ ? $fraginfo_color :
+ /^\+/ ? $diff_new_color :
+ /^-/ ? $diff_old_color :
+ $diff_plain_color),
+ $_);
+ } @_;
+}
+
+sub edit_hunk_manually {
+ my ($oldtext) = @_;
+
+ my $hunkfile = $repo->repo_path . "/addp-hunk-edit.diff";
+ my $fh;
+ open $fh, '>', $hunkfile
+ or die "failed to open hunk edit file for writing: " . $!;
+ print $fh "# Manual hunk edit mode -- see bottom for a quick guide\n";
+ print $fh @$oldtext;
+ print $fh <<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 $fh;
+
+ my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
+ || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+ system('sh', '-c', $editor.' "$@"', $editor, $hunkfile);
+
+ open $fh, '<', $hunkfile
+ or die "failed to open hunk edit file for reading: " . $!;
+ my @newtext = grep { !/^#/ } <$fh>;
+ close $fh;
+ unlink $hunkfile;
+
+ # 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
@@ -694,6 +805,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
}
@@ -798,6 +910,7 @@ sub patch_update_file {
if (hunk_splittable($hunk[$ix]{TEXT})) {
$other .= '/s';
}
+ $other .= '/e';
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
@@ -862,6 +975,12 @@ 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;
+ }
+ }
else {
help_patch_cmd($other);
next;
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.6.1.276.gde9a
^ permalink raw reply related
* [PATCH 2/3] git-add--interactive: remove hunk coalescing
From: Thomas Rast @ 2008-07-02 21:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <1215035956-26192-1-git-send-email-trast@student.ethz.ch>
Current git-apply has no trouble at all applying chunks that have
overlapping context, as produced by the splitting feature. So we can
drop the manual coalescing.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-add--interactive.perl | 89 ---------------------------------------------
1 files changed, 0 insertions(+), 89 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index e1964a5..a4234d3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -682,93 +682,6 @@ sub split_hunk {
return @split;
}
-sub find_last_o_ctx {
- my ($it) = @_;
- my $text = $it->{TEXT};
- my ($o_ofs, $o_cnt) = parse_hunk_header($text->[0]);
- my $i = @{$text};
- my $last_o_ctx = $o_ofs + $o_cnt;
- while (0 < --$i) {
- my $line = $text->[$i];
- if ($line =~ /^ /) {
- $last_o_ctx--;
- next;
- }
- last;
- }
- return $last_o_ctx;
-}
-
-sub merge_hunk {
- my ($prev, $this) = @_;
- my ($o0_ofs, $o0_cnt, $n0_ofs, $n0_cnt) =
- parse_hunk_header($prev->{TEXT}[0]);
- my ($o1_ofs, $o1_cnt, $n1_ofs, $n1_cnt) =
- parse_hunk_header($this->{TEXT}[0]);
-
- my (@line, $i, $ofs, $o_cnt, $n_cnt);
- $ofs = $o0_ofs;
- $o_cnt = $n_cnt = 0;
- for ($i = 1; $i < @{$prev->{TEXT}}; $i++) {
- my $line = $prev->{TEXT}[$i];
- if ($line =~ /^\+/) {
- $n_cnt++;
- push @line, $line;
- next;
- }
-
- last if ($o1_ofs <= $ofs);
-
- $o_cnt++;
- $ofs++;
- if ($line =~ /^ /) {
- $n_cnt++;
- }
- push @line, $line;
- }
-
- for ($i = 1; $i < @{$this->{TEXT}}; $i++) {
- my $line = $this->{TEXT}[$i];
- if ($line =~ /^\+/) {
- $n_cnt++;
- push @line, $line;
- next;
- }
- $ofs++;
- $o_cnt++;
- if ($line =~ /^ /) {
- $n_cnt++;
- }
- push @line, $line;
- }
- my $head = ("@@ -$o0_ofs" .
- (($o_cnt != 1) ? ",$o_cnt" : '') .
- " +$n0_ofs" .
- (($n_cnt != 1) ? ",$n_cnt" : '') .
- " @@\n");
- @{$prev->{TEXT}} = ($head, @line);
-}
-
-sub coalesce_overlapping_hunks {
- my (@in) = @_;
- my @out = ();
-
- my ($last_o_ctx);
-
- for (grep { $_->{USE} } @in) {
- my $text = $_->{TEXT};
- my ($o_ofs) = parse_hunk_header($text->[0]);
- if (defined $last_o_ctx &&
- $o_ofs <= $last_o_ctx) {
- merge_hunk($out[-1], $_);
- }
- else {
- push @out, $_;
- }
- $last_o_ctx = find_last_o_ctx($out[-1]);
- }
- return @out;
-}
sub help_patch_cmd {
print colored $help_color, <<\EOF ;
@@ -962,8 +875,6 @@ sub patch_update_file {
}
}
- @hunk = coalesce_overlapping_hunks(@hunk);
-
my $n_lofs = 0;
my @result = ();
if ($mode->{USE}) {
--
1.5.6.1.276.gde9a
^ permalink raw reply related
* [PATCH 1/3] git-add--interactive: replace hunk recounting with apply --recount
From: Thomas Rast @ 2008-07-02 21:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <1215035909-26110-1-git-send-email-trast@student.ethz.ch>
We recounted the postimage offsets to compensate for hunks that were
not selected. Now apply --recount can do the job for us.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-add--interactive.perl | 30 +++---------------------------
1 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..e1964a5 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -970,39 +970,15 @@ sub patch_update_file {
push @result, @{$mode->{TEXT}};
}
for (@hunk) {
- my $text = $_->{TEXT};
- my ($o_ofs, $o_cnt, $n_ofs, $n_cnt) =
- parse_hunk_header($text->[0]);
-
- if (!$_->{USE}) {
- # We would have added ($n_cnt - $o_cnt) lines
- # to the postimage if we were to use this hunk,
- # but we didn't. So the line number that the next
- # hunk starts at would be shifted by that much.
- $n_lofs -= ($n_cnt - $o_cnt);
- next;
- }
- else {
- if ($n_lofs) {
- $n_ofs += $n_lofs;
- $text->[0] = ("@@ -$o_ofs" .
- (($o_cnt != 1)
- ? ",$o_cnt" : '') .
- " +$n_ofs" .
- (($n_cnt != 1)
- ? ",$n_cnt" : '') .
- " @@\n");
- }
- for (@$text) {
- push @result, $_;
- }
+ if ($_->{USE}) {
+ push @result, @{$_->{TEXT}};
}
}
if (@result) {
my $fh;
- open $fh, '| git apply --cached';
+ open $fh, '| git apply --cached --recount';
for (@{$head->{TEXT}}, @result) {
print $fh $_;
}
--
1.5.6.1.276.gde9a
^ permalink raw reply related
* [PATCH 0/3] git-add--interactive: use --recount, editing
From: Thomas Rast @ 2008-07-02 21:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <7v7ic4hmj5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> I recall that the original "add--interactive" carefully counted numbers in
> hunks it reassembles (as it can let you split and then you can choose to
> use both parts, which requires it to merge overlapping hunks back), but if
> you are going to use --recount anyway, perhaps we can discard that logic?
> It may make the patch application less robust, though. I dunno.
This series takes it a bit further. I played around with 'apply', and
it seems there is no reason to even merge the hunks. (It would be
great if someone who knows builtin-apply.c could confirm this.) So we
can get rid of all recounting except for the correct splitting
boundaries. These are the first two patches.
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I wonder why bother trying to import things when you do not need them to
> > begin with! I mean, it is _obvious_ that in this case, we want .git/ to
> > be writable _anyway_, so why not stick with a fixed name in that?
>
> Good suggestion -- I love that simplicity. Thomas?
Well, changed that back.
Apart from that, no real changes to 3/3, but the $needs_recount code
has become unnecessary because 1/3 already forces --recount.
- Thomas
Documentation/git-add.txt | 1 +
git-add--interactive.perl | 203 ++++++++++++++++++++++---------------------
t/t3701-add-interactive.sh | 67 +++++++++++++++
3 files changed, 172 insertions(+), 99 deletions(-)
^ permalink raw reply
* Re: RFC: grafts generalised
From: Junio C Hamano @ 2008-07-02 21:49 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Stephen R. van den Berg, Linus Torvalds, git
In-Reply-To: <7vlk0k7z99.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Dmitry Potapov" <dpotapov@gmail.com> writes:
>
>> On Wed, Jul 2, 2008 at 10:10 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
>>>
>>> In that case, I will stick to extending git fsck to check grafts more
>>> rigorously and fix git clone to *refrain* from looking at grafts.
>>
>> Linus suggested that "git-fsck and repacking should just consider
>> it[grafts] to be an _additional_ source of parenthood rather than
>> a _replacement_ source."
>>
>> http://article.gmane.org/gmane.comp.version-control.git/84686
>
> Yeah, thanks for a reminder.
>
> http://thread.gmane.org/gmane.comp.version-control.git/37744/focus=37866
>
> is still on my "things to look at" list.
This shows how the "object transfer ignores grafts" side of the earlier
suggestion by Linus would look like to get people started. Totally
untested.
I threw in for_each_commit_graft() in the patch so that updates to the
reachability walker can add otherwise hidden objects, but otherwise it is
not used yet.
builtin-pack-objects.c | 5 +++++
builtin-send-pack.c | 3 ++-
cache.h | 1 +
commit.c | 10 ++++++++++
commit.h | 2 ++
environment.c | 1 +
upload-pack.c | 1 +
7 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 28207d9..53b0b33 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -30,6 +30,7 @@ git-pack-objects [{ -q | --progress | --all-progress }] \n\
[--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n\
[--stdout | base-name] [--include-tag] \n\
[--keep-unreachable | --unpack-unreachable] \n\
+ [--ignore-graft] \n\
[<ref-list | <object-list]";
struct object_entry {
@@ -2160,6 +2161,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
die("bad %s", arg);
continue;
}
+ if (!strcmp(arg, "--ignore-graft")) {
+ honor_graft = 0;
+ continue;
+ }
usage(pack_usage);
}
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index d76260c..d932352 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -27,6 +27,7 @@ static int pack_objects(int fd, struct ref *refs)
*/
const char *argv[] = {
"pack-objects",
+ "--ignore-graft",
"--all-progress",
"--revs",
"--stdout",
@@ -36,7 +37,7 @@ static int pack_objects(int fd, struct ref *refs)
struct child_process po;
if (args.use_thin_pack)
- argv[4] = "--thin";
+ argv[5] = "--thin";
memset(&po, 0, sizeof(po));
po.argv = argv;
po.in = -1;
diff --git a/cache.h b/cache.h
index 188428d..00858f9 100644
--- a/cache.h
+++ b/cache.h
@@ -435,6 +435,7 @@ extern size_t packed_git_limit;
extern size_t delta_base_cache_limit;
extern int auto_crlf;
extern int fsync_object_files;
+extern int honor_graft;
enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/commit.c b/commit.c
index e2d8624..62cf104 100644
--- a/commit.c
+++ b/commit.c
@@ -101,6 +101,13 @@ static int commit_graft_pos(const unsigned char *sha1)
return -lo - 1;
}
+void for_each_commit_graft(void (*fn)(struct commit_graft *))
+{
+ int i;
+ for (i = 0; i < commit_graft_nr; i++)
+ fn(commit_graft[i]);
+}
+
int register_commit_graft(struct commit_graft *graft, int ignore_dups)
{
int pos = commit_graft_pos(graft->sha1);
@@ -196,7 +203,10 @@ static void prepare_commit_graft(void)
struct commit_graft *lookup_commit_graft(const unsigned char *sha1)
{
int pos;
+
prepare_commit_graft();
+ if (!honor_graft)
+ return NULL;
pos = commit_graft_pos(sha1);
if (pos < 0)
return NULL;
diff --git a/commit.h b/commit.h
index 2d94d41..8f76dd9 100644
--- a/commit.h
+++ b/commit.h
@@ -138,4 +138,6 @@ static inline int single_parent(struct commit *commit)
return commit->parents && !commit->parents->next;
}
+void for_each_commit_graft(void (*fn)(struct commit_graft *));
+
#endif /* COMMIT_H */
diff --git a/environment.c b/environment.c
index 4a88a17..eb8f36d 100644
--- a/environment.c
+++ b/environment.c
@@ -41,6 +41,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+int honor_graft = 1;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
diff --git a/upload-pack.c b/upload-pack.c
index b46dd36..d948d64 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -158,6 +158,7 @@ static void create_pack_file(void)
die("git-upload-pack: unable to fork git-rev-list");
argv[arg++] = "pack-objects";
+ argv[arg++] = "--ignore-graft";
argv[arg++] = "--stdout";
if (!no_progress)
argv[arg++] = "--progress";
^ permalink raw reply related
* Re: [PATCH 3/7] Documentation: complicate example of "man git-command"
From: J. Bruce Fields @ 2008-07-02 21:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, git, Christian Couder, Nguyen Thai Ngoc Duy,
Jon Loeliger
In-Reply-To: <7vmyl1kvn6.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 01, 2008 at 04:54:53PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Mon, Jun 30, 2008 at 05:10:25PM -0500, Jonathan Nieder wrote:
> >> The manual page for the command invoked as "git clone" is named
> >> git-clone(1), and similarly for the rest of the git commands.
> >> Make sure our first example of this in tutorials makes it clear
> >> that it is the first two words of a command line that make up the
> >> command's name (that is: for example, the effect of "git svn
> >> dcommit" is described in git-svn(1)).
> >
> > Is this confusion really common?
> >
> > I can see how it might be possible in the case of a subcommand that
> > itself has subcommands, but it seems less likely in the two examples you
> > add below (where the third token is an option or a url). I like your
> > "git svn" example better. Or "git remote" might be good.
> >
> > --b.
>
> While I agree with the above, are we ready to talk about "git-svn"
> or "git-remote" that early in the tutorial material?
No, but for the purposes of this example it's not necessary to be
familiar with the command. (Though it might be less distracting to use
something that'll be discussed early on.)
> We would want to mention the typesetting convention early in the manuals
> (git(7), gittutorial(7) and user-manual.html) as well, so how about...
>
> Conventions used in this document
> ---------------------------------
>
> When talking about a git subcommand 'cmd', this documentation
> typesets the name of it like 'git-cmd', and that is the name you
> ask for its manual page.
>
> Examples are typeset like this: `$ git cmd` (`$` is your command
> prompt, do not actually type it to your shell). Note that a
> subcommand is specified as the first parameter to the 'git'
> program when you actually run it from the command line.
I'm not convinced this last sentence is necessary.
>
> E.g. a typical command description may go like this:
>
> To propagate the changes you made back to the original subversion
> repository, you would use 'git-svn dcommit' command. It does
> these things (long description here). Some examples:
>
> ------------
> $ ... some example command sequence ...
> $ git svn dcommit
> ------------
Typographical conventions shouldn't need so much explanation.
I'm curious: Jonathan, was this the original patch the result of a
real-life instance of confusion? What happened?
--b.
>
> For full details, type:
>
> ------------
> $ man git-svn
> ------------
^ permalink raw reply
* Re: RFC: grafts generalised
From: Avery Pennarun @ 2008-07-02 21:28 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Dmitry Potapov, git
In-Reply-To: <20080702211836.GF16235@cuci.nl>
On 7/2/08, Stephen R. van den Berg <srb@cuci.nl> wrote:
> Dmitry Potapov wrote:
> >On Wed, Jul 2, 2008 at 10:10 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
> >> In that case, I will stick to extending git fsck to check grafts more
> >> rigorously and fix git clone to *refrain* from looking at grafts.
>
> >Linus suggested that "git-fsck and repacking should just consider
> >it[grafts] to be an _additional_ source of parenthood rather than
> >a _replacement_ source."
>
> >http://article.gmane.org/gmane.comp.version-control.git/84686
>
> Yes, I know that's what he suggested, the way it should be implemented
> IMO though is by checking once without and once with regard to grafts.
> And still it should be such that git clone disregards grafts completely.
I could see an argument that the only modes you really need are a) use
grafts as replacements, and b) use grafts as additions. There is
perhaps no need for c) ignore grafts.
For example, say I wanted to give someone a copy of my repo that
includes grafts (ignoring the fact that this is probably bad to do in
general). He could git-clone it and then install a copy of my grafts
file, as long as git-clone does (a) or (b) but not (c). On the other
hand, if he just wants a copy of the "real" (graft-free) repo, then
git-clone needs to do (b) or (c) but not (a). git-fsck needs (b), and
most normal git operations want (a) (since that was the original
purpose of grafts).
Based on that, (c) is redundant, unless you're really concerned about
not sending redundant objects to people who clone your repo that has
grafts installed. But I think you probably shouldn't have people
cloning your grafted repository anyway unless you know what you're
doing, and if you know what you're doing, you probably want (b). If
you see what I mean.
Have fun,
Avery
^ permalink raw reply
* Re: RFC: grafts generalised
From: Junio C Hamano @ 2008-07-02 21:27 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Stephen R. van den Berg, git
In-Reply-To: <37fcd2780807021339u582f340dq2b2014951d5b7f63@mail.gmail.com>
"Dmitry Potapov" <dpotapov@gmail.com> writes:
> On Wed, Jul 2, 2008 at 10:10 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
>>
>> In that case, I will stick to extending git fsck to check grafts more
>> rigorously and fix git clone to *refrain* from looking at grafts.
>
> Linus suggested that "git-fsck and repacking should just consider
> it[grafts] to be an _additional_ source of parenthood rather than
> a _replacement_ source."
>
> http://article.gmane.org/gmane.comp.version-control.git/84686
Yeah, thanks for a reminder.
http://thread.gmane.org/gmane.comp.version-control.git/37744/focus=37866
is still on my "things to look at" list.
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-02 21:18 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <37fcd2780807021339u582f340dq2b2014951d5b7f63@mail.gmail.com>
Dmitry Potapov wrote:
>On Wed, Jul 2, 2008 at 10:10 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
>> In that case, I will stick to extending git fsck to check grafts more
>> rigorously and fix git clone to *refrain* from looking at grafts.
>Linus suggested that "git-fsck and repacking should just consider
>it[grafts] to be an _additional_ source of parenthood rather than
>a _replacement_ source."
>http://article.gmane.org/gmane.comp.version-control.git/84686
Yes, I know that's what he suggested, the way it should be implemented
IMO though is by checking once without and once with regard to grafts.
And still it should be such that git clone disregards grafts completely.
I'll fix both, eventually, since I need this functionality to verify
correctness for the projects I'm working on at the moment.
As for repack, it should probably ignore grafts, except for reference.
I.e. repack/gc should consider all mentioned SHA1s in the grafts file
to be referenced and undeletable.
--
Sincerely,
Stephen R. van den Berg.
You are confused; but this is your normal state.
^ permalink raw reply
* Re: [PATCH] Disconnect stash from its base commit
From: Junio C Hamano @ 2008-07-02 21:04 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: Nanako Shiraishi, git
In-Reply-To: <20080702195401.GA17214@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> writes:
> At 2008-07-02 12:01:35 -0700, gitster@pobox.com wrote:
>>
>> But that imaginary "stash branch" command would always give you
>> the exact state you were in and creates a clean fork to finish
>> what you were doing, and continue.
>
> Nice idea. Something as simple as the appended diff?
>
> I reversed the stash/branch arguments so that one need specify only the
> branch name. Playing with it a little, it feels very useful.
I'd further suggest to delete the stash automatically when you create a
new branch out of it.
^ permalink raw reply
* Re: RFC: grafts generalised
From: Dmitry Potapov @ 2008-07-02 20:42 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Stephen R. van den Berg, git, Mike Hommey, Michael J Gruber
In-Reply-To: <20080702193157.GA21297@leksak.fem-net>
On Wed, Jul 2, 2008 at 11:31 PM, Stephan Beyer <s-beyer@gmx.net> wrote:
>
> I'm somehow quite confused about the desired workflow but I try an
> answer.
I don't think we speak about any normal workflow but about importing
"initially disjunct CVS and SVN repositories into larger complete
histories inside a single git repository." This is one-time work, not
a regular workflow.
>
> Stephen R. van den Berg wrote:
>> As far as I understood it, the new git sequencer rewrites history
>> proper. That is timeconsuming by definition, and thus it is *not*
>> possible to make a tool based on the sequencer that supports the desired
>> iterative-history-rewrite workflow.
>
> If I got the problem right, it is possible.
> But you have to rewrite and cannot just fake history, of course.
Using grafts allows you to fake history, which is very useful during
import, because it allows you to edit history without running any
filter-branch, which is very timeconsuming. Of course, at the end
you have to run git filter-branch to have the "true" history, otherwise
anyone who clones from you will end up with a broken repo.
The purpose of rebase (and I believe the sequencer too) is rather
different -- to allow you to keep your changes as patches to the
upstream.
> I wonder if grafts can be used in combination with sequencer in such a
> way that you rewrite foo~20000..foo~19950 and then fake the parents of
> foo~19949 to be the rewritten once.
I don't think it is a good idea. During the normal work you should never
use grafts. Well, you can use grafts to add old history, but using it for
anything else is really dangerous, because its *fakes* history. git rebase
(and AFAIK sequencer too) just re-write history of some branch. IOW, it
creates another branch from a different starting point using patches from
some existing branch and then reassign the branch name to it.
Dmitry
^ permalink raw reply
* Re: RFC: grafts generalised
From: Dmitry Potapov @ 2008-07-02 20:39 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080702181021.GD16235@cuci.nl>
On Wed, Jul 2, 2008 at 10:10 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
>
> In that case, I will stick to extending git fsck to check grafts more
> rigorously and fix git clone to *refrain* from looking at grafts.
Linus suggested that "git-fsck and repacking should just consider
it[grafts] to be an _additional_ source of parenthood rather than
a _replacement_ source."
http://article.gmane.org/gmane.comp.version-control.git/84686
Dmitry
^ permalink raw reply
* Re: git describe --tags --long barfs on new tags?
From: Mikael Magnusson @ 2008-07-02 19:56 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20080702154506.7b83bae8@crow>
2008/7/2 Mark Burton <markb@ordern.com>:
>
> Howdy folks,
>
> Discovered this today:
>
> ~/git[master]$ git tag mb
> ~/git[master]$ git describe
> v1.5.6.1-156-ge903b40
> ~/git[master]$ git describe --tags
> mb
> ~/git[master]$ git describe --tags --long
> Segmentation fault (core dumped)
>
> Hope this is useful info.
>
> BTW - just started using git and I am very impressed with it - took me a while to get my head around the "index" but now I wonder what the problem was.
Here's a backtrace, i tried to follow the code but got confused and gave up.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa7cd26c0 (LWP 9670)]
0x080615f2 in describe (arg=0x80e4e9e "HEAD", last_one=1) at
builtin-describe.c:207
207 show_suffix(0, n->tag->tagged->sha1);
(gdb) bt
#0 0x080615f2 in describe (arg=0x80e4e9e "HEAD", last_one=1) at
builtin-describe.c:207
#1 0x08061bd8 in cmd_describe (argc=0, argv=0xafcd25f4, prefix=0x0)
at builtin-describe.c:360
#2 0x0804b1bf in handle_internal_command (argc=3, argv=0xafcd25f4) at git.c:252
#3 0x0804b888 in main (argc=3, argv=0x41c294c0) at git.c:463
(gdb) print n
$1 = <value optimized out>
(gdb) print cmit
$3 = (struct commit *) 0x81476a8
(gdb) print cmit->util
$4 = (void *) 0x8147430
(gdb) print *(struct commit_name*)cmit->util
$5 = {tag = 0x0, prio = 1, sha1 =
"\tEt\"±d6ª\033\005\230\237\035ëR\226¼á\017\230",
path = 0x814744c "mb"}
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH] Disconnect stash from its base commit
From: Abhijit Menon-Sen @ 2008-07-02 19:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vvdzo9kkw.fsf@gitster.siamese.dyndns.org>
At 2008-07-02 12:01:35 -0700, gitster@pobox.com wrote:
>
> But that imaginary "stash branch" command would always give you
> the exact state you were in and creates a clean fork to finish
> what you were doing, and continue.
Nice idea. Something as simple as the appended diff?
I reversed the stash/branch arguments so that one need specify only the
branch name. Playing with it a little, it feels very useful.
-- ams
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..d5ecd24 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,21 @@ drop_stash () {
git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
}
+apply_to_branch () {
+ have_stash || die 'Nothing to apply'
+
+ test -n "$1" || die 'No branch name specified'
+ branch=$1
+
+ if test -z "$2"
+ then
+ set x "$ref_stash@{0}"
+ fi
+ stash=$2
+
+ git-checkout -b $branch $stash^ && apply_stash $stash
+}
+
# Main command set
case "$1" in
list)
@@ -264,6 +279,10 @@ pop)
drop_stash "$@"
fi
;;
+branch)
+ shift
+ apply_to_branch "$@"
+ ;;
*)
if test $# -eq 0
then
^ permalink raw reply related
* Re: RFC: grafts generalised
From: Stephan Beyer @ 2008-07-02 19:36 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git, Mike Hommey, Michael J Gruber
In-Reply-To: <20080702193157.GA21297@leksak.fem-net>
A short typo fix:
> I wonder if grafts can be used in combination with sequencer in such a
> way that you rewrite foo~20000..foo~19950 and then fake the parents of
> foo~19949 to be the rewritten once.
s/once/ones/
To give it some sense. Sorry ;)
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console
From: Peter Harris @ 2008-07-02 19:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: prohaska, msysGit, git, Junio C Hamano
In-Reply-To: <200807022117.38166.johannes.sixt@telecom.at>
On Wed, Jul 2, 2008 at 3:17 PM, Johannes Sixt wrote:
> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>> This adds only the minimum necessary to keep git pull/merge's diffstat from
>> wrapping. Notably absent is support for the K (erase) operation, and
>> support for POSIX write.
>
> If I understand the patch correctly, it won't affect output that goes to the
> pager; only text that goes directly to the console would be colored.
Yes, that is correct.
Note that an MSYS bash/rxvt is effectively considered a pager by this
patch, since it fails the isatty() test. This is actually a good
thing: MSYS has better ANSI support anyway.
Peter Harris
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next
From: Johannes Sixt @ 2008-07-02 19:32 UTC (permalink / raw)
To: prohaska
Cc: msysGit, Johannes Schindelin, Git Mailing List, Junio C Hamano,
Dmitry Kakurin
In-Reply-To: <D35A2542-3943-4BDB-AEDA-0F8B7052EF7D@zib.de>
On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:
> > On Wed, 2 Jul 2008, Steffen Prohaska wrote:
> >> From: Johannes Sixt <johannes.sixt@telecom.at>
> >>
> >> Hannes,
> >> You introduced "minoffset" in 861429a7c37c7.
> >
> > AFAICT it was redone differently in 'next', because 'next' has this
> > ceiling dir thingie, which allows a different (much smaller) patch.
> >
> > It might be more sensible to base your patch series on 'next'...
>
> Hmm.. it is based on next. But obviously I needed to merge
> mingw's master to 4msysgit's master and resolve conflicts.
> Maybe I made the wrong decisions then.
>
> Hannes,
> If you believe that your setup.c is good, then I'll copy your version
> to 4msysgit's master.
The setup.c in mingw.git (and soon Junio's master) and Junio's next are
_different_, but both are correct. If you reverse-apply the patch you
presented here, then you get the version from Junio's next, which is a good
state.
[ Of course, the result will work only as long as you do not set
GIT_CEILING_DIRECTORIES, because we haven't taken care of the helper
functions that this feature uses, longest_ancestor_length() and
normalize_path(). ]
We have debated about set_git_dir(".") in the past. mingw.git doesn't have it,
and it works (for me). I don't know what it is needed for.
-- Hannes
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephan Beyer @ 2008-07-02 19:31 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git, Mike Hommey, Michael J Gruber
In-Reply-To: <20080702183701.GE16235@cuci.nl>
Hi,
I'm somehow quite confused about the desired workflow but I try an
answer.
Stephen R. van den Berg wrote:
> As far as I understood it, the new git sequencer rewrites history
> proper. That is timeconsuming by definition, and thus it is *not*
> possible to make a tool based on the sequencer that supports the desired
> iterative-history-rewrite workflow.
If I got the problem right, it is possible.
But you have to rewrite and cannot just fake history, of course.
And, as Michael wrote:
> The currently planned set of commands would need to be amended, but the
> framework should be in place.
...for example, a "pick <commit>" that just picks the _tree_ of the
commit and not the _introduced changes_. (I've never used info/grafts,
but if I get the principle right, such tree-picks could realize a
linear list of info/grafts history fakes.)
Stephen wrote earlier:
> The problem I encounter is that any number of times I have to "edit"
> history in a non-parameterable fashion, in any of the following ways:
Hm, imho sequencer is well-suited for "non-parameterable" stuff.
> - Change parents.
The "pick" instruction (onto the new parent) is your friend.
> - Add merges.
"merge" instruction ;)
> - Change author, committer, commitdate, authordate.
sequencer doesn't allow to change committer data, but this could
be an easy change if you really need that.
The same with the author timestamp, that could only be reused from
an old commit by using -C option on pick.
> - Change the tree (because of conversion errors in the automated
> conversion process) belonging to a single commit.
> - Retrofit a patch which has to ripple through all of history until
> the present.
"pause" instruction, and then do manual changes, then
git sequencer --continue
Stephan has also written:
> Also, having to run the sequencer to dig 20000 commits into the past,
> then change something, then come back up and rewrite all following
> history and relations (parents/tags/merges) will take a sizeable amount
> of time.
I wonder if grafts can be used in combination with sequencer in such a
way that you rewrite foo~20000..foo~19950 and then fake the parents of
foo~19949 to be the rewritten once.
> I need something that can be changed at will, then viewed with
> gitk a second later.
You can run gitk whenever you did "pause" in the sequencer file.
[Btw, an integration of sequencer into gitk is also on the TODO list,
but that's OT here.]
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console
From: Johannes Sixt @ 2008-07-02 19:17 UTC (permalink / raw)
To: prohaska; +Cc: msysGit, git, Junio C Hamano, Peter
In-Reply-To: <1214987532-23640-10-git-send-email-prohaska@zib.de>
On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> This adds only the minimum necessary to keep git pull/merge's diffstat from
> wrapping. Notably absent is support for the K (erase) operation, and
> support for POSIX write.
If I understand the patch correctly, it won't affect output that goes to the
pager; only text that goes directly to the console would be colored. This is
a start. I think I'll queue this in mingw.git.
-- Hannes
^ permalink raw reply
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
From: Johannes Sixt @ 2008-07-02 19:04 UTC (permalink / raw)
To: prohaska; +Cc: msysGit, git, Junio C Hamano, Edward Z. Yang
In-Reply-To: <1214987532-23640-6-git-send-email-prohaska@zib.de>
On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Edward Z. Yang <edwardzyang@thewritingpot.com>
>
> PuTTY requires -P while OpenSSH requires -p; if plink is detected
> as GIT_SSH, use the alternate flag.
>
> Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
> connect.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index 574f42f..0d007f3 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const
> char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg));
> if (protocol == PROTO_SSH) {
> const char *ssh = getenv("GIT_SSH");
> + int putty = ssh && strstr(ssh, "plink");
> if (!ssh) ssh = "ssh";
>
> *arg++ = ssh;
> if (port) {
> - *arg++ = "-p";
> + /* P is for PuTTY, p is for OpenSSH */
> + *arg++ = putty ? "-P" : "-p";
> *arg++ = port;
> }
> *arg++ = host;
What about installing a wrapper script, plinkssh, that does this:
#!/bin/bash
if test "$1" = -p; then
port="-P $2"
shift; shift
fi
exec plink $port "$@"
and require plink users to set GIT_SSH=plinkssh?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Disconnect stash from its base commit
From: Junio C Hamano @ 2008-07-02 19:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, Git Mailing List, Olivier Marin
In-Reply-To: <alpine.DEB.1.00.0807021447200.9925@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> This patch changes the structure of a stash to use a parentless new
>> commit that has the same tree as the HEAD commit, in place of the HEAD
>> commit. This way, a stash does not keep the history that leads to the
>> HEAD commit reachable, even if the stash is kept forever.
>
> May I register my suspicion that this is the wrong direction to go?
>
> I actually find it quite nice that I can easily see in gitk where I
> spawned off a certain stash, indeed, how the recent stash history
> (manually specified with "stash@{0} stash@{1} stash@{2}" [*1*]), relates
> to the current branch's history.
A stash may primarily be for applying the change to random place, but
where it was created is not a useless information. The very original use
case that was in the discussion "git stash" (actually its original form
"git save") was first posted was "I am in the middle of something, and get
interrupted. Stash the changes away to switch branches to deal with the
emergency for a while so that I can later come back to where I was, and I
want both saving away and coming back easy operations". A stash _can_ be
applied to any random other state, but "coming back" is very much part of
what it should have supported, and not recording the base commit means we
would lose that capability.
Side note. In addition to the current "stash apply" and "stash
pop", "stash branch $stash newbranchname" that does
git checkout -b newbranchanme $stash^
(i.e. create a new branch starting from the state you were in)
might be a good ingredient to support a more git-like workflow to
resume. If your original branch gained extra commits, was
rewound, or was rebased during the emergency/distraction, you may
not have anywhere to apply/pop the stash without conflicts when
you want to "come back" with normal
git checkout somebranch && git stash pop
But that imaginary "stash branch" command would always give you
the exact state you were in and creates a clean fork to finish
what you were doing, and continue.
So the base commit is an integral part of what a stash is, and I agree
with you that an unexpiring stash that pins the whole history beind it is
a feature. It is not unncessary cruft that accumulates that we need to
worry about.
^ permalink raw reply
* Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser
From: Johannes Sixt @ 2008-07-02 18:57 UTC (permalink / raw)
To: prohaska; +Cc: msysGit, git, Junio C Hamano
In-Reply-To: <1214987532-23640-5-git-send-email-prohaska@zib.de>
On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> The implementation directly calls the Win32 API to launch the browser.
> Note that the specific directory layout of msysgit is required.
> +#ifdef __MINGW32__
> + const char* exec_path = git_exec_path();
> + char *htmlpath = make_native_separator(
> + mkpath("%s/../doc/git/html/%s.html"
> + , exec_path
> + , git_cmd)
> + );
> + if (!file_exists(htmlpath)) {
> + htmlpath = make_native_separator(
> + mkpath("%s/../doc/git/html/git-%s.html"
> + , exec_path
> + , git_cmd)
> + );
> + if (!file_exists(htmlpath)) {
> + fprintf(stderr, "Can't find HTML help for '%s'.\n"
> + , git_cmd);
> + exit(1);
> + }
> + }
> + printf("Launching default browser to display HTML help ...\n");
> + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
> +#else
Can't we move this part into git-web--browse.sh? It should be a matter of
calling
start $htmlpath
(and msys-1.0.dll would convert slashes to backslashes for us).
-- Hannes
^ permalink raw reply
* Re: [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures
From: Johannes Sixt @ 2008-07-02 18:46 UTC (permalink / raw)
To: prohaska; +Cc: msysGit, git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1214987532-23640-3-git-send-email-prohaska@zib.de>
On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> On Windows, gpg outputs CR/LF signatures. But since the tag
> messages are already stripped of the CR by stripspace(), it is
> arguably nicer to do the same for the tag signature. Actually,
> this patch does not look for CR/LF, but strips all CRs
> from the signature.
>
> [ spr: ported code to use strbuf ]
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
> builtin-tag.c | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-tag.c b/builtin-tag.c
> index e675206..77977ba 100644
> --- a/builtin-tag.c
> +++ b/builtin-tag.c
> @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
> if (finish_command(&gpg) || !len || len < 0)
> return error("gpg failed to sign the tag");
>
> +#ifdef __MINGW32__
> + /* strip CR from the line endings */
> + {
> + int i, j;
> + for (i = j = 0; i < buffer->len; i++)
> + if (buffer->buf[i] != '\r') {
> + if (i != j)
> + buffer->buf[j] = buffer->buf[i];
> + j++;
> + }
> + strbuf_setlen(buffer, j);
> + }
> +#endif
> +
> return 0;
> }
Do we need the #ifdef __MINGW32__? Can't we just strip CRs unconditionally? It
shouldn't hurt on Unix anyway.
-- Hannes
^ permalink raw reply
* Re: [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL.
From: Johannes Sixt @ 2008-07-02 18:43 UTC (permalink / raw)
To: prohaska; +Cc: msysGit, git, Junio C Hamano
In-Reply-To: <1214987532-23640-1-git-send-email-prohaska@zib.de>
On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Johannes Sixt <johannes.sixt@telecom.at>
>
> git-am when invoked from git-rebase seems to rely on successful conversion.
> diff --git a/utf8.h b/utf8.h
> index 98cce1b..f22ef31 100644
> --- a/utf8.h
> +++ b/utf8.h
> @@ -10,10 +10,6 @@ int is_encoding_utf8(const char *name);
>
> int print_wrapped_text(const char *text, int indent, int indent2, int
> len);
>
> -#ifndef NO_ICONV
> char *reencode_string(const char *in, const char *out_encoding, const char
> *in_encoding); -#else
> -#define reencode_string(a,b,c) NULL
> -#endif
>
> #endif
I don't think that this is still needed. It dates back to the origins of
mingw.git, at which time I did not have a working libiconv.
-- Hannes
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-02 18:37 UTC (permalink / raw)
To: Mike Hommey; +Cc: Michael J Gruber, git
In-Reply-To: <20080702182510.GC29559@glandium.org>
Mike Hommey wrote:
>> These edits are numerous and spread over many months, so the typical
>> history fixup-sessions involve periods where you make 30 random
>> historicaledits per hour (which need to be viewed and checked every time
>> immediately after making the change). And say once every 4 months, you
>> run it through git filter-branch to cast everything into stone. A
>> typical git filter-branch run takes 15 minutes on a repository this
>> size.
>I think the point was more about making a tool to do exactly what you
>want, based on the new git sequencer. Note that git filter-branch could
>also be rewritten to use the sequencer.
As far as I understood it, the new git sequencer rewrites history
proper. That is timeconsuming by definition, and thus it is *not*
possible to make a tool based on the sequencer that supports the desired
iterative-history-rewrite workflow.
--
Sincerely,
Stephen R. van den Berg.
You are confused; but this is your normal state.
^ 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