[Vm-dev] the purpose of CI

[Tim Felgentreff]

Ben and Eliot, just in case you missed Jacobs answer to the git pull -a
question (which you both seem to be confused about)

On Fri, 2 Jun 2017 at 10:00 Jakob Reschke <jakob.reschke at student.hpi.de>
wrote:

>
> 2017-06-02 1:36 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> ...
> >
> > The commit is related to a graph of previous commits, right?  So a branch
> > implies a distinct set of commits, right?  When one merges from a branch,
> > the commits on the branch don't get added to the target into which one
> > merges do they  Isn't that the difference between pull and pull -a, that
> > the former just pulls commits on a single branch while pull -a p;pulls
> > commits on all branches?
>
> Git commits refer to their parent commits (merge commits have more
> than one parent), but do not store on which branch(es) they are or
> were on. Since a branch is just a reference (to a commit), you may
> talk about the commits that are reachable from a branch (it is what
> you get from "git log branchname"). But this set almost always
> overlaps with that of other branches because of all the common
> ancestor commits.
>
> Merging a branch adds an additional parent to the to-be-created merge
> commit. Thus, the commits from the merged branch become reachable from
> the branch into which you are merging. So, in a way, they do get added
> to the merge target.
>
> pull -a does not "pull on all branches" and does not usually affect
> the result of the merge at all. "git pull <remote> <branch>"
> essentially means "git fetch <remote> <branch>", which writes the
> fetched commits to a temporary reference called FETCH_HEAD, followed
> by "git merge FETCH_HEAD". The -a stands for --append, is an option
> for the fetch, and means that instead of overwriting what is in
> .git/FETCH_HEAD, append the newly fetched commits there. But "git
> merge FETCH_HEAD" will only use the top commit from that file anyway,
> so this is kind of pointless for pull. In fact, it might lead to
> merging the wrong branch or not merging anything at all because the
> latest fetched commit with -a goes to the end of FETCH_HEAD, not the
> top.
>
> But even if it meant to "pull commits on all branches", why would that
> be useful? When you work and pull on branch/feature X, why would you
> want to invoke a merge on an unrelated branch/feature Y?
>
> If you wanted to merge more than one upstream branch into your current
> branch, you would have to name them all when pulling:
>
>    git pull origin branch1 branch2 ...
>
> ...which attempts a merge with (1 + number of unmerged upstream
> branches named on the command line) parent commits.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170604/1d6cb5ec/attachment.html>