if it does, it is probably a bug.
A more detailed reply is to your other email. I just wanted to clarify
that an undo _should not_ affect the staged content.
> secondary effect. As I only can revert in the worktree list, I think
> we should be consistent and also only allow to undo the revert in the
> worktree list.
>
> And I think it is independent of 'does the undo apply at all' question.
--
Regards,
Pratyush Yadav
On 22/10/19 10:17AM, Bert Wesarg wrote:
> On Mon, Oct 21, 2019 at 9:04 PM Pratyush Yadav wrote:
> >
> > On 21/10/19 11:16AM, Bert Wesarg wrote:
> > > Dear Pratyush,
> > >
> > > I just noticed that the 'Revert Last Hunk' menu entry is enabl
u think should not happen, correct? What's wrong
with allowing the user to undo reverts from anywhere?
The way I see it, it doesn't really matter what file is selected or
whether it is staged or not, the action of the undo remains the same, so
it makes sense to me to allow it from anyw
; Correct the quoting of .
>
> Detail the options for cloning a complete repo.
>
> Signed-off-by: Philip Oakley
Reminder: The email in your signoff and From are different [0].
[0] https://public-inbox.org/git/59958c50-cbcb-ae9b-614f-ba28221f41ed@iee.email/
--
Regards,
Pratyush Yadav
On 14/10/19 12:18AM, Johannes Schindelin wrote:
> Hi Pratyush,
>
> On Mon, 14 Oct 2019, Pratyush Yadav wrote:
>
> > On 12/10/19 11:24PM, Johannes Schindelin wrote:
> > > Hi Pratyush,
> > >
> > > On Sat, 12 Oct 2019, Pratyush Yadav wrote:
> > >
On 17/10/19 07:08AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> On Wed, Oct 16, 2019 at 9:28 PM Pratyush Yadav wrote:
> > I mentioned this earlier, and I'll mention this again: I'm not sure
> > whether this feature would be a good thing for the larger popu
he discussion was still ongoing. My bad
:)
> The patch itself looks good, and I also prefer the bit shift format over
> octal.
--
Regards,
Pratyush Yadav
e a good thing for the larger population. So
this _might_ not end up being accepted depending on how people react to
the proposal. I thought I'd let you know to avoid any nasty surprises
later.
--
Regards,
Pratyush Yadav
ick suggestion without
looking too much into the problem is to try putting the logic inside
`do_add_all` instead of inside the bind event handler.
> # -- Commit Message Buffer Context Menu
> #
> set ctxm .vpane.lower.commarea.buffer.ctxm
> --
> 2.23.0.windows.1
>
--
Regards,
Pratyush Yadav
e.
>
> static void emit_porcelain_details(struct blame_origin *suspect, int repeat)
> {
[0]
https://public-inbox.org/git/20191010115230.10623-1-wambui.karu...@gmail.com/
[1]
https://public-inbox.org/git/20191014182754.82302-1-jonathanta...@google.com/
[2] https://public-inbox.org/git/xmqqk19ag60g@gitster-ct.c.googlers.com/
--
Regards,
Pratyush Yadav
On 14/10/19 11:11PM, Philip Oakley wrote:
> On 14/10/2019 18:57, Pratyush Yadav wrote:
> > > list "refs/heads/MSVC-README" [list "commit"
> > > "056fb95c8e983ec07e9f5f8baa0b119bf3d13fed" [concat "" "Philip Oakley"]
> >
r "%s から %s をフェッチしています"
> > +msgstr "%2$s から %1$s をフェッチしています"
>
> Both of these changes to word order make sense.
>
> It's a bit surprising that these haven't been noticed/fixed for
> quite some time ;-).
Thanks for the review.
--
Regards,
Pratyush Yadav
posal: right now,
when I apply patches from contributors, I pass '-s' to 'am', so the
applied commit would have my sign-off. The way I see it, that sign-off
is supposed to signify that I have the right to push out the commit to
the "main" repo, just like the author's sign-off means that they have
the right to send me that commit.
Looking at git.git, I notice that Junio does the same. The new '--exact'
would be incompatible with '-s', correct (since the commit message has
changed, the SHA1 would also change)? So firstly, make sure you account
for something like that if you haven't already (I haven't found the time
to read your patches yet). Secondly, is it all right for the maintainer
to just not sign-off on the commits they push out?
--
Regards,
Pratyush Yadav
On 14/10/19 01:45PM, Philip Oakley wrote:
> Hi Pratyush,
> On 13/10/2019 19:50, Pratyush Yadav wrote:
> > Just to be sure it is a git-gui/Tcl issue and not an upstream
> > git.git
> > issue, can you run:
> >
> >fmt='list %(refname) [list %(objecttype
t
> @@ -956,7 +957,7 @@ msgstr "エラー: コマンドが失敗しました"
> #: lib/checkout_op.tcl:85
> #, tcl-format
> msgid "Fetching %s from %s"
> -msgstr "%s から %s をフェッチしています"
> +msgstr "%2$s から %1$s をフェッチしています"
>
> #: lib/checkout_op.tcl:133
> #, tcl-format
Thanks for the translation update. Will queue.
[0] https://github.com/prati0100/git-gui#using-gitgitgadget
--
Regards,
Pratyush Yadav
you.
> >
> > --
> > Signed-off-by: Kim Geonwoo (김건우)
> >
>
> Git GUI is a stand-alone project which is periodically merged to Git
> project by a subtree merge. According to the latest
> SubmittingPatches[1] documentation, git-gui is managed by Pratyush
> Yadav in a
+ show_diff $path $widget
> +}
> +
> proc toggle_commit_type {} {
> global commit_type_is_amend
> set commit_type_is_amend [expr !$commit_type_is_amend]
Other than that, looks good. There isn't much changed here. Just some
code moved around.
--
Regards,
Pratyush Yadav
don't, please let me know,
and I'll clarify.
Overall, I like the idea of the patch. This would move us one step in
the direction of customizable keybindings for _all_ shortcuts. Thanks.
>
> proc tools_exec {fullname} {
> ---
>
> @Johannes Schindelin: In short, from your previous message I understand point.
>
> 1. shortcut codes like "" will only in Windows platform. It may
> not work in Linux / Mac.
> 2. We need do translate shortcut codes somehow ( using one-to-one maping ).
>
> If this is correct, do you have any example on how to do one-to-one maping of
> a list of string on TCL ?
--
Regards,
Pratyush Yadav
Hi Harish,
Sorry for the late reply. Couldn't find much time last few days.
On 07/10/19 11:43AM, Harish Karumuthil wrote:
> Hi Pratyush, Regarding your messages,
>
> >On Sun, 2019-10-06 at 02:31 +0530, Pratyush Yadav wrote:
> > You don't need to "set up&quo
On 12/10/19 11:24PM, Johannes Schindelin wrote:
> Hi Pratyush,
>
> On Sat, 12 Oct 2019, Pratyush Yadav wrote:
>
> > On 08/10/19 04:33AM, Johannes Schindelin via GitGitGadget wrote:
> >
> > > @@ -1453,10 +1501,16 @@ proc rescan {after {honor_trustmtime 1}} {
>
On 12/10/19 09:34PM, Philip Oakley wrote:
> Hi Pratyus,
> On 08/10/2019 01:00, Pratyush Yadav wrote:
> > On 07/10/19 11:02PM, Philip Oakley wrote:
> > > I'd never used the Branch:Create before (this is via mouse) and it threw
> > > an
> > > error, whic
{
rescan ui_ready
prime_gitdir_cache
}
This would allow us to do these two things in parallel since `rescan` is
asynchronous. But that would also mean it is possible that the status
bar would show "Ready" while `prime_gitdir_cache` is still executing.
I can't really make up my mind on what is better. I'm inclining on using
the latter way, effectively trading a bit of UI inconsistency for
performance (at least in theory).
Thoughts?
> + array unset _gitdir_cache
> + prime_gitdir_cache
> + }
> +
> repository_state newType newHEAD newMERGE_HEAD
> if {[string match amend* $commit_type]
> && $newType eq {normal}
--
Regards,
Pratyush Yadav
I'll take the silence to mean there are no further objections, and will
merge this version in to 'master'.
On 08/10/19 05:47PM, Pratyush Yadav wrote:
> It is a good idea to have a readme so people finding the project can
> know more about it, and know how they can get invo
fix to "RFC PATCH"
instead of just "PATCH".
And yes, it is perfectly OK to send incomplete changes as long as you
mark them as such, and specify what you need help with.
But I see that you have already sent those patches. I'm not sure when I
can find time to tinker around with them, so it might take me a couple
of days to get to them.
--
Regards,
Pratyush Yadav
It is a good idea to have a readme so people finding the project can
know more about it, and know how they can get involved.
Signed-off-by: Pratyush Yadav
---
Changes in v3:
- Reword the first paragraph to avoid some repetition. Suggested by
Junio.
- Do not mention "written in Tcl&qu
[catch {
> && [catch {
> # beware that from the .git dir this sets _gitdir to .
> # and _prefix to the empty string
> - set _gitdir [git rev-parse --git-dir]
> + prime_gitdir_cache
> set _prefix [git rev-parse --show-prefix]
> } err]} {
> load_config 1
Can these paths we cache change while git-gui is running, say by a
command run by the user in the terminal? In that case, we should refresh
the list when the user rescans.
Other than some minor comments, looks good. Thanks.
--
Regards,
Pratyush Yadav
This is meant to produce a scriptlet that
can directly be `eval`ed.
So this might possibly me an upstream bug.
If I had to guess a fix, I'd suggest trying to wrap the $line in
lib/choose_rev.tcl:159 in quotes like so:
set line [eval "$line"]
If this doesn't fix it, see if you can find out which $line is causing
problem by printing the variable before 'eval'ing it by adding a:
puts "$line"
before the call to eval.
--
Regards,
Pratyush Yadav
On 07/10/19 10:39AM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
> > -+# Git Gui - A graphical user interface for Git
> > ++# Git GUI - A graphical user interface for Git
> > +
> > -+Git Gui is a GUI for [git](https://git-scm.com/) wri
It is a good idea to have a readme so people finding the project can
know more about it, and know how they can get involved.
Signed-off-by: Pratyush Yadav
---
Changes in v2:
- s/Gui/GUI/g suggested by Johannes.
- s/git/Git/ wherever applicable suggested by Johannes.
- Clarify that there is
On 06/10/19 10:27PM, Johannes Schindelin wrote:
> Hi Pratyush,
>
> On Mon, 7 Oct 2019, Pratyush Yadav wrote:
>
> > On 06/10/19 11:49AM, Johannes Schindelin wrote:
> > > Hi Pratyush,
> > >
> > > On Sun, 6 Oct 2019, Pratyush Yadav wrote:
> > >
On 06/10/19 11:49AM, Johannes Schindelin wrote:
> Hi Pratyush,
>
> On Sun, 6 Oct 2019, Pratyush Yadav wrote:
>
> > On 06/10/19 01:46AM, Harish Karumuthil wrote:
> > >
> > > From https://www.kernel.org/doc/html/v4.10/process/email-clients.html, I
> >
On 05/10/19 12:51PM, Bert Wesarg wrote:
> On Sat, Oct 5, 2019 at 12:10 AM Pratyush Yadav wrote:
> > +# Contributing
> > +
> > +The project is currently maintained by Pratyush Yadav over at
> > +https://github.com/prati0100/git-gui. Even though the project is hosted at
&
Hi Johannes,
On 05/10/19 09:56PM, Johannes Schindelin wrote:
> Hi Pratyush,
>
> On Sat, 5 Oct 2019, Pratyush Yadav wrote:
>
> > It is a good idea to have a readme so people finding the project can
> > know more about it, and know how they can get involved.
> >
>
format-patch -o feature master..HEAD`,
assuming your feature branch is checked out. This will give you a set of
'.patch' files depending on how many commits you made in your branch in
the folder feature/. Then, you can run
git send-email --to='Pratyush Yadav '
--cc=&#x
Signed-off-by: Pratyush Yadav
---
Changes in v2:
- Only link the repo, instead of having instructions to "clone" and
"browse online".
Do note that I am using single quotes around git gui instead of
backticks like you suggested because the rest of the man page does the
same
Signed-off-by: Pratyush Yadav
---
Documentation/git-gui.txt | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index 5f93f8003d..98337b69f1 100644
--- a/Documentation/git-gui.txt
+++ b/Documentation/git-gui.txt
It is a good idea to have a readme so people finding the project can
know more about it, and know how they can get involved.
Signed-off-by: Pratyush Yadav
---
I don't have much experience writing this kind of readme or
documentation, so comments are appreciated. Please feel free to chi
On 01/10/19 07:38PM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 1 Oct 2019, Pratyush Yadav wrote:
>
> > On 30/09/19 11:42AM, Johannes Schindelin wrote:
> > > On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > > > On 27/09/19 08:10AM, Bert Wesarg wrote:
>
-posted).
Maybe because I included the references in the middle of the text you
thought the message was over (understandably so. I probably shouldn't do
that), and didn't scroll till the end to read the rest of the message.
Or maybe I don't know something about email etiquette that
, this should read "a/lib/tools.tcl" instead of
"a/git-gui/lib/tools.tcl".
I haven't looked at the contents of the patch because I can't apply it,
and I'd prefer to tinker around with it before commenting. So please
re-send the patch in the proper format and we can discuss the
implementation :).
> index 413f1a1700..40db3f6395 100644
> --- a/git-gui/lib/tools.tcl
> +++ b/git-gui/lib/tools.tcl
[snip]
--
Regards,
Pratyush Yadav
On 03/10/19 09:02PM, Philip Oakley wrote:
> On 30/09/2019 13:17, Bert Wesarg wrote:
> > Pratyush,
> >
> > On Sun, Sep 29, 2019 at 5:04 PM Pratyush Yadav
> > wrote:
> > > Hi Philip, Bert,
> > >
> > > Is there any way I can test this cha
it is
> + # normally shown as 'added', invert
> this to '--' to make
> + # it a 'removed' line
> + set line [string replace $line 0 1 {--}]
> + set tags d_--
> } else {
> set tags d_++
> }
--
Regards,
Pratyush Yadav
On 26/09/19 11:13PM, Johannes Sixt wrote:
> Am 26.09.19 um 21:15 schrieb Pratyush Yadav:
> > Reading the Stackoverflow link, it seems this is already possible via an
> > undocumented config variable "gui.gcwarning". I haven't tried using it
> > though, bu
On 01/10/19 09:46AM, Denton Liu wrote:
> Hi Pratyush,
>
> On Tue, Oct 01, 2019 at 07:44:35PM +0530, Pratyush Yadav wrote:
> > Since I have taken over maintainership of git-gui, it is a good idea to
> > point new contributors to my fork of the project, so they can see the
>
On 01/10/19 05:22PM, Bert Wesarg wrote:
> On Tue, Oct 1, 2019 at 4:24 PM Pratyush Yadav wrote:
> >
> > Hi,
> >
> > I don't see any difference between v3 and v2 of this patch. What changed
> > in this version?
>
> nothing, but 2/2 changed.
I don'
set conflict_size [gitattr $path conflict-marker-size 7]
>
> set cmd [list]
> if {$w eq $ui_index} {
> --
> 2.23.0.11.g242cf7f110
>
--
Regards,
Pratyush Yadav
Since I have taken over maintainership of git-gui, it is a good idea to
point new contributors to my fork of the project, so they can see the
latest version of the project.
Signed-off-by: Pratyush Yadav
---
Documentation/SubmittingPatches | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
y different email address.
I'm not sure if I can do something about it, just thought it was
something worth mentioning.
--
Regards,
Pratyush Yadav
On 30/09/19 11:42AM, Johannes Schindelin wrote:
> On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > On 27/09/19 08:10AM, Bert Wesarg wrote:
> > > On Fri, Sep 27, 2019 at 12:40 AM Pratyush Yadav
> > > wrote:
> > > > gitdir is used in a lot of places, an
On 30/09/19 12:27PM, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 27 Sep 2019, Pratyush Yadav wrote:
>
> > On 26/09/19 10:46AM, Thomas Klaeger via GitGitGadget wrote:
> > > From: Thomas Klaeger
> > >
> > > Git for Windows 2.x ships with an executabl
set icopath [file dirname $icopath]
> + }
> + set icopath [file dirname $icopath]
> + set icopath [file join $icopath share git git-for-windows.ico]
> + if {[file exists $icopath]} {
> + wm iconbitmap . -default $icopath
> + }
> +}
> +
> wm title . $title
> tk::PlaceWindow .
> --
> gitgitgadget
--
Regards,
Pratyush Yadav
n't really make too much of a difference for
something this simple.
> + set title [lindex $argv 1]
> + set argv [lreplace $argv 0 1]
> + }
> set prompt [join $argv " "]
> }
>
> @@ -47,5 +52,5 @@ proc yes {} {
> exit 0
> }
>
> -wm title . "Question?"
> +wm title . $title
> tk::PlaceWindow .
> --
> gitgitgadget
>
--
Regards,
Pratyush Yadav
uot;] >= 0}]
> if {![info exists env(SSH_ASKPASS)]} {
> set env(SSH_ASKPASS) [gitexec git-gui--askpass]
> }
> +if {![info exists env(GIT_ASKPASS)]} {
> + set env(GIT_ASKPASS) [gitexec git-gui--askpass]
> +}
> if {![info exists env(GIT_ASK_YESNO)]} {
> se
/git-gui.sh b/git-gui.sh
> index f9b323abff..76d8139b8d 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -1248,6 +1248,9 @@ set have_tk85 [expr {[package vcompare $tk_version
> "8.5"] >= 0}]
> if {![info exists env(SSH_ASKPASS)]} {
> set env(SSH_ASKPASS) [gitexec git-gui--askpass]
> }
> +if {![info exists env(GIT_ASK_YESNO)]} {
> + set env(GIT_ASK_YESNO) [gitexec git-gui--askyesno]
> +}
Since this seems to be a Windows-only variable, you might want to enable
it only on Windows. Are there workflows on other platforms that would
use this environment variable?
--
Regards,
Pratyush Yadav
gt; @@ -505,6 +524,9 @@ proc read_diff {fd conflict_size cont_info} {
> }
> }
> set mark [$ui_diff index "end - 1 line linestart"]
> + if {[llength $markup] > 0} {
> + set tags {}
> + }
> $ui_diff insert end $line $tags
> if {[string index $line end] eq "\r"} {
> $ui_diff tag add d_cr {end - 2c}
> --
> 2.21.0.789.ga095d9d866
>
--
Regards,
Pratyush Yadav
On 27/09/19 08:10AM, Bert Wesarg wrote:
> On Fri, Sep 27, 2019 at 12:40 AM Pratyush Yadav
> wrote:
> >
> > Hi,
> >
> > On 26/09/19 02:17PM, Johannes Schindelin via GitGitGadget wrote:
> > > From: Johannes Schindelin
> > >
> > > Since v
c start_show_diff {cont_info {add_opts {}}} {
> set is_submodule_diff 0
> set diff_active 1
> set current_diff_header {}
> - set conflict_size [get_conflict_marker_size $path]
> + set conflict_size [gitattr $path conflict-marker-size 7]
>
> set cmd [list]
> if {$w eq $ui_index} {
> --
> 2.21.0.789.ga095d9d866
>
--
Regards,
Pratyush Yadav
On 26/09/19 08:44PM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 24 Sep 2019, Pratyush Yadav wrote:
>
> > On 23/09/19 09:35PM, Johannes Schindelin wrote:
> > > Hi,
> > >
> > > On Wed, 18 Sep 2019, Junio C Hamano wrote:
> > >
> > > &
dea to move
this to the procedure gitdir. It would have to be refactored to take any
number of arguments, instead of the two it takes here.
Other than that, looks good. Thanks.
--
Regards,
Pratyush Yadav
t all easy to understand what's going on at first look.
Is there no better way of finding out git-bash's location? Is there
something like the PATH environment variable in Windows that we can use
to locate git-bash's executable? I have never developed in Windows so I
have no idea how things work there.
On Linux for example, the exec() family of functions look into the PATH
environment variable for the executable, so it is a pretty clean
mechanism to execute programs.
--
Regards,
Pratyush Yadav
Did you try binding a script to the FocusIn event of the commit message
buffer? You can do this like:
bind $ui_comm {your_script}
I'm not sure if $ui_comm is the correct widget, but you can experiment a
bit by printing something in your_script to find out for sure.
--
Regards,
Pratyush Yadav
his?
Talking about auto compression, would it be a better idea to let users
disable the dialog, and then if they do want auto compression, they can
just run a cron job (or the Windows equivalent) to do this on their
repos? What reasons do people have to have this feature in git-gui,
instead of running cron jobs?
--
Regards,
Pratyush Yadav
s commit was one of those. Junio directly merged this commit into
git/git-gui, along with some other stuff from Johannes in the commit
02a5f25d95 (Merge branch 'js/misc-git-gui-stuff' of ../git-gui) of
git.git.
[0]
https://public-inbox.org/git/CAGr--=kxqfbivuxhpnecb3dbr_hx8qqwor4pbgxy7uoit+e...@mail.gmail.com/
--
Regards,
Pratyush Yadav
rather than being separated.
> >
> > I opened a Git for Windows issue
> > https://github.com/git-for-windows/git/issues/2340 which has the
> > screenshot of the git-gui markers.
> >
> > I've not had any chance to look at the underlying code, but thought it
> > worth reporting. I guess the issue has been there a while.
--
Regards,
Pratyush Yadav
closed discussion would be much
more prone to power abuse, if any.
> I'm okay with leaving it open for now but I think I would be a lot more
> comfortable if we had the interpretations document to close up the
> vagueness later.
--
Regards,
Pratyush Yadav
On 19/09/19 12:11PM, Denton Liu wrote:
> On Fri, Sep 20, 2019 at 12:33:59AM +0530, Pratyush Yadav wrote:
> > On 19/09/19 11:47AM, Denton Liu wrote:
> > > For the record, you could do a
> > >
> > > git cherry-pick -Xsubtree=git-gui 00ddc9d13c 7560f547e6
> &
gui/pulls. Pratyush, do
> you accept contributions in this form, or should I do anything
> differently?
I prefer email. Also, please Cc this list so other people interested in
git-gui can take a look.
--
Regards,
Pratyush Yadav
On 19/09/19 11:47AM, Denton Liu wrote:
> On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote:
> > Hi Junio,
> >
> > On 18/09/19 10:49AM, Junio C Hamano wrote:
> > > Pratyush Yadav writes:
> > > You should be able to merge this (and all other
Hi Junio,
On 18/09/19 10:49AM, Junio C Hamano wrote:
> Pratyush Yadav writes:
> You should be able to merge this (and all other git-gui topics
> already in my tree Denton pointed out) to your 'master'. If you
> then make a trial merge of the result back into my tree with
a to do so.
> - remove duplicated bind entries, if a key is bound to "all" then it
> shouldn't be bound with another tag
>From my quick scan of the search results for "bind", the only keys bound
to "all" are "Q" and "W". "Q" quits the entire application, and "W"
closes the current toplevel window. Both should stay the way they are.
As for duplicated bindings for ".", and other widgets, that is something
I haven't looked into too well. I will get to it by tomorrow.
[0] https://www.tcl.tk/man/tcl8.4/TkCmd/bind.htm
--
Regards,
Pratyush Yadav
On 18/09/19 10:49AM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
> > Assuming I have git.git cloned in ../git (relative to git-gui.git), I
> > ran:
> >
> > git pull -Xsubtree=git-gui ../git $branches
> >
> > instead of:
> >
> > git
commit that is missing: 492595cfc7 (git-gui (MinGW): make use of
MSys2's msgfmt, 2017-07-25)
This commit is comes from the merge of js/msgfmt-on-windows, which has
all the commits from the merge 5ab7227 (Merge remote-tracking branch
'philoakley/dup-gui', 2017-03-18)
in git-gui.
While merging js/msgfmt-on-windows should get this commit into git-gui,
I'd rather have it separate,
>
> Hope any of this is useful to anyone,
It is very useful. Thanks :)
--
Regards,
Pratyush Yadav
gui: add hotkey to toggle "Amend Last Commit"
Pratyush Yadav (9):
git-gui: allow reverting selected lines
git-gui: allow reverting selected hunk
git-gui: return early when patch fails to apply
git-gui: allow undoing last revert
Merge branch 'bp/widget-focu
On 15/09/19 09:55AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> On Sat, Sep 14, 2019 at 11:15 PM Pratyush Yadav
> wrote:
> > Why should it only happen when the commit message widget is selected?
> > What's wrong with directly switching focus when
On 15/09/19 01:41PM, David wrote:
> On Sun, 15 Sep 2019 at 05:08, Pratyush Yadav wrote:
> > On 15/09/19 02:07AM, David wrote:
> > > On Sat, 14 Sep 2019 at 06:51, Bert Wesarg
> > > wrote:
>
> > > > I consider adding a second way as not not acceptable.
ur local branch. So if you do a `git pull`, developer A's changes are
now merged into your tree. But if you only do a fetch, origin/master
gets updated, but not your local master. So now status can know how far
you are behind, but your local branch is not changed yet.
Once you are ready to finally get those changes in your local branch,
run `git merge origin/master`.
--
Regards,
Pratyush Yadav
On 15/09/19 02:45AM, Pratyush Yadav wrote:
> On 14/09/19 02:24PM, Birger Skogeng Pedersen wrote:
> > Hi everyone,
> >
> >
> > I personally prefer to have the changes I am about to commit visible
> > in the diff view, while I write my commit message. So usuall
On 15/09/19 01:57AM, David wrote:
> On Sat, 14 Sep 2019 at 08:07, Marc Branchaud wrote:
> > On 2019-09-13 10:32 a.m., Pratyush Yadav wrote:
> > > On 13/09/19 12:24PM, Allan Ford wrote:
>
> > >> Not a bug, but a suggestion consideration for “Git Gui”
>
> &
ses the "Commit Message" widget, if no file is
> currently selected (i.e. diff widget shows no text))
> automatically select the first file listed in the "Staged Changes"
> widget so the changes of that file show up in the diff widget.
--
Regards,
Pratyush Yadav
On 15/09/19 02:07AM, David wrote:
> On Sat, 14 Sep 2019 at 06:51, Bert Wesarg wrote:
> > On Fri, Sep 13, 2019 at 4:32 PM Pratyush Yadav
> > wrote:
> > > On 13/09/19 12:24PM, Allan Ford wrote:
> >
> > I miss a general problem description: Whats wrong with
-minus> {show_less_context;break}
> bind . <$M1B-Key-KP_Subtract> {show_less_context;break}
> bind . <$M1B-Key-equal> {show_more_context;break}
> --
> 2.21.0.windows.1
>
--
Regards,
Pratyush Yadav
On 14/09/19 09:33AM, Paul Mackerras wrote:
> On Fri, Aug 30, 2019 at 12:02:07AM +0530, Pratyush Yadav wrote:
> > On 29/08/19 11:27AM, Paul Mackerras wrote:
> >
> > I know I suggested searching till the first non-whitespace character,
> > but thinking more about, there
+Cc Junio so you know what development model I'm using, and comment with
your thoughts (if you want to).
On 13/09/19 11:32PM, Birger Skogeng Pedersen wrote:
> On Fri, Sep 13, 2019 at 4:37 PM Pratyush Yadav wrote:
> > Hi Birger,
> >
> > I'm afraid you are work
On 13/09/19 10:27PM, Bert Wesarg wrote:
> On Fri, Sep 13, 2019 at 4:32 PM Pratyush Yadav wrote:
> >
> > On 13/09/19 12:24PM, Allan Ford wrote:
> > > Dear Git Authors,
> > >
> > > Not a bug, but a suggestion consideration for “Git Gui”
> > &g
bottom -fill x
> pack .vpane.lower.commarea.buffer.frame.sby -side right -fill y
> pack $ui_comm -side left -fill y
> pack .vpane.lower.commarea.buffer.header -side top -fill x
> --
> 2.21.0.789.ga095d9d866
>
--
Regards,
Pratyush Yadav
ed-off-by: Bert Wesarg
--
Regards,
Pratyush Yadav
r.commarea.buffer.frame -side left -fill y
> +pack .vpane.lower.commarea.buffer.frame -side bottom -fill both -expand 1
I'm not too familiar with pack, but why change the side from left to
bottom? I tested by changing it back to left and it doesn't seem to make
a difference.
> pack .vpane.lower.commarea.buffer -side left -fill y
>
> # -- Commit Message Buffer Context Menu
> --
> 2.21.0.789.ga095d9d866
>
--
Regards,
Pratyush Yadav
ps Lock on? I personally use it so rarely I have
my Caps Lock bound to Escape because I might as well use that key for
something I use more often.
[0] https://blog.tcl.tk/4238
--
Regards,
Pratyush Yadav
On 12/09/19 09:35PM, Bert Wesarg wrote:
> On Wed, Sep 11, 2019 at 10:15 PM Pratyush Yadav
> wrote:
> >
> > Typo in the subject. s/checketton/checkbutton/
> >
> > On 05/09/19 10:09PM, Bert Wesarg wrote:
> > > diff --git a/lib/index.tcl b/lib/index.
t; lappend disable_on_lock \
> @@ -3837,6 +3866,8 @@ bind . <$M1B-Key-j> do_revert_selection
> bind . <$M1B-Key-J> do_revert_selection
> bind . <$M1B-Key-i> do_add_all
> bind . <$M1B-Key-I> do_add_all
> +bind . <$M1B-Key-e> toggle_commit_type
> +bind . <$M1B-Key-E> toggle_commit_type
> bind . <$M1B-Key-minus> {show_less_context;break}
> bind . <$M1B-Key-KP_Subtract> {show_less_context;break}
> bind . <$M1B-Key-equal> {show_more_context;break}
> --
> 2.21.0.windows.1
>
--
Regards,
Pratyush Yadav
who are already used to it.
Is partial single and partial double click behaviour acceptable? Or
should we make the entire row double click only? Or something else that
I missed?
--
Regards,
Pratyush Yadav
On 12/09/19 08:05AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> On Wed, Sep 11, 2019 at 10:55 PM Pratyush Yadav
> wrote:
> > Also, I notice that the bindings for other letters have the same
> > function bound for both small and capital letters (IOW, same behavior
ir] {
> bind $i { toggle_or_diff click %W %x %y; break }
> bind $i <$M1B-Button-1> { add_one_to_selection %W %x %y; break }
Overall, the patch LGTM apart from a couple of nitpicks above. Thanks.
--
Regards,
Pratyush Yadav
ays_ be amend*,
and if $commit_type_is_amend == 1, then $commit_type should _never_ be
amend*.
I don't see assertions being used anywhere, but I suppose we should look
into them in the future. It would be great if you can start using
something like that here, but I'm fine with keeping this like it is
right now too.
> load_last_commit
>
> # The amend request was rejected...
> #
> if {![string match amend* $commit_type]} {
> - set selected_commit_type new
> + set commit_type_is_amend 0
> }
> }
> }
I tested it on my setup and it works fine. Thanks.
--
Regards,
Pratyush Yadav
On 12/09/19 12:04AM, Pratyush Yadav wrote:
> On 11/09/19 12:27PM, Birger Skogeng Pedersen wrote:
> > Hi Pratyush,
> >
> > I'm hoping this will be merged, even without changing the radio
> > selectors to a checkbox(?). The patch from Bert resolves the issue I
>
e based on the discussion, but I don't think
it should affect your change too much.
[0] https://public-inbox.org/git/20190904175943.11924-1-birger...@gmail.com/
[1]
https://public-inbox.org/git/ab1f68cc8552e405c9d04622be1e728ab81bda17.1567713659.git.bert.wes...@googlemail.com/
--
Regards,
Pratyush Yadav
On 11/09/19 08:49AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> On Tue, Sep 10, 2019 at 9:12 PM Pratyush Yadav wrote:
> > This patch LGTM, but I'm not sure how to resolve the keybindings
> > problem. Junio suggested we have configurable keybindings, and I agree
x27;t mind if I only take
the scrollbar change and drop this.
--
Regards,
Pratyush Yadav
.vpane.lower.commarea.buffer -side left -fill y
>
> # -- Commit Message Buffer Context Menu
Other than these couple of minor things, the patch LGTM. Thanks.
--
Regards,
Pratyush Yadav
which is what the user
> would likely expect even though the visual wrapping is smaller.
>
> We also special-case trailers like "Signed-off-by:" and other common
> trailers since user names can get long, and users sometimes use things
> like "See-also:" and paste a long URL that we don't want to wrap.
Nice catch! Didn't think of that.
> Lastly, we have a convenient session-only checkbox to temporarily
> disable
> wrapping for a commit that does not persist across restarts. The idea
> is that sometimes you might use the GUI for a one-off commit where you
> want to disable the wrapping for whatever reason, but don't want to
> change your configuration.
Sounds like a good idea, but I wonder how we can fit it into git-gui's
current UI layout.
--
Regards,
Pratyush Yadav
1 - 100 of 189 matches
Mail list logo
