Skip to content
Snippets Groups Projects

[syntax_highlight] Update

  • Fixed bug which caused inline code spans of corrected messages to expand until the end of the buffer
  • Made checking for code spans/blocks more strict (XEP-0393 conform)
  • README Updates
  • Code Cleanup
Edited by Florian Münchbach

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Florian Münchbach mentioned in merge request !117 (merged)

    mentioned in merge request !117 (merged)

  • Do you want to jump from x.x.1 to x.x.3 ? seems unnecessary, but your decision.

    Could you remove the top merge commit?

  • Do you want to jump from x.x.1 to x.x.3

    Yeah, there is an intermediate commit for .2, that never made it into an MR, since requests and fixes kept coming. Plus, I didn't want to bother you with additional MRs ;)

    Could you remove the top merge commit?

    Is the merge an issuse here? Or is it Ok, if I fix the message? I've been in a hurry to open the MR before working day starts and ended up with a mess -.-

  • Yes i dont want merge commits in the history i dont see the value in having 10 atomic commits and then some merge commit that summarizes everything. Especially if it is a merge commit within your own repo, you could delete your repo tomorrow and this merge commit would mean absolutely nothing to us anymore.

    Generally dont use the merge command

    I have written some workflow tips down here https://dev.gajim.org/gajim/gajim/wikis/development/howtogit (Look at rebasing)

    Edited by Philipp Hörist
  • added 1 commit

    • 42b9aeb8 - [syntax_highlight] Update manifest.ini

    Compare with previous version

  • Florian Münchbach marked as a Work In Progress

    marked as a Work In Progress

  • Florian Münchbach changed the description

    changed the description

  • Yeah, you are absolutely right. In the morning, I've been under the impression that I could employ a nice workflow having a kind of a plugin specific dev branch and take stuff from there for integration into both, master and current version. Now, with much more Coffein in my system and an awoken mind I realized that this will not work that way anyways -.-

    I would like to keep the small commits on my side, because they actually do provide benefit for me. Should I squash them into one for the MR or are you doing (or letting Gitlab do) that during the merge?

    Once this one is ok, I will also update the one targeted at master...

    Next time, I'll make sure to have my first coffee before opening an MR ;)

  • If you squash your commits or not is your decision, you can set the option for squash in the MR, i will honor the value you set and will not change it.

  • Florian Münchbach unmarked as a Work In Progress

    unmarked as a Work In Progress

Please register or sign in to reply
Loading