Thread (89 messages) flat view 89 messages, 18 authors, 2016-08-11

Re: Cleaning up git user-interface warts

From: Michael K. Edwards <hidden>
Date: 2016-08-11 20:25:59

Possibly related (same subject, not in this thread)

On 11/15/06, Linus Torvalds [off-list ref] wrote:
But once you understand branches, and understand "fetch" (and it really
isn't _that_ complicated: fetch really does exactly what the name says, so
if you understand local branches, you will understand "fetch"), then it's
a much smaller step to explain "pull = fetch + merge".

But I bet people don't teach it that way. They _start_ by teaching "pull".
Right?
"git fetch" is certainly the right thing for the platform integration
role, in which one is trying to maintain a series of integration
branches which track the bleeding edge of some subsystems while
keeping the core stable on each branch.  This is not as impossible as
people make it out to be, but there certainly isn't much place for
automatic merges to _persistent_ branches.

It's fundamentally a backporting and cherry-picking effort, and the
git workflow puts it where it belongs: in the local repository, where
_transient_ branches can and should be created and destroyed casually
to track exploratory efforts.  These may include automatic merges and
even cruder techniques (git diff, hack on patch, apply patch).  Once
you figure out which bits you actually want to backport, you go back
to a fresh branch and cherry-pick the same bits with the tool instead
of manually, so that there is less noise in future merges.  When
you've tested a little, you merge this branch to the persistent branch
that other repositories track.

Cheers,
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help