Under 1000 opened bugs for Phobos

[Chris via Digitalmars-d]

On Wednesday, 4 November 2015 at 00:06:34 UTC, H. S. Teoh wrote:
>
>
> It's not that hard. The thing is, the best way is to ALWAYS 
> make changes in a topic branch, never on master. That way, you 
> just pull upstream into master and rebase your topic branch:
>
> 	git checkout -b my_bugfix
> 	... # make edits here
> 	git commit
> 	git checkout master
> 	git pull upstream master
> 	git checkout my_bugfix
> 	git rebase master
> 	# Now your fixes are updated.
> 	git push -f origin
>
>
>> It's not D, it's git(hub) that makes things complicated. It'd 
>> be good if you could just update your own branch on github 
>> (refork it or whatever) and then clone it onto your own 
>> machine. But it's not that straight forward.
> [...]
>
> I'm not sure I understand what's so non-straightforward about 
> it. If you always work in a topic branch, as I suggested above, 
> it should be relatively painless. It's when you make changes on 
> master and then try to sync with upstream, that things become 
> very messy, very quickly.

What I tried to do was to update my branch to the latest version 
of master and then send my humble fix back to my (updated) branch 
and up to master. The whole thing about "topic branch" and the 
array of commands that follow shows (me) that it is not straight 
forward. I have to look up/ask every time "Sorry, how do I do 
that again" - "rebase, upstream blah". Thing is, I expected 
github (not git) to be easier, like clicking on "Update branch", 
then

     git update
     git commit mychange.d

and then go to github and just click on "make PR". IMO, it's a 
waste of time to deal with all those commands (upstream blah) 
when you have a homepage like github. They should handle it. But 
that's just my opinion.

The base line is, it makes me think twice about changing 
something, especially when I could do it on the fly as in "Uh, 
there's something I could fix, wait ... Ah, no how do I do that 
again, uh, wait git upstream, no stop rebase ah f*ck! I'll do it 
tomorrow ..." (I won't)

> Unless you're complaining about git itself, in which case my 
> only suggestion is that you have to take the time to learn the 
> "concept" behind git. It's very likely *not* what most people 
> imagine when they think of "version control", and it's pretty 
> important that you understand that when working with git, you 
> have to think in terms of "directed acyclic graph" rather than 
> "version control" in the traditional sense of the word. Trying 
> to work with git with the wrong mental model of what it 
> actually does will inevitably land you in a situation where you 
> feel like you don't know how to fix it.
>
>
> T