Assess the team’s trunk-based development maturity. Ensure developers are comfortable with concepts like rebasing over merging, using short-lived branches, and rapid integration before layering on stacking.

I closing this issue because this PR #91416 got merged, if you face any issue please feel free to post your comments if required I'll open this issue.

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

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.

When updates are generatedconcurrently and then merged, the next update containsmultiple predecessors

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

163

we should break down and MR into "Blocks"

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)

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.

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.

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.

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.

Not trying to be presumptuous, but thought this proposal would be best served with a PR.

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

If you would like to make a code change, go ahead. Fork the repository, open a pull request. Do this early, and talk about the change you want to make. Maybe we can work together on it.

kdiff3 can be used solely with keyboard, so 5 conflict file takes when reading the code just few minutes.

Thanks. Worked for me. I needed to move the merged directory into a sub-folder so after following the above steps I simply used git mv source-dir/ dest/new-source-dir

In case you want to put project-a into a subdirectory, you can use git-filter-repo (filter-branch is discouraged)

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:

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.

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.

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

Any idea @AaronLasseigne if this is mergeable?

Fork rails, add github.com/georgebrock/rails as a remote, merge this branch into rails/4.0.2 (the tag), and then use your fork of Rails: gem 'rails', github: 'yourusername/rails'

This branch is 22 commits ahead, 207 commits behind newsapps:master.

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!

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.

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.

Can this be merged please, this fixes a problem I have

May I ask what is holding this back?

You can also see this repo: default-passive-events.

I see this issue has 2 open PR's is this going to be finalized anytime soon?

Furthermore, how come there's a PR open since 3 months, at what seems to be the authoritative repo for Svelte?

I'm happy to accept PRs :)

Bonus SSR bugs I bumped into and fixed while addressing this:

I'm not going to work on this myself, but if somebody comes up with a patch, I'd be happy to review and merge.

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

But maybe this PR should still be merged until he finds time for that?

Sorry this sat for so long!

The feature is highly likely to be implemented, the API and implementation are the only real topics of discussion right now.

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.

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.

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.

Problem is, everyone's busy, so it can be days or even weeks before even a small PR is merged. So I'm stashing my stuff here as I write it. I'll still try to keep the PRs in motion, to gradually get some of this merged.

Edit this page Request docs changes

so that we would accept proposed changes from the community around this feature.

If people care about a missing feature, then ideally the issue should be marked as ~"Accepting merge requests"

The merge request must not contain more than 10 commit messages. This rule is maybe the most controversial.

With single-commit MRs I often can copy the commit message directly into the MR description, which is convenient.

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.

Test on more recent rubies

in order to track the always-improving upstream project, we continuously rebase our patches on top of the upstream master

Maybe you could provide a patch with tests and we could discuss on top of it?

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.

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.

We don’t use merge commits.

I've forked the project and made a substantial extension. I think is ready to merge back. But (appropriately) its the project owner who gets to make that call not me. And it's now been several weeks without reply.

At the same time, the whole logic of