* Re: Fwd: [Survey] Signed push
From: Matthieu Moy @ 2011-09-14 11:03 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <4E7085E6.3060509@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I wish that one could annotate a branch (e.g., at creation) and have the
> annotation follow the branch around. This would be a useful place to
> record *why* you created the branch, your plans for it, etc. The
> annotation should be modifiable, because often a branch evolves in
> unforeseen ways during its lifetime. Anybody could read the annotation
> to get a quick idea of what kind of work is in progress.
Would the notes mechanism be able to annotate ref names instead of
commit sha1?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Michael Haggerty @ 2011-09-14 10:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <CA+55aFy0b+eozmzbKD4RXcJ7e3WCpf7BV1n1qXHOeEwSHZKOXw@mail.gmail.com>
On 09/14/2011 09:06 AM, Linus Torvalds wrote:
> So I'm not against signed pushes, but quite frankly, if you add some
> per-branch signature, I would argue against it unless that signature
> also comes with information that allows us to do a better job of human
> communication too. Like a branch description.
>
> Imagine, for example, than when you do a
>
> git push -s ..
>
> git would *require* you to actually write a message about what you are
> pushing. And when somebody pulls it, and creates a merge commit, that
> explanation would become part of the merge message. The "signature"
> part of the "-s" should be thought of as the *much* less interesting
> part - that's just a small detail that git can use to verify
> something, but it doesn't actually matter for the contents of the
> pull. Not like the actual human-readable message would.
>
> Now *that* would be lovely. No?
Instead of "like a branch description", why not implement branch
descriptions directly?
I wish that one could annotate a branch (e.g., at creation) and have the
annotation follow the branch around. This would be a useful place to
record *why* you created the branch, your plans for it, etc. The
annotation should be modifiable, because often a branch evolves in
unforeseen ways during its lifetime. Anybody could read the annotation
to get a quick idea of what kind of work is in progress.
Such a branch annotation could be used in pull requests, the cover
letter of patch series emails, merge commit log messages, etc.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] contrib: add a credential helper for Mac OS X's keychain
From: John Szakmeister @ 2011-09-14 10:24 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1315683874-95583-1-git-send-email-jaysoffian@gmail.com>
On Sat, Sep 10, 2011 at 3:44 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> A credential helper which uses /usr/bin/security to add, search,
> and remove entries from the Mac OS X keychain.
>
> Tested with 10.6.8.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> This is a quick script to explore the new credential API. A more robust
> implementation would be to link to OS X's Security framework from C.
I'm pretty close with a version of this that is written in C. I've
done it as a completely separate build from git, although it probably
wouldn't be hard to make it build in the contrib area.
If no one else picks it up, I may look at doing a version against the
secrets api for Linux too.
-John
^ permalink raw reply
* Re: [nit] diff func headers ignore context
From: Andreas Ericsson @ 2011-09-14 10:13 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110913220421.GA24549@sigill.intra.peff.net>
On 09/14/2011 12:04 AM, Jeff King wrote:
> On Tue, Sep 13, 2011 at 05:58:25PM -0400, Jeff King wrote:
>
>> @@ -609,26 +610,23 @@ int finish_async(struct async *async)
>> int run_hook(const char *index_file, const char *name, ...)
>> {
>> struct child_process hook;
>> - const char **argv = NULL, *env[2];
>> + struct argv_array argv = ARGV_ARRAY_INIT;
>
> I find this diff function header pretty confusing. Of course we're not
> in finish_async, as you can see by the fact that the context contains
> the start of run_hook.
>
> I don't think this is something that can be solved with xfuncname
> config; we would have to teach xdiff to look at context lines when
> picking a header line.
>
> Am I the only one who finds this confusing? Can anyone think of a reason
> to keep showing finish_async in this example?
>
I've never thought about the problem as I tend to read changes and
context before header.
Current behaviour makes sense if the closing brace of the previous
function is inside the context, so if we're going to change this,
we'd either have to teach xfuncname() (or whatever we'll be using)
about indentation to make it handle bannerstyle[1] indentation, or
take any closing brace before a new first-level indentation as a
sign to close the previous function. OTOH we could just ignore
bannerstyle indent, as it's sort of bizarre and not very widely
used, but we'd still have to handle the case of the previous
function being closed inside the context.
Personally, I don't think it's worth it, but I certainly see your
point.
*1. Bannerstyle indent looks like this, for those who aren't
familiar with this very confusing style.
int prefixcmp(char *haystack, char *needle) {
return strncmp(haystack, needle, strlen(needle));
}
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH 1/3] make-static: master
From: Thomas Rast @ 2011-09-14 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, GIT Mailing-list
In-Reply-To: <7vhb4in4j7.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> diff --git a/graph.h b/graph.h
[...]
> @@ -50,18 +33,6 @@ void graph_update(struct git_graph *graph, struct commit *commit);
> int graph_is_commit_finished(struct git_graph const *graph);
>
> /*
> - * Output the next line for a graph.
> - * This formats the next graph line into the specified strbuf. It is not
> - * terminated with a newline.
> - *
> - * Returns 1 if the line includes the current commit, and 0 otherwise.
> - * graph_next_line() will return 1 exactly once for each time
> - * graph_update() is called.
> - */
> -int graph_next_line(struct git_graph *graph, struct strbuf *sb);
Well, you removed that, but you still have
/*
* Determine if a graph has finished outputting lines for the current
* commit.
*
* Returns 1 if graph_next_line() needs to be called again before
* graph_update() should be called. Returns 0 if no more lines are needed
* for this commit. If 0 is returned, graph_next_line() may still be
* called without calling graph_update(), and it will merely output
* appropriate "vertical padding" in the graph.
*/
int graph_is_commit_finished(struct git_graph const *graph);
which pretty explicitly tells the user to call graph_next_line in
conjunction with graph_update, even though we currently don't have any
callers outside graph.c doing that.
(I can't really say whether the API would be better off without
graph_next_line exposed; I just noticed because I drag along the
line-log stuff and it uses graph_next_line.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: "git archive" seems to be broken wrt zip files
From: Andreas Schwab @ 2011-09-14 8:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff King, René Scharfe, Junio C Hamano, Git Mailing List
In-Reply-To: <CA+55aFwLk8XcCDXM0w_wf5RnoB4oGxkjJrUGLB5wgSkx385b_g@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
>> Is this problem known to the unzip developers?
I have already sent them the patch and they have acknowledged it.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: t0300-credentials: poll failed: invalid argument
From: Thomas Rast @ 2011-09-14 8:15 UTC (permalink / raw)
To: Jeff King; +Cc: Brian Gernhardt, Git List
In-Reply-To: <201109091613.13137.trast@student.ethz.ch>
Thomas Rast wrote:
> $ uname -a
> Darwin mackeller.inf.ethz.ch 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; root:xnu-1699.22.81~1/RELEASE_X86_64 x86_64
[...]
> --- expect-stderr 2011-09-09 14:12:13.000000000 +0000
> +++ stderr 2011-09-09 14:12:13.000000000 +0000
> @@ -1,2 +1,3 @@
> askpass: Username:
> askpass: Password:
> +fatal: poll failed: Invalid argument
>
> for each of the tests 15--19. Is it supposed to be fixed?
Ping?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Setting up Git Server
From: Philippe Vaucher @ 2011-09-14 8:09 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Git List
In-Reply-To: <CAOZxsTqFfOR+Eb3rqz5hZSJRTe=a1N-CEM--GGGGO2yayT-HLA@mail.gmail.com>
> I will want to access the git server over the internet. I want to
> easily control git users, groups, and permissions apart from the linux
> user system, specifying who can access what repositories.
Have a look at gitolite (https://github.com/sitaramc/gitolite).
It's not very hard to setup and then it's pretty easy to work with. It
can also be integrated with stuffs like redmine.
Philippe
^ permalink raw reply
* Re: [PATCH] contrib: add a credential helper for Mac OS X's keychain
From: John Szakmeister @ 2011-09-14 8:01 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1315683874-95583-1-git-send-email-jaysoffian@gmail.com>
On Sat, Sep 10, 2011 at 3:44 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> A credential helper which uses /usr/bin/security to add, search,
> and remove entries from the Mac OS X keychain.
>
> Tested with 10.6.8.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> This is a quick script to explore the new credential API. A more robust
> implementation would be to link to OS X's Security framework from C.
[snip]
> +def add_internet_password(protocol, hostname, username, password):
> + # We do this over a pipe so that we can provide the password more
> + # securely than as an argument which would show up in ps output.
> + # Unfortunately this is possibly less robust since the security man
> + # page does not document how to quote arguments. Emprically it seems
> + # that using the double-quote, escaping \ and " works properly.
I'm not sure this comment is correct... it looks like you're passing
the password on the command line...
> + username = username.replace('\\', '\\\\').replace('"', '\\"')
> + password = password.replace('\\', '\\\\').replace('"', '\\"')
> + command = ' '.join([
> + 'add-internet-password', '-U',
> + '-r', protocol,
> + '-s', hostname,
> + '-a "%s"' % username,
> + '-w "%s"' % password,
...right here. :-(
-John
^ permalink raw reply
* Re: [PATCH] git-p4: import utf16 file properly
From: Luke Diamand @ 2011-09-14 7:55 UTC (permalink / raw)
To: Chris Li; +Cc: git, Pete Wyckoff, Junio C Hamano
In-Reply-To: <CANeU7QndA0yv1OzU3vta5B8r8nCRdBSqTy0Rboc_bbpst+1pcw@mail.gmail.com>
On 13/09/11 22:33, Chris Li wrote:
> The current git-p4 does not handle utf16 files properly.
> The "p4 print" command, when output to stdout, converts the
> utf16 file into utf8. That effectively imported the utf16 file
> as utf8 for git. In other words, git-p4 import a different
> file compare to file check out by perforce. This breakes my
> windows build in the company project.
>
> The fix is simple, just ask perforce to print the depot
> file into a real file. This way perforce will not performe
> the utf16 to utf8 conversion. Git can import the exact same
> file as perforce checkout.
Does this change do the right thing with RCS keywords in UTF16 files?
If p4CmdList() fails, e.g. due to running out of diskspace, will this
just happily import a truncated/corrupt file?
(And I could be wrong about this, but does you patch have newline
damage? It didn't seem to apply for me).
Regards!
Luke
> ---
> contrib/fast-import/git-p4 | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 6b9de9e..5fb1ac7 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -1239,6 +1239,11 @@ class P4Sync(Command, P4UserMap):
> contents = map(lambda text:
> re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text), contents)
> elif file['type'] in ('text+k', 'ktext', 'kxtext',
> 'unicode+k', 'binary+k'):
> contents = map(lambda text:
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$\n]*\$',r'$\1$',
> text), contents)
> + elif file['type'] == 'utf16':
> + tmpFile = tempfile.NamedTemporaryFile()
> + p4CmdList("print -o %s %s"%(tmpFile.name, file['depotFile']))
> + contents = [ open(tmpFile.name).read() ]
> + tmpFile.close()
>
> self.gitStream.write("M %s inline %s\n" % (mode, relPath))
>
^ permalink raw reply
* Fwd: [Survey] Signed push
From: Linus Torvalds @ 2011-09-14 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <CA+55aFxAQTR3sT7gekAD4qih8J+z-qwri7ZmNCPUd811xgci6w@mail.gmail.com>
Recovering lost emails. Or maybe you get duplicates. Sorry about that if so,
Linus
---------- Forwarded message ----------
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, Sep 13, 2011 at 10:48 AM
Subject: Re: [Survey] Signed push
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, linux-kernel@vger.kernel.org
On Tue, Sep 13, 2011 at 9:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> We have a tentative patch to add an extra line after the "URL branch" line
> that is for your cut & paste that looks like:
>
> are available in the git repository at:
> git://git.kernel.org/pub/flobar.git/ master
> for you to fetch changes up to 5738c9c21e53356ab5020912116e7f82fd2d428f
>
> I often see you respond to a pull request on the kernel mailing list with
> "I see nothing new; forgot to push?", and having this extra line may also
> help communication.
I think that would probably be a good idea, although I'd actually
prefer you to be more verbose, and more human-friendly, and actually
talk about the commit in a readable way. Get rid of the *horrible*
BRANCH-NOT-VERIFIED message (that actually messes up pull requests if
mirroring is a bit delayed and throws away more important
information), and instead just have a blurb afterwards saying
something human-readable like
Top commit 1f51b001cccf: "Merge branches 'cns3xxx/fixes',
'omap/fixes' and 'davinci/fixes' into fixes"
and at *that* point you might have a "UNVERIFIED" notice for people
to check if they forgot to push.
So I'd much prefer something like that over:
> An alternative that I am considering is to let the requester say this
> instead:
>
> are available in the git repository at:
> git://git.kernel.org/pub/flobar.git/ 5738c9c21e53356ab5020912116e7f82fd2d428f
>
> without adding the extra line.
The extra line in the pull request is cheap - it's not like we need to
ration them. The above format, in contrast, requires that the person
doing the *pull* have a recent enough git client, otherwise the merge
commit message will be just horrible.
And even if you do have a new git client that turns the commit into a
branch name, that's ambigious. What if both 'master' and
'experimental' have the same top commit, because experimental ended up
being tested and was percolated to master? Which branch name would you
pick? And what if the branch was updated since, so *no* branch name
matches - does that mean that you'd disallow the pull entirely?
> 2. Signed pushes.
>
> You tag official releases and release candidates with your GPG key, and
> everybody who works within the kernel ecosystem trusts the history behind
> the commits pointed by them, but there is no easy way to verify that
> commits and merges between the last tagged commit and the tip of your
> branch(es) are indeed from you, or if an intruder piled fake ones on top
> of your commits (until you try to push again and discover that the history
> does not fast-forward, that is).
>
> We have been discussing an addition of "git push -s" to let people sign
> their pushes (instead of having to sign every commit or add signed
> tag). The implementation alternatives were being bikeshed but not of much
> interest in this message, but the user experience would go like this:
Also, if we're adding branch information, I'd say that a description
of the branch is more important than a signature. Right now we lack
even that.
It would be lovely if people could annotate their branches with
descriptions, so that when I pull a "for-linus" branch, if it has a
description, the description of the branch makes it into the merge
message. Our merge messages are often not very informative.
I realize that cryptographic signature sound very important right now,
but in the end, *real* trust comes from people, not from signatures.
Realistically, I checked a few signatures this time around due to the
k.org issues, but at the same thing, the thing that made me trust most
of it was just looking at commits and the email messages. The
unconscious and non-cryptographic "signature" of a person acting like
you expect a person to act.
Technical measures can be subverted, and I think we should also think
about the social side. Every time somebody mentions a signature, I
want to also mention "human readability", because I think that matters
as much, if not more.
So I'm not against signed pushes, but quite frankly, if you add some
per-branch signature, I would argue against it unless that signature
also comes with information that allows us to do a better job of human
communication too. Like a branch description.
Imagine, for example, than when you do a
git push -s ..
git would *require* you to actually write a message about what you are
pushing. And when somebody pulls it, and creates a merge commit, that
explanation would become part of the merge message. The "signature"
part of the "-s" should be thought of as the *much* less interesting
part - that's just a small detail that git can use to verify
something, but it doesn't actually matter for the contents of the
pull. Not like the actual human-readable message would.
Now *that* would be lovely. No?
Linus
^ permalink raw reply
* Re: "git archive" seems to be broken wrt zip files
From: Linus Torvalds @ 2011-09-14 6:55 UTC (permalink / raw)
To: Andreas Schwab
Cc: Jeff King, René Scharfe, Junio C Hamano, Git Mailing List
In-Reply-To: <CA+55aFxsaE5btVJmM_QaUMcDzBg4df-g8X7NknC6t9UM+oQATw@mail.gmail.com>
Re-sent as this clearly never seems to have gone anywhere due to me
not realizing that the LF problems meant that while incoming email
worked fine, going out through smpt.linux-foundation.org didn't work.
Linus
On Sun, Sep 11, 2011 at 11:07 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Sep 11, 2011 at 6:14 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>> It is. This only happens if you have more then 16k entries and when one
>> of the 16k entry infos is reused it happend to be previously used for a
>> symlink entry.
>
> Thanks for the explanation.
>
>> Here's a patch for unzip60 for reference:
>
> Is this problem known to the unzip developers? Is it actively
> maintained any more? The 6.0 release seems to have been from April
> 2009, and the web page seems to have a "last updated" of September
> 2009.. Is there some other unofficial archive for bugfixes like this?
> Distros?
>
> Linus
>
^ permalink raw reply
* Re: [PATCH 1/3] make-static: master
From: Johannes Sixt @ 2011-09-14 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, GIT Mailing-list
In-Reply-To: <7v62kwvwe9.fsf@alter.siamese.dyndns.org>
Am 9/14/2011 1:46, schrieb Junio C Hamano:
> This kind of breakage report was exactly what I was looking for by
> merging it early to 'next'. Hopefully no other (function / platform) combo
> has such dependencies...
There is! prepare_git_cmd is used from the Windows section in run-command.c.
Therefore, the following hunks of the patch should be reverted.
diff --git a/exec_cmd.c b/exec_cmd.c
index 171e841..1dddbf4 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -113,7 +113,7 @@ void setup_path(void)
strbuf_release(&new_path);
}
-const char **prepare_git_cmd(const char **argv)
+static const char **prepare_git_cmd(const char **argv)
{
int argc;
const char **nargv;
diff --git a/exec_cmd.h b/exec_cmd.h
index e2b546b..f5d2cdd 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -5,7 +5,6 @@ extern void git_set_argv_exec_path(const char *exec_path);
extern const char *git_extract_argv0_path(const char *path);
extern const char *git_exec_path(void);
extern void setup_path(void);
-extern const char **prepare_git_cmd(const char **argv);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
extern const char *system_path(const char *path);
^ permalink raw reply related
* Re: [PATCH 3/7] refactor argv_array into generic code
From: Christian Couder @ 2011-09-14 5:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jens Lehmann, git
In-Reply-To: <20110913215757.GC24490@sigill.intra.peff.net>
Hi Peff,
On Tue, Sep 13, 2011 at 11:57 PM, Jeff King <peff@peff.net> wrote:
> diff --git a/argv-array.c b/argv-array.c
> new file mode 100644
> index 0000000..a50507a
> --- /dev/null
> +++ b/argv-array.c
> @@ -0,0 +1,52 @@
> +#include "cache.h"
> +#include "argv-array.h"
> +#include "strbuf.h"
> +
> +static const char *empty_argv_storage = NULL;
> +const char **empty_argv = &empty_argv_storage;
> +
> +void argv_array_init(struct argv_array *array)
> +{
> + array->argv = empty_argv;
> + array->argc = 0;
> + array->alloc = 0;
> +}
> +
> +static void argv_array_push_nodup(struct argv_array *array, const char *value)
> +{
> + if (array->argv == empty_argv)
> + array->argv = NULL;
> +
> + ALLOC_GROW(array->argv, array->argc + 2, array->alloc);
> + array->argv[array->argc++] = value;
> + array->argv[array->argc] = NULL;
> +}
> +
> +void argv_array_push(struct argv_array *array, const char *value)
> +{
> + argv_array_push_nodup(array, xstrdup(value));
> +}
> +
> +void argv_array_pushf(struct argv_array *array, const char *fmt, ...)
> +{
> + va_list ap;
> + struct strbuf v = STRBUF_INIT;
> +
> + va_start(ap, fmt);
> + strbuf_vaddf(&v, fmt, ap);
> + va_end(ap);
> +
> + argv_array_push_nodup(array, strbuf_detach(&v, NULL));
> +}
In sha1-array you called the "push" function "sha1_array_append"
instead of "sha1_array_push", so I wonder why here you call them
"*_push*" instead of "*_append*"?
Thanks for doing this anyway,
Christian.
^ permalink raw reply
* Re: Helping on Git development
From: Andrew Ardill @ 2011-09-14 5:16 UTC (permalink / raw)
To: Eduardo D'Avila; +Cc: git
In-Reply-To: <CAOz-D1+77JZRXa57GLz=vZyrcGs4Ojj6Wa0cSD4QcEkMP3PPsA@mail.gmail.com>
On 14 September 2011 13:05, Eduardo D'Avila <erdavila@gmail.com> wrote:
> Hi,
>
> I have being using Git for some time now and I am very satisfied with it.
> Now I'm considering giving back by helping on its development.
> Is there any bug listing which I can check if there is some point I can help?
> Any suggestions on other ways to help are also welcomed. :-)
Hi Eduardo, as stated in the README,
The messages titled "A note from the maintainer", "What's in git.git
(stable)" and "What's cooking in git.git (topics)" and the discussion
following them on the mailing list give a good reference for project
status, development direction and remaining tasks.
Additionally, I think the README should include something like
If you are looking to contribute to the project, a good place to start
is http://git-blame.blogspot.com/p/note-from-maintainer.html and in
Documentation/howto/maintain-git.txt
because it took me forever to find them, and contributing will be
difficult until you have read them.
Regards,
Andrew Ardill
^ permalink raw reply
* Helping on Git development
From: Eduardo D'Avila @ 2011-09-14 3:05 UTC (permalink / raw)
To: git
In-Reply-To: <CAOz-D1JW8RSR8kVWhT7v-DCbWayU8KhbePJwWrWvJwbmueRezQ@mail.gmail.com>
Hi,
I have being using Git for some time now and I am very satisfied with it.
Now I'm considering giving back by helping on its development.
Is there any bug listing which I can check if there is some point I can help?
Any suggestions on other ways to help are also welcomed. :-)
Thanks,
Eduardo R. D'Avila
^ permalink raw reply
* Setting up Git Server
From: Joshua Stoutenburg @ 2011-09-14 2:46 UTC (permalink / raw)
To: Git List
Looking for some guidance in setting up a git server customized to my
specific needs. Could anybody walk me through the process?
I have a VirtualBox VM server on which I want to set up a cluster of VMs
each one for a different purpose -- experimentation, web hosting, and,
of course, git.
I'm using Ubuntu 10.04 LTS for the operating system. I have a single
public ip address.
I will want to access the git server over the internet. I want to
easily control git users, groups, and permissions apart from the linux
user system, specifying who can access what repositories.
I don't mind CLI, as opposed to GUI, as long as it is well explained,
and it is the most efficient way to do it.
After setting up the server, I'd also like some guidance setting up
individual workstations (*nix and Winblows) to use git in the Eclipse
IDE.
You're guidance greatly appreciated.
I'd gladly put together a step-by-step guide as we figure it out for
other users looking to do the same.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Jonathon Mah @ 2011-09-14 2:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dan McGee, David Aguilar, git
In-Reply-To: <7vipox2wd6.fsf@alter.siamese.dyndns.org>
On 2011-09-12, at 14:59, Junio C Hamano wrote:
>> [Stalled]
>>
>> * jm/mergetool-pathspec (2011-06-22) 2 commits
>> - mergetool: Don't assume paths are unmerged
>> - mergetool: Add tests for filename with whitespace
>>
>> I think this is a good idea, but it probably needs a re-roll.
>> Cf. $gmane/176254, 176255, 166256
>
> What's the plan for this series? Do we still want to pursue it within the
> timeframe for the next round?
>
> Is there any mergetool/difftool expert who volunteers to help moving this
> topic forward?
I'd love this to stay alive. As I've mentioned before, my relationship with shell is tenuous. My biggest problem is I don't have a mental model of how quoting works, so I end up writing tests and performing trial-and-error until it works.
On 2011-06-22, at 14:33, Junio C Hamano wrote:
> Why do you need a loop here in the else clause, instead of just a single:
>
> files=$(git ls-files -u -- "$@" |...)
See above (the dumb loop isn't necessary; your suggestion is much better). Should I bother re-submitting with just this change?
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply
* Re: [Survey] Signed push
From: Sam Vilain @ 2011-09-14 1:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <CAJo=hJt-n0Xn85g7-7eEgxZhsBu8wd843dvvbaJgdYSx3t4Xug@mail.gmail.com>
On 9/13/11 5:39 PM, Shawn Pearce wrote:
> > If the push certificate also has the previous commit IDs for the changed
> > refs, then you actually have an audit log. Otherwise, it does not certify
> > the commit range they pushed.
> Is that necessary? The range they are certifying is that commit, and
> its entire ancestry. If the pusher doesn't trust his ancestry, why is
> he working with it? Similar to an annotated tag. I make a signed
> annotated tag, I am asserting that revision and its ancestry is
> something I like as far as a project build goes. You don't need the
> old revision to realize I like this commit.
Perhaps because they didn't notice what happened. Someone else pushed
to the server without a signed push somehow, and then they pulled,
pushed ... and now as far as you know, those commits are certified like
any other. Having this extra information, not much information, will
help figure out what happens in this sort of situation.
>> This is an important prerequisite for a fully distributed, peer to peer git.
>> For this case it would also need something to distinguish which repository
>> is to be updated; such as a canonical repository URL (or list of URLs), or
>> just a short project name. A P2P protocol can then know projects as (KEYID,
>> projectname).
> Why do we need a project name? Most Git based projects are uniquely
> identified by the set of root commits they have. Why? Because most
> root commits were created by different people, at different times,
> with different commit messages, and different initial trees, resulting
> in a unique commit SHA-1 for that root commit. Projects with more than
> one root commit also disambiguate themselves from other projects that
> maybe contain one of those roots (e.g. git.git vs. gitk).
>
> If you wanted to identify a project on a P2P network, I think you
> would want to do it based off the root commits, not some random name
> people came up with and might try to publish forgeries under.
>
Yes, this is true, but it also makes it a lot harder to figure out if
two projects are from the same real project, or whether they just shared
some history. In general, git repositories are partitioned by URL or
project, and so this makes a soft case for a distributed system to
partition itself by URL or project also.
Sam
^ permalink raw reply
* Re: [Survey] Signed push
From: Shawn Pearce @ 2011-09-14 0:39 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <4E6FF5D9.3080709@vilain.net>
On Tue, Sep 13, 2011 at 17:31, Sam Vilain <sam@vilain.net> wrote:
> On 9/13/11 9:45 AM, Junio C Hamano wrote:
>>
>> * "git push" prepares a "push certificate" (it is meant to certify "these
>> are the commits I place at the tips of these refs"), which is a human
>> and machine readable text file in core, that may look like this:
>>
>> Push-Certificate-Version: 0
>> Pusher: Junio C Hamano<gitster@pobox.com>
>> Update: 3793ac56b4c4f9bf0bddc306a0cec21118683728 refs/heads/master
>> Update: 12850bec0c24b529c9a9df6a95ad4bdeea39373e refs/heads/next
>
> If the push certificate also has the previous commit IDs for the changed
> refs, then you actually have an audit log. Otherwise, it does not certify
> the commit range they pushed.
Is that necessary? The range they are certifying is that commit, and
its entire ancestry. If the pusher doesn't trust his ancestry, why is
he working with it? Similar to an annotated tag. I make a signed
annotated tag, I am asserting that revision and its ancestry is
something I like as far as a project build goes. You don't need the
old revision to realize I like this commit.
If you want to get into the game of, maybe I push a branch, then
rewind it, and push something differently, and you want to be able to
verify that the 2nd push is the "right thing" and the 1st push should
be ignored, you can already see that by looking at the timestamp of
the push certificates (/me assumes there is a timestamp in there). If
you can create multiple signed pushes by yourself, using your GPG key,
within the same second, and they are conflicting... well, stop using
automated tools to create conflicting assertions as yourself. If you
are creating signed pushes on systems with clock skew, learn how to
configure NTP date.
> This is an important prerequisite for a fully distributed, peer to peer git.
> For this case it would also need something to distinguish which repository
> is to be updated; such as a canonical repository URL (or list of URLs), or
> just a short project name. A P2P protocol can then know projects as (KEYID,
> projectname).
Why do we need a project name? Most Git based projects are uniquely
identified by the set of root commits they have. Why? Because most
root commits were created by different people, at different times,
with different commit messages, and different initial trees, resulting
in a unique commit SHA-1 for that root commit. Projects with more than
one root commit also disambiguate themselves from other projects that
maybe contain one of those roots (e.g. git.git vs. gitk).
If you wanted to identify a project on a P2P network, I think you
would want to do it based off the root commits, not some random name
people came up with and might try to publish forgeries under.
--
Shawn.
^ permalink raw reply
* Re: [Survey] Signed push
From: Sam Vilain @ 2011-09-14 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, linux-kernel
In-Reply-To: <7vaaa8xufi.fsf@alter.siamese.dyndns.org>
On 9/13/11 9:45 AM, Junio C Hamano wrote:
> * You push out your work with "git push -s";
>
> * "git push" prepares a "push certificate" (it is meant to certify "these
> are the commits I place at the tips of these refs"), which is a human
> and machine readable text file in core, that may look like this:
>
> Push-Certificate-Version: 0
> Pusher: Junio C Hamano<gitster@pobox.com>
> Update: 3793ac56b4c4f9bf0bddc306a0cec21118683728 refs/heads/master
> Update: 12850bec0c24b529c9a9df6a95ad4bdeea39373e refs/heads/next
>
> and asks you to GPG sign it. You only unlock your GPG key and the
> command internally runs GPG, just like "tag -s".
>
> * When "git push" finishes, the receiving end has this record in its
> refs/notes/signed-push notes tree, together with your previous pushes
> (as this is not a shared repository, it will record only your pushes).
> The notes annnotate the commits named on the "Update:" lines above.
If the push certificate also has the previous commit IDs for the changed
refs, then you actually have an audit log. Otherwise, it does not
certify the commit range they pushed.
This is an important prerequisite for a fully distributed, peer to peer
git. For this case it would also need something to distinguish which
repository is to be updated; such as a canonical repository URL (or list
of URLs), or just a short project name. A P2P protocol can then know
projects as (KEYID, projectname).
Sam
^ permalink raw reply
* Re: [Survey] Signed push
From: Junio C Hamano @ 2011-09-14 0:02 UTC (permalink / raw)
To: Guenter Roeck; +Cc: git
In-Reply-To: <7v1uvkvw68.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Guenter Roeck <guenter.roeck@ericsson.com> writes:
>
>> On Tue, Sep 13, 2011 at 12:45:37PM -0400, Junio C Hamano wrote:
>> [ ... ]
>>
>>> 1. Improved pull requests.
>>>
>> noise for me
>
> Are you among the ones who respond to pull requests?
Sorry, this didn't come out quite the way I intended.
As I do not know every developer on earth, I would like to know in what
capacity you (figuratively---I mean everybody who gives his opinion on
this topic) fit in your ecosystem. Otherwise I cannot tell if many people
who receive pull requests find it noise but senders do not care, or many
people who send them find it noise but receivers do appreciate, etc.
For the purpose of commenting on "pull requests" topic, one can be (1)
a bystander, who does not request nor respond to pull requests, (2) who
gets requests to pull, or (3) who sends requests to pull.
The same for "signed pushes". In this case, one can be (1) who pushes, (2)
who fetches and wants to verify what he gets, (3) both (e.g. Linus
playing role (3) while fetching from his lieutenants and then role (1)
when pushing his integration results out).
^ permalink raw reply
* Re: [Survey] Signed push
From: Junio C Hamano @ 2011-09-13 23:50 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Junio C Hamano, git
In-Reply-To: <20110913232640.GA4189@ericsson.com>
Guenter Roeck <guenter.roeck@ericsson.com> writes:
> On Tue, Sep 13, 2011 at 12:45:37PM -0400, Junio C Hamano wrote:
> [ ... ]
>
>> 1. Improved pull requests.
>>
> noise for me
Are you among the ones who respond to pull requests?
^ permalink raw reply
* Re: [PATCH 1/3] make-static: master
From: Junio C Hamano @ 2011-09-13 23:46 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4E6FDE71.9050606@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Junio C Hamano wrote:
>> Many symbols that are exported to the global scope do not have to be.
>>
>> Signed-off-by: Junio C Hamano <junio@pobox.com>
>> ---
>> * To be applied on top of 3793ac5 (RelNotes/1.7.7: minor fixes, 2011-09-07)
>>
> [snipped patch]
>
> commit f34196da7b55cbf9f2651e095b6559430aff0baf (make-static: master, 11-09-2011)
> in the next branch (at repo.or.cz), but *not* this patch, breaks the build on
> cygwin.
Thanks.
This kind of breakage report was exactly what I was looking for by
merging it early to 'next'. Hopefully no other (function / platform) combo
has such dependencies...
environment.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/environment.c b/environment.c
index 478f2afa..e810f6b 100644
--- a/environment.c
+++ b/environment.c
@@ -147,6 +147,15 @@ int is_bare_repository(void)
return is_bare_repository_cfg && !get_git_work_tree();
}
+/*
+ * This symbol might be unreferenced in normal builds but
+ * compat/cygwin.c refers to it. Do not remove without checking!
+ */
+int have_git_dir(void)
+{
+ return !!git_dir;
+}
+
const char *get_git_dir(void)
{
if (!git_dir)
^ permalink raw reply related
* Re: [PATCH/RFC] bash: add --word-diff option to diff auto-completion
From: SZEDER Gábor @ 2011-09-13 23:37 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Rodrigo Rosenfeld Rosas, Thomas Rast, git
In-Reply-To: <20110913232941.GC2078@goldbirke>
On Wed, Sep 14, 2011 at 01:29:41AM +0200, SZEDER Gábor wrote:
> Or is it just too late here and I'm missing something
> obvious?
>
> Completing the mode for --word-diff=<TAB> is a good idea, but c'mon,
> there are plenty of examples ;) Have a look at _git_am(),
> _git_format_patch(), or _git_init() for something easy, and
> _git_commit(), _git_log(), or _git_notes() for something fancy.
>
> Note that --word-diff= is also valid for log and shortlog, so the same
> can be done there, too.
Not shortlog, show. It's definitely too late... ;)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox