The general idea is okay and what I would suggest too, but he is using master as working branch.Morlic wrote:I useMatGB wrote: All I wanted to do was remove a single commit from my branch.for that. Drop the commit and pick everything else...Code: Select all
rebase -i
The Git/GitHub Questions, Answers and Howto Thread
Moderator: Committer
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: The Git/GitHub Questions, Answers and Howto Thread
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: The Git/GitHub Questions, Answers and Howto Thread
I encounter a new problem when trying to edit the FR stringtable with the GitHub web interface.
Usually, here's my process to edit the FR file (way quicker than doing it with Git):
- I enter the "Edit File" page (https://github.com/freeorion/freeorion/ ... les/fr.txt)
- In the textbox, I do a right-click then "Select All"
- Right-click again and I "Paste" my local FR file content
- Commit to master
But since today, when I "Select All", it also selects the line numbers, as a part of the file content!?
So, when I check the modifications ("Preview Changes"), it says that there are 12986 additions (because obviously of the line numbers selection).
I updated my web browser (FF 49.0.1) but nothing changed.
Do you have the same problem?
Thanks.
Usually, here's my process to edit the FR file (way quicker than doing it with Git):
- I enter the "Edit File" page (https://github.com/freeorion/freeorion/ ... les/fr.txt)
- In the textbox, I do a right-click then "Select All"
- Right-click again and I "Paste" my local FR file content
- Commit to master
But since today, when I "Select All", it also selects the line numbers, as a part of the file content!?
So, when I check the modifications ("Preview Changes"), it says that there are 12986 additions (because obviously of the line numbers selection).
I updated my web browser (FF 49.0.1) but nothing changed.
Do you have the same problem?
Thanks.
I release every updated file under the CC-BY-SA 3.0 license.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: The Git/GitHub Questions, Answers and Howto Thread
Happening for me as well. At least on a different file... if I try to select all on the huge stringtable page, it hangs firefox until I kill the task.
You can download the file by clicking "Raw", copy-paste it wherever, and then should be able to paste back into the text entry box. Having the line numbers doesn't seem to affect pasting.
You can download the file by clicking "Raw", copy-paste it wherever, and then should be able to paste back into the text entry box. Having the line numbers doesn't seem to affect pasting.
Re: The Git/GitHub Questions, Answers and Howto Thread
Ok, thanks, it comes from GitHub then.
I found a quick fix though:
# On the "Edit" page (by clicking on the Pencil icon):
- Place the text cursor at the beginning of the file (first line, first character)
- CTRL+SHIFT+END (it will select all the file content -and still the line numbers-, and will place the cursor at the end of the last line)
- DEL on the keyboard
- It will delete everything, and place again the cursor on the first line
- CTRL+V the full file content copied from your local file
- Check the modifications with "Preview Changes"... everything is OK!
And voilà. ^^
Note: weirdly, it doesn't work by using the right-click context menu commands "Select All" then "Delete". It will delete only the first line... ??
I found a quick fix though:
# On the "Edit" page (by clicking on the Pencil icon):
- Place the text cursor at the beginning of the file (first line, first character)
- CTRL+SHIFT+END (it will select all the file content -and still the line numbers-, and will place the cursor at the end of the last line)
- DEL on the keyboard
- It will delete everything, and place again the cursor on the first line
- CTRL+V the full file content copied from your local file
- Check the modifications with "Preview Changes"... everything is OK!
And voilà. ^^
Note: weirdly, it doesn't work by using the right-click context menu commands "Select All" then "Delete". It will delete only the first line... ??
I release every updated file under the CC-BY-SA 3.0 license.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: The Git/GitHub Questions, Answers and Howto Thread
The merge button on the github website has changed... Should I start doing something other than merging with a merge commit?
- Attachments
-
- merge button
- merge_pull_request.png (21.45 KiB) Viewed 12341 times
Re: The Git/GitHub Questions, Answers and Howto Thread
Hm, I'd say "rebase and merge" (the new option) should be what we use normally - Marcel?
Re: The Git/GitHub Questions, Answers and Howto Thread
I think it'll depend on the PR—Squash and Merge is good for small(ish) PRs that contain, say, a "typo fix" commit or similar, I use it a lot as most of my reviews are for scripting stuff where a single commit that I've written in main is better.
I'm assuming the bottom rebase option will merge the commits in themselves without a merge message, so they'll each standalone and thus ideally need well written commit messages. And I'm also assuming the top option is merge-as-is, which I've never liked but is better if/when we merge in a fairly big project that has a lot of commits over time, a summary commit at the top explaining the main changes is easier, especially as users of Test releases need to rely on the recent commits list to know what they're meant to be looking for test wise.
So I'd say preference should be for squash and merge or rebase, but occasionally a merge commit would be better.
I'm assuming the bottom rebase option will merge the commits in themselves without a merge message, so they'll each standalone and thus ideally need well written commit messages. And I'm also assuming the top option is merge-as-is, which I've never liked but is better if/when we merge in a fairly big project that has a lot of commits over time, a summary commit at the top explaining the main changes is easier, especially as users of Test releases need to rely on the recent commits list to know what they're meant to be looking for test wise.
So I'd say preference should be for squash and merge or rebase, but occasionally a merge commit would be better.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: The Git/GitHub Questions, Answers and Howto Thread
Merge and Commit for any PRs with more than one commit.
Rebase and merge for PRs that are already a single commit.
My reasons, are that the other options destroy information that is useful when debugging.
Squash and Merge
Squash and merge destroys context information in the multiple commits of a PR. If squashing the commits would make it easier to follow, then it should have been done in the PR before the merge.
As my current PRs make clear multiple commits make a PR easier to review. It also makes it easier to find and fix bugs after they are merged to master. It easier to find bugs if git-blame leads you to a focused commit where it is obvious what the original dev's intent was and how it is interacting poorly with the current code. Sometimes it is unclear because of subsequent changes in the code that couldn't be anticipated or caught in the original PR review.
Rebase and Merge
Rebase and merge destroys all of the branching information and folds all of the commits back into a linear commit history.
Rebase and merge makes the entire commit history look like old school CVS, giving up all of the post merge benefits of branches. It does not change the dates of the commits, so all commits of the merged branch and all other branches will be mixed in together.
github does not present the branching information prominently (or well), but many other tools do. To see the branching information in git bug click Graphs->Network and you can see where/when a PR was branched and where/when it merged. Again this is useful in debugging, because one PR is probably a series of related changes and seeing them in order allows you to see where things went wrong. Rebase and merge prevents this kind of debugging by destroying all of the branching information.
Rebase and merge is appropriate for small single commit PRs, like the commits that devs directly rebase and push onto master currently. The merge message would not have added any additional useful information to the commit record.,
Create a merge commit
This is the best option.
It keeps all of the branching information. Even if the original commits are over several weeks/months they are collected together. The arc of development is visible using most git tools and in github with Graphs->Network.
Having a merge message ties the whole PR together providing context for all of the changes as a set. We might consider asking contributors to include a merge message in their PR, or just use the initial PR message. Then the message is most like correct and not an additional burden on the merging dev.
Rebase and merge for PRs that are already a single commit.
My reasons, are that the other options destroy information that is useful when debugging.
Squash and Merge
Squash and merge destroys context information in the multiple commits of a PR. If squashing the commits would make it easier to follow, then it should have been done in the PR before the merge.
As my current PRs make clear multiple commits make a PR easier to review. It also makes it easier to find and fix bugs after they are merged to master. It easier to find bugs if git-blame leads you to a focused commit where it is obvious what the original dev's intent was and how it is interacting poorly with the current code. Sometimes it is unclear because of subsequent changes in the code that couldn't be anticipated or caught in the original PR review.
Rebase and Merge
Rebase and merge destroys all of the branching information and folds all of the commits back into a linear commit history.
Rebase and merge makes the entire commit history look like old school CVS, giving up all of the post merge benefits of branches. It does not change the dates of the commits, so all commits of the merged branch and all other branches will be mixed in together.
github does not present the branching information prominently (or well), but many other tools do. To see the branching information in git bug click Graphs->Network and you can see where/when a PR was branched and where/when it merged. Again this is useful in debugging, because one PR is probably a series of related changes and seeing them in order allows you to see where things went wrong. Rebase and merge prevents this kind of debugging by destroying all of the branching information.
Rebase and merge is appropriate for small single commit PRs, like the commits that devs directly rebase and push onto master currently. The merge message would not have added any additional useful information to the commit record.,
Create a merge commit
This is the best option.
It keeps all of the branching information. Even if the original commits are over several weeks/months they are collected together. The arc of development is visible using most git tools and in github with Graphs->Network.
Having a merge message ties the whole PR together providing context for all of the changes as a set. We might consider asking contributors to include a merge message in their PR, or just use the initial PR message. Then the message is most like correct and not an additional burden on the merging dev.
Re: The Git/GitHub Questions, Answers and Howto Thread
I love squash and merge.As my current PRs make clear multiple commits make a PR easier to review. It also makes it easier to find and fix bugs after they are merged to master. It easier to find bugs if git-blame leads you to a focused commit where it is obvious what the original dev's intent was and how it is interacting poorly with the current code. Sometimes it is unclear because of subsequent changes in the code that couldn't be anticipated or caught in the original PR review.
I usually write some code, doing some commits. After that, I test and add fixes. When it works I do self-review, fix some style and other issues.
History is full of commits with wrong intents and I don't think it is useful to see them. Yes, I can play with history and put all fixes to place where they should be, or squash it manually, but I don't want to waste time on it. Different people different coding style.
Squash and merge require one feature one PR. I can see all feature changes from one blame line. (IDEA annotate feature allow to see whole commit changes). I still can find PR for any commit, that was added via PR via GitHub UI interface.
My commit messages are not good. Lots of typos. But I can save some time and edit them in squash and merge interface.
For me, squash and merge is the time saver.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: The Git/GitHub Questions, Answers and Howto Thread
New GitHub feature "code owners".
https://blog.github.com/2017-07-06-intr ... wners-work
https://blog.github.com/2017-07-06-intr ... wners-work
This might help to solve problems with contributors, who cannot assign PR to anyone.code owners will automatically be requested for review whenever a pull request touches the files they own.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: The Git/GitHub Questions, Answers and Howto Thread
Yes, it does sound helpful. If you have time to make an initial CODEOWNERS file that makes you the owner of the ru.rxt stringtable, that sounds good.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
How to test someone else's updated PR
I'm trying to test a PR that I already tested but has been updated. I really don't understand shit.
Context (long terror story):
I was at my workspace and wanted to ensure there were no local changes (they would be dispensable):
Then I looked for a way to test someone else's PR. Found this link:
https://github.com/TeamPorcupine/Projec ... ll-Request
So I did
And then I went to my build folder and called cmake, which gave me warnings about Boost 1.65 (I think I'm 1.58).
I assumed that was a problem so I didn't try to call make.
I went again to the repo folder and wanted to delete the nanite_swarm branch in my workspace. Using "git branch -d nanite_swarm" it told me it wasn't merged (¿?), so I called "git branch -D nanite_swarm". Cool.
(Only later I realised my first call to cmake was performed within the repo folder instead of the build folder, maybe that was what caused the warnings.)
However, I was told that I should not pay attention to those warnings, so I wanted to fetch that branch again. Then I did a lot of random stuff (not sure why) and went into panic mode. Copied here (from my .bash_history, it does not include the commands I've executed this morning) just in case there is something important to acknowledge there, not that I want you to read it:
One relevant point is that at some point I "managed" to merge TSO's nanite_swarm PR into my local master branch and the upstream/master branch into my local nanite_swarm branch. But I think that's been solved.
My problem now:
So, at this present moment, I have been able to compile and test TSO's PR as it was yesterday (when I did the testing, I was in my confused master branch merged/overwritten by TSO's nanite swarm, which I solved later; currently, "git checkout nanite_swarm; git diff --name-status master" allowed me to verify that my master is indeed a copy of upstream/master (and origin/master) and that my local branch nanite_swarm is actually TSO's PR, as of yesterday).
I want to fetch (or whatever I should be wanting) TSO's update on its PR, so I do this:
The word "non-bare" gives me the chills.
I've decided to stop doing random stuff and come here to ask (thank you very much in advance):
What should I do to fetch the updated PR to test it in my machine/workspace?
Context (long terror story):
I was at my workspace and wanted to ensure there were no local changes (they would be dispensable):
Code: Select all
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ git pull upstream master
From https://github.com/freeorion/freeorion
* branch master -> FETCH_HEAD
Current branch master is up to date.
$ git reset --hard upstream/master
HEAD is now at 0d4f025 Merge pull request #2623 from TheSilentOne1/turnbtn-tooltip
$ git push origin master
Username for 'https://github.com': Oberlus
Password for 'https://[email protected]':
Everything up-to-date
https://github.com/TeamPorcupine/Projec ... ll-Request
So I did
Code: Select all
$ git fetch upstream pull/2624/head:nanite_swarm
[stuff about downloading stuff]
$ git checkout nanite_swarm
I assumed that was a problem so I didn't try to call make.
I went again to the repo folder and wanted to delete the nanite_swarm branch in my workspace. Using "git branch -d nanite_swarm" it told me it wasn't merged (¿?), so I called "git branch -D nanite_swarm". Cool.
(Only later I realised my first call to cmake was performed within the repo folder instead of the build folder, maybe that was what caused the warnings.)
However, I was told that I should not pay attention to those warnings, so I wanted to fetch that branch again. Then I did a lot of random stuff (not sure why) and went into panic mode. Copied here (from my .bash_history, it does not include the commands I've executed this morning) just in case there is something important to acknowledge there, not that I want you to read it:
Code: Select all
git status
git fetch upstream
git checkout master
git pull upstream master
git reset --hard upstream/master
git push origin master --force
git status
git add *
git status
git checkout
git fetch upstream master:master
git fetch upstream master
git status
git reset --hard upstream/master
git fetch upstream master
git status
git branch
git fetch upstream pull/2624/head:nanite_swarm
git branch
git checkout nanite_swarm
git status
git fetch upstream pull/2624/head:nanite_swarm
git checkout
git checkout master
git fetch upstream
git fetch upstream pull/2624/head:nanite_swarm
git reset --hard upstream/master
git checkout master
git checkout nanite_swarm
git status
git fetch upstream pull/2624/head:nanite_swarm
git branch -D nanite_swarm
git checkout master
git branch -D nanite_swarm
git pull upstream pull/2624/head:nanite_swarm
git status
git branch
git checkout nanite_swarm
git status
git pull upstream pull/2624/head:nanite_swarm
git checkout
git checkout nanite_swarm
git remote
git remote remove Morlic-fo
git remote
git status
git checkout master
git status
git fetch upstream
git rebase upstream/
git rebase upstream/master
git fetch upstream
git reset --hard upstream/master
git checkout
git checkout master
git reset --hard upstream/master
git checkout master
git status
git rebase --continue
git rebase --abort
git status
git fetch upstream pull/2624/head:nanite_swarm
git checkout nanite_swarm
git status
git checkout master
My problem now:
So, at this present moment, I have been able to compile and test TSO's PR as it was yesterday (when I did the testing, I was in my confused master branch merged/overwritten by TSO's nanite swarm, which I solved later; currently, "git checkout nanite_swarm; git diff --name-status master" allowed me to verify that my master is indeed a copy of upstream/master (and origin/master) and that my local branch nanite_swarm is actually TSO's PR, as of yesterday).
I want to fetch (or whatever I should be wanting) TSO's update on its PR, so I do this:
Code: Select all
$ git checkout nanite_swarm
Switched to branch 'nanite_swarm'
$ git fetch upstream pull/2624/head:nanite_swarm
fatal: Refusing to fetch into current branch refs/heads/nanite_swarm of non-bare repository
I've decided to stop doing random stuff and come here to ask (thank you very much in advance):
What should I do to fetch the updated PR to test it in my machine/workspace?
Re: The Git/GitHub Questions, Answers and Howto Thread
There are two separate issues here: how to fetch the branch of a pull request, and how to get updates of that branch.
As PRs are usually based on branches developers/contributors push to their personal clone of the upstream repo, I recommend adding their repo to the remotes of your local repo and then just fetch the respective branch from that remote (instead of trying to get it via the pull/xxxx refs of the upstream repo, never tried that). IMO that's the more traditional and cleaner, less hassle prone approach.
Once the branch has received updates, and you want to fetch those updates, it depends very much on how the branch has been updated. If there have only been more commits added, and no operation done that in whatever way changed the commit history, then simply checking out the branch and doing a "git pull" should be sufficient.
However, if the commit history of the branch has been changed (which most commonly happens when the maintainer of the branch did a rebase), you need to completely delete your local copy of the branch and do a fresh checkout of that branch from its remote. There is no way to update a local branch from a remote if the upstream branch has been rebased or had their commit history changed in any way. Trying to do that will always result in a big mess.
Which is the reason why rebasing branches that more than one developers/contributers work on is frowned upon and a no-go. Rebasing a branch is only acceptable if at least one of the following is true:
As PRs are usually based on branches developers/contributors push to their personal clone of the upstream repo, I recommend adding their repo to the remotes of your local repo and then just fetch the respective branch from that remote (instead of trying to get it via the pull/xxxx refs of the upstream repo, never tried that). IMO that's the more traditional and cleaner, less hassle prone approach.
Once the branch has received updates, and you want to fetch those updates, it depends very much on how the branch has been updated. If there have only been more commits added, and no operation done that in whatever way changed the commit history, then simply checking out the branch and doing a "git pull" should be sufficient.
However, if the commit history of the branch has been changed (which most commonly happens when the maintainer of the branch did a rebase), you need to completely delete your local copy of the branch and do a fresh checkout of that branch from its remote. There is no way to update a local branch from a remote if the upstream branch has been rebased or had their commit history changed in any way. Trying to do that will always result in a big mess.
Which is the reason why rebasing branches that more than one developers/contributers work on is frowned upon and a no-go. Rebasing a branch is only acceptable if at least one of the following is true:
- if the branch in question hasn't been pushed to a public/shared repo before
- if only one person is working on it
- a proper warning is given and all contributors working on that branch can commit their changes before the rebase is done
Re: The Git/GitHub Questions, Answers and Howto Thread
This is the method i use.
I followed the guide here:
https://github.community/t5/How-to-use- ... rk/td-p/77
To set up a macro co-pr ('checkout pull request), which does the whole job in a single line. Wasn't difficult.
Re: The Git/GitHub Questions, Answers and Howto Thread
Thank you both, Vezzra and Alleryn.
I'm doing Alleryn suggestion:
I'm doing Alleryn suggestion:
Code: Select all
$ git fetch upstream pull/2624/head:PR/2624 && git checkout PR/2624
remote: Enumerating objects: 45, done.
remote: Counting objects: 100% (45/45), done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 45 (delta 23), reused 44 (delta 22), pack-reused 0
Unpacking objects: 100% (45/45), done.
From https://github.com/freeorion/freeorion
* [new ref] refs/pull/2624/head -> PR/2624
Switched to branch 'PR/2624'