Re: updating merge request
On 2023-01-19 11:01 pm, Werner LEMBERG wrote: [SNIP] Nope. The preferred way is to make the MR's commit as pretty as possible. No final squashing. That *almost* seems like squashing, but with more steps. Certainly, there is nothing to squash if everything is expressed neatly in one commit. At the end of the day, it makes for a nice clean history in the main line either way you approach. The only critique might come down to where one is expected to apply their effort. When possible, engineers should take advantage of automated systems so their time is spent primarily on the problem at hand. That could mean using linters to reformat code, leveraging continuous integration to run test suites, or (in this case) letting repositories systematically squash (or rebase, or whatever) when accepting requests. It saves contributors making ambiguous choices and/or doing what amounts to busy work. I will need to remember to keep my branches tidy before I submit anything, since I cannot rely on squash as a crutch. -- Aaron Hill
Re: Documentation viewer in Frescobaldi
Where is the Frescobaldi mailing list? Do you mean Google Groups? Andrew On 20/01/2023 8:09 pm, Federico Bruni wrote: The answer to the other questions is more complex. We are working on it... I will reply to your question in the Frescobaldi mailing list.
Re: Documentation viewer in Frescobaldi
Yes, I mean the Google Group Il giorno ven 20 gen 2023 alle 20:43:02 +1100, Andrew Bernard ha scritto: Where is the Frescobaldi mailing list? Do you mean Google Groups? Andrew On 20/01/2023 8:09 pm, Federico Bruni wrote: The answer to the other questions is more complex. We are working on it... I will reply to your question in the Frescobaldi mailing list.
Re: updating merge request
Le 20/01/2023 à 10:36, Aaron Hill a écrit : On 2023-01-19 11:01 pm, Werner LEMBERG wrote: [SNIP] Nope. The preferred way is to make the MR's commit as pretty as possible. No final squashing. That *almost* seems like squashing, but with more steps. Certainly, there is nothing to squash if everything is expressed neatly in one commit. At the end of the day, it makes for a nice clean history in the main line either way you approach. The only critique might come down to where one is expected to apply their effort. When possible, engineers should take advantage of automated systems so their time is spent primarily on the problem at hand. That could mean using linters to reformat code, leveraging continuous integration to run test suites, or (in this case) letting repositories systematically squash (or rebase, or whatever) when accepting requests. It saves contributors making ambiguous choices and/or doing what amounts to busy work. I will need to remember to keep my branches tidy before I submit anything, since I cannot rely on squash as a crutch. In our case, Gitlab's feature to automatically squash all commits upon merging doesn't fit the bill because we often do MRs with multiple commits that we *do* want to end up as separate commits in master (Lukas gave an exampe). Rewriting history is just something that one might not be used to coming from other projects, but perfectly fine for our purposes. In the end, doing "git commit --amend --no-edit" isn't more work than "git commit -m 'fix it'", especially with an alias. In case that helps anyone, I have these in my ~/.gitconfig, to make editing the history more convenient: [alias] reword = commit --amend pushfl = push --force-with-lease sync = rebase master rework = !git rebase -i $(git merge-base HEAD master) continue = rebase --continue abort = rebase --abort fixup = commit --amend -a --no-edit select-fixup = commit --amend --no-edit Jean OpenPGP_signature Description: OpenPGP digital signature
Re: updating merge request
Le 20/01/2023 à 08:05, Lukas-Fabian Moser a écrit : (Personally, I use two local branches for developing a feature: one in which I keep track of my progress by adding commit after commit, and one which is the "squashed" version that I update with amend/squash and use for pushing. git's interactive rebase feature is my best friend here. But there might be better methods.) That must be time-consuming. Out of interest, why do you feel the need to maintain this separate branch instead of just amending the one that is being submitted? Or do you only do it before submitting but don't keep it in sync afterwards? Jean OpenPGP_signature Description: OpenPGP digital signature
Re: updating merge request
On 2023-01-20 3:22 am, Jean Abou Samra wrote: Rewriting history is just something that one might not be used to coming from other projects, but perfectly fine for our purposes. It was impressed upon me to treat rewriting history as fraught with peril, potentially even Bad(tm) in the Ghostbusters sense: "Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light." -- Egon Spengler One might argue that anything in your development branch is not really part of "history" yet as it has not been accepted. (The situation gets murkier when people are forking forks.) As such, it *should* be safe to mess about with commits to clean up typos or catch missing files, what have you. And I would agree this results in a cleaner submission that is easier to review for correctness. (I probably should clarify my earlier comments that I do not intentionally make my commits messy, just that I usually do not stress about them being so absolutely pristine; again, I am used to work being squashed, so any niceness I put in there gets lost.) So I can see --amend being useful for the little things. But let's say during a review, it is determined that the scope could increase to cover more items than originally planned but that still feels part of the same submission. (Anything too distinct really should be an independent request.) Now, you might not necessarily want to force all of the new development work into the existing commit. Reviewers might even appreciate seeing the individual slices of the task more cleanly delineated. In a sense, there is some "history" to the process that might be worth preserving during this stage. -- Aaron Hill
Re: updating merge request
At first I saw it like you Aaron, but after thinking about this for the last several hours it occurred to me that we're only rewriting the history of the current MR, we're not junking a big part of the project. The idea is that given that there's no squash upon acceptance, the history in the MR will go in "as is". I do see the value in this, and I'd think you'll want a judicious user of git, with a developed taste for repo grooming to use a mix of history rewrites and additions during the lifetime of an MR if there's back and forth on it. I do keep my commit history very clean while working, I'd put in maybe up to 8-10 commits, and then pause and rebase -i onto that until I'm happy that the story told by the commits to my colleagues is sensible. At that point I push, because our stuff is not MR-based. But for the projects based on MR's we always did "squash on merge", which left me uneasy. I must say I do prefer that the contributor does have a say in how to best represent their work as a series of commits, so although it's scary and "different", I feel this idea of force-pushing amends and such onto an MR is actually a nice idea. Luca On Fri, Jan 20, 2023 at 3:03 PM Aaron Hill wrote: > On 2023-01-20 3:22 am, Jean Abou Samra wrote: > > Rewriting history is just something that one might not be used to > > coming > > from other projects, but perfectly fine for our purposes. > > It was impressed upon me to treat rewriting history as fraught with > peril, potentially even Bad(tm) in the Ghostbusters sense: > > "Try to imagine all life as you know it stopping instantaneously and > every molecule in your body exploding at the speed of light." -- > Egon Spengler > > One might argue that anything in your development branch is not really > part of "history" yet as it has not been accepted. (The situation gets > murkier when people are forking forks.) As such, it *should* be safe to > mess about with commits to clean up typos or catch missing files, what > have you. And I would agree this results in a cleaner submission that > is easier to review for correctness. (I probably should clarify my > earlier comments that I do not intentionally make my commits messy, just > that I usually do not stress about them being so absolutely pristine; > again, I am used to work being squashed, so any niceness I put in there > gets lost.) > > So I can see --amend being useful for the little things. But let's say > during a review, it is determined that the scope could increase to cover > more items than originally planned but that still feels part of the same > submission. (Anything too distinct really should be an independent > request.) Now, you might not necessarily want to force all of the new > development work into the existing commit. Reviewers might even > appreciate seeing the individual slices of the task more cleanly > delineated. In a sense, there is some "history" to the process that > might be worth preserving during this stage. > > > -- Aaron Hill > > -- Luca Fascione
Re: RFC: require librsvg to implement SVG image support
[In case people are wondering why I’m not replying: I want to actually see what it takes to cross-compile Poppler, this takes time, and I don’t have a lot of it ATM, hence the delay.]
Re: updating merge request
Lukas-Fabian Moser writes: > Am 20.01.23 um 07:38 schrieb Aaron Hill: > >> On 2023-01-19 8:54 pm, David Zelinsky wrote: >> >>> Am I misunderstanding something? Or is what it says in 3.2 a mistake? >> >> If GitLab works similar to GitHub ... > > Accepted practice in lilypond development is different. We all rewrite > history ... Gitlab itself has the feature of keeping track of the > various versions of a merge requests and letting us browse them > conveniently. Ok, I understand this now. It took me a while but I finally found where this is explained: https://docs.gitlab.com/ee/user/project/merge_requests/versions.html I wish this were documented more prominently, both in the GitLab docs and in the Contributor's Guide, since it's a GitLab feature that is quite different from (some might say contrary to) the usual git behavior. Granted it is mentioned in GC 3.2, but, without more explanation, to someone experienced with git but not GitLab it just sounds mysterious, or like a mistake. Maybe the CG could include the above link. > Note that it's not strictly necessary that a merge request consists of > one commit only: Logically independent "smallish" commits are fine > (possible example: one commit for the feature, one for the larger > documentation revision the feature necessitates). But always make sure > that each single commit gives a "working" version of LilyPond in order > to allow for bisecting later ... I see the logic in this. In my case, most of the the MR reviews were pointing out typos or small stylistic corrections. I can see that it makes sense to fix those with an --amend. But one of the reviews (Jean's) suggested adding a few inline examples in the documentation I had written. Is that something that's worth including as a new commit? Both versions are complete and valid; it's just a question of which is better. After everyone sees the examples I've added, the consensus *might* be the original version was best. Does that make sense? > (Personally, I use two local branches for developing a feature: one in > which I keep track of my progress by adding commit after commit, and > one which is the "squashed" version that I update with amend/squash > and use for pushing. git's interactive rebase feature is my best > friend here. But there might be better methods.) Yes, in any case I have no intention of overwriting my own local history. I like to commit frequently, so each commit reflects some specific change, not a bunch of different things. I will rebase -i on a parellel branch and squash the things that don't warrant new commits in the MR. -David
Re: updating merge request
Le 20/01/2023 à 15:03, Aaron Hill a écrit : On 2023-01-20 3:22 am, Jean Abou Samra wrote: Rewriting history is just something that one might not be used to coming from other projects, but perfectly fine for our purposes. It was impressed upon me to treat rewriting history as fraught with peril, potentially even Bad(tm) in the Ghostbusters sense: "Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light." -- Egon Spengler One might argue that anything in your development branch is not really part of "history" yet as it has not been accepted. (The situation gets murkier when people are forking forks.) As such, it *should* be safe to mess about with commits to clean up typos or catch missing files, what have you. And I would agree this results in a cleaner submission that is easier to review for correctness. (I probably should clarify my earlier comments that I do not intentionally make my commits messy, just that I usually do not stress about them being so absolutely pristine; again, I am used to work being squashed, so any niceness I put in there gets lost.) Indeed, overwriting history is Very Bad™ for shared branches, but not really a problem for development branches as long as a single developer edits them. So I can see --amend being useful for the little things. But let's say during a review, it is determined that the scope could increase to cover more items than originally planned but that still feels part of the same submission. (Anything too distinct really should be an independent request.) Now, you might not necessarily want to force all of the new development work into the existing commit. Reviewers might even appreciate seeing the individual slices of the task more cleanly delineated. In a sense, there is some "history" to the process that might be worth preserving during this stage. Yes, exactly! And that is what our process is designed to facilitate :) If there are two commits in the MR Commit A: add XYZ Commit B: take advantage of XYZ to better reimplement QRST and you want to modify XYZ to address reviewers' suggestions, the more "usual" workflow is adding a new commit on top, yielding Commit A: add XYZ Commit B: take advantage of XYZ to better reimplement QRST Commit C: fix typo in XYZ whereas in our process, you "rebase -i" to get Commit A: add XYZ [amended version with a different commit ID] Commit B: take advantage of XYZ to better reimplement QRST [also a new commit ID] and * the next reviewer who looks at the MR sees only the logical structure, not cluttered by the fixes, * everything can be cleanly integrated into master as-is, without squashing A and B (which you would need if you wanted C not to be separate from A, due to the ordering). IOW: it may seem counterintuitive, but our workflow that involves editing commits in-place instead of adding more commits is precisely aimed at allowing more structure between the commits, by making the history of the branch reflect what you eventually want to end up in the repo, a *logical* structure, rather than the temporal structure driven by "I just happened to fix this before that". Not that I am an out-and-out fan of this workflow, but its tradeoffs have served us well so far, I would say. While this may not be the most usual workflow with GitHub/GitLab, it's not unheard of at all. E.g., the more traditional email-based workflow (in Git itself, the Linux kernel, many GNU projects, etc.) has the same logical separation of commits where you amend patches even after making more patches on top of them. https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#separate-your-changes OpenPGP_signature Description: OpenPGP digital signature
Re: updating merge request
Le 20/01/2023 à 23:45, David Zelinsky a écrit : Note that it's not strictly necessary that a merge request consists of one commit only: Logically independent "smallish" commits are fine (possible example: one commit for the feature, one for the larger documentation revision the feature necessitates). But always make sure that each single commit gives a "working" version of LilyPond in order to allow for bisecting later ... I see the logic in this. In my case, most of the the MR reviews were pointing out typos or small stylistic corrections. I can see that it makes sense to fix those with an --amend. But one of the reviews (Jean's) suggested adding a few inline examples in the documentation I had written. Is that something that's worth including as a new commit? Both versions are complete and valid; it's just a question of which is better. After everyone sees the examples I've added, the consensus *might* be the original version was best. Does that make sense? Not worth a separate commit IMHO. (Objections against adding examples seem unlikely.) (Personally, I use two local branches for developing a feature: one in which I keep track of my progress by adding commit after commit, and one which is the "squashed" version that I update with amend/squash and use for pushing. git's interactive rebase feature is my best friend here. But there might be better methods.) Yes, in any case I have no intention of overwriting my own local history. I like to commit frequently, so each commit reflects some specific change, not a bunch of different things. I will rebase -i on a parellel branch and squash the things that don't warrant new commits in the MR. As you wish, however this sounds like it will involve lots of busywork. In general, if splitting into multiple commits helps understanding, it should be in the branch submitted for review anyway. If it doesn't, it's not clear to me why you want the chronology for yourself, but it's your choice of course. OpenPGP_signature Description: OpenPGP digital signature
PATCHES - Countdown to January 23
Here is the current countdown report. The next countdown will begin on January 23rd. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1813 Fix issue 6521 - Thomas Morley https://gitlab.com/lilypond/lilypond/-/merge_requests/1813 !1787 Add PNG image support - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1787 Countdown: !1815 Update files for web server - Federico Bruni https://gitlab.com/lilypond/lilypond/-/merge_requests/1815 Review: !1817 LSR was updated to version 2.24 [2023-Jan-20] - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1817 !1816 expand documentation of defineBarLine - David Zelinsky https://gitlab.com/lilypond/lilypond/-/merge_requests/1816 New: No patches in New at this time. Waiting: !1810 Let \rhythm markup derive from current layout - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/1810 Cheers, Colin
New Chinese (simplified) PO file for 'lilypond' (version 2.23.80)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Chinese (simplified) team of translators. The file is available at: https://translationproject.org/latest/lilypond/zh_CN.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
