On Thu, 26 Jun 2014 01:44:34 -0700 (PDT)
Pierre-François CLEMENT <lik...@gmail.com> wrote:
> > The imaginary `git pull-push` has no sense as `git pull` might
> > legitimately result in a merge conflict. Note that `git pull` is a
> > sort of macro for `git fetch` + `git merge` which just makes
> > certain (rather strong) assumptions about your workflow. Think
> > about this a bit more and you'll see that in fact you want `git
> > fetch-merge-push` which looks rather awkward and only suitable for
> > some automated changeset processing (and, honestly, I can't even
> > fancy one).m
> Git-pull (followed or not by git-push) is a perfectly sensible set of
> commands imo. Git-pull *is* a shortcut for git-fetch + git-merge
> upstream, so if you're not planning on investigating what commits
> you're pulling why bother doing in two steps (fetch then merge)
> rather than one?
Well, that's why I wrote
> ... which looks rather awkward and only suitable for some automated
> changeset processing (and, honestly, I can't even fancy one).
The chief problem with merging, as I perceive it, it that quite some
number of people understands it either as a sort of burden or a purely
mechanical process. In reality, when a VCS is used for
development (or some code base or something like this) merging is an
engeneering duty: reconciling your changes with someone other's changes
is no really different from writing new code, and it's of the same
importance. Those who don't understand this (and not properly trained
to do so) are entitled to repeat things like described in .
That is, even if merging went okay and no conflict was indicated, this
does not mean the resulting state of the repository is OK.
You have to verify it's okay -- by inspecting the results, by
building and running the test suite etc.
Only truly trivial cases are okay for the pull+push paradigm. But
anyway to deem them trivial you really have to know what you're pulling
which narrows the set of suitable workflows to an almost empty set
IMO. For instance, I do routinely use Git for one-man micro projects
where I have a repo on each of machines I work at and a central bare
repo to gateway the changes between all the involved repos. In this
workflow I just always push to the same branch in the central repo, and
when at the next work place, I do fetching and --ff-only merging locally
which is often reduced to something like
git fetch origin +branch:master
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.