Re: [egit-dev] Performance of Synchronize - unusable for CDT

[James Blackburn <jamesblackburn@xxxxxxxxx>]

On 15 January 2011 19:13, Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote:
> I frankly don't understand the Synchronize view in a Git context since
> it doesn't deal with commit (change sets). To me "synchronize" in Git
> would be something like an interactive rebase/cherry-pick in a pretty
> GUI:y dress.
>
> We once (version 0.3.1) had a structured compare in the history view
> that we should resurrect, or rather re-implement. It was very fast,
> typically much less than one second to compare two revisions and a new
> implementation should be faster.

Well that sounds neat.  The synchronize view does show commits (which
I've never used).

As a CVS/SVN refugee synchronize has two main uses:
1) Staging changes: when I'm preparing a patch for commit, I
synchronize so I can see all the changes in context, and tweak
whitespace, copyrights, etc. The synchronize view automagically
reflects any new changes in the workspace, which is very useful.
(Apart from performance, this seems to work with egit today...).  Note
that the commit dialog can't be used for this, as it's read-only and
(annoyingly) modal.

2) Comparing two heads. I want to see what the overall change of
pulling from another branch will be before doing so.  Also useful for
comparing the heads before generating a patch.

I believe a straightforward structured compare would be very useful --
I've filed a few bugs on lack of folder / project level compare.
However it doesn't seem satisfy the first case?  Staging changes in a
way which allows you to keep editing until the dev is happy with the
patch.

I've not yet found the commit list in the synchronize view useful. All
I'm after is a visual diff between the two heads, that can be
generated quickly, and stays in sync with the ws if the ws is one of
the heads.

Cheers,
James