Just like the user can select lines to stage or unstage, add the
ability to revert selected lines.
Signed-off-by: Pratyush Yadav
---
git-gui.sh | 25 -
lib/diff.tcl | 20 ++--
2 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/git-gui.sh b
Just like the user can select a hunk to stage or unstage, add the
ability to revert hunks.
Signed-off-by: Pratyush Yadav
---
git-gui.sh | 14 +-
lib/diff.tcl | 21 -
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index
-by: Pratyush Yadav
---
git-gui.sh | 18 +-
lib/diff.tcl | 53
2 files changed, 66 insertions(+), 5 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 1592544..e03a2d2 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1350,6
Hi,
This series adds the ability to revert selected lines and hunks in
git-gui. Partially based on the patch by Bert Wesarg [0].
The commits can be found in the topic branch 'py/revert-hunks-lines'
at https://github.com/prati0100/git-gui/tree/py/revert-hunks-lines
Changes in v3:
; Signed-off-by: Elijah Newren
> > ---
> > diff --git a/Documentation/git-filter-branch.txt
> > b/Documentation/git-filter-branch.txt
> > @@ -16,6 +16,20 @@ SYNOPSIS
> > +WARNING
> > +---
> > +'git filter-branch' has a plethora of pitfalls th
Hi, all:
If I know that a project uses tag signing, would "git clone" followed by
"git verify-tag" be meaningful without a "git fsck" in-between? I.e. if
an attacker has control over the remote server, can they sneak in any
badness into any of the resulting
h the author you want to change are among
> the commits that are unique to that branch and so the distinction
> doesn't matter, but it wasn't clear from the description.)
Yes, this is exactly the case for me, as I'm changing entirely linear
topic branch that is going to become
Hi Sergey,
On Wed, Aug 28, 2019 at 1:52 AM Sergey Organov wrote:
>
> Elijah Newren writes:
>
> > On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
> >>
> >> Eric Wong writes:
> >>
> >>
> >> [...]
> >>
> >&
Johannes Schindelin writes:
>> Ah, so "add.usebuiltin = interactive patch" can (eventually) choose
>> to use the C code for both while "add.usebuiltin = interactive"
>> would not use it for the patch mode, or something? Or even
>>
>> add.interactive.usebuiltin = yes
>
> This is what I had i
Johannes Schindelin writes:
> FWIW if anybody cares about my opinion: I would be totally fine with
> integrating git-filter-repo into git.git, have it there for a major
> version or two, then patch `git filter-branch` to spew out a deprecation
> warning, and then remove that latt
Hi Junio,
On Tue, 27 Aug 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Besides, I really hope that this would be only temporary,...
>
> Oh, no question about it. This should be temporary knob.
>
> I still do worry about giving a bad example for others to copy.
> People tend to
the first time GitGitGadget sent it, it did not get through (only the
cover letter did).
So I tried to fix the screw-up by sending manually, and screwed it up
even more.
Sorry about that.
Dscho
>
> Git Gadget writes:
>
> > From: "Philip.McGraw"
> > ...
>
Hi Elijah,
On Fri, 23 Aug 2019, Elijah Newren wrote:
> On Thu, Aug 22, 2019 at 8:01 PM Eric Wong wrote:
> >
> > Elijah Newren wrote:
> > > * Remove git-filter-branch from git.git. Mention in the release
> > > notes where people can go to get it.[1]
> >
gt; > >
> > > to see the loose ones. If there are a lot, try:
> > >
> > > git pack-refs --prune --all
> > >
> > > (or just "git gc", which does this).
> >
> > This is a daily updated mirror that is also incrementally back
Elijah Newren writes:
> On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
>>
>> Eric Wong writes:
>>
>>
>> [...]
>>
>> > AFAIK, filter-branch is not causing support headaches for any
>> > git developers today. With so many command
We're coming up on when Python2 is end-of-lifed - we have until
January 1st 2020.
git-p4 uses python2, and doesn't work under python3 at all.
The problem is the conversions between Python3 unicode strings and git
(utf-8) and p4 (utf-8, except when it isn't).
I had a go at f
On Tue, 27 Aug 2019 at 23:31, Junio C Hamano wrote:
>
> Andrey Mazo writes:
>
> > From: "Philip.McGraw"
> >
> > Avoid double-open exceptions on Windows platform when
> > calculating for lfs compressed size threshold
> > (git-p4.largeFileC
On Tue, Aug 27, 2019 at 8:22 PM Elijah Newren wrote:
> filter-branch suffers from a deluge of disguised dangers that disfigure
> history rewrites (i.e. deviate from the deliberate changes). [...]
>
> Signed-off-by: Elijah Newren
> ---
> diff --git a/Documentation/git-filt
git-filter-branch still exists, still has the same regression tests,
etc., but it is now being tracked in a separate repo that users will
need to download separately.
Signed-off-by: Elijah Newren
---
.gitignore | 1 -
Documentation/git-filter-branch.txt | 464
Here's a series that shifts the focus slightly to warning about
git-filter-branch usage and avoiding it ourselves. I have retained
patch 4 but left it marked as RFC for further discussion. It appears
that folks generally seem to agree the first three patches are good
to include now -- ass
it seems like I would need to
provide some kind of comparison and I would ultimately just say that
filter-repo can do everything BFG can, so ultimately it seems that it
is just better to remove that section altogether.
Signed-off-by: Elijah Newren
---
Documentation/git-fast-export.txt | 6 ++--
Andrey Mazo writes:
> From: "Philip.McGraw"
>
> Avoid double-open exceptions on Windows platform when
> calculating for lfs compressed size threshold
> (git-p4.largeFileCompressedThreshold) comparisons.
>
> Take new approach using the NamedTemporaryFile()
>
I have put up a demo repo here: https://github.com/dniku/git-external-diff-argv
On Tue, 27 Aug 2019 at 21:24, Dmitry Nikulin wrote:
>
> I wrote a very simple Python script to see which arguments git-diff
> passes to the external diff program when comparing files across
> branche
Johannes Schindelin writes:
> Besides, I really hope that this would be only temporary,...
Oh, no question about it. This should be temporary knob.
I still do worry about giving a bad example for others to copy.
People tend to copy & paste without thinking. Either we come up
with and use a tw
On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
>
> Eric Wong writes:
>
>
> [...]
>
> > AFAIK, filter-branch is not causing support headaches for any
> > git developers today. With so many commands in git, it's
> > unlikely newbies will ever ge
On Tue, Aug 27, 2019 at 2:32 PM Uwe Kleine-König
wrote:
>
> On Tue, Aug 27, 2019 at 02:59:30PM -0400, Jeff King wrote:
> > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:
> >
> > to see the loose ones. If there are a lot, try:
> >
> > git
On Tue, Aug 27, 2019 at 02:59:30PM -0400, Jeff King wrote:
> On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:
>
> > $ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time env
> > GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonex
Albert Vaca Cintora writes:
> It "works" for some definition of work, but it asks for confirmation
> for every file, which is a pain. I'm on Linux.
Ah, your "rm" command needs to learn "-f" option, too, then?
On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:
> $ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time env
> GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git
> --no-pager show --no-color --no-decorate v5.2
> ...
&g
Hi Saravanan,
On Mon, Aug 26, 2019 at 08:43:34PM +, Saravanan Shanmugham (sarvi) wrote:
>
> Based on a previous thread “First Git status takes 40+ minutes, when mounting
> fileystem/diskimage with 50G GIT repo + 900G of builds articles”
>
> The context is that
> 1. git
I wrote a very simple Python script to see which arguments git-diff
passes to the external diff program when comparing files across
branches:
$ env GIT_EXTERNAL_DIFF=./print_argv.py git diff
origin/branch1:file1.txt origin/branch2:file2.txt
['./print_argv.py',
'file1.txt',
Any suggestion or advice how to optimize this in GIT ?
Thanks,
Sarvi
Occam’s Razor Rules
On 8/26/19, 1:43 PM, "Saravanan Shanmugham (sarvi)" wrote:
Based on a previous thread “First Git status takes 40+ minutes, when
mounting fileystem/diskimage with 50G GIT repo + 900G
Changes from v1
===
* Use gmake
* Use sh
* Remove dependencies to Plan 9 tools; rc and mk
What I did
==
I ported git, and git subcommands with gmake to Plan 9. This pull request
contains patches for existing codes, and new files to build git in Plan 9.
I added three new
This is the first leg on the long journey to a fully built-in git add -i
(next up: parts 2 [https://github.com/gitgitgadget/git/pull/171], 3
[https://github.com/gitgitgadget/git/pull/172], 4
[https://github.com/gitgitgadget/git/pull/173], 5
[https://github.com/gitgitgadget/git/pull/174], and 6
From: Johannes Schindelin
This is hardly the first conversion of a Git command that is implemented
as a script to a built-in. So far, the most successful strategy for such
conversions has been to add a built-in helper and call that for more and
more functionality from the script, as more and
On Tue, 27 Aug 2019 12:56:38 +0200
Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Aug 27, 2019 at 12:33:09PM +0200, SZEDER Gábor wrote:
> > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:
> > > I'm a bit surprised that the default for --decorate depends on the
> > > out
Hello,
On Tue, Aug 27, 2019 at 12:33:09PM +0200, SZEDER Gábor wrote:
> On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:
> > I'm a bit surprised that the default for --decorate depends on the
> > output being a terminal.
>
> Decorations (and colors as well) are for humans, and hum
On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:
> I'm a bit surprised that the default for --decorate depends on the
> output being a terminal.
Decorations (and colors as well) are for humans, and humans read the
terminal.
> Thanks for your help, I will think about what I want t
On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:
> > > > > I have a problem here with git being slow in some situations.
> > > > > Using git 2.23.0 (from Debian) the effect is:
> > > > >
> > > > > u...@dude.ptx:/ptx/src/gi
gt; I have a problem here with git being slow in some situations.
> > > > Using git 2.23.0 (from Debian) the effect is:
> > > >
> > > > u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 >
> > > > /proc/sys/vm/drop_caches"; time
On Tue, 2019-08-27 at 10:56 +0200, Uwe Kleine-König wrote:
> On Tue, Aug 27, 2019 at 10:41:11AM +0200, SZEDER Gábor wrote:
> > On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:
> > > I have a problem here with git being slow in some situations.
> > > Us
On Tue, Aug 27, 2019 at 10:41:11AM +0200, SZEDER Gábor wrote:
> On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:
> > I have a problem here with git being slow in some situations.
> > Using git 2.23.0 (from Debian) the effect is:
> >
> > u...@dude.ptx:/
Eric Wong writes:
[...]
> AFAIK, filter-branch is not causing support headaches for any
> git developers today. With so many commands in git, it's
> unlikely newbies will ever get around to discover it :)
> So I think think we should be in any rush to remove it.
Nah, discove
On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:
> I have a problem here with git being slow in some situations.
> Using git 2.23.0 (from Debian) the effect is:
>
> u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 >
> /proc/sys/vm/drop_caches&quo
Hello,
I have a problem here with git being slow in some situations.
Using git 2.23.0 (from Debian) the effect is:
u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 >
/proc/sys/vm/drop_caches"; time git show v5.2
tag v5.2
...
real0m12.727s
user0m0.300s
sys 0m0
noticed? (I haven't been paying too
much attention, though)
> * Patch 5: actually deletes git-filter-branch, its tests, and
> documentation.
Given how long we've had git-filter-branch, I suggest we keep it
around but add a warning at runtime notifying users of it's
impending
On Mon, Aug 26, 2019 at 6:33 PM Derrick Stolee wrote:
>
> On 8/26/2019 7:52 PM, Elijah Newren wrote:
> > +WARNING
> > +---
> > +'git filter-branch' has a litany of gotchas that can and will cause
> > +history to be rewritten incorrectly (in addit
On Mon, Aug 26, 2019 at 6:39 PM Derrick Stolee wrote:
>
> On 8/26/2019 7:52 PM, Elijah Newren wrote:
> > Following up on the suggestion to make git.git smaller and shed non-core
> > tools, here's an RFC series to do so with git-filter-branch. This
> > series firs
Do we have interested mentors for the next round of Outreachy?
The deadline for Git to apply to the program is September 5th. The
deadline for mentors to have submitted project descriptions is September
24th. Intern applications would start on October 1st.
If there are mentors who want to
In git-format-patch.txt, we were missing some key user information.
First of all, document the special value of `--base=auto`.
Next, while we're at it, surround option arguments with <> and change
existing names such as "Message-Id" to "message id", which conforms
Currently, there are two ways where the return codes of Git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no
Quoth the git-remote-helpers man page:
"If option check-connectivity is requested, the helper must output
connectivity-ok if the clone is self-contained and connected."
I tried doing that in a helper, but I still got a connectivity check.
Looking at the code, it looks like this only
From: "Philip.McGraw"
Avoid double-open exceptions on Windows platform when
calculating for lfs compressed size threshold
(git-p4.largeFileCompressedThreshold) comparisons.
Take new approach using the NamedTemporaryFile()
file-like object as input to the ZipFile() which
auto-del
On 8/26/2019 7:52 PM, Elijah Newren wrote:
> Following up on the suggestion to make git.git smaller and shed non-core
> tools, here's an RFC series to do so with git-filter-branch. This
> series first removes dependencies on git-filter-branch (of which there
> were very few), and
filter-repo can do everything BFG can, so ultimately it seems that it
> is just better to remove that section altogether.
>
> Signed-off-by: Elijah Newren
> ---
> Documentation/git-fast-export.txt | 6 ++---
> Documentation/git-filter-branch.txt | 42 -
On 8/26/2019 7:52 PM, Elijah Newren wrote:
> Scripts external to git could source $(git --exec-path)/git-sh-setup (as
> we document in Documentation/git-sh-setup.txt). This will in turn
> source git-sh-i18n, which will setup some handy internationalization
> infrastructure. However,
Following up on the suggestion to make git.git smaller and shed non-core
tools, here's an RFC series to do so with git-filter-branch. This
series first removes dependencies on git-filter-branch (of which there
were very few), and then deletes git-filter-branch itself in the final
commit.
Signed-off-by: Elijah Newren
---
.gitignore | 1 -
Documentation/git-filter-branch.txt | 461 ---
Makefile| 1 -
command-list.txt| 1 -
git-filter-branch.sh| 662
d of comparison and I would ultimately just say that
filter-repo can do everything BFG can, so ultimately it seems that it
is just better to remove that section altogether.
Signed-off-by: Elijah Newren
---
Documentation/git-fast-export.txt | 6 ++---
Documentation/git-filter-
Scripts external to git could source $(git --exec-path)/git-sh-setup (as
we document in Documentation/git-sh-setup.txt). This will in turn
source git-sh-i18n, which will setup some handy internationalization
infrastructure. However, git-sh-i18n hardcodes the TEXTDOMAIN, meaning
that anyone using
r remote names)
> unbounded number of subcommand/submode to "add", and "interactive"
> is merely one of it, then three-level name is a perfect fit, but
> otherwise, not.
Well, my thinking was that `add.useBuiltin` would be misleading (because
the non-interactive part
Based on a previous thread “First Git status takes 40+ minutes, when mounting
fileystem/diskimage with 50G GIT repo + 900G of builds articles”
The context is that
1. git wokspace was clone(50G)
2. some 30 platorms build(900G)
3. This tree was then copied into a new diskimage/filesystem
On Thu, Aug 22, 2019 at 01:23:59PM -0700, Junio C Hamano wrote:
> I do not want a discussion to begin with a Devil's Advocate
> response, but anyway...
>
> Are we planning to go to all batteries included approach? I have a
> feeling that there are other tools (hello
On Mon, Aug 26, 2019 at 08:42:56PM +0200, Albert Vaca Cintora wrote:
> > Why don't you wrap your clone in a script that calls chmod -R u+w .git
> > after the clone? This seems like a pretty trivial approach regardless of
> > your workflow. This works in Linux, Mac, Win
On 26/08/19 07:22AM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
>
> > Subject: Re: [PATCH] git-gui: Update in-memory config when changing config
> > options
>
> s/git-gui: Update/git-gui: update/
I fixed this in my tree, just didn't send a re-roll w
On Mon, Aug 26, 2019 at 4:38 PM Junio C Hamano wrote:
>
> And directories (e.g. .git/objects/) are not made read-only for
> obvious reasons. Read-only files inside a writeable directory can
> be deleted just like read-write ones can be (iow, the "delete
> permission&qu
On Aug 26 2019, Dhaval Patel wrote:
> If it is only about files and revisions both being handled by git
> diff, would it not ne possible to do something like this?
>
> For files
>
> git diff -f a[PRESS TAB]
>
> For revisions
>
> git diff -r a[PRESS TAB]
>
>
Funny that the patch is line-wrapped, which I do not recall ever
seeing in GGG-generated e-mails. Dscho, do you know if anything
funny is going on?
Git Gadget writes:
> From: "Philip.McGraw"
> ...
> diff --git a/git-p4.py b/git-p4.py
> index c71a6832e2..33bdb14fd1 10
y in the first place. Do you guys know who might know?
> >
> > Why don't you wrap your clone in a script that calls chmod -R u+w .git
> > after the clone? This seems like a pretty trivial approach regardless
> > of your workflow. This works in Linux, Mac, Windows (u
Junio C Hamano writes:
> Denton Liu writes:
>
>> In git-format-patch.txt, we were missing some key user information.
>> First of all, document the special value of `--base=auto`.
>>
>> Next, while we're at it, surround option arguments with <>.
>
>
If it is only about files and revisions both being handled by git
diff, would it not ne possible to do something like this?
For files
git diff -f a[PRESS TAB]
For revisions
git diff -r a[PRESS TAB]
Some sort of flag which says we are handling files or revisions.
some
>> software I don't develop regularly so I don't need to keep a clone of it.
>>
>> In any case, it would be useful to know the reason those files are read-only
>> in
>> the first place. Do you guys know who might know?
>
> Why don't you wrap yo
Denton Liu writes:
> In git-format-patch.txt, we were missing some key user information.
> First of all, document the special value of `--base=auto`.
>
> Next, while we're at it, surround option arguments with <>.
I'd suggest squashing this in to
nsequence will be that such
> files are read-only.
And directories (e.g. .git/objects/) are not made read-only for
obvious reasons. Read-only files inside a writeable directory can
be deleted just like read-write ones can be (iow, the "delete
permission" comes from the "write permi
the rest. Sometimes I want to write a patch for some
> software I don't develop regularly so I don't need to keep a clone of it.
>
> In any case, it would be useful to know the reason those files are read-only
> in
> the first place. Do you guys know who might know?
Why
Pratyush Yadav writes:
> Subject: Re: [PATCH] git-gui: Update in-memory config when changing config
> options
s/git-gui: Update/git-gui: update/
> lib/option.tcl | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/option.tcl b/lib/option.tcl
> index e43971b..1
generated filename instead of object.
Thanks to Andrey for patiently suggesting several
iterations on this change for avoiding exceptions!
Also print error details after resulting IOError to make
debugging cause of exception less mysterious when it has
nothing to do with "git version recent e
On 25/08/2019 20:58, Albert Vaca Cintora wrote:
On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote:
Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora:
However, I'm sure that a large percentage of developers out there will
agree with me that having to use force (-f) to delete every cloned
repo
Junio,
This patch hasn't got any comments, but it looks correct to me, and fit
for merging IMO.
I updated the commit subject from 'git-gui: Update...' to 'git-gui:
update...' to match with the style of other commit messages, as you
suggested in the other series.
On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote:
>
> Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora:
> > However, I'm sure that a large percentage of developers out there will
> > agree with me that having to use force (-f) to delete every cloned
> > repo is annoying, and even worse, it crea
Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora:
> However, I'm sure that a large percentage of developers out there will
> agree with me that having to use force (-f) to delete every cloned
> repo is annoying, and even worse, it creates the bad habit of always
> force-deleting everything.
IMO, t
On Sun, Aug 25, 2019 at 1:59 PM Kevin Daudt wrote:
>
> On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote:
> > Hi git folks,
> >
> > Honestly I'm not aware of the reason behind .git being read-only, but
> > I'm sure there is one.
> >
On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote:
> Hi git folks,
>
> Honestly I'm not aware of the reason behind .git being read-only, but
> I'm sure there is one.
>
> However, I'm sure that a large percentage of developers out there will
&
menu item
> >
> > But what if you wanted to click "Stage hunk", and instead click "Revert
> > hunk" instead. This is what I mean by "accidentally".
> >
> > This is even more a risk in the current layout of the buttons, which are
> > i
valid directory), yet the return value still does not point just after a
dir separator.
This assumption is most prominently seen in the
setup_git_directory_gently_1() function, where we want to append a
".git" component and simply assume that there is already a dir
separator. In the UNC exam
/path as a UNC
path.]
This closes https://github.com/git-for-windows/git/issues/1264.
Signed-off-by: Torsten Bögershausen
Signed-off-by: Johannes Schindelin
---
connect.c | 4
t/t5500-fetch-pack.sh | 13 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff
In git-format-patch.txt, we were missing some key user information.
First of all, document the special value of `--base=auto`.
Next, while we're at it, surround option arguments with <>.
Finally, document the `format.outputDirectory` config and change
`format.coverletter` to use
Currently, there are two ways where the return codes of Git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no
Am 24.08.19 um 08:57 schrieb Bert Wesarg:
> On Sat, Aug 24, 2019 at 1:43 AM David Aguilar wrote:
>> On the other hand, if I had to actually move my hand over to a mouse or
>> trackpad and actually "click" on something then I would be super
>> annoyed. That would be simply horrible with RSI in min
On Sat, Aug 24, 2019 at 08:57:22AM +0200, Bert Wesarg wrote:
> On Sat, Aug 24, 2019 at 1:43 AM David Aguilar wrote:
> > On the other hand, if I had to actually move my hand over to a mouse or
> > trackpad and actually "click" on something then I would be super
> > annoyed. That would be simply ho
t behavior because it's an operation that drops data that
> cannot be recovered.
>
> In the other thread, it was mentioned that this dialog would be a
> nuisance. Perhaps that is true -- for the dialog that may have been
> implemented in this series (I haven't run it to verif
On Sat, Aug 24, 2019 at 1:43 AM David Aguilar wrote:
>
> On Fri, Aug 23, 2019 at 03:31:03AM +0530, Pratyush Yadav wrote:
> > Hi,
> >
> > This series adds the ability to revert selected lines and hunks in
> > git-gui. Partially based on the patch by Bert Wesarg [
On Fri, Aug 23, 2019 at 03:31:03AM +0530, Pratyush Yadav wrote:
> Hi,
>
> This series adds the ability to revert selected lines and hunks in
> git-gui. Partially based on the patch by Bert Wesarg [0].
>
> The commits can be found in the topic branch 'py/revert-
Hi git folks,
Honestly I'm not aware of the reason behind .git being read-only, but
I'm sure there is one.
However, I'm sure that a large percentage of developers out there will
agree with me that having to use force (-f) to delete every cloned
repo is annoying, and even worse,
Am 23.08.19 um 19:03 schrieb Pratyush Yadav:
> So how about we keep a copy of the diff in another variable. This allows
> us to enable undoing of reverts. The obvious limitations are that
> firstly, unless we use a stack/deque that means only one undo is
> allowed. I'm not sure if using an undo
ure that only the
lexicographically last one is rewritten. (fast-import will naturally
error out if told to write the same tag more than once, so you have to
avoid triggering it.)
> Summary of above: Anything compatible with git-filter-branch will be
> slower than molasses and extraordinarily unsafe.
Hi Eric!
On Thu, Aug 22, 2019 at 8:01 PM Eric Wong wrote:
>
> Elijah Newren wrote:
> > * Remove git-filter-branch from git.git. Mention in the release
> > notes where people can go to get it.[1]
> >
> > filter-branch is not merely a slow or difficult-to-use to
(re|ab)used to wipe local changes you have in the
> working tree, but that would accumulate cruft that you most of the
> time (unless you make a mistake) wanted to discard and wanted to
> never look at again in the stash. If done using the same 'stash' ref
> that is used by the nor
On 23/08/19 08:29AM, Bert Wesarg wrote:
> On Fri, Aug 23, 2019 at 12:01 AM Pratyush Yadav
> wrote:
> >
> > Just like the user can select lines to stage or unstage, add the
> > ability to revert selected lines.
> >
> > Signed-off-by: Pratyush Y
On 23/08/19 08:04AM, Bert Wesarg wrote:
> On Fri, Aug 23, 2019 at 12:51 AM Pratyush Yadav
> wrote:
> >
> > On 22/08/19 03:34PM, Junio C Hamano wrote:
[...]
> as I'm the one who use this feature for more than 7 years, I can only
> object to this. I'm happy to have the confirmation dialog for the
801 - 900 of 35392 matches
Mail list logo
