Felipe Contreras felipe.contre...@gmail.com writes:
contrib/remote-helpers/test-bzr.sh | 2 +-
contrib/remote-helpers/test-hg-bidi.sh | 2 +-
contrib/remote-helpers/test-hg-hg-git.sh | 4 ++--
contrib/remote-helpers/test-hg.sh
Michael Haggerty mhag...@alum.mit.edu writes:
On 04/17/2014 09:46 PM, Ronnie Sahlberg wrote:
Switch to using ref transactions in walker_fetch(). As part of the
refactoring
to use ref transactions we also fix a potential memory leak where in the
original code if write_ref_sha1() would fail
Felipe Contreras felipe.contre...@gmail.com writes:
Does this change relate to the moving of main scripts, and if so
how?
Yes.
Before the scripts were not generated, the shebang was '/usr/bin/env python',
that means if the user doesn't have 'python' but 'python2' git-remote-hg would
fail,
Ilya Bobyr ilya.bo...@gmail.com writes:
On 4/21/2014 2:17 PM, Felipe Contreras wrote:
Ilya Bobyr wrote:
Also, most have names that start with either pre- or post-.
It seems reasonable for both pre-update-branch and
post-update-branch to exist.
I don't see what would be the point in that.
Richard Hansen rhan...@bbn.com writes:
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name in PS1 when running in two- or
three-argument mode, construct PS1 to reference a
Junio C Hamano gits...@pobox.com writes:
Richard Hansen rhan...@bbn.com writes:
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name in PS1 when running in two- or
three
Felipe Contreras felipe.contre...@gmail.com writes:
... there are _already_ hooks without pre/post.
Like commit-msg? Yes, it would have been nicer if it were named
verify-commit-message or something.
Old mistakes are harder to change because of inertia. It is not a
good excuse to knowingly
Dan Porter dpr...@gmail.com writes:
I should have updated on this earlier, but I wished to refine my work
on this feature before submitting. With 2.0 looming I'll submit
what's there so far.
I am not Pete, but...
The pre-release time is to find and fix regressions that may have
been
Erik Faye-Lund kusmab...@gmail.com writes:
Shouldn't the latter also be anchored at the beginning of the string
with a leading ^?
+}
+
+require File::Spec::Functions;
+return File::Spec::Functions::file_name_is_absolute($path);
We already use File::Spec qw(something else) at
David Aguilar dav...@gmail.com writes:
[Cc:ing Charles in case he has an opinion, this behavior dates back to the
original MT]
On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
It's annoying to see the prompt:
Hit return to start merge resolution tool (foo):
Every
David Aguilar dav...@gmail.com writes:
On Sun, Apr 20, 2014 at 07:24:20PM -0500, Felipe Contreras wrote:
It's similar to the default, except that the other windows are hidden.
This ensures that removed/added colors are still visible on the main
merge window, but the other windows not visible.
David Aguilar dav...@gmail.com writes:
[Cc:ing Charles in case he has an opinion, this behavior dates back to the
original MT]
On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
It's annoying to see the prompt:
Hit return to start merge resolution tool (foo):
Every
Michael Haggerty mhag...@alum.mit.edu writes:
While we're at it, I think it would be prudent to ban '-' at the
beginning of reference name segments. For example, reference names like
refs/heads/--cmd=/sbin/halt
refs/tags/--exec=forkbomb(){forkbomb|forkbomb};forkbomb
are currently
Andrew Ardill andrew.ard...@gmail.com writes:
As a data point, I have seen people add .gitignore to their
.gitignore file, as they don't want to share the file.
Interesting. It will break immediately when the project starts
wanting to distribute its canonical ignore list, but until that
time,
Jan Kara j...@suse.cz writes:
On Thu 17-04-14 10:04:52, Junio C Hamano wrote:
So perhaps the rule should be updated to do something like:
- find candidate tags that can be used to describe --contains
the commit A, yielding v3.4, v3.5 (not shown), and v9.0;
- among
Sebastian Schuberth sschube...@gmail.com writes:
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are again likely to differ
Ronnie Sahlberg sahlb...@google.com writes:
diff --git a/refs.c b/refs.c
index 138ab70..9daf89e 100644
--- a/refs.c
+++ b/refs.c
@@ -3414,12 +3414,12 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
const char *msg, enum action_on_err onerr)
...
Ronnie Sahlberg sahlb...@google.com writes:
@@ -3481,6 +3481,14 @@ cleanup:
unlock_ref(updates[i]-lock);
free(delnames);
ref_transaction_free(transaction);
+ if (ret) {
+ const char *str = Cannot commit transaction.;
+ switch
Ronnie Sahlberg sahlb...@google.com writes:
This patch series changes most of the places where the ref functions for
locking and writing refs to instead use the new ref transaction API. There
are still three more places where write_ref_sha1() is called from outside
of refs.c but those all
Luis R. Rodriguez mcg...@do-not-panic.com writes:
From: Luis R. Rodriguez mcg...@suse.com
This saves us a few branches when RUN_SETUP is set up.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
Makes sense, especially because there is no sane reason to set both
bits on.
git.c | 2 +-
Richard Hansen rhan...@bbn.com writes:
and plan for transition to forbid them
everywhere in a next big version bump (it is too late for 2.0).
Would it be acceptable to have a config option to forbid these in a
non-major version bump?
Of course ;-) Because we try very hard to avoid a flag
Felipe Contreras felipe.contre...@gmail.com writes:
There's no point in this:
% git merge
fatal: No commit specified and merge.defaultToUpstream not set.
We know the most likely scenario is that the user wants to merge the
upstream, and if not, he can set merge.defaultToUpstream to false.
Kyle J. McKay mack...@gmail.com writes:
Alternatively this change can be made in git-svn.perl:
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
Jonathan Nieder jrnie...@gmail.com writes:
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
...
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches,
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
[...]
That way, normal usage of --prefix would still be consistent with
other git commands that prefer
Junio C Hamano gits...@pobox.com writes:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
A few thinking points that are necessary to be worked out, even
before we start
Matthieu Moy matthieu@grenoble-inp.fr writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Why is not material for v2.0? Because you say so? Are you going to wait
another
ten years to introduce this to v3.0?
There's no need to wait for a 3.0 to introduce this. If these would
brian m. carlson sand...@crustytoothpaste.net writes:
On Tue, Apr 22, 2014 at 03:11:48PM -0700, Jonathan Nieder wrote:
Another possibility would be to require Perl 5.8.9 or newer. It was
released in 2008.
RHEL 5 and CentOS 5 are still shipping with 5.8.8. They are still
security-supported
Kyle J. McKay mack...@gmail.com writes:
So I was trying to use pack.writebitmaps=true and all I got was core dumps.
The fix with a real subject line ;) is below. I think perhaps this should be
picked up for the 2.0.0 release. (Patch is against master.)
Of course---a breakage in a new code
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch has passed v2.0.0-rc0, an early
preview release. There are a handful of topics still in 'next' (and
a few that
Johan Herland jo...@herland.net writes:
I.e. use Kyle's patch to t9117, plus something like this:
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 5b3c38d..9f579e0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -91,6 +91,9 @@ COMMANDS
David Aguilar dav...@gmail.com writes:
On Tue, Apr 22, 2014 at 10:19 AM, Junio C Hamano gits...@pobox.com wrote:
...
Thanks for CC'ing Charles, by the way. I think his point about
mentioning the change of default somewhere in the documentation
has some merits, and it can be done in a follow
Charles Bailey char...@hashpling.org writes:
The bit of documentation that I was thinking of is in
Documentation/git-mergetool.txt where it states that --prompt is the
default which is now only partially true.
Thanks for being careful to help tying the loose ends.
Perhaps like this?
I take
Robert Dailey rcdailey.li...@gmail.com writes:
[Administrivia: because people read from top to bottom / why is it
bad to top-post? / please do not top-post.]
On Tue, Apr 22, 2014 at 4:37 PM, Junio C Hamano gits...@pobox.com wrote:
Robert Dailey rcdailey.li...@gmail.com writes:
git log log
Michael S. Tsirkin m...@redhat.com writes:
As suggested by Junio.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Ehh, I would probably not suggest such an implementation though.
test_write_lines () {
printf %s\n $@
}
might be, but not with echo and
Are these three patches the same as what has been queued on
mt/patch-id-stable topic and cooking in 'next' for a few weeks?
--
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
Michael S. Tsirkin m...@redhat.com writes:
The test is very basic and can be extended.
Couldn't find a good existing place to put it,
so created a new file.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
t/t4056-diff-order.sh | 63
Tim Chase g...@tim.thechases.com writes:
Reading up on git help update-ref, it states that it updates the
name safely.
I think that description is well intended but is misleading. There
are many potential sources of risk, and the safely refers to
protection against a particular kind of risk:
Jonathan Nieder jrnie...@gmail.com writes:
Tim Chase wrote:
cd .git/refs
mkdir -p closed
mv heads/BUG-123 closed
That breaks with packed refs (see git-pack-refs(1)), which are a normal
thing to encounter after garbage collection.
Specifically,
- if BUG-123 branch was placed in
Ilya Bobyr ilya.bo...@gmail.com writes:
Most arguments that could be provided to a test have short forms.
Unless documented, the only way to learn them is to read the code.
Signed-off-by: Ilya Bobyr ilya.bo...@gmail.com
---
t/README |8
1 files changed, 4 insertions(+), 4
Ilya Bobyr ilya.bo...@gmail.com writes:
@@ -187,10 +192,70 @@ and either can match the t[0-9]{4} part to skip the
whole
test, or t[0-9]{4} followed by .$number to say which
particular test to skip.
-Note that some tests in the existing test suite rely on previous
-test item, so you
Max Horn m...@quendi.de writes:
That said, I don't know what the criteria are for moving something out
of contrib.
Because we accept stuff to contrib/, with an assumption that it is
to stay there without contaminating the main part of the system, the
quality of stuff in contrib/ can be sub-par
Max Horn m...@quendi.de writes:
[Administrivia: please wrap your lines to reasonable length like 70-75].
On 21.04.2014, at 22:37, Felipe Contreras felipe.contre...@gmail.com
wrote:
The remote-helpers in contrib/remote-helpers have proved to work, be
reliable, and stable. It's time to move
Robert Dailey rcdailey.li...@gmail.com writes:
On Wed, Apr 23, 2014 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
Robert Dailey rcdailey.li...@gmail.com writes:
[Administrivia: because people read from top to bottom / why is it
bad to top-post? / please do not top-post.]
On Tue, Apr
Jeff King p...@peff.net writes:
On Wed, Apr 23, 2014 at 02:42:38PM -0500, Felipe Contreras wrote:
It is what the clients of this library expect.
Is it? Passing GIT_DIR to sub-invocations of git will change how they
determine the repo and working tree. Your patch seems to cause failures
all
Felipe Contreras felipe.contre...@gmail.com writes:
This hook is invoked before a branch is updated, either when a branch is
created or updated with 'git branch', or when it's rebased with 'git
rebase'. It receives three parameters; the name of the branch, the
SHA-1 of the latest commit, and
Felipe Contreras felipe.contre...@gmail.com writes:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Why is this a good change? From a zero-line log message, I cannot
even tell if this is trying to fix some problem, or trying to give
new capabilities to hooks.
How does it prevent
Jeff King p...@peff.net writes:
On Wed, Apr 23, 2014 at 12:12:14PM -0700, Junio C Hamano wrote:
+ulimit_stack=ulimit -s 64
+test_lazy_prereq ULIMIT 'bash -c '$ulimit_stack''
With this implementaion, ULIMIT implies bash, and we use bash that
appears on user's PATH that may not be the one
Jeff King p...@peff.net writes:
On Wed, Apr 23, 2014 at 01:48:05PM -0700, Junio C Hamano wrote:
I don't think so. The point is that we _must_ use bash here, not any
POSIX shell.
Sorry, but I do not understand. Isn't what you want any POSIX
shell with 'ulimit -s 64' supported?
Sure
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
This hook is invoked before a branch is updated, either when a branch is
created or updated with 'git branch', or when it's rebased with 'git
rebase
Felipe Contreras felipe.contre...@gmail.com writes:
The very unlikely issue that nobody has reported about hg multiple heads and
gc
I just fixed, and the issue he just reported about 'foo' and 'foo/bar' is
newly
reported, and there's no easy way to fix this.
I would not judge on
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Apr 23, 2014 at 10:39:23AM -0700, Junio C Hamano wrote:
Are these three patches the same as what has been queued on
mt/patch-id-stable topic and cooking in 'next' for a few weeks?
Not exactly - at your request I implemented git config
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
... there are _already_ hooks without pre/post.
Like commit-msg? Yes, it would have been nicer if it were named
verify-commit-message or something
Felipe Contreras felipe.contre...@gmail.com writes:
I have a branch which should always be recompiled on update;
post-update-branch would be a good place for that.
And why would pre-update-branch not serve that purpose?
Because the code that needs to be compiled is not yet in the
Jiri Slaby jsl...@suse.cz writes:
Which is passed on to git diff. I very need this option instead of
changing the terminal size.
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
Interesting. I wonder if that suggests perhaps the default may be
better if it were --stat=80 regardless of your
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Apr 23, 2014 at 03:05:42PM -0700, Junio C Hamano wrote:
After comparing the patches 4-6 and the one that has been in 'next'
for a few weeks, I tried to like the new one, but I couldn't.
I'm fine with the one in next too.
I was under
Junio C Hamano gits...@pobox.com writes:
Perhaps like this?
I take that your original motivation was to confirm to run a tool on
this particular (as opposed to another) path, but the user can also
take the prompt as to confirm to run this (as opposed to some other)
tool. The latter
Jonathan Nieder jrnie...@gmail.com writes:
Michael S. Tsirkin wrote:
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -712,6 +712,11 @@ test_ln_s_add () {
fi
}
+# This function writes out its parameters, one per line
+test_write_lines () {
+printf %s\n $@;
+}
Martin Erik Werner martinerikwer...@gmail.com writes:
Fix a buffer over-stepping issue triggered by providing an absolute path
that is similar to the work tree path.
abspath_part_inside_repo() may currently increment the path pointer by
offset_1st_component() + wtlen, which is too much,
Michael S. Tsirkin m...@redhat.com writes:
The test is very basic and can be extended.
Couldn't find a good existing place to put it,
so created a new file.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
t/t4056-diff-order.sh | 63
David Kastrup d...@gnu.org writes:
d...@mailtor.net writes:
It would be nice if we could change the flags to either
a) avoid cutting off
b) indicate something has been cut off (- I prefer this)
I assume there are more people with a similar workflow who're still
unaware of this feature.
Jonathan Nieder jrnie...@gmail.com writes:
Should the internal patch-id computation used by commands like 'git
cherry' (see diff.c::diff_get_patch_id) get the same change? (Not a
rhetorical question --- I don't know what the right choice would be
there.)
I thought about it but I did not
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
Traditionally, because the tool grew in a context of being used in a
project whose participants are at least not malicious, always having
to be on the lookout for fear of middle-of-line tabs hiding bad
contents near
Jeff King p...@peff.net writes:
I would think it's the opposite. Long lines look _horrible_ without
-S, as they get wrapped at awkward points. Using -S means that long
lines don't bug you, unless you really want to scroll over and see the
content.
I really think the right solution here is
Michael S. Tsirkin m...@redhat.com writes:
+--unstable::
+ Use a non-symmetrical sum of hashes, such that reordering
What is a non-symmetrical sum?
Non-symmetrical combination function is better?
I do not think either is very good X-.
The primary points to convey for --stable are:
-
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch is at v2.0.0-rc1. Last minute fixes
to newly added code keep flowing in, which is good.
You can find the
for translators in diffstat generation
i18n: only extract comments marked with TRANSLATORS:
Johan Herland (1):
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given
Junio C Hamano (3):
i18n: mention TRANSLATORS: marker in Documentation/CodingGuidelines
Update
Suvorov Ivan sv...@inbox.ru writes:
I want to extend the functionality of git due to the possibility of
separation of the user repository into 2 parts - one part will be
stored as usual, under version control git, and the second part will
be stored in another location such as an FTP-server.
Jeff King p...@peff.net writes:
[+cc Duy, whose patch this is]
On Fri, Apr 25, 2014 at 04:10:49PM -0400, Jörn Engel wrote:
A second option is to add a --pager (or rather --no-pager) option to
the command line and allow the user to specify
GIT_PAGER=git --no-pager -p column
David Kastrup d...@gnu.org writes:
Includes reasonably tasteful begging.
Thanks, but no thanks---I do not see it tasteful.
In any case, any large change that is not a regression fix (or a fix
to a code added since 1.9 series) is way too late for 2.0 at this
point, but I do look forward to
Felipe Contreras felipe.contre...@gmail.com writes:
So you grant that there is no reason anybody can think of why we would ever
want a post-update-branch?
No, it only shows that you (and I) are not imaginative enough
(and/or we didn't bother spending enough brain cycles) to come up
with an
Christian Couder chrisc...@tuxfamily.org writes:
From: Junio C Hamano gits...@pobox.com
Christian Couder chrisc...@tuxfamily.org writes:
...
+ trailer. After some alphanumeric characters, it can contain
+ some non alphanumeric characters like ':', '=' or '#' that will
+ be used
Jeff King p...@peff.net writes:
On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote:
Suvorov Ivan sv...@inbox.ru writes:
I want to extend the functionality of git due to the possibility of
separation of the user repository into 2 parts - one part will be
stored as usual
brian m. carlson sand...@crustytoothpaste.net writes:
CCS=`echo -e $CMT_MSG\n$HEADERS | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \
-e 's/^Signed-off-by: \(.*\)/\1,/gp'`
It looks like you may have missed a usage here due to the line break.
Good eyes ;-)
The following may be an obvious
Max Kirillov m...@max630.net writes:
Obviously, the feature would necessarily have to be optional, simply
because Git would have to keep understanding the old commit object
format for a LONG time (probably indefinitely), and there's nothing
you can do to prevent others from creating old-style
Jeff King p...@peff.net writes:
This patch just adds a test to demonstrate the breakage.
Some possible fixes are:
...
2. Do all index filename comparisons using a UTF-8 aware
comparison function when core.precomposeunicode is set.
This would probably have bad performance, and
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
brian m. carlson sand...@crustytoothpaste.net writes:
CCS=`echo -e $CMT_MSG\n$HEADERS | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \
-e 's/^Signed-off-by: \(.*\)/\1,/gp'`
It looks like you may have
Erik Faye-Lund kusmab...@gmail.com writes:
On Mon, Apr 28, 2014 at 5:35 PM, Stepan Kasal ka...@ucw.cz wrote:
From: theoleblond theodore.lebl...@gmail.com
Date: Wed, 16 May 2012 06:52:49 -0700
...
I also tested the very fast local case, and didn't see any measurable
difference. On a big
Jeff King p...@peff.net writes:
On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
* jk/external-diff-use-argv-array (2014-04-21) 6 commits
(merged to 'next' on 2014-04-22 at e6d92d7)
+ run_external_diff: refactor cmdline setup logic
+ run_external_diff: hoist common bits
Jeremy Morton ad...@game-point.net writes:
But surely, it's recommended with Git that you try to avoid doing
--no-ff merges to avoid commit noise?
That is a misconception, I am afraid, coming from two different
camps.
Some projects do not want any merges for whatever reason, not
limited to
Marat Radchenko ma...@slonopotamus.org writes:
Problem #1: TortoiseGit GUI windows for common tasks have a heck
lots of controls that a common Git user will never need.
Do people around TortoiseGit lurk on this list? Otherwise this may
not be something we can help you with here.
Problem #2
Erik Faye-Lund kusmab...@gmail.com writes:
We're using Curl 7.30.0 in msysGit (and thus also Git for Windows), so
we should be able to include it. However, we do not have curl-config
installed.
Hmmm, between 2.0-rc0 and 2.0-rc1 there is 61a64fff (Makefile: use
curl-config to determine curl
Jeff King p...@peff.net writes:
On Mon, Apr 28, 2014 at 02:22:21PM +0200, Matthieu Moy wrote:
I'd be OK with doing the moral equivalent for now (perhaps just taking
Junio's proposal[1]), and I can deal with the refactoring later when
re-rolling the Makefile series.
-Peff
[1]
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
But still, I am not convinced that the release notes is a good place
to do this, and would be happier if you can think of a better venue.
This change has been contributed by an independent developer
'Dave Borowitz dborow...@google.com' via msysGit
msys...@googlegroups.com writes:
I think I should probably re-roll the patch to default to the old
behavior (blind -lcurl) if curl-config returns the empty string, which
I believe is also the case when the binary is not found.
Thanks for a
Dave Borowitz dborow...@google.com writes:
Use this only when CURLDIR is not explicitly specified, to continue
supporting older builds. Moreover, if CURL_CONFIG is unset or running
it returns no results (e.g. because it is missing), default to the old
behavior of blindly setting -lcurl.
Junio C Hamano gits...@pobox.com writes:
That does not mean the patch will give us a broken behaviour,
though. It just means the ifeq/else part will be redundant.
endif
+
+ifeq $(CURL_LIBCURL)
This will catch the $(shell $(CURL_CONFIG) --libs) assigned an
empty string
Dave Borowitz dborow...@google.com writes:
On Mon, Apr 28, 2014 at 1:05 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Dave Borowitz wrote:
Instead, if CURL_CONFIG is empty or returns an empty result (e.g. due
to curl-config being missing), use the old behavior of falling back to
-lcurl.
Junio C Hamano gits...@pobox.com writes:
This ifeq is redundant and will never set CURL_LIBCURL to empty
without running the else part, I think. In a Makefile, a variable
explicitly set to empty and a variable that is unset are treated the
same
$ make -f Makefile CURL_CONFIG
Jonathan Nieder jrnie...@gmail.com writes:
Gah. Maybe it should be left-justified to avoid accentally breaking
it again.
;-). Yes, $(error) is not the usual part of to build this target,
follow this recipe part.
But let's take the last round as-is and go with it for 2.0.
Tahnks.
--
To
Dave Borowitz dborow...@google.com writes:
The original implementation of CURL_CONFIG support did not match the
original behavior of using -lcurl when CURLDIR was not set. This broke
implementations that were lacking curl-config but did have libcurl
installed along system libraries, such as
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-interpret-trailers.txt | 98
+++-
1 file changed, 97 insertions(+), 1 deletion(-)
Very good to have these examples. They seem to be
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The read penalty is not addressed here, so I still pay 14MB hashing
cost.
Hmm, yeah, the cost for verify_hdr() would still matter, and
presumably you would be hashing the additional 200kB to validate the
smaller changes since the base file to
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/cache.h b/cache.h
index 0f6247c..90a5998 100644
--- a/cache.h
+++ b/cache.h
@@ -135,6 +135,7 @@ struct cache_entry {
unsigned int ce_mode;
unsigned int ce_flags;
unsigned int ce_namelen;
+ unsigned int
Jörn Engel jo...@logfs.org writes:
On Mon, 28 April 2014 10:14:05 -0700, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
- Original Message -
On Sun, Apr 27, 2014 at 09:12:39AM +0700, Duy Nguyen wrote:
The intent of the commit was that is a stupid
Jean-Noël Avila avila...@gmail.com writes:
Most manuals on git state that it is bad practice to push -f a branch
after have meddled with its history, because this would risk to upset
the repositories of the coworkers. On the other hand, some workflows
use branches to propose modifications,
Felipe Contreras felipe.contre...@gmail.com writes:
Except that in this case virtually everyone agreed the default was wrong. I
already said that.
Clarly you didn't read the relevant discussions where everyone, including
Linus
Torvalds, agreed. Did you?
My recollection is that everybody
Felipe Contreras felipe.contre...@gmail.com writes:
In this context James was talking about what Git should be. But the vast
majority agree on this issue, so that's not what's preventing change.
Sorry, I saw take your patches from James and my patch from you
in the context above that part, and
by Paolo, concise problem description
- rest from Theodore's original commit (I = Theodore, I suppose)
- diff exctly as in gnulib commit
On Mon, Apr 28, 2014 at 11:58:50AM -0700, Junio C Hamano wrote:
Subject: compat/poll: sleep 1 millisecond to avoid busy wait
Thanks for improving
Matthieu Moy matthieu@grenoble-inp.fr writes:
I also agree that droppage of S does not have to wait for that
topic.
So, shall I rewrite my patch on top of master? (not hard, but there will
be a minor conflict to resolve when merging with Peff's cooking series).
Sure, the one near the
1201 - 1300 of 27729 matches
Mail list logo
