Max Nikulin writes:
> And changes made by this commit are included into diff shown for the
> merge commit 4f319088ba by cgit. E.g. gitk for local repository does not
> show any changes for the merge commit.
>
> So Matt did not squashed commits before committing to the main branch
> and
On 13/01/2023 22:23, Ihor Radchenko wrote:
Matt writes:
Would you like me to correct how I've incorporated my changes?
No. I was referring to the initial situation with a single commit being
displayed.
I am not sure what Max was trying to point out.
Look at the commit message for
Matt writes:
> On Fri, 13 Jan 2023 04:36:40 -0500 Ihor Radchenko wrote ---
> > Cgit displays our bugfix merges with all the required commits.
> > So, what happened what not ideal either way.
>
> Would you like me to correct how I've incorporated my changes?
No. I was referring to
On Fri, 13 Jan 2023 04:36:40 -0500 Ihor Radchenko wrote ---
> Cgit displays our bugfix merges with all the required commits.
> So, what happened what not ideal either way.
Would you like me to correct how I've incorporated my changes?
Max Nikulin writes:
>> It looks like you lost all the individual commits and commit messages in
>> the process.
>
> Ihor, it is usual merge commit of a branch with multiple commits. Cgit
> shows combined changes, but commits was not squashed. The branch started at
>
On 12/01/2023 00:02, Ihor Radchenko wrote:
I was not, thank you. I've since pushed.
This:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4f319088ba5f11d4b6adf808f39f11dfa52c08e4
?
It looks like you lost all the individual commits and commit messages in
the process.
Ihor,
Matt writes:
> On Wed, 11 Jan 2023 12:02:42 -0500 Ihor Radchenko wrote ---
> > It looks like you lost all the individual commits and commit messages in
> > the process.
> >
> > Could you please revert 4f319088ba5 and re-push in such a way that
> > individual commits do appear on
On Wed, 11 Jan 2023 12:02:42 -0500 Ihor Radchenko wrote ---
> It looks like you lost all the individual commits and commit messages in
> the process.
>
> Could you please revert 4f319088ba5 and re-push in such a way that
> individual commits do appear on main?
Goodness! Sorry!
Matt writes:
> I was not, thank you. I've since pushed.
This:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4f319088ba5f11d4b6adf808f39f11dfa52c08e4
?
It looks like you lost all the individual commits and commit messages in
the process.
Could you please revert 4f319088ba5
On Wed, 11 Jan 2023 06:53:41 -0500 Ihor Radchenko wrote ---
> I have the following Git configuration:
>
> u remote.origin.url
> yanta...@git.savannah.gnu.org:/srv/git/emacs/org-mode.git
>
> Are you using the same?
I was not, thank you. I've since pushed.
Matt writes:
> On Thu, 05 Jan 2023 06:21:16 -0500 Bastien Guerry wrote ---
> > My bad: I did not warn Emacs maintainers in time. Now it is done,
> > I will let you know when they grand you access to the Emacs project.
>
> I got an email from Eli on Thursday saying I was added. I've
On Thu, 05 Jan 2023 06:21:16 -0500 Bastien Guerry wrote ---
> My bad: I did not warn Emacs maintainers in time. Now it is done,
> I will let you know when they grand you access to the Emacs project.
I got an email from Eli on Thursday saying I was added. I've still been
getting an
Ihor Radchenko writes:
>> I'm not able to push to git://git.sv.gnu.org/emacs/org-mode.git.
My bad: I did not warn Emacs maintainers in time. Now it is done,
I will let you know when they grand you access to the Emacs project.
--
Bastien
Matt writes:
> > Feel free to push upstream.
>
> I'm not able to push to git://git.sv.gnu.org/emacs/org-mode.git.
>
> I've read through the following and, as far as I can tell, I've followed the
> directions.
>
> - https://orgmode.org/worg/org-contribute.html
> -
Ihor Radchenko writes:
>> Is there a way to see the definition of`org-babel-execute:csh' using the
>> current `org-babel-shell-initialize', that is, when generated by a function?
>
> https://github.com/Wilfred/helpful displays the function code in such
> scenario. Probably, I need to raise this
On Tue, 03 Jan 2023 05:50:17 -0500 Ihor Radchenko wrote ---
> I was mostly worried about session states affecting subsequent test
> invocations. But I do agree that it may be better to keep them.
That makes sense. I tend to run tests one at a time unless I'm about to submit
patches
Matt writes:
> On Mon, 02 Jan 2023 04:47:10 -0500 Ihor Radchenko wrote ---
> > They will not be reliable when tests are executed interactively.
> > If the `should' condition fails, `kill-buffer' will never be executed
> > leaving dirty state, especially for sessions.
>
> From my
Matt writes:
> On Sat, 31 Dec 2022 07:56:10 -0500 Ihor Radchenko wrote ---
> > As for being a macro, there will be not much gain - the convention is
> > mostly designed for things like `cl-defun' aimed to be used in the code.
> > `org-babel-shell-initialize' is only used by
On Mon, 02 Jan 2023 04:47:10 -0500 Ihor Radchenko wrote ---
> They will not be reliable when tests are executed interactively.
> If the `should' condition fails, `kill-buffer' will never be executed
> leaving dirty state, especially for sessions.
>From my perspective, that's the
Matt writes:
> If this set of patches look good, I can push them to main.
Just one more comment.
You are using constructs like
(if (should ...)
(kill-buffer ...))
They will not be reliable when tests are executed interactively.
If the `should' condition fails, `kill-buffer' will never be
On Sat, 31 Dec 2022 07:56:10 -0500 Ihor Radchenko wrote ---
> As for being a macro, there will be not much gain - the convention is
> mostly designed for things like `cl-defun' aimed to be used in the code.
> `org-babel-shell-initialize' is only used by `org-babel-shell-names'.
I'm
On Sat, 31 Dec 2022 09:31:16 -0500 Ihor Radchenko wrote ---
> Matt m...@excalamus.com> writes:
>
> > I've backed out the `require' change and adjusted everything else based on
> > your feedback. There is a separate patch for each refactor that created a
> > new test. The
Matt writes:
> I've backed out the `require' change and adjusted everything else based on
> your feedback. There is a separate patch for each refactor that created a
> new test. The remaining refactors are in a single patch. I was also able
> to resolve the issue I had with inserting the
Matt writes:
> > > +;; TODO refactor into macro. Currently violates (elisp) Coding
> > > +;; Conventions and is hard to debug.
> > > (defun org-babel-shell-initialize ()
> > >"Define execution functions associated to shell names.
> >
> > Could you please elaborate? Which particular
On Fri, 30 Dec 2022 00:34:38 -0500 Matt wrote ---
>
> On Thu, 29 Dec 2022 06:08:59 -0500 Ihor Radchenko wrote ---
> > > From: Matt Trzcinski m...@excalamus.com>
> > > +(require 'org-test (expand-file-name "../org-test.el"))
> >
> > I am unsure here. What will happen
Hi Matthew,
Matt writes:
> You're correct, I've not contributed to core. I would love to
> maintain lisp/ob-shell.el.
Your wish has been granted:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e8ceb4a2
> I'm expecting life changes in the coming
> months and can't anticipate
On Thu, 29 Dec 2022 06:08:59 -0500 Ihor Radchenko wrote ---
> Does it mean that you are willing to maintain lisp/ob-shell.el?
> We usually give write access to the maintainers and regular
> contributors. AFAIR, you previously contributed to WORG but not to Org
> core.
You're
Ihor Radchenko writes:
> Bastien, could you please check Matt's copyright paperwork record in
> FSF?
Matt's copyright paperwork are OK, I added him as FSF-copyrighted
contributor on Worg.
> Does it mean that you are willing to maintain lisp/ob-shell.el?
Until Matt wants to be the maintainer
Bastien, could you please check Matt's copyright paperwork record in
FSF?
Matt writes:
> On Wed, 21 Dec 2022 01:17:50 -0500 Matt wrote ---
>
> > Currently, though, I'm refactoring the ob-shell tests to remove dependency
> on ob-shell-test.org and to stop the suite from littering.
>
On Wed, 21 Dec 2022 01:17:50 -0500 Matt wrote ---
> Currently, though, I'm refactoring the ob-shell tests to remove dependency
> on ob-shell-test.org and to stop the suite from littering.
Done. Branched off bugfix, 12e10eb0d, and refactored test-ob-shell.el. See
attached
On Fri, 16 Dec 2022 12:41:45 -0500 Ihor Radchenko wrote ---
> We really need more tests.
I'm working on giving ob-shell a little bit of love. I wrote the worg
documentation for it earlier this year. I tried to include examples of all
coded functionality, including previously
31 matches
Mail list logo
