Duy Nguyen pclouds at gmail.com writes:
On Tue, Feb 4, 2014 at 12:13 PM, chris jugg at hotmail.com wrote:
However, I question why I should even care about this message? I'm going to
assume that simply it is a lengthy synchronous operation that someone felt
deserved some verbosity to why
chris j...@hotmail.com writes:
Duy Nguyen pclouds at gmail.com writes:
On Tue, Feb 4, 2014 at 9:20 AM, chris jugg at hotmail.com wrote:
$ git push origin next
Counting objects: 56, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects:
David Kastrup dak at gnu.org writes:
chris jugg at hotmail.com writes:
Duy Nguyen pclouds at gmail.com writes:
On Tue, Feb 4, 2014 at 9:20 AM, chris jugg at hotmail.com wrote:
$ git push origin next
Counting objects: 56, done.
Delta compression using up to 4 threads.
Compressing
chris j...@hotmail.com writes:
David Kastrup dak at gnu.org writes:
chris jugg at hotmail.com writes:
Duy Nguyen pclouds at gmail.com writes:
On Tue, Feb 4, 2014 at 9:20 AM, chris jugg at hotmail.com wrote:
$ git push origin next
Counting objects: 56, done.
Delta compression using
Hi,
when using a submodule sm, there is a relative worktree in its config:
.git/modules/sm/config:
[core]
worktree = ../../../smworktree
git-new-worktree (from contrib) symlinks this config the new worktree.
From inside the new worktree, git reads the config, but resolves the
David Kastrup dak at gnu.org writes:
chris jugg at hotmail.com writes:
That said I would naively assume that a server side house keeping
operation that does not get invoked with every client request be a
nice candidate for asynchronous handling without any need to tell the
client about
chris j...@hotmail.com writes:
Ok, given your full response, I understand how this is being
conceptualized now, thanks. However, if you look at it purely from a
user's perspective who is manually invoking these commands for the
command's primary purpose, the current behavior is annoying.
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function which first checks if the
work tree is already the
The 'prefix_path_gently' function currently applies real_path to
everything if given an absolute path, dereferencing symlinks both
outside and inside the work tree.
This causes most high-level functions to misbehave when acting on
symlinks given via absolute paths. For example
$ git add
The amount of tweaks seemed deserving of a reroll, so here it is:
* Added your test Junio, with what I figured was an appropriate commit
message describing the user-visible effect (to git-add since I think it's the
simplest to explain), the commit message for the second commit has been
From: Junio C Hamano gits...@pobox.com
When symlinks in the working tree are manipulated using the absolute
path, git dereferences them, and tries to manipulate the link target
instead.
This causes most high-level functions to misbehave when acting on
symlinks given via absolute paths. For
The current behaviour of prefix_path is to return an empty string if
prefixing and absolute path that only contains exactly the work tree.
This behaviour is a potential regression point.
Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com
Reviewed-by: Duy Nguyen pclo...@gmail.com
---
One edge-case that isn't currently checked in the tests is the beginning
of the path matching the work tree, despite the target not actually
being the work tree, for example:
path = /dir/repoa
work_tree = /dir/repo
should fail since the path is outside the repo. However, if /dir/repoa
is in
When symlinks in the working tree are manipulated using the absolute
path, git dereferences them, and tries to manipulate the link target
instead.
This applies to most high-level commands but prefix_path is the common
denominator for all of them.
Add a known-breakage tests using the prefix_path
Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Makes sense.
[...]
t/t7101-reset-empty-subdirs.sh (new +x) | 63
+
t/t7101-reset.sh (gone) | 63
-
t/t7104-reset-hard.sh
On Mon, Feb 03, 2014 at 03:39:02PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Kirill Smelkov k...@mns.spb.ru writes:
As was recently shown (c839f1bd combine-diff: optimize
combine_diff_path sets intersection), combine-diff runs very slowly. In
that commit we
Hi,
I was trying to understand the history of a piece of code in LibreOffice
and I'm facing a behaviour of git-log which is not something I can
explain. I'm not sure if this is a git bug or a user error. ;)
Here is the situation:
git clone git://anongit.freedesktop.org/libreoffice/core
cd core
Martin Erik Werner martinerikwer...@gmail.com writes:
Will you add that test or should I place it in the series with you as
author?
Either is fine. Thanks.
On Mon, Feb 03, 2014 at 01:00:48PM -0800, Junio C Hamano wrote:
Martin Erik Werner martinerikwer...@gmail.com writes:
The path
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Housekeeping jobs like auto gc generally should not get in the way.
Users who are pushing may not want to wait until auto gc is done on
the server. Give a hint for those users that it's safe now to break
git push and stop waiting.
Junio C Hamano gits...@pobox.com writes:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Housekeeping jobs like auto gc generally should not get in the way.
Users who are pushing may not want to wait until auto gc is done on
the server. Give a hint for those users that it's safe now to break
On Tue, 2014-02-04 at 10:09 -0800, Junio C Hamano wrote:
Martin Erik Werner martinerikwer...@gmail.com writes:
(...)
I was trying to convey that if path is simply /dir/repo, then the while
loop method of replacing a '/' and checking from the beginning won't
work for the last level, since it
Kirill Smelkov k...@mns.spb.ru writes:
if we did not want to reinvent the whole tree walking thing, which
would add risks for new bugs and burden to maintain this and the
usual two-tree diff tree walking in sync.
Junio, I understand it is not good to duplicate code and increase
maintenance
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This goes far back to e84fb2f (branch --contains: default to HEAD -
2008-07-08) where the same parsing code is shared with
builtin/tag.c. git-branch.txt correctly states that commit for
--contains is optional while git-tag.txt does not. Correct
On Tue, Feb 04, 2014 at 06:37:13PM +0100, Miklos Vajna
vmik...@collabora.co.uk wrote:
But then I run:
git grep 'mnTitleBarHeight =' sd
and it's not there. Am I missing something, as in e.g. even with
--full-history git-log does some simplification?
I tried to reproduce this with a repo
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
@@ -128,13 +129,20 @@ static void update_index_from_diff(struct
diff_queue_struct *q,
one-path);
add_cache_entry(ce, ADD_CACHE_OK_TO_ADD |
Martin Erik Werner martinerikwer...@gmail.com writes:
+ const char* work_tree = get_git_work_tree();
Style: asterisk sticks to the variable, not type.
No need to resend---all patches looked reasonable.
Thanks, will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
Hi,
Miklos Vajna wrote:
git clone git://anongit.freedesktop.org/libreoffice/core
cd core
git log --full-history -p -S'mnTitleBarHeight ='
sd/source/ui/dlg/PaneDockingWindow.cxx
Here the first output I get from git-log is
b390fae1706b9c511158a03e4fd61f263be4e511, where you can see that
On 2014-02-04 15.25, Martin Erik Werner wrote:
t/t0060-path-utils.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index b8e92e1..c0a14f6 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -201,6 +201,16 @@
Hi Jonathan,
On Tue, Feb 04, 2014 at 11:48:42AM -0800, Jonathan Nieder jrnie...@gmail.com
wrote:
Luckily '-m -p' without --first-parent worked and the first commit it
showed was the right one. It produces more hits than I'd like, too,
though.
Ah, excellent! :-) '-m' does what I need.
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
Signed-off-by: David Kastrup
Whitespace error in line 1778. Should I be reposting?
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Torsten Bögershausen tbo...@web.de writes:
On 2014-02-04 15.25, Martin Erik Werner wrote:
t/t0060-path-utils.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index b8e92e1..c0a14f6 100755
--- a/t/t0060-path-utils.sh
+++
Miklos Vajna vmik...@collabora.co.uk writes:
Hi,
I was trying to understand the history of a piece of code in LibreOffice
and I'm facing a behaviour of git-log which is not something I can
explain. I'm not sure if this is a git bug or a user error. ;)
Here is the situation:
git clone
David Kastrup d...@gnu.org writes:
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
David Kastrup d...@gnu.org writes:
Whitespace error in line 1778. Should I be reposting?
Heh, let me try to clean it up first and then repost for your
review.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Whitespace error in line 1778. Should I be reposting?
Heh, let me try to clean it up first and then repost for your
review.
Thanks.
-- 8 --
From: David Kastrup d...@gnu.org
Making a single preparation run for
David Kastrup d...@gnu.org writes:
Anybody know offhand what I should be including here? It looks like Git
has some fallback definitions of its own, so it's probably not just
string.h I should include?
In general, no *.c files outside the compatibility layer should
include anything #include
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
If we are progressing from V1.9 to V2.0 quickly (one cycle?), which I
understand is the plan, then mixing the minor development items
(patch
series which progress to master) with the maintenance fixes over the
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Whitespace error in line 1778. Should I be reposting?
Heh, let me try to clean it up first and then repost for your
review.
Thanks.
-- 8 --
From: David Kastrup
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Anybody know offhand what I should be including here? It looks like Git
has some fallback definitions of its own, so it's probably not just
string.h I should include?
In general, no *.c files outside the
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
Signed-off-by: David Kastrup
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Anybody know offhand what I should be including here? It looks like Git
has some fallback definitions of its own, so it's probably not just
string.h I should include?
In
David Kastrup d...@gnu.org writes:
Ok, I now wrote
for (p = buf;; num++, p++) {
p = memchr(p, '\n', end - p);
if (!p)
break;
}
Looks still wrong (perhaps this is a taste issue).
num++ is not loop control, but the real
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
Signed-off-by: David Kastrup
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Ok, I now wrote
for (p = buf;; num++, p++) {
p = memchr(p, '\n', end - p);
if (!p)
break;
}
Looks still wrong (perhaps this is a taste issue).
David Kastrup d...@gnu.org writes:
so something like
for (p = buf; p end; p++) {
p = find the end of this line
if (!p)
break;
num++;
}
perhaps?
Would crash on incomplete last line.
Hmph, even with if !p? From
On Tue, Jan 21, 2014 at 11:23:30AM -0800, Junio C Hamano wrote:
does complicate the point of my series, which was to add more intimate
logic about how we handle LESS.
...
return !x || strchr(x, 'R');
[...]
I am not sure if it is even a good idea for us to have so
Jeff King p...@peff.net writes:
But there's another set of people that I was intending to help with the
patch, which is people that have set up LESS, and did not necessarily
care about the R flag in the past (e.g., for many years before git
came along, I set LESS=giM, and never even knew that
Hi,
This may look intimidating, but it's actually 3.5 separate things:
merge-recursive: remove dead conditional in update_stages()
merge-recursive: internal flag to avoid touching the worktree
merge-recursive: -Xindex-only to leave worktree unchanged
These are unchanged from
pp_commit_list() will be reused later.
Signed-off-by: Thomas Rast t...@thomasrast.ch
---
Necessary only for the next patch, which may be of dubious value.
commit.h | 1 +
pretty.c | 40 ++--
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git
From: Thomas Rast tr...@inf.ethz.ch
650467c (merge-recursive: Consolidate different update_stages
functions, 2011-08-11) changed the former argument 'clear' to always
be true. Remove the useless conditional.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
Signed-off-by: Junio C Hamano
The four ways of displaying merge diffs,
* none: no diff
* -m: against each parent
* -c: combined
* --cc: combined-condensed
were encoded in three flag bits in struct rev_info. Fold them all
into a single enum field that captures the variants.
This makes it easier to add new merge diff
With the new --bases, print merge commits' parents' merge bases. This
is mostly a proof of viability, in particular wrt. revision walk
decoupling and speed.
We can do inline get_merge_bases() (via get_octopus_merge_bases)
because the walks in get_merge_bases() only use flag bits 16-19, and
we
The existing code passed revs-dense_combined_merges along revs itself
into the combine-diff functions, which is rather redundant. Remove
the 'dense' argument until much further down the callchain to simplify
callers.
Note that while the caller in submodule.c needs to do extra work now,
the next
Add a --conflicts-in-index option to merge-recursive, which instructs
it to always store the 3-way merged result in the index. (Normally it
only does so in recursive invocations, but not for the final result.)
This serves as a building block for the remerge diff feature coming
up in a subsequent
From: Thomas Rast tr...@inf.ethz.ch
o-call_depth has a double function: a nonzero call_depth means we
want to construct virtual merge bases, but it also means we want to
avoid touching the worktree. Introduce a new flag o-no_worktree to
trigger only the latter.
Signed-off-by: Thomas Rast
From: Thomas Rast tr...@inf.ethz.ch
Using the new no_worktree flag from the previous commit, we can teach
merge-recursive to leave the worktree untouched. Expose this with a
new strategy option so that scripts can use it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Git has --cc as a very fast inspection tool that shows a brief summary
of what a conflicted merge looks like, and -c/-m as give me the
full information data dumps.
But --cc actually loses information: if the merge lost(!) some changes
from one side, that hunk would fully agree with the other
Junio C Hamano gits...@pobox.com writes:
While I do not have any problem with adding an optional keep lost
paths as intent-to-add entries feature, I am not sure why this has
to be so different from the usual add-cache-entry codepath. The
if/elseif chain you are touching inside this loop
On Tue, Feb 04, 2014 at 02:17:57PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But there's another set of people that I was intending to help with the
patch, which is people that have set up LESS, and did not necessarily
care about the R flag in the past (e.g., for many
From: David Kastrup d...@gnu.org
To: Junio C Hamano gits...@pobox.com
Cc: git@vger.kernel.org
Sent: Tuesday, February 04, 2014 9:09 PM
Subject: Re: [PATCH] blame.c: prepare_lines should not call xrealloc for
every line
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano
On 02/04/2014 14:25, Jeff King wrote:
Right. If git just disabled the color, I think that would be sane (and
that is what my patch was shooting for). But somebody who sees:
$ git log
ESC[33mcommit 3c6b385c655a52fd9db176ce1e01469dc9954f91ESC[mESC[33m
(ESC[1;36mHEADESC[mESC[33m,
From: Philip Oakley philipoak...@iee.org
From: David Kastrup d...@gnu.org
To: Junio C Hamano gits...@pobox.com
Cc: git@vger.kernel.org
Sent: Tuesday, February 04, 2014 9:09 PM
Subject: Re: [PATCH] blame.c: prepare_lines should not call xrealloc
for every line
[...]
Where's the difference?
On Tue, Feb 04, 2014 at 02:45:11PM -0800, Yuri wrote:
On 02/04/2014 14:25, Jeff King wrote:
Right. If git just disabled the color, I think that would be sane (and
that is what my patch was shooting for). But somebody who sees:
$ git log
ESC[33mcommit
Start from an empty repository like so:
: gitster track; git init
Initialized empty Git repository in /var/tmp/x/track/.git/
: gitster track/master; git commit --allow-empty -m initial
[master (root-commit) abdcd1c] initial
: gitster track/master; git branch foo
: gitster
Jeff King p...@peff.net writes:
The safest thing would be to turn off auto-color when LESS (or any of
the pager environment variables) is set at all (and not worry about
whether R is set; only know that _we_ are not setting it, so we cannot
count on it). But that would potentially
On 02/04/2014 14:48, Jeff King wrote:
But this is not a build-time problem, but rather a run-time problem. We
do not know what the environment of the user will be at run-time.
Ok, git can test the pager on the given system before its first use and
remember the result in ~/.git for later use
Thomas Rast t...@thomasrast.ch writes:
log --remerge-diff: show what the conflict resolution changed
Yay ;-)
This series explores another angle, which I call remerge diff. It
works by re-doing the merge in core, using features from patches 1-3
and 7. Likely that will result in
This comment in builtin/repack.c:
First see if there are packs of the same name and if so
if we can move them out of the way (this can happen if we
repacked immediately after packing fully).
When a repo was fully repacked, and is repacked again, we may run
into the situation that new
Junio C Hamano gits...@pobox.com writes:
This comment in builtin/repack.c:
...
Oops; there was supposed to be these lines before anythning else:
From: Torsten Bögershausen tbo...@web.de
Date: Sun Feb 2 16:09:56 2014 +0100
First see if there are packs of the same name and
On Tue, Feb 04, 2014 at 02:25:25PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
While I do not have any problem with adding an optional keep lost
paths as intent-to-add entries feature, I am not sure why this has
to be so different from the usual add-cache-entry
On Tue, Feb 04, 2014 at 03:40:15PM -0800, Junio C Hamano wrote:
* Somehow this came to my private mailbox without Cc to list, so I
am forwarding it.
I think with 1190a1ac (pack-objects: name pack files after
trailer hash, 2013-12-05), repacking the same set of objects may
have
On 01/16/2014 17:47, Jeff King wrote:
Are you using less as your pager (it is the default in git unless you
have set your PAGER environment variable)? If so, do you have the R
option set to pass through ANSI codes? Git will set this automatically
in your LESS variable if you do not already have
On Tue, Feb 04, 2014 at 05:24:55PM -0800, Yuri wrote:
I think the 'experimental' approach is simpler and better.
When the git command requiring pager is first run, git would run the
pager with some simple one line escape sequence, and see if sequence
is preserved.
See how? If less's stdout
On Feb 4, 2014, at 14:12, Jeff King wrote:
On Tue, Jan 21, 2014 at 11:23:30AM -0800, Junio C Hamano wrote:
does complicate the point of my series, which was to add more
intimate
logic about how we handle LESS.
...
return !x || strchr(x, 'R');
[...]
I am not sure if it is
Translate 28 new messages came from git.pot update in
df49095 (l10n: git.pot: v1.9 round 1 (27 new, 11 removed)
and d57b24b (l10n: git.pot: v1.9 round 2 (1 new)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
v3 adds one new message from l10n rnd 2.
po/de.po | 92
Whenever skip_prefix_defval() was called, opt was still equal to
*opt_p. So we can use skip_prefix_if_present() instead.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
diff.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index
Change the logic a little bit so that we can use skip_prefix() instead
of doing pointer arithmetic with hardcoded numbers.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/show-branch.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
These patches apply on top of gitster/nd/more-skip-prefix.
I noticed that Duy's new function skip_prefix_defval() was mostly
being called with its first and third arguments the same. So
introduce a function skip_prefix_if_present() that implements this
pattern.
Michael Haggerty (3):
Add and
Most of the calls to skip_prefix_defval() had equal first and third
arguments, with the effect of skipping the prefix if present, but
otherwise returning the original string. So define a new function
that does exactly that.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
On 02/05/2014 07:25 AM, Michael Haggerty wrote:
These patches apply on top of gitster/nd/more-skip-prefix.
I noticed that Duy's new function skip_prefix_defval() was mostly
being called with its first and third arguments the same. So
introduce a function skip_prefix_if_present() that
83 matches
Mail list logo
