Closed lcn2 closed 1 year ago
lcn2
commented
1 year ago FYI: After creating this pull request #811 the GitHub web interface stated:
This next section in an image of part of the this pull request #811 and is NOT clickable:
We record this state for the record for informational purposes.
lcn2
commented
1 year ago Clicking on the blue "Use the command line" link we are further shown the following:
This next section in an image of part of the this pull request https://github.com/ioccc-src/temp-test-ioccc/pull/811 and is NOT clickable:
The blue open this in GitHub Desktop is a link to an information page.
The blue "Use the command line" simply toggles the view on/off of the image given in this comment.
lcn2
commented
1 year ago We observe in the NOTE in comment 1567564882 the following important phrase:
If the conflicts on this branch are too complex to resolve in the web editor, you can check it out via command line to resolve the conflicts.It may be that the "conflicts on this branch are too complex". So doing the 2 step process might be the more rational approach in the end. Nevertheless the idea of using the GitHub Desptop should be explored, just to better understand how it works.
lcn2
commented
1 year ago BTW: It is worth noting that the "This branch has conflicts that must be resolved" web frame as noted in the NOTE in comment 1567562678 keeps sinking to the bottom of this pull request #811. While the "Use the command line" part goes away when it sinks to the bottom, that section can easily be brought back by clicking in the blue "Use the command line" link.
We presume this section sinks as not only a reminder that conflicts need to be resoled, but also that this pull request #811 cannot proceed without resolving them.
lcn2
commented
1 year ago We will now proceed to explore the the GitHub Desptop option.
As we are using macOS on Apple Silicon, we will download Download for macOS Apple Silicon, the GitHub Desptop .
BTW: macOS for Intel would Download for macOS for an Intel GitHub Desptop.
lcn2
commented
1 year ago Installed the GitHub Desptop for Apple Silicon on MacOS.
First step after launching is that the App wants you to "Sign in to GitHub.com": seems reasonable. This requires one to "Authorize GitHub Desktop" in a new browser window the pops up - easy to do.
After authorizing, the app shows a "Configure Git" window which we presume means to configure how the GitHub Desptop will use git itself. We simply accept the defaults and clicked ((Finish)).
The end result is an app window of the form:
This next section in an image of part of the this pull request https://github.com/ioccc-src/temp-test-ioccc/pull/811 and is NOT clickable:
We plan to explore the "Create a Tutorial Repository..." option. When you click ((Continue)) the app creates a local repository on our local machine that, when pushed to GitHub is not visible publicly.
BTW: On macOS, the created tutorial lines under ~/Documents/GitHub/desktop-tutorial/.
On step 3 of the tutorial:
This next section in an image of part of the this pull request https://github.com/ioccc-src/temp-test-ioccc/pull/811 and is NOT clickable:
BTW: The default editor for the app is Atom. We will go with the default for purposes of the tutorial. Unfortunately when our current version of Atom launched, it crashed. Perhaps we need to install a current version of Atom for Apple Silicon?
That won't do. It seems that Atom has come to an end: Sunsetting Atom. We removed Atom from our system.
BTW: GitHub Desktop -> Preferences -> Integrations -> External Editor uas the following options:
There are no other options. For macOS, we will do with Xcode for now.
BTW: We also changed GitHub Desktop -> Preferences -> Integrations -> Shell from Terminal to iTerm2.
We have processed to Step 4 of the tutorial using Xcode:
This next section in an image of part of the this pull request https://github.com/ioccc-src/temp-test-ioccc/pull/811 and is NOT clickable:
Step 4 was to make a commit, which will be done by clicking the Commit button in the lower left:
This next section in an image of part of the this pull request https://github.com/ioccc-src/temp-test-ioccc/pull/811 and is NOT clickable:
And then in step 5 publishing (git push to GitHub):
This next section in an image of part of the this pull request https://github.com/ioccc-src/temp-test-ioccc/pull/811 and is NOT clickable:
Step 6 is tp open a Pull request:
This next section in an image of part of the this pull request https://github.com/ioccc-src/temp-test-ioccc/pull/811 and is NOT clickable:
We will/can do so via CMD-R or via GitHub Desktop -> Branch -> Create Pull Request. Doing this pops up a browser tab on the GitHub repo (as minted before this is a private repo) to "Open a pull request".
Here the process is straight forward as there are no conflicts with this simple pull request and the Merge (via the GitHub browser tab) worked as expected.
At this point the tutorial is done:
This next section in an image of part of the this pull request https://github.com/ioccc-src/temp-test-ioccc/pull/811 and is NOT clickable:
At this stage we can click ((Exit Tutorial)) and return to the app home page.
So the tutorial was a simple use of git and GitHub for the App.
It is our plan now, using the tutorial repo and the app to create a pull request merge conflict and see what happens next.
However we need to pause, make dinner, do chores, etc. and come back to this pull request #811 and the GitHub Desktop tutorial later. Stay tuned!
xexyl
commented
1 year ago We have to make absolute certain that the changes in this repo are the 'master' copies and not the other one! But I actually had a thought .. no idea if it'd work but ... it's about finding which files conflict and then just taking the files that we have here i.e. the ones that have to be merged into the other, and then doing a commit with those changes so that they match this repo.
I was going to try and extract the list of files to do this but as you know I've had other things going on.
Right now I'm too tired to address the comment in the other thread about this issue so I'll have to delay it for now but hopefully I can do more later on in that way here. Hope you're sleeping well.
xexyl
commented
1 year ago .. as for the comments noting the progress here I will hopefully be able to read them more thoroughly later this morning but if not and it's not been resolved then hopefully tomorrow. I will now look at the issue #5 to see and reply to your comments. After that I'll do other things: maybe the thing I mentioned in issue #3 last night that I put off too long or maybe something else. I wish I could rest and maybe I'll try but I don't think I'll have much luck. At least I slept in a bit today: just about half an hour or so to 0230 but still a bit better .. even if unlikely to be repeated tomorrow. It was a pretty difficult night last night too.
lcn2
commented
1 year ago The above mentioned GitHub app test repo may not provide much in the way of assistance with GitHub conflict merge resolution as we guess they simply might provide the "<<< ... >>>" merge lines that an editor must resolve. We believe we can put the test repo into a merge conflict state by using two difference copies of the test repo and by making conflicting edits. Finally we can test how the GitHub Desptop can address the merge conflict state some other time: and not while we have this repo "on hold". Therefore we plan to process the command line instructions: hopefully this will be done quickly.
xexyl
commented
1 year ago The above mentioned GitHub app test repo may not provide much in the way of assistance with GitHub conflict merge resolution as we guess they simply might provide the "<<< ... >>>" merge lines that an editor must resolve. We believe we can put the test repo into a merge conflict state by using two difference copies of the test repo and by making conflicting edits. Finally we can test how the GitHub Desptop can address the merge conflict state some other time: and not while we have this repo "on hold". Therefore we plan to process the command line instructions: hopefully this will be done quickly.
Good luck with it all!
I will be awake a bit longer but I am done with computer stuff today.
I unfortunately did not finish what I was hoping to do but I hope I can tomorrow.
If you figure out and solve the problem before the morning I will do at least one pull request but I fear I won't get much done tomorrow either way so it's good timing if it has to happen which of course it unfortunately is happening.
Hope you have a good night!
lcn2
commented
1 year ago Processing the command line instructions:
Make sure the local repo is up to date:
git fetch
git rebaseCurrent branch master is up to date.
From your project repository, check out a new branch and test the changes.
git checkout -b ioccc-src-master masterSwitched to a new branch 'ioccc-src-master'
git pull git@github.com:ioccc-src/winner.git masterThis produced:
remote: Enumerating objects: 53, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 53 (delta 29), reused 33 (delta 29), pack-reused 20
Unpacking objects: 100% (53/53), 19.51 KiB | 475.00 KiB/s, done.
From github.com:ioccc-src/winner
* branch master -> FETCH_HEAD
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint: git config pull.rebase false # merge
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.Processing the command line instructions:
Step 0
Make sure the local repo is up to date:
git fetch git rebaseCurrent branch master is up to date.
Step 1
From your project repository, check out a new branch and test the changes.
git checkout -b ioccc-src-master masterSwitched to a new branch 'ioccc-src-master'
git pull git@github.com:ioccc-src/winner.git masterThis produced:
remote: Enumerating objects: 53, done. remote: Counting objects: 100% (33/33), done. remote: Compressing objects: 100% (4/4), done. remote: Total 53 (delta 29), reused 33 (delta 29), pack-reused 20 Unpacking objects: 100% (53/53), 19.51 KiB | 475.00 KiB/s, done. From github.com:ioccc-src/winner * branch master -> FETCH_HEAD hint: You have divergent branches and need to specify how to reconcile them. hint: You can do so by running one of the following commands sometime before hint: your next pull: hint: hint: git config pull.rebase false # merge hint: git config pull.rebase true # rebase hint: git config pull.ff only # fast-forward only hint: hint: You can replace "git config" with "git config --global" to set a default hint: preference for all repositories. You can also pass --rebase, --no-rebase, hint: or --ff-only on the command line to override the configured default per hint: invocation. fatal: Need to specify how to reconcile divergent branches.
What a nightmare.
Hopefully it will be resolved easily enough but I have always felt like git has more problems with conflicts than say CVS. But then again I haven't had to deal with conflicts that many times.
Anyway I will look at this more tomorrow morning I imagine.
Good luck with it!
lcn2
commented
1 year ago What a nightmare.
Hopefully it will be resolved easily enough but I have always felt like git has more problems with conflicts than say CVS. But then again I haven't had to deal with conflicts that many times.
Anyway I will look at this more tomorrow morning I imagine.
Good luck with it!
This is not a nightmare per-se, one just has to process the conflict.
We do NOT plan to configure a default in this case as there are cases where one wants to merge, or one wants to rebase, or one wants to fast-forward. Setting a default, especially a global default, might be a mistake when one encounters a situation where some options are not wanted.
We note that in this git doc on rebasing:
The Perils of Rebasing
Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line:
Do not rebase commits that exist outside your repository and that people may have based work on.
If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.We are in situation where "that exist outside your repository" and perhaps "that people may have based work on", so a rebase is not a good idea.
As the git doc on rebasing goes on to state:
When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.Now back to step 2 in the next comment.
xexyl
commented
1 year ago What a nightmare.
Hopefully it will be resolved easily enough but I have always felt like git has more problems with conflicts than say CVS. But then again I haven't had to deal with conflicts that many times.
Anyway I will look at this more tomorrow morning I imagine.
Good luck with it!
This is not a nightmare per-se, one just has to process the conflict.
We do NOT plan to configure a default in this case as there are cases where one wants to merge, or one wants to rebase, or one wants to fast-forward. Setting a default, especially a global default, might be a mistake when one encounters a situation where some options are not wanted.
We note that in this git doc on rebasing:
The Perils of Rebasing Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line: Do not rebase commits that exist outside your repository and that people may have based work on. If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.We are in situation where "that exist outside your repository" and perhaps "that people may have based work on", so a rebase is not a good idea.
As the git doc on rebasing goes on to state:
When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.Now back to step 2 in the next comment.
Well it's a hassle anyway. Maybe I exaggerated a bit.
Sounds like you're doing well. I am going to start getting ready for sleep soon. Hopefully tomorrow morning I will see good news here but it's not a problem if it takes longer.
I will probably read the above more thoroughly tomorrow just so I have an idea about it but for now I will be leaving for the day.
Good night!
lcn2
commented
1 year ago Continuing ...
Step 2: Merge the changes and update on GitHub
git checkout masterThis produces:
Switched to branch 'master'
Your branch is up to date with 'origin/master'.Now we:
git merge --no-ff ioccc-src-masterThis produced:
Already up to date.And the final suggested part of command line instructions:
git push origin masterThis produced:
Everything up-to-dateHummm ... so what did all that do? It appears to have no impact. No files changed. The git log did not change. The repo did not change.
Did we miss something in the command line instructions?
The problem with the above steps is that the pull request changes were not fetched. Something else obviously has to happen to get the actual pull request #811 changes into the local repo tree so that such conflicts can even be addressed.
lcn2
commented
1 year ago We are going to delete or local "ioccc-src-master" branch and start again:
git br -d ioccc-src-master
git checkout master
git fetch origin
git fetch --prune --tags origin
git merge --ff-only origin/master
git rebase --rebase-merges origin/master
git br
git statusThis is a paranoid way to be sure we are back to normal. This produced:
Already up to date.
Current branch master is up to date.
* master
xexyl-updates
Already on 'master'
Your branch is up to date with 'origin/master'.
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree cleanThe command line instructions assume that the changes requested by the pull request somehow get into the local repo directory between steps 1 and 2. They do not magically appear!
We are going to use the GitHiub cli.
This is because the Checking out pull requests locally suggests that under the GitHub CLI we have this command:
gh pr checkout PULL-REQUESTThe gh pr command set seems to be able to deal with pull requests.
BTW: On macOS we used HomeBrew to download the gh command set. See GitHub CLI web page for details on now to download it.
FYI, we have installed this version of gh:
$ gh --version
gh version 2.30.0 (2023-05-30)
https://github.com/cli/cli/releases/tag/v2.30.0We need to login to GitHub:
gh auth loginWe selected:
GitHub.comWe set the repo via:
gh repo set-default https://github.com/ioccc-src/temp-test-iocccThis produced:
✓ Set ioccc-src/temp-test-ioccc as the default repository for the current directoryIf you do a:
gh browseThen the repo is opened in a browser tab.
To see the pull request we can do:
gh pr listThis produced:
Showing 1 of 1 open pull request in ioccc-src/temp-test-ioccc
#811 address the 16 commits behind ioccc-src:master ioccc-src:master about 1 day agoAnd pull request status:
gh pr statusproduced:
Relevant pull requests in ioccc-src/temp-test-ioccc
Current branch
There is no pull request associated with [ioccc-src-master]
Created by you
#811 address the 16 commits behind ioccc-src:master [ioccc-src:master]
Requesting a code review from you
You have no pull requests to reviewWe can checkout the pull request #811 into a ioccc-src-master branch:
gh pr checkout 811 -b ioccc-src-masterThis produced:
From github.com:ioccc-src/temp-test-ioccc
* [new ref] refs/pull/811/head -> ioccc-src-master
Switched to branch 'ioccc-src-master'We are now on the ioccc-src-master branch:
$ git br
* ioccc-src-master
master
xexyl-updatesSo this is the equivalent of the command line instructions 1st command of step 1.
So we do:
git pull git@github.com:ioccc-src/winner.git master
git checkout master
git merge --no-ff ioccc-src-masterNow we are getting somewhere! This produced:
$ git pull git@github.com:ioccc-src/winner.git master
From github.com:ioccc-src/winner
* branch master -> FETCH_HEAD
Already up to date.
$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
$ git merge --no-ff ioccc-src-master
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Auto-merging 2020/burton/Makefile
CONFLICT (content): Merge conflict in 2020/burton/Makefile
Auto-merging 2020/carlini/Makefile
CONFLICT (content): Merge conflict in 2020/carlini/Makefile
Auto-merging 2020/endoh1/Makefile
CONFLICT (content): Merge conflict in 2020/endoh1/Makefile
Auto-merging 2020/endoh2/Makefile
CONFLICT (content): Merge conflict in 2020/endoh2/Makefile
Auto-merging 2020/endoh3/Makefile
CONFLICT (content): Merge conflict in 2020/endoh3/Makefile
Auto-merging 2020/ferguson1/Makefile
CONFLICT (content): Merge conflict in 2020/ferguson1/Makefile
Auto-merging 2020/ferguson2/Makefile
CONFLICT (content): Merge conflict in 2020/ferguson2/Makefile
Auto-merging 2020/giles/Makefile
CONFLICT (content): Merge conflict in 2020/giles/Makefile
Auto-merging 2020/kurdyukov1/Makefile
CONFLICT (content): Merge conflict in 2020/kurdyukov1/Makefile
Auto-merging 2020/kurdyukov2/Makefile
CONFLICT (content): Merge conflict in 2020/kurdyukov2/Makefile
Auto-merging 2020/kurdyukov3/Makefile
CONFLICT (content): Merge conflict in 2020/kurdyukov3/Makefile
Auto-merging 2020/kurdyukov4/Makefile
CONFLICT (content): Merge conflict in 2020/kurdyukov4/Makefile
Auto-merging 2020/otterness/Makefile
CONFLICT (content): Merge conflict in 2020/otterness/Makefile
Auto-merging 2020/tsoj/Makefile
CONFLICT (content): Merge conflict in 2020/tsoj/Makefile
Auto-merging 2020/yang/Makefile
CONFLICT (content): Merge conflict in 2020/yang/Makefile
Auto-merging contact.html
CONFLICT (content): Merge conflict in contact.html
CONFLICT (modify/delete): faq.html deleted in HEAD and modified in ioccc-src-master. Version ioccc-src-master of faq.html left in tree.
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Auto-merging judges.html
CONFLICT (modify/delete): mirror-request.html deleted in HEAD and modified in ioccc-src-master. Version ioccc-src-master of mirror-request.html left in tree.
CONFLICT (modify/delete): mirror.html deleted in HEAD and modified in ioccc-src-master. Version ioccc-src-master of mirror.html left in tree.
Auto-merging robots.txt
CONFLICT (content): Merge conflict in robots.txt
Auto-merging status.json
CONFLICT (add/add): Merge conflict in status.json
Auto-merging winners.html
CONFLICT (modify/delete): years-spoiler.html deleted in HEAD and modified in ioccc-src-master. Version ioccc-src-master of years-spoiler.html left in tree.
Auto-merging years.html
Automatic merge failed; fix conflicts and then commit the result.That is where we want to be ... a proper set of conflicted changes. See the status is now expected as well:
$ git status
On branch master
Your branch is up to date with 'origin/master'.
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add/rm <file>..." as appropriate to mark resolution)
both added: .gitignore
both modified: 2020/burton/Makefile
both modified: 2020/carlini/Makefile
both modified: 2020/endoh1/Makefile
both modified: 2020/endoh2/Makefile
both modified: 2020/endoh3/Makefile
both modified: 2020/ferguson1/Makefile
both modified: 2020/ferguson2/Makefile
both modified: 2020/giles/Makefile
both modified: 2020/kurdyukov1/Makefile
both modified: 2020/kurdyukov2/Makefile
both modified: 2020/kurdyukov3/Makefile
both modified: 2020/kurdyukov4/Makefile
both modified: 2020/otterness/Makefile
both modified: 2020/tsoj/Makefile
both modified: 2020/yang/Makefile
both modified: contact.html
deleted by us: faq.html
both modified: index.html
deleted by us: mirror-request.html
deleted by us: mirror.html
both modified: robots.txt
both added: status.json
deleted by us: years-spoiler.html
no changes added to commit (use "git add" and/or "git commit -a")NOW we can resolve the conflicts locally!
lcn2
commented
1 year ago Continuing ...
By resolving the conflicts locally, we mean that we can use commands such as vim, cp, etc. to do the job.
For example, the top level .gitignore is now:
<<<<<<< HEAD
*.bak
*.bku
*.dSYM
.*.sv[a-z]
.*.sw[a-z]
.su[a-z]
.DS_Store
.sv[a-z]
.sw[a-z]
/NOTES
/archive/1984/
/archive/1985/
/archive/1986/
/archive/1987/
/archive/1988/
/archive/1989/
/archive/1990/
/archive/1991/
/archive/1992/
/archive/1993/
/archive/1994/
/archive/1995/
/archive/1996/
/archive/1998/
/archive/2000/
/archive/2001/
/archive/2004/
/archive/2005/
/archive/2006/
/archive/2011/
/archive/2012/
/archive/2013/
/archive/2014/
/archive/2015/
/archive/2018/
/archive/2019/
/archive/2020/
/bugs.html
/faq.html
iocccsize
mkentry
readme.html
=======
.DS_Store
prog
alt.prog
>>>>>>> ioccc-src-masterWe are going to go through the conflicted files one by one now.
lcn2
commented
1 year ago To summarize how we got here and ignoring all of the mis-steps of before:
Be sure your local repo tree is clean:
git checkout master
git fetch origin
git fetch --prune --tags origin
git merge --ff-only origin/master
git rebase --rebase-merges origin/master
git statusThen look at the GutHub status (after being suer you are logged in):
gh auth login
gh pr statusThen fetch the pull request #811 into a new branch:
gh pr checkout 811 -b ioccc-src-master
git pull git@github.com:ioccc-src/winner.git master
git checkout master
git merge --no-ff ioccc-src-master
git statusNow we use commands to resolve the conflicts.
In the case of pull request #811, most of the time we will simply use the contents of the current temp-test-ioccc repo. We will, of course, review these files on a case by case basis.
Stay tuned ...
lcn2
commented
1 year ago While we are on the subject of resolving conflicts, we will use vimdiff. The vimdiff is part of the common vim enhanced package.
To setup for git:
git config --global diff.tool vimdiff
git config --global difftool.prompt false
git config --global merge.tool vimdiff
git config --global merge.conflictstyle diff3
git config --global mergetool.prompt falseTo setup the colors for vimdiff, add this to your ~/.vimrc:
highlight DiffAdd cterm=bold ctermfg=10 ctermbg=17 gui=none guifg=bg guibg=Red
highlight DiffDelete cterm=bold ctermfg=10 ctermbg=17 gui=none guifg=bg guibg=Red
highlight DiffChange cterm=bold ctermfg=10 ctermbg=17 gui=none guifg=bg guibg=Red
highlight DiffText cterm=bold ctermfg=10 ctermbg=88 gui=none guifg=bg guibg=RedThis will allow one to use git d to invoke git difftool:
git config --global alias.d difftoolThis will allow one to use git m to invoke git mergetool:
git config --global alias.m mergetoolWe found this nice Quick and Dirty : Vimdiff Tutorial.
Here is a generic vimdiff tutorial as well.
And here is a vimdiff cheat sheat
Another very good method is to use the vim fugitive vim plugin. This may be the best option of all. See the Fugitive.vim - resolving merge conflicts with vimdiff tutorial for further details.
We used this Use vimdiff as git mergetool tutorial to practice on the GitHub desktop-tutorial.
To process the git conflicts:
git mergetoolIn vimdiff to close all windows:
:qaor to close all vimdiff windows without saving:
:qa!To abort the git mergetool when you are in vimdiff and NOT commit any changes:
:cquitYou can abort the merge:
git merge --abortWith the "git config --global alias.d difftool" alias in place, you can print all of the conflicts by:
git dwhereis this will allow you to page thru the conflict diffs:
git diffTo accept all of the original file changes, rejecting the content from the other merged file:
:%diffg LOTo accept all of the changes from the merged file:
:%diffg REvimdiff windowsWhen you have addressed conflicts in a file, you can close down the other vimdiff windows:
:onlyNow you can write the file out:
:wqNow the git mergetool, if there is another conflict, will run vimdiff on the next file with a conflict.
vimdiff windows:%diffg LO | :onlyWhile git mergetool works on all conflicted files, one can give args to the tool to just work in a few files such as:
git mergetool status.json .gitignoreThe mergtool process will create *.orig files. You may list them by:
git ls-files --exclude-standard --othersTo remove all of the untracked *.orig files:
rm $(git ls-files --exclude-standard --others | grep '\.orig$')Given the config setup in commrent 1569457158, one can do:
git mergetoolIf you want all of the local file changes and reject the merged changes:
:%diffg LO | :only
:wqWe did this for the Makefiles that had conflicts as the Makefiles in the winner repo are not suitable for this repo.
Of the files that were conflicted, only these files has to be merged:
index.html - add news from the winner repo for 2023-05-22
status.json - replace with the winner repo copy to match the news updateA diff with the backup copy shows, outside of the .git/ tree stuff, that the 2 files mentioned above are the only thing that changed.
Then:
git commit -m"Merge branch 'ioccc-src-master'"
git pushThis produced:
Enumerating objects: 171, done.
Counting objects: 100% (171/171), done.
Delta compression using up to 10 threads
Compressing objects: 100% (86/86), done.
Writing objects: 100% (89/89), 12.95 KiB | 6.48 MiB/s, done.
Total 89 (delta 66), reused 6 (delta 2), pack-reused 0
remote: Resolving deltas: 100% (66/66), completed with 39 local objects.
To github.com:ioccc-src/temp-test-ioccc.git
1c1719ba..fee2ca03 master -> masterAnd now pull request #811 has been merged! Yea!
Now the Github site shows that the pull request #811 was successfully closed!
Moreover, this temp-test-ioccc repo now shows that it is:
This branch is 1916 commits ahead of ioccc-src:master.
Thus if we were to make a pull request against the official IOCCC winner repo (we won't do that now), such a pull request would NOT have any conflicts!
xexyl
commented
1 year ago EXCELLENT commentary! I'll have to read it all when I'm more awake. But at least a few comments on the last comment you wrote.
Given the config setup in commrent 1569457158, one can do:
git mergetool
I tend to forget about this one! Thanks for the reminder.
BTW: have you ever used git bisect? Very useful tool!
If you want all of the local file changes and reject the merged changes:
:%diffg LO | :only :wq
Oh nice! That's a vim command I never used! I'll have to look into it sometime in the near future! Thanks!
We did this for the Makefiles that had conflicts as the Makefiles in the winner repo are not suitable for this repo.
Good call.
Of the files that were conflicted, only these files has to be merged:
index.html - add news from the winner repo for 2023-05-22 status.json - replace with the winner repo copy to match the news updateOn this note I was going to say: would a
news.htmlfile be a good idea? Not sure how it would work insideindex.htmlunless it was a SSI (which I guess GitHub does NOT support) but it would then allow you to update news more easily, right?A diff with the backup copy shows, outside of the
.git/tree stuff, that the 2 files mentioned above are the only thing that changed.Then:
git commit -m"Merge branch 'ioccc-src-master'" git pushThis produced:
Enumerating objects: 171, done. Counting objects: 100% (171/171), done. Delta compression using up to 10 threads Compressing objects: 100% (86/86), done. Writing objects: 100% (89/89), 12.95 KiB | 6.48 MiB/s, done. Total 89 (delta 66), reused 6 (delta 2), pack-reused 0 remote: Resolving deltas: 100% (66/66), completed with 39 local objects. To github.com:ioccc-src/temp-test-ioccc.git 1c1719ba..fee2ca03 master -> masterAnd now pull request #811 has been merged! Yea!
I'm copying my local repo to a backup directory before I pull changes. Just started that so I don't forget ..
Now the Github site shows that the pull request #811 was successfully closed!
Moreover, this temp-test-ioccc repo now shows that it is:
This branch is 1916 commits ahead of ioccc-src:master.
Excellent!
Thus if we were to make a pull request against the official IOCCC winner repo (we won't do that now), such a pull request would NOT have any conflicts!
Great job and congratulations! You should write a document on how to do this for future reference or others. Or maybe I can do that when I'm more awake though whether that's today (that is whether doing it today or not :-) .. I'll be more awake for a while today at the last but I do have other things to do too .. though I will soon make the commit I talked about yesterday morning) is another matter entirely.
Probably a great idea to NOT do such commits for now yes.
Well copying the repo was entirely useless it seems:
$ git-pull-temp
...
From https://github.com/ioccc-src/temp-test-ioccc
* branch master -> FETCH_HEAD
Updating 1c1719baf96e4a3e6e9b442708a4ed38d54052bb..fee2ca0308085a7271f3a101043fbe5fa9bf0ac4
Fast-forward
index.html | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
status.json | 3 ++-
2 files changed, 78 insertions(+), 1 deletion(-)Well better safe than sorry. But there is something interesting that I discovered when doing this that might make it not useless:
[...]
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.CMLBCCDA': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.HCABAKHF': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.MLGDLJKA': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.IMLCHGAI': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.CGGHAMGC': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.CMDGAELH': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.DEBBAAIL': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.BDHFHALG': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.LKDELKMF': Operation not permitted
cp: cannot create special file 'xexyl-temp-test-ioccc.bak/2019/duble/.EFFIIECE': Operation not permitted
[...]
$ ls -al 2019/duble/|awk '{print $NF}'|grep -E '\.[A-Z].*'
.BDHFHALG=
.CGGHAMGC=
.CMDGAELH=
.CMLBCCDA=
.DEBBAAIL=
.EFFIIECE=
.HCABAKHF=
.IMLCHGAI=
.LKDELKMF=
.MLGDLJKA=
These are sockets:
srwxr-xr-x 1 cody staff 0 Apr 6 08:19 .BDHFHALG=
srwxr-xr-x 1 cody staff 0 Apr 6 08:15 .CGGHAMGC=
srwxr-xr-x 1 cody staff 0 Apr 6 08:16 .CMDGAELH=
srwxr-xr-x 1 cody staff 0 Apr 3 08:47 .CMLBCCDA=
srwxr-xr-x 1 cody staff 0 Apr 6 08:19 .DEBBAAIL=
srwxr-xr-x 1 cody staff 0 Apr 6 08:19 .EFFIIECE=
srwxr-xr-x 1 cody staff 0 Apr 6 08:15 .HCABAKHF=
srwxr-xr-x 1 cody staff 0 Apr 6 08:15 .IMLCHGAI=
srwxr-xr-x 1 cody staff 0 Apr 6 08:19 .LKDELKMF=
srwxr-xr-x 1 cody staff 0 Apr 6 08:15 .MLGDLJKA=which makes sense given the nature of the program. But git status does not show them. I guess it ignores sockets. Interesting. Even so is there a way we could delete these? I kind of guess that depending on the system the file names might be different patterns. I should at least add a note to the README.md that this entry will leave sockets lying about in the current working directory.
xexyl
commented
1 year ago While we are on the subject of resolving conflicts, we will use
vimdiff. Thevimdiffis part of the common vim enhanced package.Yup .. this tool is excellent! I use it a lot. I might also add that
vimtutoris a great tool for beginners.
I'm really going to try resting now but I hope to reply to these comments later on: perhaps not all but some including what's below in this comment I'm replying to.
This pull request is intended to allow (we hope), eventually, for a more smooth merge (via GitHub pull request) of this temp-test-ioccc repo with the official IOCCC winner repo in the future. While we DO plan to merge in the hopefully not to distant future, we are NOT doing such a merge now. We are ONLY addressing the 16 commits behind that the temp-test-ioccc repo is behind the official IOCCC winner repo.
The following 26 files were modified on the official IOCCC winner repo AFTER this temp-test-ioccc repo was forked:
In addition the following 1 file was created on official IOCCC winner repo AFTER this temp-test-ioccc repo was forked:
This pull request will have (we predict) a number of merge conflicts associated with the above 27 files.
If is our experience that the GitHub conflict merge resolution process, via the web interface, seems awkward. Perhaps the GitHub conflict merge resolution process works well and we simply don't understand it / are doing it wrong. If so we hope to have a better understanding of the GitHub conflict merge resolution process after this pull request is over.
Once this pull request has been merged, we will restore the content of the above 27 files in this temp-test-ioccc repo by way if a restoration commit. So not only will the negative impact of this pull request be minimized, from a git history point of view that restoration commit will look like a proper edit once the future merge (via GitHub pull request) is performed. Such a future merge won't have conflicts (we hope) from the perspective of the the official IOCCC winner repo.