On Tue, Aug 27, 2019 at 07:47:33PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Is this a good thing, though?
> >
> > Giving up (because you do not have enough time or concentration to
> > finish the cherry-pick or revert in progress) with --abort, and
> > committing to the resolut
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-filter-branch.txt
> b/Docume
On Tue, Aug 27, 2019 at 8:22 PM Elijah Newren wrote:
> fast-export and fast-import can easily handle the simple rewrite that
> was being done by filter-branch, and should be significantly faster on
> systems with a slow fork. Timings from before and after on two laptops
> that I have access to (m
Junio C Hamano writes:
> Is this a good thing, though?
>
> Giving up (because you do not have enough time or concentration to
> finish the cherry-pick or revert in progress) with --abort, and
> committing to the resolution after spending effort to deal with a
> conflicted cherry-pick or revert wi
This patch fixes a strange race condition that was hitting our PR builds on
microsoft/git rather frequently. See [1] for an example.
It was only happening on the MSVC builds, so somehow that compiler/platform
combination was leading to this race condition happening more often than
other platforms.
From: Derrick Stolee
Test t5516-fetch-push.sh has a test 'deny fetch unreachable SHA1,
allowtipsha1inwant=true' that checks stderr for a specific error
string from the remote. In some build environments the error sent
over the remote connection gets mingled with the error from the
die() statement
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 -
fast-export and fast-import can easily handle the simple rewrite that
was being done by filter-branch, and should be significantly faster on
systems with a slow fork. Timings from before and after on two laptops
that I have access to (measured via `time ./t3427-rebase-subtree.sh`,
i.e. including e
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 -- assuming my
filter-branch suffers from a deluge of disguised dangers that disfigure
history rewrites (i.e. deviate from the deliberate changes). Many of
these problems are unobtrusive and can easily go undiscovered until the
new repository is in use. This can result in problems ranging from an
even messier h
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be empty. This test was written this way because
the --allow-empty-message option to git commit did not exist at the
time. Simplify t
As discovered on the mailing list, some of the descriptions of the
ff-related options were unclear. Try to be more precise with what these
options do.
Signed-off-by: Elijah Newren
---
I noticed this patch sitting around in one of my branches, and noticed it
wasn't upstream. I'm pretty sure I su
Hi, Duy
On Tue, Aug 27, 2019 at 6:26 AM Duy Nguyen wrote:
>
> On Tue, Aug 27, 2019 at 6:57 AM Matheus Tavares
> wrote:
> >
> > Currently, config_with_options() relies on the global the_repository
> > when it has to configure from a blob.
>
> Not really reading the patch, but my last experience w
On Mon, Aug 26, 2019 at 11:14:13AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > First, revision.c doesn't come with a function to clear a struct
> > rev_info
> > Then, revision.c kind of does nasty things to commit objects...
>
> Yeah, these two stem from the "run once and let ex
On Tue, Aug 27, 2019 at 02:56:57PM -0700, Junio C Hamano wrote:
> Denton Liu writes:
>
> > When reverting or cherry-picking, one of the options we can pass the
> > sequencer is `--skip`. However, unlike rebasing, `--skip` is not
> > mentioned as a possible option in the status message. Mention it
Jeff King wrote:
> The usual philosophy in Git is not to bother the user with
> confirmations, but to allow recovery after a mistake.
>
Well, always prompting for confirmation will be annoying for some people
specially who are mastered in git but, may be very useful feature for
beginner's to avoi
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()
> file-like object as input to the ZipFi
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
> branches:
>
> $ env GIT_E
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 27/08/19 09:53AM, Vipul wrote:
> Hi,
>
> Sometimes, I messed-up with git repository and lost works due
> carelessness. This includes reset a branch instead of other, drop the
> stash etc by mistake. I wonder, is there way to a get an interactive
> confirmation prompt (which ask for yes/no optio
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 get around to discover it :)
> > So I think thin
Eric Wong writes:
> I renamed it to intentionally break my build.
This cuts both ways. If you work without any throw-away merges, it
is GOOD to make sure any new use other people added will be spotted
by the compiler by breaking the build. It will force you to resolve
all such breakages until
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
> the URL.
Why just lines starting wit
Denton Liu writes:
> When reverting or cherry-picking, one of the options we can pass the
> sequencer is `--skip`. However, unlike rebasing, `--skip` is not
> mentioned as a possible option in the status message. Mention it so that
> users are more aware of their options.
Is this a good thing, t
> Jonathan Tan writes:
>
> > As written in the NEEDSWORK comment, repack does not preserve the
> > contents of .promisor files, but I thought I'd send this out anyway as
> > this change is already useful for users who don't run repack much.
>
> What do you exactly mean by "much" here?
For diagn
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 pack-refs --prune --all
> >
> > (or jus
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=/nonexistant git
> > --no-pager show --n
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 web browser command is by default "xdg-
Hey Everyone!
GSoC is finally over and I present to you my final report[1].
Thanks for all your support and reviews without which this
would not be possible.
Thanks
Rohit
[1]: https://rashiwal.me/2019/final-report/
Jonathan Tan writes:
> As written in the NEEDSWORK comment, repack does not preserve the
> contents of .promisor files, but I thought I'd send this out anyway as
> this change is already useful for users who don't run repack much.
What do you exactly mean by "much" here? The comment sounds like
I'm a bit perplexed about what is intended follow a git stash push
--include-untracked. Suppose I have files a,b,c,known modified, but only
known is in the index. After the stash, stash show only displays known. A
subsequent pop will restore a,b,c. So functionally push and pop are fine,
but show ap
Taylor Blau writes:
> ... My patch has a few
> more details such as blame information (and how the typo was only made
> in the explicit version, not the variadic form), so it may be worthwhile
> to take that instead of this, but I don't mind either way.
Yup, that was exactly why I took that vers
Carlo Arenas writes:
>> > ... but
>> > ab/pcre-jit-fixes and UTF-8 validation are likely to make that more
>> > difficult (even if it is a mostly self inflicted wound AFAIK)
>> ...
> for example 685668faaa (grep: stop using a custom JIT stack with PCRE
> v1, 2019-07-26) adds 2 regressions as dis
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 09:53:30AM +, Vipul wrote:
> Sometimes, I messed-up with git repository and lost works due
> carelessness. This includes reset a branch instead of other, drop the
> stash etc by mistake. I wonder, is there way to a get an interactive
> confirmation prompt (which ask for
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
> ...
>
> real0m1.041s
Thx for your feedback. I will update the necessary existing tests and re-submit
the patches.
Ibrahim El Rhezzali
‐‐‐ Original Message ‐‐‐
On Monday, August 26, 2019 11:07 PM, brian m. carlson
wrote:
> On 2019-08-26 at 19:58:10, Ibrahim El wrote:
>
> > From: Ibrahim El Rhezzali ibrahi
Thx for your feedback. I will incorporate the detailed explanation and
re-submit the patches.
Ibrahim El Rhezzali
‐‐‐ Original Message ‐‐‐
On Monday, August 26, 2019 11:04 PM, brian m. carlson
wrote:
> On 2019-08-26 at 19:58:00, Ibrahim El wrote:
>
> > From: Ibrahim El Rhezzali ibrah
Thx for your feedback. I will incorporate the changes and re-submit the patches.
Ibrahim El
‐‐‐ Original Message ‐‐‐
On Monday, August 26, 2019 10:46 PM, brian m. carlson
wrote:
> On 2019-08-26 at 19:57:53, Ibrahim El wrote:
>
> > From: Ibrahim El Rhezzali ibrahim...@pm.me
> > 2f8f825
Thx for your feedback. I will incorporate the config based improach into a
generic driver and will re-submit the patches.
Ibrahim El
‐‐‐ Original Message ‐‐‐
On Monday, August 26, 2019 11:15 PM, brian m. carlson
wrote:
> On 2019-08-26 at 19:57:45, Ibrahim El wrote:
>
> > Following pr
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 wokspace was clone(50
On Tue, Aug 27, 2019 at 04:27:25PM +, Giuseppe Crino' wrote:
> Hello, to debug some issues I built and installed git via
>
> $ make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g"
> $ sudo make install
What do the output of these two command look like? After the first
command build Git with th
Am 27.08.19 um 18:27 schrieb Giuseppe Crino':
> Hello, to debug some issues I built and installed git via
>
> $ make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g"
> $ sudo make install
> $ git --version # git version 2.23.0.40.g4d8aada92f
>
> But it seems there's still some optimization going on
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',
'/tmp/QRaIJ1_file1.txt
On August 27, 2019 1:56 PM, Matheus Tavares Bernardino wrote:
> On Tue, Aug 27, 2019 at 1:27 PM Giuseppe Crino'
> wrote:
> > Hello, to debug some issues I built and installed git via
> >
> > $ make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g"
> > $ sudo make install
> > $ git --version # git vers
On Tue, Aug 27, 2019 at 1:27 PM Giuseppe Crino' wrote:
>
> Hello, to debug some issues I built and installed git via
>
> $ make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g"
> $ sudo make install
> $ git --version # git version 2.23.0.40.g4d8aada92f
Hmm, could it be perhaps that CFLAGS is being o
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 of builds a
Emit trace2_cmd_mode() messages for each commit-graph sub-command.
The commit graph commands were in flux when trace2 was making it's way to
git. Now that we have enough sub-commands in commit-graph, we can label the
various modes within them. Distinguishing between read, write and verify is
a gre
From: Garima Singh
Emit trace2_cmd_mode() messages for each commit-graph
sub-command.
The commit graph commands were in flux when trace2 was
making it's way to git. Now that we have enough sub-commands
in commit-graph, we can label the various modes within them.
Distinguishing between read, writ
Hello, to debug some issues I built and installed git via
$ make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g"
$ sudo make install
$ git --version # git version 2.23.0.40.g4d8aada92f
But it seems there's still some optimization going on that prevents gdb from
working correctly.
For example
(g
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 browser command is by defau
On 8/25/2019 10:43 PM, Eric Wong wrote:
> This is a step towards removing the requirement for
> hashmap_entry being the first field of a struct.
>
> Signed-off-by: Eric Wong
> ---
> diff.c | 19 ---
> diffcore-rename.c | 11 +++
> hashmap.c
On 8/25/2019 10:43 PM, Eric Wong wrote:
> This macro is popular within the Linux kernel for supporting
> intrusive data structures such as linked lists, red-black trees,
> and chained hash tables while allowing the compiler to do
> type checking.
>
> I intend to use this to remove the limitation o
On Tue, 27 Aug 2019 13:51:49 +
"Giuseppe Crino'" wrote:
> On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> > So it might make sense to push these rules into "git mailinfo" instead
> > of applying them everywhere. But we'd still need something at least for
> > GECOS, where "Your Na
On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> So it might make sense to push these rules into "git mailinfo" instead
> of applying them everywhere. But we'd still need something at least for
> GECOS, where "Your Name" is common.
What's the GECOS you mean?
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 o
From: lufia
Signed-off-by: lufia
---
compat/plan9/openssl/crypto.h | 5 +
compat/regex/regex_internal.h | 3 +++
config.c | 3 ++-
git-compat-util.h | 9 -
parse-options.h | 18 +-
remove-bitfields.sh | 17
From: lufia
In Plan 9, almost environment variables are not capitalized.
Signed-off-by: lufia
---
Makefile | 40 +---
builtin/config.c | 2 +-
config.c | 2 +-
credential-cache.c | 2 +-
credential-store.c | 2 +-
exec-cmd.c
From: lufia
Plan 9 ANSI/POSIX environment is:
* No expr(1)
* sed(1) limits max length of label to 7 characters
* pcc ignores object files that has incorrect extension,
so should use underlying loader directly.
* No ln(1). Instead use bind(1), but bind isn't persisted to the disk.
However it i
On 8/25/2019 10:43 PM, Eric Wong wrote:
> C compilers do type checking to make life easier for us. So
> rely on that and update all hashmap_entry_init callers to take
> "struct hashmap_entry *" to avoid future bugs while improving
> safety and readability.
Overall I like this change. I'll need to
On 8/25/2019 10:43 PM, Eric Wong wrote:
> Otherwise, the hashmap_entry.next field appears to remain
> uninitialized, which can lead to problems when
> add_lines_to_move_detection calls hashmap_add.
>
> I found this through manual inspection when converting
> hashmap_add callers to take "struct has
This is to notify you that your Consignment worth $1.5 Million will be
delivered to you without delay.
Your Consignment will be brought to your doorstep by a reputable Courier
Service.
We want you to understand that the Delivery Courier Service charge of $50 is
the only fee you will pay for th
From: Slavica Djukic
The error messages as well as the unique prefixes are colored in `git
add -i` by default; We need to do the same in the built-in version.
Signed-off-by: Slavica Djukic
Signed-off-by: Johannes Schindelin
---
add-interactive.c | 37 -
1 f
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
[ht
From: Slavica Djukic
In the `git add -i` command, we show unique prefixes of the commands and
files, to give an indication what prefix would select them.
Naturally, the C implementation looks a lot different than the Perl
implementation: in Perl, a trie is much easier implemented, while we
alrea
From: Johannes Schindelin
This is what the Perl version does, and therefore it is what the
built-in version should do, too.
Signed-off-by: Johannes Schindelin
---
add-interactive.c | 4 +++-
repository.c | 19 +++
repository.h | 7 +++
3 files changed, 29 insert
From: Slavica Djukic
Just like in the Perl script `git-add--interactive.perl`, for each
command a unique prefix is determined (if there exists any within the
given parameters), and shown in the list, and accepted as a shortcut for
the command.
We use the prefix map implementation that we just ad
From: Johannes Schindelin
With this change, we print out the same colored help text that the
Perl-based `git add -i` prints in the main loop when question mark is
entered.
Signed-off-by: Johannes Schindelin
---
add-interactive.c | 22 +-
1 file changed, 21 insertions(+), 1
From: Daniel Ferreira
Make the diffstat interface (namely, the diffstat_t struct and
compute_diffstat) no longer be internal to diff.c and allow it to be used
by other parts of git.
This is helpful for code that may want to easily extract information
from files using the diff machinery, while fl
From: Daniel Ferreira
This implements the `status` command of `git add -i`. The data
structures introduced in this commit will be extended as needed later.
At this point, we re-implement only part of the `list_and_choose()`
function of the Perl script `git-add--interactive.perl` and call it
`lis
From: Johannes Schindelin
For simplicity, we only implemented the `status` command without colors.
This patch starts adding color, matching what the Perl script
`git-add--interactive.perl` does.
Original-Patch-By: Daniel Ferreira
Signed-off-by: Slavica Djukic
Signed-off-by: Johannes Schindelin
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 more
From: Johannes Schindelin
The reason why we did not start with the main loop to begin with is that
it is the first user of `list_and_choose()`, which uses the `list()`
function that we conveniently introduced for use by the `status`
command.
Apart from the "and choose" part, there are more diffe
From: Johannes Schindelin
This imitates the code to show the help text from the Perl script
`git-add--interactive.perl` in the built-in version.
To make sure that it renders exactly like the Perl version of `git add
-i`, we also add a test case for that to `t3701-add-interactive.sh`.
Signed-off
Hi Gábor,
On Sat, 24 Aug 2019, SZEDER Gábor wrote:
> On Tue, Jul 16, 2019 at 07:58:42AM -0700, Slavica Djukic via GitGitGadget
> wrote:
> > In the `git add -i` command, we show unique prefixes of the commands and
> > files, to give an indication what prefix would select them.
> >
> > Naturally,
On Tue, Aug 27, 2019 at 2:07 AM Johannes Schindelin
wrote:
>
> Unfortunately, this is _still_ incorrect.
I know, and that is why we worked out a v6 RC with Rene than then was
pushed to github[0] and validated to work thanks to your integration
as detailed in [1], I never got to send an update to
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
thank you. your answer is pretty complete.
On Tue, Aug 27, 2019 at 1:36 PM SZEDER Gábor wrote:
>
> On Tue, Aug 27, 2019 at 01:10:02PM +0300, Konstantin wrote:
> > currently we have one code file with deep history.
> > As code file grown it is necessary to split it.
> > but this action will drop h
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 01:10:02PM +0300, Konstantin wrote:
> currently we have one code file with deep history.
> As code file grown it is necessary to split it.
> but this action will drop history for the new extracted file.
> how can i split one big code file to small files and save its history
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
When converting stash into C, calls to 'git update-index --refresh'
were replaced with the 'refresh_cache()' function. That is fine as
long as the index is only needed in-core, and not re-read from disk.
However in many cases we do actually need the refreshed index to be
written to disk, for exam
Thanks Peff for spotting the bug! Here's a series that fixes it.
> And before the third one, introduction of a new entry point that
> makes merge-recursive machinery inherit the already populated
> in-core index, happens, I think the right solution is to write the
> in-core index out---the write
Getting the lock for the index, refreshing it and then writing it is a
pattern that happens more than once throughout the codebase. Factor
out the refresh_and_write_cache function from builtin/am.c to
read-cache.c, so it can be re-used in other places in a subsequent
commit.
Note that we return d
Use the 'refresh_and_write_cache()' convenience function introduced in
the last commit, instead of refreshing and writing the index manually
in merge.c
Signed-off-by: Thomas Gummerer
---
builtin/merge.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/builtin/
currently we have one code file with deep history.
As code file grown it is necessary to split it.
but this action will drop history for the new extracted file.
how can i split one big code file to small files and save its history
for the "blame" action?
--
Best regards,
Konstantin K
Hi Junio,
On Wed, 31 Jul 2019, Junio C Hamano wrote:
> "Daniel Ferreira via GitGitGadget" writes:
>
> > +struct item {
> > + const char *name;
> > +};
> > +
> > +struct list_options {
> > + const char *header;
> > + void (*print_item)(int i, struct item *item, void *print_item_data);
> > +
On Tue, Aug 27, 2019 at 11:44:07AM +0200, SZEDER Gábor wrote:
> On Tue, Aug 27, 2019 at 11:12:06AM +0200, Philipp Zabel wrote:
> > 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:59A
Hi,
Sometimes, I messed-up with git repository and lost works due
carelessness. This includes reset a branch instead of other, drop the
stash etc by mistake. I wonder, is there way to a get an interactive
confirmation prompt (which ask for yes/no option) before executing those
commands when users
Johannes Schindelin wrote:
> Hi Eric,
>
> On Mon, 26 Aug 2019, Eric Wong wrote:
>
> > By renaming the "hash" field to "_hash", it's easy to spot
> > improper initialization of hashmap_entry structs which
> > can leave "hashmap_entry.next" uninitialized.
>
> Would you mind elaborating a bit? Thi
On Tue, Aug 27, 2019 at 11:12:06AM +0200, Philipp Zabel wrote:
> 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 gi
On Tue, Aug 27, 2019 at 6:57 AM Matheus Tavares
wrote:
>
> Currently, config_with_options() relies on the global the_repository
> when it has to configure from a blob.
Not really reading the patch, but my last experience with moving
config.c away from the_repo [1] shows that there are more hidden
Hi Junio,
On Wed, 31 Jul 2019, Junio C Hamano wrote:
> "Daniel Ferreira via GitGitGadget" writes:
>
> > @@ -6273,12 +6257,7 @@ void diff_flush(struct diff_options *options)
> > dirstat_by_line) {
> > struct diffstat_t diffstat;
> >
> > - memset(&diffstat, 0, sizeof(
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.
> > > Using git 2.23.0 (from Debian) t
Hi Eric,
On Mon, 26 Aug 2019, Eric Wong wrote:
> By renaming the "hash" field to "_hash", it's easy to spot
> improper initialization of hashmap_entry structs which
> can leave "hashmap_entry.next" uninitialized.
Would you mind elaborating a bit? This explanation does not enlighten
me, sadly, al
Hi Carlo,
On Thu, 8 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> 94da9193a6 (grep: add support for PCRE v2, 2017-06-01) didn't include
> a way to override the system allocator, and so it is incompatible with
> USE_NED_ALLOCATOR. The problem was made visible when an attempt to
> avoid a leak in
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:/ptx/src/git/linux.git$ sudo s
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, discovering it is simple.
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"; time git show v5.2
> tag v5
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.371s
But to ge
1 - 100 of 102 matches
Mail list logo
