Duy Nguyen gmail.com> writes:
> On Tue, Feb 4, 2014 at 12:13 PM, chris 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 the client
chris writes:
> Duy Nguyen gmail.com> writes:
>> On Tue, Feb 4, 2014 at 9:20 AM, chris 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: 100% (9/9), 895
David Kastrup gnu.org> writes:
> chris hotmail.com> writes:
> > Duy Nguyen gmail.com> writes:
> >> On Tue, Feb 4, 2014 at 9:20 AM, chris hotmail.com> wrote:
> >> > $ git push origin next
> >> > Counting objects: 56, done.
> >> > Delta compression using up to 4 threads.
> >> > Compressing object
chris writes:
> David Kastrup gnu.org> writes:
>> chris hotmail.com> writes:
>> > Duy Nguyen gmail.com> writes:
>> >> On Tue, Feb 4, 2014 at 9:20 AM, chris hotmail.com> wrote:
>> >> > $ git push origin next
>> >> > Counting objects: 56, done.
>> >> > Delta compression using up to 4 threads.
>
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
relati
David Kastrup gnu.org> writes:
> chris 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 it.
>
chris 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.
>
> If we assume
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 pref
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
reduc
From: Junio C Hamano
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 example
$ git add /d
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
Reviewed-by: Duy Nguyen
---
t/t0060-path-utils.sh | 6 ++
1 file chang
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 f
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 f
Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
Makes sense.
[...]
> t/t7101-reset-empty-subdirs.sh (new +x) | 63
> +
> t/t7101-reset.sh (gone) | 63
> -
> t/t7104-reset-hard.sh (new +x)
On Mon, Feb 03, 2014 at 03:39:02PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Kirill Smelkov writes:
> >
> >> As was recently shown (c839f1bd "combine-diff: optimize
> >> combine_diff_path sets intersection"), combine-diff runs very slowly. In
> >> that commit we optimized paths
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
g
Martin Erik Werner 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 writes:
>>
>> > The path being exactly equal to the work tree is handle
Nguyễn Thái Ngọc Duy 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.
>
> Signed-off-by: Nguyễn
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy 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 wai
On Tue, 2014-02-04 at 10:09 -0800, Junio C Hamano wrote:
> Martin Erik Werner 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 has no terminatin
Kirill Smelkov 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 risks..
Nguyễn Thái Ngọc Duy 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 for
> --contains is optional while git-tag.txt does not. Correct it.
>
> Signed-off-b
On Tue, Feb 04, 2014 at 06:37:13PM +0100, Miklos Vajna
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 from scratch, and i
Nguyễn Thái Ngọc Duy 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 |
> ADD_CACHE_OK_TO_REPLACE);
> +
Martin Erik Werner 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
the body of a message to
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 t
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,1
Hi Jonathan,
On Tue, Feb 04, 2014 at 11:48:42AM -0800, Jonathan Nieder
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.
Thanks a lot,
Miklos
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
---
bui
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 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
>> +++ b
Miklos Vajna 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 git://anongit.free
David Kastrup 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.
>
> Sig
David Kastrup 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 majordomo inf
Junio C Hamano writes:
> David Kastrup 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(in
Junio C Hamano writes:
> David Kastrup 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
Making a single preparation run for counting the lines will avoid mem
David Kastrup 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
> I should include?
In general, no *.c files outside the compatibility layer should
include anything "#include ", as there seem
From: "Junio C Hamano"
"Philip Oakley" 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
next few months, thus only having
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> David Kastrup 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
>
> Making a single preparati
Junio C Hamano writes:
> David Kastrup 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
>> I should include?
>
> In general, no *.c files outside the compatibility layer should
> include
Junio C Hamano writes:
> David Kastrup 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(in
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
---
bui
David Kastrup writes:
> Junio C Hamano writes:
>
>> David Kastrup 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
>>> I should include?
>>
>> In general, no *.c files outside the com
David Kastrup 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 acti
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
---
Now
Junio C Hamano writes:
> David Kastrup 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
David Kastrup 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
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 hav
Jeff King 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 "R" exi
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 tr/merge-recur
pp_commit_list() will be reused later.
Signed-off-by: Thomas Rast
---
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 a/commit.h b/commit.h
From: Thomas Rast
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
Signed-off-by: Junio C Hamano
---
merge-recursive.c | 6 ++
1 file chan
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 variants
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 r
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 subsequen
From: Thomas Rast
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
Signed-off-by: Junio
From: Thomas Rast
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
---
Documentation/merge-strategies.txt | 4
merge-rec
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 s
Junio C Hamano 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 does:
>
> - If
On Tue, Feb 04, 2014 at 02:17:57PM -0800, Junio C Hamano wrote:
> Jeff King 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 year
From: "David Kastrup"
To: "Junio C Hamano"
Cc:
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 writes:
Junio C Hamano writes:
David Kastrup writes:
Whitespace error in line 1778. Should I
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, ESC[1;32m
From: "Philip Oakley"
From: "David Kastrup"
To: "Junio C Hamano"
Cc:
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? This is exactly what will happen with my
code
as well. I _d
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 3c6b385c655a52fd9db176c
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 t
Jeff King 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 inconvenience a lot
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 fo
Thomas Rast 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 conflicts, which are f
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 writes:
> This comment in builtin/repack.c:
> ...
Oops; there was supposed to be these lines before anythning else:
From: Torsten Bögershausen
Date: Sun Feb 2 16:09:56 2014 +0100
> First see if there are packs of the same name and if so
> if we can move
On Tue, Feb 04, 2014 at 02:25:25PM -0800, Junio C Hamano wrote:
> Junio C Hamano 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.
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
>
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
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 stdou
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 even
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
---
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
---
diff.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index d629cc5..a07fe9d 100644
--- a/diff.
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
---
builtin/show-branch.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtin/show-branch.c b/builtin/show-b
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 us
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
---
builtin/checkout.c| 4 ++--
bui
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 im
83 matches
Mail list logo
