Container Name Generator
According to names-generator.go :
Docker, starting from 0.7.x, generates names from notable scientists and hackers.
History
The commit history of this file only goes back to 2013:
Questions
What did docker use prior to 0.7.x? Animal names?
Is that list (or older docker source code) available somewhere?
In the GitHub UI, click "History" at the top-right corner of that file's page. That takes you to a listing of all commits that have ever touched this file. There aren't actually that many; the oldest, which you cite in the question, is commit a009d4a. Click on its commit hash in the UI.
That takes you to a page that shows that commit. That commit is mostly a pair of file renames. Note what got renamed.
That also commit has 1 parent 3fc9de3. Click on that commit hash, and then the "Browse Files" button at the top-right corner of the UI. You are now browsing the Docker source tree at the commit immediately before the rename.
The commit description and diff reference a package namesgenerator that got renamed. You can find that in the top-level directory listing in the pre-rename commit. Click into that, and then click "History" on that page to find the very early history of the name generator.
From this history we can find out:
The name generator didn't exist at all more than 2 months before the rename commit you cite; its first commit was on 28 October 2013.
The very first version of it generated names of the form color_animal. Its second commit added more colors and animals, so it would allow names like brown_bear, red_bird, yellow_duck, and so on.
The mood_inventor scheme was introduced in the fourth commit on 23 November 2013.
These pairs were required to have cool inventor names, be easy to remember, be mildly funny on occasion, and be politically correct, though the heuristics for determining these were rather limited (all four conditions were fixed to true). These requirements were removed in 2016 (since the test actually did nothing).
Looking at the Docker CHANGELOG.md, Docker 0.6.5 added the initial "Containers can now be named" with the first color_animal scheme, 0.6.6 "Add[ed] some more colors and animals to increase the pool of generated names", and 0.7.0 added "Container naming: organize your containers by giving them memorable names" with the modern scheme.
Related
I want to get the state of a repository as of a given date, view the files and then subsequently view the history of those files independently in Team Foundation Version Control (TFVC).
I know I can "Get this Version", but that's not what I want. I'm not looking to change my local system or download and change my working directories contents. Even if I do a "Get this Version" and view the contents of a file that exists which was replaced later down the line with a file of the same name (a "Delete" followed by an "Add" in a different commit), the history of the file I'm attempting to view seems to only follow the ancestry of the most recent file, not the older one in question.
Ex:
Feb: ADD Repo\MyFile.cs
March MODIFY Repo\MyFile.cs
April: DELETE Repo\MyFile.cs
May: ADD Repo\MyFile.cs
June: MODIFY Repo\MyFile.cs
If I do a "Get This Version" at revision #2 and then, after getting that version, find the file MyFile.cs in my project attempt to view the history of the file, I only see history from revisions #4 and #5. I want to be able to get insight into revisions #1 - #3 and see that ancestry clearly.
Is there a way to do this?
A colleague sent me a Gerrrit code review "draft" (I suppose via "refs/drafts/master" instead of "refs/for/master") and then left on holiday. Without downloading the patch and submitting it myself, how can I promote his draft to a full regular code-review so I can approve it & submit it for merging?
I think this is a similar question, but it's for git-review, not Gerrit. Also I'm interested in doing it from the Gerrit web GUI if at all possible. And I don't see a "Publish" button on my Gerrit web GUI for that draft. (And currently it doesn't say anything about merge conflicts, as long as I hurry....)
If I click on the "Patch Sets" link in the top right of the GUI, this is what I see:
In the top left it says "Change 58358 - Draft", and in the middle of the window it shows this:
Only the change owner can publish a draft patch set. Using the UI's cherry-pick option as described in other answers won't work because the cherry-pick implementation preserves the draft status on the new change or patch set.
As far as I know the only way to force the change into NEW state is to manually download the commit and push a new patch set using refs/for/master instead of refs/drafts/master.
Note that if you're not rebasing the change onto a new parent at the same time, you might need to slightly edit the commit message to make gerrit accept it. Otherwise it'll reject with no new changes.
If your colleague add you as reviewer, you can. You can cherry-pick this commit.
Click on download link at the right-top corner, and there are aliases for commands above.
But as you updated your question, you don't want to check out and manually push or cherry pick to master branch. You can use cherry-pick\merge button on ui, if you are confident in this mr, and it should be on master branch. Also you can publish this commit for other reviewers.
p.s. updated (you can cherry-pick, merge, publish via UI)
Do the following procedure:
1) Go to the draft change page
2) Click on Cherry Pick button
3) Write "master" in the Cherry Pick to Branch field
4) Adjust the Cherry Pick Commit Message if needed
5) Click on Cherry Pick Change button
It'll be created a NEW CHANGE cherry-picked from the draft change. Go to the new change page and follow the regular Gerrit process (review, approve, submit). The original draft change can be abandoned or deleted.
Is there any way I can get the git commit id to show on the current row?
It doesn't even show when I click on the grey bit with the commits - no IDs
I have to click on the "See details" link - which is 2 clicks too many, according to my team mates who are addicted to commit hashes and spurn the use of human-readable version numbers.
Even worse, when there are no commits that haven't been built yet, that box with "2 commits" is just blank with no link and so no commit id at all.
Ideally someone knows of a way to do it with groovy in the Jenkinsfile.
I have already played around with stage("Doing " + GIT_COMMIT_ID) but that makes the cells in the table extra extra wide.
Is there some Jenkins-foo I can use?
I am considering using Docker for a project, but I have one question I have not been able to find an answer to in the docs or anywhere else: is it possible to commit only a subset of the changes I make to an image?
Let's say I start a container, make a bunch of changes to the filesystem, get my thing working well and then want to commit them to a new base image. However, I only want a small subset of the changes that were actually made (maybe some of them were to log files, or other things that are unimportant). Does docker commit allow to specify that I only want changes, say, under some part of the filesystem to be committed?
You would just first remove the unnessecary files. To my knowledge, partial commits are not supported.
If you want to do this, using docker diff is really handy. You can easily see what the file system changes are that way. You can even run that against a running container.
I have a library on github which uses rebar, but it has never been tagged via git. As of this writing, the app.src file indicates it is version 0.1 (this has never been changed).
I'd like to make some commits which will change some of the function definitions. I need to use tags and application versions so this doesn't negatively impact users, but I'm unclear on the order I'm supposed to tag, bump, etc.
What steps do I take now and in the future in order to ensure that users can code to the version of their choice?
I use the following scheme in my repositories:
X.Y.Z where X is major, Y is minor and Z is patch releases (taking some ideas from
Semantinc Versioning)
The order I change .app.src files and tags is as following:
Make the change, bump version number in the .app.src file and commit it with a
nice commit message.
Tag that commit using the same version number as in the .app.src file. I enter a
tag message of the following form:
Version X.Y.Z
- New Feature 1
- New Feature 1
- Fix this and that
The tag is then GPG signed with my signature (using the -s flag)
Push the commit with git push && git push --tags to upload both the commit and the tag to the server.
I don't use semantic versioning's "vX.Y.Z" scheme as tags because I think it's superflous and doesn't look very good.
Once you have proper tagging and versioning (of your choice) your users should be able to rely on using the Git tags as is.
You can see the results here: https://github.com/eproxus/meck (you need to download the code to see the tag messages and verify the GPG signature).