Jonathan Nieder writes:
> The warning about use of 'git add -u' with no pathspec is annoying
> because it serves no purpose in this case. So suppress the warning
> unless there are changes outside the cwd that are not being added.
No time to review the code now. I thought about implementing som
Duy Nguyen wrote:
> My concern is run full-tree diff can be expensive on large repos (one
> of the reasons the user may choose to work from within a
> subdirectory). We can exit as soon as we find a difference outside
> $prefix. But in case we find nothing, we need to diff the whole
> worktree.
Y
On Tue, Mar 19, 2013 at 11:25 AM, Junio C Hamano wrote:
> I am wondering if we can special case the no-pathspec case to have
> add_files_to_cache() call underlying run_diff_files() without any
> pathspec, inspect the paths that are modified and/or deleted in the
> update_callback, add ones that ar
Junio C Hamano wrote:
> The implemenation appears to run an extra diff_files() in addition
> to the one we already have to run in order to implement the "add -u"
> to collect modified/deleted paths. Is that the best we can do?
At least the following should be squashed in to avoid wasted effort
Junio C Hamano wrote:
> The implemenation appears to run an extra diff_files() in addition
> to the one we already have to run in order to implement the "add -u"
> to collect modified/deleted paths. Is that the best we can do?
>
> I am wondering if we can special case the no-pathspec case to ha
On Tue, Mar 19, 2013 at 11:08 AM, Junio C Hamano wrote:
> Karsten Blees writes:
>
>> This patch series addresses several bugs and performance issues in
>> .gitignore processing that came up in the inotify discussion.
>
> Thanks.
>
> How does this interact with the nd/read-directory-recursive-opti
Jonathan Nieder writes:
> A common workflow in large projects is to chdir into a subdirectory of
> interest and only do work there:
>
> cd src
> vi foo.c
> make test
> git add -u
> git commit
>
> The upcoming change to 'git add -u' behavior would not affect such a
>
On Mon, Mar 18, 2013 at 08:44:15PM -0700, Jonathan Nieder wrote:
> > The
> > config option added by this patch gives them such an option.
>
> I suspect the need for this config option is a sign that the warning
> is too eager. After all, t
Karsten Blees writes:
> This patch series addresses several bugs and performance issues in
> .gitignore processing that came up in the inotify discussion.
Thanks.
How does this interact with the nd/read-directory-recursive-optim
topic that has been cooking for a while?
--
To unsubscribe from
In the spirit of the recent similar change for 'git add -u', avoid
pestering users that restrict their attention to a subdirectory and
will not be affected by the coming change in the behavior of pathless
'git add -A'.
Signed-off-by: Jonathan Nieder
---
builtin/add.c | 21 -
A common workflow in large projects is to chdir into a subdirectory of
interest and only do work there:
cd src
vi foo.c
make test
git add -u
git commit
The upcoming change to 'git add -u' behavior would not affect such a
workflow: when the only changes pres
Make warn_pathless_add() print its warning the first time it is called
and do nothing if called again. This will make it easier to show the
warning on the fly when a relevant condition is detected without
risking showing it multiple times when multiple such conditions hold.
Signed-off-by: Jonatha
Currently warn_pathless_add() is only called directly by cmd_add(),
but that is about to change. Move its definition higher in the file
and pass the "--update" or "--all" option name used in its message
through globals instead of function arguments to make it easier to
call without passing values
Hi,
Jeff King wrote:
> The
> config option added by this patch gives them such an option.
I suspect the need for this config option is a sign that the warning
is too eager. After all, the whole idea of the change being safe is
that it sho
On Mon, Mar 18, 2013 at 5:24 AM, Joydeep Bakshi
wrote:
> I'm closer to my requirement. I have found gitweb simply provide a GUI for
> history check
> and code comparison. And the git itself is good enough to do the ACL stuff
> with hooks.
>
> I already have the following code to deploy the push
On Tue, Mar 19, 2013 at 1:26 AM, John Keeping wrote:
> On Fri, Mar 15, 2013 at 01:06:42PM +0700, Nguyễn Thái Ngọc Duy wrote:
>> This passes the pathspec, more or less unmodified, to
>> git-add--interactive. The command itself does not process pathspec. It
>> simply passes the pathspec to other bui
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Test nits:
>> ...
>> Hope that helps,
>>
>> Jonathan Nieder (3):
>> push test: use test_config where appropriate
>> push test: simplify check of push result
>> push test: rely on &&-chaining instead of 'if bad; then echo Oops; fi'
>
> Are t
Jonathan Nieder writes:
> Test nits:
> ...
> Hope that helps,
>
> Jonathan Nieder (3):
> push test: use test_config where appropriate
> push test: simplify check of push result
> push test: rely on &&-chaining instead of 'if bad; then echo Oops; fi'
Are these supposed to be follow-up patch
Jens Lehmann writes:
> Am 12.03.2013 17:22, schrieb Junio C Hamano:
>> Phil Hord writes:
>>
>>> I think this would be clearer if 'git deinit' said
>>>
>>> rm 'submodule/*'
>>>
>>> or maybe
>>>
>>> Removed workdir for 'submodule'
>>>
>>> Is it just me?
>>
>> The latter may probably be b
On Tue, Mar 19, 2013 at 12:50 AM, Junio C Hamano wrote:
> While it is true that strbuf_remove(&sb, sb.len - trim, trim) is
> equivalent to strbuf_setlen(&sb, sb.len - trim), I wonder why we see
> any memcpy() in the first place.
>
> strbuf_remove(&sb, sb.len - trim, trim) is turned into
> strbuf_s
Hi,
Rob Hoelz wrote:
> [url "git://github.com/"]
> insteadOf = github:
> [url "git://github.com/myuser/"]
> insteadOf = mygithub:
> [url "g...@github.com:myuser/"]
> pushInsteadOf = mygithub:
> [remote "origin"]
> url = github:organization/project
> pushurl = mygithub:proj
When it is unclear which command from a test has failed, usual
practice these days is to debug by running the test again with "sh -x"
instead of relying on debugging 'echo' statements.
Signed-off-by: Jonathan Nieder
---
t/t5516-fetch-push.sh | 15 ---
1 file changed, 4 insertions(+),
This test checks each ref with code like the following:
r=$(git show-ref -s --verify refs/$ref) &&
test "z$r" = "z$the_first_commit"
Afterward it counts refs:
test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
Simpler to test the number and values of relevant refs
Configuration from test_config does not last beyond the end of the
current test assertion, making each test easier to think about in
isolation.
This changes the meaning of some of the tests. For example, currently
"push with insteadOf" passes even if the line setting
"url.$TRASH.pushInsteadOf" is
On Mon, Mar 18, 2013 at 9:16 AM, Ramkumar Ramachandra
wrote:
> - If no remote is configured, or if you are not on any branch,
> - it defaults to `origin` for fetching and `remote.pushdefault`
> - for pushing.
> + The remote to push to, for the current branch, may be further
On Mon, Mar 18, 2013 at 9:16 AM, Ramkumar Ramachandra
wrote:
> branch..remote::
> - When in branch , it tells 'git fetch' and 'git push' which
> - remote to fetch from/push to. It defaults to `origin` if no remote is
> - configured. `origin` is also used if you are not on any b
On Mon, Mar 18, 2013 at 9:16 AM, Ramkumar Ramachandra
wrote:
> remote.c: introduce a way to have different remotes for fetch/ push
s/ push/push/
> Currently, do_push() in push.c calls remote_get(), which gets the
> configured remote for fetching and pushing. Replace this call with a
> call to p
On Mon, Mar 18, 2013 at 9:16 AM, Ramkumar Ramachandra
wrote:
> remote.c: simply a bit of code using git_config_string()
s/simply/simplify/
> A small segment where handle_config() parses the branch.remote
> configuration variable can be simplified using git_config_string().
>
> Signed-off-by: Ram
On Mon, Mar 18, 2013 at 4:29 PM, Karsten Blees wrote:
> Directories could also be excluded by exclude patterns specified on the
> command line or .git/info/exclude, so we cannot simply skip prep_exclude
> entirely if there's no .gitignore file name (dir_struct.exclude_per_dir).
> Move this check t
On Mon, Mar 18, 2013 at 4:28 PM, Karsten Blees wrote:
> When checking if a directory is already listed as untracked (i.e. shouldn't
> be listed as ignored as well), don't assume that the dirctory has only
s/dirctory/directory/
> ignored files if it doesn't have untracked files, as the directory
Thanks, just a quick review before I find some time do take a
deeper look.
Am 14.03.2013 07:30, schrieb Eric Cousineau:
> From 59fb432e17a1aae9de26bbaaca7f09cc7f03b471 Mon Sep 17 00:00:00 2001
> From: Eric Cousineau
> Date: Thu, 14 Mar 2013 01:19:53 -0500
> Subject: [PATCH] submodule-foreach: Add
Windows probably isn’t the most popular platform for Git developers ☺, but here
goes…
On Windows with an NTFS volume with Deduplication enabled, Git believes that
deduplicated files are symlinks. It then fails to be able to do anything with
the file. This can be repro-ed by creating an NTFS v
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We have been scheduling each cycle to last 8-10 weeks, but at the
end of 1.8.2 cycle we already have quite a many topics in flight. I
am wonder
Am 12.03.2013 17:01, schrieb Phil Hord:
> On Sat, Mar 9, 2013 at 1:18 PM, Jens Lehmann wrote:
>> Am 05.03.2013 22:17, schrieb Phil Hord:
>>> On Tue, Mar 5, 2013 at 3:51 PM, Jens Lehmann wrote:
Am 05.03.2013 19:34, schrieb Junio C Hamano:
> Eric Cousineau writes:
>> ...
> I am no
git push currently doesn't consider pushInsteadOf when
using pushurl; this test tests that.
If you use pushurl with an alias that has a pushInsteadOf configuration
value, Git does not take advantage of it. For example:
[url "git://github.com/"]
insteadOf = github:
[url "git://github.com/myus
On Sun, 17 Mar 2013 16:35:59 -0700
Junio C Hamano wrote:
> Rob Hoelz writes:
>
> > git push currently doesn't consider pushInsteadOf when
> > using pushurl; this tests and fixes that.
> >
> > If you use pushurl with an alias that has a pushInsteadOf
> > configuration value, Git does not take ad
Am 12.03.2013 17:22, schrieb Junio C Hamano:
> Phil Hord writes:
>
>> I think this would be clearer if 'git deinit' said
>>
>> rm 'submodule/*'
>>
>> or maybe
>>
>> Removed workdir for 'submodule'
>>
>> Is it just me?
>
> The latter may probably be better.
Hmm, it doesn't really remov
'git-status --ignored' lists empty untracked directories as ignored, even
though they don't have any ignored files.
When checking if a directory is already listed as untracked (i.e. shouldn't
be listed as ignored as well), don't assume that the dirctory has only
ignored files if it doesn't have un
Checking if a file is in the index is much faster (hashtable lookup) than
checking if the file is excluded (linear search over exclude patterns).
Skip is_excluded checks for files: move the cache_name_exists check from
treat_file to treat_one_path and return early if the file is tracked.
This can
Signed-off-by: Karsten Blees
---
builtin/add.c | 5 +---
builtin/check-ignore.c | 6 +---
builtin/ls-files.c | 15 +++---
dir.c | 79 --
dir.h | 16 ++
unpack-trees.c | 10 +--
The is_excluded and is_path_excluded APIs are very similar, except for a
few noteworthy differences:
is_excluded doesn't handle ignored directories, results for paths within
ignored directories are incorrect. This is probably based on the premise
that recursive directory scans should stop at ignor
Move code around in preparation for the next patch.
Signed-off-by: Karsten Blees
---
dir.c | 181 ++
1 file changed, 94 insertions(+), 87 deletions(-)
diff --git a/dir.c b/dir.c
index 64457db..417feaa 100644
--- a/dir.c
+++ b/dir.c
'git-status --ignored' lists ignored tracked directories without any
ignored files if a tracked file happens to match an exclude pattern.
Always exclude tracked files.
Signed-off-by: Karsten Blees
---
dir.c | 11 ---
t/t7061-wtstatus-ignore.sh | 24 +
'git-status --ignored' lists both the ignored directory and the ignored
files if the files are in a tracked sub directory.
When recursing into sub directories in read_directory_recursive, pass on
the check_only parameter so that we don't accidentally add the files.
Signed-off-by: Karsten Blees
-
'git-status --ignored' drops ignored directories if they contain untracked
files in an untracked sub directory.
Fix it by getting exact (recursive) excluded status in treat_directory.
Signed-off-by: Karsten Blees
---
dir.c | 9 +
t/t7061-wtstatus-ignore.sh | 27 +++
This patch series addresses several bugs and performance issues in .gitignore
processing that came up in the inotify discussion.
Also available here:
https://github.com/kblees/git/tree/kb/improve-git-status-ignored
git pull git://github.com/kblees/git.git kb/improve-git-status-ignored
Patches 1
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> I usually use `git fetch`, inspect state, and then merge/ rebase
>> accordingly. Unfortunately, this is very sub-optimal as I can
>> automate this 80% of the time. I want to be able to decide what to do
>> on a repository-specific basis,
Ramkumar Ramachandra writes:
> I usually use `git fetch`, inspect state, and then merge/ rebase
> accordingly. Unfortunately, this is very sub-optimal as I can
> automate this 80% of the time. I want to be able to decide what to do
> on a repository-specific basis, and hence propose a pull.defa
Jeff King writes:
> I do not see anything obviously wrong in it, though I did not walk
> through all of the ofs calculation to look for any clever speedups.
> However, I think it is clear from the other timings and Ingo's thread
> that glibc 2.11's memcmp does not perform very well on many short
On Fri, Mar 15, 2013 at 01:06:42PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This passes the pathspec, more or less unmodified, to
> git-add--interactive. The command itself does not process pathspec. It
> simply passes the pathspec to other builtin commands. So if all those
> commands support pathspec,
Jeff King writes:
> - blame-tree; re-rolled from my submission last year to build on top
>
> - diff --max-depth; this is a requirement to do blame-tree efficiently
Both look mildly interesting, especially after the magic pathspec
settles the latter may be a good addition.
> - share ref se
Nguyễn Thái Ngọc Duy writes:
> perf reports memcpy at the the 6th position [1] in "git status -uno"
> using index v4, and strbuf_remove() in expand_name_field() accounts
> for 25% of that. What we need here is a simple string cut and a
> cheaper strbuf_setlen() should be enough.
While it is tru
On Mon, Mar 18, 2013 at 10:08:11AM -0700, Junio C Hamano wrote:
> Just for fun, here is a totally unrelated comparison, both with
> current master, compiled with -O2 and running on the same box.
>
> [without GIT_USE_LOOKUP]
> real0m39.906s
> real0m40.020s
> real0m40.022s
> real0m4
Jeff King writes:
> On Mon, Mar 18, 2013 at 09:44:20AM -0700, Junio C Hamano wrote:
>
>> FWIW, I am getting something like this on my
>>
>> $ grep 'model name' /proc/cpuinfo | uniq -c
>> 4 model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz
>>
>> The same "rev-list --objects --a
On Mon, Mar 18, 2013 at 10:28:59PM +0530, Ramkumar Ramachandra wrote:
> This has irritated me for a long time. I often end up doing:
>
> $ git push master:master +pu:pu
Me too.
> Is there a reason for the remote not being optional, or are we just
> waiting for a patch? The only problem I
On Mon, Mar 18, 2013 at 09:44:20AM -0700, Junio C Hamano wrote:
> FWIW, I am getting something like this on my
>
> $ grep 'model name' /proc/cpuinfo | uniq -c
> 4 model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz
>
> The same "rev-list --objects --all >/dev/null", best of five:
Jeff King writes:
> By the way, looking at that made me think for a few minutes about
> hashcmp, and I was surprised to find that we use an open-coded
> comparison loop. That dates back to this thread by Ingo:
>
> http://article.gmane.org/gmane.comp.version-control.git/172286
>
> I could not re
Jeff King writes:
> Here's the re-roll.
Above reasoning (elided) look sensible. Thanks; will replace.
--
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
On 13-03-18 10:25 AM, Jeff King wrote:
> On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
>
>> I've put off implementing remote.default corresponding to
>> remote.pushdefault, as Jeff suggested in [1], because it's currently
>> not an itch; apart from the obvious symmetry, I d
On Mon, Mar 18, 2013 at 1:29 AM, Konstantin Khomoutov
wrote:
> FYI, I've already tried to answer this exact question [1] with no
> comments from the OP.
>
> 1. http://serverfault.com/a/488604/118848
It is I who posted that question. :P
I haven't made any comments yet because this issue is still
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
>
> and ACK for the whole series, once Junio's points are addressed.
>
> Regarding Junio's readability suggestion: I agree that his versions are
> a bit more readable, albeit at the expense of having to evaluate a bit
> more logic for ea
On Mon, Mar 18, 2013 at 08:26:46PM +0530, Ramkumar Ramachandra wrote:
> > Can we get rid of this duplication by having remote_get_1 take a
> > service-specific default argument? And then each service calls it like:
> >
> > struct remote *remote_get(const char *name)
> > {
> > read_co
Jeff King wrote:
> On Mon, Mar 18, 2013 at 06:46:13PM +0530, Ramkumar Ramachandra wrote:
>
>> +struct remote *remote_get(const char *name)
>> +{
>> + int name_given = 0;
>> +
>> + read_config();
>> + if (name)
>> + name_given = 1;
>> + else {
>> + name = defa
On Mon, Mar 18, 2013 at 07:58:23PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
> >> Documentation/config.txt | 23 ---
> >> builtin/push.c | 2 +-
> >> remote.c | 60
> >
On Mon, Mar 18, 2013 at 06:46:13PM +0530, Ramkumar Ramachandra wrote:
> +struct remote *remote_get(const char *name)
> +{
> + int name_given = 0;
> +
> + read_config();
> + if (name)
> + name_given = 1;
> + else {
> + name = default_remote_name;
> +
Jeff King wrote:
> On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
>> Documentation/config.txt | 23 ---
>> builtin/push.c | 2 +-
>> remote.c | 60
>> +++-
>> remote.h |
On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
> I've put off implementing remote.default corresponding to
> remote.pushdefault, as Jeff suggested in [1], because it's currently
> not an itch; apart from the obvious symmetry, I don't know what
> purpose it serves: why would
Hi Peff,
On Thu, Mar 14, 2013 at 03:39:14AM -0400, Jeff King wrote:
On Thu, Mar 14, 2013 at 03:10:46AM -0400, Jeff King wrote:
> I looked into this a little. The first sticking point is that
> git_config_with_options needs to support the alternate source. Here's a
> sketch of what I think the s
Interesting. 'Implementing sitewide pessimistic locking with p4 typemap',
http://www.perforce.com/perforce/doc.current/manuals/p4sag/03_superuser.htm
l seems to suggest this is all that's needed. I believe we're using the
default configuration, the exclusive lock on all files behaviour was
research
Currently, do_push() in push.c calls remote_get(), which gets the
configured remote for fetching and pushing. Replace this call with a
call to pushremote_get() instead, a new function that will return the
remote configured specifically for pushing. This function tries to
work with the string push
This new configuration variable overrides `remote.pushdefault` and
`branch..remote` for pushes. In a typical triangular-workflow
setup, you would want to set `remote.pushdefault` to specify the
remote to push to for all branches, and use this option to override it
for a specific branch.
Signed-of
A small segment where handle_config() parses the branch.remote
configuration variable can be simplified using git_config_string().
Signed-off-by: Ramkumar Ramachandra
---
remote.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index e53a6eb..45b69d6 10
This new configuration variable defines the default remote to push to,
and overrides `branch..remote` for all branches. It is useful
in the typical triangular-workflow setup, where the remote you're
fetching from is different from the remote you're pushing to.
Signed-off-by: Ramkumar Ramachandra
Hi,
This series follows up a previous discussion with Junio and Jeff [1].
It attempts to support the triangular workflow, where the remote
you're fetching from is not the same as the remote you're pushing to.
`remote..pushurl` has already been discussed, and deemed as a
poor solution to the proble
perf reports memcpy at the the 6th position [1] in "git status -uno"
using index v4, and strbuf_remove() in expand_name_field() accounts
for 25% of that. What we need here is a simple string cut and a
cheaper strbuf_setlen() should be enough. After this change, memcpy
drops down to the 13th positio
I'm closer to my requirement. I have found gitweb simply provide a GUI for
history check
and code comparison. And the git itself is good enough to do the ACL stuff with
hooks.
I already have the following code to deploy the push into its work-tree
===
#!/bin/bash
while
On Sun, Mar 17, 2013 at 08:21:13PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Thu, Jan 31, 2013 at 6:06 PM, Duy Nguyen wrote:
> > On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
> >> Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
> >> space/time trade-off.
> >
> > Follow
On Mon, Mar 18, 2013 at 11:38 AM, Erik Faye-Lund wrote:
> On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano wrote:
>> Daniel Stenberg writes:
>>
>>> On Sun, 17 Mar 2013, Antoine Pelisse wrote:
>>>
> With redirects taken into account, I can't think of any really good way
> around avoiding
[Re-titled, as we are off-topic from the original patch series]
On Sun, Mar 17, 2013 at 05:38:59PM +0100, René Scharfe wrote:
> Am 17.03.2013 06:40, schrieb Jeff King:
> >We do have the capability to roll out to one or a few of our servers
> >(the granularity is not 0.2%, but it is still small).
On Mon, Mar 18, 2013 at 02:30:23PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > I don't think you can avoid the 3-step problem and retain the safety in
> > the general case. Forgetting implementation details for a minute, you
> > have either a 1-step system:
> >
> > 1. Fetch and st
On Sun, Mar 17, 2013 at 01:01:44PM -0700, Junio C Hamano wrote:
> > + * All references in the file that can be peeled are peeled.
> > + * Inversely (and this is more important, any references in the
>
> A missing closing paren after "more important". Also the e-mail
> quote reveals the
On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano wrote:
> Daniel Stenberg writes:
>
>> On Sun, 17 Mar 2013, Antoine Pelisse wrote:
>>
With redirects taken into account, I can't think of any really good way
around avoiding this init...
>>>
>>> Is there any way for curl to initialize SSL
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Yes, and you would need one inotify per directory but you do not
>> have an infinite supply of outstanding inotify watch (wasn't the
>> limit like 8k per a single uid or something?), so the daemon must be
>> prepared to say "I'll watch this,
On 3/18/13 12:35 AM, Junio C Hamano wrote:
> Rob Hoelz writes:
>
>> git push currently doesn't consider pushInsteadOf when
>> using pushurl; this tests and fixes that.
>>
>> If you use pushurl with an alias that has a pushInsteadOf configuration
>> value, Git does not take advantage of it. For ex
Jeff King wrote:
> So the push lookup list is (in order of precedence):
>
> 1. branch.*.pushremote
> 2. remote.pushdefault
> 3. branch.*.remote
> 4. remote.default
> 5. origin
>
> and it solves Junio's issue because the way to say "override my
> remote.pushdefault for this branch" is not
Jeff King wrote:
> I don't think you can avoid the 3-step problem and retain the safety in
> the general case. Forgetting implementation details for a minute, you
> have either a 1-step system:
>
> 1. Fetch and start using config from the remote.
>
> which is subject to fetching and executing ma
[+cc Ingo and Jonathan, as this revisits the "open-code hashcmp" thread
referenced below]
On Sun, Mar 17, 2013 at 01:13:56PM -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > This env comes from jc/sha1-lookup in 2008 (merge commit e9f9d4f), 5
> > years ago. I wonder if it's good eno
On Sun, Mar 17, 2013 at 10:03:37PM -0600, zero modulo wrote:
> $ LDFLAGS="-L/sandbox/builds/lib" CPPFLAGS="-I/sandbox/builds/include"
> ./configure --prefix=$PREFIX
>
> $ make
> […]
> /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function
> `dlfcn_globallookup':
> dso_dlfcn.c:(.text+0x1b): un
88 matches
Mail list logo
