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 [1]. 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 1. http://randyfay.com/content/avoiding-git-disasters-gory-story -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
