100% Agreed.
> On 8 Jan 2016, at 18:25, Dimitris Chloupis <kilon.al...@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.n...@gmail.com
> <mailto:nicolas.cellier.aka.n...@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/5986a695fb28834247a90dbf85c0d1e02a54b6fc/FFI-NB.package/FFIExternalStructure.class/class/private/compileFields_withAccessors_.st#L9
>
> <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
>
> <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.
