[BUNDLE] Add Commit Tool to Cheetah menus and added extra menu separator
Christian MICHON
please find enclosed a git bundle based on
dde2f6f67049f355b689a626bc09076971f760a0.
this commit allows 2 things:
- a new menu item, calling git-citool (this is what I usually miss on
windows: a quick commit window that closes itself once the commit is
done)
- extra separator menu (because if gvim is installed, "edit with vim"
usually ends up in the same menu space as git-cheetah :( )
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Johannes Schindelin
On Wed, 21 Jan 2009, Christian MICHON wrote:
> please find enclosed a git bundle based on
> dde2f6f67049f355b689a626bc09076971f760a0.
Thanks. I applied it, and pushed it out as branch "christian" for larger
visibility.
ATM I am swamped with work, so I will not be able to test or comment for a
while.
Ciao,
Dscho
Christian MICHON
<Johannes....@gmx.de> wrote:
> Hi,
>
> On Wed, 21 Jan 2009, Christian MICHON wrote:
>
>> please find enclosed a git bundle based on
>> dde2f6f67049f355b689a626bc09076971f760a0.
>
> Thanks. I applied it, and pushed it out as branch "christian" for larger
> visibility.
thanks. I've a few more ideas I'll try to push soon into this branch.
>
> ATM I am swamped with work, so I will not be able to test or comment for a
> while.
>
same here for me: I'm way due to deliver a 'vim compilation' for
msysgit, but the current day job ate the whole bandwitdh (even in the
train...)
Kirill
Sorry for my late responses. Seems like everybody is busy these days :)
> -----Original Message-----
> From: Christian MICHON
> Sent: Wednesday, January 21, 2009 4:45 AM
> Subject: [msysGit] [BUNDLE] Add Commit Tool to Cheetah menus and added
> extra menu separator
> this commit allows 2 things:
> - extra separator menu (because if gvim is installed, "edit with vim"
> usually ends up in the same menu space as git-cheetah :( )
This extra separator should be placed in (g)vim's extension. Because if you
have two Cheetah-like extensions installed, you'll end up with two
separators.
> -----Original Message-----
> From: Christian MICHON [mailto:christia...@gmail.com]
> Sent: Friday, February 06, 2009 9:48 AM
> Subject: Re: [msysGit] Minor menu changes to git-cheetah available on
> 'christian' branch
>
> On Fri, Feb 6, 2009 at 3:29 PM, Christian MICHON
> <christia...@gmail.com> wrote:
> >>> I agree, but we would need a way (outside of git-gui) to tell us
> >>> the status of the files.
> >>
> >> We already have that, thanks to Kirill. The menu items have flags
> >> specifying when to display them.
> trying to fiddle with exec_program: I cannot figure out how to pipe 2
> commands (this would solve nicely my local pb).
In Cheetah, there is currently no way to pipe commands. It's probably not
that difficult to extend exec_program to redirect stdin as well, but to make
a real pipe we'll need to provide some sort of callback mechanism or some
other means to write to that stdin.
Having said that, you may be able to get away without feedling with [already
unmanagable] exec_program if you use cmd.exe to do the piping. Essentially,
you need to execute something like
cmd.exe /c git format-patch -k --stdout R1..R2 | git am -3 -k
There __may__ be some troubles with explaining to cmd.exe that the piping is
part of the inner command. In other words that what should be executed is
"cmd (git | git)" and not "(cmd git) | git". But from cmd /? it seems
possible with quotes.
The rest is just two minor comments to the patches.
Unfortunately, I can't find how to comment on a patch, sent in a bundle, so
I copied-pasted the following from repo.or.cz and hope that you'll find what
I'm talking about:
> Add a truly separated git-init in Cheetah menus
> diff --git a/cheetahmenu.c b/cheetahmenu.c
> index b825ca9..8688558 100644 (file)
> --- a/cheetahmenu.c
> +++ b/cheetahmenu.c
> @@ -140,9 +147,9 @@ const struct menu_item cheetah_menu[] = {
> "Launch the GIT Gui in the local or chosen directory.",
> build_item, menu_gui },
>
> - { MENU_ITEM_NOREPO | MENU_ITEM_FILE, "&Git Init Here",
> + { MENU_ITEM_NOREPO, "&Git Init Here",
> "Initialize GIT repo in the local directory.",
> - build_item, menu_gui },
> + build_item, menu_init },
> { MENU_ITEM_NOREPO | MENU_ITEM_DIR, "&Git Clone Here",
> "Clone GIT repo into the local or chosen directory.",
> build_item, menu_gui },
The fact that we have Git Init Here in non-repo dir always [and Git Clone
Here only if a directory is selected] bother me, but I can't explain why.
May be you can give it a second thought.
> Fixed incoherent menu_gui entries (removed git clone here)
> diff --git a/cheetahmenu.c b/cheetahmenu.c
> index 8688558..55a1b77 100644 (file)
> --- a/cheetahmenu.c
> +++ b/cheetahmenu.c
> @@ -143,15 +143,15 @@ const struct menu_item cheetah_menu[] = {
> "Start a blame viewer on the specified file.",
> build_item, menu_blame },
>
> - { MENU_ITEM_REPO, "&Git",
> + { MENU_ITEM_REPO, "Git &Gui",
> "Launch the GIT Gui in the local or chosen directory.",
> build_item, menu_gui },
>
> { MENU_ITEM_NOREPO, "&Git Init Here",
> "Initialize GIT repo in the local directory.",
> build_item, menu_init },
> - { MENU_ITEM_NOREPO | MENU_ITEM_DIR, "&Git Clone Here",
> - "Clone GIT repo into the local or chosen directory.",
> + { MENU_ITEM_NOREPO | MENU_ITEM_DIR, "Git &Gui",
> + "Launch the GIT Gui in the local or chosen directory.",
> build_item, menu_gui },
>
> { MENU_ITEM_ALWAYS, "Git Ba&sh",
It took me good 5 minutes to figure out why we can't add Git Gui always.
Correct me if I'm wrong, but the idea is that one day we'll be able to
launch gui in the "clone" mode with the destination directory prefilled. If
so, a comment would help the next poor soul :)
Hope it helps a bit.
--
Kirill.
Christian MICHON
> Christian,
>
> Sorry for my late responses. Seems like everybody is busy these days :)
yessss
>> this commit allows 2 things:
>> - extra separator menu (because if gvim is installed, "edit with vim"
>> usually ends up in the same menu space as git-cheetah :( )
> This extra separator should be placed in (g)vim's extension. Because if you
> have two Cheetah-like extensions installed, you'll end up with two
> separators.
no, I do not end up with 2 separators. how do you install 2
cheetah-like extensions ? ;-)
>> >>> I agree, but we would need a way (outside of git-gui) to tell us
>> >>> the status of the files.
>> >>
>> >> We already have that, thanks to Kirill. The menu items have flags
>> >> specifying when to display them.
>> trying to fiddle with exec_program: I cannot figure out how to pipe 2
>> commands (this would solve nicely my local pb).
> In Cheetah, there is currently no way to pipe commands. It's probably not
> that difficult to extend exec_program to redirect stdin as well, but to make
> a real pipe we'll need to provide some sort of callback mechanism or some
> other means to write to that stdin.
yes, I saw the code in exec.c
>
> Having said that, you may be able to get away without feedling with [already
> unmanagable] exec_program if you use cmd.exe to do the piping. Essentially,
> you need to execute something like
>
> cmd.exe /c git format-patch -k --stdout R1..R2 | git am -3 -k
>
> There __may__ be some troubles with explaining to cmd.exe that the piping is
> part of the inner command. In other words that what should be executed is
> "cmd (git | git)" and not "(cmd git) | git". But from cmd /? it seems
> possible with quotes.
I'm not in favor of using cmd: I'd rather get the status from git-gui instead
>
> The rest is just two minor comments to the patches.
>
> Unfortunately, I can't find how to comment on a patch, sent in a bundle, so
> I copied-pasted the following from repo.or.cz and hope that you'll find what
> I'm talking about:
ok. I saw Dscho merged my changes with the master branch. Actually, I
inserted inside these changes the git-gui submenu the way they made
sense to me. If I've a git-init, the git-clone does not make so much
sense, unless it's indeed a pre-filled form.
>> Add a truly separated git-init in Cheetah menus
>> diff --git a/cheetahmenu.c b/cheetahmenu.c
> The fact that we have Git Init Here in non-repo dir always [and Git Clone
> Here only if a directory is selected] bother me, but I can't explain why.
> May be you can give it a second thought.
I removed git-clone afterwards :)
>
>> Fixed incoherent menu_gui entries (removed git clone here)
>> diff --git a/cheetahmenu.c b/cheetahmenu.c
> It took me good 5 minutes to figure out why we can't add Git Gui always.
> Correct me if I'm wrong, but the idea is that one day we'll be able to
> launch gui in the "clone" mode with the destination directory prefilled. If
> so, a comment would help the next poor soul :)
well, you guessed it right. I had a look at git-gui and it'll take me
some time to get what I'd like to see. The comment has been changed
and aligned with git-gui original comment. If we implement
successfully the git-clone functionality, I'll add the comment on this
new submenu entry.
>
> Hope it helps a bit.
>
yes, thanks. do you have a way to feed a status as columns into a
custom explorer view using c only ?
Johannes Schindelin
On Mon, 9 Feb 2009, Christian MICHON wrote:
> ok. I saw Dscho merged my changes with the master branch.
Yes, I reserve the right to include code when the interested parties do
not react with revisions. I see that as silent consent.
Also, I would like to see git-cheetah development speed up, what with
others having overtaken us in terms of Windows support :-(
Ciao,
Dscho
Kirill
> -----Original Message-----
> From: Christian MICHON [mailto:christia...@gmail.com]
> Sent: Monday, February 09, 2009 3:24 AM
> On Sat, Feb 7, 2009 at 4:01 PM, Kirill <kirill...@gmail.com> wrote:
> >> - extra separator menu (because if gvim is installed, "edit with
> >> vim" usually ends up in the same menu space as git-cheetah :( )
> > This extra separator should be placed in (g)vim's extension. Because
> > if you have two Cheetah-like extensions installed, you'll end up
> > with two separators.
> no, I do not end up with 2 separators. how do you install 2
> cheetah-like extensions ? ;-)
Right, there is only one separator, because (g)vim does not add one. But if
you look at cheetahmenu.c, you'll see that the first thing Cheetah does is
adding a separator:
const struct menu_item cheetah_menu[] = {
{ MENU_ITEM_ALWAYS, NULL, NULL, build_separator, NULL },
Now, the logic behind that is: nobody told me that when my extension is
asked to build menu items, the new group of items is started with a
separator; hence, I'll add one to start a new group.
And, IMHO, this is a fine logic for a well behaving extension (you want a
new group, you start one).
Now, let's imagine that we have two well behaving extensions. The first one
will add a separator to start its group and then will add few items. The
second one will add a separator to start its group and then will add few
items.
But your code does one extra step: it adds a separator at the end of its
group, which if inserted in the story from the previous paragraph will
produce two separators. Actually, for all the extension knows, its group
could actually be the last group in the whole context menu, producing a
separator as the last item of a menu.
> yes, thanks. do you have a way to feed a status as columns into a
> custom explorer view using c only ?
That would require yet another COM interface. So far, I'm supposed to have
some free time this weekend (Feb 28), and if I do, I'll send you a
boilerplate.
--
Kirill.