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. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in.

How does one keep their fork up to date? For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch?

And how does a pull request actually work? Is it a request to merge my entire branch, or just some specific files? and do I need a separate branch for each pull request, or is the pull request itself somehow isolated from my changes?

Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful.

    Thanks

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. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in.
>
> How does one keep their fork up to date?

Just push to your fork/master after pulling from the (shared) origin/master.

> For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch?

In a non personal project you NEVER commit to master. You make each single fucking change in a specific branch (sorry for the language, it's intentionally gross). the master branch is only updated when you pull from the origin.

> And how does a pull request actually work? Is it a request to merge my entire branch,

Yes it's a merge. Optionally all the commits can be squashed.

> or just some specific files? and do I need a separate branch for each pull request,

Yes, yes yes, again. ~master is sacrosanct.

> or is the pull request itself somehow isolated from my changes?
>
> Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful.
>
>     Thanks

The only article i've ever read about git was when the first time i needed to squash (actually i rather do "fixup" 99% of the time...) so i have nothing else to add.

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. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in.
>
> How does one keep their fork up to date? For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch?

you can fork it, set dmd/master as upstream and then git fetch upstream. you can then rebase.

>
> And how does a pull request actually work? Is it a request to merge my entire branch, or just some specific files? and do I need a separate branch for each pull request, or is the pull request itself somehow isolated from my changes?

commits can be cherrypick-ed or you can request your entire branch to be merged. it doesn't always have to be the master branch. for example, if there's std.experimental.logger branch, you can ask for your branch to be merged with that. having a seperate branch for each feature is most of the time the way to go. makes it cleaner for yourself. later on you can delete those merged branches.

>
> Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful.
>
>     Thanks

Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Since then I always access git via mercurial. In comparison Mercurial is far better a VCS tool.

On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote:
> Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake).

Who hasn't ;)
Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch.

> Since then I always access git via mercurial. In comparison Mercurial is far better a VCS tool.

I use git gui (i find other GUIs slower even if nicer) but even...there are few commands to know:

- checkout /*select a branch or a commit in the history*/
- commit /*validate changes*/
- pull /*get upstream changes*/
- push /*send upstream changes*/
- rebase /*squash - fixup*/
- stash /*backup before pull in case of...*/

you can live with that.

On Sunday, 3 December 2017 at 23:39:49 UTC, Basile B. wrote:
> On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote:
>> Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake).
>
> Who hasn't ;)
> Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch.

If you still lose changes, you could try using Mercurial with hggit. It can be a bit slow, but not destructive as git itself. ;)

I really wish Mercurial won instead of git. Now that hg evolve and hg topic are stable, that actually alleviates the need for git. But the world talks git now. So everyone else is forced to talk in git :(

I guess, without StackOverflow and GitHub, no one would be using git.

Facebook uses Mercurial and their team is working on a Mercurial server in Rust. https://github.com/facebookexperimental/mononoke

I thought Facebook uses DLang as well. No one's motivated to write one in DLang?

Basile B. wrote:

> On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote:
>> Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake).
>
> Who hasn't ;)
me.

> Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch.
"git reflog". nothing commited is *ever* lost until you do "git gc". git sometimes does GC on its own, so you can turn it off with:

	git config --global gc.auto 0

don't forget to manually GC your repo then with "git gc", or it may grow quite huge.

On Monday, 4 December 2017 at 01:54:57 UTC, ketmar wrote:
> Basile B. wrote:
>
>> On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote:
>>> Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake).
>>
>> Who hasn't ;)
> me.
>
>> Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch.

"git reflog". nothing commited is *ever* lost until you do "git gc".

This needs to be repeated: nothing in git is ever lost if it had been commited. You can lose untracked files, but commits do not disappear.
If you're unsure before an operation and have difficulties to use git reflog. Before doing the operation, do a simple git branch life-draft (or whatever you want). After the operation if it failed, you still have the commit your HEAD was on referenced by the life-draft branch.
branches and tags are just pointers in the directed graph a git repositery is. The interface only does not display the branches that have no entry pointer.

git sometimes does GC on its own, so you can turn it off
> with:
>
> 	git config --global gc.auto 0
>
> don't forget to manually GC your repo then with "git gc", or it may grow quite huge.

On 12/03/2017 03:05 PM, bitwise wrote:
> I've finally started learning git, due to our team expanding beyond one person - awesome, right? 

PROTIP: Version control systems (no matter whether you use git, subversion, or whatever), are VERY helpful on single-person projects, too! Highly recommended! (Or even any time you have a directory tree where you might want to enable undo/redo/magic-time-machine on!)


> 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. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em.

Congrats! Like Arun mentioned, git's CLI can be a royal mess. I've heard it be compared to driving a car by crawling under the hood and pulling on wires - and I agree.

But it's VERY helpful stuff to know, and the closer you get to understanding it inside and out, the better off you are. (And I admit, I still have a long ways to go myself.)

> What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in.

Yea. It's fundamental stuff, but it can be frustratingly convoluted for the uninitiated. TBH, I really wish we had widespread tools that cater to what have emerged as the most common best-practice workflows and the basic primitives of those workflows. I even went so far as to get started on such a tool (I call it "wit"), but it's been kind of on the back burner lately, and it's still far too embryonic for any kind of release. (I am still using a git repo for it locally though! Again, highly recommeded. At the very least, just because there's nothing worse than accidentally loosing a bunch of important code, or finding you need to undo a bunch of changes that didn't work out.)

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.)

> How does one keep their fork up to date? For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase?

Yes. "pull" from the official ~master to your local repo's ~master, if necessary rebasing your changes on top of the new ~master. Although generally, you shouldn't have much (or any) changes in your own ~master branch, so typically the rebase part really shouldn't be needed at all, since you shouldnt have any local changes on ~master which would need to be rebased (this ideal is a situation git refers to as "fast-forward").

Unless, of course, you happen to be futzing around making some changes and making your commits to your ~master (which you're not *supposed* to be doing anyway - standard best practice is to do all your work within a branch). In this case you probably will need to rebase. (The other alternative to rebasing is always a merge, but in the specific situation you're describing, rebase is definitely cleaner and will lead to less problems).

> Will that actually work,

Yes.

> or is that impossible across separate forks/branches?

Totally possible. In fact, that's exactly the sort of stuff git is designed to handle.

> What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch?
> 

You pretty much already got this right. First, you do just as you said above:

1. Pull from the official repo's ~master to your local repo's ~master (rebasing, if necessary, any commits you may have on your local ~master. Although, like Bastile said, if you're making local commits to ~master then *technically* "you're doing it wrong").

2. And then, after you've pulled (and maybe rebased) the lastest official updates to your local machine...maybe then you added some more commits of your own...then you can push it all from your local machine's clone to your remote fork.

Think of your remote github fork as the "published" copy of your local repo. It should exactly mirror your local repo (minus whatever branches/commits you're not yet ready to unleash upon the world): You do your work locally, and whenever you want to "publish" or "make public" your local work, you push it from your local repo to your remote github fork. That's all your remote github fork is: A copy of your whatever parts of your local repo that you've chosen to publish.

> And how does a pull request actually work?

Those two steps I outlined above? A pull request is the step 3:

3. After you've done steps 1 and 2 above, go to your remote fork on github.com, go to whatever branch you were making your changes on (you *were* making all your changes in a separate branch and not ~master, right? Because otherwise, doing another PR before your last one is merged becomes a big PITA - that's why people are so adamant about doing all your work in separate branches even though it's honestly a bit of an administrative pain to make a branch every time there's a change you're brewing in your mind.) Then, hit the big button to make a PR out of your branch. The PR tells the others you want them to pull the commits from your branch on your github remote repo, into their ~master.

> Is it a request to merge my entire branch, or just some specific files?

The entire branch. Or specifically, the commits in your branch. And 99.9% of the time, the way it works is, your PR proposes they merge your "feature-foobar" or "issue 977734" branch into THEIR ~master. And then when they approve and merge your PR - there it goes - your commits get copied from your branch to their repo's ~master.

> and do I need a separate branch for each pull request, or is the pull request itself somehow isolated from my changes?

You *should* create a separate branch for each pull request unless you're a masochist. There's *no* isolation other than whatever isolation YOU create. (Not my idea of award-winning software design, but meh, it is what it is).

This is why people are adamant about making a separate branch for each pull request. *Technically* speaking you don't absolutely HAVE to...But if you *don't* create a separate branch for each PR, you're just asking for pain: It'll be a PITA if you want to create another PR before your first one is approved and merged. And it'll be a PITA if your PR is rejected and you want to do any more work on the codebase.

Think of your local ~master as being a direct mirror of the official repo. Do your work in separate branches (each to be converted into individual PRs), and keep your ~master as your copy of "this is the current state of the official project".

> If anyone can
> offer any kind of advice, or an article that explains these things
> concisely and effectively, that would be helpful.

You asked about keeping your fork up-to-date. Like I mentioned before, typically your fork should have these branches:

~master: Should be an exact copy of what the official project's ~master branch looked like last time you updated.

issue95423: Your work that's going to be your PR to fix bug #95423. Starts with ~master and then adds additional commits on top.

foobar-feature: Your work that's going to be your PR to add feature foobar. Starts with ~master and then adds additional commits on top.

So, you've got it like that, and your PRs are taking awhile to develop. In the meantime, the official project receives a lot of updates, which makes your local clone out-of-date. So what do you do?

1. Pull the lastest changes from the official repo's ~master to your local ~master. This should be trivial, and git calls it a "fast-forward". After all, your ~master is identical to the official one, except you're just missing the newest commits.

2. Pull the lastest changes from the official repo's ~master to each of your local branches: issue95423 and foobar-feature. For these, you'll need to rebase your changes on top of what you're pulling. There might be conflicts. If so, you'll need to resolve them.

That's it. Then when you're satisfied with your changes:

3. Publish, by pushing your local issue95423 or foobar-feature branch to a same-named branch on your github remote repo (have git create this new branch if it doesn't already exist on your github remote repo).

4. Go onto github.com and create a PR out of the issue95423 or foobar-feature branch of your github remote repo.

5. Optionally, add more commits to your local branches, push them to your github remote repo, and when you do, your PR will automatically be updated with the new commits.

On Monday, 4 December 2017 at 04:45:01 UTC, Patrick Schluter wrote:
> On Monday, 4 December 2017 at 01:54:57 UTC, ketmar wrote:
>> Basile B. wrote:
>>
>>> On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote:
>>>> Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake).
>>>
>>> Who hasn't ;)
>> me.
>>
>>> Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch.
>
> "git reflog". nothing commited is *ever* lost until you do "git gc".
>

Actually (and i reply to ketmar too) i've never lost commits either. What 's happened to me is that i lost non-validated stuff in the staging area b/c as you noticed otherwise it would be recoverable.

Now i use "git submodule foreach git clean -f" to clean submodules.