Git menu

[Johannes Schmid-4]

Hi!

I don't like the last git menu reorganization at all. It's hardly
possible to find any command you need. Especially you need to go into 2
submenus just to do a git fetch && git rebase origin which is (at least
for me) the most needed command.

I would like to have at least "fetch", "commit", "push" and "rebase" in
the top-level menu.

Regards,
Johannes


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Massimo Cora']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Johannes Schmid wrote:

> Hi!
>
> I don't like the last git menu reorganization at all. It's hardly
> possible to find any command you need. Especially you need to go into 2
> submenus just to do a git fetch && git rebase origin which is (at least
> for me) the most needed command.
>
> I would like to have at least "fetch", "commit", "push" and "rebase" in
> the top-level menu.
>

yes, I must admit that I agree with you.
I often use also the 'pull' command.

regards,
Massimo


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqtTlgACgkQcfVTgMRILk2RHwCeMLWLM8LOiqdpqTkKFbVioRPJ
qC0An3H3rEuDEa9XNRg2W9dAdzH8Px9b
=JrZd
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi,

Johannes Schmid a écrit :
> I don't like the last git menu reorganization at all. It's hardly
> possible to find any command you need. Especially you need to go into 2
> submenus just to do a git fetch && git rebase origin which is (at least
> for me) the most needed command.
> I would like to have at least "fetch", "commit", "push" and "rebase" in
> the top-level menu.

I'm agree but I think a bit more changes will be useful.

On my side, I'm often using View diff too.

I'm not using anjuta for push and pull because I'm afraid to break
something. pull is probably safe, but for push I need to check
something. Some documentation will be useful here.

I don't use the GUI neither to restore an older version of a file or
remove all my local changes. I'm reading git documentation and it is a
bit complex depending on the situation (if the changes are already
committed or not).

I think it would be better if adding and removing a file from the
context menu of the project or file manager window does not need an
dialog. Perhaps you can try to add/remove the file with default option
and display a dialog only if it fails. Then adding a directory add all
files in it which is not always what we want to do.

File status are not refreshed when you add a file by example too.


Then, I like the commit dialog especially, the modify previous commit
option (getting back the previous log message) and the use custom author
informations. I'm use it every time and I don't know how to do this in
the command line.

Regards,

Sébastien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Sat, 2009-09-12 at 16:42 +0200, Johannes Schmid wrote:
> Hi!
>
> I don't like the last git menu reorganization at all. It's hardly
> possible to find any command you need. Especially you need to go into 2
> submenus just to do a git fetch && git rebase origin which is (at least
> for me) the most needed command.
Do a Pull in rebase mode (the default for pull now.) This will do both
git fetch and rebase for you in one shot.
>
> I would like to have at least "fetch", "commit", "push" and "rebase" in
> the top-level menu.
Well I thought about doing something like this, but the problem is that
there is no one "right" way to do a lot of things in git. Different
projects, even different people working on the same project, will use
different commands depending on their exact situation. While an
arrangement like this might be OK for you, it might get in somebody
else's way. It would get in my way, because I don't ever use fetch,
except when I'm messing around with a copy of my repository for
backporting as a means of getting around the project manager hang bug.

Also, keep in mind that I'm trying as much as possible to be HIG
compliant here. The HIG says we can't have more than 15 items in one
single menu. Right now there are nine submenus. If I were to move the
five you suggest to the top level, that gives us 14. That's not a whole
lot of room to grow. As it is, I'm going to be adding more features to
the git plugin, and that will likely mean more menu items. So even if I
were to do what you suggest to appease you now, you'd probably be
complaining again about the menu in a few months. :-)

I think this is probably at least the second or third time this subject
has come up since April. If we continue like this, I'm afraid it won't
be the last either. So over the last couple of days I started thinking
of ways we could nip these problems in the bud, which is why I took so
long to reply. ;)

It might end up being a bit of work, but I would like to suggest that we
implement a way to allow users to customize the layout of their menus.
That way, individual users could decide on a case by case basis which
features are most important to them. I'm still working on formulating
the exact details of an implementation, but I at least want to throw the
idea out there...

Thoughts?

Thanks,
James


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!

