Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]
Hi All, so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?) I have a VM that outputs a reasonable version info: /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT Compiler: 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] CoInterpreter VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun 16 12:53:33 2016 -0700 $ Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ Which begs the question how do I differentiate this from something built officially via Travis? Arguably the URL is wrong, and should only say " http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps should just include my local hostname and current directory when I make any kind of local modification. So the above would read ... VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 12:53:33 2016 -0700 $ Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ Alternatively we could add another field, or modify one of the existing fields to say "I'm official" however one would do that. I don't know how, I just know we need this. I shouldn't be able to pollute the VM pool by putting some VM on some site somewhere that i just happened to build after several sherries and some cannabis brownies that looks to all intents and purposes just like a VM built by our official Travis slaves. Hic. Chillin' _,,,^..^,,,_ best, Eliot
On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote:
Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?)
"git commit" will commit anything that has been "git add"ed to the index. -a is a convenience to automatically stage files that have been modified. HTH, Alistair
Hi Alistair, On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote:
Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?)
"git commit" will commit anything that has been "git add"ed to the index. -a is a convenience to automatically stage files that have been modified.
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
HTH, Alistair
-- _,,,^..^,,,_ best, Eliot
On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Alistair,
On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote:
Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?)
"git commit" will commit anything that has been "git add"ed to the index. -a is a convenience to automatically stage files that have been modified.
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
Because you can choose what files will be part of the commit (cherry-picking changes). -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote: Hi Alistair,
On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?)
"git commit" will commit anything that has been "git add"ed to the index. -a is a convenience to automatically stage files that have been modified.
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
Because you can choose what files will be part of the commit (cherry-picking changes).
Ok. My objection is primarily linguistic. For me "add" means include a previously uncontrolled file to the set under control, /not/ stage this for commit. I'm happy with the concept of staging; Bert implement Ted it in Monticello in being able to select changes to ignore (but note the improvement; the default is to commit all changes; the exception is to exclude; git has this bass-ackwards). But one should call a spade a spade and have a command called eg stage, not misuse add. My problems aren't with hits concepts; they're to do with gits willfully perverse nomenclature. Add ferchrissakes. It's absurd. At least I'll get used to it now ;-)
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Thu, Jun 16, 2016 at 08:51:16PM -0700, Eliot Miranda wrote:
On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote: Hi Alistair,
On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?)
"git commit" will commit anything that has been "git add"ed to the index. -a is a convenience to automatically stage files that have been modified.
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
Because you can choose what files will be part of the commit (cherry-picking changes).
Ok. My objection is primarily linguistic. For me "add" means include a previously uncontrolled file to the set under control, /not/ stage this for commit. I'm happy with the concept of staging; Bert implement Ted it in Monticello in being able to select changes to ignore (but note the improvement; the default is to commit all changes; the exception is to exclude; git has this bass-ackwards). But one should call a spade a spade and have a command called eg stage, not misuse add. My problems aren't with hits concepts; they're to do with gits willfully perverse nomenclature. Add ferchrissakes. It's absurd. At least I'll get used to it now ;-)
The Linux Kernel development has some fairly strict rules about how patches are structured and what is included in each commit (which I can't remember now). One of the requirements is that you have a working system after each commit, and that it is fairly small in scope (they define "small" properly). git has a great "bisect" feature which makes it easy to go back and find where problems started, and structuring the commits is necessary for bisect to be easily usable. I also find it not particularly intuitive, but it is still a great tool once you understand it. Cheers, Alistair
On Fri, Jun 17, 2016 at 11:51 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote: Hi Alistair,
On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?)
"git commit" will commit anything that has been "git add"ed to the index. -a is a convenience to automatically stage files that have been modified.
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
Because you can choose what files will be part of the commit (cherry-picking changes).
Ok. My objection is primarily linguistic. For me "add" means include a previously uncontrolled file to the set under control, /not/ stage this for commit. I'm happy with the concept of staging; Bert implement Ted it in Monticello in being able to select changes to ignore (but note the improvement; the default is to commit all changes; the exception is to exclude; git has this bass-ackwards). But one should call a spade a spade and have a command called eg stage, not misuse add. My problems aren't with hits concepts; they're to do with gits willfully perverse nomenclature.
Hi Eliot, Seems enough others must have felt the same that this was added to help... https://git-scm.com/docs/git-stage Perhaps it would be preferred to use "stage" over "add" in documenting the usual workflows for this project? cheers -ben
On 17 June 2016 at 00:08, Eliot Miranda <eliot.miranda@gmail.com> wrote:
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
The mindset with git is that your working copy is a sort of experimentation area where you can have a crazy scientist attitude. When you commit, however, you switch hats and become the thorough developer that cares about your future self, and therefore has done all changes in a perfect didactic sequence so that you can understand what the hell your future-past-self was doing. If your crazy-scientist-self is already auto-censored into producing limpid incremental patches, then he can use git aliases for his preferred workflow (for instance I have git ci, git co, git st configured to mimic their svn counterparts; git staged shows a diff of what's to be committed next, etc) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Fri, Jun 17, 2016 at 6:46 AM, Damien Pollet <damien.pollet@gmail.com> wrote:
On 17 June 2016 at 00:08, Eliot Miranda <eliot.miranda@gmail.com> wrote:
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
The mindset with git is that your working copy is a sort of experimentation area where you can have a crazy scientist attitude. When you commit, however, you switch hats and become the thorough developer that cares about your future self, and therefore has done all changes in a perfect didactic sequence so that you can understand what the hell your future-past-self was doing.
If your crazy-scientist-self is already auto-censored into producing limpid incremental patches, then he can use git aliases for his preferred workflow (for instance I have git ci, git co, git st configured to mimic their svn counterparts; git staged shows a diff of what's to be committed next, etc)
While creating svn like aliases and using "commit -a" may initially aid transition to git from svn, consider that this is a bit like a C programmer migrating to C++ to earn OO, versus learning OO by using Smalltalk. The hybrid nature of the C++ impedes them changing their *mindset* to use OO the full power of OO. In some respects it is better to make the effort up front to change mindset, but of course that needs to balanced against productivity today. cheers -ben P.S. Just to complete my other reply...
Personally I like the staging area as a final check to observe what I'm *really* committing,
Instead of "commit -a" which atomically does... git add -u ; git commit I like to separately use something like... git add -u ; git diff --staged ; git commit cheers -ben
On Fri, Jun 17, 2016 at 10:47 AM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Jun 17, 2016 at 6:46 AM, Damien Pollet <damien.pollet@gmail.com> wrote:
On 17 June 2016 at 00:08, Eliot Miranda <eliot.miranda@gmail.com> wrote:
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
The mindset with git is that your working copy is a sort of experimentation area where you can have a crazy scientist attitude. When you commit, however, you switch hats and become the thorough developer that cares about your future self, and therefore has done all changes in a perfect didactic sequence so that you can understand what the hell your future-past-self was doing.
If your crazy-scientist-self is already auto-censored into producing limpid incremental patches, then he can use git aliases for his preferred workflow (for instance I have git ci, git co, git st configured to mimic their svn counterparts; git staged shows a diff of what's to be committed next, etc)
While creating svn like aliases and using "commit -a" may initially aid transition to git from svn, consider that this is a bit like a C programmer migrating to C++ to earn OO, versus learning OO by using Smalltalk. The hybrid nature of the C++ impedes them changing their *mindset* to use OO the full power of OO. In some respects it is better to make the effort up front to change mindset, but of course that needs to balanced against productivity today.
cheers -ben
P.S. Just to complete my other reply...
Personally I like the staging area as a final check to observe what I'm *really* committing,
Instead of "commit -a" which atomically does... git add -u ; git commit I like to separately use something like... git add -u ; git diff --staged ; git commit
but actually there is a subtle difference if you are in a subdirectory when you issue the commands... http://stackoverflow.com/questions/3541647/git-add-vs-git-commit-a
On Fri, Jun 17, 2016 at 6:08 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Alistair,
On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote:
Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?)
What do you mean "nothing" ? If you do "git status" before and after you should see some difference. If you mean "why didn't ii push to the server", here [1] is a good diagram, and the next page also is good, plus this one on branching mindset change [2] and nice introduction to undoing things [3] (for your local repo only.)
"git commit" will commit anything that has been "git add"ed to the index. -a is a convenience to automatically stage files that have been modified.
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
Staging is a significant difference of git to svn, so a few opinions on the benefit of staging [4] [5] [6] [7] is useful. Personally I like the staging area as a final check to observe what I'm *really* committing, particularly when my working area has become a bit messy. Now as described in one of the links, "git commit -a" is a way ignore the staging area so git acts more like svn, but here are some insightful stories from people that were initially annoyed by the staging area but later found it useful [8] [9]. And btw, a quickstart git/svn cheat sheet [10]. cheers -ben [1] https://www.git-tower.com/learn/git/ebook/en/command-line/appendix/from-subv... [2] https://www.git-tower.com/learn/git/ebook/en/command-line/branching-merging/... [3] https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/un... [4] http://stackoverflow.com/questions/4878358/why-would-i-want-stage-before-com... [5] http://programmers.stackexchange.com/questions/69178/what-is-the-benefit-of-... [6] http://stackoverflow.com/questions/4878358/why-would-i-want-stage-before-com... [7] http://gitolite.com/uses-of-index.html [8] http://blog.osteele.com/posts/2008/05/my-git-workflow/ [9] http://2ndscale.com/rtomayko/2008/the-thing-about-git [10] https://www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/
Hi Eliot, how secure does this need to be? One way to differentiate the official VMs is to sign them directly on Travis (which we'll want to do anyway, just didn't get to it, yet). Another option is to just change the URL replacement code to do something else when not running on Travis --- like adding your hostname and path instead --- but this could be fairly easily messed with. Not sure how much malicious intent we want to prevent. cheers, Tim On 16 June 2016 at 22:07, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?) I have a VM that outputs a reasonable version info:
/Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT Compiler: 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] CoInterpreter VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun 16 12:53:33 2016 -0700 $ Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $
Which begs the question how do I differentiate this from something built officially via Travis? Arguably the URL is wrong, and should only say "http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps should just include my local hostname and current directory when I make any kind of local modification. So the above would read
... VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 12:53:33 2016 -0700 $ Plugins: r201606161953 McStalker:?users/eliot/oscogvm $
Alternatively we could add another field, or modify one of the existing fields to say "I'm official" however one would do that. I don't know how, I just know we need this. I shouldn't be able to pollute the VM pool by putting some VM on some site somewhere that i just happened to build after several sherries and some cannabis brownies that looks to all intents and purposes just like a VM built by our official Travis slaves. Hic. Chillin'
_,,,^..^,,,_ best, Eliot
participants (6)
-
Alistair Grant -
Ben Coman -
Damien Pollet -
Eliot Miranda -
Serge Stinckwich -
Tim Felgentreff