having trouble with github

[ontheDOL]

Ok everytime I try to submit a pull request , it always has my previous commits and tries to push them as well , which are already merged on the upstream repository . Previously , i've just deleted my forked branch and started again with a clean slate, but this is getting tedious lol.

Here is what i have tried in posh-git shell

edit# pic not showing there http://imgur.com/a/iZ9mi

what am i doing wrong? says up to date, but if i try to pull request, its still trying to push 3 commits already coommited

[Leodagan]

Just do

git push
-- or --
git push origin

The logic is to get the status from "Upstream" (the official repository, read-only for you !)
--
git fetch upstream

Merge it to your own Master code branch
-- switch branch if needed --
git checkout master
-- merge (this mean merge the target on my current branch) --
git merge upstream/master

Then apply the changes to your Own/Origin Repository so your fork is at the same level than Upstream...
--
git push
git push origin

[ontheDOL]

this is kinda what i had already tried, and it was saying everything up to date

but when doing a pull request, it still showed me 3 commits ahead (which im not) although 0 files changed. But i'm guessing if i did add my changes it would be 4 commits, leading to a dirty commit history.

What i found worked (or appears to have worked ) was;
git rebase upstream/master
git push -f origin master
now when i compare my fork to DOL its identical. I do loose my own forks commit history but thats not too important to me

[Leodagan]

hum if you had to rebase and force push that mean your master branch had commits that did not exists in upstream.

[ontheDOL]

the 3 commits it showed were the lootgen and ameleorating melodies fix , already commited, and something about a merge from master ...

like i said when i clicked new pull request, it would show these three, but have 0 files changed. But i assume it would still actually added my new change, pull request , there would then be 4 commits but only file changes would be from the new commit.

[Graveen]

Hum,i'm using GH for this
Browse your repo, you 'll have to do a sync commit (so, DOL repo is sync'ed with your fork), then you can do a pull request again. The sync commit will be shown.

[ontheDOL]

GH as in github website? or different app. i already rebased so its clean slate now but i will try again when (if ) my latest commit goes through

[Leodagan]

Github has its own App (for Windows I think), I never tried it

Your new PR is from your master branch again, I think this can be a trouble...

Your Timeline will be like :

Code: Select all

Last Commit Sync'ed from DOL -> Your Commit -> Your Commit

When it's Merged Upstream, Official Repo Timeline will be like :

Code: Select all

(Your Fork Branch) -> Your Commit -> Your Commit -> (Official Repo) Last Commit -> -> Merged Pull Request Commit (two parents)

If you Try to merge Upstream to your master it will (...probably...) end up like :

Code: Select all

Last Commit Sync'ed from DOL -> Your Commit -> Your Commit -> Merged Pull Request Commit (no change...)

The timeline won't match the one from Upstream/master... Git is not easy to grasp most users have trouble understanding how it works (I still use stack overflow and stack exchange to search for most basic features apart from checkout/push/merge)

Anyway your Fork will be different in Timeline (different Sha1 Hash for the snapshot right after last sync), and you won't be able to match the Upstream anymore, changing your timeline when rebasing will break your existing commit snapshots that's why you need to force push, force push means that if other users cloned your master branch they will be out of sync.

Git commits are like nodes in a binary tree, if the tree hierarchy don't match you can't provide Pull Request that contains only new nodes...

I suggest you don't use master for anything except to keep in sync with upstream.

Each change should be a new branch here is what I usually do :

Code: Select all

// checkout an up to date master $ git checkout master // create a feature branch $ git checkout -b my-new-feature // ... change some code here ... // Commit changes to the branch $ git add . $ git commit -m "Added: New features !!" // push to Github (probably need some options to push a non-existing remote branch...) $ git push origin // Revert to master branch $ git checkout master // Start another feature $ git checkout -b other-new-feature // ... change some code here ... // Rinse and repeat above...

Then go to Github website to create a pull request from the new branches only

