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
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 in
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
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 d34833f..1ec545e
From: Alex Riesen
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).
This will make it show first arbitrarily chosen number of commits,
which might be only marginally better.
Signed-off
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).
[1/2]: gitk: sh
Ævar Arnfjörð Bjarmason, Wed, Dec 20, 2017 19:24:19 +0100:
> diff --git a/INSTALL b/INSTALL
> index ffb071e9f0..808e07b659 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -84,9 +84,24 @@ Issues of note:
>
> GIT_EXEC_PATH=`pwd`
> PATH=`pwd`:$PATH
> - GITPERLLIB=`pwd`/perl/blib/lib
> +
file in the list to make it selected.
Signed-off-by: Alex Riesen
---
lib/diff.tcl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 0d56986..30bdd69 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -127,6 +127,9 @@ proc show_diff {path w {lno {}} {scroll_pos
into the separate names.
Note that the file marked and diffed immediately after starting the GUI up,
is not actually selected. One must click on it once to really select it.
Signed-off-by: Alex Riesen
---
lib/tools.tcl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/tools.tcl b/lib
Jakub Narębski, Mon, Jun 27, 2016 19:28:07 +0200:
> On 2016-06-27, Alex Riesen wrote:
>
> > This adds a FILENAMES environment variable, which contains the repository
> > pathnames of all selected files the list.
> > The variable contains the names separated by space
Johannes Schindelin, Mon, Jun 27, 2016 17:49:30 +0200:
> On Mon, 27 Jun 2016, Alex Riesen wrote:
>
> > This adds a FILENAMES environment variable, which contains the repository
> > pathnames of all selected files the list.
> > The variable contains the names separated by
Jakub Narębski, Mon, Jun 27, 2016 19:32:25 +0200:
> W dniu 2016-06-27 o 15:23, Alex Riesen pisze:
> > It is very confusing that the file, diff of which is displayed and which is
> > marked as selected in the file list, is not, in fact, selected. I.e. the
> > array
> >
{}}} {
} else {
start_show_diff $cont_info
}
+
+ global current_diff_path selected_paths
+ set selected_paths($current_diff_path) 1
}
proc show_unmerged_diff {cont_info} {
--
2.9.0.45.g28c608e.dirty
To:
Cc:
Bcc:
Subject:
Reply-To: Alex Riesen
starting the GUI up,
is not actually selected. One must click on it once to really select it.
Signed-off-by: Alex Riesen
---
One day the FILENAME and FILENAMES will have to be fixed to properly pass the
file names with spaces. Sorry, I couldn't find how to do it this time around.
lib/tool
FWIW, the issue is still present.
-- Forwarded message --
From: Alex Riesen
Date: Wed, Nov 17, 2010 at 6:10 PM
Subject: Runaway "git remote" if group definition contains a remote by
the same name
To: Git Mailing List
Hi,
it is also a way to create a fork bomb
On Thu, Aug 29, 2013 at 8:54 AM, Johannes Sixt wrote:
> It looks like on Windows we disallow arguments that contain double-quote,
> colon, or asterisk, and otherwise wrap arguments in double-quotes if they
> contain space. Then pass them through qx{}, which I can only guess what it
> does.
Well,
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen wrote:
> This short discussion on GitHub (file git-compat-util.h) might be relevant:
>
> https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
>
> The change suggested there (to remove
This short discussion on GitHub (file git-compat-util.h) might be relevant:
https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
The change suggested there (to remove an inclusion of windows.h in
git-compat-util.h) might simplify the solution a litt
mv: cannot stat `perl.mak': No such file or directory
mv: cannot move `perl.mak' to `perl.mak.old': No such file or directory
Writing perl.mak for Git
Writing MYMETA.yml
Writing perl.mak for Git
Writing MYMETA.yml
Writing perl.mak for Git
Writing MYMETA.yml
make[2]: *** [perl.mak] Error 1
make[1]:
On Mon, Jul 9, 2012 at 3:41 AM, Junio C Hamano wrote:
> Alex Riesen writes:
>
>> The original (shell coded) version of the git-clone just used mkdir(1)
>> to create the working directories. The builtin changed the mode argument
>> to mkdir(2) to 0755, which was a bit u
behaviour for new directory/file creation.
---
On Fri, 6 Jul 2012, Daniel Barkalow wrote:
> On Fri, 6 Jul 2012, Alex Riesen wrote:
>> when git-clone was built in, its treatment of umask has changed: the shell
>> version respected umask for newly created directories by using pl
Hi list,
when git-clone was built in, its treatment of umask has changed: the shell
version respected umask for newly created directories by using plain mkdir(1),
and the builtin version just uses mkdir(work_tree, 0755).
Is it intentional?
This Stackoverflow question is what got me interested:
On 9/1/05, Sean <[EMAIL PROTECTED]> wrote:
> > BTW, did you sometimes notice lines you can't click at all?
> > An example is the red line on the most left side of the graph
> > by SHA 66129f88c4cc719591f687e5c8c764fe9d3e437a.
> For what it's worth, everything near that SHA1 works here as expected.
On 8/30/05, Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> Try now... :)
>
> It also makes the current graph line thicker now, so it's easier to
> pick out where the line you clicked on goes.
>
That's a fine feature :)
BTW, did you sometimes notice lines you can't click at all?
An example is th
On 8/29/05, Ben Greear <[EMAIL PROTECTED]> wrote:
> I think I'm missing something fundamental though... I wanted to
> change to the ben_dev_rfcnt branch to build a kernel without my
> additional patch. git branch ben_dev_rfcnt seems to change
> it fine, but all of the changes for repository 'foo'
On 8/23/05, Alex Riesen <[EMAIL PROTECTED]> wrote:
> On 8/17/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > NOTE! This does _not_ handle ".." or "." in the _middle_ of a pathspec. If
> > you have people who do
>
> BTW, could this (below) be
On 8/17/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> NOTE! This does _not_ handle ".." or "." in the _middle_ of a pathspec. If
> you have people who do
BTW, could this (below) be useful for something?
#include
#include
#include
// an analog of "cd path" from a directory "cwd".
char* pathe
On 4/18/05, randy_dunlap <[EMAIL PROTECTED]> wrote:
> Here's the beginnings of yet another git usage/howto/tutorial.
>
> It can grow or die... I'll gladly take patches for it,
> or Pasky et al can merge more git plumbing and toilet usages
> into it, with or without me.
>
> http://www.xenotime.net
On 4/15/05, Martin Schlemmer <[EMAIL PROTECTED]> wrote:
> > > + if (update_mode && changed & MODE_CHANGED)
> > > + chmod(ce->name, ce->st_mode);
> >
> > it's "if ((update_mode && changed) & MODE_CHANGED)"
> > Did you really mean that?
>
> No, '&' have a higher p
On 4/14/05, Martin Schlemmer <[EMAIL PROTECTED]> wrote:
> + if (update_mode && changed & MODE_CHANGED)
> + chmod(ce->name, ce->st_mode);
it's "if ((update_mode && changed) & MODE_CHANGED)"
Did you really mean that?
-alex
-
To unsubscribe from this list: send th
38 matches
Mail list logo
