Stefan Beller stefanbel...@gmail.com writes:
burden is not an issue, as I'll be signing the push certificate
anyway when I push. A signed tag or a signed commit and signed push
certificate solves two completely separate and orthogonal issues.
What happens if you break into GitHub or k.org
-Original Message-
From: Junio C Hamano
Sent: Monday, August 25, 2014 13:55
Stefan Beller stefanbel...@gmail.com writes:
burden is not an issue, as I'll be signing the push certificate
anyway when I push. A signed tag or a signed commit and
signed push
certificate solves
On 20.08.2014 00:06, Junio C Hamano wrote:
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
maint_2014_08_21
and so on. Whenever there is no tag at the tip of the branch, we'd
know there is something wrong.
Who creates
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
maint_2014_08_21
and so on. Whenever there is no tag at the tip of the branch, we'd
know
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
maint_2014_08_21
and so on. Whenever there is
On 22.08.2014 22:33, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:33, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
On 23.08.2014 00:32, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:33, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags
No code == no substance might be a stretch, but definitely fair enough.
I thought the idea was clear enough, but I can flesh it out if
desired. The particular advantage I saw in it is that it would reuse
the existing object infrastructure, and extend to branches the
first-class treatment that
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it
On Wed, Aug 20, 2014 at 5:06 AM, Junio C Hamano gits...@pobox.com wrote:
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch.
I don't think anybody can come up with a good auditing and recording
scheme without sufficient experience. Because I want to avoid whatever
random scheme we happen to implement first in git-core, even if it is
way suboptimal, ends up as the de-facto standard, I deliberately stayed
away from adding
On Tue, Aug 19, 2014 at 03:06:09PM -0700, Junio C Hamano wrote:
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My
On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano gits...@pobox.com wrote:
If the server's GPG keychain and pre-receive hook are properly set
up, a git push --signed over an unauthenticated and unencrypted
communication channel (aka git daemon) can be made as secure as,
and even more secure
Sorry, but I cannot answer, as the only thing that I recall when
I hear branch object was that I heard the phrase used but
without much substance.
I do not think I saw a clear explanation on what it is, how it is
represented, how it is presented to the end user, how it is
propagated across
On Tue, Aug 19, 2014 at 7:54 PM, Junio C Hamano gits...@pobox.com wrote:
Sorry, but I cannot answer, as the only thing that I recall when
I hear branch object was that I heard the phrase used but
without much substance.
Just to avoid unnecessary misunderstanding, by the above, especially
the
17 matches
Mail list logo
