Skip to content

PR for @MacDennis76 suggested fix for Dynamic Repo #348

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

Closed
wants to merge 2 commits into from
Closed

PR for @MacDennis76 suggested fix for Dynamic Repo #348

wants to merge 2 commits into from

Conversation

dazinator
Copy link
Member

No description provided.

dazinator and others added 2 commits January 11, 2015 21:26
updating my fork from master
- Committed @MacDennis76 's fix which allows dynamic repository to run.. Although have no idea if this is an acceptable fix.
@gep13
Copy link
Member

gep13 commented Jan 14, 2015

Thanks for the contribution!

Can I make a suggestion that you redo this Pull Request by first creating a branch off of master? This will allow you to rebase the changes that have happened, rather than having a merge commit in the PR.

Thanks!

@dazinator
Copy link
Member Author

Forgive me. I've thus far lived a sheltered source control life consisting of Visual Source Safe and TFS. Rebasing is an entirely new concept for me.
I was going to ask you to clarify what I need to do, as I'm not understanding how to eliminate the merge commit, but rather than hassle you I think I need to go away and learn about git and rebasing!

Not sure how long that will take me :)

Happy for someone more familiar with git to review and make this 1 liner change in the interim if its needed.

@JakeGinnivan
Copy link
Contributor

Git is awesome once you figure it out. You will not want to go back.

I find git best on the command line, then using something like Git Extensions to visualise and sometimes commit if you want to commit only a subset of your changes.

With the git workflow we tend to use in open source there is one basic rule which makes life easier for us and can help prevent things going wrong (git has a lot of sharp edges unfortunately). That rule is don't commit to master. The reason is then you master is always clean with no custom commits and you can 'pull upstream' without merge commits.

To get yourself into the ideal state, do this:

git branch DynamicRepoFix # Put your changes on another branch, we will still have master checked out though at the moment
git fetch upstream # this assumes you have two remotes. origin points at your fork, upstream points at main repo. Adjust as needed
git reset upstream/master --hard # this will make master exactly the same as master in the main repo (removing your commits and adding any new ones).
git checkout DynamicRepoFix  # checkout your new branch with your commits
git rebase master   # Rebase basically checks out master then *replays* your commits one by one on top of master. Making history look like you checked out master, then did your work. 

Rebasing will not replay merge commits, so they get removed.

You can then git push origin DynamicRepoFix and then open a new pull request from your feature branch.

Once it has been merged, or if you want to work on something else you go

git checkout master
git pull upstream master
git checkout -b MyFeature

And you have a new feature branch, not containing commits from your other feature branches ready to go and work on something else before your first PR is merged.

Hope that helps

@dazinator
Copy link
Member Author

Thanks Jake, that is extremely helpful, I didn't realise that Rebasing will not replay merge commits - that helps to explain a lot.

I have generally been using Visual Studio with the Git plugin / UI - but it doesn't expose many of these git commands so I'm having to switch to GitBash on windows for this stuff.

It seems my local repo is missing upstream remote.

image

So i'll add that, and then follow those steps.

I think the penny is slowly dropping.

I am just wondering, is it always the case that you have to manually add the remote for "upstream" - i would have thought the cloning process would potentially also copy the remotes from the source repo and add them to the clone repo automagically. Perhaps I am expecting too much :)

Thanks for your help :)

@dazinator
Copy link
Member Author

Ok - have submitted the new PR - will close this one! Thanks again

@dazinator dazinator closed this Jan 15, 2015
@JakeGinnivan
Copy link
Contributor

@dazinator yeah, have to manually add upstream as a remote.

My normal clone process is

git clone /jakeginnivan/repo.git
git remote add upstream org/repo.git
git fetch upstream
git branch --set-upstream-to upstream/master

The last step makes master track upstream, not your fork. Handy when git is telling you how many commits you are behind. You want it tracking upstream

@gep13
Copy link
Member

gep13 commented Jan 15, 2015

@dazinator sorry, I should have went into more detail when I made my first comment. Looks like @JakeGinnivan has got you covered though 👍

@gep13
Copy link
Member

gep13 commented Jan 15, 2015

Here is the replacement PR for this one: #349

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.

3 participants