Le jeudi 26 juin 2014 13:04:18 UTC+2, Konstantin Khomoutov a écrit :
>
> On Thu, 26 Jun 2014 01:44:34 -0700 (PDT) 
> Pierre-François CLEMENT <lik...@gmail.com <javascript:>> 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 
>

Not exactly, cuz' it feels like you're not supporting the use of *git-pull*. 
All I'm sayin' is that people can have perfectly legitimate reasons to use 
it.

Le jeudi 26 juin 2014 13:04:18 UTC+2, Konstantin Khomoutov a écrit : 

>
> > ... 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 
>

I agree with *almost* all of this, although I'll add to it that not all 
users need to go this far in their workflow. It's probably better if they 
do, but it's not required -- especially if you have a project maintainer 
for instance. They might also feel more comfortable investigating the files 
or the test suite's results rather than the repo's tree. I personally 
prefer investigating the commits too, but I do understand people who don't.

What I do not understand however, is what made you think *treaki* needed 
these explanations in the first place? Don't get me wrong, it's no big 
deal; but I could have asked the same question, and I would have 
appreciated not being told stuff I already know about git-pull / git-fetch 
/ git-merge.

-- 
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.

Reply via email to