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
