The existing wording gives an impression that it only gives the
contents of the $GIT_DIR/rebase-apply/patch file, i.e. the patch
proper, but the option actually emits the entire e-mail message
being processed (iow, one of the output files from "git mailsplit").
Signed-off-by: Juni
Hi Pratyush,
On Tue, Oct 8, 2019 at 7:59 PM Pratyush Yadav wrote:
> On 07/10/19 06:52PM, Birger Skogeng Pedersen wrote:
> > So I kinda got this working, but only when focusing the commit message
> > widget.
>
> Isn't this the point of your feature? You change the view
On 07/10/19 06:52PM, Birger Skogeng Pedersen wrote:
> So I kinda got this working, but only when focusing the commit message widget.
Isn't this the point of your feature? You change the view when focusing
the commit message widget. I remember you were explicitly against doing
it as soo
So I kinda got this working, but only when focusing the commit message widget.
I did not manage to get it working when invoking "do_add_all", (e.g.
when pressing CTRL/CMD+i). I added this:
bind $ui_comm <$M1B-Key-i> {do_add_all;select_staged_file;break}
bind $ui_comm <$M1B
Add a new "discard" event type for trace2 event destinations. When the
trace2 file count check creates a sentinel file, it will include the
normal trace2 output in the sentinel, along with this new discard
event.
Writing this message into the sentinel file is useful for tracking how
Hi Alexander,
On Thu, 3 Oct 2019, Alexander Mills wrote:
> when running git commands outside of a git repo, we often see:
>
> fatal: Not a git repository (or any of the parent directories): .git
>
> such a lame message lol.
An equally ornery response might point out that reportin
Add a new "overload" event type for trace2 event destinations. When the
trace2 overload feature creates a sentinel file, it will include the
normal trace2 output in the sentinel, along with this new overload
event.
Writing this message into the sentinel file is useful for tracking how
when running git commands outside of a git repo, we often see:
fatal: Not a git repository (or any of the parent directories): .git
such a lame message lol.
can we get an absolute path on this message in future git versions, eg:
Not a git repository (or any of the parent directories): /home
).
True. I would much prefer that the staged file is selected on commit
widget focus, regardless of how the focus was changed (hotkey or
mouse).
> Did you try binding a script to the FocusIn event of the commit message
> buffer? You can do this like:
>
> bind $ui_comm {your_script}
&
On Tue, Sep 24, 2019 at 03:40:28AM -0700, Alexandr Miloslavskiy via
GitGitGadget wrote:
> Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
> tests Please refer to individual commit messages for more information.
>
> Alexandr Miloslavskiy (2):
> t0028: fix test for UTF-16
select a path in the
> list, if it isn't focused already), then
> - Focus the "Commit Message" widget
Why are you changing the Alt+4 binding? This means your feature won't
work for people who use the mouse to move around in the UI (which I
suppose would be a majority).
Honestly I'll need some help to get this one implemented. The only
implementation I've got working currently, is to change Alt+4 key bind
to do the following:
- Focus the "Staged Changes" widget (which will select a path in the
list, if it isn't focused already), then
-
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
rload" event type for trace2 event destinations. Write
this event into the sentinel file created by the trace2.maxFiles
feature. Bump up the event format version since we've added a new event
type.
Writing this message into the sentinel file is useful for tracking how
often the overload protec
admon wrote:
> > > > > Add a new "overload" event type for trace2 event destinations. Write
> > > > > this event into the sentinel file created by the trace2.maxFiles
> > > > > feature. Bump up the event format version since we've added a n
created by the trace2.maxFiles
feature. Bump up the event format version since we've added a new event
type.
Writing this message into the sentinel file is useful for tracking how
often the overload protection feature is triggered in practice.
Putting meaningful data into the sentinel file is
entinel file created by the trace2.maxFiles
> > > feature. Bump up the event format version since we've added a new event
> > > type.
> > >
> > > Writing this message into the sentinel file is useful for tracking how
> > > often the overload protection
mat version since we've added a new event
> > type.
> >
> > Writing this message into the sentinel file is useful for tracking how
> > often the overload protection feature is triggered in practice.
>
> Putting meaningful data into the sentinel file is valuable.
On 15/09/19 09:55AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> On Sat, Sep 14, 2019 at 11:15 PM Pratyush Yadav
> wrote:
> > Why should it only happen when the commit message widget is selected?
> > What's wrong with directly switching focus when
ded a new event
type.
Writing this message into the sentinel file is useful for tracking how
often the overload protection feature is triggered in practice.
Putting meaningful data into the sentinel file is valuable. It's
important to know a bit about when and why this happened. A user
woul
On 9/13/2019 8:26 PM, Josh Steadmon wrote:
> Add a new "overload" event type for trace2 event destinations. Write
> this event into the sentinel file created by the trace2.maxFiles
> feature. Bump up the event format version since we've added a new event
> type.
>
&
Hi Pratyush,
On Sat, Sep 14, 2019 at 11:15 PM Pratyush Yadav wrote:
> Why should it only happen when the commit message widget is selected?
> What's wrong with directly switching focus when all the files are
> staged?
>
> What I have in mind is once there are no more files
On 15/09/19 02:45AM, Pratyush Yadav wrote:
> On 14/09/19 02:24PM, Birger Skogeng Pedersen wrote:
> > Hi everyone,
> >
> >
> > I personally prefer to have the changes I am about to commit visible
> > in the diff view, while I write my commit message. So usuall
uld prefer that git-gui automatically selects one of the staged
>> files and shows it in the diff widget before I type up my commit
>> message. Naturally, this automatic selection should **only** happen
>> when the user chooses focus the "Commit Message" widget.
>
&g
On 14/09/19 02:24PM, Birger Skogeng Pedersen wrote:
> Hi everyone,
>
>
> I personally prefer to have the changes I am about to commit visible
> in the diff view, while I write my commit message. So usually I do
> this:
> 1. Stage the file(s) I've been working on.
> 2
Hi everyone,
I personally prefer to have the changes I am about to commit visible
in the diff view, while I write my commit message. So usually I do
this:
1. Stage the file(s) I've been working on.
2. Select a file I just staged, so I can see the changes in the diff widget.
3. Jump t
Add a new "overload" event type for trace2 event destinations. Write
this event into the sentinel file created by the trace2.maxFiles
feature. Bump up the event format version since we've added a new event
type.
Writing this message into the sentinel file is useful for trackin
On Tue, Sep 10, 2019 at 6:50 PM Johannes Sixt wrote:
>
> Am 04.09.19 um 22:10 schrieb Bert Wesarg:
> > The commit message widget does not wrap the next and has a configurable
> > fixed width to avoid creating too wide commit messages. Though this was
> > only enforced
On Tue, Sep 10, 2019 at 10:35 PM Pratyush Yadav wrote:
>
> On 04/09/19 10:10PM, Bert Wesarg wrote:
> > The commit message widget does not wrap the next and has a configurable
> > fixed width to avoid creating too wide commit messages. Though this was
> > only enforced
On 04/09/19 10:10PM, Bert Wesarg wrote:
> The commit message widget does not wrap the next and has a configurable
> fixed width to avoid creating too wide commit messages. Though this was
> only enforced in the GUI. Now we also check the commit message at commit
> time for long lines
ping can be
> > annoying.
> >
> > I suspect there is a moderately happy medium between the two, perhaps with
> > an autowrap key (per paragraph) being available.
> >
> > I also had it in my head that some parts of Git do allow more than a single
> > line hea
Am 04.09.19 um 22:10 schrieb Bert Wesarg:
> The commit message widget does not wrap the next and has a configurable
> fixed width to avoid creating too wide commit messages. Though this was
> only enforced in the GUI. Now we also check the commit message at commit
> time for long lines
what is actually wrapped in the commit
> > message.
> > I believe the former is referred to as "soft wrap", while the latter
> > is "hard wrap".
> >
> >
> > On Thu, Sep 5, 2019 at 7:46 PM Bert Wesarg
> > wrote:
> > > Please ex
Hi Birger,
On 06/09/2019 15:08, Birger Skogeng Pedersen wrote:
Hi Bert,
We should probably distinguish between what is wrapped in git-gui
(i.e. purely visual), and what is actually wrapped in the commit
message.
I believe the former is referred to as "soft wrap", while the latte
Hi Bert,
We should probably distinguish between what is wrapped in git-gui
(i.e. purely visual), and what is actually wrapped in the commit
message.
I believe the former is referred to as "soft wrap", while the latter
is "hard wrap".
On Thu, Sep 5, 2019 at 7:46 PM Bert Wes
On Thu, Sep 5, 2019 at 8:50 AM Birger Skogeng Pedersen
wrote:
>
> On Thu, Sep 5, 2019 at 12:48 AM Pratyush Yadav wrote:
> > I'll chime in with what I think would be a great solution: auto word
> > wrapping. This way, the users can set the text width, and not have to
> > worry about manually forma
On Thu, Sep 5, 2019 at 8:22 AM Johannes Sixt wrote:
>
> Am 04.09.19 um 22:43 schrieb Bert Wesarg:
> > these people did not saw the entered text anyway. they would have
> > needed to change the option (default to 75 characters) to see what
> > they have typed. which could have been garbage to begin
On Thu, Sep 5, 2019 at 12:48 AM Pratyush Yadav wrote:
> I'll chime in with what I think would be a great solution: auto word
> wrapping. This way, the users can set the text width, and not have to
> worry about manually formatting it. Long "words" like URLs would still
> get to be on one line, and
Am 04.09.19 um 22:43 schrieb Bert Wesarg:
> these people did not saw the entered text anyway. they would have
> needed to change the option (default to 75 characters) to see what
> they have typed. which could have been garbage to begin with.
Huh? When I type overly long line, all text scrolls out
On 04/09/19 10:43PM, Bert Wesarg wrote:
[snip]
> > > fixed width to avoid creating too wide commit messages. Though
> > > this was
> > > only enforced in the GUI. Now we also check the commit message at commit
> > > time for long lines and ask the autho
On 04/09/19 09:39PM, Bert Wesarg wrote:
> On Tue, Sep 3, 2019 at 7:15 PM Pratyush Yadav wrote:
> >
> > On 02/09/19 09:13PM, Bert Wesarg wrote:
[snip]
> >
> > One more observation:
> >
> > If I write a particularly long line (and consequently the scrollbar
> > becomes active), and then hit Ctrl+A t
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be "empty". This test was introduced in commit
1fb5fdd25f0 ("rev-list: fix --pretty=oneline with empty
On Wed, Sep 4, 2019 at 10:30 PM Eric Sunshine wrote:
>
> On Wed, Sep 4, 2019 at 4:10 PM Bert Wesarg wrote:
> > The commit message widget does not wrap the next and has a configurable
>
> s/next/text/
fixed
>
> > fixed width to avoid creating too wide commit message
On Wed, Sep 4, 2019 at 4:10 PM Bert Wesarg wrote:
> The commit message widget does not wrap the next and has a configurable
s/next/text/
> fixed width to avoid creating too wide commit messages. Though this was
> only enforced in the GUI. Now we also check the commit message at comm
The commit message widget does not wrap the next and has a configurable
fixed width to avoid creating too wide commit messages. Though this was
only enforced in the GUI. Now we also check the commit message at commit
time for long lines and ask the author for confirmation if it exceeds the
On Tue, Sep 3, 2019 at 7:15 PM Pratyush Yadav wrote:
>
> On 02/09/19 09:13PM, Bert Wesarg wrote:
> > On Mon, Sep 2, 2019 at 9:03 PM Bert Wesarg
> > wrote:
> > >
> [snip]
> > > > On second thought, wouldn't it make more sense to expand the
> >
On 04/09/19 07:42AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
>
> Just wanted to chime in on this one:
>
> On Mon, Sep 2, 2019 at 8:58 PM Pratyush Yadav wrote:
> > On second thought, wouldn't it make more sense to expand the commit
> > message buffer
Hi Pratyush,
Just wanted to chime in on this one:
On Mon, Sep 2, 2019 at 8:58 PM Pratyush Yadav wrote:
> On second thought, wouldn't it make more sense to expand the commit
> message buffer instead? The point of resizing that pane is to see more
> of the commit message. So it ma
Elijah Newren writes:
> Ah, good catch. I checked out the commit before 1fb5fdd25f0
> ("rev-list: fix --pretty=oneline with empty message", 2010-03-21), to
> try and see the error before that testcase was introduced. I tried it
> on a repo with both an actual empty commit
On Tue, Sep 3, 2019 at 2:08 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Test t6006.71 ("oneline with empty message") was creating two commits
> > with simple commit messages, and then running filter-branch to rewrite
> > the commit messages to
Elijah Newren writes:
> Test t6006.71 ("oneline with empty message") was creating two commits
> with simple commit messages, and then running filter-branch to rewrite
> the commit messages to be empty. This test was written this way because
> the --allow-empty-message op
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be empty. This test was written this way because
the --allow-empty-message option to git commit did not exist at the
time.
On 02/09/19 09:13PM, Bert Wesarg wrote:
> On Mon, Sep 2, 2019 at 9:03 PM Bert Wesarg wrote:
> >
[snip]
> > > On second thought, wouldn't it make more sense to expand the
> > > commit
> > > message buffer instead? The point of resizing that pane is to se
Bert,
Works great now. Thanks a lot for fixing this!
Birger
ight pane of git gui, you should see that the
> > > > scrollbar remains at the bottom while the input area moves upwards.
> > >
> > > Yes, I can reproduce the problem when I do this. Interestingly, the
> > > vertical scrollbar does move, the horizontal one (wh
eproduce the problem when I do this. Interestingly, the
> > vertical scrollbar does move, the horizontal one (which Bert just added)
> > doesn't. So I think there is a slight difference in how the horizontal
> > scrollbar is set up that is causing this.
>
> On second t
oesn't. So I think there is a slight difference in how the horizontal
> scrollbar is set up that is causing this.
On second thought, wouldn't it make more sense to expand the commit
message buffer instead? The point of resizing that pane is to see more
of the commit message. S
On Mon, Sep 2, 2019 at 7:58 PM Bert Wesarg wrote:
> up to now, git-gui does not hide any scrollbars, if they are not
> needed. IMHO, I would keep it that way, as I don't like the flicker
> when it appears and disappears. Imagine you are typing in the bottom
> line and than you typed too much. The
On 02/09/19 08:22PM, Birger Skogeng Pedersen wrote:
> On Mon, Sep 2, 2019 at 8:05 PM Bert Wesarg wrote:
> > I cannot test windows easily, it looks good on Linux Tcl /Tk 8.6:
> >
> > https://kgab.selfhost.eu/s/f38GX4caCZBj4mZ
>
> On Mon, Sep 2, 2019 at 8:12 PM Pratyush Yadav wrote:
> > Hmm, it lo
On Mon, Sep 2, 2019 at 8:05 PM Bert Wesarg wrote:
> I cannot test windows easily, it looks good on Linux Tcl /Tk 8.6:
>
> https://kgab.selfhost.eu/s/f38GX4caCZBj4mZ
On Mon, Sep 2, 2019 at 8:12 PM Pratyush Yadav wrote:
> Hmm, it looks fine for me. Which platform are you using? I am running it
> o
omewhere, and that's why your patch has whitespace problems.
> Replacing the spaces with tabs before applying, I notice the
> horisontal scrollbar appears to be "outside" of the text input area.
> And it doesn't follow the height of the commit message text input
> ar
On Mon, Sep 2, 2019 at 7:35 PM Junio C Hamano wrote:
>
> Bert Wesarg writes:
>
> > the old reasoning was, that you should not create commit messages
> > which are too wide.
>
> True, and that reasoning would justify hiding scrollbar when not
> necessary to gain vertical space. Can we arrange the
Bert Wesarg writes:
> the old reasoning was, that you should not create commit messages
> which are too wide.
True, and that reasoning would justify hiding scrollbar when not
necessary to gain vertical space. Can we arrange the scrollbar to
appear only when needed?
type 100644, expected 100755
error: patch failed: git-gui.sh:3363
error: git-gui.sh: patch does not apply
Replacing the spaces with tabs before applying, I notice the
horisontal scrollbar appears to be "outside" of the text input area.
And it doesn't follow the height of the comm
Hi Elijah,
On Thu, 29 Aug 2019, Elijah Newren wrote:
> Despite only being one piece of the 71st test and there being 73 tests
> overall, this small change to just this one test speeds up the overall
> execution time of t6006 (as measured by the best of 3 runs of `time
> ./t6006-rev-list-format.sh
Hi Birger,
On Mon, Sep 2, 2019 at 11:13 AM Birger Skogeng Pedersen
wrote:
>
> Hi,
>
> I just noticed that long lines in the commit message widget does in
> fact not show a horizontal scrollbar.
> So if a line in the commit message is more than 75 characters, it gets
> a bi
Hi,
I just noticed that long lines in the commit message widget does in
fact not show a horizontal scrollbar.
So if a line in the commit message is more than 75 characters, it gets
a bit confusing.
Should it not have a scrollbar?
Example shown here: https://i.imgur.com/I3d6nBJ.png
Hi Junio,
On 30-08-2019 22:16, Junio C Hamano wrote:
> Ben Wijen writes:
>
>> -struct object_id head_oid;
>> -if (get_oid("HEAD", &head_oid)) {
>> -ret = error(_("could not determine HEAD
>> revision"));
>
> I think we saw die
Ben Wijen writes:
> @@ -1968,13 +1968,6 @@ int cmd_rebase(int argc, const char **argv, const char
> *prefix)
> state_dir_path("autostash", &options);
> struct child_process stash = CHILD_PROCESS_INIT;
> struct object_id oi
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-b
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-b
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be empty. This test was written this way because
the --allow-empty-message option to git commit did not exist at the
time.
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-b
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be empty. This test was written this way because
the --allow-empty-message option to git commit did not exist at the
time.
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be empty. This test was written this way because
the --allow-empty-message option to git commit did not exist at the
time.
On 8/26/2019 7:52 PM, Elijah Newren wrote:
> Test t6006.71 ("oneline with empty message") was creating two commits
> with simple commit messages, and then running filter-branch to rewrite
> the commit messages to be empty. This test was written this way because
> the --allo
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be empty. This test was written this way because
the --allow-empty-message option to git commit did not exist at the
time.
In cc8fdaee1e (banned.h: mark sprintf() as banned, 2018-07-24), both
'sprintf()' and 'vsprintf()' were marked as banned functions. The
non-variadic macro to ban 'vsprintf' has a typo which says that
'sprintf', not 'vsprintf' is banned. The variadic version does not have
the same typo.
Fix this by
Eric Sunshine writes:
> On Tue, Aug 13, 2019 at 2:04 PM SZEDER Gábor wrote:
>> To avoid data loss, 'git worktree remove' refuses to delete a worktree
>> if it's dirty or contains untracked files. However, the error message
>> only mentions that the worktree
On Tue, Aug 13, 2019 at 2:04 PM SZEDER Gábor wrote:
> To avoid data loss, 'git worktree remove' refuses to delete a worktree
> if it's dirty or contains untracked files. However, the error message
> only mentions that the worktree "is dirty", even if the workt
To avoid data loss, 'git worktree remove' refuses to delete a worktree
if it's dirty or contains untracked files. However, the error message
only mentions that the worktree "is dirty", even if the worktree in
question is in fact clean, but contains untracked files:
From: Jeff Hostetler
Avoid creating unnecessary trailing whitespace in normal
target format error messages when the message is omitted.
Signed-off-by: Jeff Hostetler
---
trace2/tr2_tgt_normal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/trace2/tr2_tgt_normal.c
From: Jeff Hostetler
Avoid creating unnecessary trailing whitespace in normal
target format error messages when the message is omitted.
Signed-off-by: Jeff Hostetler
---
trace2/tr2_tgt_normal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/trace2/tr2_tgt_normal.c
Jeff Hostetler writes:
> On 8/1/2019 5:34 PM, Junio C Hamano wrote:
>> "Jeff Hostetler via GitGitGadget" writes:
>>
>>> From: Jeff Hostetler
>>>
>>> Trim leading/trailing whitespace from the command line
>>> printed in
On 8/1/2019 5:34 PM, Junio C Hamano wrote:
"Jeff Hostetler via GitGitGadget" writes:
From: Jeff Hostetler
Trim leading/trailing whitespace from the command line
printed in the "start" message in the perf target format.
We use `sq_quote_argv_pretty()` to format the m
On 19-08-01 13:24:00, Junio C Hamano wrote:
Mateusz Loskot writes:
Is there any other way, without remembering to `git merge` with `--log`?
"git config merge.log true"?
That's sweet! Thank you
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Fingerprint=C081 EA1B 4AFB 7C19 38BA
Re-Cc:ing the Git mailing list.
Please make sure to keep the Git mailing list in Cc:. I get extremely
testy when I see mails asking me for personal help in private. As long
as others can learn from my answers, I am fine with helping. I stop
being fine when I feel like I am mistaken for a free-of-c
"Jeff Hostetler via GitGitGadget" writes:
> From: Jeff Hostetler
>
> Trim leading/trailing whitespace from the command line
> printed in the "start" message in the perf target format.
>
> We use `sq_quote_argv_pretty()` to format the message
> and it
Mateusz Loskot writes:
> Is there any other way, without remembering to `git merge` with `--log`?
"git config merge.log true"?
Hi,
When cherry-picking a merge with `cherry-pick -x -m 1 `,
is it possible to populate the log message with (short) log of all
commits that have been merged by the merge commit ?
The only workaround to copy the log messages along with
cherry-picked changes is to always merge copying all log
From: Jeff Hostetler
Trim leading/trailing whitespace from the command line
printed in the "start" message in the perf target format.
We use `sq_quote_argv_pretty()` to format the message
and it adds a leading space to the output. Trim that.
Signed-off-by: Jeff Hostetler
-
ohannes Schindelin schrieb am
> >> >>> 25.07.2019 um 12:07 in Nachricht
> >> >>> :
> >> >
> >> > On Wed, 24 Jul 2019, Ulrich Windl wrote:
> >> >
> >> >> When using "git merge ‑‑no‑ff ‑‑no‑commit ..", the pre‑created
> >
24 Jul 2019, Ulrich Windl wrote:
>> >
>> >> When using "git merge ‑‑no‑ff ‑‑no‑commit ..", the pre‑created
>> >> merge message always contains two empty lines in between the
>> >> comment lines. However if there was a merge conflict (being
>
From: Philip Oakley
The error message talked about a "lib option", but it clearly referred
to a link option.
Signed-off-by: Philip Oakley
Signed-off-by: Johannes Schindelin
---
contrib/buildsystems/engine.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Ulrich,
On Thu, 25 Jul 2019, Ulrich Windl wrote:
> >>> Johannes Schindelin schrieb am 25.07.2019 um
> 12:07
> in Nachricht :
> >
> > On Wed, 24 Jul 2019, Ulrich Windl wrote:
> >
> >> When using "git merge --no-ff --no-commit ..", the p
eem purely cosmetical, while being easy to fix (is my
guess):
>>
>> When using "git merge --no-ff --no-commit ..", the pre-created merge
message
>> always contains two empty lines in between the comment lines. However if
> there
>> was a merge conflict (being re
-commit ..", the pre-created merge message
> always contains two empty lines in between the comment lines. However if there
> was a merge conflict (being resolved) an extra blank line is added after the
> first line.
>
> In vi those empty lines are easy to spot, and I routinely rem
Hi!
I think I had tried bringing this to your attention before, but I think it was
without success.
The issue may seem purely cosmetical, while being easy to fix (is my guess):
When using "git merge --no-ff --no-commit ..", the pre-created merge message
always contains two empty lines
Johannes Schindelin writes:
> On Thu, 18 Jul 2019, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget"
>> writes:
>>
>> > From: Johannes Schindelin
>> >
>> > Without an error message when `lstat()` failed, `git clean
1 - 100 of 1938 matches
Mail list logo
