On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote:
>
> How does one keep their fork up to date? For example, if I fork

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

On 12/3/17 3:48 PM, Basile B. wrote:
> On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote:

>> or just some specific files? and do I need a separate branch for each pull request,
> 
> Yes, yes yes, again. ~master is sacrosanct.

For good reason. If you commit things to your master, and they don't get merged into the mainline master, now you have a borked master, and you have to reset it.

One other thing to mention, whenever I update my master from the upstream fork, I always always specify --ff-only, which means I'm only going to let you merge if both my master and the upstream master are exactly the same (i.e. my master is just an earlier version of upstream master). Even though I never *intentionally* commit to master, this is a sanity check to make sure I didn't *accidentally* do it.

If you have to reset master, then I recommend reading articles. I always use this website for any git questions: https://git-scm.com/book/en/v2

Or just do a search on google. You will probably find the answers in stack-overflow.

-Steve

On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote:
> I've finally started learning git, due to our team expanding beyond one person - awesome, right? Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. [snip]

Here's my usual workflow.
1) Fork project
2) Add upstream
3) Create a new branch
4) Make changes
5) Add/Commit to branch
6) Push

I sometimes find myself getting tripped up if I need to deviate from this. Ideally, I could just make the change, push it, and it gets accepted. Sometimes though you have to make changes to what you've done and add more commits and then the master has additional updates and you may need to handle merge conflicts.

I make fewer mistakes now than when I started, but I'm still nowhere near as good with it as I should be.

On Monday, 4 December 2017 at 11:51:42 UTC, Nick Sabalausky (Abscissa) wrote:
> On 12/03/2017 03:05 PM, bitwise wrote:
>
> One thing to keep in mind: Any time you're talking about moving anything from one repo to another, there's exactly two basic primitives there: push and pull. Both of them are basically the same simple thing: All they're about is copying the latest new commits (or tags) from WW branch on XX repo, to YY branch on ZZ repo. All other git commands that move anything bewteen repos start out with this basic "push" or "pull" primitive. (Engh, technically "fetch" is even more of a primitive than those, but I find it more helpful to think in terms of "push/pull" for the most typical daily tasks.)
No, the pair us push/fetch. pull is fetch+merge and a lot of confusion comes from that in fact. I've seen several people cursing git because of that idea that pull is the opposite of push. When I explained that they should never use git pull, but always separating fetch from the merge, it clicked every time.
So, avoid pull, look first what fetch does and if that is what you thought it would do, do the merge and be happy.

On 12/04/2017 09:38 AM, Patrick Schluter wrote:

> So, avoid pull, look first what fetch does and if that is what you
> thought it would do, do the merge and be happy.

+1

Paraphrasing someone I trust very much, "Never 'pull', always 'fetch -p' and then rebase."

Ali

On 12/03/2017 12:05 PM, bitwise wrote:
> I've finally started learning git

git is one of those things where as soon as you understand how it works, you lose the ability to teach. :) I'm watching this thread with amusement because like most online tutorials, nobody is mentioning the relationship of *three* repos in the picture:

- The original repo, which will be updated by others frequently

- Your clone of it on GitHub which will be hopelessly behind unless you update it (if I'm not mistaken, none of the replies mentioned '-force')

- Your local (e.g. laptop) clone of your GitHub clone, where you do all the work

Dear git experts, given 3 repos, now what are the steps? Is the following correct? What are the exact commands?

- Only once, create the original repo as an upstream of your local repo.

- For each change:

1) Fetch from upstream

2) Rebase origin/master (on upstream, right?)

3) Make changes

4) Commit (potentially after 'add')

5) Repeat steps 3 and 4 as needed

6) 'git push -force' so that your GitHub repo is up-to-date right? (There, I mentioned "force". :) )

7) Go to GitHub and press the big button to create a pull request

Since I still don't know how git works, :) I trust my steps above but I know the steps can use improvement.

Ali

On 12/04/2017 12:14 PM, Ali Çehreli wrote:

> 2) Rebase origin/master (on upstream, right?)

2.5) Create a branch and do all work on that branch

> 3) Make changes

Ali

On Monday, December 04, 2017 12:02:37 Ali Çehreli via Digitalmars-d-learn wrote:
> On 12/04/2017 09:38 AM, Patrick Schluter wrote:
>  > So, avoid pull, look first what fetch does and if that is what you
>  > thought it would do, do the merge and be happy.
>
> +1
>
> Paraphrasing someone I trust very much, "Never 'pull', always 'fetch -p' and then rebase."

I use pull all the time, but it's always pulling master from upstream, and I never make any changes to my local master; all my changes go on branches. Using github or gitlab, I really don't have any other reason to pull or fetch, because the only place that I normally care about getting code from is upstream master. Any code being merged from someone else is merged into upstream master via github/gitlab, and my code is all done on separate branches that get pushed up to github/gitlab to be merged. With different workflows (like sharing work directly with someone rather than using github or gitlab), I could see reasons to be wary of pull, but in the typical workflow with github/gitlab, I really don't see any reason to be wary of it - not when the only time it's needed is to sync my local master with the main one on github/gitlab.

- Jonathan M Davis

On Monday, 4 December 2017 at 20:14:15 UTC, Ali Çehreli wrote:
> 6) 'git push -force' so that your GitHub repo is up-to-date right? (There, I mentioned "force". :) )
>

The right option name is --force-with-lease ).

I'm going to answer with something that others may not agree with, maybe they can enlighten me, but let me first get a generic principle of git and answer some questions.

Git has 2 types of branches, local branches (you know them as just branches) and remotes (which have their own local branches). I say this to remove the confusion with having an original repository, a forked repository, and a cloned repository. When it comes to interactions with these repositories the only difference from your local branches is that you can't interact directly with them (i.e. you can't commit to them) and the interactions require specifying the remote location of the branch.

Some of your other questions are about GitHub and Forking. Git doesn't know what a fork is, but GitHub ties a pull request to a branch. This means you can update/change your pull request by updating/changing your branch. From that you should realize each pull request needs its own branch.

Back to git remotes. I'm sure you're aware of the commonly named "origin" remote and possible the second common "upstream." When you're dealing with many remotes your local branches can get complicated. For example many people utilize 'master' as a *tracking* branch to "origin" well, "upstream" if there is one. I'm to the point that in this situation my recommendation is just delete your 'master' branch both local and "origin." Don't worry you can bring it back if you need it, you won't need it.

Here is the thing, you already have two, maybe 3 master branches 'master' 'origin/master' 'upstream/master' these are local branches (they are special in that you can't commit to them). And these are also your true tracking branches, whenever you fetch/pull from your remote these branches are updated, they will always reflect the branch of the remote and they will never conflict during updates. You can always create your own master $ git branch master upstream/master

I want to note that 'origin/master' is different from such commands as `$ git push origin master` because in the first you are referring to a local branch and the second you reference your remote followed by your remotes local branch (actually I could be wrong here because the full syntax is `$ git push origin master:master` where the left: is your local and :right is the remote local branch [and note that `push origin :master` would delete the remote master branch because you're push no branch to it.).

I hope that this along with answers other have given will help you to answer all of your questions.