On 6/24/2014 4:55 AM, Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
+static struct hashmap *get_config_cache(void)
+{
+ static struct hashmap config_cache;
+ if (!hashmap_initialized) {
+ config_cache_init(config_cache);
+
On 2014-06-23 07:42 PM, Junio C Hamano wrote:
Noel Grandin noelgran...@gmail.com writes:
It looks like the perl regular expression multiline mode does not work with
'git grep'
Yes, and deliberately so, to avoid having to think about things like
how would a multi-line match interact with
I tried to use git replace --edit today to repair a corrupted tree
that had an empty filename:
$ git replace --edit HEAD^{tree}
fatal: empty filename in tree entry
fatal: cat-file reported failure
Oops. One of the major purposes of the command is to repair broken
objects. This series
This matches our usual style and the surrounding code.
Signed-off-by: Jeff King p...@peff.net
---
builtin/replace.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index 1bb491d..8507835 100644
--- a/builtin/replace.c
+++
This is a little more verbose, but will make it easier to
make parts of our command-line conditional (without
resorting to magic numbers or lots of NULLs to get an
appropriately sized argv array).
Signed-off-by: Jeff King p...@peff.net
---
builtin/replace.c | 8 +---
1 file changed, 5
When a file descriptor is given to run_command via the
in, out, or err parameters, run_command takes
ownership. The descriptor will be closed in the parent
process whether the process is spawned successfully or not,
and closing it again is wrong.
In practice this has not caused problems, because
One of the purposes of git replace --edit is to help a
user repair objects which are malformed or corrupted.
Usually we pretty-print trees with ls-tree, which is much
easier to work with than the raw binary data. However, some
forms of corruption break the tree-walker, in which case our
Jens Lehmann wrote:
Am 23.06.2014 20:24, schrieb Stephen Kelly:
Stephen Kelly wrote:
I see that gitk is showing the output of git diff --submodule, similar
to git submodule summary.
Right, and for your use case --submodule would have to learn a
different value in addition to 'log' and
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
The Illumos repo, like OpenSolaris before it, and Solaris itself at
Sun (and now at Oracle) requires that fixes be broken down into small
commits, with related fixes, tests, and docs changes all typically in
separate commits, but
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
Now, suppose that branches were objects. Then at push time one might
push with a message about the set of commits being pushed, and this
message (and time of push, and pusher ID) would get recorded in the
branch object. At
fsck is a tool that error() is more preferred than die(), but many
functions embed die() inside beyond fsck's control.
unpack_compressed_entry()'s using xmallocz is such a function,
triggered from verify_packfile() - unpack_entry(). Make it use
xmallocz_gentle() instead.
Noticed-by: Dale R.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-compat-util.h | 1 +
wrapper.c | 68 ++-
2 files changed, 53 insertions(+), 16 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index b6f03b3..7eee0f2 100644
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff.c| 13 +++--
diffcore-rename.c | 6 --
diffcore.h| 3 ++-
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/diff.c b/diff.c
index bba9a55..a489540 100644
--- a/diff.c
+++ b/diff.c
@@
Too large files may lead to failure to allocate memory. If it happens
here, it could impact quite a few commands that involve
diff. Moreover, too large files are inefficient to compare anyway (and
most likely non-text), so mark them binary and skip looking at their
content.
Noticed-by: Dale R.
On Tue, Jun 24, 2014 at 2:03 AM, Junio C Hamano gits...@pobox.com wrote:
Since its inception at 7e29b825 (Add column layout skeleton and
git-column, 2012-04-21), it seems that git_column_config() asked for
a specific $command did not give column.$command.* any precedence
over the fallback
On 6/23/2014 5:25 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
+/* for NULL values, 'util' for each `string_list_item` is flagged as 1 */
It's a void *, so just saying that it is flagged as 1 does not say how
it's encoded. How about ... is an 'int *' pointing to the value
On 6/24/2014 4:44 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
+static int hashmap_initialized;
+ ...
+static struct hashmap *get_config_cache(void)
+{
+ static struct hashmap config_cache;
+ if (!hashmap_initialized) {
+
I discovered an issue while trying to clone a git repo over an IPv6 link-local
address:
[vb@nerenyi ~/code/ocaml-llnet]% LANG=C git clone
http://[fe80::226:c6ff:fe50:efa0%wlan0]:33075/repo;
Cloning into 'repo'...
fatal: unable to access 'http://[fe80::226:c6ff:fe50:efa0%wlan0]:33075/repo/':
On Mon, Jun 23, 2014 at 5:21 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Thu, Jun 19, 2014 at 5:28 PM, Jeff King p...@peff.net wrote:
This is shorter, harder to get wrong, and more clearly
captures the intent.
Signed-off-by: Jeff King p...@peff.net
---
I wondered if there was a
On 06/24/2014 02:47 PM, Vincent B. wrote:
I discovered an issue while trying to clone a git repo over an IPv6 link-local
address:
[vb@nerenyi ~/code/ocaml-llnet]% LANG=C git clone
http://[fe80::226:c6ff:fe50:efa0%wlan0]:33075/repo;
Cloning into 'repo'...
fatal: unable to access
On 24/06/2014 15:15, Torsten Bögershausen wrote:
Which OS are you using ?
what does
git --version
give?
And what does this do ?
GIT_CURL_VERBOSE=1 LANG=C git clone
http://[fe80::226:c6ff:fe50:efa0%wlan0]:33075/repo;
My mistake, actually:
As per RFC6874, IPv6 URI with zones have
While it's about malloc..
On Fri, Jun 20, 2014 at 4:28 AM, Jeff King p...@peff.net wrote:
diff --git a/environment.c b/environment.c
index 4dac5e9..4de7b81 100644
--- a/environment.c
+++ b/environment.c
@@ -135,15 +135,11 @@ static void setup_git_env(void)
gitfile =
On 23/06/14 17:20, Tanay Abhra wrote:
On 06/23/2014 07:57 AM, Ramsay Jones wrote:
On 23/06/14 11:11, Tanay Abhra wrote:
[snip]
+static struct hashmap *get_config_cache(void)
+{
+ static struct hashmap config_cache;
+ if (!hashmap_initialized) {
+
On 24/06/14 00:25, Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
+static struct hashmap *get_config_cache(void)
+{
+ static struct hashmap config_cache;
+ if (!hashmap_initialized) {
+ config_cache_init(config_cache);
+ hashmap_initialized =
Changes vs v1:
* Rebase to latest gitk master
* Fix typos in commments
* Switch to patch mode at showing the found change
Max Kirillov (4):
gitk: use single blamestuff for all show_line_source{} calls
gitk: refactor: separate generic hunk parsing out of
find_hunk_blamespecs{}
There seems to be no point to search for several origins at once.
Probably is is not even fully working (because there is one blameinst),
but blamestuff for some reason is an array. Also, it is not cleaned
after blame is completed.
Signed-off-by: Max Kirillov m...@max630.net
---
gitk | 13
For requesting a region blame, it is necessary to parse a hunk and
find the region in the parent file corresponding to the selected region.
There is already hunk parsing functionality in find_hunk_blamespec{},
but it returns only information for a single line.
The new function,
The pattern of maintaining blame command and collecting output
can be reused for searching of latest change to region.
It still can use the blame's global variables, because the two
search commands should not run concurrently as well as two instances
of blame.
Signed-off-by: Max Kirillov
On Mon, Feb 03, 2014 at 06:20:36PM -0500, Eric Sunshine wrote:
On Mon, Feb 3, 2014 at 5:41 PM, Max Kirillov m...@max630.net wrote:
For requesting a region blame, it is necessary to parse a hunk and
find the region in the parent file corresponding to the selected region.
There is already hunk
Add a new command to the diffmenu, Show the latest change of selected
region. The menu command picks selection, and if it exists and covers
a single hunk, locates the latest change which has been made to the
selected lines in the file.
The menu command is disabled if the region blame is
Hi all-
I work on the education team at GitHub and do a fair number of Git
workshops. One thing that I've always found difficult to explain to
newbies is how the staging area works, and why it's useful. As a
hand-wave to simplify things, I usually have them use
git add -A
git commit -m ...
to
So, I've got a gitconfig template for new people (also what link to as
my ~/.gitconfig) so I have a smudge/clean:
[filter gitconfig-rmuser]
clean = sed -e \s/^\\( *email =\\).*/\\1 email address/\ -e
\s/^\\( *name =\\).*/\\1 real name/\ -e \s/^\\( *signingkey
=\\).*/\\1 gpg key/\
smudge =
On Tue, Jun 24, 2014 at 08:30:26PM +0700, Duy Nguyen wrote:
On Fri, Jun 20, 2014 at 4:28 AM, Jeff King p...@peff.net wrote:
diff --git a/environment.c b/environment.c
index 4dac5e9..4de7b81 100644
--- a/environment.c
+++ b/environment.c
@@ -135,15 +135,11 @@ static void
Putting the new trace_performance functions to good use, here are a few
observations about git-status performance.
Comes with three patches (mostly independent, not a patch series!):
* [PATCH] preload-index: optimize for sequential IO
Improves preload-index performance, should apply
Enabling core.preloadIndex on a real HD reduces cold cache performance by
~5%. This is because the threads read from up to 20 different locations on
disk.
Additionally, some threads finish early (each thread is assigned a fixed
number of cache entries to process in advance), i.e. preloading is
Make the amount of IO parallelism configurable (i.e. number of separate
index sections to be processed in parallel).
Defining PARALLEL_IO = 20 restores approximately the IO pattern of the
original preload_index() implementation. Best performance is achieved with
PARALLEL_IO = 1 (i.e. sequential
Add trace_performance output to functions involved in git-status.
Signed-off-by: Karsten Blees bl...@dcon.de
---
Applies on top of performance-tracing topic.
builtin/commit.c | 8
preload-index.c | 4
read-cache.c | 2 ++
wt-status.c | 11 +++
4 files
On Wed, 2014-06-25 at 00:52 +0200, Karsten Blees wrote:
Even more time is spent unpacking the HEAD tree, even with hot cache
(repacking with depth 10 reduces this to ~250ms, on SSD its just 7ms).
Perhaps caching the HEAD tree in an index extension could help here?
This is approximately what
Am 25.06.2014 01:12, schrieb David Turner:
On Wed, 2014-06-25 at 00:52 +0200, Karsten Blees wrote:
Even more time is spent unpacking the HEAD tree, even with hot cache
(repacking with depth 10 reduces this to ~250ms, on SSD its just 7ms).
Perhaps caching the HEAD tree in an index extension
On Tue, 2014-06-24 at 15:01 -0400, Aidan Feldman wrote:
Hi all-
I work on the education team at GitHub and do a fair number of Git
workshops. One thing that I've always found difficult to explain to
newbies is how the staging area works, and why it's useful. As a
hand-wave to simplify
We'd like to hear from people using Git to manage software projects. Taking
this short 5 minute survey helps us create better Git tools. Take the survey
here: http://svy.mk/1irgfmt
By completing this survey, you will be entered to win a $25 Amazon gift card
(submit by 07/11/14, 50 winners will
On Tue, Jun 24, 2014 at 5:46 AM, Jeff King p...@peff.net wrote:
One of the purposes of git replace --edit is to help a
user repair objects which are malformed or corrupted.
Usually we pretty-print trees with ls-tree, which is much
easier to work with than the raw binary data. However, some
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra tanay...@gmail.com wrote:
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
alias.c | 28
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra tanay...@gmail.com wrote:
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
pager.c | 44
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra tanay...@gmail.com wrote:
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
branch.c | 24
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu wrote:
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
Now, suppose that branches were objects. Then at push time one might
push with a message about the set of commits being pushed, and this
message (and time
46 matches
Mail list logo
