* Re: How to simulate a real checkout to test a new smudge filter?
From: Michael J Gruber @ 2016-09-07 8:52 UTC (permalink / raw)
To: john smith, Torsten Bögershausen; +Cc: git
In-Reply-To: <CAKmQUfbemaid61xPyvNheLM2jVGXGjiyF_x=NZnxkZ=5wccQ=Q@mail.gmail.com>
john smith venit, vidit, dixit 06.09.2016 23:01:
> On 9/6/16, Torsten Bögershausen <tboegi@web.de> wrote:
>> On 06.09.16 19:47, john smith wrote:
>>> I am looking for a way to force smudge filter to run by simulating a
>>> real life checkout. Let's say I just created a new branch and did not
>>> modify any files but want to test my new smudge filter. According to
>>> some answers such as
>>> https://stackoverflow.com/questions/22909620/git-smudge-clean-filter-between-branches
>>> and
>>> https://stackoverflow.com/questions/21652242/git-re-checkout-files-after-creating-smudge-filter
>>> it should be possible by running:
>>>
>>> git checkout HEAD --
>>>
>>> but in doesn't work with git 2.9.0. Method suggested in accepted
>>> answer here
>>> https://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft
>>> works but I don't like because it seems fragile. Is there a safe way
>>> to do what I want to do in Git still today?
>>>
>> It depends what you mean with "safe way".
>
> I want to store all my dotfiles in a single repoitory. The problem is
> that that some specific pieces of these files are different on
> different machines. I have a special .conf file that is different on
> every branch and contains machine-specific definitions of some
> variables such as EMAIL or SMTP server. In my smudge filter I call a
> script which parses .conf file and replace all template variable
> definitions saved in the given file with correct definitions. For
> example in my ~/.bashrc I have this on all branches:
>
> export EMAIL="@EMAIL@"
>
> and in my .conf file on `home' branch
>
> EMAIL=home@address.com
>
> and on `work' branch:
>
> EMAIL=work@address.com
>
> And in .gitattributes on both branches:
>
> bash/.bashrc filter=make-usable
>
> I also have single `master' branch that only contains template
> dotfiles and no .conf. When setting up a new machine I could just
> create a new branch off master branch and add a new .conf.
>
> In turn, clean filter replace all correct definitions in the given
> dotfiles back into template definitions.
>
> I'd prefer smudge/clean filters instead of `make' scripts etc. to
> convert template dotfiles into something usable and back because
> filters:
>
> 1. could be run automatically
>
> 2. do not modify files as shown by `git show HEAD:<file>' and
> therefore no files are reported as modified by git status and also
> there are not conflicts when merging master into work/home branch.
>
> I have problems because with point 1 because apparently smudge filter
> is not run automatically every time when branch is changed if files
> listed in .gitattributes do not change. As the last resort I could
> force smudge/clean filter to run just to keep advantage specified in
> point 2.
I'm afraid smudge/clean are not a good match for your use case:
smudge can do anything that clean removes again, i.e.: if you smudge a
blob, then clean it, it has to be the same blob.
Your smudge filter seems to give different results for the same blob
depending on other variables (your .conf), but git doesn't care as long
as clean output is the same. Also, git cannot possibly know when "it is
time" to rerun smudge.
Maybe "source"-ing .conf files would be an alternative approach for you,
or using hooks?
Cheers
Michael
^ permalink raw reply
* Re: [PATCH] gpg-interface: reflect stderr to stderr
From: Jeff King @ 2016-09-07 8:39 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <655b42d8-baa9-e649-2b3c-5b7bfc914bc5@drmicha.warpmail.net>
On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
> Now, I can't reproduce C on Linux[*], so there is more involved. It
> could be that my patch just exposes a problem in our start_command()
> etc.: run-command.c contains a lot of ifdefing, so possibly quite
> different code is run on different platforms.
Maybe, though my blind guess is that it is simply that on Linux we can
open /dev/tty directly, and console-IO on Windows is a bit more
complicated.
You might also check your GPG versions; between gpg1.x and gpg2, the
passphrase input handling has been completely revamped.
> It would be great if someone with a Windows environment could help our
> efforts in resolving issue C, by checking what is actually behind[**]: I
> can't believe that capturing stderr keeps gpg from reading stdin, but
> who knows. Maybe Jeff of pipe_command() fame? I'll put him on cc.
I know nothing about Windows, but I'd be surprised if gpg is reading
from stdin, as opposed to /dev/tty. It's probably more to do with how
gpg finds the "tty" on Windows (presumably it looks at stderr for that).
Anyway, I wrote pipe_command() in such a way as to be prepared for
exactly this kind of thing, so it would be trivial to extend it to an
extra descriptor. The trouble is that run_command() doesn't understand
anything except stdin/stdout/stderr. We can open an extra pipe() before
calling run_command(), and make sure it is not marked CLOEXEC. I don't
know if there are other portability concerns, though.
-Peff
^ permalink raw reply
* Re: [PATCH] gpg-interface: reflect stderr to stderr
From: Michael J Gruber @ 2016-09-07 8:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <alpine.DEB.2.20.1609061843120.129229@virtualbox>
Johannes Schindelin venit, vidit, dixit 06.09.2016 18:43:
> Hi Michael,
>
> okay, final mail on this issue today:
>
> On Tue, 6 Sep 2016, Johannes Schindelin wrote:
>
>> Your original issue seemed to be that the gpg command could succeed, but
>> still no signature be seen. There *must* be a way to test whether the
>> called program added a signature, simply by testing whether *any*
>> characters were written.
>>
>> And if characters were written that were not actually a GPG signature,
>> maybe the enterprisey user who configured the gpg command to be her magic
>> script actually meant something else than a GPG signature to be added?
>
> I actually just saw that this is *precisely* what the code does already:
>
> if (ret || signature->len == bottom)
> return error(_("gpg failed to sign the data"));
>
> Why is this not good enough?
Assuming "this" refers to error():
You said it's not good enough - because gpg's stderr is not displayed.
And I agree with you on that point.
Assuming "this" refers to the exit code check:
gpg documentation says so over and over again: do not rely on exit
codes, parse status-fd instead. (An often ignored advice, oh well.)
As for most of your other remarks, I would appreciate if you could take
a breath and reread what I wrote and what you wrote - before you send it
- and curb your remarks about who is working on resolving issues.
So, trying again to structure the issues and solutions, there are three
issues:
A) relying on gpg's exit code (and stdout) is not enough. Secure use of
gpg requires checking status-fd.
This is what my old patch solved.
B) "gpg --status-fd=2" and swallowing stderr hides usual stderr from the
user.
This is what my old patch introduced and a Windows user reported. It is
solved by my new additional patch.
C) With that old patch, that Windows user is not asked for a passphrase
on tty any more.
Reverting my patches appears to solve C on Windows and reintroduces A on
all platforms, obviously. C is not present on Linux. B is solved either way.
Now, I can't reproduce C on Linux[*], so there is more involved. It
could be that my patch just exposes a problem in our start_command()
etc.: run-command.c contains a lot of ifdefing, so possibly quite
different code is run on different platforms.
It would be great if someone with a Windows environment could help our
efforts in resolving issue C, by checking what is actually behind[**]: I
can't believe that capturing stderr keeps gpg from reading stdin, but
who knows. Maybe Jeff of pipe_command() fame? I'll put him on cc.
Michael
[*] Maybe that even depends on Linux environments (terminal emulator),
so input from others would be helpful, too:
Without a passphrase-agent/wallet etc, does "git tag -s -m test test"
ask you for a passphrase on the terminal?
I does for me with this stack:
X11->i3->st->tmux->bash->git->gpg
[**] "--status-fd=3" instead of "--status-fd=2" in my old patch would be
a check whether our capturing of stderr is creating problems on Windows
or gpg's writing status to stderr (which --status-fd=3 would change, at
the expense of breaking the final check): Does gpg ask for the
passphrase now?
^ permalink raw reply
* Why patch is not showed at log?
From: KES @ 2016-09-07 8:13 UTC (permalink / raw)
To: git
I have patch:
diff --git a/t b/t
index ced22c4..992533b 100644
--- a/t
+++ b/t
@@ -1,2 +1,2 @@
asdf
-asdf
\ No newline at end of file
+asdf
When I commit it I do not see it at log:
commit 1efee9908a734c40194ffc07e7793afd2e386fbc
Author: x
Date: Wed Sep 7 11:09:04 2016 +0300
asdf
commit 4f429665850cb929f73f1463bedd978dd8b68009
Author: x
Date: Wed Sep 7 11:05:20 2016 +0300
asdf
diff --git a/t b/t
new file mode 100644
index 0000000..ced22c4
--- /dev/null
+++ b/t
@@ -0,0 +1,2 @@
+asdf
+asdf
\ No newline at end of file
Why I do not see changes at log when 'new line' was added at the end of file?
^ permalink raw reply related
* [PATCH 2/2] patch-ids: skip merge commits
From: Jeff King @ 2016-09-07 7:54 UTC (permalink / raw)
To: git; +Cc: Michael Haggerty, Kevin Willford
In-Reply-To: <20160907075346.z6wtmqnfc6bsunjb@sigill.intra.peff.net>
The patch-ids code which powers "log --cherry-pick" doesn't
look at whether each commit is a merge or not. It just feeds
the commit's first parent to the diff, and ignores any
additional parents.
In theory, this might be useful if you wanted to find
equivalence between, say, a merge commit and a squash-merge
that does the same thing. But that may also be the wrong
thing; the diffs may be the same, but the meaning of the two
commits is definitely not identical. We should err on the
side of _not_ matching such commits.
Moreover, we may spend a lot of extra time computing these
merge diffs. In the case that inspired this patch, a "git
format-patch --cherry-pick" dropped from over 3 minutes to
less than 4 seconds. This seems pretty drastic, but is
easily explained. The command was invoked by a "git rebase"
of an older topic branch; there had been tens of thousands
of commits on the upstream branch in the meantime. In
addition, this project used a topic-branch workflow with
occasional "back-merges" from "master" to each topic (to
resolve conflicts on the topics rather than in the merge
commits). So there were not only extra merges, but the diffs
for these back-merges were generally quite large (because
they represented _everything_ that had been merged to master
since the topic branched).
This patch just ignores merge commits entirely when
generating patch-ids, meaning they will never be matched
(from either side of a symmetric-diff traversal).
Signed-off-by: Jeff King <peff@peff.net>
---
patch-ids.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/patch-ids.c b/patch-ids.c
index 77e4663..b1f8514 100644
--- a/patch-ids.c
+++ b/patch-ids.c
@@ -7,10 +7,12 @@
int commit_patch_id(struct commit *commit, struct diff_options *options,
unsigned char *sha1, int diff_header_only)
{
- if (commit->parents)
+ if (commit->parents) {
+ if (commit->parents->next)
+ return 0;
diff_tree_sha1(commit->parents->item->object.oid.hash,
commit->object.oid.hash, "", options);
- else
+ } else
diff_root_tree_sha1(commit->object.oid.hash, "", options);
diffcore_std(options);
return diff_flush_patch_id(options, sha1, diff_header_only);
--
2.10.0.rc2.154.gb4a4b8b
^ permalink raw reply related
* [PATCH 1/2] patch-ids: turn off rename detection
From: Jeff King @ 2016-09-07 7:54 UTC (permalink / raw)
To: git; +Cc: Michael Haggerty, Kevin Willford
In-Reply-To: <20160907075346.z6wtmqnfc6bsunjb@sigill.intra.peff.net>
The patch-id code may be running inside another porcelain
like "git log" or "git format-patch", and therefore may have
set diff_detect_rename_default, either via the diff-ui
config, or by default since 5404c11 (diff: activate
diff.renames by default, 2016-02-25). This is the case even
if a command is run with `--no-renames`, as that is applied
only to the diff-options used by the command itself.
Rename detection doesn't help the patch-id results. It
_may_ actually hurt, as minor differences in the files that
would be overlooked by patch-id's canonicalization might
result in different renames (though I'd doubt that it ever
comes up in practice).
But mostly it is just a waste of CPU to compute these
renames.
Note that we don't have to worry about compatibility here.
This patch disables renames just for the internal patch-id
comparison run by "log --cherry-pick", etc. The user-visible
"git patch-id" output depends on the patch that it is fed
(so it is up to the diff generator to use --no-renames if
they wish).
Signed-off-by: Jeff King <peff@peff.net>
---
patch-ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/patch-ids.c b/patch-ids.c
index 082412a..77e4663 100644
--- a/patch-ids.c
+++ b/patch-ids.c
@@ -45,6 +45,7 @@ int init_patch_ids(struct patch_ids *ids)
{
memset(ids, 0, sizeof(*ids));
diff_setup(&ids->diffopts);
+ ids->diffopts.detect_rename = 0;
DIFF_OPT_SET(&ids->diffopts, RECURSIVE);
diff_setup_done(&ids->diffopts);
hashmap_init(&ids->patches, (hashmap_cmp_fn)patch_id_cmp, 256);
--
2.10.0.rc2.154.gb4a4b8b
^ permalink raw reply related
* [RFC/PATCH 0/2] more patch-id speedups
From: Jeff King @ 2016-09-07 7:53 UTC (permalink / raw)
To: git; +Cc: Michael Haggerty, Kevin Willford
Michael and I found a case where the "format-patch --cherry-pick A...B"
command for a rebase took over 7 minutes to run with git v2.9.3. Yikes.
Switching to v2.10 dropped that to a bit over 3 minutes (due to the
kw/patch-ids-optim topic). Better, but not great.
The culprit turned out to be merge commits; the patch-id code will
happily diff a merge against its first parent, and ignore the rest. This
_seems_ like a bad idea, but maybe there is something clever going on
that I don't know about. I couldn't find anything useful in the history,
and given that this code was adapted from rebase, my guess is that it
was never really intended to handle merge commits in the first place (of
course we weren't trying to rebase merge commits; but it has to generate
patch-ids for everything that happened on "A" to compare against).
Dropping the computation of the merge commits got it down to about 4
seconds. I also noticed that it was doing rename detection (which also
seems like a bad idea). Disabling renames dropped another half second or
so.
This is marked as "RFC" because I don't feel entirely confident that I'm
not missing some clever need for these options. But in both cases my gut
feeling is that they are simply unintended effects that nobody ever
noticed, because it would be very rare that they would affect the
output. And that if they _did_ affect the output, they would probably be
doing the wrong thing.
-peff
^ permalink raw reply
* [PATCH] send-email: use sanitized address for cc
From: changbin.du @ 2016-09-07 6:57 UTC (permalink / raw)
To: gitster; +Cc: git, Du, Changbin
From: "Du, Changbin" <changbin.du@gmail.com>
Some username in the email address may include a ','. In this case,
we need quoting the username field so it will not be parsed as two
single addresses by Mail::Address->parse().
For example, my eamil address "Du, Changbin <changbin.du@gmail.com>"
can be parsed as two addresses "Du" and "Changbin <changbin.du@gmail.com>"
if username is not quoted. ("Du, Changbin" is a legal format of signature
in Chinese)
The sanitized address can be used because quote is added automactically.
Signed-off-by: Du, Changbin <changbin.du@gmail.com>
---
git-send-email.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 6958785..6ec189e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1554,9 +1554,9 @@ foreach my $t (@files) {
next if $suppress_cc{'sob'} and $what =~ /Signed-off-by/i;
next if $suppress_cc{'bodycc'} and $what =~ /Cc/i;
}
- push @cc, $c;
+ push @cc, $sc;
printf("(body) Adding cc: %s from line '%s'\n",
- $c, $_) unless $quiet;
+ $sc, $_) unless $quiet;
}
}
close $fh;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] sequencer: support folding in rfc2822 footer
From: Jeff King @ 2016-09-07 6:38 UTC (permalink / raw)
To: Jonathan Tan; +Cc: Junio C Hamano, git
In-Reply-To: <fbdda11c-c53e-f9fc-8b3a-934810215c5f@google.com>
On Tue, Sep 06, 2016 at 04:30:24PM -0700, Jonathan Tan wrote:
> On 09/06/2016 03:08 PM, Jonathan Tan wrote:
> > On 09/02/2016 07:23 PM, Junio C Hamano wrote:
> > > A slightly related tangent. An unconditionally good change you
> > > could make is to allow folding of in-body headers. I.e. you can
> > > have e.g.
> > >
> > > -- >8 --
> > > Subject: [PATCH] sequencer: support in-body headers that are
> > > folded according to RFC2822 rules
> > >
> > > The first paragraph after the above long title begins
> > > here...
> > >
> > > in the body of the msssage, and I _think_ we do not fold it properly
> > > when applying such a patch. We should, as that is something that
> > > appears in format-patch output (i.e. something Git itself produces,
> > > unlike the folded "footer").
> >
> > OK, I'll take a look at this.
>
> It turns out that Git seems to already do this, at least for Subject.
Right, because "Subject" is actually a real RFC 2822 header in the
generated email message. Not only do we expect things like mail readers
to handle this, but we _have_ to wrap at a certain point to meet the
standard[1].
I don't think any part of Git ever shunts "Subject" to an in-body
header, though I'd guess people do it manually all the time.
> $ git format-patch HEAD^
> 0001-this-is-a-very-long-subject-to-test-line-wrapping-th.patch
> $ cat 0001-this-is-a-very-long-subject-to-test-line-wrapping-th.patch
> <snip>
> Subject: [PATCH] this is a very long subject to test line wrapping this is a
> very long subject to test line wrapping
> <snip>
So the interesting bit is what happens with:
git checkout master^
git am 0001-*
and with:
perl -lpe '
# Bump subject down to in-body header.
if (/^Subject:/) {
print "Subject: real subject";
print "";
}
' 0001-* >patch
git checkout master^
git am patch
It looks like we get the first one right, but not the second.
-Peff
[1] A careful reader may note that arbitrarily-long body lines,
including in-body headers and footers, may _also_ run afoul of
the body line-length limits. The "right" solution there is
probably quoted-printable, but it's ugly enough that I wouldn't do
so unless we see a real-world case where the line lengths are a
problem.
^ permalink raw reply
* [PATCH v2] t6026-merge-attr: clean up background process at end of test case
From: Johannes Sixt @ 2016-09-07 6:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.20.1609060909420.129229@virtualbox>
The process spawned in the hook uses the test's trash directory as CWD.
As long as it is alive, the directory cannot be removed on Windows.
Although the test succeeds, the 'test_done' that follows produces an
error message and leaves the trash directory around. Kill the process
before the test case advances.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Am 06.09.2016 um 09:25 schrieb Johannes Schindelin:
> Maybe we should write a pid file in the sleep command instead, and kill it
> in the end? Something like this, maybe?
Yes, that is much better, thank you!
I did not extend the sleep time because it requires to change the file name
in the same patch.
I did experiment with 'while sleep 1; do :; done &' to spin indefinitely,
but the loop did not terminate in time in my tests on Windows for some
unknown reason (most likely because the killed process does not exit with
a non-zero code -- remember, Windows is not POSIX, particularly, when it
comes to signal handling).
t/t6026-merge-attr.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
index dd8f88d..7a6e33e 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -185,7 +185,9 @@ test_expect_success 'custom merge does not lock index' '
git reset --hard anchor &&
write_script sleep-one-second.sh <<-\EOF &&
sleep 1 &
+ echo $! >sleep.pid
EOF
+ test_when_finished "kill \$(cat sleep.pid)" &&
test_write_lines >.gitattributes \
"* merge=ours" "text merge=sleep-one-second" &&
--
2.10.0.85.gea34e30
^ permalink raw reply related
* Re: [PATCH v2 02/38] rename_ref_available(): add docstring
From: Michael Haggerty @ 2016-09-07 4:32 UTC (permalink / raw)
To: Jakub Narębski, Junio C Hamano
Cc: David Turner, Ramsay Jones, Eric Sunshine, Jeff King,
Nguyễn Thái Ngọc Duy, git, David Turner
In-Reply-To: <236a95a0-59d4-3788-9104-5ca299119e66@gmail.com>
On 09/06/2016 04:25 PM, Jakub Narębski wrote:
> W dniu 04.09.2016 o 18:08, Michael Haggerty pisze:
>
>> +/*
>> + * Check whether an attempt to rename old_refname to new_refname would
>> + * cause a D/F conflict with any existing reference (other than
>> + * possibly old_refname). If there would be a conflict, emit an error
>> + * message and return false; otherwise, return true.
>> + *
>> + * Note that this function is not safe against all races with other
>> + * processes (though rename_ref() catches some races that might get by
>> + * this check).
>> + */
>> +int rename_ref_available(const char *old_refname, const char *new_refname);
>
> Just a sidenote: does Git have a naming convention for query functions
> returning a boolean, for example using is_* as a prefix?
I've never heard of an official convention like that, and don't see it
documented anywhere. But there are a lot of functions (and variables)
whose names start with `is_`, and it seems like a reasonable idea.
> That is, shouldn't it be
>
> int is_rename_ref_available(const char *old_refname, const char *new_refname);
I agree, that would be a better name.
But that naming change is orthogonal to this patch series, which only
adds a docstring to the function. I don't think it's worth rerolling
this 38-patch series to add it. So I suggest that we keep your idea in
mind for the next time this code is touched (or feel free to submit a
patch yourself, preferably on top of this patch series to avoid conflicts).
Thanks,
Michael
^ permalink raw reply
* Re: Draft of Git Rev News edition 18
From: Eric Wong @ 2016-09-07 1:08 UTC (permalink / raw)
To: Josh Triplett
Cc: Jakub Narębski, Philip Oakley, Christian Couder, git,
Thomas Ferris Nicolaisen, Nicola Paolucci, Junio C Hamano,
Jeff King, Nguyen Thai Ngoc Duy, Stefan Beller, Michael Haggerty,
Ramsay Jones, remi galan-alfonso, Johannes Sixt,
Torsten Bögershausen, Lars Schneider, meta
In-Reply-To: <20160816223215.GC17195@cloud>
Josh Triplett <josh@joshtriplett.org> wrote:
> On Tue, Aug 16, 2016 at 09:27:04PM +0000, Eric Wong wrote:
> > As for other projects, I'm not aware of anybody else using it,
> > yet. I have some small projects using it, but most of those are
> > one-off throwaways and I'm not comfortable promoting those along
> > with public-inbox. I admit: I'm not comfortable promoting
> > anything I do, really.
>
> Please take this as encouragement to do so. I'd love to see the
> public-inbox equivalent to the main page of https://lists.debian.org/ ,
> as an example. (And I'd love to have public-inbox archives of Debian
> mailing lists.)
Just pushed out some POD (which should build to manpages),
so maybe early adopters can start hosting mirrors themselves(*).
https://public-inbox.org/meta/20160907004907.1479-1-e@80x24.org/
I hope public-inbox-overview(7) is a good starting point
(along with the existing INSTALL) and there'll be more docs
coming at some point...
Writing documentation tends to make my attention span drift all
over the place; so maybe parts don't make sense or were glossed
over, but I'll be glad to help clarify anything. (Responding
to emails is generally easier for me since I can answer things
specifically, tough to do for generic docs)
I'll try to get a tarball release out soonish,
but my schedule is unpredictable.
(*) None of the code has had any security audit, yet;
and there's no warranty of course.
^ permalink raw reply
* Re: [PATCH] sequencer: support folding in rfc2822 footer
From: Jonathan Tan @ 2016-09-06 23:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <29cb0f55-f729-80af-cdca-64e927fa97c0@google.com>
On 09/06/2016 03:08 PM, Jonathan Tan wrote:
> On 09/02/2016 07:23 PM, Junio C Hamano wrote:
>> A slightly related tangent. An unconditionally good change you
>> could make is to allow folding of in-body headers. I.e. you can
>> have e.g.
>>
>> -- >8 --
>> Subject: [PATCH] sequencer: support in-body headers that are
>> folded according to RFC2822 rules
>>
>> The first paragraph after the above long title begins
>> here...
>>
>> in the body of the msssage, and I _think_ we do not fold it properly
>> when applying such a patch. We should, as that is something that
>> appears in format-patch output (i.e. something Git itself produces,
>> unlike the folded "footer").
>
> OK, I'll take a look at this.
It turns out that Git seems to already do this, at least for Subject.
Transcript below:
$ echo one > file.txt
$ git add file.txt
$ git commit -m x
[master (root-commit) 2389483] x
1 file changed, 1 insertion(+)
create mode 100644 file.txt
$ echo two > file.txt
$ git commit -am 'this is a very long subject to test line wrapping this
is a very long subject to test line wrapping'
[master ca86792] this is a very long subject to test line wrapping this
is a very long subject to test line wrapping
1 file changed, 1 insertion(+), 1 deletion(-)
$ git format-patch HEAD^
0001-this-is-a-very-long-subject-to-test-line-wrapping-th.patch
$ cat 0001-this-is-a-very-long-subject-to-test-line-wrapping-th.patch
<snip>
Subject: [PATCH] this is a very long subject to test line wrapping this is a
very long subject to test line wrapping
<snip>
^ permalink raw reply
* Re: [PATCH] sequencer: support folding in rfc2822 footer
From: Jonathan Tan @ 2016-09-06 22:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqy439rabb.fsf@gitster.mtv.corp.google.com>
On 09/02/2016 07:23 PM, Junio C Hamano wrote:
> Jonathan Tan <jonathantanmy@google.com> writes:
>
>> Sample-field: multiple-line field body
>> that causes a blank line below
>
> I am not sure this is unconditionally good, or may cause problems to
> those with workflows you did not consider when you wrote this patch.
>
> Not being too lenient here historically has been a deliberate
> decision to avoid misidentification of non "footers". Does Git
> itself produce some folded footer line? If Git itself produced such
> folded lines, I'd be a lot more receptive to this change, but I do
> not think that is the case here.
I don't think Git produces any folded lines, but folded lines do appear
in footers in projects that use Git. For example, some Android commits
have multi-line "Test:" fields (example, [1]) and some Linux commits
have multi-line "Tested-by:" fields (example, [2]).
Taking the Android commit as an example, this would mean that
cherrypicking that commit would create a whole new footer, and tripping
up tools (for example, Gerrit, which looks for "Change-Id:" in the last
paragraph). But this would not happen if "Test:" was single-line instead
of multi-line - which seems inconsistent.
[1]
https://android.googlesource.com/platform/frameworks/base/+/4c5281862f750cbc9d7355a07ef1a5545b9b3523
[2]
https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/69f92f67b68ab7028ffe15f0eea76b59f8859383
> A slightly related tangent. An unconditionally good change you
> could make is to allow folding of in-body headers. I.e. you can
> have e.g.
>
> -- >8 --
> Subject: [PATCH] sequencer: support in-body headers that are
> folded according to RFC2822 rules
>
> The first paragraph after the above long title begins
> here...
>
> in the body of the msssage, and I _think_ we do not fold it properly
> when applying such a patch. We should, as that is something that
> appears in format-patch output (i.e. something Git itself produces,
> unlike the folded "footer").
OK, I'll take a look at this.
^ permalink raw reply
* Re: [PATCH v1 2/2] read-cache: make sure file handles are not inherited by child processes
From: Eric Wong @ 2016-09-06 21:06 UTC (permalink / raw)
To: larsxschneider; +Cc: git, gitster, tboegi, Johannes.Schindelin
In-Reply-To: <20160905211111.72956-3-larsxschneider@gmail.com>
larsxschneider@gmail.com wrote:
> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> {
> int match = -1;
> - int fd = open(ce->name, O_RDONLY);
> + int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
>
> if (fd >= 0) {
> unsigned char sha1[20];
Also, this needs to check EINVAL when O_CLOEXEC != 0 the same
way create_tempfile currently does. Somebody could be building
with modern headers but running an old kernel that doesn't
understand O_CLOEXEC.
There should probably be a open() wrapper for handling this case
since we're now up to 3 places where open(... O_CLOEXEC) is
used.
^ permalink raw reply
* Re: How to simulate a real checkout to test a new smudge filter?
From: john smith @ 2016-09-06 21:01 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <b71adc54-2ae6-ef8e-1dca-0883cd617e6e@web.de>
On 9/6/16, Torsten Bögershausen <tboegi@web.de> wrote:
> On 06.09.16 19:47, john smith wrote:
>> I am looking for a way to force smudge filter to run by simulating a
>> real life checkout. Let's say I just created a new branch and did not
>> modify any files but want to test my new smudge filter. According to
>> some answers such as
>> https://stackoverflow.com/questions/22909620/git-smudge-clean-filter-between-branches
>> and
>> https://stackoverflow.com/questions/21652242/git-re-checkout-files-after-creating-smudge-filter
>> it should be possible by running:
>>
>> git checkout HEAD --
>>
>> but in doesn't work with git 2.9.0. Method suggested in accepted
>> answer here
>> https://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft
>> works but I don't like because it seems fragile. Is there a safe way
>> to do what I want to do in Git still today?
>>
> It depends what you mean with "safe way".
I want to store all my dotfiles in a single repoitory. The problem is
that that some specific pieces of these files are different on
different machines. I have a special .conf file that is different on
every branch and contains machine-specific definitions of some
variables such as EMAIL or SMTP server. In my smudge filter I call a
script which parses .conf file and replace all template variable
definitions saved in the given file with correct definitions. For
example in my ~/.bashrc I have this on all branches:
export EMAIL="@EMAIL@"
and in my .conf file on `home' branch
EMAIL=home@address.com
and on `work' branch:
EMAIL=work@address.com
And in .gitattributes on both branches:
bash/.bashrc filter=make-usable
I also have single `master' branch that only contains template
dotfiles and no .conf. When setting up a new machine I could just
create a new branch off master branch and add a new .conf.
In turn, clean filter replace all correct definitions in the given
dotfiles back into template definitions.
I'd prefer smudge/clean filters instead of `make' scripts etc. to
convert template dotfiles into something usable and back because
filters:
1. could be run automatically
2. do not modify files as shown by `git show HEAD:<file>' and
therefore no files are reported as modified by git status and also
there are not conflicts when merging master into work/home branch.
I have problems because with point 1 because apparently smudge filter
is not run automatically every time when branch is changed if files
listed in .gitattributes do not change. As the last resort I could
force smudge/clean filter to run just to keep advantage specified in
point 2.
--
<wempwer@gmail.com>
^ permalink raw reply
* Re: Your email
From: Idan Shimoni @ 2016-09-06 20:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.2.20.1609061823110.129229@virtualbox>
Johannes,
You know what, lets end it.
You are right and I am sorry.
Have a great life.
--
-Best
Idan
^ permalink raw reply
* Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts
From: Dakota Hawkins @ 2016-09-06 20:02 UTC (permalink / raw)
To: Stefan Beller; +Cc: Git Mailing List, mwitte
In-Reply-To: <CAGZ79kb=LyusFH6tGirGP9qK1k-cov2UubEbKPfeyPRThUsa-Q@mail.gmail.com>
On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller <sbeller@google.com> wrote:
> On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins <dakotahawkins@gmail.com> wrote:
>> Below is a simple reproduction of the issue.
>>
>> The _real_ problem is that this is how our pull request merges work,
>
> So your workflow is the problem or is the actual bug just exposed in
> your workflow?
I believe the workflow just exposes the problem, which is that
generically for this case a fast-forward merge works without conflicts
while a non-fast-forward merge fails with conflicts. Sorry if this
confuses the issue, it's just how we experienced it so I wanted to add
that background.
>> ## Test fast-forward merge, this will work
>> git checkout -b merge-ff-test master # warning: unable to rmdir
>> submodule-location-2: Directory not empty
>> rm -rf ./submodule-location-2
>> git merge --ff-only move-submodule
>>
>
> And no reset/rm in between, i.e. we still have
> submodule-location-2 from merge-ff-test still around?
That is true in that example, but somewhat immaterial. The first merge
was only to demonstrate that a fast-forward merge works without
conflict. The simplest reproduction is to skip that and get straight
to the failure case:
## Clone and setup branches
git clone https://github.com/dakotahawkins/submodule-move-merge-bug-main-repo.git
cd submodule-move-merge-bug-main-repo
git branch move-submodule origin/move-submodule
git checkout -b merge-no-ff-test master
## This will fail
git merge --no-ff move-submodule
# Auto-merging submodule-location-2
# Adding as submodule-location-2~move-submodule instead
# Automatic merge failed; fix conflicts and then commit the result.
Does that make things a little bit clearer?
Dakota
^ permalink raw reply
* Re: How to simulate a real checkout to test a new smudge filter?
From: Torsten Bögershausen @ 2016-09-06 19:48 UTC (permalink / raw)
To: john smith, git
In-Reply-To: <CAKmQUfa_U-g6vC+SjbQSicEUwO+WofNfzezEEwikeOAeL31W5g@mail.gmail.com>
On 06.09.16 19:47, john smith wrote:
> I am looking for a way to force smudge filter to run by simulating a
> real life checkout. Let's say I just created a new branch and did not
> modify any files but want to test my new smudge filter. According to
> some answers such as
> https://stackoverflow.com/questions/22909620/git-smudge-clean-filter-between-branches
> and
> https://stackoverflow.com/questions/21652242/git-re-checkout-files-after-creating-smudge-filter
> it should be possible by running:
>
> git checkout HEAD --
>
> but in doesn't work with git 2.9.0. Method suggested in accepted
> answer here
> https://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft
> works but I don't like because it seems fragile. Is there a safe way
> to do what I want to do in Git still today?
>
It depends what you mean with "safe way".
git checkout, git checkout -f or other combinations will only
overwrite/rewrite the files in the working tree, if, and only if,
git comes to the conclusion that "git add" will do something,
like replace a blob for a file in the index.
(And by running "rm .git/index git will evaluate the "clean" filters,
and the CRLF->LF conversion).
If you want to test a smudge filter, simply remove the file:
mv file /tmp && git checkout file
^ permalink raw reply
* Re: 2.10.0: multiple versionsort.prereleasesuffix buggy?
From: SZEDER Gábor @ 2016-09-06 19:45 UTC (permalink / raw)
To: Jeff King; +Cc: git, leho
In-Reply-To: <20160906040739.37otpk3l2wt7qfbb@sigill.intra.peff.net>
Hi,
Quoting Jeff King <peff@peff.net>:
> On Tue, Sep 06, 2016 at 03:07:59AM +0200, SZEDER Gábor wrote:
>
>>> So that seems wrong. Even weirder, if I set _only_ "-beta", I get:
>>>
>>> $ git tag -l --sort=version:refname | grep -v ^2.6.0
>>> 2.6.0-beta-2
>>> 2.6.0-beta-3
>>> 2.6.0-beta-4
>>> 2.6.0
>>> 2.6.0-RC1
>>> 2.6.0-RC2
>>> 2.6.0-beta-1
>>>
>>> Umm...what? beta-1 is sorted away from its companions? That's weird.
>>>
>>> I wondered if the presence of "-" after the suffix ("beta-1" rather than
>>> "beta1") would matter. It looks like that shouldn't matter, though; it's
>>> purely doing a prefix match on "do these names differ at a prerelease
>>> suffix".
>>>
>>> But something certainly seems wrong.
>>
>> Some of the weirdness is caused by the '-' at the _beginning_ of the
>> suffixes, because versioncmp() gets confused by suffixes starting with
>> the same character(s).
>
> Oh, right, that makes sense. So it's effectively not finding _any_
> suffix between X-RC1 and X-beta-1, because we only start looking after
> "X-", and none of them match.
>
> I am still confused why "2.6.0-beta-1" doesn't get sorted with its
> peers. I'd guess that the comparison function doesn't actually provide a
> strict ordering, so the results depend on the actual sort algorithm, and
> which pairs it ends up comparing.
Turns out that this weirdness is caused by that leading '-' in the suffix,
too.
Here is a manageably small recipe to reproduce:
$ git -c versionsort.prereleasesuffix=-beta tag -l
--sort=version:refname v2.1.0* v2.1.{1,2}
v2.1.0-beta-2
v2.1.0-beta-3
v2.1.0
v2.1.0-RC1
v2.1.0-RC2
v2.1.0-beta-1
v2.1.1
v2.1.2
Tracing which pairs of tagnames are compared, I found that somewhere along
the line "v2.1.0-beta-1" happens to be compared to "v2.1.0-RC2", and the
issue described in my previous email strikes again: the '-' is part of the
common part of the two tagnames, swap_prereleases() gets only "beta-1" and
"RC2", thus it can't match the configured "-beta" suffix, and since the
byte value of 'b' is higher than that of 'R', "-beta-1" is sorted after
"-RC2". OTOH, "v2.1.0-beta-2" and "v2.1.0-beta-3" are only compared to
each other or to final release tags, but never to any "-RCx" tags, hence
they are sorted properly.
Once I finish teaching versioncmp() and swap_prereleases() to cope with
leading characters of a prereleaseSuffix being part of the common part of
two tagnames, this out-of-order "beta-1" issue will be gone as well.
Best,
Gábor
^ permalink raw reply
* Re: Fixup of a fixup not working right
From: Philip Oakley @ 2016-09-06 19:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Robert Dailey, Git
In-Reply-To: <alpine.DEB.2.20.1609050950130.129229@virtualbox>
From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> Hi Philip,
>
> On Sun, 4 Sep 2016, Philip Oakley wrote:
>
>> From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
>>
>> > The point is that fixup! messages are really special, and are always
>> > intended to be squashed into the referenced commit *before* the latter
>> > hits `master`.
>>
>> I think it's here that we have the hidden use case. I agree that all
>> fixups
>> should be squashed before they hit the blessed golden repository.
>>
>> I suspect that some use cases have intermediate repositories that
>> contain a 'master' branch (it's just a name ;-) that isn't blessed and
>> golden, e.g. at the team review repo level. In such cases it is possible
>> for a fixup! to be passed up as part of the review, though it's not the
>> current norm/expectation.
>
> In such a case (which can totally arise when criss-crossing Pull Requests
> on GitHub, for example, where a Pull Request's purpose may be to fix up
> commits in another Pull Request before the latter is merged), the most
> appropriate course of action is... to not reorder the fixup!s prematurely.
We just need to be careful about that plural just there.
If it is multiple fixup!s for the same commit, then I believe they should be
grouped together at the same point as the first fixup! commit (in their
original order).
If they are for different commits, then they should stay in their place in
the commit series (for their first occurrence, then rule 1 applies)
>
>> > In short, I am opposed to this change.
>>
>> It's not like G4W doesn't need fixup!s on the side branches e.g. 5eaffe9
>> ("fixup! Handle new t1501 test case properly with MinGW", 2016-07-12)
I note that you don't have two fixup!s for that commit
> Yeah, well, Git for Windows' `master` branch is special, in that it is
> constantly rebased (as "merging rebases", to keep fast-forwardability). I
> would not necessarily use Git for Windows as a role model in this respect.
I don't see GfW as 'special', rather as being a representative of a broader
realpolitik where some of the rugged individualism of open source is
moderated in some way or another.
> Ciao,
> Dscho
>
--
Philip
^ permalink raw reply
* [PATCH] gitweb: use highlight's shebang detection
From: Ian Kelling @ 2016-09-06 19:00 UTC (permalink / raw)
To: git; +Cc: jnareb
The highlight binary can detect language by shebang when we can't tell
the syntax type by the name of the file. To use highlight's shebang
detection, add highlight to the pipeline whenever highlight is enabled.
Document the shebang detection and add a test which exercises it in
t/t9500-gitweb-standalone-no-errors.sh.
Signed-off-by: Ian Kelling <ian@iankelling.org>
---
Notes:
I wondered if adding highlight to the pipeline would make viewing a blob
with no highlighting take longer but it did not on my computer. I found
no noticeable impact on small files and strangely, on a 159k file, it
took 7% less time averaged over several requests.
Documentation/gitweb.conf.txt | 21 ++++++++++++++-------
gitweb/gitweb.perl | 10 +++++-----
t/t9500-gitweb-standalone-no-errors.sh | 18 +++++++++++++-----
3 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index a79e350..e632089 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -246,13 +246,20 @@ $highlight_bin::
Note that 'highlight' feature must be set for gitweb to actually
use syntax highlighting.
+
-*NOTE*: if you want to add support for new file type (supported by
-"highlight" but not used by gitweb), you need to modify `%highlight_ext`
-or `%highlight_basename`, depending on whether you detect type of file
-based on extension (for example "sh") or on its basename (for example
-"Makefile"). The keys of these hashes are extension and basename,
-respectively, and value for given key is name of syntax to be passed via
-`--syntax <syntax>` to highlighter.
+*NOTE*: for a file to be highlighted, its syntax type must be detected
+and that syntax must be supported by "highlight". The default syntax
+detection is minimal, and there are many supported syntax types with no
+detection by default. There are three options for adding syntax
+detection. The first and second priority are `%highlight_basename` and
+`%highlight_ext`, which detect based on basename (the full filename, for
+example "Makefile") and extension (for example "sh"). The keys of these
+hashes are the basename and extension, respectively, and the value for a
+given key is the name of the syntax to be passed via `--syntax <syntax>`
+to "highlight". The last priority is the "highlight" configuration of
+`Shebang` regular expressions to detect the language based on the first
+line in the file, (for example, matching the line "#!/bin/bash"). See
+the highlight documentation and the default config at
+/etc/highlight/filetypes.conf for more details.
+
For example if repositories you are hosting use "phtml" extension for
PHP files, and you want to have correct syntax-highlighting for those
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 33d701d..a672181 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3931,15 +3931,16 @@ sub guess_file_syntax {
# or return original FD if no highlighting
sub run_highlighter {
my ($fd, $highlight, $syntax) = @_;
- return $fd unless ($highlight && defined $syntax);
+ return $fd unless ($highlight);
close $fd;
+ my $syntax_arg = (defined $syntax) ? "--syntax $syntax" : "--force";
open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
quote_command($^X, '-CO', '-MEncode=decode,FB_DEFAULT', '-pse',
'$_ = decode($fe, $_, FB_DEFAULT) if !utf8::decode($_);',
'--', "-fe=$fallback_encoding")." | ".
quote_command($highlight_bin).
- " --replace-tabs=8 --fragment --syntax $syntax |"
+ " --replace-tabs=8 --fragment $syntax_arg |"
or die_error(500, "Couldn't open file or run syntax highlighter");
return $fd;
}
@@ -7063,8 +7064,7 @@ sub git_blob {
my $highlight = gitweb_check_feature('highlight');
my $syntax = guess_file_syntax($highlight, $mimetype, $file_name);
- $fd = run_highlighter($fd, $highlight, $syntax)
- if $syntax;
+ $fd = run_highlighter($fd, $highlight, $syntax);
git_header_html(undef, $expires);
my $formats_nav = '';
@@ -7117,7 +7117,7 @@ sub git_blob {
$line = untabify($line);
printf qq!<div class="pre"><a id="l%i" href="%s#l%i" class="linenr">%4i</a> %s</div>\n!,
$nr, esc_attr(href(-replay => 1)), $nr, $nr,
- $syntax ? sanitize($line) : esc_html($line, -nbsp=>1);
+ $highlight ? sanitize($line) : esc_html($line, -nbsp=>1);
}
}
close $fd
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index e94b2f1..9e5fcfe 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -702,12 +702,20 @@ test_expect_success HIGHLIGHT \
gitweb_run "p=.git;a=blob;f=file"'
test_expect_success HIGHLIGHT \
- 'syntax highlighting (highlighted, shell script)' \
+ 'syntax highlighting (highlighted, shell script shebang)' \
'git config gitweb.highlight yes &&
- echo "#!/usr/bin/sh" > test.sh &&
- git add test.sh &&
- git commit -m "Add test.sh" &&
- gitweb_run "p=.git;a=blob;f=test.sh"'
+ echo "#!/usr/bin/sh" > test &&
+ git add test &&
+ git commit -m "Add test" &&
+ gitweb_run "p=.git;a=blob;f=test"'
+
+test_expect_success HIGHLIGHT \
+ 'syntax highlighting (highlighted, header file)' \
+ 'git config gitweb.highlight yes &&
+ echo "#define ANSWER 42" > test.h &&
+ git add test.h &&
+ git commit -m "Add test.h" &&
+ gitweb_run "p=.git;a=blob;f=test.h"'
# ----------------------------------------------------------------------
# forks of projects
--
2.9.3
^ permalink raw reply related
* Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts
From: Stefan Beller @ 2016-09-06 19:00 UTC (permalink / raw)
To: Dakota Hawkins; +Cc: Git Mailing List, mwitte
In-Reply-To: <CAG0BQX=wvpkJ=PQWV-NbmhuPV8yzvd_KYKzJmsfWq9xStZ2bnQ@mail.gmail.com>
On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins <dakotahawkins@gmail.com> wrote:
> Below is a simple reproduction of the issue.
>
> The _real_ problem is that this is how our pull request merges work,
So your workflow is the problem or is the actual bug just exposed in
your workflow?
> they're not allowed to do fast-forward merges. To work around this we
> are having to split this up into two pull requests/merges: One that
> copies the submodules to the new location and includes any fixes
> required to support the move, and a second that removes the old
> locations.
>
> ## Setup steps
> git clone https://github.com/dakotahawkins/submodule-move-merge-bug-main-repo.git
> cd submodule-move-merge-bug-main-repo
> ## How it was initially constructed
> # git submodule add ../submodule-move-merge-bug-submodule-repo.git
> ./submodule-location-1
> # git commit -m "Added submodule in its initial location"
> # git push
> # git checkout -b move-submodule
> # git mv ./submodule-location-1 ./submodule-location-2
> # git commit -m "Moved submodule"
> # git push --set-upstream origin move-submodule
> git branch move-submodule origin/move-submodule
>
> ## Test fast-forward merge, this will work
> git checkout -b merge-ff-test master # warning: unable to rmdir
> submodule-location-2: Directory not empty
> rm -rf ./submodule-location-2
> git merge --ff-only move-submodule
>
And no reset/rm in between, i.e. we still have
submodule-location-2 from merge-ff-test still around?
> ## Test no-fast-forward merge, this will fail with conflicts:
> git checkout -b merge-no-ff-test master
> git merge --no-ff move-submodule
> # Auto-merging submodule-location-2
> # Adding as submodule-location-2~move-submodule instead
> # Automatic merge failed; fix conflicts and then commit the result.
> git status
> # On branch merge-no-ff-test
> # You have unmerged paths.
> # (fix conflicts and run "git commit")
> # (use "git merge --abort" to abort the merge)
> #
> # Changes to be committed:
> #
> # modified: .gitmodules
> # deleted: submodule-location-1
> #
> # Unmerged paths:
> # (use "git add <file>..." to mark resolution)
> #
> # added by us: submodule-location-2
> #
> # fatal: Not a git repository: 'submodule-location-1/.git'
> # Submodule changes to be committed:
> #
> # * submodule-location-1 07fec24...0000000:
^ permalink raw reply
* [PATCH v2] rebase -i: improve advice on bad instruction lines
From: Ralf Thielow @ 2016-09-06 18:59 UTC (permalink / raw)
To: git; +Cc: gitster, Ralf Thielow
In-Reply-To: <20160906180838.865-1-ralf.thielow@gmail.com>
If we found bad instruction lines in the instruction sheet
of interactive rebase, we give the user advice on how to
fix it. However, we don't tell the user what to do afterwards.
Give the user advice to run 'git rebase --continue' after
the fix.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
Changes in v2:
- adjust tests
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index b1ba21c..029594e 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1041,7 +1041,7 @@ The possible behaviours are: ignore, warn, error.")"
# placed before the commit of the next action
checkout_onto
- warn "$(gettext "You can fix this with 'git rebase --edit-todo'.")"
+ warn "$(gettext "You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.")"
die "$(gettext "Or you can abort the rebase with 'git rebase --abort'.")"
fi
}
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 597e94e..e38e296 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1195,7 +1195,7 @@ To avoid this message, use "drop" to explicitly remove a commit.
Use 'git config rebase.missingCommitsCheck' to change the level of warnings.
The possible behaviours are: ignore, warn, error.
-You can fix this with 'git rebase --edit-todo'.
+You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.
EOF
@@ -1219,7 +1219,7 @@ cat >expect <<EOF
Warning: the command isn't recognized in the following line:
- badcmd $(git rev-list --oneline -1 master~1)
-You can fix this with 'git rebase --edit-todo'.
+You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.
EOF
@@ -1254,7 +1254,7 @@ cat >expect <<EOF
Warning: the SHA-1 is missing or isn't a commit in the following line:
- edit XXXXXXX False commit
-You can fix this with 'git rebase --edit-todo'.
+You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.
EOF
--
2.10.0.304.gf2ff484.dirty
^ permalink raw reply related
* Re: [PATCH v14 00/41] libify apply and use lib in am, part 2
From: Stefan Beller @ 2016-09-06 18:54 UTC (permalink / raw)
To: Christian Couder
Cc: git@vger.kernel.org, Junio C Hamano, Jeff King,
Ævar Arnfjörð Bjarmason, Karsten Blees,
Nguyen Thai Ngoc Duy, Eric Sunshine, Ramsay Jones, Johannes Sixt,
René Scharfe, Stefan Naewe, Christian Couder
In-Reply-To: <20160904201833.21676-1-chriscool@tuxfamily.org>
On Sun, Sep 4, 2016 at 1:17 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> Goal
> ~~~~
>
> This is a patch series about libifying `git apply` functionality, and
> using this libified functionality in `git am`, so that no 'git apply'
> process is spawn anymore. This makes `git am` significantly faster, so
> `git rebase`, when it uses the am backend, is also significantly
> faster.
>
I reviewed this v14 and all patches look good to me.
Thanks,
Stefan
^ 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