> It might end up being a bit of work, but I would like to suggest that we
> implement a way to allow users to customize the layout of their menus.
> That way, individual users could decide on a case by case basis which
> features are most important to them. I'm still working on formulating
> the exact details of an implementation, but I at least want to throw the
> idea out there...

That could be an idea but I don't like it two much.

I don't think the point is to fit with the HIG literally because that
won't bring us further. A menu that only consists of submenus looks
rather ridiculous anyway.

My idea would rather be to rework the UI work git in general. Maybe some
of commands are better moved out of the menu and made accessible in some
other way (for example from the log window).

I could also think of some dock that might contain all the branches and
allow to work with them in a graphical way (push, pull, merge, rebase,
cherry-pcik etc.). These are just ideas but I think the UI (not only of
the git plugin) has two many menu items and menu items are just so
90s ;)

Regards,
Johannes  


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Wed, 2009-09-16 at 00:11 +0200, Johannes Schmid wrote:

> Hi!
>
> > It might end up being a bit of work, but I would like to suggest that we
> > implement a way to allow users to customize the layout of their menus.
> > That way, individual users could decide on a case by case basis which
> > features are most important to them. I'm still working on formulating
> > the exact details of an implementation, but I at least want to throw the
> > idea out there...
>
> That could be an idea but I don't like it two much.
>
> I don't think the point is to fit with the HIG literally because that
> won't bring us further. A menu that only consists of submenus looks
> rather ridiculous anyway.

Be that as it may, my argument about workflows still stands though...

>
> My idea would rather be to rework the UI work git in general. Maybe some
> of commands are better moved out of the menu and made accessible in some
> other way (for example from the log window).
>
> I could also think of some dock that might contain all the branches and
> allow to work with them in a graphical way (push, pull, merge, rebase,
> cherry-pcik etc.). These are just ideas but I think the UI (not only of
> the git plugin) has two many menu items and menu items are just so
> 90s ;)

Not too long ago I was thinking of something very much like this,
implemented on Clutter. But I don't know very much about Clutter, and
what stuff I did find seems to suggest that we'd be rewriting most of
our widgets from scratch, as Clutter isn't much of a widget toolkit.
There is, however, a way to integrate Clutter and GTK with some code
that's in GTK master. Maybe we could do something like that, but it'd be
a long way off.

But even if I could pull it off techinically, I still don't know if it's
such a great idea. If we don't do it right we could end up making it
harder to use, and more confusing for advanced git users. The very
flexible nature of git is the source of all of our problems. There are
too many commands with way too many options. How do we fit all of it in?
If we can't fit it all or shouldn't, how should we decide what goes into
the plugin and what doesn't? When I first designed it, I thought what I
had would be fine for most people, then I was given commit access and
started using different things than before, and I had to change some of
my previous assumptions about what would be used and what wouldn't.

Basically my point is this: you can't define a git GUI simply based on
just your use cases; you have to consider how other people might use it
too. If you look at all of the other git GUI's, you'll find one thing in
common: their UI's suck in some way, i.e. they either leave out needed
features or when they do have those features, the UI isn't very
intuitive. In many ways we suffer from the same issues, and it's not
going to be easy to fix.

Thanks,
James


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!

> Basically my point is this: you can't define a git GUI simply based on
> just your use cases; you have to consider how other people might use it
> too. If you look at all of the other git GUI's, you'll find one thing in
> common: their UI's suck in some way, i.e. they either leave out needed
> features or when they do have those features, the UI isn't very
> intuitive. In many ways we suffer from the same issues, and it's not
> going to be easy to fix.

I think this is a valid point and we really have to decide which
features need to be accessed from the UI. git has some very exotic
features and people who know how to use them will most likely use them
from the command line anyway. But I think there is a subset of the
features where an UI makes the work-flow much simpler because you don't
have to care about commit IDs or finding the correct files.

Anyway, some ideas to make the menu less flooded:

- Put Add/Remove/checkout/revert/resolve conflict only in the
file-manager popup-menu. The three latter could still show a dialog
where the user can select more files

- Merge everything from the "Changes" submenu with the log viewer
widget. Same for the "tags" submenu

