On Mon, May 5, 2014 at 12:53 AM, Felipe Contreras
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 going through an
>> onl
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 arc
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. Th
Nathan Collins wrote:
> On Wed, Apr 30, 2014 at 7:40 PM, Jonathan Nieder 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 Wed, Apr 30, 2014 at 7:40 PM, Jonathan Nieder 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 patch"
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 p
Junio C Hamano wrote:
> John Keeping 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 distribution beca
On Tue, May 6, 2014 at 7:26 AM, Duy Nguyen 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, the next
assi
On Sat, May 3, 2014 at 7:52 AM, Duy Nguyen 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 topic of cache
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
---
config.c
test_write_lines carefully quotes its arguments as "$@", so
test_write_lines "a b" c
writes two lines as requested, not three.
Signed-off-by: Jonathan Nieder
---
Hi,
Michael S. Tsirkin wrote:
> +++ b/t/README
> @@ -596,6 +596,28 @@ library for your script to use.
> + test_write_li
John Keeping 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 'next', whi
Thanks!
On Mon, May 5, 2014 at 6:08 AM, Michael Haggerty 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 are currently
Dave Bradley writes:
>> Original #178 content
>> G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git 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 wit
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 t
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. Update
[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 furth
On 6 May 2014 07:49:30 GMT+10:00, Jeff King 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
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
---
config.c | 7 +++
t/t1300-repo-config.sh | 6 ++
On 5 May 2014 15:08:04 GMT+10:00, Jeff King 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 through
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 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
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 i
On 5 May 2014 15:09:39 GMT+10:00, Jeff King 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
>> @@ -11,8
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.
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 promo
Mostly copied from my personal github wiki.
Signed-off-by: Felipe Contreras
---
Documentation/git-remote-bzr.txt | 74
Documentation/git-remote-hg.txt | 121 +++
2 files changed, 195 insertions(+)
create mode 100644 Documentation/gi
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 t
- 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). T
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
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 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
>
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 han
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 f
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
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
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
> > > > filena
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 s
On Mon, May 5, 2014 at 5:57 AM, Michael Haggerty 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 not
> only i
On Mon, May 5, 2014 at 4:22 AM, Michael Haggerty wrote:
> 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 previ
Am 05.05.2014 12:53, schrieb Erik Faye-Lund:
> On Wed, Apr 30, 2014 at 9:46 PM, Sebastian Schuberth
> wrote:
>> On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
>> wrote:
>>
We can keep this patch in the msysGit repo for the 2.0 release.
>>>
>>> FWIW the plan is to switch to mingwGitDevE
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 '' without full index line
> >error: : patch does not apply
> >
> >Cheers,
> >Tolga
>
> Any feedback is appreciated.
Sorry, tr
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
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 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.
On Mon, May 5, 2014 at 6:03 PM, Matthieu Moy
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 not need to adjust
Andreas Schwab writes:
> David Kastrup 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 a
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.
>
> Upda
Duy Nguyen writes:
> On Mon, May 5, 2014 at 12:13 AM, David Kastrup 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
>
> ...
>
>> dif
David Kastrup 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 object_i
Duy Nguyen writes:
> On Mon, May 5, 2014 at 12:13 AM, David Kastrup 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
>
> ...
>
>> dif
On Mon, May 5, 2014 at 12:53 PM, Erik Faye-Lund 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
>> Windows.
On Wed, Apr 30, 2014 at 9:46 PM, Sebastian Schuberth
wrote:
> On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
> 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 release. It is
>> not quite clear as of
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 situat
On Mon, May 5, 2014 at 5:26 PM, Duy Nguyen 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 majord...@vger.kernel.org
More majo
On Mon, May 5, 2014 at 12:13 AM, David Kastrup 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 a/Documentation/config.txt
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
[git
Andreas Schwab writes:
> David Kastrup 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 an
On 5 May 2014 19:23:06 GMT+10:00, Andreas Schwab wrote:
>David Kastrup 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.
>
David Kastrup 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 object of
Andreas Schwab writes:
> 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 a
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
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
>
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 w
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.
>
> Wo
65 matches
Mail list logo
