threads / patch / 17929

patchPredefined external command: git commit

Subject: [tig PATCH] Predefined external command: git commit

## tl;dr

5 messages between Feb 21, 2009 and Feb 21, 2009. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

Giuseppe Bilotta· Feb 21, 2009, 00:28 UTC · lore

Status view allows management of the stage area, and the user is likely to issue a commit as soon as (s)he's satisfied with the result. Mapping 'git commit' to the 'C' key in status view makes this straightforward and allows a very streamlined workflow from within git.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---

It might make sense to map 'A' to 'git commit --amend', too, even though that key is currently taken by author display toggle.

 manual.txt |    9 +++++----
 tig.c      |    2 ++
 2 files changed, 7 insertions(+), 4 deletions(-)
Show changes to 2 files +7 −4

manual.txt, tig.c

diff --git a/manual.txt b/manual.txt
index 74fa3f8..104989f 100644
--- a/manual.txt
+++ b/manual.txt
@@ -449,11 +449,12 @@ a script or program. They are bound to keys and use information from the
 current browsing state, such as the current commit ID. Tig comes with
 the following built-in external commands:
 
-`-------`--------------------------------------------------------------------
-Key	Action
+`-------`-------`------------------------------------------------------------
+Keymap	Key	Action
 -----------------------------------------------------------------------------
-C	git cherry-pick %(commit)
-G	git gc
+MAIN	C	git cherry-pick %(commit)
+STATUS	C	git commit
+GENERIC	G	git gc
 -----------------------------------------------------------------------------
 
 [[refspec]]
diff --git a/tig.c b/tig.c
index 9349f69..c22f271 100644
--- a/tig.c
+++ b/tig.c
@@ -1365,6 +1365,7 @@ static void
 add_builtin_run_requests(void)
 {
 	const char *cherry_pick[] = { "git", "cherry-pick", "%(commit)", NULL };
+	const char *commit[] = { "git", "commit", NULL };
 	const char *gc[] = { "git", "gc", NULL };
 	struct {
 		enum keymap keymap;
@@ -1373,6 +1374,7 @@ add_builtin_run_requests(void)
 		const char **argv;
 	} reqs[] = {
 		{ KEYMAP_MAIN,	  'C', ARRAY_SIZE(cherry_pick) - 1, cherry_pick },
+		{ KEYMAP_STATUS,  'C', ARRAY_SIZE(commit) - 1, commit },
 		{ KEYMAP_GENERIC, 'G', ARRAY_SIZE(gc) - 1, gc },
 	};
 	int i;
-- 
1.6.2.rc1.258.g1d592.dirty
Jonas Fonseca· Feb 21, 2009, 16:19 UTC · re: Giuseppe Bilotta · lore

Re: [tig PATCH] Predefined external command: git commit

On Sat, Feb 21, 2009 at 01:28, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:

> It might make sense to map 'A' to 'git commit --amend', too, even though
> that key is currently taken by author display toggle.

We could remap author toggling to 'a' to free 'A'. I assume you want 'A' to make it less likely to be pressed by accident?

BTW, to make the keybinding more scalable, the option toggling should probably be hidden behind a common prefix key, which would open a menu with next key searching this menu.

Thanks for both patches.
-- 
Jonas Fonseca
Giuseppe Bilotta· Feb 21, 2009, 17:19 UTC · re: Jonas Fonseca · lore

Re: [tig PATCH] Predefined external command: git commit

On Sat, Feb 21, 2009 at 5:19 PM, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
Show 7 quoted lines
> On Sat, Feb 21, 2009 at 01:28, Giuseppe Bilotta
> <giuseppe.bilotta@gmail.com> wrote:
>> It might make sense to map 'A' to 'git commit --amend', too, even though
>> that key is currently taken by author display toggle.
>
> We could remap author toggling to 'a' to free 'A'. I assume you want
> 'A' to make it less likely to be pressed by accident?

Actually it was more for consistency (uppercase C, uppercase A), but it could be considered for that purpose: it makes sense to have actions that change the repo harder to hit by accident.

> BTW, to make the keybinding more scalable, the option toggling should
> probably be hidden behind a common prefix key, which would open a menu
> with next key searching this menu.

Since t is taken by tree view, we could have 'o' for options. However, it IS a nice thing to have quick toggles for the most common ones.

> Thanks for both patches.

Thank you for this excellent piece of software. I have some more minor patches up at git://git.oblomov.eu/tig (gitweb at same address with http) which I'm going to submit soon.

I honestly wish I could contribute with some more important feature such as bundle support or automatic color inversion on light backgrounds.

-- 
Giuseppe "Oblomov" Bilotta
Jonas Fonseca· Feb 21, 2009, 17:51 UTC · re: Giuseppe Bilotta · lore

Re: [tig PATCH] Predefined external command: git commit

On Sat, Feb 21, 2009 at 18:19, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:

> Thank you for this excellent piece of software. I have some more minor
> patches up at git://git.oblomov.eu/tig (gitweb at same address with
> http) which I'm going to submit soon.
Don't bother sending the `tig log` patch. ;)

I deprecated this subcommand a long time ago, and would prefer if it wasn't added again. Having a lot of subcommands makes it more likely that doing `tig $BRANCH` will not do the expected thing. Also, I don't find it particularly useful myself and might actually remove it in the future, if I ever get to implementing support for defining "custom views".

> I honestly wish I could contribute with some more important feature
> such as bundle support or automatic color inversion on light
> backgrounds.
/me too. :)
-- 
Jonas Fonseca
Giuseppe Bilotta· Feb 21, 2009, 18:52 UTC · re: Jonas Fonseca · lore

Re: [tig PATCH] Predefined external command: git commit

On Sat, Feb 21, 2009 at 6:51 PM, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
Show 14 quoted lines
> On Sat, Feb 21, 2009 at 18:19, Giuseppe Bilotta
> <giuseppe.bilotta@gmail.com> wrote:
>> Thank you for this excellent piece of software. I have some more minor
>> patches up at git://git.oblomov.eu/tig (gitweb at same address with
>> http) which I'm going to submit soon.
>
> Don't bother sending the `tig log` patch. ;)
>
> I deprecated this subcommand a long time ago, and would prefer if it
> wasn't added again. Having a lot of subcommands makes it more likely
> that doing `tig $BRANCH` will not do the expected thing. Also, I don't
> find it particularly useful myself and might actually remove it in the
> future, if I ever get to implementing support for defining "custom
> views".
You actually plan on removing the log view altogether?

The problem of conflicting with tig $BRANCH could maybe be solved by prefixing commands with something (a dot or something easy to type, if not the traditional - or --)

Show 5 quoted lines
>> I honestly wish I could contribute with some more important feature
>> such as bundle support or automatic color inversion on light
>> backgrounds.
>
> /me too. :)
I'll do my best 8-)
-- 
Giuseppe "Oblomov" Bilotta

← back to recent threads