all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Ok to backport Eshell manual improvements to 29?
@ 2023-07-13  1:52 Jim Porter
  2023-07-13  7:14 ` Michael Albinus
  0 siblings, 1 reply; 8+ messages in thread
From: Jim Porter @ 2023-07-13  1:52 UTC (permalink / raw)
  To: emacs-devel

I just pushed a branch - "scratch/backport-eshell-docs-to-29" - that 
backports all the relevant changes to the Eshell manual that are 
currently on master. I've double-checked that the documentation all 
looks right to me (specifically that the 29 branch doesn't mention any 
features only present on master), but before I merge to the 29 branch, I 
wanted to give others the chance to look over the changes too.

I've opted not to squash any of the commits and to add a note to each 
commit message indicating the Git SHA for each master commit. Hopefully 
that will make it easier if anyone needs to look back on these commits 
in the future.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Ok to backport Eshell manual improvements to 29?
  2023-07-13  1:52 Ok to backport Eshell manual improvements to 29? Jim Porter
@ 2023-07-13  7:14 ` Michael Albinus
  2023-07-13 16:10   ` Jim Porter
  0 siblings, 1 reply; 8+ messages in thread
From: Michael Albinus @ 2023-07-13  7:14 UTC (permalink / raw)
  To: Jim Porter; +Cc: emacs-devel

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> I just pushed a branch - "scratch/backport-eshell-docs-to-29" - that
> backports all the relevant changes to the Eshell manual that are
> currently on master. I've double-checked that the documentation all
> looks right to me (specifically that the 29 branch doesn't mention any
> features only present on master), but before I merge to the 29 branch,
> I wanted to give others the chance to look over the changes too.
>
> I've opted not to squash any of the commits and to add a note to each
> commit message indicating the Git SHA for each master
> commit. Hopefully that will make it easier if anyone needs to look
> back on these commits in the future.

I haven't checked each commit. Just a diff between eshell.texi in master
and scratch/backport-eshell-docs-to-29. One minor nit: in node
Variables, you have deleted "@vindex $INSIDE_EMACS". Pls keep it.

Otherwise, it LGTM.

Best regards, Michael.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Ok to backport Eshell manual improvements to 29?
  2023-07-13  7:14 ` Michael Albinus
@ 2023-07-13 16:10   ` Jim Porter
  2023-07-14  2:26     ` Jim Porter
  0 siblings, 1 reply; 8+ messages in thread
From: Jim Porter @ 2023-07-13 16:10 UTC (permalink / raw)
  To: Michael Albinus; +Cc: emacs-devel

On 7/13/2023 12:14 AM, Michael Albinus wrote:
> I haven't checked each commit. Just a diff between eshell.texi in master
> and scratch/backport-eshell-docs-to-29. One minor nit: in node
> Variables, you have deleted "@vindex $INSIDE_EMACS". Pls keep it.

Thanks for the catch. That was apparently fixed in commit 0bb8a011d5 on 
master (which added 'file-user-uid' and the special Eshell '$UID' 
variable). I didn't cherry-pick that patch, since it was a new feature; 
I'll just fix that in a separate commit for 29.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Ok to backport Eshell manual improvements to 29?
  2023-07-13 16:10   ` Jim Porter
@ 2023-07-14  2:26     ` Jim Porter
  2023-07-14  7:10       ` Juri Linkov
  0 siblings, 1 reply; 8+ messages in thread
From: Jim Porter @ 2023-07-14  2:26 UTC (permalink / raw)
  To: Michael Albinus; +Cc: emacs-devel

On 7/13/2023 9:10 AM, Jim Porter wrote:
> Thanks for the catch. That was apparently fixed in commit 0bb8a011d5 on 
> master (which added 'file-user-uid' and the special Eshell '$UID' 
> variable). I didn't cherry-pick that patch, since it was a new feature; 
> I'll just fix that in a separate commit for 29.

Now merged to the emacs-29 branch as 6a360b08405.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Ok to backport Eshell manual improvements to 29?
  2023-07-14  2:26     ` Jim Porter
