About Git support for windows
Locked
12
12
About Git support for windows
 
|
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits. He is waiting at Wien and is probably checking everything right now. It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :) Stef |
Re: About Git support for windows
|
|
Hi All,
> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> wrote: > > Hi all > > At ESUG we discussed with Esteban, martin mcClure, Dale and (many many > others :), esteban designed a nice class file format. So that we will > not have 2Gb of space on harddisc, problems with long method names and > sluggish commits. Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! Can someone post the grammar or a description of the syntax asap? > > He is waiting at Wien and is probably checking everything right now. > > It is a nice format because we will be able to use it to communicate > by emails using it. So readable, compact and I like it :) Lovely! Details please :-) > > Stef > |
Re: About Git support for windows
|
|
From memory one class of class/trait and one for extension
In class/Trait "class / trait comments comment" Special STON order for classes to minimic our logical order (ie package tag add the end). Class { } or Trait { name: #T } + Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2 ] + STON for meta data {category : "printing"} Since I do not know STON all the above can be wrong but this is the idea. Stef On Fri, Sep 8, 2017 at 10:02 PM, Eliot Miranda <[hidden email]> wrote: > Hi All, > >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> wrote: >> >> Hi all >> >> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >> others :), esteban designed a nice class file format. So that we will >> not have 2Gb of space on harddisc, problems with long method names and >> sluggish commits. > > Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! > > Can someone post the grammar or a description of the syntax asap? > >> >> He is waiting at Wien and is probably checking everything right now. >> >> It is a nice format because we will be able to use it to communicate >> by emails using it. So readable, compact and I like it :) > > Lovely! Details please :-) > >> >> Stef >> > |
Re: About Git support for windows
|
|
for example here and it also shows one downside --- up until now we didn't care much about how many methods are in class (because it was just another file), but now we have 10000 lines of code class. On Fri, Sep 8, 2017 at 10:25 PM, Stephane Ducasse <[hidden email]> wrote: From memory one class of class/trait and one for extension |
|
|
but this is still WIP: for example timestamp needs to go to avoid conflicts.
I do not think this is a huge problem since the format is not intended to be for direct edition, but yes, this is a downside... no format will be perfect. Esteban
|
|
|
In reply to this post by Eliot Miranda-2
> On 8 Sep 2017, at 22:02, Eliot Miranda <[hidden email]> wrote: > > Hi All, > >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> wrote: >> >> Hi all >> >> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >> others :), esteban designed a nice class file format. So that we will >> not have 2Gb of space on harddisc, problems with long method names and >> sluggish commits. > > Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! > > Can someone post the grammar or a description of the syntax asap? I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didn’t use RBParser) so it can be ported easily to other dialects. Esteban > >> >> He is waiting at Wien and is probably checking everything right now. >> >> It is a nice format because we will be able to use it to communicate >> by emails using it. So readable, compact and I like it :) > > Lovely! Details please :-) > >> >> Stef >> > |
Re: About Git support for windows
|
|
>> but this is still WIP: for example timestamp needs to go to avoid conflicts. why/how would this cause conflicts versus other changes?
Fra: Pharo-dev <[hidden email]> på vegne av Esteban Lorenzano <[hidden email]>
Sendt: 9. september 2017 11:39:12 Til: Pharo Development List Emne: Re: [Pharo-dev] About Git support for windows > On 8 Sep 2017, at 22:02, Eliot Miranda <[hidden email]> wrote: > > Hi All, > >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> wrote: >> >> Hi all >> >> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >> others :), esteban designed a nice class file format. So that we will >> not have 2Gb of space on harddisc, problems with long method names and >> sluggish commits. > > Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! > > Can someone post the grammar or a description of the syntax asap? I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didn’t use RBParser) so it can be ported easily to other dialects. Esteban > >> >> He is waiting at Wien and is probably checking everything right now. >> >> It is a nice format because we will be able to use it to communicate >> by emails using it. So readable, compact and I like it :) > > Lovely! Details please :-) > >> >> Stef >> > |
|
|
two people modifying same method could have a marge without conflict, but if both modify same line (like the timestamp line), then for sure it will be a conflict :)
|
Re: About Git support for windows
|
|
In reply to this post by EstebanLM
Hi Esteban,
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2 ] specify it must be Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2] because trailing white space will only accumulate, something I see in Pharo and Squeak code. Alternatively have the output add white space if required and the input remove any and all trailing white space.
The main issue with a file containing many methods is method order stability. So sort by alphabetical order of method selector, not by protocol.
|
Re: About Git support for windows
|
|
In reply to this post by EstebanLM
Hi Esteban,
|
Re: About Git support for windows
|
|
In reply to this post by Eliot Miranda-2
I do remember that I hated long classes because of git conflicts, but I suppose if we have good tooling for that it shouldn't be such a pain. Git can sometimes make the diff really weirdly... Peter |
|
|
In reply to this post by EstebanLM
Hi!
I live very very much this idea! I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <[hidden email]> wrote: > > >> On 8 Sep 2017, at 22:02, Eliot Miranda <[hidden email]> wrote: >> >> Hi All, >> >>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> wrote: >>> >>> Hi all >>> >>> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>> others :), esteban designed a nice class file format. So that we will >>> not have 2Gb of space on harddisc, problems with long method names and >>> sluggish commits. >> >> Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >> >> Can someone post the grammar or a description of the syntax asap? > > I will commit it with a spec next week. > and I made the parser by hand and simple enough (e.g. I didn’t use RBParser) so it can be ported easily to other dialects. > > Esteban > >> >>> >>> He is waiting at Wien and is probably checking everything right now. >>> >>> It is a nice format because we will be able to use it to communicate >>> by emails using it. So readable, compact and I like it :) >> >> Lovely! Details please :-) >> >>> >>> Stef >>> >> > > |
Re: About Git support for windows
|
|
Hi!
> Am 10.09.2017 um 05:44 schrieb Alexandre Bergel <[hidden email]>: > > Hi! > > I live very very much this idea! > > I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information? > the difference is commit time vs. compile time. From a collaboration point of view it is the important time. From a personal view it might do a service to have the date you compiled. But putting the timestamp where git will resolve a conflict is a no-go. Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. Norbert > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <[hidden email]> wrote: >> >> >>> On 8 Sep 2017, at 22:02, Eliot Miranda <[hidden email]> wrote: >>> >>> Hi All, >>> >>>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> wrote: >>>> >>>> Hi all >>>> >>>> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>>> others :), esteban designed a nice class file format. So that we will >>>> not have 2Gb of space on harddisc, problems with long method names and >>>> sluggish commits. >>> >>> Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >>> >>> Can someone post the grammar or a description of the syntax asap? >> >> I will commit it with a spec next week. >> and I made the parser by hand and simple enough (e.g. I didn’t use RBParser) so it can be ported easily to other dialects. >> >> Esteban >> >>> >>>> >>>> He is waiting at Wien and is probably checking everything right now. >>>> >>>> It is a nice format because we will be able to use it to communicate >>>> by emails using it. So readable, compact and I like it :) >>> >>> Lovely! Details please :-) >>> >>>> >>>> Stef >>>> >>> >> >> |
|
|
> On 10 Sep 2017, at 09:50, Norbert Hartl <[hidden email]> wrote: > > Hi! > >> Am 10.09.2017 um 05:44 schrieb Alexandre Bergel <[hidden email]>: >> >> Hi! >> >> I live very very much this idea! >> >> I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information? >> > the difference is commit time vs. compile time. From a collaboration point of view it is the important time. From a personal view it might do a service to have the date you compiled. But putting the timestamp where git will resolve a conflict is a no-go. Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. that’s the real problem. That’s why we need to find ways to have the correct timestamp using git tooling (like using git blame or something like that) > > Norbert >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <[hidden email]> wrote: >>> >>> >>>> On 8 Sep 2017, at 22:02, Eliot Miranda <[hidden email]> wrote: >>>> >>>> Hi All, >>>> >>>>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> wrote: >>>>> >>>>> Hi all >>>>> >>>>> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>>>> others :), esteban designed a nice class file format. So that we will >>>>> not have 2Gb of space on harddisc, problems with long method names and >>>>> sluggish commits. >>>> >>>> Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >>>> >>>> Can someone post the grammar or a description of the syntax asap? >>> >>> I will commit it with a spec next week. >>> and I made the parser by hand and simple enough (e.g. I didn’t use RBParser) so it can be ported easily to other dialects. >>> >>> Esteban >>> >>>> >>>>> >>>>> He is waiting at Wien and is probably checking everything right now. >>>>> >>>>> It is a nice format because we will be able to use it to communicate >>>>> by emails using it. So readable, compact and I like it :) >>>> >>>> Lovely! Details please :-) >>>> >>>>> >>>>> Stef >>>>> >>>> >>> >>> > |
|
|
In reply to this post by Eliot Miranda-2
Hi!
thing is: we need to obtain that information in a different way than just put it there as text, because of conflicts. But I do not want to lose that information either… just get it in a different way. Esteban
|
|
|
In reply to this post by Eliot Miranda-2
in fact, I’m working to remove the extra trailings this format can add. The idea is that parsed text == original text. Then, originally my format was methodDeclaration [ methodBody ] but now I’m digging also into methodDeclaration [ methodBody ] (always keeping the identity of sources idea) cheers! Esteban |
Re: About Git support for windows
|
|
In reply to this post by NorbertHartl
>>Everyone who used filetree with metadata can tell it is super annoying and
destroys the complete experience. There has been a fix for this on the issue tracker for some time: https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html |
|
|
that’s not related. Timestamp conflicts are related two different users touching exactly same part of source: conflict guaranteed, no matter the order. btw, Tonel export order is deterministic and it will always output same data in same way. Esteban |
Re: About Git support for windows
|
|
In reply to this post by Henrik-Nergaard
Hi Henrik,
Le 10/09/2017 à 10:56, Henrik-Nergaard a écrit : >>> Everyone who used filetree with metadata can tell it is super annoying and > destroys the complete experience. > There has been a fix for this on the issue tracker for some time: > https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order Could you add an issue on FileTree (github.com://dalehenrich/filetree)? It is of interest to all users of FileTree, and other things than git. Regards, Thierry > Best regards, > Henrik > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > |
Re: About Git support for windows
|
|
In reply to this post by Eliot Miranda-2
On 09-09-17 19:43, Eliot Miranda wrote:
> I think this is a serious mistake. Time stamps and author marks are > important (even more important if the unit of commit is a single file > for the whole class). When converting repos from monticello to git we could add extra commits for groups of time stamp and author ranges. I'd expect them to be most common for the first monticello commits. I would expect git based commits to be one-author only. When converting, we could also fix back-edited to reverts. Stephan |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |