[Vm-dev] the purpose of CI

[Ben Coman]

Yes, that helped.  Thx Jacob.

On Sun, Jun 4, 2017 at 4:56 PM, Tim Felgentreff <timfelgentreff at gmail.com>
wrote:

>
> 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/20170608/a7344b0f/attachment.html>