- As suggested in the last mail, think of some "Branches" widget to
manage branches and move the

I don't know some of the other features very well and maybe there could
be even more reorganized but not sure. Maybe it's enough to have
"Bisect" in the log viewer.

TODO: Write a help file for the git plugin...

Regards,
Johannes


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi James,

James Liggett a écrit :
> Well I thought about doing something like this, but the problem is that
> there is no one "right" way to do a lot of things in git. Different
> projects, even different people working on the same project, will use
> different commands depending on their exact situation. While an
> arrangement like this might be OK for you, it might get in somebody
> else's way.

Sure, but I think we could all try to look at this and try to find a
better arrangement for all of us. Now, everybody is using git so we have
more experience.

> Also, keep in mind that I'm trying as much as possible to be HIG
> compliant here. The HIG says we can't have more than 15 items in one
> single menu. Right now there are nine submenus. If I were to move the
> five you suggest to the top level, that gives us 14. That's not a whole
> lot of room to grow. As it is, I'm going to be adding more features to
> the git plugin, and that will likely mean more menu items.

This 15 limits looks a bit small and I don't thinks submenus are really
better.

Then you don't need to have one menu item for each git command. By
example you could allow to run command only from another dialog. I think
diff could be run from the commit dialog only without using menu item.

> I think this is probably at least the second or third time this subject
> has come up since April. If we continue like this, I'm afraid it won't
> be the last either.

Yes, I remember. It means that this plugin is often used.

> It might end up being a bit of work, but I would like to suggest that we
> implement a way to allow users to customize the layout of their menus.
> That way, individual users could decide on a case by case basis which
> features are most important to them. I'm still working on formulating
> the exact details of an implementation, but I at least want to throw the
> idea out there...

I'm not really in favor of this idea. Perhaps it's only me but I doing
almost no customization of my own environment. It's too annoying to
redefine everything when you install a new version. Then, when you are
using someone else computer you don't have all these customizations
anyway. Finally, I think the developers of an application can spend more
time than me trying to find the best arrangement.

Regards,

Sébastien

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi James,

I have used git cherry-pick recently and I have tried to imagine how it
could be improved in Anjuta.

Here are several proposals that I would like to have in this dialog.

* Cherry pick is a kind of commit operation so it should look a bit like
the commit dialog. I would like to have a log message entry, with the
column number.

* It would be nice to put somewhere the name of the current branch, so
we can check it. Perhaps in the windows title: "cherry pick in master"
by example, or add a line with the branch name. A more advanced
possibility would be to add a combo box where you can select another
branch (not the current one). Anyway I'm really not sure it's really
better as it will make branch change perhaps too easy and can lead to
errors.

* Then, probably the main point, I would like to avoid entering the
commit name in this dialog. It forces me to know how git is naming the
commits. If I know this information, I can easily use the command line.
So instead of a simple entry, I would like to have a list view listing
all commits where I can choose one of them.

As I can select commit in different branches, perhaps a tree view with a
list of branch having all the commit as children. Or a combo box with
the branch name and a list view with the commit. In fact, I expect
something like your current Git Log dialog, and the filter part could be
useful. Obviously when you select a commit, it should update the message
entry described above.

* I would like to have a view of the difference too to be sure that I
really commit exactly what I want. I have already asked you this for the
commit dialog. It can be included in the tree view, with each commit
having as child all changed files containing all diff. Or it could be
another widget containing a colored diff, obviously updated each time
you select a new commit. By example, gitk display this for each commit.

* For the options, I think you can keep more or less the one you already
have. The -e option should be used if the commit message is modified.

* For the -n option, I think it could be better to have 3 buttons at the
end:
- Cancel: Do nothing
- Apply: git cherry-pick -n,
- Commit: git cherry-pick
I'm not sure about this, as I think it's not obvious that Commit is
doing Apply then Commit.


This is really the kind of changes that I would like to have in the Git
plugin. I have some different ideas about menu items but it's really not
very important. The main idea, is that I don't want to have one menu
item for each git command else I'm using the command line. I want to
have one menu item for each operation which probably involve several git
commands.

Regards,

Sébastien

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!

