On Wed, Dec 9, 2015 at 11:20 PM, Edmundo Carmona Antoranz
wrote:
> On Tue, Dec 8, 2015 at 2:22 AM, Eric Sunshine wrote:
>> On Tue, Nov 24, 2015 at 11:36 PM, Edmundo Carmona Antoranz
>> wrote:
>>> +--[no-]progress::
>>> + Progress status is reported on the standard error stream
>>> +
Am 10.12.2015 um 02:07 schrieb Stefan Beller:
This reimplements the helper function `resolve_relative_url` in shell
in C. This functionality is needed in C for introducing the groups
feature later on. When using groups, the user should not need to run
`git submodule init`, but it should be implic
Hey, Eric!
On Tue, Dec 8, 2015 at 2:22 AM, Eric Sunshine wrote:
> On Tue, Nov 24, 2015 at 11:36 PM, Edmundo Carmona Antoranz
> wrote:
>> * created struct progress_info in builtin/blame.c
>> this struct holds the information used to display progress so
>> that only one additional parameter is
On Tue, Dec 08, 2015 at 05:34:43PM +, Daniel Koverman wrote:
> Your interpretation of my email was correct. As you picked up on, I
> had a fundamental misunderstanding of what pack-objects was doing.
> Thanks for the explanation, I have a much better idea of what is
> going on now.
>
> Given
On Wed, Dec 09, 2015 at 05:43:36PM -0500, Jeff King wrote:
> On Wed, Dec 09, 2015 at 02:24:17PM -0800, Stefan Beller wrote:
>
> > On Wed, Dec 9, 2015 at 2:04 PM, Jeff King wrote:
> > >
> > > Of course you can't just fetch the v1.7.1.4 tag _now_, because the same
> > > person impersonating the mos
This reimplements the helper function `resolve_relative_url` in shell
in C. This functionality is needed in C for introducing the groups
feature later on. When using groups, the user should not need to run
`git submodule init`, but it should be implicit at all appropriate places,
which are all in C
On 8 December 2015 at 09:36, wrote:
> From: Lars Schneider
>
> A changelist that contains only excluded files due to a client spec was
> imported as an empty commit. Fix that issue by ignoring these commits.
> Add option "git-p4.keepEmptyCommits" to make the previous behavior
> available.
Looks
On Wed, Dec 09, 2015 at 02:29:12PM -0800, Stefan Beller wrote:
> On Wed, Dec 9, 2015 at 2:24 PM, Jeff King wrote:
> > On Wed, Dec 09, 2015 at 05:20:41PM -0500, Jeff King wrote:
> >
> >> Of course that is a bitter pill to swallow if you have reasons for
> >> wanting to use the old sha1s. E.g., you
On Wed, Dec 09, 2015 at 02:24:17PM -0800, Stefan Beller wrote:
> On Wed, Dec 9, 2015 at 2:04 PM, Jeff King wrote:
> >
> > Of course you can't just fetch the v1.7.1.4 tag _now_, because the same
> > person impersonating the most recent tag could also be impersonating
> > (and back-dating) the olde
On Wed, Dec 9, 2015 at 1:24 PM, Duy Nguyen wrote:
> On Wed, Dec 9, 2015 at 5:08 PM, Duy Nguyen wrote:
>> On Wed, Dec 2, 2015 at 9:10 PM, Taylor Braun-Jones
>> wrote:
>>> My use case it running git clone inside a docker container with
>>> `docker run --user $(id -u):$(id -g) --volume /foo:/foo ..
On Wed, Dec 9, 2015 at 2:24 PM, Jeff King wrote:
> On Wed, Dec 09, 2015 at 05:20:41PM -0500, Jeff King wrote:
>
>> Of course that is a bitter pill to swallow if you have reasons for
>> wanting to use the old sha1s. E.g., you have internal development
>> proceeding against the old tree and want to
On Wed, Dec 09, 2015 at 05:20:41PM -0500, Jeff King wrote:
> Of course that is a bitter pill to swallow if you have reasons for
> wanting to use the old sha1s. E.g., you have internal development
> proceeding against the old tree and want to share a truncated version
> with the public.
After re-r
On Wed, Dec 9, 2015 at 2:04 PM, Jeff King wrote:
>
> Of course you can't just fetch the v1.7.1.4 tag _now_, because the same
> person impersonating the most recent tag could also be impersonating
> (and back-dating) the older tags. But you could fetch it now, store it
> somewhere trusted (e.g., on
On Wed, Dec 09, 2015 at 02:45:44PM +0100, Jörn Hees wrote:
> I've been hacking away on a library for quite some time and have a lot of
> commits in my private repository:
>
> A -> B -> C -> D -> E
>
> Finally, I'm nearing completion of a first version, and want to
> publish it to a remote calle
On Wed, Dec 09, 2015 at 09:03:47AM -0800, Jamie Evans wrote:
> Thanks, Junio, for the tutorial! I had tried to lookup the key, but
> failed to put the ‘0x’ at the head.
An easier way to get keys is just:
$ gpg --recv-keys 96AFE6CB
gpg: requesting key 96AFE6CB from hkp server keys.gnupg.net
On Tue, Dec 08, 2015 at 01:21:25AM +, brian m. carlson wrote:
> On Mon, Dec 07, 2015 at 03:00:15PM +0100, Alexander 'z33ky' Hirsch wrote:
> > Is there any technical reason why rebase should not have a
> > --verify-signatures flag? I have written a patch to git-rebase--am
> > which enables it to
'git subtree split' can incorrectly skip a merge even when both parents
act on the subtree, provided the merge results in a tree identical to
one of the parents. Fix by copying the merge if at least one parent is
non-identical, and the non-identical parent is not an ancestor of the
identical parent
On Wed, Dec 9, 2015 at 5:08 PM, Duy Nguyen wrote:
> On Wed, Dec 2, 2015 at 9:10 PM, Taylor Braun-Jones
> wrote:
>> My use case it running git clone inside a docker container with
>> `docker run --user $(id -u):$(id -g) --volume /foo:/foo ...`. I want
>> all /foo/* file creation/access from inside
On 09/12, Jörn Hees wrote:
Hi,
I've been hacking away on a library for quite some time and have a lot
of commits in my private repository:
A -> B -> C -> D -> E
Finally, I'm nearing completion of a first version, and want to publish
it to a remote called public from D onward keeping A..C to
Thanks, Junio, for the tutorial! I had tried to lookup the key, but failed to
put the ‘0x’ at the head.
I was actually verifying the signature on a tarball release. Just curious, how
do I know the key in the database really belongs to you? It’s has your name
and email, but what’s to keep a
On Wed, Dec 2, 2015 at 9:10 PM, Taylor Braun-Jones
wrote:
> My use case it running git clone inside a docker container with
> `docker run --user $(id -u):$(id -g) --volume /foo:/foo ...`. I want
> all /foo/* file creation/access from inside the Docker container to be
> done as the current uid/gid
What's the feeling on this one? If there's agreement in principle that
git-clone should not fail when the current UID cannot be found in
/etc/passwd then I'm happy to submit a patch to fix it.
Thanks,
Taylor
On Wed, Dec 2, 2015 at 3:10 PM, Taylor Braun-Jones
wrote:
> My use case it running git c
Hi,
I've been hacking away on a library for quite some time and have a lot of
commits in my private repository:
A -> B -> C -> D -> E
Finally, I'm nearing completion of a first version, and want to publish it to a
remote called public from D onward keeping A..C to myself, so public should
aft
On 08.12.15 18:15, Christian Couder wrote:
> When we know that mtime is fully supported by the environment, we
> might want the untracked cache to be always used by default without
> any mtime test or kernel version check being performed.
>
For the people which didn't follow the discussion, or rea
Success in your activities
good day,
ask at the top of any page click once on the banner,
so that we could pay for hosting our site,
Thank you
wellnesshotels...@gmail.com
http://wellness-hotels.pp.ua/
добрий день,
просимо на будь-якій сторінці вгорі один раз натиснути на рекламний банер,
щоб ми
25 matches
Mail list logo
