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 i
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
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
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
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 oth
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 initia
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
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 str
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 ../../GI
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)
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/
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, 2014
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) wit
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.
M
Johannes Sixt 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 padding, it does
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 (thou
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 t
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 l
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 li
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]
> > sta
Am 04.05.2014 12:55, schrieb Andreas Schwab:
> Johannes Sixt 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 h
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 oth
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, "");
> ^
>
>
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.
> > >
> >
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'
David Kastrup writes:
> Andreas Schwab writes:
>
>> David Kastrup writes:
>>
>>> Andreas Schwab writes:
>>>
"brian m. carlson" 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,
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 s
Daniel Villeneuve 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
> updated on 2014-
Andreas Schwab writes:
> David Kastrup writes:
>
>> Andreas Schwab writes:
>>
>>> "brian m. carlson" 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?
>
> §6.7
David Kastrup writes:
> Andreas Schwab writes:
>
>> "brian m. carlson" 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?
§6.7.2.1#15
Andreas.
--
Andreas Schwab, sc
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
Andreas Schwab writes:
> "brian m. carlson" 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 this list: send the line "unsubscribe gi
"brian m. carlson" 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 44D5 214B 8276 4ED5
"And
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 caus
On Sun, May 4, 2014 at 1:07 PM, Michael Haggerty 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 leads to confus
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 maj
James Denholm writes:
> On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras
> 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 whose summary?
https://www.youtube.co
Johannes Sixt 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
perfectly complia
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras
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 people in
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 s
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.x>git log --all
"--pretty=forma
Johannes Sixt 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 siz
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 wher
On Sat, May 3, 2014 at 10:16 PM, Felipe Contreras
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
> ---
> contrib/remote-helpers/test-hg.sh | 150
> ++
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 requirem
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
On Wed, Apr 30, 2014 at 1:15 PM, Geert Bosch wrote:
>
> On Apr 28, 2014, at 02:29, Marat Radchenko 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 SVN
> used to do in
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 you
James Denholm 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 where y
49 matches
Mail list logo