Just a note: I find it much easier to start a cherry-pick from the
Log-Viewer (popup-menu => cherry-pick). I rather think that it would be
enough to have it that way and avoid the menu entry entirely. The other
points that Sébastien has are probably still true though.

Regards,
Johannes

Am Samstag, den 10.10.2009, 09:30 +0200 schrieb Sébastien Granjoux:

> Hi James,
>
> I have used git cherry-pick recently and I have tried to imagine how it
> could be improved in Anjuta.
>
> Here are several proposals that I would like to have in this dialog.
>
> * Cherry pick is a kind of commit operation so it should look a bit like
> the commit dialog. I would like to have a log message entry, with the
> column number.
>
> * It would be nice to put somewhere the name of the current branch, so
> we can check it. Perhaps in the windows title: "cherry pick in master"
> by example, or add a line with the branch name. A more advanced
> possibility would be to add a combo box where you can select another
> branch (not the current one). Anyway I'm really not sure it's really
> better as it will make branch change perhaps too easy and can lead to
> errors.
>
> * Then, probably the main point, I would like to avoid entering the
> commit name in this dialog. It forces me to know how git is naming the
> commits. If I know this information, I can easily use the command line.
> So instead of a simple entry, I would like to have a list view listing
> all commits where I can choose one of them.
>
> As I can select commit in different branches, perhaps a tree view with a
> list of branch having all the commit as children. Or a combo box with
> the branch name and a list view with the commit. In fact, I expect
> something like your current Git Log dialog, and the filter part could be
> useful. Obviously when you select a commit, it should update the message
> entry described above.
>
> * I would like to have a view of the difference too to be sure that I
> really commit exactly what I want. I have already asked you this for the
> commit dialog. It can be included in the tree view, with each commit
> having as child all changed files containing all diff. Or it could be
> another widget containing a colored diff, obviously updated each time
> you select a new commit. By example, gitk display this for each commit.
>
> * For the options, I think you can keep more or less the one you already
> have. The -e option should be used if the commit message is modified.
>
> * For the -n option, I think it could be better to have 3 buttons at the
> end:
> - Cancel: Do nothing
> - Apply: git cherry-pick -n,
> - Commit: git cherry-pick
> I'm not sure about this, as I think it's not obvious that Commit is
> doing Apply then Commit.
>
>
> This is really the kind of changes that I would like to have in the Git
> plugin. I have some different ideas about menu items but it's really not
> very important. The main idea, is that I don't want to have one menu
> item for each git command else I'm using the command line. I want to
> have one menu item for each operation which probably involve several git
> commands.
>
> Regards,
>
> Sébastien
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Anjuta-devel mailing list
> Anjuta-devel@...
> https://lists.sourceforge.net/lists/listinfo/anjuta-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi,

Johannes Schmid a écrit :
> Just a note: I find it much easier to start a cherry-pick from the
> Log-Viewer (popup-menu => cherry-pick). I rather think that it would be
> enough to have it that way and avoid the menu entry entirely.

I wasn't aware of the cherry-pick menu item in the log viewer, indeed
it's much easier like this.

Then, I have a some remarks about Log Viewer dialog too but they are
less important.

* I don't like the View Log button. As a developer, I know why it is
here but as an user, I expect that when I'm selecting another file or
another branch, the log is automatically updated. As it can be a bit
long, it has to be done in background which is more annoying to code.

* Perhaps we could make this window more central in the Git GUI as
several commands need a commit reference and it's much better to select
it from here. Just changing its name as Git Window or Git View, could be
enough. I haven't looked here because I was thinking this window doesn't
allow any changes. Then, I think the cherry-pick item is not necessary
in the main menu.

* I would prefer to have the colored difference inside the git window
than in Anjuta editor. It will allow to remove the view difference
button and always display the difference. I always prefer to see exactly
what will be commited.

* The current branch is already displayed with a green mark. I think it
could still be useful to have a line with its name. When you do
operation between branch, like cherry pick, it's more clear.

* If there isn't too much operations, it can be an option to have a
button at the end for all of them. But, I'm afraid it will not be
possible, in this case, I think the current menu items are fine.

