Duy Nguyen wrote:
libgit.a is just a way of grouping a bunch of objects together, not a
real library and not meant to be. If you aim something more organized,
please show at least a roadmap what to move where.
Exactly. There are some rough plans I would like to help with in the
direction of
Ramkumar Ramachandra wrote:
How else am I supposed to write them? If there is a stale state from
the previous test, there isn't too much I can do. Or should I be
cleaning up state at the beginning of each test, instead of at the
end?
That's one strategy. test_when_finished to restore the
Felipe Contreras wrote:
This has nothing to do with better strategy, it has everything to do
with gut feelings and tradition. Not reasons.
I try to help you, and you insult me. I don't think this is worth it.
If I were managing this list, I would ban mails from you, since this
discussion
Felipe Contreras wrote:
Just the past three months I've probably done more work than anybody
else[1], and you would ban me because you don't like my words?
Definitely, yes. Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
is
Felipe Contreras wrote:
A collegial work environment is overrated, and proof of that the Linux
kernel, where honest and straight talk is the bread and butter of the
mailing list.
An aside, since it doesn't bear too much on the topic at hand:
For what it's worth, in my experience the people
Jeff King wrote:
My advice would be to ignore him when the discussion proceeds in an
unproductive direction.
There is something appealing about that option. The problem is that
it doesn't work, at least for someone that relies on the list as a way
of understanding patches that have been
in /etc/bash_completion.d/* finds
similar breakage (removal of '=' and '@') in the npm completion
script, but nothing involving colon. So this looks like a good
change.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Junio C Hamano wrote:
0. You do not take offense, no matter what. If someone attacks
you irrationally, you do not respond. This is a public mailing
list, and we are all rational people: the attacker has already
humiliated herself in public, and everyone can see that.
[...]
Hi Paul,
Paul Menzel wrote:
there are people out there disliking elaborate commit messages, as going
over `git log` is tedious as you have to scroll a lot. As I do not like
the suggestion to make commit messages shorter by omitting certain
details, a way to limit the number displayed lines
Junio C Hamano wrote:
Or inside less that is spawned by git log -p, I often say this:
/^commit .*|^diff --git .*ENTER
and navigate with 'n' and 'p'.
Hm, that implies an interesting trick. If I run
LESS='FRSX +/^commit |^diff --git ' git log -p
then 'n' and shift+'n' can be
Jun 17, 2013 at 01:14:51PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Signed-off-by: John Keeping j...@keeping.me.uk
---
Thanks; will directly apply 1/2 on maint. I am not absolutely sure
about this one, where variables related to an optional info
support used to
Hi Thomas,
Thomas Ackermann wrote:
This target was only used to create user-manual.pdf with dblatex
using a separate style definition than was used for user-manual.html.
These two style definitions had to be maintained separately and
so made improvements to user-manual.html unnecessarily
Thomas Ackermann wrote:
Would generating different XML files
for the PDF and for other purposes (with different names) work as a
way to achieve that without losing the printable manual?
This would be even worse when we have to create different xml depending on
*
It would probably be better to remove the above two lines which are
redundant next to the filename. That can wait for a later patch if
you like, though.
With or without that change,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git
Thomas Ackermann wrote:
When I want to tweak the html generation rules I also have to tweak the pdf
generation rules because html and pdf should be as similiar to each other as
possible.
Ah, *that's* what I missed. Thanks for explaining.
I think it's fine for the html and pdf to look
Phil Hord wrote:
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Yep, still looks good from a quick glance.
Thanks for the quick turnaround.
--
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
Hi,
Richard Hansen wrote:
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -82,6 +82,17 @@ to point at the new commit.
to the top def_directory,directory of the stored
revision.
+[[def_committish]]committish (also commit-ish)::
+ A
Hi,
SZEDER Gábor wrote:
$ git init
Initialized empty Git repository in /tmp/test/.git/
$ git checkout --detach
fatal: You are on a branch yet to be born
Are there some plumbing commands and options that would still allow
this, or can I rely on that that it's impossible?
Michael Schubert wrote:
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -180,7 +180,7 @@ subsequent 'sync' operations.
Import changes into given branch. If the branch starts with
'refs/', it will be used as is. Otherwise if it does not start
with 'p4/',
--- to escape link
text generated programatically, use esc_html($text).
For what it's worth, with or without such a change,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
(Patch left unsnipped for reference.)
+
$logo_url::
$logo_label::
URI and label (title) for the Git logo
Paul A. Kennedy wrote:
If we don't expect this, should we update the documentation for the
--abort heading in the git rebase man page to indicate that newly
staged content will be lost after a git rebase --abort?
How about something along these lines?
diff --git
Hi Dany,
Dany wrote:
I had a pretty sucky thing happen to me today: while remote tracking
a non-master branch, I force pushed. This had the intended effect of
force pushing the branch I was working on, but also the unintended
function of force pushing all branches I wasn't on.
Yeah, I agree
Hi,
Kyle McKay wrote:
The temp_is_locked function can be used to determine whether
or not a given name previously passed to temp_acquire is
currently locked.
[...]
+=item temp_is_locked ( NAME )
+
+Returns true if the file mapped to CNAME is currently locked.
+
+If true is returned, an
(cc-ing Eric Wong, who wrote this code)
Hi,
Kyle McKay wrote:
Temp file with moniker 'svn_delta' already in use at Git.pm line 1250
Temp file with moniker 'git_blob' already in use at Git.pm line 1250
David Rothenberger daver...@acm.org has determined the cause to
be that ra_serf does not
David Rothenberger wrote:
On 7/5/2013 8:41 PM, Kyle McKay wrote:
Daniel Shahaf has suggested also setting
servers:global:http-bulk-updates=on.
I have a patch that does this, but since turning on bulk updates has
a possible performance penalty, I prefer your approach.
I assume that's
Hi,
Junio C Hamano wrote:
We are in the middle of 5th week now in the 11-week releace cycle
for 1.8.4 (http://tinyurl.com/gitCal), and quite a few topics have
graduated to 'master'. I'd expect the rest of the week to be slow.
I'd like this or the next release to be 2.0, so the common user
it.
Put the warning in context by making an analogy to HTTP's security
properties as compared to HTTPS.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks,
Jonathan
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 9ccb246..bd0058f 100644
--- a/Documentation/urls.txt
Mark Levedahl wrote:
Do not use FIFOs on cygwin, they do not work. Cygwin includes
coreutils, so has mkfifo, and that command does something. However,
the resultant named pipe is known (on the Cygwin mailing list at
least) to not work correctly.
Hm. How would you recommend going about
Tony Finch wrote:
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Yep, fwiw this version looks perfect to me. :)
Thanks.
--
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
Kyle McKay wrote:
On Jul 6, 2013, at 17:28, Jonathan Nieder wrote:
David Rothenberger wrote:
On 7/5/2013 8:41 PM, Kyle McKay wrote:
Daniel Shahaf has suggested also setting
servers:global:http-bulk-updates=on.
I have a patch that does this, but since turning on bulk updates has
a possible
Hi,
Szuba, Marek (IKP) wrote:
On the git-svn(1) man page, the third example in the Basic Examples
[...]
$ git checkout -b master FETCH_HEAD
fatal: Cannot update paths and switch to branch 'master' at the same time.
Did you intend to checkout 'FETCH_HEAD' which can not be resolved as commit?
Kyle McKay wrote:
Unless bulk updates are disabled when using the serf access method
(the only one available with svn 1.8) for https?: urls,
apply_textdelta does indeed get called multiple times in a row
without an intervening temp_release.
You mean Unless bulk updates are enabled and
(cc-ing users@ as requested by danielsh)
David Rothenberger wrote:
On 7/6/2013 5:28 PM, Jonathan Nieder wrote:
Is there a simple explanation of why violating the depth-first
constraint would lead to multiple blob (i.e., file, not directory)
deltas being opened in a row without an intervening
-by: Jonathan Nieder jrnie...@gmail.com
--
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
Hi,
Felipe Contreras wrote:
No reason to use the full path in case this is used externally.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
No reason not to is not a reason to do anything. What symptoms does
this prevent? Could you describe the benefit of this patch in a
Elia Pinto wrote:
The shell word splitting done in base is a bashism, iow not portable.
No, ${varname##glob} is in POSIX and we already use it here and there.
See Documentation/CodingGuidelines:
- We use ${parameter#word} and its [#%] siblings, and their
doubled longest matching form.
-by: Felipe Contreras felipe.contre...@gmail.com
With that change, for what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Patch left unsnipped since it doesn't seem to have hit the list.
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
the
other way around.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
For what it's worth, with amended message,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Patch left unsnipped because it hadn't hit the list.
---
t/t9350-fast-export.sh | 6 +++---
1 file changed, 3 insertions
Felipe Contreras wrote:
They have been marked as UNINTERESTING for a reason, lets respect that.
This patch looks unsafe, and in the examples listed in the patch
description the changed behavior does not look like an improvement.
Worse, the description lists a few examples but gives no
Felipe Contreras wrote:
% git fast-export $marks_args one
% git fast-export $marks_args one two
Then yeah, 'one' will be updated once again in the second command,
That's probably worth a mention in the commit message and tests
(test_expect_failure), to save future readers from some
Felipe Contreras wrote:
So you think what we have now is the correct behavior:
% git fast-export master ^master
reset refs/heads/master
from :0
No, I don't think that, either.
Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
Felipe Contreras wrote:
Well, that's what we have now, and you want to preserve this feature
(aka bug), right?
Nope. I just don't want regressions, and found a patch description
that did nothing to explain to the reader how it avoids regressions
more than a little disturbing.
I also think
Felipe Contreras wrote:
On Tue, Oct 30, 2012 at 11:07 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Nope. I just don't want regressions, and found a patch description
that did nothing to explain to the reader how it avoids regressions
more than a little disturbing.
I see, so you don't have
Felipe Contreras wrote:
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,11 +523,16 @@ static void get_tags_and_duplicates(struct object_array
*pending,
typename(e-item-type));
continue;
}
- if
reset refs/heads/master
commit refs/heads/master
mark :1
author Jonathan Nieder jrnie...@gmail.com 1351644412 -0700
committer Jonathan Nieder jrnie...@gmail.com 1351644412 -0700
data 17
My first commit
Felipe Contreras wrote:
I don't think it's my job to explain to you how 'git fast-export'
works.
Actually, if you are submitting a patch for inclusion, it is your job
to explain to future readers what the patch does. Yes, the reader
might not be deeply familiar with the part of fast-export
Felipe Contreras wrote:
On Tue, Oct 30, 2012 at 5:46 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
No reason to use the full path in case this is used externally.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
No reason not to is not a reason to do
Felipe Contreras wrote:
It's not my job to
explain to you that 'git fast-export' doesn't work this way, you have
a command line to type those commands and see for yourself if they do
what you think they do with a vanilla version of git.
Felipe Contreras wrote:
It's all fun and games to write explanations for things, but it's not
that easy when you want those explanations to be actually true, and
corrent--you have to spend time to make sure of that.
That's why it's useful for the patch submitter to write them, asking
for help
Sverre Rabbelier wrote:
Thanks for the thorough explanation. Perhaps some of that could make
it's way into the commit message?
It's fine with me if it doesn't, since the original commit message
covers the basics (current behavior and intent of the change) in its
first two paragraphs and anyone
Felipe Contreras wrote:
On Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
I just tested this with junio/next and it seems this issue is still
unfixed: instead of
reset refs/heads/blub
from e7510461b7db54b181d07acced0ed3b1ada072c8
I get
Junio C Hamano wrote:
We've been hoping we can do without a rigid code of conduct written
down to maintain cordial community focused on technical merits, and
instead relied on people's common sense, but sense may not be so
common, unfortunately, so we may have to have one.
I think that
Kevin wrote:
As I see it, the problem is not the possibility to add new lines, but
colleagues being too lazy to add them.
I suspect the underlying problem is that we make it too hard to tell
git which text editor to run.
Ram, what platform do your colleagues use?
Thanks,
Jonathan
--
To
Jeff King wrote:
If so, then this series isn't regressing behavior; the only downside is
that it's an incomplete fix. In theory this could get in the way of the
full fix later on, but given the commit messages and the archive of this
discussion, it would be simple enough to revert it later in
Hi Ram,
Ramkumar Ramachandra wrote:
59893a88 (Documentation/log: add a CONFIGURATION section, 2010-05-08)
mentioned that `format.pretty` is the default for the `--format`
option. Such an option never existed,
False. Have you tried it?
Thanks,
Jonathan
--
To unsubscribe from this list:
Ramkumar Ramachandra wrote:
Oops, I read about `--pretty` in pretty-formats.txt and didn't realize
that `--format` existed. However, your patch is still wrong because
there seems to be a subtle (and confusing) difference between
`--pretty` and `--format`. In the latter, you can't omit the
Max Horn wrote:
Aha, now I understand what this patch is about. So I would suggest
this alternate commit message:
remote-testgit: make it explicit clear that we use the 'done' feature
Previously we relied on passing '--use-done-feature ' to git
fast-export, which is easy to miss when
-rc1~15^2~18 (2012-05-21) the var is only written in ident.c,
and the variable can finally be made static.
This patch finally does that, which is a nice way to make cache.h
easier to read and change less often.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe
Jeff King wrote:
This patch lets callers specify multiple variables, and
prints one per line.
Yay!
[...]
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -9,11 +9,16 @@ git-var - Show a git logical variable
SYNOPSIS
[verse]
-'git var' ( -l | variable )
Jeff King wrote:
Internally, we keep track of whether the author or committer
ident information was provided by the user, or whether it
was implicitly determined by the system. However, there is
currently no way for external programs or scripts to get
this information
What are the intended
Jeff King wrote:
git var recently learned to report on whether an ident we
fetch from it was configured explicitly or implicitly. Let's
make that information available to callers of the ident
function.
Sounds sensible. Quick nits:
[...]
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -737,7
for the default, the prompt
is a safety check in case git generated an incorrect
implicit ident string.
I haven't read the code carefully, but this behavior sounds sensible,
so for what it's worth,
Acked-by: Jonathan Nieder jrnie...@gmail.com
[...]
The test scripts need to be adjusted to not expect
Jeff King wrote:
+test_expect_success !LAZY_TRUE 'missing lazy prereqs skip tests' '
I have a visceral nervousness when reading this code, from too much
unpleasant experience of bash's csh-style !history expansion. Luckily
bash does not treat ! specially in the '-o sh' mode used by tests.
Jeff King wrote:
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -738,6 +738,12 @@ test_lazy_prereq UTF8_NFD_TO_NFC '
esac
'
+test_lazy_prereq AUTOIDENT '
+ sane_unset GIT_AUTHOR_NAME
+ sane_unset GIT_AUTHOR_EMAIL
+ git var GIT_AUTHOR_IDENT
+'
Lazy prereq scripts run
Jeff King wrote:
In v1.5.6-rc0~56^2 (2008-05-04) user_ident_explicitly_given
was introduced as a global for communication between config,
ident, and builtin-commit. In v1.7.0-rc0~72^2 (2010-01-07)
readers switched to using the common wrapper
user_ident_sufficiently_given(). After
Jeff King wrote:
1. GIT_COMMITTER_* is set explicitly, but we fallback for
GIT_AUTHOR. We claim the ident is explicit, even though
the author is not.
2. GIT_AUTHOR_* is set and we ask for author ident, but
not committer ident. We will claim the ident is
implicit,
Jeff King wrote:
This patch lets callers specify multiple variables, and
prints one per line.
[...]
Signed-off-by: Jeff King p...@peff.net
Very pleasantly done --- thanks. For what it's worth, assuming this
is tested, I can't see any reason not to apply it.
Reviewed-by: Jonathan Nieder
Jeff King wrote:
Signed-off-by: Jeff King p...@peff.net
For what it's worth,
Acked-by: Jonathan Nieder jrnie...@gmail.com
--
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
GIT_SEND_EMAIL_NOTTY=1 \
git send-email --smtp-server=... $patches /dev/null
2err
)
test_i18ngrep [Tt]ell me who you are err
For what it's worth, with or without such changes,
Acked-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line
Jeff King wrote:
Yes. You can test it yourself with bash t-basic.sh. The reason is
that the ! is part of history expansion, which is only enabled by
default for interactive shells.
Nice to hear. Thanks much for looking into it.
On Wed, Nov 14, 2012 at 11:46:58PM -0800, Jonathan Nieder
SZEDER Gábor wrote:
The 'basic' test uses 'grep -q' to filter the resulting possible
completion words while looking for the presence or absence of certain
git commands, and relies on grep's exit status to indicate a failure.
[...]
To make testers' life easier provide some output about the
SZEDER Gábor wrote:
Fix this by passing the command line to run_completion() as separate
words.
Good catch. The change makes sense, the code looks saner after the
fix, and since this is test code any breakage should be caught
quickly, so
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
I've tried, including
bash, keeps the $ unmolested.
Other parts of the file already use the same style, so I wouldn't
suggest changing it in this patch.
Thanks for some nice tests.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git
SZEDER Gábor wrote:
The breakage can
be simply bogus possible completion words, but it can also be a
failure:
$ git branch '${foo.bar}'
$ git checkout TAB
bash: ${foo.bar}: bad substitution
Or arbitrary code execution:
$
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Of course, transport-helper shouldn't even be specifying the negative
(^) refs, but that's another story.
Hrm, I am not sure I understand what you mean by this.
How should it be telling the fast-export up to what
Hi Peff,
Jeff King wrote:
--- a/read-cache.c
+++ b/read-cache.c
@@ -1800,6 +1800,8 @@ int write_index(struct index_state *istate, int newfd)
continue;
if (!ce_uptodate(ce) is_racy_timestamp(istate, ce))
Jeff King wrote:
I can't reproduce here. I can checkout v3.2.35, and I guess that the
patch you are applying comes from f5f1654, but I don't know your
local modification to sound/usb/midi.c.
No local modification. The unstaged change after git am --abort to
recover from a conflicted git am
Jeff King wrote:
Can you give more details?
$ GIT_TRACE=1 git am --abort
trace: exec: 'git-am' '--abort'
trace: run_command: 'git-am' '--abort'
trace: built-in: git 'rev-parse' '--parseopt' '--' '--abort'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse'
Jeff King wrote:
Hrm. But your output does not say there is a conflict. It says you have
a local modification and it does not try the merge:
That's probably operator error on my part when gathering output to
paste into the email.
In other words, nothing to see there. :) Sorry for the
the reconfiguration process only trigger for
changes to configure.ac's logic. Tweak the Makefile rule to match
that intent by depending on configure.ac instead of configure.
Reported-by: Martin von Zweigbergk martinv...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
[...]
--- a/Makefile
+++ b
Hi,
Eric S. Raymond wrote:
Junio C Hamano gits...@pobox.com:
So..., is this a flag-day patch?
After this is merged, users who have been interoperating with CVS
repositories with the older cvsps have to install the updated cvsps
before using a new version of Git that ships with it?
Yes,
von Zweigbergk martinv...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Martin von Zweigbergk wrote:
The next line just outside the context here does depend on
'configure', which is why I thought this would not be right.
Yes, the 'configure' script that is run needs to reflect
Jonathan Nieder wrote:
Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if
configure.ac changes, 2012-07-19), configure is automatically run
every time the configure script changes. In particular, that
means configure is automatically rerun whenever the version number
changes
Jeff King wrote:
It seems I am late to the party. But FWIW, this looks the most sane to
me of the patches posted in this thread.
Thanks. config.status runs ./configure itself, though, so the rule
should actually be
config.status: configure.ac
$(QUIET_GEN)$(MAKE)
Eric S. Raymond wrote:
Jonathan Nieder jrnie...@gmail.com:
The former is already loudly advertised in the package description and
manpage, at least lets you get work done, and works fine for simple
repositories with linear history.
Two of the three claims in this paragraph are false.
Give
lifetimes clearer are valuable anyway), this
looks useful as a debugging tool when people on strange platforms
report problems. And unlike the trick I sent a while ago, it doesn't
involve recompiling git. So for what it's worth,
Acked-by: Jonathan Nieder jrnie...@gmail.com
Thanks
Eric S. Raymond wrote:
Michael Haggerty wants me to trust that cvs2git's analysis stage has
been fixed, but I must say that is a more difficult leap of faith when
two of the most visible things about it are still (a) a conspicuous
instance of interface misdesign, and (b) documentation that is
Eric S. Raymond wrote:
---
Missing sign-off. Depending on when you prefer to add the sign-off, something
like
echo '[alias] c = commit --signoff' ~/.gitconfig
or
echo '[alias] f = format-patch --signoff' ~/.gitconfig
might be useful for the future, assuming you already look
John Keeping wrote:
The --done option to git-fast-import is documented twice in its manual
page. Combine the best bits of each description, keeping the location
of the instance that was added first.
Signed-off-by: John Keeping j...@keeping.me.uk
Good catch, thanks.
Reviewed-by: Jonathan
John Keeping wrote:
When building manual pages, the source text is transformed to XML with
AsciiDoc before the man pages are generated from the XML with xmlto.
Fix the dependency in the Makefile so that the XML files are rebuilt
when asciidoc.conf changes and not just the manual pages from
René Scharfe wrote:
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -153,6 +153,8 @@ static unsigned int ustar_header_chksum(const struct
ustar_header *header)
static size_t get_path_prefix(const char *path, size_t pathlen, size_t
maxlen)
{
size_t i = pathlen;
+ if (i 1 path[i
Jeff King wrote:
I happened to notice this while looking at the sigpipe topic. I guess
not many people are building with NO_PTHREADS these days.
Or that those people don't build next. :)
Thanks for catching it.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Jeff King wrote:
I'd expecting cooking this patch for a while
would flush out any I missed.
Heh, probably not. ;-) But I tried to examine all the callsites (and
only found the two messages I mentioned), and among the reviewers, I'm
guessing we hit them all.
Ciao,
Hi Manlio,
Manlio Perillo wrote:
Many C projects I have seen (based on autoconf, but not always - like
Nginx) allow the project to be build in a separate directory, in order
to avoid to pollute the working directory with compiled files.
Unfortunately this seems to not be possible with Git.
Duy Nguyen wrote:
And
because junk_work_tree is not set up for --bare, I guess we still need
to fix --bare --separate-git-dir case, or forbid it because i'm not
sure if that case makes sense at all.
Forbidding it makes sense to
Hi,
Torsten Bögershausen wrote:
Stephen Linda Smith wrote:
git co 9fca6c make all
... The make errored out as before
[...]
git co 9fca6c^ make all
... and this compiles to completion
CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
i686 Cygwin
[...]
You can either
Torsten Bögershausen wrote:
The short version:
Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
[...]
I don't know if we want to improve the Makefile to enable
CYGWIN_V15_WIN32API = YesPlease
for cygwin versions 1.7.1 .. 1.7.16 (which are outdated)
Confusing.
Nguyễn Thái Ngọc Duy wrote:
--separate-git-dir was added to clone with the repository away from
standard position worktree/.git. It does not make sense to use it
without creating working directory.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
The patch correctly implements the
the dependencies from a recipeless rule to the
rules with commands that use asciidoc.conf to make the dependencies
easier to understand and maintain.
Reported-by: John Keeping j...@keeping.me.uk
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Junio C Hamano wrote:
Care to do a real patch
Mark Levedahl wrote:
However, the newer
win32api is provided only for the current cygwin release series, which can
be reliably identified by having dll version 1.7.x, while the older frozen
releases (dll versions 1.6.x from redhat,
601 - 700 of 2895 matches
Mail list logo
