58 Matching Annotations
  1. Oct 2021
  2. May 2021
    1. No it doesn't. I've simply told SvelteKit to ignore the type error from credentials missing. If there's some other issue or missing feature it's not blocked by this. That being said, I wouldn't mind getting this change in
    1. New changes to the old repositories can be imported into the monorepo and merged in. For example, in the above example, say repository one had a branch my_branch which continued to be developed after the migration. To pull those changes in:
    1. Let's say that we want to extract a piece of a repository, with the intent on merging just that piece into some other bigger repo.
  3. Apr 2021
  4. Feb 2021
    1. Another HD wallet solution to generate privacy is a so-called merge and re-split operation. In this example, several entities anonymously submit new addresses to a smart contract. The contract collects the same amount from each party, let's say it's 100 bitcoins each. Then the contract re-deploys the amount to the new addresses.

      workaround to avoid full trace with attribution

    1. Rebasing For feature/topic branches, you should always use the --rebase flag to git pull, or if you are usually handling many temporary "to be in a github pull request" branches, run the following to automate this: git config branch.autosetuprebase local

      That's what I keep telling people. Glad to see I'm not the only one...

  5. Jan 2021
    1. On the linked thread I've put details, a suggestion for implementation and an offer of help if someone wants to submit a PR. Let's see what happens!

      If you've done all that work, why not just submit the PR yourself? Maybe the implementation was too incomplete/untested...

  6. Dec 2020
    1. It works very well, especially since the current Gimp roadmap relegates CMYK support to a version Gimp 3.2 However to be fairquoteShould a new developer join the team to specifically work on CMYK-related features, we will do our best to help him/her to complete this project and get it to our users as soon as possible.unquoteNot holding my breath.
    1. No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

      This could be both good and bad.

      potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.

      Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.

      Ah, good, I see they touched on some of these points in the sections:

      • Benefits of patching over forking
      • When to fork instead
  7. Nov 2020
  8. Oct 2020
    1. 2011-06-23 at OSBridge2011 having lunch with Ward, Tantek exclaimed: The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web. #osb11 lunch table. #diso #indieweb

      This is what I want too!

  9. Sep 2020
  10. Aug 2020
    1. New information that would be useful toward the future usage or troubleshooting of GitLab should not be written directly in a forum or other messaging system, but added to a docs MR and then referenced, as described above.
    2. When you encounter new information not available in GitLab’s documentation (for example, when working on a support case or testing a feature), your first step should be to create a merge request (MR) to add this information to the docs. You can then share the MR in order to communicate this information.
    1. Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed? No. Merge requests submitted to this project will be closed automatically.
  11. Jul 2020
  12. May 2020
    1. The merge request must not contain more than 10 commit messages. This rule is maybe the most controversial.
    2. With single-commit MRs I often can copy the commit message directly into the MR description, which is convenient.
  13. Apr 2020
    1. In particular, I, quite accidentally, became a maintainer of ActsAsTaggableOn, a Rails tagging engine, after bumping a long-stale, minor, pull-request I had written.
  14. Mar 2020
    1. Don't be discouraged when you get feedback about a method that isn't all sunshine and roses. Facets has been around long enough now that it needs to maintain a certain degree of quality control, and that means serious discernment about what goes into the library. That includes having in depth discussions the merits of methods, even about the best name for a method --even if the functionality has been accepted the name may not.

      about: merits

  15. Feb 2020
    1. it is worth opening a merge request with the minimal viable change instead of opening an issue encouraging open feedback on the problem without proposing any specific change directly.
  16. Jan 2020
  17. Aug 2019
  18. Oct 2017
    1. At the same time, the whole logic of

      from [::text] manifesto