* When the cherry pick is triggered from this window, most of my
comments in the previous mail don't apply in the same way. Having a
entry for the log message could be useful though because making it
editable in the main Git window can be a bit unexpected.

* For the cherry pick option. It would be better if we can remove all of
them so we can save one click but I don't know if it's possible. For -n,
another menu item looks fine, we just need to find a nice name. For the
other options, they can be defined in global preferences but I don't use
them and I don't know if it really makes sense.

Regards,

Sébastien

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Sat, 2009-10-10 at 12:59 +0200, Johannes Schmid wrote:
> Hi!
>
> Just a note: I find it much easier to start a cherry-pick from the
> Log-Viewer (popup-menu => cherry-pick). I rather think that it would be
> enough to have it that way and avoid the menu entry entirely. The other
> points that Sébastien has are probably still true though.
While for most purposes, selecting the cherry pick option from within
the log viewer, I very much have both methods there on purpose. The
command from the Git menu is there for cases where you already have a
commit hash, usually from an e-mail or bug report, from which you can
copy and paste it.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Sat, 2009-10-10 at 15:27 +0200, Sébastien Granjoux wrote:

> Hi,
>
> Johannes Schmid a écrit :
> > Just a note: I find it much easier to start a cherry-pick from the
> > Log-Viewer (popup-menu => cherry-pick). I rather think that it would be
> > enough to have it that way and avoid the menu entry entirely.
>
> I wasn't aware of the cherry-pick menu item in the log viewer, indeed
> it's much easier like this.
>
> Then, I have a some remarks about Log Viewer dialog too but they are
> less important.
>
> * I don't like the View Log button. As a developer, I know why it is
> here but as an user, I expect that when I'm selecting another file or
> another branch, the log is automatically updated. As it can be a bit
> long, it has to be done in background which is more annoying to code.

If you already have a log listed, it will update itself when you switch
branches. I don't always do this automatically for a couple of reasons:

1. Viewing the log of very large projects is a very slow process and
consumes a lot of memory.

2. It's very difficult to tell when something has changed; I'd have to
monitor a lot of files in a lot of different places, which is likely a
waste of CPU cycles.
>
> * Perhaps we could make this window more central in the Git GUI as
> several commands need a commit reference and it's much better to select
> it from here. Just changing its name as Git Window or Git View, could be
> enough. I haven't looked here because I was thinking this window doesn't
> allow any changes. Then, I think the cherry-pick item is not necessary
> in the main menu.
This is exactly what my proposed UI changes will do for us. Imagine the
log viewer taking up the whole Anjuta window, with all the relevant
commands at your fingertips, almost like GNOME shell but for git. So,
I'm just starting to call this project the "Git Shell." Under this plan,
the main menu is replaced by a list of buttons on the left side of the
pane.
>
> * I would prefer to have the colored difference inside the git window
> than in Anjuta editor. It will allow to remove the view difference
> button and always display the difference. I always prefer to see exactly
> what will be commited.
Why can't we have both? Sometimes I need to save diffs to files, and
maybe even edit them.
>
> * The current branch is already displayed with a green mark. I think it
> could still be useful to have a line with its name. When you do
> operation between branch, like cherry pick, it's more clear.
The current branch is displayed in the status bar.
>
> * If there isn't too much operations, it can be an option to have a
> button at the end for all of them. But, I'm afraid it will not be
> possible, in this case, I think the current menu items are fine.
>
> * When the cherry pick is triggered from this window, most of my
> comments in the previous mail don't apply in the same way. Having a
> entry for the log message could be useful though because making it
> editable in the main Git window can be a bit unexpected.
In theory yes, having a log editor there is great. However, practice is
almost always harder than theory with git. :( What I mean by that is,
AFAICS you can't get the message from an external source like you can
with a regular commit, i.e. there is no -m option for cherry-pick. The
only way git allows you to change the message is with the system's
command line editor. That means we'd either have to find some way to be
able to control editors from AnjutaLauncher, or find another way to get
at that message. ATM I have no idea how to do that...
>
> * For the cherry pick option. It would be better if we can remove all of
> them so we can save one click but I don't know if it's possible. For -n,
> another menu item looks fine, we just need to find a nice name. For the
> other options, they can be defined in global preferences but I don't use
> them and I don't know if it really makes sense.
While you might never use them, somebody will, and eventually they'll
want to have them. :-)

