On Tue, Feb 24, 2015 at 9:23 AM, J. R. Westmoreland wrote:
> Hi
>
> I hope it is okay to ask such a question here.
>
> I cloned the current source tree and tried to build it and I get the
> following error.
> Could someone tell me why and if there is an easy way to fix it?
> I’m running on a Mac
is prepared to
> pass such a timestamp as a sane value---instead they diagnose a
> failure and die.
I remember a pretty old thread found some success storing timestamps this way:
http://comments.gmane.org/gmane.comp.version-control.git/152433
-Dan Johnson
--
To unsubscribe from this list: sen
On Thu, Oct 2, 2014 at 9:57 AM, Christian Halstrick
wrote:
> I always though during fetch I have to specify a refspec and that a
> sha1 would not be accepted as a ref. Firing some like 'git fetch
> origin ' should be forbidden. But in fact I see that such a
> fetch command succeeds if you already
On Wed, Sep 12, 2012 at 6:19 PM, Junio C Hamano wrote:
> Dan Johnson writes:
>
>>> Not really. If we start encouraging people to use "git show" output
>>> as a kosher input to "am", we would have to support such use
>>> forever, and we end up
On Wed, Sep 12, 2012 at 5:18 PM, Junio C Hamano wrote:
> Peter Jones writes:
>
>> Well, if that happens, maybe we could regexp match on
>> "[[:alnum:]_-]+: /someexprthatlookslikeanemailaddress/" ?
>
> I doubt that would be even reliably done.
>
>> But we could
>> also just wait to cross that brid
On Wed, Sep 12, 2012 at 3:21 PM, Jens Lehmann wrote:
> Am 11.09.2012 21:41, schrieb Junio C Hamano:
>> Thanks. I wish all others paid attention to "What's cooking" like
>> you did here.
>>
>> And if it is hard to do so for whatever reason, suggest a better way
>> for me to publish "What's cooking
When fetch is invoked with --all, we need to pass the tag-following
preference to each individual fetch; without this, we will always
auto-follow tags, preventing us from fetching the remote tags into a
remote-specific namespace, for example.
Reported-by: Oswald Buddenhagen
Signed-off-by: Dan
Reported-by: Oswald Buddenhagen
Signed-off-by: Dan Johnson
---
Junio C Hamano writes:
>Dan Johnson writes:
>
>> I believe that is bad interaction with "--all" (probably a bug). If I
>> am remembering correctly, --no-tags is internally a per-remote
>> setting
On Fri, Aug 31, 2012 at 12:26 PM, Oswald Buddenhagen wrote:
> On Thu, Aug 30, 2012 at 09:03:34AM -0700, Junio C Hamano wrote:
>> Oswald Buddenhagen writes:
>>
>> >> Doesn't
>> >>
>> >>git push $over_there 'refs/*:refs/remotes/mine/*'
>> >>
>> >> push your tag v1.0 to refs/remotes/mine/v1.0 ov
On Wed, Aug 29, 2012 at 2:15 AM, Martin von Zweigbergk
wrote:
> When 'git log' is passed the --no-walk option, no revision walk takes
> place, naturally. Perhaps somewhat surprisingly, however, the provided
> revisions still get sorted by commit date. So e.g 'git log --no-walk
> HEAD HEAD~1' and '
On Mon, Aug 27, 2012 at 10:32 AM, Aaron Gray wrote:
> Hi,
>
> Is there anyway to get my git repository as a single file ?
You're probably looking for the git bundle command (see git bundle
--help), but it's possible you might just want to use tar.
Hope that helps,
--
-Dan
--
To unsubscribe from
On Wed, Jul 25, 2012 at 2:53 PM, Paul Gortmaker
wrote:
> Has anyone else noticed false positives coming from the
> orphan check? It is warning me about commits that are
> clearly on master. Here is an example, where I checkout
> master~2 and then switch back to master. It somehow thinks
> that
On Tue, Jul 17, 2012 at 10:06 AM, Matthieu Moy wrote:
> Traditionnally, pages named Foo:Bar are page 'Bar' in namespace 'Foo'.
> However, it is also possible to call a page Foo:Bar if 'Foo' is not a
> namespace. In this case, the actual name of the page is 'Foo:Bar', in the
> main namespace. Since
On Thu, Jul 19, 2012 at 12:40 PM, Alexey Muranov
wrote:
> On 19 Jul 2012, at 13:55, Jeff King wrote:
>
>> I agree it would be much less confusing. However, one downside is that
>> we do not keep reflogs on deleted branches (and nor did the commits in
>> remote branches necessarily make it into the
On Thu, Jul 19, 2012 at 7:55 AM, Jeff King wrote:
> On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
>
>> i would like
>>
>> `git fetch --prune `
>>
>> to be the default behavior of
>>
>> `git fetch `
>>
>> In fact, i think this is the only reasonable behavior.
>> Keeping copies of
15 matches
Mail list logo