72 Matching Annotations
  1. Sep 2024
    1. On many occasions, I've opened up requests for support in the form of a Github pull request. This way, I am telling the author: I have found a potential problem with your library, here is how I fixed it for my circumstance, here is the code I used for reference. You get extra internet points if you open the pull request with: "I don't expect this pull request to get merged, but I wanted to you show you what I did".
    2. Not everyone has time to adhere to the specific coding styles for a project, so if you can't do a full blown pull-request, there is NOTHING wrong with opening a pull-request that only has the intention of showing the author how you solved the problem.
  2. May 2024
    1. When updates are generatedconcurrently and then merged, the next update containsmultiple predecessors

      Given many updates are merged at the same time pointers are = many. But given we merge right away having learned an update - we always merge two updates - hence two pointers.

    1. Smart Merge is built on a customized adaptation of Myer's diff algorithm and Google's diff-match-patch

      The Git's way. Snapshots as the source of truth, derive deltas to merge.

  3. Mar 2024
  4. Jan 2024
    1. we should break down and MR into "Blocks"
    2. Code block Metadata block Note block MR block (we should still be able to interact with the MR as a whole thing, e.g. leaving a generic comment on the whole thing)
    3. A user wants to comment on a single parameter name in a function. It is highlighted as a unique part of the syntax tree, and they're not happy with the particular name the author of the MR chose. Problem: The user can only comment on the entire line, because "lines" are considered the most fundamental building block in our Diffs UI.
    4. A user notices that an unchanged part of the diff already has features that are being implemented in the changes in the MR. The user leaves a comment on the unchanged part of the diff, telling the author that what they're trying to do is already present. Problem: The author cannot see that comment in the Changes tab, because the comment is outside the understood scope of the diff.
    5. A reviewer would like to open a discussion on the MR description because they disagree with some of the conclusions, but want more clarification. Problem: The only way to have a conversation about the MR metadata (like title, description, labels, etc.) is to open a generic note on the whole MR. There's no way to scope a discussion to a part of the MR.
  5. Feb 2023
    1. In very large code bases, it is likely impossible to make a change to a fundamental API and get it code reviewed by every affected team before merge conflicts force the process to start over again.
  6. Nov 2022
  7. Oct 2021
  8. 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.
  9. Apr 2021
  10. 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...

  11. 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...

  12. 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
  13. Nov 2020
  14. 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!

  15. Sep 2020
  16. 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.
  17. Jul 2020
  18. 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.
  19. 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.
  20. 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

  21. 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.
  22. Jan 2020
  23. Aug 2019
  24. Oct 2017
    1. At the same time, the whole logic of

      from [::text] manifesto