James


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi James,

James Liggett a écrit :
> While for most purposes, selecting the cherry pick option from within
> the log viewer, I very much have both methods there on purpose. The
> command from the Git menu is there for cases where you already have a
> commit hash, usually from an e-mail or bug report, from which you can
> copy and paste it.

I don't see the reason to use a commit hash here, I think sending
directly a patch make more sense. Moreover, I think in such case, you
can use the command line, git has a good command line interface.

Regards,

Sébastien

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi James,

James Liggett a écrit :
> If you already have a log listed, it will update itself when you switch
> branches.

It doesn't work here.

> 1. Viewing the log of very large projects is a very slow process and
> consumes a lot of memory.

Sure, so you have to do this in background. You can get only the first
20 items and request other only when the list view is scrolled.
Obviously, it is more work and it is a second order problem. But now
that your git plugin is working fine, I think it's useful to take care
of this.

> 2. It's very difficult to tell when something has changed; I'd have to
> monitor a lot of files in a lot of different places, which is likely a
> waste of CPU cycles.

I don't ask you to monitor everything. You can keep your refresh button.
But, I want to get the list filled by default with the log of the
current branch and have it automatically updated when I select another
branch.

> This is exactly what my proposed UI changes will do for us. Imagine the
> log viewer taking up the whole Anjuta window, with all the relevant
> commands at your fingertips, almost like GNOME shell but for git.  So,
> I'm just starting to call this project the "Git Shell." Under this plan,
> the main menu is replaced by a list of buttons on the left side of the
> pane.

I have something simpler in mind. Anjuta is already using gdl which
already support complex and user defined layout. I think we can still
make some improvements within this frame.

Your Git Log Window is already quite good for me, I'm just requesting a
few improvements:
- more automatic update
- Rename it Git Window or Git View, to make more clear that it's not
only a viewer.
- You can remove the Git->See Log as this window is already accessible
through View->Git Log (In the debugger most of the windows are
accessible only through the View menu).

Then, working on Git Shell can be interesting and useful but it will
probably need to change completely Anjuta graphical interface. Or do you
think it's needed only for the Git plugin ?

> Why can't we have both?  Sometimes I need to save diffs to files, and
> maybe even edit them.

Well, it's fine for me if you add a display window and keep the menu
item to open them in the editor.

Most of the time, I only want to see the diffs and currently I have to
create a new editor window to do this. It is not very convenient because:
- I need a click for each diff (you cannot create editor automatically)
- I need to move the git window, because the editor in under.
- I need to close the editor window (with an additional click because I
want to discard the data).

I think that a view window with just a send to editor in a context popup
menu will be much better. What do you think about this ?

>> * The current branch is already displayed with a green mark. I think it
>> could still be useful to have a line with its name. When you do
>> operation between branch, like cherry pick, it's more clear.
> The current branch is displayed in the status bar.

Yes, I haven't seen it, so perhaps something more obvious will be
better. Anyway if you think it's enough that's fine for me.

> In theory yes, having a log editor there is great. However, practice is
> almost always harder than theory with git.

Ok. That's a perfectly valid technical explanation, I haven't token care
that the -m option was missing. Then, perhaps you can do a cherry
picking without the commit (-n) and then do a normal commit with the old
log message ? But honestly, I'm considering this as a third order problem :)

>> them so we can save one click but I don't know if it's possible. For -n,
>> another menu item looks fine, we just need to find a nice name. For the
>> other options, they can be defined in global preferences but I don't use
>> them and I don't know if it really makes sense.
> While you might never use them, somebody will, and eventually they'll
> want to have them. :-)

Yes but, you haven't implemented all options for all git commands
(hopefully) so there is always a choice to do between common and less
common commands. You can always use the command line.
Then, I haven't asked you to remove any option but to move some of them
in a preference pages.
Anyway, I don't know these options and when launched from the log
window, I think it's useful to have this dialog to have one click before
doing something which cannot be easily reverted.

Regards,

Sébastien

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel