On Mon, May 05, 2014 at 12:45:30AM -0500, Felipe Contreras wrote:
Jeff King wrote:
On Sun, May 04, 2014 at 01:12:53AM -0500, Felipe Contreras wrote:
So it looks like gcc is smarter now, and in trying to fix a few warnings
we generated hundreds more.
This reverts commit
Jeff King wrote:
On Mon, May 05, 2014 at 12:45:30AM -0500, Felipe Contreras wrote:
Jeff King wrote:
On Sun, May 04, 2014 at 01:12:53AM -0500, Felipe Contreras wrote:
So it looks like gcc is smarter now, and in trying to fix a few warnings
we generated hundreds more.
On Mon, May 05, 2014 at 01:14:43AM -0500, Felipe Contreras wrote:
Jeff King wrote:
On Mon, May 05, 2014 at 12:45:30AM -0500, Felipe Contreras wrote:
Jeff King wrote:
On Sun, May 04, 2014 at 01:12:53AM -0500, Felipe Contreras wrote:
So it looks like gcc is smarter now, and
Hello,
On Mon, May 05, 2014 at 12:55:52AM +0400, Marat Radchenko wrote:
On Sun, May 04, 2014 at 08:52:44PM +0200, Stepan Kasal wrote:
is really a work around: it would be in effect only for MinGW-W64,
and the comment would explain that this is a hack to work around the
bug.
Jeff King wrote:
On Mon, May 05, 2014 at 01:14:43AM -0500, Felipe Contreras wrote:
Jeff King wrote:
You could try reading the commit message of the commit you are
reverting, which explains it, but the short answer is: try compiling
with -O3.
Sigh. And I'm the one with the
Stepan Kasal wrote:
diff --git a/config.mak.uname b/config.mak.uname
index 82b8dff..446dd41 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -508,7 +508,11 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_POSIX_GOODIES = UnfortunatelyYes
DEFAULT_HELP_FORMAT = html
Hi,
I'm trying to script a setup that would periodically import a tarball
to git with fast-import. But things do not always change, so I'd like
fast-import to be able to not do the commit in case there is no change.
That is, I'm constructing the commit with deleteall + importing each
object by
Andreas Schwab sch...@linux-m68k.org writes:
Johannes Sixt j...@kdbg.org writes:
Isn't internal padding only allowed between members to achieve correct
alignment of later members, and at the end only sufficient padding so
that members are aligned correctly when the struct is part of an
David Kastrup d...@gnu.org writes:
It does not as far as I can see guarantee that a pointer to something
of the same type of its first member can be converted to a pointer to
a struct even if the struct only contains a member of such type.
This sentence doesn't make any sense. If you have an
On 5 May 2014 19:23:06 GMT+10:00, Andreas Schwab sch...@linux-m68k.org wrote:
David Kastrup d...@gnu.org writes:
It does not as far as I can see guarantee that a pointer to something
of the same type of its first member can be converted to a pointer to
a struct even if the struct only contains
Andreas Schwab sch...@linux-m68k.org writes:
David Kastrup d...@gnu.org writes:
It does not as far as I can see guarantee that a pointer to something
of the same type of its first member can be converted to a pointer to
a struct even if the struct only contains a member of such type.
This
Well, I'm on Windows.
using `git version 1.9.2.msysgit.0`.
You can find all the exchanges, recorded with wireshark, of the
following usecases:
* git vanilla (not working),
* VisualStudio2013 with libgit (working)
* curl (--ntlm, working)
* curl (--negotiate, not working)
They're available on
On Mon, May 5, 2014 at 12:13 AM, David Kastrup d...@gnu.org wrote:
The default of 16m causes serious thrashing for large delta chains
combined with large files.
Here are some benchmarks (pu variant of git blame):
time git blame -C src/xdisp.c /dev/null
...
diff --git
On Mon, May 5, 2014 at 5:26 PM, Duy Nguyen pclo...@gmail.com wrote:
part. Would it make more sense to advise git devs to set this per repo
s/advise git devs/advise emacs devs/
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On 05/05/2014 11:50 AM, David Kastrup wrote:
The case we are talking about is basically passing a pointer to some
actual bonafide toplevel unsigned char [20] object to a routine that
expects a pointer to a struct _only_ containing one such
unsigned char [20] element.
This is the situation
On Wed, Apr 30, 2014 at 9:46 PM, Sebastian Schuberth
sschube...@gmail.com wrote:
On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
We can keep this patch in the msysGit repo for the 2.0 release.
FWIW the plan is to switch to mingwGitDevEnv for the 2.0
On Mon, May 5, 2014 at 12:53 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
FWIW the plan is to switch to mingwGitDevEnv for the 2.0 release. It is
not quite clear as of yet how patches will be managed with said
environment.
The environment is just that: The environment to build Git for
Duy Nguyen pclo...@gmail.com writes:
On Mon, May 5, 2014 at 12:13 AM, David Kastrup d...@gnu.org wrote:
The default of 16m causes serious thrashing for large delta chains
combined with large files.
Here are some benchmarks (pu variant of git blame):
time git blame -C src/xdisp.c /dev/null
David Kastrup d...@gnu.org writes:
Your premise is _not_ assumed in my statement. My premise was a
pointer to something of the same type of [the struct's] first member.
That does quite explicitly _not_ state that an object of struct type is
in existence.
So you are not taking about struct
Duy Nguyen pclo...@gmail.com writes:
On Mon, May 5, 2014 at 12:13 AM, David Kastrup d...@gnu.org wrote:
The default of 16m causes serious thrashing for large delta chains
combined with large files.
Here are some benchmarks (pu variant of git blame):
time git blame -C src/xdisp.c /dev/null
On 04/22/2014 08:45 PM, Ronnie Sahlberg wrote:
This change is based on the previous ref transaction patches.
This is sent as a separate patch series since it implements a lot more
non-trivial changes to the behaviour than the previous patches and thus can
use more detailed review.
Update
Andreas Schwab sch...@linux-m68k.org writes:
David Kastrup d...@gnu.org writes:
Your premise is _not_ assumed in my statement. My premise was a
pointer to something of the same type of [the struct's] first member.
That does quite explicitly _not_ state that an object of struct type is
in
On Mon, May 5, 2014 at 6:03 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
-Default is 16 MiB on all platforms. This should be reasonable
+Default is 96 MiB on all platforms. This should be reasonable
for all users/operating systems, except on the largest projects.
You probably do
On Mon, May 05, 2014 at 02:32:11AM -0500, Felipe Contreras wrote:
Stepan Kasal wrote:
+ifneq ($(uname_M),x86_64)
+ # MinGW-W64 x.y headers do not provide MsgWaitForMultipleObjects with
NOGDI
MinGW-w64 != x86_64; it provides a i686 compiler as well.
thanks for correcting me. The
On 05/01/2014 10:37 PM, Ronnie Sahlberg wrote:
This patch series is based on next and expands on the transaction API. [...]
Meta-comment:
Ronnie,
It seems like successive versions of this patch series are growing not
only in maturity but also in breadth. That makes it harder to review them.
On 05/01/2014 10:37 PM, Ronnie Sahlberg wrote:
Update ref_transaction_update() do some basic error checking and return
true on error. Update all callers to check ref_transaction_update() for error.
There are currently no conditions in _update that will return error but there
will be in the
tolga.cey...@gmail.com wrote on Fri, 02 May 2014 22:40 -0700:
This is the error message git-apply emits in this case:
error: cannot apply binary patch to 'filename' without full index line
error: filename: patch does not apply
Cheers,
Tolga
Any feedback is appreciated.
Sorry,
Am 05.05.2014 12:53, schrieb Erik Faye-Lund:
On Wed, Apr 30, 2014 at 9:46 PM, Sebastian Schuberth
sschube...@gmail.com wrote:
On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
We can keep this patch in the msysGit repo for the 2.0 release.
FWIW the plan
On Mon, May 5, 2014 at 5:57 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/01/2014 10:37 PM, Ronnie Sahlberg wrote:
This patch series is based on next and expands on the transaction API. [...]
Meta-comment:
Ronnie,
It seems like successive versions of this patch series are growing
On 2014-05-03 06:00, John Szakmeister wrote:
FWIW, at my company, we took another approach. We introduced a `git
ffwd` command that fetches from all remotes, and fast-forwards all
your local branches that are tracking a remote, and everyone on the
team uses it all the time. It should be said
On Fri, 2014-05-02 at 22:40 -0500, Felipe Contreras wrote:
David Turner wrote:
On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
dturner@ wrote:
Test repository 1: Linux
Linux is about 45k files in 3k directories. The average length of a
filename is about 32 bytes.
David Turner wrote:
On Fri, 2014-05-02 at 22:40 -0500, Felipe Contreras wrote:
David Turner wrote:
On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
dturner@ wrote:
Test repository 1: Linux
Linux is about 45k files in 3k directories. The average length of a
Richard Hansen wrote:
On 2014-05-03 06:00, John Szakmeister wrote:
FWIW, at my company, we took another approach. We introduced a `git
ffwd` command that fetches from all remotes, and fast-forwards all
your local branches that are tracking a remote, and everyone on the
team uses it all
Andreas Schwab wrote:
This thread is about objects of type struct object_id, and their
address is always the same as the address of its first member.
Nothing else is relevant.
Indeed. I suggest you ingore that guy, he will only derail the
discussion.
--
Felipe Contreras
--
To unsubscribe
Hi,
Matthieu Moy wrote:
By default, Git used to set $LESS to -FRSX if $LESS was not set by the
user. The FRX flags actually make sense for Git (F and X because Git
sometimes pipes short output to less, and R because Git pipes colored
output). The S flag (chop long lines), on the other hand,
On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
- remote-hg: trivial cleanups
- remote-hg: make sure we omit multiple heads
- git-remote-hg: use internal clone's hgrc
- t: remote-hg: split into setup test
-
John Keeping wrote:
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary for promoting associated tools when Git was young and had
not established mindshare, Git is now by far the most
On Mon, May 05, 2014 at 02:08:28PM -0500, Felipe Contreras wrote:
John Keeping wrote:
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary for promoting associated tools when Git was
- Original Message -
Hi,
Matthieu Moy wrote:
By default, Git used to set $LESS to -FRSX if $LESS was not set by the
user. The FRX flags actually make sense for Git (F and X because Git
sometimes pipes short output to less, and R because Git pipes colored
output). The S flag
On Mon, May 05, 2014 at 01:20:09PM +0200, David Kastrup wrote:
Would it make more sense to advise git devs to set this per repo
instead? The majority of (open source) repositories out there are
small if I'm not mistaken. Of those few big repos, we could have a
section listing all the tips
Mostly copied from my personal github wiki.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-remote-bzr.txt | 74
Documentation/git-remote-hg.txt | 121 +++
2 files changed, 195 insertions(+)
create
John Keeping wrote:
On Mon, May 05, 2014 at 02:08:28PM -0500, Felipe Contreras wrote:
John Keeping wrote:
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary for promoting
On Mon, May 05, 2014 at 02:30:12AM -0500, Felipe Contreras wrote:
If we have a) code that fixes a couple warnings with -O3 but introduces
hundreds with -O2, vs. b) code that has only a comple warnings with -O3,
I'd go for b) any day.
I agree. But my point was to ask whether we can fix both.
On 5 May 2014 15:09:39 GMT+10:00, Jeff King p...@peff.net wrote:
On Sat, May 03, 2014 at 10:49:35PM +1000, James Denholm wrote:
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index f3834b5..4f96a24 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@
On Sun, May 04, 2014 at 08:13:15AM +0200, Torsten Bögershausen wrote:
1. Tell everyone that NFD in the git repo is wrong, and
they should make a new commit to normalize all their
in-repo files to be precomposed.
This is probably not the right thing to do, because it
On Tue, May 06, 2014 at 07:41:29AM +1000, James Denholm wrote:
I do not think BSD-ism matters for rm, as it works pretty much the
same everywhere. install, on the other hand, is a bit weirder between
systems. So you might want to leave that comment as-is.
True. I might just buff that out
Felipe Contreras wrote:
John Keeping wrote:
I don't see that building against Mercurial's default branch, so it
will not help with future releases.
I can easily add that.
There:
https://travis-ci.org/felipec/git
--
Felipe Contreras
--
To unsubscribe from this list: send the line
On 5 May 2014 15:08:04 GMT+10:00, Jeff King p...@peff.net wrote:
On Sat, May 03, 2014 at 10:49:30PM +1000, James Denholm wrote:
The main issues are that calls are made to git itself in the build
process, and that a subtree-exclusive variable is used for specifying
the exec path. Patches 1/5
Users may already store sensitive data such as imap.pass in
.git/config; making the file world-readable when git config
is called to edit means their password would be compromised
on a shared system.
Signed-off-by: Eric Wong normalper...@yhbt.net
---
config.c | 7 +++
On 6 May 2014 07:49:30 GMT+10:00, Jeff King p...@peff.net wrote:
On Tue, May 06, 2014 at 07:41:29AM +1000, James Denholm wrote:
I do not think BSD-ism matters for rm, as it works pretty much the
same everywhere. install, on the other hand, is a bit weirder
between
systems. So you might want to
[fixed David's address in cc list]
On Tue, May 06, 2014 at 07:54:30AM +1000, James Denholm wrote:
Given that subtree subtree doesn't really generate a lot of discussion,
would it be advisable to wrap this up (barring further discussion) and send
it off to Junio rather than waiting for further
This is a single patch that adds two new functions to try to hide the reflog
implementation details from the callers in checkout.c and reflog.c.
It adds new functions to test if a reflog exists and to delete it, thus
allowing checkout.c to perform this if-test-then-delete operation without
having
Add two new functions, reflog_exists and delete_reflog to hide the internal
reflog implementation (that they are files under .git/logs/...) from callers.
Update checkout.c to use these functions in update_refs_for_switch instead of
building pathnames and calling out to file access functions.
Dave Bradley dbradl...@bell.net writes:
Original #178 content
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all
--pretty=format:%an%ad -- pom.xml
Mon Nov 23 03:09:17 2009 +
Mon Nov 23 02:42:24 2009 +
This added to my confusion as by right dq
Thanks!
On Mon, May 5, 2014 at 6:08 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/01/2014 10:37 PM, Ronnie Sahlberg wrote:
Update ref_transaction_update() do some basic error checking and return
true on error. Update all callers to check ref_transaction_update() for
error.
There
John Keeping j...@keeping.me.uk writes:
On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
...
Move remote-hg and remote-bzr out of contrib/. There were some
suggestions on the follow-up fix patches still not in
Users may already store sensitive data such as imap.pass in
.git/config; making the file world-readable when git config
is called to edit means their password would be compromised
on a shared system.
[v2: updated for section renames, as noted by Junio]
Signed-off-by: Eric Wong
On Sat, May 3, 2014 at 7:52 AM, Duy Nguyen pclo...@gmail.com wrote:
wt_status_collect_changes_index() depends on how damaged cache-tree is
(in this case, totally scraped). watchman does not help this either.
We need to try to heal cache-tree as much as possible to reduce the
number.
On the
On Tue, May 6, 2014 at 7:26 AM, Duy Nguyen pclo...@gmail.com wrote:
This discard_index() code was added
recently in e28f764 (unpack-trees: plug a memory leak - 2013-08-13).
As a workaround, perhaps we only do so when the sequencer is running.
Hmm.. as o-result does not carry cache-tree anyway,
Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
In the case of git-remote-hg specifically, the remote helper has to use
an interface that the Mercurial developers consider unstable [1];...
I do not want to end up in a situation where an update to Git is blocked
by a
Felipe Contreras wrote:
Having said that alignment issues do happen, and we have one of those
in Git v2.0, but I don't think they are a major concern (at least for
remote-hg/bzr).
Actually I just noticed that the remote-helpers side is not in the
master branch.
I don't know what is your plan
On Wed, Apr 30, 2014 at 7:40 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Nathan Collins wrote:
Patches created with 'diff.noprefix=true' don't 'git apply' without
specifying '-p0'.
I'm not sure this is a bug -- the 'man git-apply' just says Reads the
supplied diff output (i.e. a
Nathan Collins wrote:
On Wed, Apr 30, 2014 at 7:40 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Nathan Collins wrote:
git show | git apply --reverse
The following which only uses plumbing commands should work:
git diff-tree -p HEAD^! |
git apply --reverse
Nice! However,
On Sun, 2014-05-04 at 07:15 +0700, Duy Nguyen wrote:
I would like to merge the feature into master. It works well for me,
and some of my colleagues who have tried it out.
Have you tried to turn watchman on by default, then run it with git
test suite? That usually helps.
I have. The
Stilhaus Kitchens Complaints. fact is that there are no stilhaus kitchens
complaints.stilhaus
kitchens are the only kitchen company with no complaints
--
View this message in context:
http://git.661346.n2.nabble.com/Stilhaus-Kitchens-Complaints-tp7609746.html
Sent from the git mailing list
On Mon, May 5, 2014 at 12:53 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Scott Chacon wrote:
The GitHub training team has all of their materials open sourced under
a CC BY 3.0 license. They're all written in Markdown and hosted on
GitHub. You can check them out here, including
66 matches
Mail list logo
