This fix is intended to let gitk preserve the window pane dimensions
regardless of whether ttk is enabled or not. I'm not an expert on Tcl/Tk but
as far as I can tell, this edit works and doesn't cause problems. Please
double-check what I did.
Eric Huber (1):
gitk: Preserve window dim
From: Eric Huber
Bug was: gitk would overwrite the botwidth setting in .gitk with
a nonsense value when not using tk themes. I'm not sure if this
is the right fix or not but it seems to work. Moving the affected
line within the conditional results in the expected behavior.
Signed-off-by:
From: Arash Bannazadeh-Mahani
The change is stemmed from a problem on the MacOS where, if --all
is passed to gitk it should show all the refs/commits graphically.
However, on really large git repos, in my instance a git repo with
over 52,000 commits, gitk will report an error,
"Error exec
gitk: no need to specify all refs, since git log --all is the same as list
is all the refs/commit ids. Also Mac OS has a limit on size of the list of
params for a command line
Arash Bannazadeh-Mahani (1):
gitk: Addressing error running on MacOS with large repos.
gitk-git/gitk | 7 ++-
1
On 2019-10-01 6:08 a.m., Bert Wesarg wrote:
Wrapping filenames is an unexpected experience in UX design. Disable
wrapping and add a horizontal scrollbar to the files list to remove this.
(Thanks for working on gitk and git-gui!)
I have to say I'm mildly opposed to this change. The reas
Wrapping filenames is an unexpected experience in UX design. Disable
wrapping and add a horizontal scrollbar to the files list to remove this.
Signed-off-by: Bert Wesarg
---
gitk | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index abe4805..bf2a061
Junio C Hamano writes:
> This would make this in line with pt_{pt,br}.po, existing locales
> with country code in them.
>
> Reviewed-by: Junio C Hamano
Paul, I've applied this to a clone of gitk locally and merged it
(resutling in 2a4ac71ffb that should be reachable from &#x
Denton Liu writes:
> When running make from a clean environment, all of the *.po files should
> be converted into *.msg files. After that, when make is run without any
> changes, make should not do anything.
>
> After beffae768a (gitk: Add Chinese (zh_CN) translation, 2017-03-11),
When running make from a clean environment, all of the *.po files should
be converted into *.msg files. After that, when make is run without any
changes, make should not do anything.
After beffae768a (gitk: Add Chinese (zh_CN) translation, 2017-03-11),
zh_CN.po was introduced. When make was run
Paul Mackerras writes:
> Hi Junio,
>
> Whenever it's convenient, please do a pull from my gitk repository at
> git://ozlabs.org/~paulus/gitk.git to get four commits updating gitk.
>
> Thanks,
> Paul.
Will do. Thanks.
Hi Junio,
Whenever it's convenient, please do a pull from my gitk repository at
git://ozlabs.org/~paulus/gitk.git to get four commits updating gitk.
Thanks,
Paul.
Gabriele Mazzotta (1):
gitk: Do not mistake unchanged
On Sat, Mar 23, 2019 at 06:00:36PM +0100, Gabriele Mazzotta wrote:
> Unchanged lines are prefixed with a white-space, thus unchanged lines
> starting with either " <" or " >" are mistaken for submodule changes.
> Check if a line starts with either " <" or " >" only if we listing
> the changes of
re are subexpressions, that
> will change how we have to interpret the list returned by the
> regexp -indices -all -inline command.
That just puts the responsibility of parsing the URL on the user, it
doesn't solve the problem.
I don't have any numbers, but I think most problemat
On Fri, Aug 30, 2019 at 12:02:07AM +0530, Pratyush Yadav wrote:
> On 29/08/19 11:27AM, Paul Mackerras wrote:
> > This makes gitk look for http or https URLs in the commit description
> > and make the URLs clickable. Clicking on them will invoke an external
> > web
On 29/08/19 11:27AM, Paul Mackerras wrote:
> This makes gitk look for http or https URLs in the commit description
> and make the URLs clickable. Clicking on them will invoke an external
> web browser with the URL.
>
> The web browser command is by default "xdg-open" on
Paul Mackerras writes:
> I was expecting some comments and suggestions, so I didn't push it out
> yet. One suggestion which seems reasonable is to match any http or
> https URL anywhere in the commit description, not just with Link: or
> BugLink: at the start of the line. What do you think of t
This makes gitk look for http or https URLs in the commit description
and make the URLs clickable. Clicking on them will invoke an external
web browser with the URL.
The web browser command is by default "xdg-open" on Linux, "open" on
MacOS, and "cmd /c start" o
Hi Junio,
On Tue, Aug 27, 2019 at 01:32:30PM -0700, Junio C Hamano wrote:
> Paul Mackerras writes:
>
> > This makes gitk look for lines in the commit message which start with
> > "Link:" or "BugLink:" followed by a http or https URL, and make the
> >
On 27/08/19 08:14AM, Paul Mackerras wrote:
> This makes gitk look for lines in the commit message which start with
> "Link:" or "BugLink:" followed by a http or https URL, and make the
> URL clickable. Clicking on it will invoke an external web browser with
> th
Paul Mackerras writes:
> This makes gitk look for lines in the commit message which start with
> "Link:" or "BugLink:" followed by a http or https URL, and make the
> URL clickable. Clicking on it will invoke an external web browser with
> the URL.
>
> The
On 8/26/19 6:14 PM, Paul Mackerras wrote:
This makes gitk look for lines in the commit message which start with
"Link:" or "BugLink:" followed by a http or https URL, and make the
URL clickable. Clicking on it will invoke an external web browser with
the URL.
The web b
This makes gitk look for lines in the commit message which start with
"Link:" or "BugLink:" followed by a http or https URL, and make the
URL clickable. Clicking on it will invoke an external web browser with
the URL.
The web browser command is by default "xdg-open&q
Hi
I run a MacBook Pro (15-inch, 2018) with macOS 10.14.6 (18G87)
I run git version 2.23.0 via brew install git.
As soon as I launch gitk, I get an empty gitk window for about 0.5
seconds before getting thrown back to the macOS login screen due to a
SIGSEGV in com.apple.WindowServer.
If I
on, the meaning of the
'--all' option changes its meaning from 'all refs' to 'all refs and
HEAD'". That way, gitk does not have to guess if '--all' found on
the command line is an option or something else (e.g. pathspec etc.)
That makes sense. It would be a
?
>>
>> What do you think? Or would you rather go the route of changing
>> rev-parse behavior?
>
> Depends on what you mean by the above. Do you mean that now the end
> user needs to say
>
> gitk --all-include-head --not origin/master
>
> to get
f like you proposed below?
> >
> > What do you think? Or would you rather go the route of changing
> > rev-parse behavior?
>
> Depends on what you mean by the above. Do you mean that now the end
> user needs to say
>
> gitk --all-include-head --not origin/mast
> rev-parse behavior?
Depends on what you mean by the above. Do you mean that now the end
user needs to say
gitk --all-include-head --not origin/master
to get a rough equivalent of
git log --graph --oneline --all --not origin/master
due to the discrepancy between how &quo
On Mon, Jul 08, 2019 at 10:16:50PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > The "--all" in rev-list family (including "git log") unconditionally
> > include HEAD. The glitch here is that "--all" in rev-parse does
> > not. And 4d5e1b1319 was an attempt to "fix" that, i.e. make
On Mon, Jul 08, 2019 at 09:55:00PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Heiko Voigt writes:
> >
> >> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
> >> 2014-09-09) the intention was to have detac
Junio C Hamano writes:
> The "--all" in rev-list family (including "git log") unconditionally
> include HEAD. The glitch here is that "--all" in rev-parse does
> not. And 4d5e1b1319 was an attempt to "fix" that, i.e. make "--all"
> imply "HEAD".
And it becomes really tempting to get rid of tha
Junio C Hamano writes:
> Heiko Voigt writes:
>
>> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
>> 2014-09-09) the intention was to have detached HEAD shown when the --all
>> argument is given.
>
> The "do we have --all
Heiko Voigt writes:
> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
> 2014-09-09) the intention was to have detached HEAD shown when the --all
> argument is given.
The "do we have --all?" test added by that old commit is not quite
satisf
is using --not this way or everyone took it
as a feature that HEAD would be removed and will complain once this get
released ;)
I usually use the caret notation, but I guess this time I was lazy and
the dash was easier to type...
> > ---
> > gitk | 2 +-
> > 1 file ch
Hi Heiko,
On Thu, 4 Jul 2019, Heiko Voigt wrote:
> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
> 2014-09-09) the intention was to have detached HEAD shown when the --all
> argument is given.
>
> This was solved by appending HEAD to the rev
In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
2014-09-09) the intention was to have detached HEAD shown when the --all
argument is given.
This was solved by appending HEAD to the revs list. By doing that the
behavior using the --not argument is now broken,
post-v2.22.0 to
brush up those gitk patches and contribute them to the Git mailing list
for review.
> On Sat, Apr 27, 2019 at 4:20 PM Johannes Schindelin
> wrote:
> >
> > Hi Bret,
> >
> > On Thu, 18 Apr 2019, Bret Barkelew wrote:
> >
> > > This i
ssue is now being reported by more users inside MS. I'll also
> > reach out to the Git for Windows advocacy group to see if they have
> > any ideas.
> >
> > I have not had time to figure out the inner workings of Tcl/Tk. Is
> > there any way to turn on tracing/l
s
> there any way to turn on tracing/logging in Git for which commands are
> being called by gitk?
Thank you for reaching out with detailed information internally, I am
happy to report that together with the help of Max Kirillov, this is now
resolved and a snapshot is available from
https://wi
alled by gitk?
On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew wrote:
>
> On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
> wrote:
> >
> > Hi Bret,
> >
> > in that case, please try to find a way to trace the commands in a Tcl/Tk
> > program (which gitk
On Tue, Apr 02, 2019 at 08:20:05PM +0200, Johannes Schindelin wrote:
> > Hitting some quadratic complexity algorithm explains why the "degradation"
> > is so huge. And if I understand it correctly we are more or less "unlucky"
> > to hit such access patterns more often in the new repo.
> >
> > Any
Hi Björn,
On Tue, 2 Apr 2019, Björn Pettersson A wrote:
> Thanks for a quick reply (with lots of details).
>
> Hitting some quadratic complexity algorithm explains why the "degradation"
> is so huge. And if I understand it correctly we are more or less "unlucky"
> to hit such access patterns more
nice to see that you already have some ideas regarding how to
improve this.
Regards,
Björn
> -Original Message-
> From: Jeff King
> Sent: den 2 april 2019 15:28
> To: Björn Pettersson A
> Cc: git@vger.kernel.org
> Subject: Re: Bad performance when using git log --pare
On Tue, Apr 02, 2019 at 11:31:59AM +, Björn Pettersson A wrote:
> Example:
>
> Run "git log --parents" for an old file (bswap.ll), and a brand new file
> (dummy).
Interesting case. I was able to reproduce it here pretty easily, and I
have a start on a solution below.
> So for bswap.ll it t
Hi!
The LLVM project is moving from SVN to git, creating a single repo on github
for several LLVM sub-projects.
In the past we have had one git repo mirror for each sub-project (mirroring the
SVN projects).
Unfortunately, I've seen some performance problems with git (or rather gitk)
Unchanged lines are prefixed with a white-space, thus unchanged lines
starting with either " <" or " >" are mistaken for submodule changes.
Check if a line starts with either " <" or " >" only if we listing
the changes of a submodule.
Signed-o
Paul Mackerras writes:
> On Wed, Mar 13, 2019 at 01:06:32PM +0100, Alexander Shopov wrote:
>>
>>
>> Hello all,
>> I am resending the update of Bulgarina translation of Gitk that I last sent
>> here:
>> on 4 of March: https://marc.info/?l=git&m=15
On Wed, Mar 13, 2019 at 01:28:33PM +0100, Alexander Shopov wrote:
> Signed-off-by: Alexander Shopov
Thanks, applied.
Paul.
On Wed, Mar 13, 2019 at 01:06:32PM +0100, Alexander Shopov wrote:
>
>
> Hello all,
> I am resending the update of Bulgarina translation of Gitk that I last sent
> here:
> on 4 of March: https://marc.info/?l=git&m=155169580131311&w=2
> Any idea why it is not get
translation of gitk po-file.
-# Copyright (C) 2014, 2015 Alexander Shopov .
+# Copyright (C) 2014, 2015, 2019 Alexander Shopov .
# This file is distributed under the same license as the git package.
-# Alexander Shopov , 2014, 2015.
+# Alexander Shopov , 2014, 2015, 2019.
#
#
msgid "&quo
Hello all,
I am resending the update of Bulgarina translation of Gitk that I last sent
here:
on 4 of March: https://marc.info/?l=git&m=155169580131311&w=2
Any idea why it is not getting merged? Perhaps I missed something or Paul
Mackerras,
maintaining gitk, is busy?
Anything that
+1,15 @@
# Bulgarian translation of gitk po-file.
-# Copyright (C) 2014, 2015 Alexander Shopov .
+# Copyright (C) 2014, 2015, 2019 Alexander Shopov .
# This file is distributed under the same license as the git package.
-# Alexander Shopov , 2014, 2015.
+# Alexander Shopov , 2014, 2015, 2019
On 03/03/2019 00:02, Paul Mackerras wrote:
> On Tue, Feb 26, 2019 at 12:05:34PM +0100, Andrej Shadura wrote:
>> The colours gitk is currently using are from the basic 16 colour
>> palette, and are a bit too intensive to be comfortable or pleasant
>> to work with.
>>
On Tue, Feb 26, 2019 at 12:05:34PM +0100, Andrej Shadura wrote:
> The colours gitk is currently using are from the basic 16 colour
> palette, and are a bit too intensive to be comfortable or pleasant
> to work with.
>
> Adjust the main colours (commit nodes, remotes, tags and one
Auto-selection of the commit hash overwrites whatever content was in the
selection clipboard, and also pollutes the clipboard history if the user
is using a clipboard manager. Most users probably want this off by
default.
Signed-off-by: Andrej Shadura
---
gitk-git/gitk | 2 +-
1 file changed, 1
The colours gitk is currently using are from the basic 16 colour
palette, and are a bit too intensive to be comfortable or pleasant
to work with.
Adjust the main colours (commit nodes, remotes, tags and one branch
colour) to be slightly softer.
Signed-off-by: Andrej Shadura
---
gitk-git/gitk
Run 'git update-index --refresh' in order to get rid
of false positives about unstaged changes in files.
To reproduce:
1. git status # no local changes
2. touch
3. gitk # file shows up as unstaged modified file
4. git update-index --refresh
5. gitk # file does not show up
See link
On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
wrote:
>
> Hi Bret,
>
> in that case, please try to find a way to trace the commands in a Tcl/Tk
> program (which gitk is) and see which command triggers the error.
Er... that's a little out of my depth. I'll see if
Hi Bret,
in that case, please try to find a way to trace the commands in a Tcl/Tk
program (which gitk is) and see which command triggers the error.
Ciao,
Johannes
On Wed, 9 Jan 2019, Bret Barkelew wrote:
> Will try to reply in-line, when appropriate.
> The latest snapshot (git version
;
> > - Bret
> >
> > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner wrote:
> > >
> > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew wrote:
> > >>
> > >> When I open gitk in a particular repository under this version of Git
> > >&
3, 2019 at 7:10 PM Bryan Turner wrote:
> >
> > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew wrote:
> >>
> >> When I open gitk in a particular repository under this version of Git
> >> for Windows, I now get a dialog box that says "Error: couldn't
On 1/7/19 6:41 PM, Philip Oakley wrote:
On 06/01/2019 22:51, Jacob Kroon wrote:
Hi,
Not sure if this has already been reported, but I observe this odd
behaviour in gitk from master:
git status
gitk # everything looks good
touch
gitk # gitk shows "local uncomitted changes" on
On 06/01/2019 22:51, Jacob Kroon wrote:
Hi,
Not sure if this has already been reported, but I observe this odd
behaviour in gitk from master:
git status
gitk # everything looks good
touch
gitk # gitk shows "local uncomitted changes" on the file I touched
git status
gitk # gitk
Hi,
Not sure if this has already been reported, but I observe this odd
behaviour in gitk from master:
git status
gitk # everything looks good
touch
gitk # gitk shows "local uncomitted changes" on the file I touched
git status
gitk # gitk is back to normal again, showing no local u
mes in the Windows registry, which did not resolve the issue with
git 2.20.1.
Happy to collect any additional data.
- Bret
On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner wrote:
>
> On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew wrote:
>>
>> When I open gitk in a particular repository unde
When I open gitk in a particular repository under this version of Git
for Windows, I now get a dialog box that says "Error: couldn't execute
"git": file name too long". I've noticed that the most pronounced
effect is that I cannot see the file diffs (or sometimes the
Signed-off-by: Guillermo S. Romero
---
Hi:
This removes the hardcoded color and uses the user config (still
yellow by default) so searches share a common look.
GSR
PS: Not subscribed to git@vger, so remember to CC: me.
gitk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Dear developers,
I am a daily use of gitk; I use the "color words" diff option most often.
I have found no way to set --word-diff-regex for gitk, or to make the command
git config --global diff.wordRegex '.'
have effect on the diffs shown in gitk.
I think the value of
there are
effectively useless because they set the variable whose name is the
contents of currdiffsubmod, rather than currdiffsubmod itself. I assume
it was a typo.)
-Roman
Thanks,
Stefan
Signed-off-by: Роман Донченко
---
gitk | 8 ++++----
1 file changed, 4 insertions(+), 4 deletio
was not taken AFAICT.
Thanks,
Stefan
>
> Signed-off-by: Роман Донченко
> ---
> gitk | 8 ++++
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gitk b/gitk
> index a14d7a1..6bb6dc6 100755
> --- a/gitk
> +++ b/gitk
> @@ -8109,6 +8109,8 @@
er we are currently
inside a submodule diff and only highlight these lines if we are.
Signed-off-by: Роман Донченко
---
gitk | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index a14d7a1..6bb6dc6 100755
--- a/gitk
+++ b/gitk
@@ -8109,6 +8109,8 @@ proc parseblob
On 21/10/18 18:34, Dummy Name wrote:
> From: Gabriele Mazzotta
>
> Unchanged lines are prefixed with a white-space, thus unchanged lines
> starting with either " <" or " >" are mistaken for submodule changes.
> Check if a line starts with either " <" or " >" only if we listing
> the changes of
es of a submodule.
Signed-off-by: Gabriele Mazzotta
---
gitk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index a14d7a1..dd4bbbf 100755
--- a/gitk
+++ b/gitk
@@ -8191,11 +8191,11 @@ proc parseblobdiffline {ids line} {
} else {
$ctext
Hi,
Just a ping for opinions. I can provide a patch if the changes make sense.
On 12/05/18 15:14, Andrej Shadura wrote:
> Hello everyone,
>
> I’ve been using Gitk with the following colour settings for a year or
> so, and I found it much more convenient to use that the current defau
To quit gitk, I have to invoke ctrl-c from the command line. I get this
error when trying to quit gitk with ctrl-q or from the GUI menu:
--
☧
error writing "stdout": I/O error
error writing "stdout": I/O error
while executing
"puts "Error saving config: $e
On MacOS, a "wish" application started from the terminal opens in the
background, thus doesn't match user expectation that a newly-launched
application ought to be placed in the foreground. To address this
shortcoming, both gitk and git-gui use Apple Events to send a message to
t;>>> Not sure what you referring to?
>>>> Is it alternative to gitk? How I install it?
>>>
>>> This: https://git-scm.com/docs/git-gui
>>>
>>> It's not an alternative to gitk, but complements it by providing
>>> abilit
[re-adding cc:git]
On Fri, Jul 20, 2018 at 12:38 AM Evgeny Cherpak wrote:
> > On 20 Jul 2018, at 7:30, Eric Sunshine wrote:
> >
> > On Fri, Jul 20, 2018 at 12:11 AM Evgeny Cherpak wrote:
> >> Not sure what you referring to?
> >> Is it alternative to gitk? H
> open -a \"$(ps -p %d -o comm=)\"
> } [pid] ]
> exec osascript -e [format {
> do shell script "%s"
> } "$openscript” ]
> }
Interesting idea. A shortcoming of this approach is that it's
non-deterministic
do shell script "%s"
} "$openscript” ]
}
> On 19 Jul 2018, at 22:12, Eric Sunshine wrote:
>
> On Thu, Jul 19, 2018 at 2:48 PM Evgeny Cherpak wrote:
>> You have probably heard this by now already, but gitk doesn’t work on macOS
>> 10.14 - because it uses
On Thu, Jul 19, 2018 at 2:48 PM Evgeny Cherpak wrote:
> You have probably heard this by now already, but gitk doesn’t work on macOS
> 10.14 - because it uses Apple Events,
> And apps on 10.14 require user to give them permissions to control other apps
> with Apple Events.
This
Hi
You have probably heard this by now already, but gitk doesn’t work on macOS
10.14 - because it uses Apple Events,
And apps on 10.14 require user to give them permissions to control other apps
with Apple Events.
Here is what I get when I try running it on my machine with beta 4 installed
Dear git community,
Is it possible please for the gitk selection color setting to be persistent?
Since 2015 the below approach has been working for me.
Thank you for considering!
Mychael
--- a/gitk
+++ b/gitk
@@ -2409,6 +2409,7 @@ proc makewindow {} {
text $ctext -background $bgcolor
On Thu, Jun 14, 2018 at 02:53:03PM +0200, Juan Navarro wrote:
> Gitk "find commit" search function doesn't follow the "IgnCase" option that
> is selectable with a combo selector on the right side of the window; it
> should be searching in a case-insensitive
Hi,
this question was originally posted on the Google Groups list, trying to
get help
(https://groups.google.com/d/topic/git-users/QAFKOQU4eUo/discussion).
Now that it's confirmed as a bug and I have a proposed solution, I'm
posting here.
Gitk "find commit" search fun
Hello everyone,
I’ve been using Gitk with the following colour settings for a year or
so, and I found it much more convenient to use that the current default,
so I’d like to propose to make them the defaults. These colours are
slightly less 80’s i.e. they’re using colours outside of the ‘classic
and by adding a menu element
> to start gitk in the submodule (similar to git gui).
>
> This iteration does not address the behaviour of file list panel in tree mode
> when gitk is started from a subdirectory (gitk strictly limits the file
> listing to the files in that repository, with
From: Alex Riesen
Currently, selecting a name in the file list (bottom right) panel in
"Tree" mode does not do anything useful if the name is a submodule.
If gitk is currently showing a commit, the submodule names are not shown
at all (which is very confusing). If the gitk is s
From: Alex Riesen
Similar to a git gui feature which visualizes history in a submodule,
the submodules cause the gitk be started inside the submodule.
Signed-off-by: Alex Riesen
---
gitk | 12
1 file changed, 12 insertions(+)
diff --git a/gitk b/gitk
index 742f36b..c430dfe
From: Alex Riesen
Currently, the submodule entries in the file list panel are mostly ignored.
This series attempts to improve the situation by showing part of submodule
history when focusing it in the file list panel and by adding a menu element
to start gitk in the submodule (similar to git gui
Bert Wesarg, Wed, May 09, 2018 14:08:51 +0200:
> >> I noticed that too, while testing your patch and I'm also confused.
> >> But was not able to send a request to Paul yet. ls-tree --full-tree
> >> seems to be one that should be used here, I think.
> >
> > Well, I just tried your suggestion. 'ls-fi
the full listing without restarting
> gitk.
> ---
>
> Bert Wesarg, Wed, May 09, 2018 09:19:55 +0200:
>> > Frankly, this listing limited to just a sub-directory confuses me a bit. Is
>> > there anyway to get to display full repository without changing to the top
>> > l
Sorry for broken threading... I'll have to work on that.
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
From: Alex Riesen
Similar to a git gui feature which visualizes history in a submodule,
the submodules cause the gitk be started inside the submodule.
---
gitk | 12
1 file changed, 12 insertions(+)
diff --git a/gitk b/gitk
index 742f36b..c430dfe 100755
--- a/gitk
+++ b/gitk
From: Alex Riesen
Currently, selecting a name in the file list (bottom right) panel in
"Tree" mode does not do anything useful if the name is a submodule.
If gitk is currently showing a commit, the submodule names are not shown
at all (which is very confusing). If the gitk is s
Currently, the submodule entries in the file list panel are mostly ignored.
This series attempts to improve the situation by showing part of submodule
history when focusing it in the file list panel and by adding a menu element
to start gitk in the submodule (similar to git gui).
Alex Riesen (2
From: Alex Riesen
The previous behavior conflicts with the "Patch" mode of the panel,
which always shows the changes from the top-level of the repository.
It is also impossible to get back to the full listing without restarting
gitk.
---
Bert Wesarg, Wed, May 09, 2018 09:1
Stefan Beller, Tue, May 08, 2018 19:07:29 +0200:
> On Tue, May 8, 2018 at 5:22 AM, Alex Riesen
> wrote:
> > Currently, the submodules either are not shown at all (if listing a
> > committed tree) or a Tcl error appears (when clicking on a submodule
> > from the index list).
>
> I do not understan
t;> > +set x [shellquote $flist_menu_file]
>>
>> this needs to handle cdup, i.e., if gitk is run from a subdirectory,
>> all paths needs to be prefixed with $cdup, like: [file join $cdup
>> $flist_menu_file]
>
> That, indeed, is easily done:
>
> set x [shel
yet.
Where do I have to click to see the effects of this patch?
>
> This will make it show first arbitrarily chosen number of commits,
> which might be only marginally better.
>
> Signed-off-by: Alex Riesen
> ---
> gitk | 42 --
>
Bert Wesarg, Tue, May 08, 2018 15:17:03 +0200:
> On Tue, May 8, 2018 at 2:22 PM, Alex Riesen
> wrote:
> > +proc flist_gitk {} {
> > +global flist_menu_file findstring gdttype
> > +
> > +set x [shellquote $flist_menu_file]
>
> this needs to hand
1 - 100 of 965 matches
Mail list logo
