On Friday 02 June 2017 12:28 AM, Fabio Niephaus wrote: > As Tim F. already mentioned, the initial idea was to use Cog as the dev > branch, and the master for stable releases. Unfortunately, we don't have a > working procedure for releasing new OpenSmalltalkVMs. I dared to create > releases when we "had to" and after I asked Eliot for his recommendation. I admit to feeling a bit confused about this 'master'. > But it would be much nicer to have more frequent releases which our CI > infrastructure allows us to do. +1. Eliot is right in proposing in an earlier post on taking a step back to look at the overall design now that we have Git and CI. My understanding of a master branch is the opposite of what is described above :-(. In a typical project, it is the master (or trunk) branch which is under active development and receives a stream of feature and repair patches. At some point of stability, it undergoes a feature freeze and starts taking in only repairs. Freeze helps get more eyeballs on clearing bug backlog yielding a series of candidate releases culminating in 'public release', tagged and branched to a maintenance branch. The master is then opened up for feature patches and the cycle proceeds. Release branch is then actively maintained with security and compat patches for two cycles (so that git bisect can be used to trace regressions). Regards .. Subbu |
In reply to this post by Ben Coman
2017-06-02 1:36 GMT+02:00 Eliot Miranda <[hidden email]>: > > On Thu, Jun 1, 2017 at 10:40 AM, Ben Coman <[hidden email]> 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. |
In reply to this post by Eliot Miranda-2
On Fri, Jun 2, 2017 at 7:36 AM, Eliot Miranda <[hidden email]> wrote:
ah, gotcha. I was thinking more along the lines of short lived experiments where things might break to before fully understanding the impact.
Okay. If master is kept reasonably up to date, then this concern goes away.
Yes. This already happens on the Cog branch doesn't it? It just hasn't seemed a priority to keep it green.
Just an aside: A dream scenario would be something like PharoLauncher also managing VMs as well as Images, gathering statistics on {OS. VM. Image} tuples started and crashed, reporting aggregate statistics to users to facilitate users (ranged across the technology adoption bell curve) to organically identify particular builds as real-world-tested-stable. But I'm not sure how workable that would be.
okay. just floating ideas.
As a second order effect yes, a branch pointing at a single commit implies the set of all its ancestors. I just found that page particularly enlightening... "Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline)."
I've had trouble trouble parsing that. On one hand, it might be considered that commits on the source branch *are* added to the target branch. One the other hand, it sounds like you concur that branches aren't a set of commits (since git under the hood has no "sets") - just the code of two specific commits being merged to create a new commit, to which the target branch reference is moved to.
Sorry I don't know. I never use `git pull`, rather always `git fetch` + `git merge` after some advice I read to get more flexibility and a chance to review changes first. I search extensively but really could only find regurgitation of this copied from the man-page... "-a --append Append ref names and object names of fetched refs to the existing contents of .git/FETCH_HEAD. Without this option old data in .git/FETCH_HEAD will be overwritten." which I don't understand.
It seems a better process for master is underway, so okay.
After being a bit slow, now got it.
okay. got it.
I guess experimental configurations are orthogonal - more of a build issue. Ideally adding features to an experimental configuration would still be done using a PR from a feature branch so the CI tests ensure no problems leaked out of their #ifdefs, but without that, experimental configurations is still a good step. cheers -ben
|
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 <[hidden email]> wrote:
|
In reply to this post by Eliot Miranda-2
> 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 repository is just a big key-value store. Keyed under SHA1 of their contents, the following kinds of values are stored - files, trees objects and commit objects. Files are themselves. Tree objects contain list of files and other tree objects. Commit objects contain a list of other commit objects and tree objects. I think it is nicely explained in the official git book: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects[10.2 Git Internals - Git Objects]. Commits are lists of SHA1s of other objects in the store. Each commit stores the SHA1 for its ancestor commit and/or any merged in commit. Each branch is a pointer to a SHA1. When you commit to a branch, a new commit object is created. The object for the commit is stored under its SHA1 and the branch pointer is set to this new SHA1. Any commit you know the SHA1 of can be compared/merged to/from any other commit you know the SHA1 of. The branches serve just like a pointer to a SHA1 that gets moved each time you make a commit to the branch. Since each commit contains a pointer the SHA1 of its ancestor and any commit merged from, you can walk the history with 'git log SHA1'. When you merge a commit, both the ancestors' SHA1 and the merged's SHA1 are added to the list of SHA1s that form the commit. Best Regards, Milan Vavra |
In reply to this post by timfelgentreff
Yes, that helped. Thx Jacob.
On Sun, Jun 4, 2017 at 4:56 PM, Tim Felgentreff <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |