Le mercredi 25 juin 2014 13:15:23 UTC+2, Konstantin Khomoutov a écrit :
> 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?
Le mercredi 25 juin 2014 09:26:50 UTC+2, treaki a écrit :
> i am using git with an ssh remote running at my router@home. the most
> times i use it the following way:
> git pull
> git push
> the problem i see it that he ueses 2 ssh sessions for this job, so i would
> like to ask if there is a way to do everything together using one session.
> thanks for your help
You're right, running those two commands in a row does open two SSH
connections, one for the git-pull and another one for the git-push. It's
not a problem in itself, but if you're looking for optimising this process
as I think you are, I'd definitely back Konstantin's suggestion of setting
up SSH multiplexing: it will allow any of your processes using SSH to
re-use existing SSH connections instead of opening new ones each time. Have
a look at the ssh_config man page
in particular the *ControlMaster*, *ControlPath* and *ControlPersist*
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.