* Re: The imporantance of including http credential caching in 1.7.7
From: Philip Oakley @ 2011-09-07 23:01 UTC (permalink / raw)
To: Kyle Neath, Michael J Gruber; +Cc: git
In-Reply-To: <CAFcyEthuf49_kOmoLmoSSbNJN+iOBpicP4-eFAV5wL5_RffwGg@mail.gmail.com>
From: "Kyle Neath" <kneath@gmail.com>
> Junio C Hamano <gitster@pobox.com> wrote:
>> If this were a new, insignificant, and obscure feature in a piece of
>> software with mere 20k users, it may be OK to release a new version with
>> the feature in an uncooked shape.
>
> Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> So, it's been a year or more that you've been aware of the importance of
>> this issue (from your/github's perspective), and we hear about it now,
>> at the end of the rc phase.
>
> I apologize if it sounds like that. I've been discussing this situation
> with
> many people (including Jeff King) for a very long time now, and it was my
> understanding that the credential caching was done and simply waiting for
> a
> new release. This is the first I've heard that it will not be included in
> 1.7.7, so I'm voicing my opinion now. Admittedly, late in the game - and I
> apologize for that.
>
> I'd be happy to help in any capacity I can. Unfortunately I'm no C hacker,
> and
> I've accepted that as a character flaw (it's something I'm working on).
> I'm
> afraid I can't be of much help with the actual code. What I can provide is
> an
> alternate viewpoint to the core team. A viewpoint of someone who's spent 3
> years trying to make git easier for newcomers.
Help in any capacity :
Would it not be possible for GitHub to provide for those key users such a
trial version
that includes the patches identified to obtain the "real-world success
reports" that
are needed, as mentioned in the "Re: What's cooking in git.git (Aug 2011,
#07; Wed, 24)"
This should help satisfy the needs from both sides, even if you can only
push it to a few clients.
>>What's cooking in git.git (Aug 2011, #07; Wed, 24)
>> Looked mostly reasonable except for the limitation that it is not clear
>> how to deal with a site at which a user needs to use different passwords
>> for different repositories. Will keep it in "next" at least for one
>> cycle,
>> until we start hearing real-world success reports on the list.
^ permalink raw reply
* Re: [RFC/PATCH] fetch: bigger forced-update warnings
From: Thomas Rast @ 2011-09-07 22:42 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20110907212042.GG13364@sigill.intra.peff.net>
Jeff King wrote:
> On Mon, Sep 05, 2011 at 02:14:57PM -0700, Shawn O. Pearce wrote:
>
> > > Right. What I mean is, what should the bigger warning look like?
> >
> > Its a bikeshed. I refuse to paint bikesheds. :-)
[...]
> + if (uncommon_forced_update)
> + warning("HEY STUPID FIX YOUR TOPICS");
Whatever comes out of the bikeshedding, I'm going to keep a patch
locally that refreshes the mental picture of Shawn shouting that!
That being said, I think there should be a multiline warning pointing
the user at the "recovering from upstream rebase" section in
git-rebase(1). At least by default with an advice.* setting to
disable it.
> + if (!prefixcmp(message, "fetch: fast-forward"))
> + uc->fastforward++;
> + else if (!prefixcmp(message, "fetch: forced-update\n"))
> + uc->forced++;
That doesn't work: fetch puts the whole command line there.
E.g.
git fetch altgit
--> fetch altgit: fast-forward
git fetch altgit next:refs/remotes/next
--> fetch altgit next:remotes/altgit/next: fast-forward
There's also a minor subtlety here that I had to double-check first:
the message for a branch creation is 'storing head', so the later
check
> + return uc.fastforward && uc.forced <= 1; /* 1 for the one we just did */
never triggers at the second fetch.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 2/2] push -s: skeleton
From: Junio C Hamano @ 2011-09-07 22:40 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, Robin H. Johnson, git, Shawn O. Pearce
In-Reply-To: <CACsJy8Cy_Nn3EExV0D=RWtft+1pc9RBdJgpmES4AeQgYsUfU3A@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> ...
>> 4. A new phase to record the push certificate is introduced in the
>> codepath after the receiving end runs receive_hook(). It is envisioned
>> that this phase:
>>
>> a. parses the updated-to object names, and appends the push
>> certificate (still GPG signed) to a note attached to each of the
>> objects that will sit at the tip of the refs;
>
> I recall Gentoo wanted something like this (recording who pushes
> what). Pulling Robin in if he has any comments.
As the beauty of this approach is that we can update and tailor what the
receiving end does using the information given from the server, it is a
strange thing to do to chomp this list in the middle at a funny place
here.
^ permalink raw reply
* Re: [PATCH 2/2] push -s: skeleton
From: Nguyen Thai Ngoc Duy @ 2011-09-07 22:21 UTC (permalink / raw)
To: Junio C Hamano, Robin H. Johnson; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vbouw2hqg.fsf@alter.siamese.dyndns.org>
On Thu, Sep 8, 2011 at 6:57 AM, Junio C Hamano <gitster@pobox.com> wrote:
> A better alternative could be to sign a "push certificate" (for the lack
> of better name) every time you push, asserting that what commits you are
> pushing to update which refs. The basic workflow goes like this:
>
> 1. You push out your work with "git push -s";
>
> 2. "git push", as usual, learns where the remote refs are and which refs
> are to be updated with this push. It prepares a text file in memory
> that looks like this using this information:
>
> Push-Certificate-Version: 1
> Pusher: Junio C Hamano <gitster@pobox.com> 1315427886 -0700
> Update: e83c51633... d4e58965f... refs/heads/master
> Update: 5a144a288... 7931f38a2... refs/heads/next
>
> An actual push certificate records full 40-char object name, but it is
> ellided for brevity here.
>
> The user then is asked to sign this push certificate using GPG. The
> result is carried to the other side (i.e. receive-pack). In the
> protocol exchange, this step comes immediately after the sender tells
> what the result of the push should be, before it sends the pack data.
>
> 3. The receiving end will keep the signed push certificate in core,
> receives the pack data and unpacks (or stores and runs index-pack)
> as usual.
>
> 4. A new phase to record the push certificate is introduced in the
> codepath after the receiving end runs receive_hook(). It is envisioned
> that this phase:
>
> a. parses the updated-to object names, and appends the push
> certificate (still GPG signed) to a note attached to each of the
> objects that will sit at the tip of the refs;
I recall Gentoo wanted something like this (recording who pushes
what). Pulling Robin in if he has any comments.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/2] push -s: skeleton
From: Junio C Hamano @ 2011-09-07 22:21 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <CAJo=hJtz6fa4XfC-4ghryP_nfg3sbcrE2bKauj+F7w2Z_8Ckvw@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> Yes. Above we flushed the req_buf and send that in an HTTP request.
> You need to hoist this block above the "if (args->stateless_rpc)"
> segment.
What do you mean by "hoist"? For the req advertisement, it seems that you
are not hoisting anything but duplicating the code, turning safe_write()
followed by flush into packet-buf-flush and sending the result over the
sideband. Shouldn't this new data be sent over the sideband-to-http the
same way?
Unless you do not want signed push over http, that is...
builtin/send-pack.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 3193f34..37e0313 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -379,9 +379,13 @@ int send_pack(struct send_pack_args *args,
packet_buf_write(&req_buf, "%.*s",
(int)(ep - cp), cp);
}
- /* Do we need anything funky for stateless rpc? */
- safe_write(out, req_buf.buf, req_buf.len);
- packet_flush(out);
+ if (args->stateless_rpc) {
+ packet_buf_flush(&req_buf);
+ send_sideband(out, -1, req_buf.buf, req_buf.len, LARGE_PACKET_MAX);
+ } else {
+ safe_write(out, req_buf.buf, req_buf.len);
+ packet_flush(out);
+ }
}
strbuf_release(&req_buf);
^ permalink raw reply related
* Re: git push output goes into stderr
From: Jeff King @ 2011-09-07 21:57 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Junio C Hamano, Lynn Lin, git
In-Reply-To: <20110906074916.GC28490@ecki>
On Tue, Sep 06, 2011 at 09:49:16AM +0200, Clemens Buchacher wrote:
> On Sun, Sep 04, 2011 at 05:57:53PM -0700, Junio C Hamano wrote:
> > Lynn Lin <lynn.xin.lin@gmail.com> writes:
> >
> > > When I create a local branch and then push it to remote. I find that
> > > the output without error goes into stderr, is this expected?
> >
> > Progress output are sent to the stderr stream.
>
> But it's not only progress output that goes to stderr in case of
> git push. Even the summary written in tranport_print_push_status
> goes to stderr, unless we specify git push --porcelain. Can't we
> let that part of the output go to stdout unconditionally?
We could, though it makes more sense on stderr to me.
Stdout has always been about "the main program output" and stderr about
diagnostic messages. With a program whose main function is to generate
output (e.g., "git tag -l", it's very easy to know that the list of tags
is the main program output (which you don't want to pollute with
anything else), and any problems or even general chattiness goes to
stderr.
But with a program whose main function is to perform an action, like
"git push", I think there are really two ways to look at it:
1. There is no main output; any progress or status update is just
diagnostic chat, and should go to stderr.
2. The main output is the status report; it goes to stdout, and
progress updates go to stderr.
I think both are equally valid mental models, and both are consistent
with the philosophy above. If we switch, I wouldn't be surprised to see
somebody say "why is this going to stdout, it should be on stderr". In
fact, I seem to recall that we've had this discussion before on the
list.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] fetch: bigger forced-update warnings
From: Jeff King @ 2011-09-07 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Michael J Gruber, git
In-Reply-To: <7vty8o10kj.fsf@alter.siamese.dyndns.org>
On Wed, Sep 07, 2011 at 02:53:32PM -0700, Junio C Hamano wrote:
> > Some branches are expected to rewind, so the prominent
> > warning would be annoying. However, git doesn't know what
> > the expectation is for a particular branch. We can have it
> > guess by peeking at the lost couple of reflog entries. If we
>
> s/lost/last/
Oops, thanks.
> This is slightly offtopic, but I have been wondering if this approach do
> the right thing for "git pull". Wouldn't the underlying "git fetch" give a
> warning, and then the calling "git pull" go ahead and make a merge,
> scrolling the warning away with the merge/update summary diffstat? That
> would be a larger change if "git pull" needs to stash away the warning
> message, do its thing and then spit out the warning later.
I think this particular warning has nothing to do with git-pull. But
rather, that we should _always_ abort a pull with a forced-update.
Because the only sane things to do there are:
1. Stop and look around, and see if you should be doing a "git reset"
first.
or
2. "git pull --rebase"
But proceeding with the pull just seems like a disaster. So it is not
about "this usually fast forwards, but isn't now, so let's make the
warning bigger". It is more about noticing that it is a forced-update at
all. Maybe that's what you meant by "off-topic". :)
> > +static int forced_update_is_uncommon(const char *ref)
> > +{
> > + struct update_counts uc;
> > + memset(&uc, 0, sizeof(&uc));
> > + if (for_each_recent_reflog_ent(ref, count_updates, 4096, &uc) < 0)
> > + for_each_reflog_ent(ref, count_updates, &uc);
> > + return uc.fastforward && uc.forced <= 1; /* 1 for the one we just did */
> > +}
>
> Looks sensible.
Now we just need to paint the shed. :)
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] fetch: bigger forced-update warnings
From: Junio C Hamano @ 2011-09-07 21:53 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Michael J Gruber, git
In-Reply-To: <20110907212042.GG13364@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Subject: fetch: bigger forced-update warnings
>
> The default fetch refspec allows forced-updates. We already
> print "forced update" in the status table, but it's easy to
> miss. Let's make the warning a little more prominent.
>
> Some branches are expected to rewind, so the prominent
> warning would be annoying. However, git doesn't know what
> the expectation is for a particular branch. We can have it
> guess by peeking at the lost couple of reflog entries. If we
s/lost/last/
> see all fast forwards, then a new forced-update is probably
> noteworthy. If we see something that force-updates all the
> time, it's probably boring and not worth displaying the big
> warning (we keep the status table "forced update" note, of
> course).
>
> Signed-off-by: Jeff King <peff@peff.net>
This is slightly offtopic, but I have been wondering if this approach do
the right thing for "git pull". Wouldn't the underlying "git fetch" give a
warning, and then the calling "git pull" go ahead and make a merge,
scrolling the warning away with the merge/update summary diffstat? That
would be a larger change if "git pull" needs to stash away the warning
message, do its thing and then spit out the warning later.
> +static int forced_update_is_uncommon(const char *ref)
> +{
> + struct update_counts uc;
> + memset(&uc, 0, sizeof(&uc));
> + if (for_each_recent_reflog_ent(ref, count_updates, 4096, &uc) < 0)
> + for_each_reflog_ent(ref, count_updates, &uc);
> + return uc.fastforward && uc.forced <= 1; /* 1 for the one we just did */
> +}
Looks sensible.
^ permalink raw reply
* Re: [RFC/PATCH] fetch: bigger forced-update warnings
From: Shawn Pearce @ 2011-09-07 21:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20110907212042.GG13364@sigill.intra.peff.net>
On Wed, Sep 7, 2011 at 14:20, Jeff King <peff@peff.net> wrote:
> + if (uncommon_forced_update)
> + warning("HEY STUPID FIX YOUR TOPICS");
<action>
<type>paint</type>
<object>bikeshed</object>
<why>because-i-can</why>
How about:
warning("!!! REMOTE BRANCH REWOUND HISTORY !!!");
warning(" Check status report for branches that rewound.");
</action>
--
Shawn.
^ permalink raw reply
* Re: Pushing with --mirror over HTTP?
From: Jeff King @ 2011-09-07 21:39 UTC (permalink / raw)
To: Eli Barzilay; +Cc: git
In-Reply-To: <20068.19089.303108.950233@winooski.ccs.neu.edu>
On Mon, Sep 05, 2011 at 12:05:37AM -0400, Eli Barzilay wrote:
> Is there anything broken with pushing with mirror over HTTP? I'm
> trying that with a github url, and I get a broken-looking error
> message:
>
> remote part of refspec is not a valid name in :.have
It's probably nothing to do with http, but rather with alternate object
databases on the server (which GitHub uses heavily). The server hands
out fake ".have" refs telling you it has some other branch tips to base
packs off of. So I suspect the "push --mirror" code is simply wrong for
trying to update those refs (it may be exacerbated by using http,
though, as the remote helper code seems to have some extra checks).
> and with the google code, I get:
>
> error: unable to push to unqualified destination: HEAD
>
> Pushing to both of these work fine without `--mirror'.
This one, I'm not sure. It may be related.
> (BTW, as a workaround, I'm using
> push --force --tags <url> :
> is this achieving the same effect for a repo without weird refs?)
Not quite. I think:
git push --force <url> refs/*:refs/*
would be closer. But even that's not quite right. I believe that
"--mirror" will also delete any remote refs that don't exist locally
(which is why you are seeing the ":.have" refspec above, which attempts
to delete it).
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef
From: Jeff King @ 2011-09-07 21:35 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, John S. Urban", Tor Arntsen, knittl, Junio C Hamano
In-Reply-To: <201109072329.18338.trast@student.ethz.ch>
On Wed, Sep 07, 2011 at 11:29:17PM +0200, Thomas Rast wrote:
> Admittedly I never considered the problem of supposedly-immutable
> notes here. The whole point was to help users who had no idea that
> the string put there should probably start with refs/notes/.
>
> So maybe the patch should instead say something along the lines of, to
> enable rewriting for the notes ref called foo, put refs/notes/foo --
> which to a core gitter of course sounds extremely redundant.
>
> But what about the general issue of users who *have* put refs/notes/*,
> and then some software comes along that does not expect them to be
> rewritten? Do we declare the software broken, or discourage from such
> blanket rewriting?
I think putting "refs/notes/*" is a perfectly reasonable thing from the
user's perspective, and I'd hate to take away that convenience (and
especially, I think in the long run, we'd like to have a hierarchy of
notes that have rewriting turned on by default).
The cache code is probably what should be changed, then. It can move to
"refs/cache", I guess, though I'm not too happy with that. The notes
code assumes refs/notes in several places, and it's nice to be able to
look at the cache trees with "--notes=cache/foo".
Maybe some way of saying "every notes tree gets rewriting, except ones
in refs/notes/cache"?
Right now it's not a big problem. The only such immutable cache in a
released version of git is the textconv cache, and it only contains
blobs. Which, AFAIK, cannot be subject to rewriting. So we could put it
off until another such cache comes along.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef
From: Thomas Rast @ 2011-09-07 21:29 UTC (permalink / raw)
To: Jeff King; +Cc: git, John S. Urban", Tor Arntsen, knittl, Junio C Hamano
In-Reply-To: <20110907212310.GH13364@sigill.intra.peff.net>
Jeff King wrote:
> On Sun, Sep 04, 2011 at 10:27:04PM +0200, Thomas Rast wrote:
>
> > Users had problems finding a working setting for notes.rewriteRef.
> > Document how to enable rewriting for all notes.
>
> Hmm. Is this a safe thing to recommend?
>
> I think the idea of storing something like generation numbers in
> git-notes is dead at this point, but it would be quite disastrous to
> have generation numbers copied to rebased commits. Ditto for something
> like a patch-id cache. Should these sorts of immutable cache notes, if
> and when they do come about, go into a separate hierarchy?
Admittedly I never considered the problem of supposedly-immutable
notes here. The whole point was to help users who had no idea that
the string put there should probably start with refs/notes/.
So maybe the patch should instead say something along the lines of, to
enable rewriting for the notes ref called foo, put refs/notes/foo --
which to a core gitter of course sounds extremely redundant.
But what about the general issue of users who *have* put refs/notes/*,
and then some software comes along that does not expect them to be
rewritten? Do we declare the software broken, or discourage from such
blanket rewriting?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef
From: Jeff King @ 2011-09-07 21:23 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, John S. Urban", Tor Arntsen, knittl, Junio C Hamano
In-Reply-To: <f415402994735a60664e1f9f85be490a68b25ed3.1315167848.git.trast@student.ethz.ch>
On Sun, Sep 04, 2011 at 10:27:04PM +0200, Thomas Rast wrote:
> Users had problems finding a working setting for notes.rewriteRef.
> Document how to enable rewriting for all notes.
Hmm. Is this a safe thing to recommend?
I think the idea of storing something like generation numbers in
git-notes is dead at this point, but it would be quite disastrous to
have generation numbers copied to rebased commits. Ditto for something
like a patch-id cache. Should these sorts of immutable cache notes, if
and when they do come about, go into a separate hierarchy?
-Peff
^ permalink raw reply
* [RFC/PATCH] fetch: bigger forced-update warnings
From: Jeff King @ 2011-09-07 21:20 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <CAJo=hJvFSegSzTOMj824PoG=soj75JMChfRnjyz4rNgUcVM=Jw@mail.gmail.com>
On Mon, Sep 05, 2011 at 02:14:57PM -0700, Shawn O. Pearce wrote:
> > Right. What I mean is, what should the bigger warning look like?
>
> Its a bikeshed. I refuse to paint bikesheds. :-)
Hmph. Somebody has to write the patch. :P
> > Also, you suggested caching to avoid looking through the whole reflog
> > each time. I think you could probably just sample the last 10 or so
> > reflog entries to get an idea.
>
> Good point. 10 or so last records might be representative of the
> branch's recent behavior, which is all that matters to the user who
> wants this warning.
Actually, because recent ones are near the end, it's much easier to say
"look at the last 4096 bytes of reflogs" rather than "look at exactly
10". For our purposes, it's about the same (actually 4096 is probably
more like 18-20, depending on the exact size of each entry. But it's a
page, so it's probably reasonable).
-- >8 --
Subject: fetch: bigger forced-update warnings
The default fetch refspec allows forced-updates. We already
print "forced update" in the status table, but it's easy to
miss. Let's make the warning a little more prominent.
Some branches are expected to rewind, so the prominent
warning would be annoying. However, git doesn't know what
the expectation is for a particular branch. We can have it
guess by peeking at the lost couple of reflog entries. If we
see all fast forwards, then a new forced-update is probably
noteworthy. If we see something that force-updates all the
time, it's probably boring and not worth displaying the big
warning (we keep the status table "forced update" note, of
course).
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/fetch.c | 39 +++++++++++++++++++++++++++++++++++++--
1 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 93c9938..93bfefa 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -208,6 +208,34 @@ static struct ref *get_ref_map(struct transport *transport,
return ref_map;
}
+struct update_counts {
+ unsigned fastforward;
+ unsigned forced;
+};
+
+static int count_updates(unsigned char *osha1, unsigned char *nsha1,
+ const char *email, unsigned long timestamp, int tz,
+ const char *message, void *data)
+{
+ struct update_counts *uc = data;
+ /* We could check the ancestry of osha1 and nsha1, but this is way
+ * cheaper */
+ if (!prefixcmp(message, "fetch: fast-forward"))
+ uc->fastforward++;
+ else if (!prefixcmp(message, "fetch: forced-update\n"))
+ uc->forced++;
+ return 0;
+}
+
+static int forced_update_is_uncommon(const char *ref)
+{
+ struct update_counts uc;
+ memset(&uc, 0, sizeof(&uc));
+ if (for_each_recent_reflog_ent(ref, count_updates, 4096, &uc) < 0)
+ for_each_reflog_ent(ref, count_updates, &uc);
+ return uc.fastforward && uc.forced <= 1; /* 1 for the one we just did */
+}
+
#define STORE_REF_ERROR_OTHER 1
#define STORE_REF_ERROR_DF_CONFLICT 2
@@ -239,7 +267,8 @@ static int s_update_ref(const char *action,
static int update_local_ref(struct ref *ref,
const char *remote,
- char *display)
+ char *display,
+ int *uncommon_forced_update)
{
struct commit *current = NULL, *updated;
enum object_type type;
@@ -336,6 +365,8 @@ static int update_local_ref(struct ref *ref,
TRANSPORT_SUMMARY_WIDTH, quickref, REFCOL_WIDTH, remote,
pretty_ref,
r ? _("unable to update local ref") : _("forced update"));
+ if (!r && forced_update_is_uncommon(ref->name))
+ *uncommon_forced_update = 1;
return r;
} else {
sprintf(display, "! %-*s %-*s -> %s %s",
@@ -355,6 +386,7 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
const char *what, *kind;
struct ref *rm;
char *url, *filename = dry_run ? "/dev/null" : git_path("FETCH_HEAD");
+ int uncommon_forced_update = 0;
fp = fopen(filename, "a");
if (!fp)
@@ -428,7 +460,8 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
fputc('\n', fp);
if (ref) {
- rc |= update_local_ref(ref, what, note);
+ rc |= update_local_ref(ref, what, note,
+ &uncommon_forced_update);
free(ref);
} else
sprintf(note, "* %-*s %-*s -> FETCH_HEAD",
@@ -450,6 +483,8 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
error(_("some local refs could not be updated; try running\n"
" 'git remote prune %s' to remove any old, conflicting "
"branches"), remote_name);
+ if (uncommon_forced_update)
+ warning("HEY STUPID FIX YOUR TOPICS");
return rc;
}
--
1.7.6.10.g62f04
^ permalink raw reply related
* Re: [PATCH 2/2] push -s: skeleton
From: Shawn Pearce @ 2011-09-07 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbouw2hqg.fsf@alter.siamese.dyndns.org>
On Wed, Sep 7, 2011 at 13:57, Junio C Hamano <gitster@pobox.com> wrote:
> If a tag is GPG-signed, and if you trust the cryptographic robustness of
> the SHA-1 and GPG, you can guarantee that all the history leading to the
> signed commit is not tampered with. However, it would be both cumbersome
> and cluttering to sign each and every commit. Especially if you strive to
> keep your history clean by tweaking, rewriting and polishing your commits
> before pushing the resulting history out, many commits you will create
> locally end up not mattering at all, and it is a waste of time to sign
> them.
>
> A better alternative could be to sign a "push certificate" (for the lack
> of better name) every time you push, asserting that what commits you are
> pushing to update which refs. The basic workflow goes like this:
>
> 1. You push out your work with "git push -s";
Yay!
> And here is a skeleton to implement it. It has all the necessary protocol
> extensions implemented (although I do not know if we need separate
> codepath for stateless RPC mode), but does not have subroutines to:
Yea, its broken for stateless RPC. See below.
> +static char *receive_push_certificate(void)
> +{
> + struct strbuf cert = STRBUF_INIT;
> + for (;;) {
> + char line[1000];
1000 isn't enough for some certificates. Imagine pushing a Gerrit Code
Review managed repository with 2M worth of advertisement data at once.
You can't sign that in 1000 bytes.
> @@ -326,6 +366,23 @@ int send_pack(struct send_pack_args *args,
> safe_write(out, req_buf.buf, req_buf.len);
> packet_flush(out);
> }
> +
> + if (signed_push) {
> + char *cp, *ep;
> +
> + sign_push_certificate(&push_cert);
> + strbuf_reset(&req_buf);
> + for (cp = push_cert.buf; *cp; cp = ep) {
> + ep = strchrnul(cp, '\n');
> + if (*ep == '\n')
> + ep++;
> + packet_buf_write(&req_buf, "%.*s",
> + (int)(ep - cp), cp);
> + }
> + /* Do we need anything funky for stateless rpc? */
Yes. Above we flushed the req_buf and send that in an HTTP request.
You need to hoist this block above the "if (args->stateless_rpc)"
segment.
--
Shawn.
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Junio C Hamano @ 2011-09-07 21:08 UTC (permalink / raw)
To: Kyle Neath; +Cc: Michael J Gruber, git
In-Reply-To: <CAFcyEthuf49_kOmoLmoSSbNJN+iOBpicP4-eFAV5wL5_RffwGg@mail.gmail.com>
Kyle Neath <kneath@gmail.com> writes:
> ... However, I do think this feature is
> important enough to delay the release. I trust in the judgement of the core
> members to know when something is ready for inclusion in master.
We do not delay a release for any new feature, as we shoot for 8 to 10
week release cycle these days. For an important feature that we must avoid
painting ourselves into a corner that we cannot get out of if we screw up
the initial design due to possible backward compatibility issues, it is
even more true than other minor features.
This cycle is being delayed longer than anybody wishes for an external
reason, and unfortunately it does not mean we have longer period to
eyeball the topics in cooking due to that same external reason.
^ permalink raw reply
* Re: [ANNOUNCE] GitTogether 2011 - Oct 24th/25th
From: Shawn Pearce @ 2011-09-07 21:06 UTC (permalink / raw)
To: Scott Chacon; +Cc: Jeff King, git
In-Reply-To: <CAP2yMa+A3CW63ra8ndj6jtb6vHmP-1f78NB2zBLZcRBueMNUBQ@mail.gmail.com>
On Wed, Sep 7, 2011 at 13:44, Scott Chacon <schacon@gmail.com> wrote:
> On Wed, Sep 7, 2011 at 7:30 PM, Jeff King <peff@peff.net> wrote:
>> On Wed, Sep 07, 2011 at 11:38:18AM -0700, Shawn O. Pearce wrote:
>>
>>> As we approach 50 people, does it makes sense to be able to break the
>>> event down into 2 "tracks", and have 2 meeting spaces available?
>>
>> I think that's reasonable, especially as we grow. However, one of the
>> valuable things (for me, anyway) in previous GitTogethers is throwing
>> all of these people together to some degree.
>>
>> Maybe we can be segmented for part of the conference, and then bring
>> everybody together for other parts. I dunno. I guess that involves
>> predicting which parts will be useful for everybody to be together.
>
> Yeah, I think it would be best to have one track, but have breakout
> periods where people can work on stuff together or have smaller
> conversations, or even have smaller rooms that people can go into to
> work for a while.
Right now we are looking for new space on the Google campus that would
allow us to get everyone in 1 room together, but also offer some
break-out space. More details as soon as I know. :-)
I'd like to keep it still somewhat unconferencey. Maybe do the morning
before lunch with everyone together and the topics that have the most
interest, and the afternoons for more breakout style smaller
discussions, especially if a subgroup identifies with something from
the morning and they want to purse that a little bit more in person.
--
Shawn.
^ permalink raw reply
* [PATCH] send-mail: Add option to sleep between sending each email.
From: Georgi Chorbadzhiyski @ 2011-09-07 20:43 UTC (permalink / raw)
To: git
Sometimes when sending lots of changes it is not nice
to send emails as fast as possible. Of course you can
confirm each email after waiting couple of seconds but
this is not optimal. This patch adds --sleep option
to git-send-mail and corresponding sendmail.sleep config
variable to control how much seconds to wait between
sending each email. The default is 0 (not wait at all).
Signed-off-by: Georgi Chorbadzhiyski <gf@unixsol.org>
---
Documentation/git-send-email.txt | 6 ++++++
git-send-email.perl | 13 ++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 327233c..2ceb69f 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -298,6 +298,9 @@ Default is the value of 'sendemail.confirm' configuration value; if that
is unspecified, default to 'auto' unless any of the suppress options
have been specified, in which case default to 'compose'.
+--sleep=<seconds>::
+ How many seconds to wait between sending each email.
+
--dry-run::
Do everything except actually send the emails.
@@ -349,6 +352,9 @@ sendemail.confirm::
one of 'always', 'never', 'cc', 'compose', or 'auto'. See '--confirm'
in the previous section for the meaning of these values.
+sendemail.sleep::
+ Sets how many seconds to wait between sending each email.
+
EXAMPLE
-------
Use gmail as the smtp server
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..7239fd4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -84,6 +84,7 @@ git send-email [options] <file | directory | rev-list options >
Administering:
--confirm <str> * Confirm recipients before sending;
auto, cc, compose, always, or never.
+ --sleep <int> * Sleep <int> seconds between sending mails.
--quiet * Output one line of info per email.
--dry-run * Don't actually send the emails.
--[no-]validate * Perform patch sanity checks. Default on.
@@ -195,7 +196,7 @@ my ($to_cmd, $cc_cmd);
my ($smtp_server, $smtp_server_port, @smtp_server_options);
my ($smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
-my ($validate, $confirm);
+my ($validate, $confirm, $sleep);
my (@suppress_cc);
my ($auto_8bit_encoding);
@@ -230,6 +231,7 @@ my %config_settings = (
"envelopesender" => \$envelope_sender,
"multiedit" => \$multiedit,
"confirm" => \$confirm,
+ "sleep" => \$sleep,
"from" => \$sender,
"assume8bitencoding" => \$auto_8bit_encoding,
);
@@ -304,6 +306,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
"confirm=s" => \$confirm,
+ "sleep:i" => \$sleep,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -405,6 +408,9 @@ if ($confirm_unconfigured) {
die "Unknown --confirm setting: '$confirm'\n"
unless $confirm =~ /^(?:auto|cc|compose|always|never)/;
+# Set sleep's default value
+$sleep = 0 if (!defined $sleep);
+
# Debugging, print out the suppressions.
if (0) {
print "suppressions:\n";
@@ -1143,6 +1149,11 @@ X-Mailer: git-send-email $gitversion
}
}
+ if (!$dry_run && $sleep) {
+ print "Sleeping: $sleep second(s).\n" if (!$quiet);
+ sleep($sleep);
+ };
+
return 1;
}
--
1.7.5.1
^ permalink raw reply related
* Re: [ANNOUNCE] GitTogether 2011 - Oct 24th/25th
From: Junio C Hamano @ 2011-09-07 21:00 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Scott Chacon, git
In-Reply-To: <20110907193006.GB13364@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think that's reasonable, especially as we grow. However, one of the
> valuable things (for me, anyway) in previous GitTogethers is throwing
> all of these people together to some degree. I'm not terribly interested
> in day-to-day Gerrit issues, but sometimes the discussions start from
> some minor Gerrit annoyance, and we end up realizing that the right
> solution involves changes at a more fundamental layer, and all of git is
> better as a result. I'd hate to lose that developer/user interaction.
Same here, as I have been meaning to gauge interests from non-Gerrit
people on issues identified in Gerrit land (e.g. expand-refs).
> Maybe we can be segmented for part of the conference, and then bring
> everybody together for other parts. I dunno. I guess that involves
> predicting which parts will be useful for everybody to be together.
Also we would need to predict what parts we will have to begin with ;-).
^ permalink raw reply
* Re: Git without morning coffee
From: Michael Witten @ 2011-09-07 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Git Mailing List
In-Reply-To: <7vy5y02qf4.fsf@alter.siamese.dyndns.org>
On Wed, Sep 7, 2011 at 17:49, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> I think it would be great if at some point you could write a detailed
>> tutorial of how you maintain git...
>
> Is MaintNotes[*1*] taken together with Documentation/howto/maintain-git.txt
> insufficient?
>
> [Reference]
> *1* http://git-blame.blogspot.com/p/note-from-maintainer.html
I was unaware of the `howto'; I look forward to reading it.
^ permalink raw reply
* [PATCH 2/2] push -s: skeleton
From: Junio C Hamano @ 2011-09-07 20:57 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <7vfwk82hrt.fsf@alter.siamese.dyndns.org>
If a tag is GPG-signed, and if you trust the cryptographic robustness of
the SHA-1 and GPG, you can guarantee that all the history leading to the
signed commit is not tampered with. However, it would be both cumbersome
and cluttering to sign each and every commit. Especially if you strive to
keep your history clean by tweaking, rewriting and polishing your commits
before pushing the resulting history out, many commits you will create
locally end up not mattering at all, and it is a waste of time to sign
them.
A better alternative could be to sign a "push certificate" (for the lack
of better name) every time you push, asserting that what commits you are
pushing to update which refs. The basic workflow goes like this:
1. You push out your work with "git push -s";
2. "git push", as usual, learns where the remote refs are and which refs
are to be updated with this push. It prepares a text file in memory
that looks like this using this information:
Push-Certificate-Version: 1
Pusher: Junio C Hamano <gitster@pobox.com> 1315427886 -0700
Update: e83c51633... d4e58965f... refs/heads/master
Update: 5a144a288... 7931f38a2... refs/heads/next
An actual push certificate records full 40-char object name, but it is
ellided for brevity here.
The user then is asked to sign this push certificate using GPG. The
result is carried to the other side (i.e. receive-pack). In the
protocol exchange, this step comes immediately after the sender tells
what the result of the push should be, before it sends the pack data.
3. The receiving end will keep the signed push certificate in core,
receives the pack data and unpacks (or stores and runs index-pack)
as usual.
4. A new phase to record the push certificate is introduced in the
codepath after the receiving end runs receive_hook(). It is envisioned
that this phase:
a. parses the updated-to object names, and appends the push
certificate (still GPG signed) to a note attached to each of the
objects that will sit at the tip of the refs;
b. verifies that the push certificate is signed with a GPG key that is
authorized to push into this repository; and/or
c. invokes pre-push-verify-signature hook, feeds the push
certificate to it and asks it to veto the ref updates.
And here is a skeleton to implement it. It has all the necessary protocol
extensions implemented (although I do not know if we need separate
codepath for stateless RPC mode), but does not have subroutines to:
- Sign the certificate with GPG key;
- Parse the signed certificate to identify the updated-to objects, and
add the certificate as notes to them;
- Verify the certificate and find out what GPG key was used to sign it;
or
- Invoke and feed the certificate to pre-push-verify-hook.
all of which should be fairly trivial. The places that needs to implement
these are clearly marked with large comments, so I'll leave it up to other
people who are interested in the topic to fill in the blanks ;-)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/push.c | 1 +
builtin/receive-pack.c | 54 +++++++++++++++++++++++++++++++++++++++-
builtin/send-pack.c | 65 +++++++++++++++++++++++++++++++++++++++++++++---
send-pack.h | 1 +
transport.c | 4 +++
transport.h | 4 +++
6 files changed, 124 insertions(+), 5 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 35cce53..2238f4e 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -261,6 +261,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT('u', "set-upstream", &flags, "set upstream for git pull/status",
TRANSPORT_PUSH_SET_UPSTREAM),
OPT_BOOLEAN(0, "progress", &progress, "force progress reporting"),
+ OPT_BIT('s', "signed", &flags, "GPG sign the push", TRANSPORT_PUSH_SIGNED),
OPT_END()
};
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ae164da..307fc3b 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -30,12 +30,14 @@ static int receive_unpack_limit = -1;
static int transfer_unpack_limit = -1;
static int unpack_limit = 100;
static int report_status;
+static int signed_push;
static int use_sideband;
static int prefer_ofs_delta = 1;
static int auto_update_server_info;
static int auto_gc = 1;
static const char *head_name;
static int sent_capabilities;
+static char *push_certificate;
static enum deny_action parse_deny_action(const char *var, const char *value)
{
@@ -114,7 +116,7 @@ static int show_ref(const char *path, const unsigned char *sha1, int flag, void
else
packet_write(1, "%s %s%c%s%s\n",
sha1_to_hex(sha1), path, 0,
- " report-status delete-refs side-band-64k",
+ " report-status delete-refs side-band-64k signed-push",
prefer_ofs_delta ? " ofs-delta" : "");
sent_capabilities = 1;
return 0;
@@ -579,6 +581,31 @@ static void check_aliased_updates(struct command *commands)
string_list_clear(&ref_list, 0);
}
+static int record_signed_push(char *cert)
+{
+ /*
+ * This is the place for you to parse the signed push
+ * certificate, grab the commit object names the push updates
+ * refs to, and append the certificate to the notes to these
+ * commits.
+ *
+ * You could also feed the signed push certificate to GPG,
+ * verify the signer identity, and all the other fun stuff,
+ * including feeding it to "pre-push-verify-signature" hook.
+ *
+ * Here we just throw it to stderr to demonstrate that the
+ * codepath is being exercised.
+ */
+ char *cp, *ep;
+ for (cp = cert; *cp; cp = ep) {
+ ep = strchrnul(cp, '\n');
+ if (*ep == '\n')
+ ep++;
+ fprintf(stderr, "RSP: %.*s", (int)(ep - cp), cp);
+ }
+ return 0;
+}
+
static void execute_commands(struct command *commands, const char *unpacker_error)
{
struct command *cmd;
@@ -596,6 +623,12 @@ static void execute_commands(struct command *commands, const char *unpacker_erro
return;
}
+ if (push_certificate && record_signed_push(push_certificate)) {
+ for (cmd = commands; cmd; cmd = cmd->next)
+ cmd->error_string = "n/a (push signature error)";
+ return;
+ }
+
check_aliased_updates(commands);
head_name = resolve_ref("HEAD", sha1, 0, NULL);
@@ -636,6 +669,8 @@ static struct command *read_head_info(void)
report_status = 1;
if (strstr(refname + reflen + 1, "side-band-64k"))
use_sideband = LARGE_PACKET_MAX;
+ if (strstr(refname + reflen + 1, "signed-push"))
+ signed_push = 1;
}
cmd = xcalloc(1, sizeof(struct command) + len - 80);
hashcpy(cmd->old_sha1, old_sha1);
@@ -731,6 +766,21 @@ static const char *unpack(void)
}
}
+static char *receive_push_certificate(void)
+{
+ struct strbuf cert = STRBUF_INIT;
+ for (;;) {
+ char line[1000];
+ int len;
+
+ len = packet_read_line(0, line, sizeof(line));
+ if (!len)
+ break;
+ strbuf_add(&cert, line, len);
+ }
+ return strbuf_detach(&cert, NULL);
+}
+
static void report(struct command *commands, const char *unpack_status)
{
struct command *cmd;
@@ -846,6 +896,8 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
if ((commands = read_head_info()) != NULL) {
const char *unpack_status = NULL;
+ if (signed_push)
+ push_certificate = receive_push_certificate();
if (!delete_only(commands))
unpack_status = unpack();
execute_commands(commands, unpack_status);
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 87833f4..3193f34 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -237,6 +237,27 @@ static int sideband_demux(int in, int out, void *data)
return ret;
}
+static void sign_push_certificate(struct strbuf *cert)
+{
+ /*
+ * Here, take the contents of cert->buf, and have the user GPG
+ * sign it, and read it back in the strbuf.
+ *
+ * You may want to append some extra info to cert before giving
+ * it to GPG, possibly via a hook.
+ *
+ * Here we upcase them just to demonstrate that the codepath
+ * is being exercised.
+ */
+ char *cp;
+ for (cp = cert->buf; *cp; cp++) {
+ int ch = *cp;
+ if ('a' <= ch && ch <= 'z')
+ *cp = toupper(ch);
+ }
+ return;
+}
+
int send_pack(struct send_pack_args *args,
int fd[], struct child_process *conn,
struct ref *remote_refs,
@@ -250,9 +271,11 @@ int send_pack(struct send_pack_args *args,
int allow_deleting_refs = 0;
int status_report = 0;
int use_sideband = 0;
+ int signed_push = 0;
unsigned cmds_sent = 0;
int ret;
struct async demux;
+ struct strbuf push_cert = STRBUF_INIT;
/* Does the other end support the reporting? */
if (server_supports("report-status"))
@@ -270,6 +293,19 @@ int send_pack(struct send_pack_args *args,
return 0;
}
+ if (args->signed_push) {
+ if (server_supports("signed-push"))
+ signed_push = !args->dry_run;
+ else
+ warning("The receiving side does not support signed-push");
+ }
+
+ if (signed_push) {
+ const char *committer_info = git_committer_info(0);
+ strbuf_addstr(&push_cert, "Push-Certificate-Version: 1\n");
+ strbuf_addf(&push_cert, "Pusher: %s\n", committer_info);
+ }
+
/*
* Finally, tell the other end!
*/
@@ -301,15 +337,19 @@ int send_pack(struct send_pack_args *args,
char *old_hex = sha1_to_hex(ref->old_sha1);
char *new_hex = sha1_to_hex(ref->new_sha1);
- if (!cmds_sent && (status_report || use_sideband)) {
- packet_buf_write(&req_buf, "%s %s %s%c%s%s",
+ if (!cmds_sent &&
+ (status_report || use_sideband || signed_push))
+ packet_buf_write(&req_buf, "%s %s %s%c%s%s%s",
old_hex, new_hex, ref->name, 0,
status_report ? " report-status" : "",
- use_sideband ? " side-band-64k" : "");
- }
+ use_sideband ? " side-band-64k" : "",
+ signed_push ? " signed-push" : "");
else
packet_buf_write(&req_buf, "%s %s %s",
old_hex, new_hex, ref->name);
+ if (signed_push && hashcmp(ref->old_sha1, ref->new_sha1))
+ strbuf_addf(&push_cert, "Update: %s %s %s\n",
+ old_hex, new_hex, ref->name);
ref->status = status_report ?
REF_STATUS_EXPECTING_REPORT :
REF_STATUS_OK;
@@ -326,6 +366,23 @@ int send_pack(struct send_pack_args *args,
safe_write(out, req_buf.buf, req_buf.len);
packet_flush(out);
}
+
+ if (signed_push) {
+ char *cp, *ep;
+
+ sign_push_certificate(&push_cert);
+ strbuf_reset(&req_buf);
+ for (cp = push_cert.buf; *cp; cp = ep) {
+ ep = strchrnul(cp, '\n');
+ if (*ep == '\n')
+ ep++;
+ packet_buf_write(&req_buf, "%.*s",
+ (int)(ep - cp), cp);
+ }
+ /* Do we need anything funky for stateless rpc? */
+ safe_write(out, req_buf.buf, req_buf.len);
+ packet_flush(out);
+ }
strbuf_release(&req_buf);
if (use_sideband && cmds_sent) {
diff --git a/send-pack.h b/send-pack.h
index 05d7ab1..754943e 100644
--- a/send-pack.h
+++ b/send-pack.h
@@ -11,6 +11,7 @@ struct send_pack_args {
use_thin_pack:1,
use_ofs_delta:1,
dry_run:1,
+ signed_push:1,
stateless_rpc:1;
};
diff --git a/transport.c b/transport.c
index fa279d5..7a7ffe4 100644
--- a/transport.c
+++ b/transport.c
@@ -476,6 +476,9 @@ static int set_git_option(struct git_transport_options *opts,
else
opts->depth = atoi(value);
return 0;
+ } else if (!strcmp(name, TRANS_OPT_SIGNED_PUSH)) {
+ opts->signed_push = !!value;
+ return 0;
}
return 1;
}
@@ -793,6 +796,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
args.progress = transport->progress;
args.dry_run = !!(flags & TRANSPORT_PUSH_DRY_RUN);
args.porcelain = !!(flags & TRANSPORT_PUSH_PORCELAIN);
+ args.signed_push = !!(flags & TRANSPORT_PUSH_SIGNED);
ret = send_pack(&args, data->fd, data->conn, remote_refs,
&data->extra_have);
diff --git a/transport.h b/transport.h
index 059b330..d2fa478 100644
--- a/transport.h
+++ b/transport.h
@@ -8,6 +8,7 @@ struct git_transport_options {
unsigned thin : 1;
unsigned keep : 1;
unsigned followtags : 1;
+ unsigned signed_push : 1;
int depth;
const char *uploadpack;
const char *receivepack;
@@ -102,6 +103,7 @@ struct transport {
#define TRANSPORT_PUSH_PORCELAIN 16
#define TRANSPORT_PUSH_SET_UPSTREAM 32
#define TRANSPORT_RECURSE_SUBMODULES_CHECK 64
+#define TRANSPORT_PUSH_SIGNED 128
#define TRANSPORT_SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)
@@ -128,6 +130,8 @@ struct transport *transport_get(struct remote *, const char *);
/* Aggressively fetch annotated tags if possible */
#define TRANS_OPT_FOLLOWTAGS "followtags"
+#define TRANS_OPT_SIGNED_PUSH "signedpush"
+
/**
* Returns 0 if the option was used, non-zero otherwise. Prints a
* message to stderr if the option is not used.
--
1.7.7.rc0.186.g50963
^ permalink raw reply related
* [PATCH 1/2] send-pack: typofix error message
From: Junio C Hamano @ 2011-09-07 20:56 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
The message identifies the process as receive-pack when it cannot fork the
sideband demultiplexer. We are actually a send-pack.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/send-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index c1f6ddd..87833f4 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -334,7 +334,7 @@ int send_pack(struct send_pack_args *args,
demux.data = fd;
demux.out = -1;
if (start_async(&demux))
- die("receive-pack: unable to fork off sideband demultiplexer");
+ die("send-pack: unable to fork off sideband demultiplexer");
in = demux.out;
}
--
1.7.7.rc0.186.g50963
^ permalink raw reply related
* Re: [ANNOUNCE] GitTogether 2011 - Oct 24th/25th
From: Scott Chacon @ 2011-09-07 20:44 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, git
In-Reply-To: <20110907193006.GB13364@sigill.intra.peff.net>
Hey,
On Wed, Sep 7, 2011 at 7:30 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Sep 07, 2011 at 11:38:18AM -0700, Shawn O. Pearce wrote:
>
>> As we approach 50 people, does it makes sense to be able to break the
>> event down into 2 "tracks", and have 2 meeting spaces available? I
>> know a number of the folks on the attendee list are Gerrit Code Review
>> / Android sorts of shops and will want to discuss topics related to
>> that that aren't necessarily relevant to the GitHub users / Linux
>> kernel hacking folks that are also on the list. Being able to break
>> off some of those discussions might make the event more interesting
>> for everyone involved.
>
> I think that's reasonable, especially as we grow. However, one of the
> valuable things (for me, anyway) in previous GitTogethers is throwing
> all of these people together to some degree. I'm not terribly interested
> in day-to-day Gerrit issues, but sometimes the discussions start from
> some minor Gerrit annoyance, and we end up realizing that the right
> solution involves changes at a more fundamental layer, and all of git is
> better as a result. I'd hate to lose that developer/user interaction.
>
> Maybe we can be segmented for part of the conference, and then bring
> everybody together for other parts. I dunno. I guess that involves
> predicting which parts will be useful for everybody to be together.
Yeah, I think it would be best to have one track, but have breakout
periods where people can work on stuff together or have smaller
conversations, or even have smaller rooms that people can go into to
work for a while.
I really want to have one track though - I'm personally interested in
everything. I want to know how Gerrit is working these days and
different workflows and stuff. I think we have enough time where even
with 50 or 60 people we could have everyone who wanted to speak (which
isn't going to be everybody) have a chance without being too crazy.
Scott
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Kyle Neath @ 2011-09-07 20:14 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E6769E3.4070003@drmicha.warpmail.net>
Junio C Hamano <gitster@pobox.com> wrote:
> If this were a new, insignificant, and obscure feature in a piece of
> software with mere 20k users, it may be OK to release a new version with
> the feature in an uncooked shape.
For the sake of my paycheck, I should certainly hope not! I'm not at all
suggesting we merge what we have in. However, I do think this feature is
important enough to delay the release. I trust in the judgement of the core
members to know when something is ready for inclusion in master.
Michael J Gruber <git@drmicha.warpmail.net> wrote:
> So, it's been a year or more that you've been aware of the importance of
> this issue (from your/github's perspective), and we hear about it now,
> at the end of the rc phase.
I apologize if it sounds like that. I've been discussing this situation with
many people (including Jeff King) for a very long time now, and it was my
understanding that the credential caching was done and simply waiting for a
new release. This is the first I've heard that it will not be included in
1.7.7, so I'm voicing my opinion now. Admittedly, late in the game - and I
apologize for that.
I'd be happy to help in any capacity I can. Unfortunately I'm no C hacker, and
I've accepted that as a character flaw (it's something I'm working on). I'm
afraid I can't be of much help with the actual code. What I can provide is an
alternate viewpoint to the core team. A viewpoint of someone who's spent 3
years trying to make git easier for newcomers.
I urge the core team to think about what kind of opportunity we have here.
Credential caching isn't some minor feature. It's the last piece of the puzzle
that promotes Smart HTTP to a viable alternative over the git & ssh protocols.
Smart HTTP solves an huge collection of problems people have with using git
day to day. One URL to push privately and pull anonymously. No firewall
restrictions at universities or workplaces. Username & password
authentication. I get kind of turned on just thinking about it.
Kyle
^ permalink raw reply
* Re: [PATCH v4] gitk: Allow commit editing
From: Jeff King @ 2011-09-07 20:10 UTC (permalink / raw)
To: Michal Sojka; +Cc: git, paulus
In-Reply-To: <87fwknaveh.fsf@steelpick.2x.cz>
On Sat, Aug 27, 2011 at 02:31:02PM +0200, Michal Sojka wrote:
> Here is a new version with the micro-optimization.
>
> Another minor change is that this patch now applies to gitk repo
> (http://git.kernel.org/pub/scm/gitk/gitk.git) instead of the main git
> repo.
Thanks. This version fixes most of my complaints and looks reasonable
sane, as long as you accept the idea that starting an interactive rebase
behind the scenes is sane. I'm still not 100% convinced. But then, I am
not a big gitk user, either (I like visualizing with it, but I rarely
want to do anything interactive). So I'll leave Paul and anyone else to
argue or make a decision on that count.
-Peff
^ 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