Atomic commits

On Jan 6, 2016, at 3:13 PM, Nicolas Cellier <[hidden email]> 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/5986a695fb28834247a90dbf85c0d1e02a54b6fc/FFI-NB.package/FFIExternalStructure.class/class/private/compileFields_withAccessors_.st#L9

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/dfd4f3ae0f0b0af7766c1405a3affa3f890ce51a

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.

On 8 Jan 2016, at 18:25, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> 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/5986a695fb28834247a90dbf85c0d1e02a54b6fc/FFI-NB.package/FFIExternalStructure.class/class/private/compileFields_withAccessors_.st#L9

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/dfd4f3ae0f0b0af7766c1405a3affa3f890ce51a

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.