Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

> Hi Alistair,
>
> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <[hidden email]>
> 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?

> Hi Alistair,
>
> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <[hidden email]>
> 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?

>
> On 17 June 2016 at 00:08, Eliot Miranda <[hidden email]> 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)

> On Fri, Jun 17, 2016 at 6:46 AM, Damien Pollet <[hidden email]> wrote:
>>
>> On 17 June 2016 at 00:08, Eliot Miranda <[hidden email]> 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

> On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <[hidden email]> wrote:
>
>> On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <[hidden email]> wrote:
>> Hi Alistair,
>>
>> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <[hidden email]>
>> 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).

>
>
> > On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <[hidden email]> wrote:
> >
> >> On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <[hidden email]> wrote:
> >> Hi Alistair,
> >>
> >> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <[hidden email]>
> >> 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 ;-)

> 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 Jun 16, 2016, at 3:32 PM, Serge Stinckwich <[hidden email]> wrote:
>>
>>> On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <[hidden email]> wrote:
>>> Hi Alistair,
>>>
>>> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <[hidden email]>
>>> 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.