@ 2023-07-14  7:10       ` Juri Linkov
  2023-07-14  7:22         ` Eli Zaretskii
  2023-07-14 16:29         ` Jim Porter
  0 siblings, 2 replies; 8+ messages in thread
From: Juri Linkov @ 2023-07-14  7:10 UTC (permalink / raw)
  To: Jim Porter; +Cc: emacs-devel

> Now merged to the emacs-29 branch as 6a360b08405.

Is there a policy that requires deleting a merged branch?
(I'm asking because it was very convenient to type just "-29"
to complete to the "emacs-29" branch, but now the name
"backport-eshell-docs-to-29" gets in the way ;-)



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Ok to backport Eshell manual improvements to 29?
  2023-07-14  7:10       ` Juri Linkov
@ 2023-07-14  7:22         ` Eli Zaretskii
  2023-07-14 16:29         ` Jim Porter
  1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2023-07-14  7:22 UTC (permalink / raw)
  To: Juri Linkov; +Cc: jporterbugs, emacs-devel

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Fri, 14 Jul 2023 10:10:13 +0300
> 
> > Now merged to the emacs-29 branch as 6a360b08405.
> 
> Is there a policy that requires deleting a merged branch?

They should be deleted eventually, but we don't require them to be
deleted as soon as they land on the main branches.  It is up to the
branch owner to decide when to delete the branch; there could be
reasons to wait for some short time, like if any leftovers are
anticipated that are easier handled on the branch.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Ok to backport Eshell manual improvements to 29?
  2023-07-14  7:10       ` Juri Linkov
  2023-07-14  7:22         ` Eli Zaretskii
@ 2023-07-14 16:29         ` Jim Porter
  2023-07-14 16:52           ` Juri Linkov
  1 sibling, 1 reply; 8+ messages in thread
From: Jim Porter @ 2023-07-14 16:29 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

On 7/14/2023 12:10 AM, Juri Linkov wrote:
> Is there a policy that requires deleting a merged branch?
> (I'm asking because it was very convenient to type just "-29"
> to complete to the "emacs-29" branch, but now the name
> "backport-eshell-docs-to-29" gets in the way ;-)

I deleted my scratch branch right after merging it[1]. Maybe you just 
need to call something like `git remote prune origin` to clean up your 
local references to the branch?

[1] https://lists.gnu.org/archive/html/emacs-diffs/2023-07/msg00305.html



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Ok to backport Eshell manual improvements to 29?
  2023-07-14 16:29         ` Jim Porter
@ 2023-07-14 16:52           ` Juri Linkov
  0 siblings, 0 replies; 8+ messages in thread
From: Juri Linkov @ 2023-07-14 16:52 UTC (permalink / raw)
  To: Jim Porter; +Cc: emacs-devel

>> Is there a policy that requires deleting a merged branch?
>> (I'm asking because it was very convenient to type just "-29"
>> to complete to the "emacs-29" branch, but now the name
>> "backport-eshell-docs-to-29" gets in the way ;-)
>
> I deleted my scratch branch right after merging it[1]. Maybe you just need
> to call something like `git remote prune origin` to clean up your local
> references to the branch?

Thanks, this helped.  I don't remember using this command before,
but maybe because I always used `git fetch -p origin`.



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-07-14 16:52 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-13  1:52 Ok to backport Eshell manual improvements to 29? Jim Porter
2023-07-13  7:14 ` Michael Albinus
2023-07-13 16:10   ` Jim Porter
2023-07-14  2:26     ` Jim Porter
2023-07-14  7:10       ` Juri Linkov
2023-07-14  7:22         ` Eli Zaretskii
2023-07-14 16:29         ` Jim Porter
2023-07-14 16:52           ` Juri Linkov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.