Re: Progress on merging Eglot?

Re: Progress on merging Eglot?

[Payas Relekar]

João Távora <joaotavora@gmail.com> writes:

> [Sorry, I took part of this conversation off-list by mistake.  Bringing it
> back.]
>
> Cool, I'll put you down for item 2 then!  I recommend the tool
> https://github.com/newren/git-filter-repo.  Here's an example of how it's
> used.
>
> https://stackoverflow.com/questions/60863773/git-bulk-change-of-commit-dates
>
> This tool seems to be preferred over `git filter-branch` nowadays and is
> easy to
> combine with whatever scripting language you're comfortable with.
>
> I've used one of the two in the past (can't remember which).  There are
> others, so choose your poison. I also vaguely  remember that running the
> script on windows was about a million times slower than on a GNU/linux
> box.
> Also not sure if that holds anymore.
>
> So the inputs should be Eglot's main repo (master branch) and some branch
> of the emacs.git repo.  The output should be something like a new
> lisp/progmodes/eglot.el added and then some 900+ commits on top of it.
> Place this on a git branch somewhere so we can look at it.
>
> We'll probably need to make adjustments, so make sure to post the script
> somewhere with instructions on how to use it.

Thanks a ton for pointers! I think I got most of it down, if any more
questions, will reach back out.

One thing I'm thinking is, is there any possibility of PRs being
referred in commit messages? If so, the */issues/num won't work, and
*/pulls/num will have to be used. That means probably involving curl.

This looks fun :)

--
Payas
--

Re: Progress on merging Eglot?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Thu, Sep 8, 2022 at 6:03 PM Payas Relekar <relekarpayas@gmail.com> wrote:


> One thing I'm thinking is, is there any possibility of PRs being
> referred in commit messages? If so, the */issues/num won't work, and
> */pulls/num will have to be used. That means probably involving curl.
>

But I think GitHub automatically redirects "issues" -> "pulls"

So if you want to be super clean and heroic, yes do the curl scraping.
Could be useful that day GitHub is no more and we need the wayback
machine to read the discussion.

But don't let that block you either.


> This looks fun :)


Thanks a lot for your help!

João

[-- Attachment #2: Type: text/html, Size: 1263 bytes --]

Re: Progress on merging Eglot?

[Payas Relekar]

João Távora <joaotavora@gmail.com> writes:

> On Thu, Sep 8, 2022 at 6:03 PM Payas Relekar <relekarpayas@gmail.com> wrote:
>
>
>> One thing I'm thinking is, is there any possibility of PRs being
>> referred in commit messages? If so, the */issues/num won't work, and
>> */pulls/num will have to be used. That means probably involving curl.
>>
>
> But I think GitHub automatically redirects "issues" -> "pulls"

That's convenient :)

> So if you want to be super clean and heroic, yes do the curl scraping.
> Could be useful that day GitHub is no more and we need the wayback
> machine to read the discussion.

I think I'll stay clear of heroics for v0, perhaps stretch goal later..

> But don't let that block you either.
>
>
>> This looks fun :)
>
>
> Thanks a lot for your help!

Okay, some dumb questions to boot. I see eglot repo has below relevant files:

1. .dir-locals.el
2. Makefile
3. NEWS.md
4. eglot-tests.el
5. eglot.el

From your description above, I see we only care about #4 and #5, is that
correct? Any of the files omitted here (gifs and .gitignore etc) relevant?

I took a quick skim and there are some commits with `* Makefile', can
these be safely ignored? If we are skipping NEWS.md and .dir-locals.el
files, can we skip commits that are limited to them as well?


Thanks,
Payas
--

Re: Progress on merging Eglot?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Thu, Sep 8, 2022 at 6:12 PM Payas Relekar <relekarpayas@gmail.com> wrote:

> Thanks a lot for your help!
>
> Okay, some dumb questions to boot. I see eglot repo has below relevant
> files:
>
> 1. .dir-locals.el
> 2. Makefile
> 3. NEWS.md
> 4. eglot-tests.el
> 5. eglot.el


I'd say focus just on keeping the history of eglot.el.  The history of
eglot-tests.el would
be nice too, but nowhere as important as eglot.el.

Don't worry about the other files.

João

[-- Attachment #2: Type: text/html, Size: 905 bytes --]

Re: Progress on merging Eglot?

[Payas Relekar]

João Távora <joaotavora@gmail.com> writes:

> On Thu, Sep 8, 2022 at 6:12 PM Payas Relekar <relekarpayas@gmail.com> wrote:
>
>> Thanks a lot for your help!
>>
>> Okay, some dumb questions to boot. I see eglot repo has below relevant
>> files:
>>
>> 1. .dir-locals.el
>> 2. Makefile
>> 3. NEWS.md
>> 4. eglot-tests.el
>> 5. eglot.el
>
>
> I'd say focus just on keeping the history of eglot.el.  The history of
> eglot-tests.el would
> be nice too, but nowhere as important as eglot.el.
>
> Don't worry about the other files.
>
> João

Very well. Thank you!

Will get back once there is some progress.

--
Payas

--

Re: Progress on merging Eglot?

[Payas Relekar]

Hello,

A bit later than I expected, but $LIFE and all..

I made a naive attempt to get eglot.el into emacs with history (took too
long to call it QnD, but its definitely dirty).

Here's the steps I followed:

***
# move to a directory where both repos can be cloned
cd ~/git

# clone repos
git clone https://github.com/joaotavora/eglot.git

git clone git clone -b master git://git.sv.gnu.org/emacs.git

# filter eglot with only eglot.el and find+replace # in commit messages
git filter-repo --path eglot.el --message-callback '
      return re.sub(b" #", b" https://github.com/joaotavora/eglot/issues/", message)
      return re.sub(b",#", b",https://github.com/joaotavora/eglot/issues/", message)
      return re.sub(b"(#", b"(https://github.com/joaotavora/eglot/issues/", message)
      return re.sub(b"Fix#", b"Fix: https://github.com/joaotavora/eglot/issues/", message)
      return re.sub(b"github#", b"Github: https://github.com/joaotavora/eglot/issues/", message)
      '

# back to emacs repo
cd ../emacs

# add filtered eglot as upstream
git remote add eglot ../eglot/

git fetch eglot master

# prepare emacs repo for merge
git merge remotes/eglot/master --allow-unrelated-histories --no-commit

# reset eglot to initial commit
cd ../eglot && git reset --hard 4970e7e1b605510c665c52bc1ddd83bcd1e255d4

# merge by pushing eglot.el into lisp/progmodes/
cd ../emacs && git read-tree --prefix=lisp/progmodes/ -u eglot/master

# make a commit
git commit -m "; Merge from joaotavora/eglot"

# push eglot to latest
cd ../eglot && git reset --hard 2f9cf0dcfb2d37f45ec8b9ea65ac9063da033b70

# pull all eglot history to emacs
cd ../emacs && git pull -s subtree eglot master
--allow-unrelated-histories
***

This is the repo I pushed for you to see:
https://github.com/bhankas/emacs/commits/master

There are couple of glaring issues with this:

1. commit message length is not validated, but can be part of 'git filter-repo' script
2. history does not show for eglot.el or lisp/progmodes, but only as part
  of entire emacs repo

I'm kinda unsure where to go from here, for #1 I can definitely use some
help, my bash skills are primitive at best.

As for #2, I've tried quite a few solutions after scouring Google  and
this seems to be the least bad. Another approach was to export patches
from our filtered eglot repo and apply them to particular file in emacs
repo, but that way leads to many many merge conflicts, that I am unsure
how to resolve automatically. I'll be happy to provide the patches to
anybody if it can help.

Further help appreciated.

Thanks,
Payas

Payas Relekar <relekarpayas@gmail.com> writes:

> João Távora <joaotavora@gmail.com> writes:
> I'd say focus just on keeping the history of eglot.el.  The history of
>> eglot-tests.el would
>> be nice too, but nowhere as important as eglot.el.
>>
>> Don't worry about the other files.
>>
>> João
>
> Very well. Thank you!
>
> Will get back once there is some progress.

--

Re: Progress on merging Eglot?

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> There are couple of glaring issues with this:
>
> 1. commit message length is not validated, but can be part of 'git filter-repo' script

A script to do the job might not be trivial, but I think you write
something "good enough", then manually fix anything that the rough
attempt missed. 

> 2. history does not show for eglot.el or lisp/progmodes, but only as part
>   of entire emacs repo

I know that João said he didn't want to discuss the topic, but I'll say
it anyway.  The necessity to preserve the history seems superfluous to
me.  emacs.git has projects like Org or the Modus Themes that are
developed out of tree and are regularly synchronised back without any
major issues.

It seems to me that this is an unnecessary hindrance towards merging
Eglot, that might be nice to have but is really stretching what you can
do with Git.

Re: Progress on merging Eglot?

[Dmitry Gutov]

On 18.09.2022 23:30, Philip Kaludercic wrote:
>> 2. history does not show for eglot.el or lisp/progmodes, but only as part
>>    of entire emacs repo
> I know that João said he didn't want to discuss the topic, but I'll say
> it anyway.  The necessity to preserve the history seems superfluous to
> me.  emacs.git has projects like Org or the Modus Themes that are
> developed out of tree and are regularly synchronised back without any
> major issues.

Org is still being developed out of tree, though. So any history digs 
are probably going to occur in its own repo.

IIUC, Joao want to move Eglot entirely into Emacs and be done with 
github at some soon-ish point.

Re: Progress on merging Eglot?

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 18.09.2022 23:30, Philip Kaludercic wrote:
>>> 2. history does not show for eglot.el or lisp/progmodes, but only as part
>>>    of entire emacs repo
>> I know that João said he didn't want to discuss the topic, but I'll say
>> it anyway.  The necessity to preserve the history seems superfluous to
>> me.  emacs.git has projects like Org or the Modus Themes that are
>> developed out of tree and are regularly synchronised back without any
>> major issues.
>
> Org is still being developed out of tree, though. So any history digs
> are probably going to occur in its own repo.

> IIUC, Joao want to move Eglot entirely into Emacs and be done with
> github at some soon-ish point.

I am not sure about that, in his message he wrote the following:

    5. Arrange for the eglot.el file in Eglot's current upstream --
       https://github.com/joaotavora/eglot -- to mirror
       src/progmodes/eglot.el, ideally (but not necessarily) automatically

       This is so that:

       5.1 Users of bare Git clones can continue mostly unimpeded.

       5.2 GitHub users can still suggest changes as "Pull Requests"
           via GitHub's interface

       5.3 The current GitHub actions CI -- where installation of third-party
           language servers is relatively easy -- can run at least the current
           eglot-tests.el.

Maybe there would be a point in "copying" the history into emacs.git,
but this is a continuous process that would have to be synchronised on
both sides (emacs.git and GitHub) all the time.  That sounds like more
effort than the history is worth.

Re: Progress on merging Eglot?

[Dmitry Gutov]

On 19.09.2022 00:00, Philip Kaludercic wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> On 18.09.2022 23:30, Philip Kaludercic wrote:
>>>> 2. history does not show for eglot.el or lisp/progmodes, but only as part
>>>>     of entire emacs repo
>>> I know that João said he didn't want to discuss the topic, but I'll say
>>> it anyway.  The necessity to preserve the history seems superfluous to
>>> me.  emacs.git has projects like Org or the Modus Themes that are
>>> developed out of tree and are regularly synchronised back without any
>>> major issues.
>> Org is still being developed out of tree, though. So any history digs
>> are probably going to occur in its own repo.
>> IIUC, Joao want to move Eglot entirely into Emacs and be done with
>> github at some soon-ish point.
> I am not sure about that, in his message he wrote the following:
> 
>      5. Arrange for the eglot.el file in Eglot's current upstream --
>         https://github.com/joaotavora/eglot  -- to mirror
>         src/progmodes/eglot.el, ideally (but not necessarily) automatically
> 
>         This is so that:
> 
>         5.1 Users of bare Git clones can continue mostly unimpeded.
> 
>         5.2 GitHub users can still suggest changes as "Pull Requests"
>             via GitHub's interface
> 
>         5.3 The current GitHub actions CI -- where installation of third-party
>             language servers is relatively easy -- can run at least the current
>             eglot-tests.el.
> 
> Maybe there would be a point in "copying" the history into emacs.git,
> but this is a continuous process that would have to be synchronised on
> both sides (emacs.git and GitHub) all the time.  That sounds like more
> effort than the history is worth.

Maybe I misunderstood, then.

But if the full move is never going to happen, I think the elpa-bundling 
approach seems like a better option all-around. It just need a little 
more work and (perhaps significantly) more attention from the maintainers.

Re: Progress on merging Eglot?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

On Sun, Sep 18, 2022 at 10:11 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 19.09.2022 00:00, Philip Kaludercic wrote:
> > Dmitry Gutov<dgutov@yandex.ru>  writes:
>
> Maybe I misunderstood, then.


You didn't.

[-- Attachment #2: Type: text/html, Size: 591 bytes --]

Re: Progress on merging Eglot?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

Dmitry is right. The goal is to be done with GitHub soonish. Soonish
meaning phased.

Philip, this is item number 5.  Not only is it secondary to item 2, which
Payas is handling, but
it has to be handled after 2 is done.

So, once Eglot's mainline is the same as Emacs's, I will find some way for
the
current Github repo to somehow mirror only that part of Emacs.  Of course
by
force-pushing to the current repo.  This will be a "best effort thing".  If
it's a dump copy
of eglot.el from emacs.git -> git@github.com:joaotavora/eglot every 24h
then I'm perfectly
happy.  If something more sophisticated can be done, so much the better.
Regardless,
keeping history in that repo is not important because it won't be the
upstream by then.

Maybe there would be a point in "copying" the history into emacs.git,
> but this is a continuous process that would have to be synchronised on
> both sides (emacs.git and GitHub) all the time.  That sounds like more
> effort than the history is worth.
>

That's not the plan.  But if that _were_ the plan, then I can think of no
better
arguments than keeping history.  Good (Git) history is a benediction that
should
be preserved at (almost) all costs.

João Távora

[-- Attachment #2: Type: text/html, Size: 1745 bytes --]

Re: Progress on merging Eglot?

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

>> but this is a continuous process that would have to be synchronised on
>> both sides (emacs.git and GitHub) all the time.  That sounds like more
>> effort than the history is worth.
>>
>
> That's not the plan.  But if that _were_ the plan, then I can think of no
> better
> arguments than keeping history.  

In that case my apologies, I had misunderstood.

>                                  Good (Git) history is a benediction that
> should
> be preserved at (almost) all costs.
>
> João Távora

Re: Progress on merging Eglot?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

On Sun, Sep 18, 2022 at 10:20 PM Philip Kaludercic <philipk@posteo.net>
wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> >> but this is a continuous process that would have to be synchronised on
> >> both sides (emacs.git and GitHub) all the time.  That sounds like more
> >> effort than the history is worth.
> > That's not the plan.
> In that case my apologies, I had misunderstood.
>

No need to apologize, of course!

João

[-- Attachment #2: Type: text/html, Size: 877 bytes --]

Re: Progress on merging Eglot?

[Stefan Monnier]

> # filter eglot with only eglot.el and find+replace # in commit messages
> git filter-repo --path eglot.el --message-callback '
>       return re.sub(b" #", b" https://github.com/joaotavora/eglot/issues/", message)
>       return re.sub(b",#", b",https://github.com/joaotavora/eglot/issues/", message)
>       return re.sub(b"(#", b"(https://github.com/joaotavora/eglot/issues/", message)
>       return re.sub(b"Fix#", b"Fix: https://github.com/joaotavora/eglot/issues/", message)
>       return re.sub(b"github#", b"Github: https://github.com/joaotavora/eglot/issues/", message)

I suspect you can get a slightly better result if you tweak this filter
script so as to rename `eglot.el` to `lisp/progmodes/eglot.el` in each commit.

Then you can also skip the `git read-tree`.


        Stefan

Re: Progress on merging Eglot?

[Payas Relekar]

Thank you! Indeed moving to subdirectory makes history apply to
correct file and shows up as expected. Was also quite straightforward
with git-filter-repo, so here's the updates:

Updates gist:
https://gist.github.com/bhankas/422c34db2e987d4dc3f243e26ba156a3

Updated repo:
https://github.com/bhankas/emacs

Updated history:
https://github.com/bhankas/emacs/commits/master/lisp/progmodes/eglot.el

Now the only remaining issue is commit length. Can someone please
advice on how we can go about it? My brute force thinking is to simply
add newline where length exceeds, delimited at word boundary, but
obviously that's not good enough nor covers sufficient edge cases.
Perhaps a Python/Perl wizard has a one/two liner to take that pain
away?

Thanks,
Payas

On Mon, 19 Sep, 2022, 08:08 Stefan Monnier, <monnier@iro.umontreal.ca> wrote:
>
> > # filter eglot with only eglot.el and find+replace # in commit messages
> > git filter-repo --path eglot.el --message-callback '
> >       return re.sub(b" #", b" https://github.com/joaotavora/eglot/issues/", message)
> >       return re.sub(b",#", b",https://github.com/joaotavora/eglot/issues/", message)
> >       return re.sub(b"(#", b"(https://github.com/joaotavora/eglot/issues/", message)
> >       return re.sub(b"Fix#", b"Fix: https://github.com/joaotavora/eglot/issues/", message)
> >       return re.sub(b"github#", b"Github: https://github.com/joaotavora/eglot/issues/", message)
>
> I suspect you can get a slightly better result if you tweak this filter
> script so as to rename `eglot.el` to `lisp/progmodes/eglot.el` in each commit.
>
> Then you can also skip the `git read-tree`.
>
>
>         Stefan
>

Re: Progress on merging Eglot?

[Payas Relekar]

Another way I can think of is to keep #nums where they are right now,
but add their respective links in the message body below.

e.g.
Fixes #234,#456

this fixes two issues

Becomes =>

Fixes #234,#456

this fixes two issues
#234: https://github.com/joaotavora/eglot/234
#456: https://github.com/joaotavora/eglot/456

Inputs welcome, since this is not 100% convenient, but much simpler to
implement, with minimal to none manual readjustment needed.

Thanks,
Payas

On 9/19/22, Payas Relekar <relekarpayas@gmail.com> wrote:
> Thank you! Indeed moving to subdirectory makes history apply to
> correct file and shows up as expected. Was also quite straightforward
> with git-filter-repo, so here's the updates:
>
> Updates gist:
> https://gist.github.com/bhankas/422c34db2e987d4dc3f243e26ba156a3
>
> Updated repo:
> https://github.com/bhankas/emacs
>
> Updated history:
> https://github.com/bhankas/emacs/commits/master/lisp/progmodes/eglot.el
>
> Now the only remaining issue is commit length. Can someone please
> advice on how we can go about it? My brute force thinking is to simply
> add newline where length exceeds, delimited at word boundary, but
> obviously that's not good enough nor covers sufficient edge cases.
> Perhaps a Python/Perl wizard has a one/two liner to take that pain
> away?
>
> Thanks,
> Payas
>
> On Mon, 19 Sep, 2022, 08:08 Stefan Monnier, <monnier@iro.umontreal.ca>
> wrote:
>>
>> > # filter eglot with only eglot.el and find+replace # in commit messages
>> > git filter-repo --path eglot.el --message-callback '
>> >       return re.sub(b" #", b"
>> > https://github.com/joaotavora/eglot/issues/", message)
>> >       return re.sub(b",#",
>> > b",https://github.com/joaotavora/eglot/issues/", message)
>> >       return re.sub(b"(#",
>> > b"(https://github.com/joaotavora/eglot/issues/", message)
>> >       return re.sub(b"Fix#", b"Fix:
>> > https://github.com/joaotavora/eglot/issues/", message)
>> >       return re.sub(b"github#", b"Github:
>> > https://github.com/joaotavora/eglot/issues/", message)
>>
>> I suspect you can get a slightly better result if you tweak this filter
>> script so as to rename `eglot.el` to `lisp/progmodes/eglot.el` in each
>> commit.
>>
>> Then you can also skip the `git read-tree`.
>>
>>
>>         Stefan
>>
>

Re: Progress on merging Eglot?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]

Hi Payas,

I haven't had the to look at this in depth, but this looks mighty fine,
including this last idea of putting two "fixes" found in the subject line
in two lines of the body.

Many thanks,
João

On Mon, Sep 19, 2022, 05:42 Payas Relekar <relekarpayas@gmail.com> wrote:

> Another way I can think of is to keep #nums where they are right now,
> but add their respective links in the message body below.
>
> e.g.
> Fixes #234,#456
>
> this fixes two issues
>
> Becomes =>
>
> Fixes #234,#456
>
> this fixes two issues
> #234: https://github.com/joaotavora/eglot/234
> #456: https://github.com/joaotavora/eglot/456
>
> Inputs welcome, since this is not 100% convenient, but much simpler to
> implement, with minimal to none manual readjustment needed.
>
> Thanks,
> Payas
>
> On 9/19/22, Payas Relekar <relekarpayas@gmail.com> wrote:
> > Thank you! Indeed moving to subdirectory makes history apply to
> > correct file and shows up as expected. Was also quite straightforward
> > with git-filter-repo, so here's the updates:
> >
> > Updates gist:
> > https://gist.github.com/bhankas/422c34db2e987d4dc3f243e26ba156a3
> >
> > Updated repo:
> > https://github.com/bhankas/emacs
> >
> > Updated history:
> > https://github.com/bhankas/emacs/commits/master/lisp/progmodes/eglot.el
> >
> > Now the only remaining issue is commit length. Can someone please
> > advice on how we can go about it? My brute force thinking is to simply
> > add newline where length exceeds, delimited at word boundary, but
> > obviously that's not good enough nor covers sufficient edge cases.
> > Perhaps a Python/Perl wizard has a one/two liner to take that pain
> > away?
> >
> > Thanks,
> > Payas
> >
> > On Mon, 19 Sep, 2022, 08:08 Stefan Monnier, <monnier@iro.umontreal.ca>
> > wrote:
> >>
> >> > # filter eglot with only eglot.el and find+replace # in commit
> messages
> >> > git filter-repo --path eglot.el --message-callback '
> >> >       return re.sub(b" #", b"
> >> > https://github.com/joaotavora/eglot/issues/", message)
> >> >       return re.sub(b",#",
> >> > b",https://github.com/joaotavora/eglot/issues/", message)
> >> >       return re.sub(b"(#",
> >> > b"(https://github.com/joaotavora/eglot/issues/", message)
> >> >       return re.sub(b"Fix#", b"Fix:
> >> > https://github.com/joaotavora/eglot/issues/", message)
> >> >       return re.sub(b"github#", b"Github:
> >> > https://github.com/joaotavora/eglot/issues/", message)
> >>
> >> I suspect you can get a slightly better result if you tweak this filter
> >> script so as to rename `eglot.el` to `lisp/progmodes/eglot.el` in each
> >> commit.
> >>
> >> Then you can also skip the `git read-tree`.
> >>
> >>
> >>         Stefan
> >>
> >
>

[-- Attachment #2: Type: text/html, Size: 4914 bytes --]

Re: Progress on merging Eglot?

[Payas Relekar]

João Távora <joaotavora@gmail.com> writes:

> I haven't had the to look at this in depth, but this looks mighty fine,
> including this last idea of putting two "fixes" found in the subject line
> in two lines of the body.
>
> On Mon, Sep 19, 2022, 05:42 Payas Relekar <relekarpayas@gmail.com> wrote:
>
>> Another way I can think of is to keep #nums where they are right now,
>> but add their respective links in the message body below.
>>
>> e.g.
>> Fixes #234,#456
>>
>> this fixes two issues
>>
>> Becomes =>
>>
>> Fixes #234,#456
>>
>> this fixes two issues
>> #234: https://github.com/joaotavora/eglot/234
>> #456: https://github.com/joaotavora/eglot/456
>>

Alright! I think we have everything we need. I took the append URLs to
bottom of commit message approach. Here's what we have:

- History visible for file lisp/progmodes/eglot.el
- Commit message length undisturbed
- every #num is appended with appropriate URL at the bottom of commit
  message

These are the latest and (hopefully) final URLs:

Code:
https://gist.github.com/bhankas/422c34db2e987d4dc3f243e26ba156a3

(Please ensure eglot2emacs.py is in same directory as eglot/ and emacs/
repos)

Emacs repo with eglot.el merged:
https://github.com/bhankas/emacs

eglot.el file history within merged emacs repo:
https://github.com/bhankas/emacs/commits/master/lisp/progmodes/eglot.el

If all is good, that concludes #2 on João's list.

Let me know for any corrections and/or improvements.

Thanks,
Payas

--

Re: Progress on merging Eglot?

[Payas Relekar]

Payas Relekar <relekarpayas@gmail.com> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> I haven't had the to look at this in depth, but this looks mighty fine,
>> including this last idea of putting two "fixes" found in the subject line
>> in two lines of the body.
>>
> Alright! I think we have everything we need. I took the append URLs to
> bottom of commit message approach. Here's what we have:
>
> - History visible for file lisp/progmodes/eglot.el
> - Commit message length undisturbed
> - every #num is appended with appropriate URL at the bottom of commit
>   message
>
> These are the latest and (hopefully) final URLs:
>
> Code:
> https://gist.github.com/bhankas/422c34db2e987d4dc3f243e26ba156a3
>
> (Please ensure eglot2emacs.py is in same directory as eglot/ and emacs/
> repos)
>
> Emacs repo with eglot.el merged:
> https://github.com/bhankas/emacs
>
> eglot.el file history within merged emacs repo:
> https://github.com/bhankas/emacs/commits/master/lisp/progmodes/eglot.el

Jumped a bit :)
Made another, this time final final correction (properly strip excess
before # in URL) and ready for review.

git is updated with revision 4, all other links are same.

> If all is good, that concludes #2 on João's list.
>
> Let me know for any corrections and/or improvements.
>
> Thanks,
> Payas

Thanks,
Payas

--

Re: Progress on merging Eglot?

[Payas Relekar]

[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]

João Távora <joaotavora@gmail.com> writes:

> I haven't had the to look at this in depth, but this looks mighty fine,
> including this last idea of putting two "fixes" found in the subject line
> in two lines of the body.
>
> On Mon, Sep 19, 2022, 05:42 Payas Relekar <relekarpayas@gmail.com> wrote:
>
>> Another way I can think of is to keep #nums where they are right now,
>> but add their respective links in the message body below.
>>
>> e.g.
>> Fixes #234,#456
>>
>> this fixes two issues
>>
>> Becomes =>
>>
>> Fixes #234,#456
>>
>> this fixes two issues
>> #234: https://github.com/joaotavora/eglot/234
>> #456: https://github.com/joaotavora/eglot/456
>>

Alright! I think we have everything we need. I took the append URLs to
bottom of commit message approach. Here's what we have:

- History visible for file lisp/progmodes/eglot.el
- Commit message length undisturbed
- every #num is appended with appropriate URL at the bottom of commit
  message

These are the latest and (hopefully) final URLs:

Code:
https://gist.github.com/bhankas/422c34db2e987d4dc3f243e26ba156a3

(Please ensure eglot2emacs.py is in same directory as eglot/ and emacs/
repos)

Emacs repo with eglot.el merged:
https://github.com/bhankas/emacs

eglot.el file history within merged emacs repo:
https://github.com/bhankas/emacs/commits/master/lisp/progmodes/eglot.el

If all is good, that concludes #2 on João's list.

Let me know for any corrections and/or improvements.

Thanks,
Payas

--

[-- Attachment #2: Type: text/html, Size: 2622 bytes --]

Re: Progress on merging Eglot?

[João Távora]

Payas Relekar <relekarpayas@gmail.com> writes:

> Alright! I think we have everything we need. I took the append URLs to
> bottom of commit message approach. Here's what we have:
>
> - History visible for file lisp/progmodes/eglot.el
> - Commit message length undisturbed
> - every #num is appended with appropriate URL at the bottom of commit
>   message
>
> These are the latest and (hopefully) final URLs:
>
> Code:
> https://gist.github.com/bhankas/422c34db2e987d4dc3f243e26ba156a3
>
> (Please ensure eglot2emacs.py is in same directory as eglot/ and emacs/
> repos)
>
> Emacs repo with eglot.el merged:
> https://github.com/bhankas/emacs
>
> eglot.el file history within merged emacs repo:
> https://github.com/bhankas/emacs/commits/master/lisp/progmodes/eglot.el
>
> If all is good, that concludes #2 on João's list.
>
> Let me know for any corrections and/or improvements.

Thanks very much Payas, your work provided a most excellent start.

I took your GitHub gist, forked it, and reworked it.  That version now
lives at

   https://gist.github.com/joaotavora/2ed97f2ec85958986983d5cb78202770

and I ask that any work proceeds from there.

Most of my work happened in the eglot2emacs.py script, which I have
renamed eglot2emacs-message-callback.py.  After many tweaks, I ran it
through git filter-repo and think this version is now my preferred one.
For instance it transforms:

   Close #974, #776: Update docstring of eglot-events-buffer-size
    
   * eglot.el (eglot-events-buffer-size): Mention that you need to<CARRIAGE-RETURN>
   restart the connection for 'eglot-events-buffer-size' to take effect.

into

   Update docstring of eglot-events-buffer-size

   * eglot.el (eglot-events-buffer-size): Mention that you need to
   restart the connection for 'eglot-events-buffer-size' to take effect.
    
   GitHub-reference: Close https://github.com/joaotavora/eglot/issues/974
   GitHub-reference: Close https://github.com/joaotavora/eglot/issues/776

It also does other small tricks (and maybe some more can be added)

The only problem is that I can't get run the full eglot2emacs.sh to run.
The process is blocked, I think, by an Emacs commit hook that refuses to
accept some trailing changes in some unrelated files.  Can you see
what's up with that?  Did I mess up eglot2emacs.sh?

João

Progress on merging Eglot: update

[João Távora]

Hi,

We've worked a little bit last week on getting Eglot merged into the
core and this is the latest status:

1. TODO Eglot in emacs.git, published to ELPA as a :core package

   I think this is very easy consists of tweaking elpa.git with this
   patch once item 2 is done:

   diff --git a/elpa-packages b/elpa-packages
   index d87a9f9e4e..10379a9c32 100644
   --- a/elpa-packages
   +++ b/elpa-packages
   @@ -139,7 +139,7 @@
   - ("eglot"               :url "https://github.com/joaotavora/eglot.git")
   + ("eglot"               :core "lisp/progmodes/eglot.el")

2. DONE Preserve full Git history in lisp/progmodes/eglot.el file after merge

   A final version of the scripts lives in:

   https://gist.github.com/joaotavora/2ed97f2ec85958986983d5cb78202770

   I think the commit messages look fine.  I tweaked the emails to match
   what we have in the copyright file and made the author's names
   uniform.

   The scratch/eglot2emacs branch contains the latest result of running
   the ./eglot2emacs.sh script.

3. TODO Adapt tests in eglot-tests.el into Emacs's test suite

   Volunteers welcome for this, but reasonably low priority.

4. DONE Check carefully for copyright assignments for Eglot's many
   contributors

   I've done this.  The scripts mentioned in item 2 describe how I
   proceeded.

5. HELP rewrite https://github.com/joaotavora/eglot
   to list/progmodes/eglot.el

   I need to come up with a git incantation to run periodically so that
   the patches that happen in list/progmodes/eglot.el upstream can
   somehow be applied to the GitHub downstream-used-to-be-upstream.

   Then I need to know if there's some kind of FSF machine where a cron
   job can run these scripts periodically.  Maybe where the Elpa.git
   stuff runs?

6. DOING Adapt the README.md into a manual section in TexInfo format.

   Eli Zaretskii will handle this part once I hand him a slightly better
   structured README.md


João

Re: Progress on merging Eglot: update

[Payas Relekar]

Thanks a lot for all the work! Looking forward to Eglot in Emacs 29.1.

João Távora <joaotavora@gmail.com> writes:

> 5. HELP rewrite https://github.com/joaotavora/eglot
>    to list/progmodes/eglot.el
>
>    I need to come up with a git incantation to run periodically so that
>    the patches that happen in list/progmodes/eglot.el upstream can
>    somehow be applied to the GitHub downstream-used-to-be-upstream.

Can we use git-filter repo in similar manner as we did now, but instead
of moving to child dir (lisp/progmodes/), we move to parent dir
(../../)?

Then we can simply force push to github. Admittedly I haven't tested
this yet, but sounds doable. That way commit history will be preserved
both ways.

>    Then I need to know if there's some kind of FSF machine where a cron
>    job can run these scripts periodically.  Maybe where the Elpa.git
>    stuff runs?

Thanks,
Payas

--

Re: Progress on merging Eglot: update

[Payas Relekar]

Payas Relekar <relekarpayas@gmail.com> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> 5. HELP rewrite https://github.com/joaotavora/eglot
>>    to list/progmodes/eglot.el
>>
>>    I need to come up with a git incantation to run periodically so that
>>    the patches that happen in list/progmodes/eglot.el upstream can
>>    somehow be applied to the GitHub downstream-used-to-be-upstream.
>
> Can we use git-filter repo in similar manner as we did now, but instead
> of moving to child dir (lisp/progmodes/), we move to parent dir
> (../../)?
>
> Then we can simply force push to github. Admittedly I haven't tested
> this yet, but sounds doable. That way commit history will be preserved
> both ways.

Okay, tested and apparently working. It's a bit convoluted, but seems to
be working..

Here's the steps (assuming eglot/ and emacs/ repos are cloned in same
dir):

***
cd emacs/

# reduce to lisp/progmodes
git filter-repo --subdirectory-filter lisp/progmodes/

# reduce to eglot.el
git filter-repo --path eglot.el

cd ../eglot/

# remove eglot.el (to be pulled from emacs)
git filter-repo --invert-paths --path eglot.el

# add emacs.git as upstream
git remote add emacs ../emacs/

# fetch latest emacs.git with eglot.el
git fetch emacs master

# merge both repos
git merge remotes/emacs/master --allow-unrelated-histories --no-commit

# make a commit
git commit -m "; Merge from emacs.git"
***

Here's a repo with test commit added from emacs.git on top:
https://github.com/bhankas/eglot

I did not check extensively, but on (very) quick skim did not notice any
obvious duplication in the log.

Let me know if its helpful or needs more work.

Thanks,
Payas

--

Re: Progress on merging Eglot: update

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >    I need to come up with a git incantation to run periodically so that
  > >    the patches that happen in list/progmodes/eglot.el upstream can
  > >    somehow be applied to the GitHub downstream-used-to-be-upstream.

  > Can we use git-filter repo in similar manner as we did now, but instead
  > of moving to child dir (lisp/progmodes/), we move to parent dir
  > (../../)?

  > Then we can simply force push to github. Admittedly I haven't tested
  > this yet, but sounds doable. That way commit history will be preserved
  > both ways.

Using GitHub this way is no disaster in practice, but it is embarrassing.
Could we move that repo to a better place, such as sourcehut?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Progress on merging Eglot: update

[Payas Relekar]

Richard Stallman <rms@gnu.org> writes:

> Using GitHub this way is no disaster in practice, but it is embarrassing.
> Could we move that repo to a better place, such as sourcehut?

I believe Joao's reasons were to keep the users who target the github
repo from having their config broken, as well as provide another avenue
to submit issues/patches.

Modus-themes is hosted on sourcehut but also provides mirrors on Github
and Gitlab for similar reasons. Prot (modus-themes author/maintainer)
uses sourcehut as his primary hosting provider, but Joao plans to use
emacs.git for that purpose. As such, yet another mirror using mailing
list for issues/patches seems redundant. It will be his call in the end.

--

Re: Progress on merging Eglot: update

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: joaotavora@gmail.com, emacs-devel@gnu.org, eliz@gnu.org
> Date: Sat, 24 Sep 2022 22:46:18 -0400
> 
> Using GitHub this way is no disaster in practice, but it is embarrassing.
> Could we move that repo to a better place, such as sourcehut?

I don't think it makes sense to invest such an effort now, since we
are going to import Eglot into Emacs very soon, as soon as the
remaining technical issues are resolved.  Moving it to another hosting
service now will just delay the merge with Emacs, which is undesirable
since we want Eglot in Emacs before we start the Emacs 29 release
cycle.

Re: Progress on merging Eglot: update

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I don't think it makes sense to invest such an effort now, since we
  > are going to import Eglot into Emacs very soon, as soon as the
  > remaining technical issues are resolved.  Moving it to another hosting
  > service now will just delay the merge with Emacs, which is undesirable
  > since we want Eglot in Emacs before we start the Emacs 29 release
  > cycle.

Are you saying that this connection with GitHub is temporary?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Progress on merging Eglot: update

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On Mon, Sep 26, 2022 at 1:10 PM Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I don't think it makes sense to invest such an effort now, since we
>   > are going to import Eglot into Emacs very soon, as soon as the
>   > remaining technical issues are resolved.  Moving it to another hosting
>   > service now will just delay the merge with Emacs, which is undesirable
>   > since we want Eglot in Emacs before we start the Emacs 29 release
>   > cycle.
>
> Are you saying that this connection with GitHub is temporary?
>

That's correct.  My plan is to sever it completely, but in the short- to
medium-term it is still useful.  At any rate, GitHub will cease to be the
"upstream" of Eglot source once the merge to core is done.

João

[-- Attachment #2: Type: text/html, Size: 1401 bytes --]

Re: Progress on merging Eglot: update

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Are you saying that this connection with GitHub is temporary?
  > >

  > That's correct.  My plan is to sever it completely, but in the short- to
  > medium-term it is still useful.  At any rate, GitHub will cease to be the
  > "upstream" of Eglot source once the merge to core is done.

Thanks.  I agree it's not something to worry about if it is temporary.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Progress on merging Eglot?

[Stefan Monnier]

Payas Relekar [2022-09-19 10:12:34] wrote:
> Another way I can think of is to keep #nums where they are right now,
> but add their respective links in the message body below.

I was about to say that the overlong lines are perfectly fine (the main
focus is to preserve information, rather than make it pretty), but this
is even better.


        Stefan