[Vm-dev] the purpose of CI

[Jakob Reschke]

2017-06-02 1:36 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
> On Thu, Jun 1, 2017 at 10:40 AM, Ben Coman <btc at openinworld.com> wrote:
>> I just want to interject a check everyone's understanding of git
>> branches.  Although I haven't used SVN, what I've read indicates SVN
>> concepts can be hard to shake and git branching is conceptually very
>> different from SVN.
>>
>> The key thing is "a branch in Git is simply a lightweight movable pointer
>> to a commit."
>> The following article seems particularly useful to help frame our
>> discussion...
>> https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is
>>
>
> 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.