On 05/03/2014 10:12 PM, brian m. carlson wrote:
Many places throughout the code use unsigned char [20] to store object IDs
(SHA-1 values). This leads to lots of hardcoded numbers throughout the
codebase. It also leads to confusion about the purposes of a buffer.
Introduce a structure for
(Sorry for the late reply, I'm handicapped by some local IT problems)
Peff, do you know if the fix below helps ?
On 2014-04-28 18.16, Jeff King wrote:
If you have existing decomposed filenames in your git
repository (e.g., that were created with older versions of
git that did not precompose
Felipe Contreras felipe.contre...@gmail.com writes:
David Lang wrote:
note that this is one person taking the I don't see any commits from
you so your opinion doesn't count attitude.
Wrong. I said it doesn't count for the project.
There are a number of commits from me that actually count.
This is in gcc 4.9.0:
wt-status.c: In function ‘wt_status_print_unmerged_header’:
wt-status.c:191:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
status_printf_ln(s, c, );
^
We could pass -Wno-format-zero-length, but it seems compiler-specific
flags are
In recent versions of gcc (4.9.0), we get a few of these:
notes.c: In function ‘notes_display_config’:
notes.c:970:28: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
config_error_nonbool(k);
^
Previous commit explains the
Hi,
I'm getting tons and tons of warnings with gcc 4.9.0. Here are the patches to
fix them all.
Felipe Contreras (3):
Revert make error()'s constant return value more visible
Revert silence some -Wuninitialized false positives
Silence a bunch of format-zero-length warnings
In recent versions of gcc (4.9.0), we get hundreds of these:
advice.c: In function ‘error_resolve_conflict’:
advice.c:79:69: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
error('%s' is not possible because you have unmerged files., me);
On 05/03/2014 10:12 PM, brian m. carlson wrote:
This is a preliminary RFC patch series to move all the relevant uses of
unsigned char [20] to struct object_id. It should not be applied to any
branch yet.
The goal of this series to improve type-checking in the codebase and to
make it easier
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track record
of the people in the discussion.
Ah, yes, like that discussion we once had where you totally
didn't run `git log | grep
James Denholm nod.h...@gmail.com writes:
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track record
of the people in the discussion.
Ah, yes, like that discussion we once had
On 2014-05-03 23:08, Felipe Contreras wrote:
Richard Hansen wrote:
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
OK. Let me summarize to make sure I understand your full
On Wed, Apr 30, 2014 at 1:15 PM, Geert Bosch bos...@mac.com wrote:
On Apr 28, 2014, at 02:29, Marat Radchenko ma...@slonopotamus.org wrote:
In short:
1. Hack, hack, hack
2. Commit
3. Push, woops, reject (non-ff)
4. Pull
5. Push
Just do pull --rebase? This is essentially the same as what
Am 04.05.2014 08:35, schrieb Michael Haggerty:
On 05/03/2014 10:12 PM, brian m. carlson wrote:
I specifically did not choose sha1 since it
looks weird to have sha1-sha1 and I didn't want to rename lots of
variables.
That means that we will have sha1-oid all over the place, right?
Only
Am 04.05.2014 08:07, schrieb Michael Haggerty:
On 05/03/2014 10:12 PM, brian m. carlson wrote:
Introduce a structure for object IDs. This allows us to obtain the benefits
of compile-time checking for misuse. The structure is expected to remain
the same size and have the same alignment
On Sat, May 3, 2014 at 10:16 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Inspired by the tests in gitifyhg.
One test is failing, but that's because of a limitation of
remote-helpers.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
James Denholm wrote:
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track record
of the people in the discussion.
Ah, yes, like that discussion we once had where you totally
Johannes Sixt j...@kdbg.org writes:
Am 04.05.2014 08:07, schrieb Michael Haggerty:
On 05/03/2014 10:12 PM, brian m. carlson wrote:
Introduce a structure for object IDs. This allows us to obtain the benefits
of compile-time checking for misuse. The structure is expected to remain
the same
Hi,
Interesting discussion. However, the example below of three-spaces between
%an and %ad in the example below resulted in the
formatting of the output with the three spaces, but no dq's.
Original #178 content
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all
--pretty=format:%an
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
Richard Hansen wrote:
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
OK. Let me summarize to
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com
wrote:
James Denholm wrote:
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track
record
of the
Johannes Sixt j...@kdbg.org writes:
I think that a compiler that has different size and alignment requirements
for the proposed struct object_id and an unsigned char[20] would, strictly
speaking, not be a C compiler.
Unlike arrays, a struct can have arbitrary internal padding. It is
James Denholm nod.h...@gmail.com writes:
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras
felipe.contre...@gmail.com wrote:
But I'm not going to bother any more with you, you are just spreading
lies and tainting the discussion.
Well, maybe we'll see what other folks think.
According to
On 2014-04-30 16.57, Torsten Bögershausen wrote:
There is something wrong with the patch, (test suite hangs or TC fail),
so I need to com back later. Sorry for the noise.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
On Sun, May 4, 2014 at 1:07 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/03/2014 10:12 PM, brian m. carlson wrote:
Many places throughout the code use unsigned char [20] to store object IDs
(SHA-1 values). This leads to lots of hardcoded numbers throughout the
codebase. It also
On Sun, May 04, 2014 at 08:07:26AM +0200, Michael Haggerty wrote:
Please clarify whether you plan to rely on all platforms having the
same size and alignment constraints for correctness, or whether that
observation of the status quo is only meant to reassure us that this
change won't cause
brian m. carlson sand...@crustytoothpaste.net writes:
I don't even plan to write the code assuming that offsetof(struct
object_id, oid) is 0.
This is guaranteed by the C standard, though.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3
Andreas Schwab sch...@linux-m68k.org writes:
brian m. carlson sand...@crustytoothpaste.net writes:
I don't even plan to write the code assuming that offsetof(struct
object_id, oid) is 0.
This is guaranteed by the C standard, though.
Any reference?
--
David Kastrup
--
To unsubscribe from
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
for a repository of Emacs repacked with git gc --aggressive (v1.9,
resulting in a window size of 250) located
David Kastrup d...@gnu.org writes:
Andreas Schwab sch...@linux-m68k.org writes:
brian m. carlson sand...@crustytoothpaste.net writes:
I don't even plan to write the code assuming that offsetof(struct
object_id, oid) is 0.
This is guaranteed by the C standard, though.
Any reference?
Andreas Schwab sch...@linux-m68k.org writes:
David Kastrup d...@gnu.org writes:
Andreas Schwab sch...@linux-m68k.org writes:
brian m. carlson sand...@crustytoothpaste.net writes:
I don't even plan to write the code assuming that offsetof(struct
object_id, oid) is 0.
This is guaranteed
Daniel Villeneuve dvillene...@kronos.com writes:
Hi,
I've used the following link to download git source and corresponding
pre-formatted man pages for several months:
https://code.google.com/p/git-core/downloads/
However, the latest version available on the site is git-1.9.0 (last
On Sun, May 04, 2014 at 08:35:00AM +0200, Michael Haggerty wrote:
On 05/03/2014 10:12 PM, brian m. carlson wrote:
I called the structure member oid because it was easily grepable and
distinct from the rest of the codebase. It, too, can be changed if we
decide on a better name. I
David Kastrup d...@gnu.org writes:
Andreas Schwab sch...@linux-m68k.org writes:
David Kastrup d...@gnu.org writes:
Andreas Schwab sch...@linux-m68k.org writes:
brian m. carlson sand...@crustytoothpaste.net writes:
I don't even plan to write the code assuming that offsetof(struct
On Sat, May 03, 2014 at 04:50:52AM -0500, Felipe Contreras wrote:
Either way it would be impossible for Git to figre out what you want
to do.
That's my point. The details of my particular workflow are
unimportant.
Anyway I don't see how is this possibly relevant to the topic at
hand.
I'm
Hello Marat,
On Sat, May 03, 2014 at 11:00:51AM +0400, Marat Radchenko wrote:
On Wed, Apr 30, 2014 at 01:41:25PM +0200, Stepan Kasal wrote:
On Tue, Apr 29, 2014 at 01:12:04PM +0400, Marat Radchenko wrote:
On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.
Removal
On Sun, May 04, 2014 at 01:12:55AM -0500, Felipe Contreras wrote:
This is in gcc 4.9.0:
wt-status.c: In function ‘wt_status_print_unmerged_header’:
wt-status.c:191:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
status_printf_ln(s, c, );
^
We could
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form of code), and others have
Am 04.05.2014 12:55, schrieb Andreas Schwab:
Johannes Sixt j...@kdbg.org writes:
I think that a compiler that has different size and alignment requirements
for the proposed struct object_id and an unsigned char[20] would, strictly
speaking, not be a C compiler.
Unlike arrays, a struct can
brian m. carlson wrote:
On Sun, May 04, 2014 at 01:12:55AM -0500, Felipe Contreras wrote:
This is in gcc 4.9.0:
wt-status.c: In function ‘wt_status_print_unmerged_header’:
wt-status.c:191:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
Marat Radchenko wrote:
If one wants to dig deeper, I'd say the problem is in MinGW-W64
headers because their behavior of hiding MsgWaitForMultipleObjects
doesn't match behavior of MSVC headers.
I agree with that. Can you file a bug report?
--
Felipe Contreras
--
To unsubscribe from this
On Sun, May 04, 2014 at 08:52:44PM +0200, Stepan Kasal wrote:
Thank you very much for this analysis.
It enables us to redirect you the third time: to report this as a
bug in MinGW-W64 ! ;-)
I'll report this to MinGW-W64 soon, though even if/when they fix
the issue on their side, I'd still
W. Trevor King wrote:
Do you feel folks won't need a way to slow/disable 'git pull' while
they build the ff options and their project's recommended workflow
into their own practice?
That's right.
Or do you agree that they will need some kind of helper for the
transition, and just feel that
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form
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 array?
The standard allows arbitrary internal
Hi,
There has been a lot of discussion about why `git pull` is broken for so
many many workflows: [1][2][3][4][5], even as far back as [6].
Many issues has been brought up, and many proposed solutions, probably
too many for most people properly digest them, so here I'll try to
synthesize them.
Hi,
I know there are a few people on this list that do git training in
various forms. At $dayjob I've been asked to run a few training
sessions in house. The initial audience is SW developers so they are
fairly clued up on VCS concepts and most have some experience
(although some not positive)
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 going through an
online rendering of the materials:
http://training.github.com/kit/
Scott
On Sun, May 4,
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 going through an
online rendering of the materials:
http://training.github.com/kit/
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 through 3/5 resolve these.
The cleanup fixes (4/5 and 5/5) are
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
@@ -11,8 +11,9 @@ man1dir ?= $(mandir)/man1
-include
On Sun, May 04, 2014 at 07:01:22PM +, brian m. carlson wrote:
On Sun, May 04, 2014 at 01:12:55AM -0500, Felipe Contreras wrote:
This is in gcc 4.9.0:
wt-status.c: In function ‘wt_status_print_unmerged_header’:
wt-status.c:191:2: warning: zero-length gnu_printf format string
On 2014-05-04 17:13, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in
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 e208f9cc7574f5980faba498d0aa30b4defeb34f.
And now we've gone the other way, and re-enabled the initial
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 e208f9cc7574f5980faba498d0aa30b4defeb34f.
And now we've gone the other way, and
Richard Hansen wrote:
On 2014-05-04 17:13, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I
55 matches
Mail list logo
