Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add instructions to rebase and push branch before merging #267

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

yalsayyad
Copy link
Contributor

No description provided.

Copy link
Contributor

@jonathansick jonathansick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here are some suggestions on how to reorganize the content for flow.

work/flow.rst Outdated Show resolved Hide resolved
work/flow.rst Outdated Show resolved Hide resolved
@@ -474,11 +474,22 @@ We **always use non-fast forward merges** so that the merge point is marked in G

.. code-block:: bash

# Prepare to merge
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete this comment. Instead, before the code block, write:

First, prepare the merge by making sure the branch is up-to-date:

git checkout tickets/DM-NNNN
git rebase master
git push --force # so that the commits on the remote branch match the commits merged*
# Merge
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete this comment.

Now add the paragraph + list starting with "We force push..." here.

Then introduce a new code block:

Next, merge to ``master`` and push.
We **always use non-fast forward merges** so that the merge point is marked in Git history, with the merge commit containing the ticket number:

.. code-block:: bash

   git checkout master
   git merge --no-ff tickets/DM-NNNN
   git push

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means you can delete the identical paragraph, We **always use ... from before the two code blocks.

@timj timj force-pushed the tickets/DM-15548 branch 2 times, most recently from d9aa2ed to 58b2b31 Compare September 27, 2019 20:35
@timj
Copy link
Member

timj commented Sep 27, 2019

@yalsayyad I've rebased and dealt with the second half of @jonathansick 's comments.

@jonathansick
Copy link
Contributor

Please address this syntax error, rebase, then re-push.

https://travis-ci.com/lsst-dm/dm_dev_guide/builds/129509687#L653-L654

I'm guessing there are single backticks around master; they need to be double backticks to treat that word as a code literal instead of an API link.

Copy link
Contributor

@jonathansick jonathansick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@yalsayyad
Copy link
Contributor Author

Recent events inspired me to revisit this, and now I remember why I stopped. I'm torn with indecision on @jonathansick's suggestion. It flows a lot better and makes more sense. But I only read code blocks, and I worry that separating the git merge --no-ff tickets/DM-XXXXX from the git checkout master/git pull will just make people even MORE likely to skip the necessary steps before merging to master. Help.

@jdswinbank
Copy link
Contributor

I think revisiting this is a great idea. On balance, I'd probably go with Jonathan's wording, but I'd love to see this merged in either form.

@jdswinbank
Copy link
Contributor

Hey folks, can we just merge this? The issue is coming up again today, and I'd love to be able to point people to docs. Either wording is okay, and we should definitely avoid the whole perfect-and-the-good thing.

@jonathansick
Copy link
Contributor

Sorry, is anything waiting on me?

@jonathansick
Copy link
Contributor

To expand; I did approve this ages ago, so I'm also wondering why this isn't merged. Shall I just do the rebase and merge now?

@jdswinbank
Copy link
Contributor

I think @yalsayyad is conflicted by your suggestion and doesn't know which way to jump. 😀

Let's give her a few hours to call it, otherwise it's probably fine to just jump in and merge.

@parejkoj
Copy link
Contributor

It'll take a potentially exciting rebase now, but I do think we should still merge this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants