Hi, I wish the commits were much more atomic than they currently are... With current practice, reviewing the changes is near to impossible: - it requires far too much concentration - it's just impossible through github web interface For example, I did wander if the structure fields were correclty aligned in: https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf85... because I see no code for aligning the offsets... But I cannot even navigate in the history... If I do so, https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405a... the page tells me "Sorry, we could not display the entire diff because too many files (2,121) changed" and I couldn't find a way of displaying the portion of interest. I thus loose the ability to deposit a comment. I can still open a fresh Pharo image and browse and review the whole code snapshot there. Or I can navigate more easily in history with git tools. But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't. While ranting, it's nice to have the commits performed by a jenkins server, but how do we track the authors of original modifications? In a normal git based development, there would be feature branches integrated/merged in trunk/master by whatever process. But in current process i fail to capture such information... This gives a taste of under-powered use of the tools, and I wander if being visible in these conditions is a good thing: we don't expose the best practices.
Hi, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> writes:
I wish the commits were much more atomic than they currently are...
I agree. This is important (and one of my research topics https://hal.inria.fr/hal-01116225 :-)). Martin Dias worked on EpiceaUntangler to help developers do atomic commits http://smalltalkhub.com/#!/~MartinDias/EpiceaTaskClusterer. To put that in production, we need the Random Forest algorithm implemented in Pharo.
I can still open a fresh Pharo image and browse and review the whole code snapshot there. Or I can navigate more easily in history with git tools. But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't.
Skip is working on a code review tool. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
I agree (see my mails about sending diffs to the mailing-lists.) People do not listen to me so ... Le 6/1/16 19:13, Nicolas Cellier a écrit :
Hi, I wish the commits were much more atomic than they currently are... With current practice, reviewing the changes is near to impossible: - it requires far too much concentration - it's just impossible through github web interface
For example, I did wander if the structure fields were correclty aligned in: https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf85... because I see no code for aligning the offsets...
But I cannot even navigate in the history... If I do so, https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405a...
the page tells me "Sorry, we could not display the entire diff because too many files (2,121) changed" and I couldn't find a way of displaying the portion of interest.
I thus loose the ability to deposit a comment.
I can still open a fresh Pharo image and browse and review the whole code snapshot there. Or I can navigate more easily in history with git tools. But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't.
While ranting, it's nice to have the commits performed by a jenkins server, but how do we track the authors of original modifications? In a normal git based development, there would be feature branches integrated/merged in trunk/master by whatever process. But in current process i fail to capture such information...
This gives a taste of under-powered use of the tools, and I wander if being visible in these conditions is a good thing: we don't expose the best practices.
Would the situation be different if we had one per per class in the git repo? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jan 6, 2016, at 3:13 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Hi, I wish the commits were much more atomic than they currently are... With current practice, reviewing the changes is near to impossible: - it requires far too much concentration - it's just impossible through github web interface
For example, I did wander if the structure fields were correclty aligned in: https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf85... <https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf85...> because I see no code for aligning the offsets...
But I cannot even navigate in the history... If I do so, https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405a... <https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405a...> the page tells me "Sorry, we could not display the entire diff because too many files (2,121) changed" and I couldn't find a way of displaying the portion of interest.
I thus loose the ability to deposit a comment.
I can still open a fresh Pharo image and browse and review the whole code snapshot there. Or I can navigate more easily in history with git tools. But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't.
While ranting, it's nice to have the commits performed by a jenkins server, but how do we track the authors of original modifications? In a normal git based development, there would be feature branches integrated/merged in trunk/master by whatever process. But in current process i fail to capture such information...
This gives a taste of under-powered use of the tools, and I wander if being visible in these conditions is a good thing: we don't expose the best practices.
When one uses a tool in a way that is not suppose to use , the one must expect all sort of new and fascinating problems. Some think that putting changes in 2121 files in a single commit is a good idea, github politely disagrees. In this case if you want go down the visual route I highly recommend a Git GUI client, I know people are obsessed of doing everything inside pharo, something I may never understand but as I stated in my video tutorial about Git , nothing pharo will create at least the next year will come remotely close to the elegant workflow of some of the best GIT GUIs like SmartGit, SourceTree and lately I am deeply in love with GitUp which unfortunately is only for MacOS because I think is awesome git gui client that makes git super easy. Most coders that use git rely on a git client of some sort, if you dont like guis and prefer emacs, there is also magit that i hear is very good. No disrespect on people working on git integration in pharo, I am 100% behind them, but frankly I rather use pharo with other tools than pharo alone and try to convince myself that my old methods are going to work with new external tools. On Wed, Jan 6, 2016 at 8:14 PM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi, I wish the commits were much more atomic than they currently are... With current practice, reviewing the changes is near to impossible: - it requires far too much concentration - it's just impossible through github web interface
For example, I did wander if the structure fields were correclty aligned in:
https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf85... because I see no code for aligning the offsets...
But I cannot even navigate in the history... If I do so,
https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405a... the page tells me "Sorry, we could not display the entire diff because too many files (2,121) changed" and I couldn't find a way of displaying the portion of interest.
I thus loose the ability to deposit a comment.
I can still open a fresh Pharo image and browse and review the whole code snapshot there. Or I can navigate more easily in history with git tools. But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't.
While ranting, it's nice to have the commits performed by a jenkins server, but how do we track the authors of original modifications? In a normal git based development, there would be feature branches integrated/merged in trunk/master by whatever process. But in current process i fail to capture such information...
This gives a taste of under-powered use of the tools, and I wander if being visible in these conditions is a good thing: we don't expose the best practices.
100% Agreed.
On 8 Jan 2016, at 18:25, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
When one uses a tool in a way that is not suppose to use , the one must expect all sort of new and fascinating problems.
Some think that putting changes in 2121 files in a single commit is a good idea, github politely disagrees.
In this case if you want go down the visual route I highly recommend a Git GUI client, I know people are obsessed of doing everything inside pharo, something I may never understand but as I stated in my video tutorial about Git , nothing pharo will create at least the next year will come remotely close to the elegant workflow of some of the best GIT GUIs like SmartGit, SourceTree and lately I am deeply in love with GitUp which unfortunately is only for MacOS because I think is awesome git gui client that makes git super easy.
Most coders that use git rely on a git client of some sort, if you dont like guis and prefer emacs, there is also magit that i hear is very good.
No disrespect on people working on git integration in pharo, I am 100% behind them, but frankly I rather use pharo with other tools than pharo alone and try to convince myself that my old methods are going to work with new external tools.
On Wed, Jan 6, 2016 at 8:14 PM Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: Hi, I wish the commits were much more atomic than they currently are... With current practice, reviewing the changes is near to impossible: - it requires far too much concentration - it's just impossible through github web interface
For example, I did wander if the structure fields were correclty aligned in: https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf85... <https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf85...> because I see no code for aligning the offsets...
But I cannot even navigate in the history... If I do so, https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405a... <https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405a...> the page tells me "Sorry, we could not display the entire diff because too many files (2,121) changed" and I couldn't find a way of displaying the portion of interest.
I thus loose the ability to deposit a comment.
I can still open a fresh Pharo image and browse and review the whole code snapshot there. Or I can navigate more easily in history with git tools. But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't.
While ranting, it's nice to have the commits performed by a jenkins server, but how do we track the authors of original modifications? In a normal git based development, there would be feature branches integrated/merged in trunk/master by whatever process. But in current process i fail to capture such information...
This gives a taste of under-powered use of the tools, and I wander if being visible in these conditions is a good thing: we don't expose the best practices.
Dimitris Chloupis <kilon.alios@gmail.com> writes:
Most coders that use git rely on a git client of some sort, if you dont like guis and prefer emacs, there is also magit that i hear is very good.
totally agree, Magit is awesome. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
participants (6)
-
Alexandre Bergel -
Damien Cassou -
David Allouche -
Dimitris Chloupis -
Nicolas Cellier -
stepharo