You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(7) |
Aug
(1) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(3) |
2010 |
Jan
|
Feb
(10) |
Mar
(12) |
Apr
(13) |
May
(2) |
Jun
(4) |
Jul
(4) |
Aug
(4) |
Sep
|
Oct
(4) |
Nov
(2) |
Dec
(4) |
2011 |
Jan
(11) |
Feb
|
Mar
(18) |
Apr
|
May
(1) |
Jun
(12) |
Jul
(10) |
Aug
(4) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
(10) |
2012 |
Jan
(4) |
Feb
(26) |
Mar
|
Apr
(1) |
May
|
Jun
(8) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(1) |
Dec
(2) |
2013 |
Jan
(5) |
Feb
(2) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(7) |
2014 |
Jan
(14) |
Feb
|
Mar
(6) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(7) |
Oct
(9) |
Nov
(9) |
Dec
(5) |
2015 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(10) |
Jul
(3) |
Aug
(4) |
Sep
(8) |
Oct
(1) |
Nov
(3) |
Dec
(3) |
2016 |
Jan
(12) |
Feb
(59) |
Mar
(23) |
Apr
(11) |
May
(4) |
Jun
(15) |
Jul
|
Aug
|
Sep
(9) |
Oct
(19) |
Nov
(12) |
Dec
(5) |
2017 |
Jan
(1) |
Feb
(5) |
Mar
(5) |
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
(3) |
Oct
(12) |
Nov
(15) |
Dec
|
2018 |
Jan
(7) |
Feb
(6) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(2) |
Oct
(4) |
Nov
|
Dec
|
2019 |
Jan
(2) |
Feb
(9) |
Mar
(4) |
Apr
(9) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(5) |
2020 |
Jan
(9) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(28) |
Dec
(5) |
2021 |
Jan
(11) |
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
(15) |
Jun
(9) |
Jul
(11) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
(3) |
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
(9) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(4) |
Jun
|
Jul
(22) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
(14) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
(17) |
May
(35) |
Jun
(1) |
Jul
(18) |
Aug
(31) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
From: Uwe B. <ou...@ma...> - 2024-08-13 09:11:52
|
>>> "EL" == Eric Ludlam <eri...@gm...> writes: Hi all > Regarding finding differences between a branch and main/master. > I was trying to remind myself what the changes were. Thus, just a diff > between branch tip and main/master from whence the branch was created. (ie > - what did I change). Then I could check main/master to see if that change > was already merged (in the case of the fontlock branch). Sorry to nag, but basically I have around 2 weeks left in which I can find the time to deal with the move of the repository to github and do the cleanup we discussed 1. I also would like to settle the issue concerning ELPA, but I think it is best do do this after the move to github 2. Maybe we should then remove the MELPA package just in order to simplify things. Sorry Eric, any idea what to do with the only branch whose status is unclear: shellcomplete Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-08-09 07:55:24
|
>>> "EL" == Eric Ludlam <eri...@gm...> writes: > Regarding finding differences between a branch and main/master. > I was trying to remind myself what the changes were. Thus, just a diff > between branch tip and main/master from whence the branch was created. (ie > - what did I change). Then I could check main/master to see if that change > was already merged (in the case of the fontlock branch). Any news? Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-08-05 11:42:46
|
I took a quick look at shellcomplete and think master is more current. There's a fair bit of diff in matlab-complete.el and master looks more current. Around the time of the branch activity, Eric and I were improving matlab completion and I think we used this branch a little, then directly sent to master. Also, all the older completion problems that we were working on are resolved (master contains the fixes). We'll wait for Eric to verify before deleting the shellcomplete branch. Thanks John ________________________________ From: Uwe Brauer Sent: Sunday, August 04, 2024 11:52 AM To: John Ciolfi Cc: Uwe Brauer; Eric Ludlam; matlab-emacs-discuss Subject: Re: [Matlab-emacs-discuss] move -->github: rebase, and which branches could be deleted >>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi > I just double checked the fontlonkhang branch, downloaded zip > * > matlab-emacs-src-a78b368387c85437f8de187acf0a2b1cbeeacc3f/ (master) > * > matlab-emacs-src-ce22c697d06ece776cfd7a9a41b3704f1815823f/ (fontlockhang) > And diff'd them - all changes are in master. I also validated that the > hangs we were seeing no longer exist. Ok, thanks for checking to this settled and this branch can be safely deleted. The only open question then concerns the shellcomplete branch, Eric wanted to check. > Thanks > John > ________________________________ > From: Uwe Brauer > Sent: Thursday, August 01, 2024 4:46 PM > To: John Ciolfi > Cc: Eric Ludlam; Uwe Brauer; matlab-emacs-discuss > Subject: Re: [Matlab-emacs-discuss] move -->github: rebase, and which branches could be deleted >>> "JC" == John Ciolfi <ci...@ma...> writes: >> Regarding the fontlockhang, these have been merged in to the >> main/master branch already. I just manually compared matlab.el between >> and the fontlock improvements are in the tip. >> The fontlockhang branch can be deleted. > This is odd, (and this is why I don't trust git (and prefer mercurial 😉) > If I run clone the sourceforge repository again and run > git log --graph --color=always --all --decorate --pretty | git name-rev --annotate-stdin | less -R > I see > | * commit ce22c697d06ece776cfd7a9a41b3704f1815823f (remotes/origin/fontlockhang) (origin/fontlockhang) > | | Author: Eric Ludlam <el...@ma...> > | | Date: Mon Sep 26 17:44:26 2022 -0400 > | | > | | mclass.m: Added AH to test a type with a long package name. > | | > | | This used to be very very slow or hang Emacs. > | | > | * commit c0af4943b5d45fa73e6d4ed5681121d6e1983727 (remotes/origin/fontlockhang~1) > |/ Author: Eric Ludlam <el...@ma...> > | Date: Mon Sep 26 17:31:41 2022 -0400 > | > | (matlab-font-lock-anchor-variable-match): Fix regex to be faster. > | > | Fixes what was percieved as a hang for properties with lots of package.class types. > | > So this branch clearly is not merged. That is confirmed by running > git branch -a --no-merged master > remotes/origin/copyright > remotes/origin/fill-fix > remotes/origin/fontlockhang > remotes/origin/matlab-cells > remotes/origin/org-mode > remotes/origin/shellcomplete > remotes/origin/wisent-parser > Could you please check again and confirm before I delete, because if I > delete an unmerged branch in git, its commits are gone (well I will do > this on my experimental github repository not in sourceforge). >> Note, in MathWorks we are using the current matlab-emacs tip minus a >> few items that no longer work such as the cedet items. Once we get >> matlab-emacs into github, I'll update it with improvements such as >> good org mode support and LSP support. > Ok, should be ready in a couple of days. I need to clarify the status of > this branch and the one Eric is looking into. > Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-08-04 15:52:59
|
>>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi > I just double checked the fontlonkhang branch, downloaded zip > * > matlab-emacs-src-a78b368387c85437f8de187acf0a2b1cbeeacc3f/ (master) > * > matlab-emacs-src-ce22c697d06ece776cfd7a9a41b3704f1815823f/ (fontlockhang) > And diff'd them - all changes are in master. I also validated that the > hangs we were seeing no longer exist. Ok, thanks for checking to this settled and this branch can be safely deleted. The only open question then concerns the shellcomplete branch, Eric wanted to check. > Thanks > John > ________________________________ > From: Uwe Brauer > Sent: Thursday, August 01, 2024 4:46 PM > To: John Ciolfi > Cc: Eric Ludlam; Uwe Brauer; matlab-emacs-discuss > Subject: Re: [Matlab-emacs-discuss] move -->github: rebase, and which branches could be deleted >>> "JC" == John Ciolfi <ci...@ma...> writes: >> Regarding the fontlockhang, these have been merged in to the >> main/master branch already. I just manually compared matlab.el between >> and the fontlock improvements are in the tip. >> The fontlockhang branch can be deleted. > This is odd, (and this is why I don't trust git (and prefer mercurial 😉) > If I run clone the sourceforge repository again and run > git log --graph --color=always --all --decorate --pretty | git name-rev --annotate-stdin | less -R > I see > | * commit ce22c697d06ece776cfd7a9a41b3704f1815823f (remotes/origin/fontlockhang) (origin/fontlockhang) > | | Author: Eric Ludlam <el...@ma...> > | | Date: Mon Sep 26 17:44:26 2022 -0400 > | | > | | mclass.m: Added AH to test a type with a long package name. > | | > | | This used to be very very slow or hang Emacs. > | | > | * commit c0af4943b5d45fa73e6d4ed5681121d6e1983727 (remotes/origin/fontlockhang~1) > |/ Author: Eric Ludlam <el...@ma...> > | Date: Mon Sep 26 17:31:41 2022 -0400 > | > | (matlab-font-lock-anchor-variable-match): Fix regex to be faster. > | > | Fixes what was percieved as a hang for properties with lots of package.class types. > | > So this branch clearly is not merged. That is confirmed by running > git branch -a --no-merged master > remotes/origin/copyright > remotes/origin/fill-fix > remotes/origin/fontlockhang > remotes/origin/matlab-cells > remotes/origin/org-mode > remotes/origin/shellcomplete > remotes/origin/wisent-parser > Could you please check again and confirm before I delete, because if I > delete an unmerged branch in git, its commits are gone (well I will do > this on my experimental github repository not in sourceforge). >> Note, in MathWorks we are using the current matlab-emacs tip minus a >> few items that no longer work such as the cedet items. Once we get >> matlab-emacs into github, I'll update it with improvements such as >> good org mode support and LSP support. > Ok, should be ready in a couple of days. I need to clarify the status of > this branch and the one Eric is looking into. > Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-08-04 10:59:55
|
Hi I just double checked the fontlonkhang branch, downloaded zip * matlab-emacs-src-a78b368387c85437f8de187acf0a2b1cbeeacc3f/ (master) * matlab-emacs-src-ce22c697d06ece776cfd7a9a41b3704f1815823f/ (fontlockhang) And diff'd them - all changes are in master. I also validated that the hangs we were seeing no longer exist. I believe what happened is that Eric and I used the fontlockhang as a "staging" area and then once solved, we manually added to master. Thanks John ________________________________ From: Uwe Brauer Sent: Thursday, August 01, 2024 4:46 PM To: John Ciolfi Cc: Eric Ludlam; Uwe Brauer; matlab-emacs-discuss Subject: Re: [Matlab-emacs-discuss] move -->github: rebase, and which branches could be deleted >>> "JC" == John Ciolfi <ci...@ma...> writes: > Regarding the fontlockhang, these have been merged in to the > main/master branch already. I just manually compared matlab.el between > and the fontlock improvements are in the tip. > The fontlockhang branch can be deleted. This is odd, (and this is why I don't trust git (and prefer mercurial 😉) If I run clone the sourceforge repository again and run git log --graph --color=always --all --decorate --pretty | git name-rev --annotate-stdin | less -R I see | * commit ce22c697d06ece776cfd7a9a41b3704f1815823f (remotes/origin/fontlockhang) (origin/fontlockhang) | | Author: Eric Ludlam <el...@ma...> | | Date: Mon Sep 26 17:44:26 2022 -0400 | | | | mclass.m: Added AH to test a type with a long package name. | | | | This used to be very very slow or hang Emacs. | | | * commit c0af4943b5d45fa73e6d4ed5681121d6e1983727 (remotes/origin/fontlockhang~1) |/ Author: Eric Ludlam <el...@ma...> | Date: Mon Sep 26 17:31:41 2022 -0400 | | (matlab-font-lock-anchor-variable-match): Fix regex to be faster. | | Fixes what was percieved as a hang for properties with lots of package.class types. | So this branch clearly is not merged. That is confirmed by running git branch -a --no-merged master remotes/origin/copyright remotes/origin/fill-fix remotes/origin/fontlockhang remotes/origin/matlab-cells remotes/origin/org-mode remotes/origin/shellcomplete remotes/origin/wisent-parser Could you please check again and confirm before I delete, because if I delete an unmerged branch in git, its commits are gone (well I will do this on my experimental github repository not in sourceforge). > Note, in MathWorks we are using the current matlab-emacs tip minus a > few items that no longer work such as the cedet items. Once we get > matlab-emacs into github, I'll update it with improvements such as > good org mode support and LSP support. Ok, should be ready in a couple of days. I need to clarify the status of this branch and the one Eric is looking into. Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-08-01 20:46:33
|
>>> "JC" == John Ciolfi <ci...@ma...> writes: > Regarding the fontlockhang, these have been merged in to the > main/master branch already. I just manually compared matlab.el between > and the fontlock improvements are in the tip. > The fontlockhang branch can be deleted. This is odd, (and this is why I don't trust git (and prefer mercurial 😉) If I run clone the sourceforge repository again and run git log --graph --color=always --all --decorate --pretty | git name-rev --annotate-stdin | less -R I see | * commit ce22c697d06ece776cfd7a9a41b3704f1815823f (remotes/origin/fontlockhang) (origin/fontlockhang) | | Author: Eric Ludlam <el...@ma...> | | Date: Mon Sep 26 17:44:26 2022 -0400 | | | | mclass.m: Added AH to test a type with a long package name. | | | | This used to be very very slow or hang Emacs. | | | * commit c0af4943b5d45fa73e6d4ed5681121d6e1983727 (remotes/origin/fontlockhang~1) |/ Author: Eric Ludlam <el...@ma...> | Date: Mon Sep 26 17:31:41 2022 -0400 | | (matlab-font-lock-anchor-variable-match): Fix regex to be faster. | | Fixes what was percieved as a hang for properties with lots of package.class types. | So this branch clearly is not merged. That is confirmed by running git branch -a --no-merged master remotes/origin/copyright remotes/origin/fill-fix remotes/origin/fontlockhang remotes/origin/matlab-cells remotes/origin/org-mode remotes/origin/shellcomplete remotes/origin/wisent-parser Could you please check again and confirm before I delete, because if I delete an unmerged branch in git, its commits are gone (well I will do this on my experimental github repository not in sourceforge). > Note, in MathWorks we are using the current matlab-emacs tip minus a > few items that no longer work such as the cedet items. Once we get > matlab-emacs into github, I'll update it with improvements such as > good org mode support and LSP support. Ok, should be ready in a couple of days. I need to clarify the status of this branch and the one Eric is looking into. Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-08-01 20:26:04
|
Regarding the fontlockhang, these have been merged in to the main/master branch already. I just manually compared matlab.el between and the fontlock improvements are in the tip. The fontlockhang branch can be deleted. Note, in MathWorks we are using the current matlab-emacs tip minus a few items that no longer work such as the cedet items. Once we get matlab-emacs into github, I'll update it with improvements such as good org mode support and LSP support. Thanks, John ________________________________ From: Eric Ludlam <eri...@gm...> Sent: Thursday, August 1, 2024 1:59 PM To: Uwe Brauer <ou...@ma...> Cc: matlab-emacs-discuss <mat...@li...> Subject: Re: [Matlab-emacs-discuss] move -->github: rebase, and which branches could be deleted Regarding finding differences between a branch and main/master. I was trying to remind myself what the changes were. Thus, just a diff between branch tip and main/master from whence the branch was created. (ie - what did I change). Then I could check main/master to see if that change was already merged (in the case of the fontlock branch). I know how to do it from the command line (or more accurately, I know how to look up how to do it), but I didn't have a clone handy at the time and was hoping to use the web interface for a quick check and not delay replying. I can dig in more soon to find the answers when I get some other tasks off my plate. Eric On Thu, Aug 1, 2024 at 11:16 AM Uwe Brauer <ou...@ma...<mailto:ou...@ma...>> wrote: >>> "UB" == Uwe Brauer <ou...@ma...<mailto:ou...@ma...>> writes: >>> "EL" == Eric Ludlam <eri...@gm...<mailto:eri...@gm...>> writes: >> Removing those 3 items are fine with me. Here are some details. >> * I'm pretty sure fontlockhang was used by John to solve problems at >> MathWorks. I thought John then recommended the fixes be merged into >> mainline after that. > I would like to clarify these issues before we move to github > Hm, ok @John, what do you say? Shall (and can) this branch be merged > into master (in sourceforge)? Can you do that? >> * wisent-parser is a dead end and is fine to delete > Ok. >> * shell-complete I just don't recall what that is. Maybe there is >> something useful in there but I don't remember enough about it to advise. >> I was looking to use the sourceforge interface to show what was different >> about each branch from where it was branched from, but I didn't see an easy >> way to do that. That would make it much easier to verify my assumptions >> about fontlockhang, or guess at what shell-complete was about. Is there an >> easy way to do that? I just realize that maybe I misunderstood you, do you want to see which files have been changed in each commit in that branch, or do you want to have a diff of the latest commit in master with each commit in that branch? -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Eric L. <eri...@gm...> - 2024-08-01 17:59:23
|
Regarding finding differences between a branch and main/master. I was trying to remind myself what the changes were. Thus, just a diff between branch tip and main/master from whence the branch was created. (ie - what did I change). Then I could check main/master to see if that change was already merged (in the case of the fontlock branch). I know how to do it from the command line (or more accurately, I know how to look up how to do it), but I didn't have a clone handy at the time and was hoping to use the web interface for a quick check and not delay replying. I can dig in more soon to find the answers when I get some other tasks off my plate. Eric On Thu, Aug 1, 2024 at 11:16 AM Uwe Brauer <ou...@ma...> wrote: > >>> "UB" == Uwe Brauer <ou...@ma...> writes: > > >>> "EL" == Eric Ludlam <eri...@gm...> writes: > >> Removing those 3 items are fine with me. Here are some details. > >> * I'm pretty sure fontlockhang was used by John to solve problems at > >> MathWorks. I thought John then recommended the fixes be merged into > >> mainline after that. > > > I would like to clarify these issues before we move to github > > > Hm, ok @John, what do you say? Shall (and can) this branch be merged > > into master (in sourceforge)? Can you do that? > > > >> * wisent-parser is a dead end and is fine to delete > > > Ok. > > >> * shell-complete I just don't recall what that is. Maybe there is > >> something useful in there but I don't remember enough about it to > advise. > > >> I was looking to use the sourceforge interface to show what was > different > >> about each branch from where it was branched from, but I didn't see an > easy > >> way to do that. That would make it much easier to verify my assumptions > >> about fontlockhang, or guess at what shell-complete was about. Is > there an > >> easy way to do that? > > > I just realize that maybe I misunderstood you, do you want to see which > files have been changed in each commit in that branch, or do you want to > have a diff of the latest commit in master with each commit in that branch? > > > > -- > I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel > I strongly condemn Putin's war of aggression against Ukraine. > I support to deliver weapons to Ukraine's military. > I support the EU and NATO membership of Ukraine. > > |
From: Uwe B. <ou...@ma...> - 2024-08-01 15:17:01
|
>>> "UB" == Uwe Brauer <ou...@ma...> writes: >>> "EL" == Eric Ludlam <eri...@gm...> writes: >> Removing those 3 items are fine with me. Here are some details. >> * I'm pretty sure fontlockhang was used by John to solve problems at >> MathWorks. I thought John then recommended the fixes be merged into >> mainline after that. > I would like to clarify these issues before we move to github > Hm, ok @John, what do you say? Shall (and can) this branch be merged > into master (in sourceforge)? Can you do that? >> * wisent-parser is a dead end and is fine to delete > Ok. >> * shell-complete I just don't recall what that is. Maybe there is >> something useful in there but I don't remember enough about it to advise. >> I was looking to use the sourceforge interface to show what was different >> about each branch from where it was branched from, but I didn't see an easy >> way to do that. That would make it much easier to verify my assumptions >> about fontlockhang, or guess at what shell-complete was about. Is there an >> easy way to do that? I just realize that maybe I misunderstood you, do you want to see which files have been changed in each commit in that branch, or do you want to have a diff of the latest commit in master with each commit in that branch? -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-08-01 08:03:36
|
>>> "EL" == Eric Ludlam <eri...@gm...> writes: > Removing those 3 items are fine with me. Here are some details. > * I'm pretty sure fontlockhang was used by John to solve problems at > MathWorks. I thought John then recommended the fixes be merged into > mainline after that. I would like to clarify these issues before we move to github Hm, ok @John, what do you say? Shall (and can) this branch be merged into master (in sourceforge)? Can you do that? > * wisent-parser is a dead end and is fine to delete Ok. > * shell-complete I just don't recall what that is. Maybe there is > something useful in there but I don't remember enough about it to advise. > I was looking to use the sourceforge interface to show what was different > about each branch from where it was branched from, but I didn't see an easy > way to do that. That would make it much easier to verify my assumptions > about fontlockhang, or guess at what shell-complete was about. Is there an > easy way to do that? Yes and no. First a small rant. Git is praised for its speed and flexibility, (renaming, tracking, deleting branches), but this comes at a price. In git you can never be sure where a branch starts and which commits belong to which branch (there are relative simple counter examples, but I don't want to bore you). There is the command name-rev which tries on the fly to find out which commit belongs to which branch but as said this is not failsafe (contrary to mercurial). So what you should do on the command line is this. git switch --guess shellcomplete git log --graph --color=always --decorate --pretty | git name-rev --annotate-stdin | less -R That gives me * commit 27972c21a5b7b154af83b0d0a941674f668dd06b (shellcomplete) (HEAD -> shellcomplete, origin/shellcomplete) | Author: Eric Ludlam <er...@si...> | Date: Tue Apr 6 20:45:07 2021 -0400 | | matlab-shell.el: | | (matlab-shell-collect-command-output): Prevent read-only text from throwing | errors for systems where this is on by default. | * commit 9c0da9f52812001ff3584f623fe4fa6f62b7a7b1 (shellcomplete~1) | Author: Eric Ludlam <er...@si...> | Date: Mon Jan 18 11:58:12 2021 -0500 | | matlab-xref.el: | | (matlab-shell-xref-activate, matlab-local-xref-activate): | Don't bother checking major mode. Only installed for ML buffers, | and user might want to install in org mode buffers too. | * commit 34aab6039575f7132a99116ec4760a0a51d2d587 (shellcomplete~2) | Author: Eric Ludlam <er...@si...> | Date: Sun Jan 17 12:34:29 2021 -0500 | | matlab.el: | | (matlab-local-xref-activate): Declare fcn / quiet compiler. | * commit 8fe27556fe2acdfca2e65eee919fd05e283e00bc (shellcomplete~3) | Author: Eric Ludlam <er...@si...> | Date: Sun Jan 17 12:33:16 2021 -0500 | | | *commit 71daa45c0b0f0513c24461a0a24a277bc7430f91 (shellcomplete~8) Begin the last commit on that branch. Hope this helps Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Eric L. <eri...@gm...> - 2024-08-01 02:56:26
|
Removing those 3 items are fine with me. Here are some details. * I'm pretty sure fontlockhang was used by John to solve problems at MathWorks. I thought John then recommended the fixes be merged into mainline after that. * wisent-parser is a dead end and is fine to delete * shell-complete I just don't recall what that is. Maybe there is something useful in there but I don't remember enough about it to advise. I was looking to use the sourceforge interface to show what was different about each branch from where it was branched from, but I didn't see an easy way to do that. That would make it much easier to verify my assumptions about fontlockhang, or guess at what shell-complete was about. Is there an easy way to do that? Thanks Eric On Wed, Jul 31, 2024 at 11:07 AM Uwe Brauer <ou...@ma...> wrote: > >>> "EL" == Eric Ludlam <eri...@gm...> writes: > > Hi > > Thanks for doing all this work Uwe. I appreciate it. > > For unmerged branches, I recognize some as branches that were merged via > > other avenues, and others are not relevant anymore or I don't recall > what I > > might have been up to. Should be fine to ignore them all > > Just to be sure, because this is git not mercurial, deleting an unmerged > branch will delete all its commits (impossible in mercurial). > > So I would like to keep the following branches, for the moment > > - matlab-cells > > - org-mode > > - fill-fix > > - copyright > > - documentation. > > If I understand you correctly I can delete the unmerged branches. > > - fonlockhang > > - shell-complete > > - wisent-parser > > Right? I can do that as soon as I have you definite ok and push the > resulting repository for further inspection as a public repository to my > github account. > > Uwe > > > > > -- > I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel > I strongly condemn Putin's war of aggression against Ukraine. > I support to deliver weapons to Ukraine's military. > I support the EU and NATO membership of Ukraine. > > |
From: Uwe B. <ou...@ma...> - 2024-07-31 16:07:30
|
>>> "EL" == Eric Ludlam <eri...@gm...> writes: Hi > Thanks for doing all this work Uwe. I appreciate it. > For unmerged branches, I recognize some as branches that were merged via > other avenues, and others are not relevant anymore or I don't recall what I > might have been up to. Should be fine to ignore them all Just to be sure, because this is git not mercurial, deleting an unmerged branch will delete all its commits (impossible in mercurial). So I would like to keep the following branches, for the moment - matlab-cells - org-mode - fill-fix - copyright - documentation. If I understand you correctly I can delete the unmerged branches. - fonlockhang - shell-complete - wisent-parser Right? I can do that as soon as I have you definite ok and push the resulting repository for further inspection as a public repository to my github account. Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Eric L. <eri...@gm...> - 2024-07-31 13:40:00
|
Thanks for doing all this work Uwe. I appreciate it. For unmerged branches, I recognize some as branches that were merged via other avenues, and others are not relevant anymore or I don't recall what I might have been up to. Should be fine to ignore them all Thanks for checking in Eric On Tue, Jul 30, 2024 at 8:29 AM Uwe Brauer via Matlab-emacs-discuss < mat...@li...> wrote: > Hi all (especially Eric) > > > As you maybe aware of, we plan to move the development to github. That > is a good moment, to think about cleaning up a bit the repository, like > rebasing and deleting old merged branches. > > The idea is once we agree, I would push a test, but public repository to > my own > github account so that everybody can have a look and if everything is > alright it will then be pushed to its new «home», and we will leave a > note in sourceforge. > > 1. I would like to rename the principal branch, «default» (instead of > master). That simplify things quite a bit on my side, besides the > name master is hm, controversial, a lot of repositories call the > principal branch now, «main», but on technical reasons I prefer, > «default» > > 2. The actual git branches > > - Git branch -a tells me > ,---- > | > | * master > | remotes/origin/HEAD -> origin/master > | remotes/origin/copyright > | remotes/origin/documentation > | remotes/origin/fill-fix > | remotes/origin/font-lock > | remotes/origin/fontlockhang > | remotes/origin/hairyblocks > | remotes/origin/mac_init > | remotes/origin/master > | remotes/origin/matlab-cells > | remotes/origin/modernize > | remotes/origin/org-mode > | remotes/origin/shell-patch > | remotes/origin/shellcomplete > | remotes/origin/strings > | remotes/origin/usage1 > | remotes/origin/wisent-parser > `---- > > > - while git branch -r --no-merged origin/master results in > ,---- > | > | origin/copyright > | origin/fill-fix > | origin/fontlockhang > | origin/matlab-cells > | origin/org-mode > | origin/shellcomplete > | origin/wisent-parser > `---- > > So 7 branches are actually not merged and can't be deleted without > loosing the commits. > > > > 1. I created > > - copyright, (to sort out the issue with the FSF papers and having > the repository in ELPA, not MELPA) > > - fill-fix a branch for testing and trying to improve the filling of > comments, and inline comments. > > - org-mode a branch for testing who the matlab-shell could > interact with org mode. > > 2. Nidish created matlab-cells, which hopefully soon will be merged > into master/default. > > 3. Eric created the rest. So Eric, is it ok if I delete all the > branches that are *not* merged into master? > > > Once that is settled, I rename master-->default, do some rebasing and > push the result to a test repository in github. > > Regards > > Uwe > > > > > > > > > > > -- > I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel > I strongly condemn Putin's war of aggression against Ukraine. > I support to deliver weapons to Ukraine's military. > I support the EU and NATO membership of Ukraine. > > _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss > |
From: Uwe B. <ou...@ma...> - 2024-07-30 12:29:10
|
Hi all (especially Eric) As you maybe aware of, we plan to move the development to github. That is a good moment, to think about cleaning up a bit the repository, like rebasing and deleting old merged branches. The idea is once we agree, I would push a test, but public repository to my own github account so that everybody can have a look and if everything is alright it will then be pushed to its new «home», and we will leave a note in sourceforge. 1. I would like to rename the principal branch, «default» (instead of master). That simplify things quite a bit on my side, besides the name master is hm, controversial, a lot of repositories call the principal branch now, «main», but on technical reasons I prefer, «default» 2. The actual git branches - Git branch -a tells me ,---- | | * master | remotes/origin/HEAD -> origin/master | remotes/origin/copyright | remotes/origin/documentation | remotes/origin/fill-fix | remotes/origin/font-lock | remotes/origin/fontlockhang | remotes/origin/hairyblocks | remotes/origin/mac_init | remotes/origin/master | remotes/origin/matlab-cells | remotes/origin/modernize | remotes/origin/org-mode | remotes/origin/shell-patch | remotes/origin/shellcomplete | remotes/origin/strings | remotes/origin/usage1 | remotes/origin/wisent-parser `---- - while git branch -r --no-merged origin/master results in ,---- | | origin/copyright | origin/fill-fix | origin/fontlockhang | origin/matlab-cells | origin/org-mode | origin/shellcomplete | origin/wisent-parser `---- So 7 branches are actually not merged and can't be deleted without loosing the commits. 1. I created - copyright, (to sort out the issue with the FSF papers and having the repository in ELPA, not MELPA) - fill-fix a branch for testing and trying to improve the filling of comments, and inline comments. - org-mode a branch for testing who the matlab-shell could interact with org mode. 2. Nidish created matlab-cells, which hopefully soon will be merged into master/default. 3. Eric created the rest. So Eric, is it ok if I delete all the branches that are *not* merged into master? Once that is settled, I rename master-->default, do some rebasing and push the result to a test repository in github. Regards Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-07-29 20:36:13
|
>>> "JC" == John Ciolfi <ci...@ma...> writes: > Great, if you can help me get this in place (clean history and the 'default' branch), I will up get it uploaded to github. Ok, let's to this calmly in the next few days. Tomorrow I will write to the list and ask Eric specifically which merged branch we can safely delete. Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-07-29 20:17:23
|
Great, if you can help me get this in place (clean history and the 'default' branch), I will up get it uploaded to github. Thanks John ________________________________ From: Uwe Brauer Sent: Monday, July 29, 2024 4:11 PM To: John Ciolfi Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi > I'm proposing starting fresh meaning initially no history in github. > You'd need to jump back to Source Forge for the older changes. They > would not be lost. We'd freeze Source Forge and add a link to them. > Part of the reason for doing this is that there is a bunch of old > stuff in Source Forge and this way we don't need to worry about > cleaning it up or pulling in stuff we don't want. So, we are good for > the history - it's just a side step to access Source Forge. > With this proposal, in github, we'd see > matlab.el "initial commit" > etc. > And then on the page: The problem with this approach is that all the branches that are not merged yet are lost! That includes 1. The matlab-cell branch Nidish is working on 2. The fix-fix branch and which Eric and me try to test and improve the filling funcion. 3. The org-mode branch I create to test and to improve org-matlab interaction. All the commits on these branches would be lost. > History matlab-mode has a history dating back many years. Older > contributions can be found in > https://sourceforge.net/projects/matlab-emacs/. > If you feel like we should import the history, could you help with that? Sure that is actually very easy to do. > Maybe the easiest way would be to just copy the history from the main > branch, then people with other branches could choose to create new > forks in github with their changes. I still have reasonable amount of time till the send of August, then I have to travel and will be much more occupied with other stuff. I propose the following: - I will ask in the list, which of the old branches can be safely deleted. Here is a list of git branches remotes/origin/copyright remotes/origin/documentation remotes/origin/fill-fix remotes/origin/font-lock remotes/origin/fontlockhang remotes/origin/hairyblocks remotes/origin/mac_init remotes/origin/master remotes/origin/matlab-cells remotes/origin/modernize remotes/origin/org-mode remotes/origin/shell-patch remotes/origin/shellcomplete remotes/origin/strings remotes/origin/usage1 remotes/origin/wisent-parser I presume that most of them I can delete, but I want to be sure before I do this. - I will rename the principal branch default (I checked this is possible in github) - I will then rebase stuff and make the graph leaner. - I will push that to a github repository I call matlab-emacs-experiment or so, so people can clone and look. - once this is settled, you give me write access to the MATLAB repository, I push everything. Write access will have at the moment, you, Eric, Nidish and myself. Regards Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-07-29 20:11:50
|
>>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi > I'm proposing starting fresh meaning initially no history in github. > You'd need to jump back to Source Forge for the older changes. They > would not be lost. We'd freeze Source Forge and add a link to them. > Part of the reason for doing this is that there is a bunch of old > stuff in Source Forge and this way we don't need to worry about > cleaning it up or pulling in stuff we don't want. So, we are good for > the history - it's just a side step to access Source Forge. > With this proposal, in github, we'd see > matlab.el "initial commit" > etc. > And then on the page: The problem with this approach is that all the branches that are not merged yet are lost! That includes 1. The matlab-cell branch Nidish is working on 2. The fix-fix branch and which Eric and me try to test and improve the filling funcion. 3. The org-mode branch I create to test and to improve org-matlab interaction. All the commits on these branches would be lost. > History matlab-mode has a history dating back many years. Older > contributions can be found in > https://sourceforge.net/projects/matlab-emacs/. > If you feel like we should import the history, could you help with that? Sure that is actually very easy to do. > Maybe the easiest way would be to just copy the history from the main > branch, then people with other branches could choose to create new > forks in github with their changes. I still have reasonable amount of time till the send of August, then I have to travel and will be much more occupied with other stuff. I propose the following: - I will ask in the list, which of the old branches can be safely deleted. Here is a list of git branches remotes/origin/copyright remotes/origin/documentation remotes/origin/fill-fix remotes/origin/font-lock remotes/origin/fontlockhang remotes/origin/hairyblocks remotes/origin/mac_init remotes/origin/master remotes/origin/matlab-cells remotes/origin/modernize remotes/origin/org-mode remotes/origin/shell-patch remotes/origin/shellcomplete remotes/origin/strings remotes/origin/usage1 remotes/origin/wisent-parser I presume that most of them I can delete, but I want to be sure before I do this. - I will rename the principal branch default (I checked this is possible in github) - I will then rebase stuff and make the graph leaner. - I will push that to a github repository I call matlab-emacs-experiment or so, so people can clone and look. - once this is settled, you give me write access to the MATLAB repository, I push everything. Write access will have at the moment, you, Eric, Nidish and myself. Regards Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-07-29 19:23:53
|
Hi I'm proposing starting fresh meaning initially no history in github. You'd need to jump back to Source Forge for the older changes. They would not be lost. We'd freeze Source Forge and add a link to them. Part of the reason for doing this is that there is a bunch of old stuff in Source Forge and this way we don't need to worry about cleaning it up or pulling in stuff we don't want. So, we are good for the history - it's just a side step to access Source Forge. With this proposal, in github, we'd see matlab.el "initial commit" etc. And then on the page: History matlab-mode has a history dating back many years. Older contributions can be found in https://sourceforge.net/projects/matlab-emacs/. If you feel like we should import the history, could you help with that? Maybe the easiest way would be to just copy the history from the main branch, then people with other branches could choose to create new forks in github with their changes. Regardless, we should keep the Source Forge reference in the github repo. Thanks John ________________________________ From: Uwe Brauer Sent: Monday, July 29, 2024 1:20 PM To: John Ciolfi Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi > I haven't spent time looking into how to make the branch 'default' > (too many other items on my plate). I did this in the past, without problems, I am just retrying it again and tell you the details later. > Once that's done, I can upload the repo to github. I am not sure what you mean by upload. > My original proposal was to start fresh in github and keep the older > history in Source Forge as this is simpler. Is that okay? Ah wait, I am confused. That defies a bit the idea of a version control system, doesn't it? I mean I understand that you are not interested in very old versions, that is why I proposed some cleanup, rebase and deleting old branches. But, please note, that our repository is about 5 MB even less. For example GNU emacs, goes way back at least to 1995 (using RCS), and well it is about 1GB. But I can see the benefits of having a long history. Another problem are the branches that are yet not even merged. Do you want to delete and forget them? Uwe > thanks > John > ________________________________ > From: Uwe Brauer > Sent: Monday, July 29, 2024 11:21 AM > To: John Ciolfi > Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji > Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: >> Okay, I'll look into seeing if we can call it default. > Any news? > I also would like before we move > 1. Do some rebasing and make the graph a bit leaner > 2. Delete some very old branches which are merged into master a long time ago. > 3. That most likely will imply that everybody should then clone > again once we move to github, since I am not sure that the rebasing > and deleting branches will not break things. > Uwe >> ________________________________ >> From: Uwe Brauer >> Sent: Wednesday, July 17, 2024 2:32 PM >> To: John Ciolfi >> Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji >> Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: >> Hi >>> Hi >>> For the main branch, the convention is to use "main" in github. I'm >>> not sure if there's a way to switch from that. If possible, I'd like >>> to use that. Here's an example of a MathWorks sponsored project, >>> https://github.com/mathworks/MATLAB-language-server. >> Ah, well, this is true for repositories you start on github/gitlab etc nowadays. >> Some remarks >> 1. In git you can rename branches easily (while in mercurial you >> would need the evolve extension, and even then it is more >> complicated). Historically the «main» branch was called «master». >> But on political reasons «main» is now preferred. >> 2. As I said we push an existing repository, that is different from >> creating an empty one in github. For me using the name «default» >> would simplify things considerably especially now, since I had to >> upgrade my Ubuntu system and the most recent mercurial version is >> less flexible concerning the hg-git exporter. >> 3. So I propose we start with default, if we see that a lot of >> people want to contribute and are confused by this name, we might >> reconsider (this also gives me time to look for a technical >> solution) >> Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-07-29 17:27:28
|
>>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi > I haven't spent time looking into how to make the branch 'default' > (too many other items on my plate). I did this in the past, without problems, I am just retrying it again and tell you the details later. > Once that's done, I can upload the repo to github. I am not sure what you mean by upload. > My original proposal was to start fresh in github and keep the older > history in Source Forge as this is simpler. Is that okay? Ah wait, I am confused. That defies a bit the idea of a version control system, doesn't it? I mean I understand that you are not interested in very old versions, that is why I proposed some cleanup, rebase and deleting old branches. But, please note, that our repository is about 5 MB even less. For example GNU emacs, goes way back at least to 1995 (using RCS), and well it is about 1GB. But I can see the benefits of having a long history. Another problem are the branches that are yet not even merged. Do you want to delete and forget them? Uwe > thanks > John > ________________________________ > From: Uwe Brauer > Sent: Monday, July 29, 2024 11:21 AM > To: John Ciolfi > Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji > Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: >> Okay, I'll look into seeing if we can call it default. > Any news? > I also would like before we move > 1. Do some rebasing and make the graph a bit leaner > 2. Delete some very old branches which are merged into master a long time ago. > 3. That most likely will imply that everybody should then clone > again once we move to github, since I am not sure that the rebasing > and deleting branches will not break things. > Uwe >> ________________________________ >> From: Uwe Brauer >> Sent: Wednesday, July 17, 2024 2:32 PM >> To: John Ciolfi >> Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji >> Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: >> Hi >>> Hi >>> For the main branch, the convention is to use "main" in github. I'm >>> not sure if there's a way to switch from that. If possible, I'd like >>> to use that. Here's an example of a MathWorks sponsored project, >>> https://github.com/mathworks/MATLAB-language-server. >> Ah, well, this is true for repositories you start on github/gitlab etc nowadays. >> Some remarks >> 1. In git you can rename branches easily (while in mercurial you >> would need the evolve extension, and even then it is more >> complicated). Historically the «main» branch was called «master». >> But on political reasons «main» is now preferred. >> 2. As I said we push an existing repository, that is different from >> creating an empty one in github. For me using the name «default» >> would simplify things considerably especially now, since I had to >> upgrade my Ubuntu system and the most recent mercurial version is >> less flexible concerning the hg-git exporter. >> 3. So I propose we start with default, if we see that a lot of >> people want to contribute and are confused by this name, we might >> reconsider (this also gives me time to look for a technical >> solution) >> Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-07-29 17:03:17
|
To be clear on the proposal, I would place the latest version matlab-mode in github with a reference to the project history in Source Forge in the main README.org file ________________________________ From: John Ciolfi via Matlab-emacs-discuss <mat...@li...> Sent: Monday, July 29, 2024 12:50 PM To: Uwe Brauer <ou...@ma...> Cc: mat...@li... <mat...@li...> Subject: Re: [Matlab-emacs-discuss] Move of matlab-mode from Source Forge to github Hi I haven't spent time looking into how to make the branch 'default' (too many other items on my plate) Once that's done, I can upload the repo to github. My original proposal was to start fresh in github and keep the older history in Source Forge as this is simpler. Is that okay? thanks John ________________________________ From: Uwe Brauer Sent: Monday, July 29, 2024 11:21 AM To: John Ciolfi Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: > Okay, I'll look into seeing if we can call it default. Any news? I also would like before we move 1. Do some rebasing and make the graph a bit leaner 2. Delete some very old branches which are merged into master a long time ago. 3. That most likely will imply that everybody should then clone again once we move to github, since I am not sure that the rebasing and deleting branches will not break things. Uwe > ________________________________ > From: Uwe Brauer > Sent: Wednesday, July 17, 2024 2:32 PM > To: John Ciolfi > Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji > Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi >> Hi >> For the main branch, the convention is to use "main" in github. I'm >> not sure if there's a way to switch from that. If possible, I'd like >> to use that. Here's an example of a MathWorks sponsored project, >> https://github.com/mathworks/MATLAB-language-server<https://github.com/mathworks/MATLAB-language-server>. > Ah, well, this is true for repositories you start on github/gitlab etc nowadays. > Some remarks > 1. In git you can rename branches easily (while in mercurial you > would need the evolve extension, and even then it is more > complicated). Historically the «main» branch was called «master». > But on political reasons «main» is now preferred. > 2. As I said we push an existing repository, that is different from > creating an empty one in github. For me using the name «default» > would simplify things considerably especially now, since I had to > upgrade my Ubuntu system and the most recent mercurial version is > less flexible concerning the hg-git exporter. > 3. So I propose we start with default, if we see that a lot of > people want to contribute and are confused by this name, we might > reconsider (this also gives me time to look for a technical > solution) > Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-07-29 16:52:16
|
Hi I haven't spent time looking into how to make the branch 'default' (too many other items on my plate) Once that's done, I can upload the repo to github. My original proposal was to start fresh in github and keep the older history in Source Forge as this is simpler. Is that okay? thanks John ________________________________ From: Uwe Brauer Sent: Monday, July 29, 2024 11:21 AM To: John Ciolfi Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: > Okay, I'll look into seeing if we can call it default. Any news? I also would like before we move 1. Do some rebasing and make the graph a bit leaner 2. Delete some very old branches which are merged into master a long time ago. 3. That most likely will imply that everybody should then clone again once we move to github, since I am not sure that the rebasing and deleting branches will not break things. Uwe > ________________________________ > From: Uwe Brauer > Sent: Wednesday, July 17, 2024 2:32 PM > To: John Ciolfi > Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji > Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi >> Hi >> For the main branch, the convention is to use "main" in github. I'm >> not sure if there's a way to switch from that. If possible, I'd like >> to use that. Here's an example of a MathWorks sponsored project, >> https://github.com/mathworks/MATLAB-language-server. > Ah, well, this is true for repositories you start on github/gitlab etc nowadays. > Some remarks > 1. In git you can rename branches easily (while in mercurial you > would need the evolve extension, and even then it is more > complicated). Historically the «main» branch was called «master». > But on political reasons «main» is now preferred. > 2. As I said we push an existing repository, that is different from > creating an empty one in github. For me using the name «default» > would simplify things considerably especially now, since I had to > upgrade my Ubuntu system and the most recent mercurial version is > less flexible concerning the hg-git exporter. > 3. So I propose we start with default, if we see that a lot of > people want to contribute and are confused by this name, we might > reconsider (this also gives me time to look for a technical > solution) > Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-07-29 15:26:51
|
>>> "JC" == John Ciolfi <ci...@ma...> writes: > Okay, I'll look into seeing if we can call it default. Any news? I also would like before we move 1. Do some rebasing and make the graph a bit leaner 2. Delete some very old branches which are merged into master a long time ago. 3. That most likely will imply that everybody should then clone again once we move to github, since I am not sure that the rebasing and deleting branches will not break things. Uwe > ________________________________ > From: Uwe Brauer > Sent: Wednesday, July 17, 2024 2:32 PM > To: John Ciolfi > Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji > Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: > Hi >> Hi >> For the main branch, the convention is to use "main" in github. I'm >> not sure if there's a way to switch from that. If possible, I'd like >> to use that. Here's an example of a MathWorks sponsored project, >> https://github.com/mathworks/MATLAB-language-server. > Ah, well, this is true for repositories you start on github/gitlab etc nowadays. > Some remarks > 1. In git you can rename branches easily (while in mercurial you > would need the evolve extension, and even then it is more > complicated). Historically the «main» branch was called «master». > But on political reasons «main» is now preferred. > 2. As I said we push an existing repository, that is different from > creating an empty one in github. For me using the name «default» > would simplify things considerably especially now, since I had to > upgrade my Ubuntu system and the most recent mercurial version is > less flexible concerning the hg-git exporter. > 3. So I propose we start with default, if we see that a lot of > people want to contribute and are confused by this name, we might > reconsider (this also gives me time to look for a technical > solution) > Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-07-17 19:57:05
|
Okay, I'll look into seeing if we can call it default. Thanks ________________________________ From: Uwe Brauer Sent: Wednesday, July 17, 2024 2:32 PM To: John Ciolfi Cc: Uwe Brauer; mat...@li...; Nidish Narayanaa Balaji Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: Hi > Hi > For the main branch, the convention is to use "main" in github. I'm > not sure if there's a way to switch from that. If possible, I'd like > to use that. Here's an example of a MathWorks sponsored project, > https://github.com/mathworks/MATLAB-language-server. Ah, well, this is true for repositories you start on github/gitlab etc nowadays. Some remarks 1. In git you can rename branches easily (while in mercurial you would need the evolve extension, and even then it is more complicated). Historically the «main» branch was called «master». But on political reasons «main» is now preferred. 2. As I said we push an existing repository, that is different from creating an empty one in github. For me using the name «default» would simplify things considerably especially now, since I had to upgrade my Ubuntu system and the most recent mercurial version is less flexible concerning the hg-git exporter. 3. So I propose we start with default, if we see that a lot of people want to contribute and are confused by this name, we might reconsider (this also gives me time to look for a technical solution) Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: Uwe B. <ou...@ma...> - 2024-07-17 19:42:42
|
>>> "JC" == John Ciolfi <ci...@ma...> writes: Hi > Hi > For the main branch, the convention is to use "main" in github. I'm > not sure if there's a way to switch from that. If possible, I'd like > to use that. Here's an example of a MathWorks sponsored project, > https://github.com/mathworks/MATLAB-language-server. Ah, well, this is true for repositories you start on github/gitlab etc nowadays. Some remarks 1. In git you can rename branches easily (while in mercurial you would need the evolve extension, and even then it is more complicated). Historically the «main» branch was called «master». But on political reasons «main» is now preferred. 2. As I said we push an existing repository, that is different from creating an empty one in github. For me using the name «default» would simplify things considerably especially now, since I had to upgrade my Ubuntu system and the most recent mercurial version is less flexible concerning the hg-git exporter. 3. So I propose we start with default, if we see that a lot of people want to contribute and are confused by this name, we might reconsider (this also gives me time to look for a technical solution) Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |
From: John C. <ci...@ma...> - 2024-07-17 17:46:26
|
Hi For the main branch, the convention is to use "main" in github. I'm not sure if there's a way to switch from that. If possible, I'd like to use that. Here's an example of a MathWorks sponsored project, https://github.com/mathworks/MATLAB-language-server. As a side note, I have the MATLAB language server working in Emacs locally with https://github.com/emacs-lsp/lsp-mode. After we get the github area setup, I'll send in these changes. Yes, agreed on the ELPA. We'll help with that. Thanks John ________________________________ From: Uwe Brauer <ou...@ma...> Sent: Tuesday, July 16, 2024 10:58 AM To: John Ciolfi <ci...@ma...> Cc: mat...@li... <mat...@li...>; Uwe Brauer <ou...@ma...>; Nidish Narayanaa Balaji <nid...@il...> Subject: Re: Move of matlab-mode from Source Forge to github >>> "JC" == John Ciolfi <ci...@ma...> writes: hi > Hi > We'd like to move matlab-mode from Source Forge to github, > https://github.com/MathWorks/Emacs-MATLAB-Mode<https://github.com/MathWorks/Emacs-MATLAB-Mode>, which gives us a good > location for the "master" matlab-mode in github along with the > benefits of github. Note, there are already many copies of matlab-mode > in other github areas. > The process for managing matlab-mode will remain the same - Uwe Brauer > will be the primary maintainer. > This proposal has mostly cleared internally within MathWorks. I'd like > to ask non-MathWorker contributors to matlab-mode if this is, okay? > Nidish and Uwe as recent non-MathWorker contributors can you reply to > this with if you like or dislike this proposal. Yes I am, but let me add two remarks, in order to be sure we are in the same boat. 1. The main dev branch will be renamed from master to default (that simplify things on my side). I would like to rename the branch before the move. 2. The package is intended also to be in ELPA (there is still a problem with a signature from one author) I think we agreed on this before, I just wanted to be sure. Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. |