Editing rights

[hvalin]

Hi Albert, @acjbrouwer

I wanted to edit the main page to support a bit, but did not succeed to push. Do I need some access rights or is it coming from my git client?

Thanks, Hugo

git.exe push --progress "origin" master:master remote: Permission to iiasa/COACCH.git denied to hvalin. fatal: unable to access 'https://github.com/iiasa/COACCH.git/': The requested URL returned error: 403

git did not exit cleanly (exit code 128) (2922 ms @ 01-Oct-21 15:40:04)

[acjbrouwer]

@hvalin, that was because so far only I and Esther had write access. I have now given such to you too. Note that your changes may need merging with already committed changes.

[hvalin]

Thanks Albert.

Actually, I would like you to check that I did not undo some of your changes. Not used to this type of conflict yet on Git. Below is the screen capture of what my pull did. I initially only wanted to do changes in the index.rst.

Can you confirm I did not overwrite anything from your last changes?

Thanks, Hugo

[acjbrouwer]

Dear Hugo,

It is difficult to say from the snapshot, but I suppose you modified just the index.rst. Probably, those changes hit different lines than mine in which case the Git automated merge algorithm tends to do the right thing. The merge, by the looks of it, so far only happened in your local repo.

From the command line, exploring what the merge commit entailed in terms of changes can be done by the following invocation: git diff <commit>~1 <commit>

For <commit> you can use HEAD if the merge is still the last local commit. Otherwise you can do git log and copy and paste the right commit hash (the long lists of hexadecimal numbers) in place of <commit> in the above invocation.

But I am guessing your graphical Git client has a more user-friendly way of showing the changes made in a particular commit.

Once you're convinced the merge is fine, you can push it out to the GitHub repo.

[acjbrouwer]

As merge commit 715498c did not break anything, I guess this issue can be closed.

Note that unnecessary merge commits are best avoided as they confuse and clutter up the log. This is best done by fetching and merging (or pulling) any remote work before committing to your local repo and pushing without too much delay.

If you have commits in your local repo that you did not push, and the remote has new commits as well that you bring in with fetch+merge or pull, then you will get a merge commit in your local repo if local and remote commits are to the same branch. There is no need to push that ugliness: with Git rebase you can clean things up before pushing.

[acjbrouwer]

Read here for a brief discussion of the issue of branch divergence and further options for handling it .