The only downside is there won't be "my-new-feature" code in "other-new-feature" branch, so you can't work using the previous change you made (but this is intended by design, if "my-new-feature" don't make it to Upstream that won't prevent from merging "other-new-feature", you can probably branch "my-new-feature" to "upgrade-to-my-new-feature" if you want to expand on the previous code, but if the root node is not merged to Upstream other branches won't be able to make it either !)

If you want to keep a repository for your customized server containing changes that didn't make it to Upstream repository you should probably maintain a branch for it (branch dev or branch my-custom-server, you can even change your default branch from github website), then you should be able to cherry pick which changes you merge with your custom-server branch and if you make some research you should be able to extract and cherry pick changes to rebase them on Upstream/master for a proper pull request (but I admit I don't have the skills to do this, I'm not maintaining a custom server anyway...)

[Graveen]

I'm using TortoiseGIT for pull/push/fetch/rebase/merge/handle SVN repos....
I'm performing tasks on the github main site.
Here are the steps i'm doing:

Code: Select all

On Github site (GS): cloning into my account DOLSharp (doing this only once) With TortoiseGIT (TG): clone, fetch to a local folder (let's call it DOLocal) work on it... With TG: commit to master With TG: push to remote On GS: pull from DOLSharp to my clone (to sync changes done to DOL during my work session). This is a reversed pull request PR i have to accept locally (i'm calling it the "sync commit") On GS: create the new PR for DOLSharp (with my changes)

I'll read carefully the Leodagan's post above... Because the PR i submit to DOLSharp is displaying my "sync commit" which is noise at this step. I could miss a point (when you're used to a way...)

[Leodagan]

I don't feel like explaining a lot because most of my knowledge comes from "How To"/"Tutorials" articles...

I don't want to make people look like they are lazy, but I just typed "github sync fork" in Google Search (this can imply using a browser with en-us/en-uk language set in priority to receive quality answers for development topics...)

And the first answer is this link

https://help.github.com/articles/syncing-a-fork/

(And it doesn't tell you to push the master merge back to your fork remote "origin" by default...)

I admit I needed some time to understand there was a previous linked topic to read also :

https://help.github.com/articles/config ... for-a-fork

But I don't think my explanations with non-native english speaker skills could be better than these

For the workflow it's more trial and errors based on another Tutorial (using "github workflow" as search topic...) :

https://guides.github.com/introduction/flow/


I still believe most of these articles need some computer/development literacy, good english reading skills and time to master

Aside from this I tried to read the official Git Handbook and never managed to keep focused more than 10-15 minutes, I couldn't understand most of the concepts from just reading it and I spent weeks reading this

https://git-scm.com/book/en/v2/Getting- ... Git-Basics

There is multiple language version

I still can't handle the staging area, I mess up my stash save/apply pretty often (mostly because I use them instead of understanding staging area...), I have trouble wrapping my head around what "refs" means, and I'm glad the Continuous Integration process create "Tags" on its own

I like that XKCD has a comic explanation for this :

https://explainxkcd.com/wiki/index.php/1597:_Git


----Edit
This one is funny too :
http://ohshitgit.com/

[ontheDOL]

thanks for the info lads,
some of those link i had already read, particularly the syncing fork one, which i followed. But i think you are right about the problem being from master branch, when trying to sync with upstream commits that were made from that branch originally.

I will try the separate branch method next time i make a commit and go from there!

[Graveen]

Yeah Leo ! My main concern is i "should" use the command line to have better understanding of the inner concepts. But finally, i'm continuously using TortoiseGIT (which is filling all my needs locally) or GH site options.

I must dig this "sync commit back", really

[Leodagan]

I'm using Tortoise Git with Git Bash...

Git for Windows should be a pre-requisite for recent Tortoise Git setup, with Git 4 Windows you have the options to install contextual menu "Git Bash Here..."

It's a great complement to the GUI of Tortoise Git, if you found some command that fills your needs, just "Git Bash Here..." in the correct folder then use the commands, you can always use Tortoise Git after this to Diff or Push Changes and have a GUI for visually identifying the modifications you've just done

[Xanxicar]

"Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space"
...
And i thought it was just me.

Thanks for the links and the tips!
I wasn't aware at first that i needed to create my own fork and push the local changes to my personal fork to be able to create the pull request from there. But now that it's done I'm eager to hear if you liked my first commit.

[PlanarChaosRvrtwo]

testpost for gathering info on forum issue of an friend