* Re: warning in tree xxx: contains zero-padded file modes
From: Samuel Lijin @ 2017-02-06 20:26 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, git@vger.kernel.org
In-Reply-To: <CAJZjrdWq+xSEoTypA_hWdQJgioGOHJd3V7djeQ0YxpzvhuoM=g@mail.gmail.com>
On Mon, Feb 6, 2017 at 2:23 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
> I'm just going to go ahead and split this off the git/git-scm.com
> issues thread since this is a distinct topic.
>
> On Mon, Feb 6, 2017 at 12:49 PM, Jeff King <peff@peff.net> wrote:
>> On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:
>>
>>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>>> > # Irrelevant but someone should take a look
>>> >
>>> > 693
>>>
>>> To save people some time (and since i looked at it anyway), this is
>>> about whether "warning in tree xxx: contains zero-padded file modes:
>>> from fsck should be a warning or error. It is a warning now even
>>> though "git -c transfer.fsckobjects=true clone" treats it as an error.
>>> There are some discussions in the past [1] [2] about this.
>
> I think you forgot to link to [2] :p
>
>> The bug that caused the trees is long-fixed. There's a question of
>> how severity levels should be handled in transfer.fsckObjects. By
>> default it treats everything as a reason to reject the object. Dscho
>> added configurable levels a few versions ago. It may be a good idea to
>> tweak the defaults to something more permissive[1].
>>
>>> There's also a question "And I failed to find in the documentation if
>>> transfer.fsckobjects could be disabled per repository, can you confirm
>>> it's not possible for now ?"
>>
>> I don't know why it wouldn't be, though note that it won't override
>> the operation-specific {receive,fetch}.fsckObjects.
>>
>> -Peff
>>
>> [1] If we had a more permissive set of defaults, it would probably make
>> sense to turn on fsckObjects by default. Some of the checks are
>> security-relevant, like disallowing trees with ".GIT",
>> "../../etc/passwd", etc. Those _should_ be handled sanely by the
>> rest of Git, but it serves as a belt-and-suspenders check, and also
>> protects anybody with a buggy Git downstream from you.
>>
>> GitHub has had the feature turned on for ages, with a few caveats:
>>
>> - we loosened the zero-padded mode warning, because it was causing
>> too many false positives
>>
>> - we loosened the timezone checks for the same reason; we've seen
>> time zones that aren't exactly 4 characters before
>>
>> - we occasionally get complaints from people trying to push old
>> histories with bogus committer idents. Usually a missing name or
>> similar.
>>
>> So those are the ones we'd probably need to loosen off the bat, and
>> they're all pretty harmless. But it would be a potential irritating
>> regression for somebody if they have a history with other minor
>> flaws, and Git suddenly starts refusing to clone it.
>
> The linked issue on bugs.debian.org has seen activity recently, which
> is the main reason I mentioned it separately as still relevant:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227
I take it back: last activity was in Feb 2016. >_<
^ permalink raw reply
* Re: warning in tree xxx: contains zero-padded file modes
From: Jeff King @ 2017-02-06 20:32 UTC (permalink / raw)
To: Samuel Lijin; +Cc: Duy Nguyen, git@vger.kernel.org
In-Reply-To: <CAJZjrdWq+xSEoTypA_hWdQJgioGOHJd3V7djeQ0YxpzvhuoM=g@mail.gmail.com>
On Mon, Feb 06, 2017 at 02:23:37PM -0600, Samuel Lijin wrote:
> >> There are some discussions in the past [1] [2] about this.
>
> I think you forgot to link to [2] :p
I think the [1] [2] there were recursive quotes from Duy's email. Those
footnotes were:
[1] http://public-inbox.org/git/%3CCAEBDL5W3DL0v=TusuB7Vg-4bWdAJh5d2Psc1N0Qe+KK3bZH3=Q@mail.gmail.com%3E/
[2] http://public-inbox.org/git/%3C20100326215600.GA10910@spearce.org%3E/
> The linked issue on bugs.debian.org has seen activity recently, which
> is the main reason I mentioned it separately as still relevant:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227
Yeah. I think that's not quite solvable with Git as we have it now. We
have fsck.* and receive.fsck.* to tweak severity levels, but no matching
fetch.fsck.* for handling a push (and presumably a transfer.fsck.* to
cover both fetching and pushing). So there's a potential patch series
for anybody interested.
-Peff
^ permalink raw reply
* Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`
From: Eric Wong @ 2017-02-06 20:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Josh Triplett, git
In-Reply-To: <alpine.DEB.2.20.1702041206130.3496@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> For details, see:
> http://public-inbox.org/git/11340844841342-git-send-email-mailing-lists.git@rawuncut.elitemail.org/
> (this is also an example where public-inbox' thread detection went utterly
> wrong, including way too many mails in the "thread")
Thanks, it should be fixed in an hour or two when reindexing
finishes...
<https://public-inbox.org/meta/20170206200216.GA26676@dcvr/>
but it looks like reindexing is a little buggy in that it reuses
thread IDs, too... (will fix)
The Tor .onion mirrors should be done, first, since they're on
better hardware:
http://hjrcffqmbrq6wope.onion/git/11340844841342-git-send-email-mailing-lists.git@rawuncut.elitemail.org/
http://czquwvybam4bgbro.onion/git/11340844841342-git-send-email-mailing-lists.git@rawuncut.elitemail.org/
> This last example also demonstrates a very curious test case for a
> different difficulty in trying to reconstruct lost correspondences: the
> patch series was applied *twice*, independently of each other. First, on
> the day v3 was submitted, it was applied on top of v1.8.1-rc0 (as commits
> ee26a6e2b8..dd465ce66f), although it was not merged until v1.8.1-rc3. 22
> days later, it was reapplied on top of maint so it could enter v1.8.0.3
> (back then, Git still had "patchlevel" versions): c2999adcd5..008c208c2c.
>
> As you can see, there is a many-to-many relationship here, even if you do
> leave the *original* branch out of the picture entirely.
Fwiw, I've always seen the search ability of public-inbox as
analogous to rename detection in git; in that it can never be
perfect, but can still be tweaked and improved after-the-fact
and be used more flexibly.
Right now, the thread searching public-inbox is loose in that it
favors overmatching based on Subject in addition to References.
But the actual threading algorithm (for display) is strict,
relying only on References. But yeah, there can be tweaks to
improve matching and introducing git (code) repository awareness
into the mail search...
> Will keep you posted,
Likewise :>
> P.S.: I used public-inbox.org links instead of commit references to the
> Git repository containing the mailing list archive, because the format of
> said Git repository is so unfavorable that it was determined very quickly
> in a discussion between Patrick Reynolds (GitHub) and myself that it would
> put totally undue burden on GitHub to mirror it there (compare also Carlos
> Nieto's talk at GitMerge titled "Top Ten Worst Repositories to host on
> GitHub").
Any suggestions on how the repository format can be improved?
I haven't hit insurmountable performance problems, even on
low-end hardware; especially since I started storing blob ids in
Xapian itself, avoiding the expensive tree lookup via git.
The main problem seems to be tree size. Deepening (2/2/36 vs
2/38) might be an option (I think Peff brought that up); but it
might be easier to switch to YYYYMM refs (working like
logrotate) and rely on Xapian to tie the entire thing together.
Some change will definitely be needed for all LKML, but most
projects have less traffic than even git, and should be fine.
But, I am working to undermine centralized messaging systems
(which GitHub and GitLab both are), so they would be wise to
undermine public-inbox all the same ;>
^ permalink raw reply
* Re: git/git-scm.com GH Issue Tracker
From: Junio C Hamano @ 2017-02-06 20:49 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, Samuel Lijin, git@vger.kernel.org
In-Reply-To: <20170206184951.vwq6ib2qzxc542i4@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [1] If we had a more permissive set of defaults, it would probably make
> sense to turn on fsckObjects by default. Some of the checks are
> security-relevant, like disallowing trees with ".GIT",
> "../../etc/passwd", etc. Those _should_ be handled sanely by the
> rest of Git, but it serves as a belt-and-suspenders check, and also
> protects anybody with a buggy Git downstream from you.
Yeah, we really should encourage people to turn it on. Turning it
on by default is one way to do so, of course.
I think the reason why the transfer side is stricter than the local
checking [*1*] is because the problem in the local history is
already done and there is not much the user can do to fix it, while
objects that originate from outside world could be rejected to keep
the receiving repository clean.
> GitHub has had the feature turned on for ages, with a few caveats:
>
> - we loosened the zero-padded mode warning, because it was causing
> too many false positives
>
> - we loosened the timezone checks for the same reason; we've seen
> time zones that aren't exactly 4 characters before
>
> - we occasionally get complaints from people trying to push old
> histories with bogus committer idents. Usually a missing name or
> similar.
As long as we are sure that modern Git and its reimplementations no
longer create objects with this problems, I think loosening these
checks is perfectly sensible, as the only objects that trigger the
check will be the ones buried deep in the history made back when Git
was young.
Of course, that will make it easier to let broken objects created by
newer reimplementations of Git (and bugs in our code that cause us
to create such broken objects) go unnoticed, so we would want to
keep them at warn (not ignore) for the end-users.
> So those are the ones we'd probably need to loosen off the bat, and
> they're all pretty harmless. But it would be a potential irritating
> regression for somebody if they have a history with other minor
> flaws, and Git suddenly starts refusing to clone it.
[Footnote]
*1* ... which is what Jonathan Nieder originally wondered at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227
^ permalink raw reply
* Re: [PATCH v2 0/7] completion bash: add more options and commands
From: Junio C Hamano @ 2017-02-06 21:29 UTC (permalink / raw)
To: cornelius.weig; +Cc: git, szeder.dev, j6t
In-Reply-To: <20170203110159.377-1-cornelius.weig@tngtech.com>
cornelius.weig@tngtech.com writes:
> From: Cornelius Weig <cornelius.weig@tngtech.com>
>
> This is the re-roll of patch series <20170122225724.19360-1-cornelius.weig@tngtech.com>.
>
> This patch series adds all long-options that are mentioned in the synopsis of
> the man-page for the respective git-command. There are only a few exceptions,
> as discussed in the above thread. For example, no unsafe options should be
> completed.
> Furthermore, the patches add subommand option completion for git-submodule and
> git-remote.
Reviewers, do these look good now?
Thanks all.
^ permalink raw reply
* Re: [PATCHv2 00/21] completion: various __gitdir()-related improvements
From: Junio C Hamano @ 2017-02-06 21:29 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20170203024829.8071-1-szeder.dev@gmail.com>
SZEDER Gábor <szeder.dev@gmail.com> writes:
> This is a long overdue reroll of a bunch of bugfixes, cleanups and
> optimizations related to how the completion script finds the path to
> the repository and how it uses that path. Most importantly this
> series adds support for completion following 'git -C path', and it
> eliminates a few subshells and git processes, for the sake of
> fork()+exec() challenged OSes.
Thanks. Queued.
^ permalink raw reply
* Re: git/git-scm.com GH Issue Tracker
From: Jeff King @ 2017-02-06 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Duy Nguyen, Samuel Lijin, git@vger.kernel.org
In-Reply-To: <xmqqlgtj11up.fsf@gitster.mtv.corp.google.com>
On Mon, Feb 06, 2017 at 12:49:34PM -0800, Junio C Hamano wrote:
> Of course, that will make it easier to let broken objects created by
> newer reimplementations of Git (and bugs in our code that cause us
> to create such broken objects) go unnoticed, so we would want to
> keep them at warn (not ignore) for the end-users.
Yes, sorry if that wasn't clear. By "loosen" I just meant to warn,
not ignore.
So a viable path forward is perhaps:
1. Add fetch.fsck.* (and probably transfer.fsck.*) to match the
receive-pack options.
2. Go over the current list of default warning/error settings and make
sure they are sensible.
3. Add a "light" mode to transfer.fsckObjects and friends that blocks
only errors, not warnings. Maybe setting the config bool to
"errors-only" instead of "true" or something.
4. (Optional) Default transfer.fsckObjects to "errors-only".
The escape hatch is to set fsckObjects to "false", or to downgrade
your specific problem to a warning via transfer.fsck.*.
-Peff
^ permalink raw reply
* Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`
From: Jeff King @ 2017-02-06 22:07 UTC (permalink / raw)
To: Eric Wong; +Cc: Johannes Schindelin, Josh Triplett, git
In-Reply-To: <20170206204820.GA7128@starla>
On Mon, Feb 06, 2017 at 08:48:20PM +0000, Eric Wong wrote:
> I haven't hit insurmountable performance problems, even on
> low-end hardware; especially since I started storing blob ids in
> Xapian itself, avoiding the expensive tree lookup via git.
The painful thing is traversing the object graph for clones and fetches.
Bitmaps help, but you still have to generate them.
> The main problem seems to be tree size. Deepening (2/2/36 vs
> 2/38) might be an option (I think Peff brought that up); but it
> might be easier to switch to YYYYMM refs (working like
> logrotate) and rely on Xapian to tie the entire thing together.
Yes, the hashing is definitely one issue. Some numbers here:
http://public-inbox.org/git/20160805092805.w3nwv2l6jkbuwlzf@sigill.intra.peff.net/
If you have C commits on a tree with T entries, you have to do C*T hash
lookups for a flat tree (for each commit, you have to see "yup, already
saw that object"). Sharding that across H entries at the top level drops
the tree cost from T to H + T/H (actually, it's a bit worse because we
have to read the secondary tree, too). Sharding again (at H') gets you
H + H' + T/H/H'.
Let's imagine you do one message per commit, so C=T. At 400K messages,
that's about 160 billion hash lookups flat. At H=256, it's about 700
million. If you shard again with H'=256, it's 200 million. After that,
the additive terms start to dominate, and it's not worth going any
further (and also, we're ignoring the extra-tree cost to each level).
At that point you're better off to start having fewer commits. I know
that the schema you use does put useful information into the commit
message, but it's also redundant with what's in the messages themselves.
And it sounds like you push most of that out to Xapian anyway.
Imagine your repo had one commit with 400K historical messages, and then
grouped the new messages so that on average we got about 10 messages per
commit (this doesn't seem unrealistic for something that commits every
few minutes; the messages tend to be bunched in time; I ran some
numbers against a 10-minute mark in the earlier message).
Then after another 100K messages, we'd have C=10,001 and T=500K. With
two levels of hashing at 256 each, that's ~5 million hash lookups to
walk the graph. And those numbers would be reasonable for a hosting site
like GitHub.
I don't know what C is for the kernel repo, but I suspect with the right
tuning it could be made into large-but-reasonable.
-Peff
^ permalink raw reply
* Re: Git clonebundles
From: Junio C Hamano @ 2017-02-06 22:16 UTC (permalink / raw)
To: Christian Couder; +Cc: Shawn Pearce, Stefan Saasen, Git Mailing List
In-Reply-To: <CAP8UFD2ffeHr0-z3xPFFODqRTTgVnrrWcYRbASpUOrp0QGnp6g@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> There is also Junio's work on Bundle v3 that was unfortunately
> recently discarded.
> Look for "jc/bundle" in:
>
> http://public-inbox.org/git/xmqq4m0cry60.fsf@gitster.mtv.corp.google.com/
>
> and previous "What's cooking in git.git" emails.
If people think it might be useful to have it around to experiment,
I can resurrect and keep that in 'pu' (or rather 'jch'), as long as
it does not overlap and conflict with other topics in flight. Let
me try that in today's integration cycle.
^ permalink raw reply
* [PATCH v4] tag: generate useful reflog message
From: cornelius.weig @ 2017-02-06 22:24 UTC (permalink / raw)
To: git
Cc: Cornelius Weig, karthik.188, peff, gitster,
bitte.keine.werbung.einwerfen
In-Reply-To: <xmqqpoiv15ew.fsf@gitster.mtv.corp.google.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Thanks for taking a look at my last version.
> On the other hand, it's not like failing to describe the tagged
> commit in the reflog is such a grave error. If we can get away with
> being vague on a tag that points at an object of unknown type like
> the above code does, we could loosen the "oops, we thought we got a
> commit, but it turns out that we cannot read it" case below from
> die() to just stuffing generic _("commit object") in the reflog.
Good point. I agree that failing to create the message should be no reason to
die().
As you also pointed out, "internal object" is no reliable description
for unhandled object types. I changed that as well.
Changes wrt v3 (interdiff below):
- change default message for unhandled object types
- do not die if commit is not readable, but use default description instead
- test: use verbatim HT character instead of \t
Cornelius Weig (1):
tag: generate useful reflog message
builtin/tag.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
t/t7004-tag.sh | 16 +++++++++++++++-
2 files changed, 68 insertions(+), 2 deletions(-)
Interdiff v3..v4:
diff --git a/builtin/tag.c b/builtin/tag.c
index 638b68e..9b2eabd 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -323,19 +323,19 @@ static void create_reflog_msg(const unsigned char *sha1, struct strbuf *sb)
type = sha1_object_info(sha1, NULL);
switch (type) {
default:
- strbuf_addstr(sb, _("internal object"));
+ strbuf_addstr(sb, _("object of unknown type"));
break;
case OBJ_COMMIT:
- c = lookup_commit_reference(sha1);
- buf = read_sha1_file(sha1, &type, &size);
- if (!c || !buf) {
- die(_("commit object %s could not be read"),
- sha1_to_hex(sha1));
+ if ((buf = read_sha1_file(sha1, &type, &size)) != NULL) {
+ subject_len = find_commit_subject(buf, &subject_start);
+ strbuf_insert(sb, sb->len, subject_start, subject_len);
+ } else {
+ strbuf_addstr(sb, _("commit object"));
}
- subject_len = find_commit_subject(buf, &subject_start);
- strbuf_insert(sb, sb->len, subject_start, subject_len);
- strbuf_addf(sb, ", %s", show_date(c->date, 0, DATE_MODE(SHORT)));
free(buf);
+
+ if ((c = lookup_commit_reference(sha1)) != NULL)
+ strbuf_addf(sb, ", %s", show_date(c->date, 0, DATE_MODE(SHORT)));
break;
case OBJ_TREE:
strbuf_addstr(sb, _("tree object"));
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 3c4cb58..894959f 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -86,7 +86,7 @@ test_expect_success 'creating a tag with --create-reflog should create reflog' '
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
git reflog exists refs/tags/tag_with_reflog &&
- sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&
+ sed -e "s/^.* //" .git/logs/refs/tags/tag_with_reflog > actual &&
test_cmp expected actual
'
@@ -96,7 +96,7 @@ test_expect_success 'annotated tag with --create-reflog has correct message' '
test_when_finished "git tag -d tag_with_reflog" &&
git tag -m "annotated tag" --create-reflog tag_with_reflog &&
git reflog exists refs/tags/tag_with_reflog &&
- sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&
+ sed -e "s/^.* //" .git/logs/refs/tags/tag_with_reflog > actual &&
test_cmp expected actual
'
--
2.10.2
^ permalink raw reply related
* [PATCH v4] tag: generate useful reflog message
From: cornelius.weig @ 2017-02-06 22:24 UTC (permalink / raw)
To: git
Cc: Cornelius Weig, karthik.188, peff, gitster,
bitte.keine.werbung.einwerfen
In-Reply-To: <xmqqpoiv15ew.fsf@gitster.mtv.corp.google.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: Junio C Hamano <gitster@pobox.com>
---
builtin/tag.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
t/t7004-tag.sh | 16 +++++++++++++++-
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index e40c4a9..bca890f 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -302,6 +302,54 @@ static void create_tag(const unsigned char *object, const char *tag,
}
}
+static void create_reflog_msg(const unsigned char *sha1, struct strbuf *sb)
+{
+ enum object_type type;
+ struct commit *c;
+ char *buf;
+ unsigned long size;
+ int subject_len = 0;
+ const char *subject_start;
+
+ char *rla = getenv("GIT_REFLOG_ACTION");
+ if (rla) {
+ strbuf_addstr(sb, rla);
+ } else {
+ strbuf_addstr(sb, _("tag: tagging "));
+ strbuf_add_unique_abbrev(sb, sha1, DEFAULT_ABBREV);
+ }
+
+ strbuf_addstr(sb, " (");
+ type = sha1_object_info(sha1, NULL);
+ switch (type) {
+ default:
+ strbuf_addstr(sb, _("object of unknown type"));
+ break;
+ case OBJ_COMMIT:
+ if ((buf = read_sha1_file(sha1, &type, &size)) != NULL) {
+ subject_len = find_commit_subject(buf, &subject_start);
+ strbuf_insert(sb, sb->len, subject_start, subject_len);
+ } else {
+ strbuf_addstr(sb, _("commit object"));
+ }
+ free(buf);
+
+ if ((c = lookup_commit_reference(sha1)) != NULL)
+ strbuf_addf(sb, ", %s", show_date(c->date, 0, DATE_MODE(SHORT)));
+ break;
+ case OBJ_TREE:
+ strbuf_addstr(sb, _("tree object"));
+ break;
+ case OBJ_BLOB:
+ strbuf_addstr(sb, _("blob object"));
+ break;
+ case OBJ_TAG:
+ strbuf_addstr(sb, _("other tag object"));
+ break;
+ }
+ strbuf_addch(sb, ')');
+}
+
struct msg_arg {
int given;
struct strbuf buf;
@@ -335,6 +383,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
struct strbuf ref = STRBUF_INIT;
+ struct strbuf reflog_msg = STRBUF_INIT;
unsigned char object[20], prev[20];
const char *object_ref, *tag;
struct create_tag_options opt;
@@ -494,6 +543,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else
die(_("Invalid cleanup mode %s"), cleanup_arg);
+ create_reflog_msg(object, &reflog_msg);
+
if (create_tag_object) {
if (force_sign_annotate && !annotate)
opt.sign = 1;
@@ -504,7 +555,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (!transaction ||
ref_transaction_update(transaction, ref.buf, object, prev,
create_reflog ? REF_FORCE_CREATE_REFLOG : 0,
- NULL, &err) ||
+ reflog_msg.buf, &err) ||
ref_transaction_commit(transaction, &err))
die("%s", err.buf);
ref_transaction_free(transaction);
@@ -514,5 +565,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
strbuf_release(&err);
strbuf_release(&buf);
strbuf_release(&ref);
+ strbuf_release(&reflog_msg);
return 0;
}
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 072e6c6..894959f 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -80,10 +80,24 @@ test_expect_success 'creating a tag using default HEAD should succeed' '
test_must_fail git reflog exists refs/tags/mytag
'
+git log -1 > expected \
+ --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
test_expect_success 'creating a tag with --create-reflog should create reflog' '
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
- git reflog exists refs/tags/tag_with_reflog
+ git reflog exists refs/tags/tag_with_reflog &&
+ sed -e "s/^.* //" .git/logs/refs/tags/tag_with_reflog > actual &&
+ test_cmp expected actual
+'
+
+git log -1 > expected \
+ --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
+test_expect_success 'annotated tag with --create-reflog has correct message' '
+ test_when_finished "git tag -d tag_with_reflog" &&
+ git tag -m "annotated tag" --create-reflog tag_with_reflog &&
+ git reflog exists refs/tags/tag_with_reflog &&
+ sed -e "s/^.* //" .git/logs/refs/tags/tag_with_reflog > actual &&
+ test_cmp expected actual
'
test_expect_success '--create-reflog does not create reflog on failure' '
--
2.10.2
^ permalink raw reply related
* What's cooking in git.git (Feb 2017, #02; Mon, 6)
From: Junio C Hamano @ 2017-02-06 22:34 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* cw/log-updates-for-all-refs-really (2017-02-01) 4 commits
(merged to 'next' on 2017-02-02 at 3e11673fcc)
+ doc: add note about ignoring '--no-create-reflog'
(merged to 'next' on 2017-01-31 at 53f71d2401)
+ update-ref: add test cases for bare repository
+ refs: add option core.logAllRefUpdates = always
+ config: add markup to core.logAllRefUpdates doc
The "core.logAllRefUpdates" that used to be boolean has been
enhanced to take 'always' as well, to record ref updates to refs
other than the ones that are expected to be updated (i.e. branches,
remote-tracking branches and notes).
* js/re-running-failed-tests (2017-01-27) 1 commit
(merged to 'next' on 2017-01-31 at 30c3a9e0cf)
+ t/Makefile: add a rule to re-run previously-failed tests
"make -C t failed" will now run only the tests that failed in the
previous run. This is usable only when prove is not use, and gives
a useless error message when run after "make clean", but otherwise
is serviceable.
* pl/complete-diff-submodule-diff (2017-01-30) 1 commit
(merged to 'next' on 2017-01-31 at 7e668d325c)
+ Completion: Add support for --submodule=diff
The command line completion (in contrib/) learned that
"git diff --submodule=" can take "diff" as a recently added option.
* rs/object-id (2017-01-30) 3 commits
(merged to 'next' on 2017-01-31 at c442e4780c)
+ checkout: convert post_checkout_hook() to struct object_id
+ use oidcpy() for copying hashes between instances of struct object_id
+ use oid_to_hex_r() for converting struct object_id hashes to hex strings
"uchar [40]" to "struct object_id" conversion continues.
* sb/submodule-recursive-absorb (2017-01-26) 3 commits
(merged to 'next' on 2017-01-31 at 0a24cfd06b)
+ submodule absorbing: fix worktree/gitdir pointers recursively for non-moves
+ cache.h: expose the dying procedure for reading gitlinks
+ setup: add gentle version of resolve_git_dir
When a submodule "A", which has another submodule "B" nested within
it, is "absorbed" into the top-level superproject, the inner
submodule "B" used to be left in a strange state. The logic to
adjust the .git pointers in these submodules has been corrected.
* sb/submodule-update-initial-runs-custom-script (2017-01-26) 1 commit
(merged to 'next' on 2017-01-31 at d794f894c6)
+ submodule update: run custom update script for initial populating as well
The user can specify a custom update method that is run when
"submodule update" updates an already checked out submodule. This
was ignored when checking the submodule out for the first time and
we instead always just checked out the commit that is bound to the
path in the superproject's index.
* sb/unpack-trees-super-prefix (2017-01-25) 4 commits
(merged to 'next' on 2017-01-31 at dabe6ca2b1)
+ unpack-trees: support super-prefix option
+ t1001: modernize style
+ t1000: modernize style
+ read-tree: use OPT_BOOL instead of OPT_SET_INT
"git read-tree" and its underlying unpack_trees() machinery learned
to report problematic paths prefixed with the --super-prefix option.
--------------------------------------------------
[New Topics]
* bw/push-submodule-only (2017-02-01) 2 commits
(merged to 'next' on 2017-02-06 at 851edafb14)
+ completion: add completion for --recurse-submodules=only
+ doc: add doc for git-push --recurse-submodules=only
Add missing documentation update to a recent topic.
Will merge to 'master'.
* cw/completion (2017-02-03) 7 commits
- completion: recognize more long-options
- completion: teach remote subcommands to complete options
- completion: teach replace to complete options
- completion: teach ls-remote to complete options
- completion: improve bash completion for git-add
- completion: add subcommand completion for rerere
- completion: teach submodule subcommands to complete options
More command line completion (in contrib/) for recent additions.
Needs review.
* cw/tag-reflog-message (2017-02-06) 1 commit
- tag: generate useful reflog message
"git tag", because refs/tags/* doesn't keep reflog by default, did
not leave useful message when adding a new entry to reflog.
Waiting for review to conclude.
An uneven error handling is somewhat disturbing.
* dl/document-that-difftool-takes-no-gui-option (2017-02-06) 1 commit
- Document the --no-gui option in difftool
A minor doc update.
Waiting for review to conclude.
A minor inconsistency is somewhat disturbing.
* ew/complete-svn-authorship-options (2017-02-06) 1 commit
(merged to 'next' on 2017-02-06 at dca324db7c)
+ completion: fix git svn authorship switches
Correct command line completion (in contrib/) on "git svn"
Will merge to 'master'.
* jk/reset-to-break-a-commit-doc (2017-02-03) 1 commit
(merged to 'next' on 2017-02-06 at 7f571e62e9)
+ reset: add an example of how to split a commit into two
A minor doc update.
Will merge to 'master'.
* js/difftool-builtin (2017-02-06) 1 commit
(merged to 'next' on 2017-02-06 at 6a90549f38)
+ difftool: fix bug when printing usage
A hot-fix to C-rewrite of "git difftool".
Will merge to 'master'.
* ps/worktree-prune-help-fix (2017-02-06) 1 commit
(merged to 'next' on 2017-02-06 at eeb96f1677)
+ worktree: fix option descriptions for `prune`
Incorrect usage help message for "git worktree prune" has been fixed.
Will merge to 'master'.
* rs/p5302-create-repositories-before-tests (2017-02-06) 1 commit
(merged to 'next' on 2017-02-06 at f93bd2ed47)
+ p5302: create repositories for index-pack results explicitly
Adjust a perf test to new world order where commands that do
require a repository are really strict about having a repository.
Will merge to 'master'.
* sg/completion (2017-02-03) 21 commits
- completion: cache the path to the repository
- completion: extract repository discovery from __gitdir()
- completion: don't guard git executions with __gitdir()
- completion: consolidate silencing errors from git commands
- completion: don't use __gitdir() for git commands
- completion: respect 'git -C <path>'
- rev-parse: add '--absolute-git-dir' option
- completion: fix completion after 'git -C <path>'
- completion: don't offer commands when 'git --opt' needs an argument
- completion: list short refs from a remote given as a URL
- completion: don't list 'HEAD' when trying refs completion outside of a repo
- completion: list refs from remote when remote's name matches a directory
- completion: respect 'git --git-dir=<path>' when listing remote refs
- completion: fix most spots not respecting 'git --git-dir=<path>'
- completion: ensure that the repository path given on the command line exists
- completion tests: add tests for the __git_refs() helper function
- completion tests: check __gitdir()'s output in the error cases
- completion tests: consolidate getting path of current working directory
- completion tests: make the $cur variable local to the test helper functions
- completion tests: don't add test cruft to the test repository
- completion: improve __git_refs()'s in-code documentation
(this branch is used by sg/completion-refs-speedup.)
Clean-up and updates to command line completion (in contrib/).
Will merge to 'next'.
* sg/completion-refs-speedup (2017-02-06) 13 commits
- squash! completion: fill COMPREPLY directly when completing refs
- completion: fill COMPREPLY directly when completing refs
- completion: list only matching symbolic and pseudorefs when completing refs
- completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
- completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery
- completion: let 'for-each-ref' strip the remote name from remote branches
- completion: let 'for-each-ref' and 'ls-remote' filter matching refs
- completion: don't disambiguate short refs
- completion: don't disambiguate tags and branches
- completion: support excluding full refs
- completion: support completing full refs after '--option=refs/<TAB>'
- completion: wrap __git_refs() for better option parsing
- completion: remove redundant __gitcomp_nl() options from _git_commit()
(this branch uses sg/completion.)
Will hold.
This seems to break 9902 when merged to 'pu'.
* sk/parse-remote-cleanup (2017-02-06) 1 commit
(merged to 'next' on 2017-02-06 at 6ec89f72d5)
+ parse-remote: remove reference to unused op_prep
Code clean-up.
Will merge to 'master'.
--------------------------------------------------
[Stalled]
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Expecting a reroll.
cf. <CAFZEwPPXPPHi8KiEGS9ggzNHDCGhuqMgH9Z8-Pf9GLshg8+LPA@mail.gmail.com>
cf. <CAFZEwPM9RSTGN54dzaw9gO9iZmsYjJ_d1SjUD4EzSDDbmh-XuA@mail.gmail.com>
* ls/filter-process-delayed (2017-01-08) 1 commit
. convert: add "status=delayed" to filter process protocol
Ejected, as does not build when merged to 'pu'.
* ls/p4-path-encoding (2016-12-18) 1 commit
- git-p4: fix git-p4.pathEncoding for removed files
When "git p4" imports changelist that removes paths, it failed to
convert pathnames when the p4 used encoding different from the one
used on the Git side. This has been corrected.
Will be rerolled.
cf. <7E1C7387-4F37-423F-803D-3B5690B49D40@gmail.com>
* sh/grep-tree-obj-tweak-output (2017-01-20) 2 commits
- grep: use '/' delimiter for paths
- grep: only add delimiter if there isn't one already
"git grep", when fed a tree-ish as an input, shows each hit
prefixed with "<tree-ish>:<path>:<lineno>:". As <tree-ish> is
almost always either a commit or a tag that points at a commit, the
early part of the output "<tree-ish>:<path>" can be used as the
name of the blob and given to "git show". When <tree-ish> is a
tree given in the extended SHA-1 syntax (e.g. "<commit>:", or
"<commit>:<dir>"), however, this results in a string that does not
name a blob (e.g. "<commit>::<path>" or "<commit>:<dir>:<path>").
"git grep" has been taught to be a bit more intelligent about these
cases and omit a colon (in the former case) or use slash (in the
latter case) to produce "<commit>:<path>" and
"<commit>:<dir>/<path>" that can be used as the name of a blob.
Waiting for the review discussion to settle, followed by a reroll.
* mh/ref-remove-empty-directory (2017-01-07) 23 commits
- files_transaction_commit(): clean up empty directories
- try_remove_empty_parents(): teach to remove parents of reflogs, too
- try_remove_empty_parents(): don't trash argument contents
- try_remove_empty_parents(): rename parameter "name" -> "refname"
- delete_ref_loose(): inline function
- delete_ref_loose(): derive loose reference path from lock
- log_ref_write_1(): inline function
- log_ref_setup(): manage the name of the reflog file internally
- log_ref_write_1(): don't depend on logfile argument
- log_ref_setup(): pass the open file descriptor back to the caller
- log_ref_setup(): improve robustness against races
- log_ref_setup(): separate code for create vs non-create
- log_ref_write(): inline function
- rename_tmp_log(): improve error reporting
- rename_tmp_log(): use raceproof_create_file()
- lock_ref_sha1_basic(): use raceproof_create_file()
- lock_ref_sha1_basic(): inline constant
- raceproof_create_file(): new function
- safe_create_leading_directories(): set errno on SCLD_EXISTS
- safe_create_leading_directories_const(): preserve errno
- t5505: use "for-each-ref" to test for the non-existence of references
- refname_is_safe(): correct docstring
- files_rename_ref(): tidy up whitespace
Deletion of a branch "foo/bar" could remove .git/refs/heads/foo
once there no longer is any other branch whose name begins with
"foo/", but we didn't do so so far. Now we do.
Expecting a reroll.
cf. <5051c78e-51f9-becd-e1a6-9c0b781d6912@alum.mit.edu>
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* jk/delta-chain-limit (2017-01-27) 2 commits
(merged to 'next' on 2017-02-06 at 9ff36ae9b2)
+ pack-objects: convert recursion to iteration in break_delta_chain()
+ pack-objects: enforce --depth limit in reused deltas
"git repack --depth=<n>" for a long time busted the specified depth
when reusing delta from existing packs. This has been corrected.
Will cook in 'next'.
* mm/merge-rename-delete-message (2017-01-30) 1 commit
- merge-recursive: make "CONFLICT (rename/delete)" message show both paths
When "git merge" detects a path that is renamed in one history
while the other history deleted (or modified) it, it now reports
both paths to help the user understand what is going on in the two
histories being merged.
Will merge to and then cook in 'next'.
* rs/swap (2017-01-30) 5 commits
- graph: use SWAP macro
- diff: use SWAP macro
- use SWAP macro
- apply: use SWAP macro
- add SWAP macro
Code clean-up.
Will merge to 'next'.
... unless there is an objection with better alternative. The
discussion seems to have quieted down.
* ps/urlmatch-wildcard (2017-02-01) 5 commits
- urlmatch: allow globbing for the URL host part
- urlmatch: include host in urlmatch ranking
- urlmatch: split host and port fields in `struct url_info`
- urlmatch: enable normalization of URLs with globs
- mailmap: add Patrick Steinhardt's work address
The <url> part in "http.<url>.<variable>" configuration variable
can now be spelled with '*' that serves as wildcard.
E.g. "http.https://*.example.com.proxy" can be used to specify the
proxy used for https://a.example.com, https://b.example.com, etc.,
i.e. any host in the example.com domain.
Will merge to and then cook in 'next'.
* sf/putty-w-args (2017-02-01) 5 commits
- SQUASH???
- connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config
- git_connect(): factor out SSH variant handling
- connect: rename tortoiseplink and putty variables
- connect: handle putty/plink also in GIT_SSH_COMMAND
The command line options for ssh invocation needs to be tweaked for
some implementations of SSH (e.g. PuTTY plink wants "-P <port>"
while OpenSSH wants "-p <port>" to specify port to connect to), and
the variant was guessed when GIT_SSH environment variable is used
to specify it. Extend the guess to the command specified by the
newer GIT_SSH_COMMAND and also core.sshcommand configuration
variable, and give an escape hatch for users to deal with
misdetected cases.
Stalled?
cf. <alpine.DEB.2.20.1702012319460.3496@virtualbox>
* jk/describe-omit-some-refs (2017-01-23) 5 commits
(merged to 'next' on 2017-01-23 at f8a14b4996)
+ describe: teach describe negative pattern matches
+ describe: teach --match to accept multiple patterns
+ name-rev: add support to exclude refs by pattern match
+ name-rev: extend --refs to accept multiple patterns
+ doc: add documentation for OPT_STRING_LIST
"git describe" and "git name-rev" have been taught to take more
than one refname patterns to restrict the set of refs to base their
naming output on, and also learned to take negative patterns to
name refs not to be used for naming via their "--exclude" option.
Will cook in 'next'.
* sb/submodule-doc (2017-01-12) 3 commits
- submodules: add a background story
- submodule update documentation: don't repeat ourselves
- submodule documentation: add options to the subcommand
Needs review.
* bw/attr (2017-02-01) 27 commits
- attr: reformat git_attr_set_direction() function
- attr: push the bare repo check into read_attr()
- attr: store attribute stack in attr_check structure
- attr: tighten const correctness with git_attr and match_attr
- attr: remove maybe-real, maybe-macro from git_attr
- attr: eliminate global check_all_attr array
- attr: use hashmap for attribute dictionary
- attr: change validity check for attribute names to use positive logic
- attr: pass struct attr_check to collect_some_attrs
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct attr_check"
- attr: (re)introduce git_check_attr() and struct attr_check
- attr: rename function and struct related to checking attributes
- attr.c: outline the future plans by heavily commenting
- Documentation: fix a typo
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The gitattributes machinery is being taught to work better in a
multi-threaded environment.
Will merge to and then cook in 'next'.
* vn/xdiff-func-context (2017-01-15) 1 commit
- xdiff -W: relax end-of-file function detection
"git diff -W" has been taught to handle the case where a new
function is added at the end of the file better.
Will hold.
An follow-up change to go back from the line that matches the
funcline to show comments before the function definition is still
being discussed.
* nd/worktree-move (2017-01-27) 7 commits
- fixup! worktree move: new command
- worktree remove: new command
- worktree move: refuse to move worktrees with submodules
- worktree move: accept destination as directory
- worktree move: new command
- worktree.c: add update_worktree_location()
- worktree.c: add validate_worktree()
"git worktree" learned move and remove subcommands.
Needs review.
* cc/split-index-config (2016-12-26) 21 commits
- Documentation/git-update-index: explain splitIndex.*
- Documentation/config: add splitIndex.sharedIndexExpire
- read-cache: use freshen_shared_index() in read_index_from()
- read-cache: refactor read_index_from()
- t1700: test shared index file expiration
- read-cache: unlink old sharedindex files
- config: add git_config_get_expiry() from gc.c
- read-cache: touch shared index files when used
- sha1_file: make check_and_freshen_file() non static
- Documentation/config: add splitIndex.maxPercentChange
- t1700: add tests for splitIndex.maxPercentChange
- read-cache: regenerate shared index if necessary
- config: add git_config_get_max_percent_split_change()
- Documentation/git-update-index: talk about core.splitIndex config var
- Documentation/config: add information for core.splitIndex
- t1700: add tests for core.splitIndex
- update-index: warn in case of split-index incoherency
- read-cache: add and then use tweak_split_index()
- split-index: add {add,remove}_split_index() functions
- config: add git_config_get_split_index()
- config: mark an error message up for translation
The experimental "split index" feature has gained a few
configuration variables to make it easier to use.
Waiting for review comments to be addressed.
cf. <20161226102222.17150-1-chriscool@tuxfamily.org>
cf. <a1a44640-ff6c-2294-72ac-46322eff8505@ramsayjones.plus.com>
* kn/ref-filter-branch-list (2017-01-31) 20 commits
(merged to 'next' on 2017-01-31 at e7592a5461)
+ branch: implement '--format' option
+ branch: use ref-filter printing APIs
+ branch, tag: use porcelain output
+ ref-filter: allow porcelain to translate messages in the output
+ ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
+ ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
+ ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
+ ref-filter: rename the 'strip' option to 'lstrip'
+ ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
+ ref-filter: introduce refname_atom_parser()
+ ref-filter: introduce refname_atom_parser_internal()
+ ref-filter: make "%(symref)" atom work with the ':short' modifier
+ ref-filter: add support for %(upstream:track,nobracket)
+ ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
+ ref-filter: introduce format_ref_array_item()
+ ref-filter: move get_head_description() from branch.c
+ ref-filter: modify "%(objectname:short)" to take length
+ ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
+ ref-filter: include reference to 'used_atom' within 'atom_value'
+ ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Will cook in 'next'.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-12-05 at 0c77e39cd5)
+ setup_git_env: avoid blind fall-back to ".git"
Originally merged to 'next' on 2016-10-26
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
Will cook in 'next'.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-12-05 at 041946dae0)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Originally merged to 'next' on 2016-10-11
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
Will cook in 'next'.
* jc/bundle (2016-03-03) 6 commits
. index-pack: --clone-bundle option
. Merge branch 'jc/index-pack' into jc/bundle
. bundle v3: the beginning
. bundle: keep a copy of bundle file name in the in-core bundle header
. bundle: plug resource leak
. bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
--------------------------------------------------
[Discarded]
* jk/nofollow-attr-ignore (2016-11-02) 5 commits
. exclude: do not respect symlinks for in-tree .gitignore
. attr: do not respect symlinks for in-tree .gitattributes
. exclude: convert "check_index" into a flags field
. attr: convert "macro_ok" into a flags field
. add open_nofollow() helper
As we do not follow symbolic links when reading control files like
.gitignore and .gitattributes from the index, match the behaviour
and not follow symbolic links when reading them from the working
tree. This also tightens security a bit by not leaking contents of
an unrelated file in the error messages when it is pointed at by
one of these files that is a symbolic link.
Perhaps we want to cover .gitmodules too with the same mechanism?
* sb/push-make-submodule-check-the-default (2017-01-26) 2 commits
(merged to 'next' on 2017-01-26 at 5f4715cea6)
+ Revert "push: change submodule default to check when submodules exist"
(merged to 'next' on 2016-12-12 at 1863e05af5)
+ push: change submodule default to check when submodules exist
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Retracted.
^ permalink raw reply
* Re: [PATCH] Completion: Add support for --submodule=diff
From: Peter Law @ 2017-02-06 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq4m0gtakk.fsf@gitster.mtv.corp.google.com>
Hi,
Junio C Hamano <gitster@pobox.com> wrote:
> Peter Law <peterjclaw@gmail.com> writes:
>
>>> Teach git-completion.bash about the 'diff' option to 'git diff
>>> --submodule=', which was added in Git 2.11.
>>
>> I posted this patch back in December, but I've not heard anything. I'm
>> sure as maintainers you're all quite busy, but I was wondering how
>> long it usually takes to get a response to patches? (also whether I'd
>> gotten some part of the submission process wrong?)
>
> When there is clear "subsystem maintainer(s)" in the area, I try to
> refrain from commenting until they speak up, and completion scripts
> are one of these areas. I usually ping them after a few days but in
> December with holidays and things people are usually slow, and so
> was I X-<.
>
> Will pick it up. Thanks for a reminder; you absolutely did the
> right thing (i.e. sending it out with people who are likely to know
> about the area CC'ed, waiting for a while and then sending a
> reminder).
Awesome, many thanks!
Peter
^ permalink raw reply
* Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"
From: Junio C Hamano @ 2017-02-06 23:09 UTC (permalink / raw)
To: Siddharth Kannan; +Cc: git, pranit.bauva, Matthieu.Moy, peff, pclouds, sandals
In-Reply-To: <20170206181026.GA4010@ubuntu-512mb-blr1-01.localdomain>
Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
> Hey Junio, I did some more digging into the codepath:
> ...
> In case you would prefer for me to not work on this anymore
> because I am new to the codebase, I will leave it at this.
The above is nicely analized and summarized.
The earlier mention of "those new to the codebase" by me was "this
is an inappropriate topic as a GSoC microproject for people new to
the codebase" and it wasn't meant to say "this part of the code is
too precious to let unknown folks touch it."
The focus of GSoC being mentoring those who are new to the open
source development, and hopefully retain them in the community after
GSoC is over, we do expect microprojects to be suitable for those
who are new to the codebase.
The focus of microprojects are twofold. It is a way for new people
to learn the way in which they will be interacting with the
community once they become Git developers, sending their patches
(which includes analyzing and explaining the problem they are trying
to solve and their solution to it) and receiving and responding to
review comments. We also want to find out which candidates are
willing to learn and which ones are difficult to work with during
the process. And its primary focus is not about solving the real
issues the project has with its code---something "bite-sized" is
sufficient (and desirable) for microprojects for both GSoC student
candidates and GSoC mentors and reviewers to work with.
> (c) -> Else look for "r1^-"
> ...
> Case (c) is a bit confusing. This could be something like "-^-", and
> something like "^-" could mean "Not commits on previous branch" or it
> could mean "All commits on this branch except for the parent of HEAD"
Do you mean:
"git rev-parse ^-" does not mean "git rev-parse HEAD^-", but we
probably would want to, and if that is what is going to happen,
"^-" should mean "HEAD^-", and cannot be used for "^@{-1}"?
It's friend "^!" does not mean "HEAD^!", and "^@" does not mean
"HEAD^@", either (the latter is somewhat borked, though, and "^@"
translates to "^HEAD" because confusingly "@" stands for "HEAD"
sometimes).
So my gut feeling is that it is probably OK to make "^-" mean
"^@{-1}"; it may be prudent to at least initially keep "^-" an error
like it currently is already, though.
^ permalink raw reply
* Request re git status
From: Ron Pero @ 2017-02-06 23:35 UTC (permalink / raw)
To: git
Hi
I almost got bit by git: I knew there were changes on the remote
server, but git status said I was uptodate with the remote.
This page explains it well.
http://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream
That page also contains a good suggestion:
Why ... not design it to [optionally] DO a fetch and THEN declare
whether it is up to date? Or change the message to tell what it really
did, e.g. "Your branch was up-to-date with 'origin/master' when last
checked at {timestamp}"? Or even just say, "Do a fetch to find out
whether your branch is up to date"?
Thanks, and best wishes,
Ron
^ permalink raw reply
* Re: [PATCH 00/12] completion: speed up refs completion
From: Jacob Keller @ 2017-02-06 23:55 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Git mailing list
In-Reply-To: <CAM0VKjm-HQFtDypcWgOdQrLyjAicOVLUsFby5_wE1hvTE1pTRQ@mail.gmail.com>
On Mon, Feb 6, 2017 at 11:36 AM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
> On Mon, Feb 6, 2017 at 7:31 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> On Fri, Feb 3, 2017 at 7:15 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>> I haven't had a chance to further investigate, but I tried this series
>>> out (from your github) and it appears that this series (or the
>>> previous series for __gitdir work) breaks "git log" ref completion.
>>> I'll have further details when I am able to investigate a it more.
>>>
>>> Thanks,
>>> Jake
>>
>> At first I had the same problem, but I verified by re-installing the
>> completion script and the problem appears to have gone away. I suspect
>> what happened is that the original time, I forgot to actually install
>> the new version of git, and only installed the completion script, so
>> when some of the commands were run with new options they (silently)
>> failed and the result was missing completion values.
>>
>> Once I properly re-installed everything it appears to work as
>> expected. I haven't found any other issues yet.
>
> Thanks, that's good to hear.
>
> Still, I'm a bit puzzled as to what exactly might have caused your
> problem. Considering new options:
>
> - the __gitdir()-related series added the 'git rev-parse
> --absolute-git-dir' option, but only ever used it if you invoked
> completion after 'git -C some/where'.
>
> - The refs completion speedup didn't add any new options but started
> to use two that it previously didn't:
>
> - 'git for-each-ref --sort=<key>' option, but that's with us since
> the earliest ever 'for-each-ref' version from more than a decade
> ago...
>
> - 'git for-each-ref' format modifier 'strip=2', which was
> introduced in v2.7.1~15^2 (tag: do not show ambiguous tag names
> as "tags/foo", 2016-01-25), only about a year ago. Were you
> using a pre-2.7.1 version when seeing the problems?
>
> Gábor
Nope. I was using some version of next at some point recently (less
than a couple months old). I do not know exactly what caused it, and
I'm not really able to find out because I can't reproduce it any more.
(after a fresh make install).
Thanks,
Jake
^ permalink raw reply
* Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`
From: Eric Wong @ 2017-02-07 0:14 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Josh Triplett, git
In-Reply-To: <20170206220754.5q2oddr5ej7c6qcg@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Mon, Feb 06, 2017 at 08:48:20PM +0000, Eric Wong wrote:
>
> > I haven't hit insurmountable performance problems, even on
> > low-end hardware; especially since I started storing blob ids in
> > Xapian itself, avoiding the expensive tree lookup via git.
>
> The painful thing is traversing the object graph for clones and fetches.
> Bitmaps help, but you still have to generate them.
Yep. "public-inbox-init" defaults to enabling bitmaps in the
config for this reason.
> > The main problem seems to be tree size. Deepening (2/2/36 vs
> > 2/38) might be an option (I think Peff brought that up); but it
> > might be easier to switch to YYYYMM refs (working like
> > logrotate) and rely on Xapian to tie the entire thing together.
>
> Yes, the hashing is definitely one issue. Some numbers here:
>
> http://public-inbox.org/git/20160805092805.w3nwv2l6jkbuwlzf@sigill.intra.peff.net/
>
> If you have C commits on a tree with T entries, you have to do C*T hash
> lookups for a flat tree (for each commit, you have to see "yup, already
> saw that object"). Sharding that across H entries at the top level drops
> the tree cost from T to H + T/H (actually, it's a bit worse because we
> have to read the secondary tree, too). Sharding again (at H') gets you
> H + H' + T/H/H'.
>
> Let's imagine you do one message per commit, so C=T. At 400K messages,
> that's about 160 billion hash lookups flat. At H=256, it's about 700
> million. If you shard again with H'=256, it's 200 million. After that,
> the additive terms start to dominate, and it's not worth going any
> further (and also, we're ignoring the extra-tree cost to each level).
Just to make sure I'm following, here; the entire formulas are:
C * H + H' + (T / H / H') # 2/2/36
C * H + (T / H) # 2/38 (current)
Right?
> At that point you're better off to start having fewer commits. I know
> that the schema you use does put useful information into the commit
> message, but it's also redundant with what's in the messages themselves.
> And it sounds like you push most of that out to Xapian anyway.
Yeah, there's no benefit to Xapian users for having any info in
the commit. However, keeping commit-per-message is still
important to me to for better robustness from hardware and
network failures.
But yes, historical stuff could be squashed into a single commit
(much like how linux.git started with v2.6.12-rc2 without
history). Perhaps some folks will care about NNTP article
numbering being non-chronological...
> Imagine your repo had one commit with 400K historical messages, and then
> grouped the new messages so that on average we got about 10 messages per
> commit (this doesn't seem unrealistic for something that commits every
> few minutes; the messages tend to be bunched in time; I ran some
> numbers against a 10-minute mark in the earlier message).
>
> Then after another 100K messages, we'd have C=10,001 and T=500K. With
> two levels of hashing at 256 each, that's ~5 million hash lookups to
> walk the graph. And those numbers would be reasonable for a hosting site
> like GitHub.
>
> I don't know what C is for the kernel repo, but I suspect with the right
> tuning it could be made into large-but-reasonable.
LKML probably has an upper bound of 30K messages per month;
so it could hit 100K in less than 4 months. Worst case might
be 360K messages a year
360000 * (256 + 256 + ((360000 + old) / 256 / 256))
That's still at least 180 million hash lookups after a year or
so of real-time updates; right? (But probably closer to 240
million if there's 10 million old messages in there.
Instead, I think I will add an option to support logrotate-style
monthly heads (YYYYMM); keeping 2/38 and C == T:
30000 * (256 + (30000 / 256)) => 11 million
30000 * (256 + 256 + (30000 / 256 / 256)) => 15 million
The monthly heads would each be discontiguous history-wise;
so Xapian would become a requirement for users of this option
for Message-ID lookups, but histories would still be readable
with "git log"
One good side-effect of using monthly heads is --single-branch
clones may be used if someone lacks the bandwidth or space to do
a full mirror. I'm not sure if the server-side (pack reuse,
bitmaps) will benefit other aside from bandwidth reductions,
though.
A (far-fetched) option I've considered would be to store entire
messages in the commit and have no trees or blobs at all. But
that would require a significant rework, and would also make
Xapian a hard requirement for even checking if a message is
deleted or not.
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)
From: SZEDER Gábor @ 2017-02-07 0:24 UTC (permalink / raw)
To: Junio C Hamano, Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <xmqqzihzymn3.fsf@gitster.mtv.corp.google.com>
> * sg/completion-refs-speedup (2017-02-06) 13 commits
> - squash! completion: fill COMPREPLY directly when completing refs
> - completion: fill COMPREPLY directly when completing refs
> - completion: list only matching symbolic and pseudorefs when completing refs
> - completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
> - completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery
> - completion: let 'for-each-ref' strip the remote name from remote branches
> - completion: let 'for-each-ref' and 'ls-remote' filter matching refs
> - completion: don't disambiguate short refs
> - completion: don't disambiguate tags and branches
> - completion: support excluding full refs
> - completion: support completing full refs after '--option=refs/<TAB>'
> - completion: wrap __git_refs() for better option parsing
> - completion: remove redundant __gitcomp_nl() options from _git_commit()
> (this branch uses sg/completion.)
>
> Will hold.
> This seems to break 9902 when merged to 'pu'.
All failing tests fail with the same error:
fatal: unrecognized %(refname:strip=2) argument: strip=2
That's because of this topic:
> * kn/ref-filter-branch-list (2017-01-31) 20 commits
> (merged to 'next' on 2017-01-31 at e7592a5461)
> + branch: implement '--format' option
> + branch: use ref-filter printing APIs
> + branch, tag: use porcelain output
> + ref-filter: allow porcelain to translate messages in the output
> + ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
> + ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
> + ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
> + ref-filter: rename the 'strip' option to 'lstrip'
And in particular this commit, which, well, does what it's subject
says it's doing, thus breaking backwards compatibility.
> + ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
> + ref-filter: introduce refname_atom_parser()
> + ref-filter: introduce refname_atom_parser_internal()
> + ref-filter: make "%(symref)" atom work with the ':short' modifier
> + ref-filter: add support for %(upstream:track,nobracket)
> + ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
> + ref-filter: introduce format_ref_array_item()
> + ref-filter: move get_head_description() from branch.c
> + ref-filter: modify "%(objectname:short)" to take length
> + ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
> + ref-filter: include reference to 'used_atom' within 'atom_value'
> + ref-filter: implement %(if), %(then), and %(else) atoms
>
> The code to list branches in "git branch" has been consolidated
> with the more generic ref-filter API.
>
> Will cook in 'next'.
^ permalink raw reply
* Re: git-daemon shallow checkout fail
From: Bob Proulx @ 2017-02-07 0:27 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.20.1701301719590.3469@virtualbox>
Hello Johannes,
Thank you very much for the good hints here. They are very helpful.
Johannes Schindelin wrote:
> Assuming that you can rebuild your Git with debug symbols and without
> optimization (simply remove the -O2 from CFLAGS in the Makefile, I never
> had any luck with single-stepping in gdb when compiled with -O2), you
I always debug with -g and without -O because otherwise it leads to a
lot of confusion. But git-daemon is a forking daemon which makes
debugging it with the debugger somewhere more default and requiring
more setup to debug past the fork points. As you note and hint with
later setting up an attach point for gdb.
> - that error message comes from shallow.c's setup_temporary_shallow()
> function
Yes. I find that too.
> - that function is only called from fetch-pack and receive-pack, neither
> of which should be called by upload-pack, so it is a puzzle
The choice of directionality for upload and download might be
confusing me here too. Since from the client side of things it is a
download. But on the server side it is an upload.
> - adding a test case to t5570-git-daemon.sh that tests specifically your
> described scenario seems *not* to fail:
I have seen some of the patches that seems like should have fixed this
problem. It is perplexing. But see my next mail on this too.
> - I even modified t/lib-git-daemon.sh to start the daemon as `nobody` and
> kill it as `root`, and I won't share that patch because it is as
> ugly, but *even then* the test succeeded.
It succeeds for me on other systems. It is only the one (where I need
it) that it is failing.
> So my suspicion is that the repository you try to serve may already be
> shallow, or something else funky is going on that has not been included in
> your report.
It happens to any repository. I picked a small repository and copied
it verbatim using rsync to my working environment. The identical bits
of a repository copied by rsync work okay on one system but fail on
the other.
> The most direct way to get to the bottom of this may be to do something
> like this:
...
> if (write_shallow_commits(&sb, 0, extra)) {
> +error("About to create shallow_XXXXXX: pid = %d", getpid());
> +while (!debug_me) {
> + sleep(1);
> +}
> fd = xmks_tempfile(&temporary_shallow, git_path("shallow_XXXXXX"));
>
> if (write_in_full(fd, sb.buf, sb.len) != sb.len)
> -- snap --
>
> Then let it run, wait for the error message "About to create
> shallow_XXXXXX" and then attach with a gdb started as nobody via `attach
> <pid>` to see the stack trace.
>
> That should give you an idea where that code path is hit (unexpectedly).
That is a good hint. I will give that a try. However see my next
email for more (confusing) information.
Bob
^ permalink raw reply
* Re: git-daemon shallow checkout fail
From: Bob Proulx @ 2017-02-07 0:27 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <CACsJy8DED9WRr_T6g43bxHUGQYVnfaTx15hqSGiiajvi0TxtuA@mail.gmail.com>
Duy Nguyen wrote:
> Jeff King wrote:
> > It depends on the git version on the server. The interesting code is in
> > upload-pack.c, which is spawned by git-daemon to serve a fetch or clone
> > request.
> >
> > See commit b790e0f67 (upload-pack: send shallow info over stdin to
> > pack-objects, 2014-03-11), which lays out the history. Since that commit
> > (in git v2.0.0), there should be no tmpfile needed.
>
> It must be it. There's nowhere else that upload-pack can create
> shallow_XXXXXX. (receive-pack and fetch-pack can).
I am sure the file creation is there. Because it isn't being done
anywhere. But the problem is before that time period. By then the
paths are already set.
> >Bob Proulx wrote:
> >> git --version # from today's git clone build
> >> git version 2.11.0.485.g4e59582
> >
> > This shouldn't be happening with git v2.11. Are you sure that the "git
> > daemon" invocation is running that same version? I notice you set up a
> > restricted PATH. Is it possible that /usr/local/bin or /usr/bin has an
> > older version of git?
I have been starting it with PATH set to my directory. But given this
question I start it with a full path.
PATH=~/src/git-stuff/git:$PATH ~/src/git-stuff/git/git-daemon --export-all --base-path=/srv/git --verbose
But then I worry about the package installed binary still getting
invoked with the fork somehow. Therefore I disable it. There should
be no possibility of it invoking the packaged daemon. I moved it out
of the way.
mv /usr/lib/git-core/git-daemon /usr/lib/git-core/git-daemon.disabled
I can't trivially remove the packaged version because other things
depend upon it. I could get more agressive about disabling it in a
non-destructive and reversible way though.
> One easy way to verify is clone or fetch again with GIT_TRACE_PACKET=1
> since we send the server's version as a capability since 1.8.0
And here is the interesting part. If I read this right the client is
reporting 1.9.1 from the server! But how?
$ GIT_TRACE_PACKET=1 git clone --depth 1 git://git0.savannah.gnu.org/test-project.git
Cloning into 'test-project'...
17:20:40.482970 pkt-line.c:46 packet: clone> git-upload-pack /test-project.git\0host=git0.savannah.gnu.org\0
17:20:40.590177 pkt-line.c:46 packet: clone< 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/1.9.1
17:20:40.662623 pkt-line.c:46 packet: clone< 34e7202270c381f4e5734180dc19426ce69f2e1e refs/heads/master
17:20:40.662653 pkt-line.c:46 packet: clone< 0000
17:20:40.663682 pkt-line.c:46 packet: clone> want 34e7202270c381f4e5734180dc19426ce69f2e1e multi_ack_detailed side-band-64k thin-pack include-tag ofs-delta agent=git/2.1.4
17:20:40.663701 pkt-line.c:46 packet: clone> want 34e7202270c381f4e5734180dc19426ce69f2e1e
17:20:40.663713 pkt-line.c:46 packet: clone> deepen 1
17:20:40.663724 pkt-line.c:46 packet: clone> 0000
17:20:40.739502 pkt-line.c:46 packet: clone< shallow 34e7202270c381f4e5734180dc19426ce69f2e1e
17:20:40.854338 pkt-line.c:46 packet: clone< 0000
17:20:40.854360 pkt-line.c:46 packet: clone> done
17:20:40.929349 pkt-line.c:46 packet: clone< NAK
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
I am assuming that the "agent=git/1.9.1" is the evidence that it isn't
running the code that I am trying to make it run? Of course the
packaged installed git version is 1.9.1 (from Trisquel 7, an Ubuntu
14.04 fork) so that matches. My client is "agent=git/2.1.4" (from
Debian Jessie) so that matches my client end.
Therefore it looks like it is invoking some other command by a hard
coded path and avoiding PATH to my development bits. It must be
invoking some other binary. I will get more agressive about disabling
the packaged version and hopefully find out which one.
Thank you very much for the good hints here. They are very helpful.
Bob
^ permalink raw reply
* Re: Request re git status
From: Phil Hord @ 2017-02-07 0:45 UTC (permalink / raw)
To: Ron Pero, Git
In-Reply-To: <CANOj2JG5VuDtS30PfOrZ=4q8pTv_frY7=p+0g=UW3yV6ev+1KQ@mail.gmail.com>
On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@magnadev.com> wrote:
> I almost got bit by git: I knew there were changes on the remote
> server, but git status said I was uptodate with the remote.
>
Do you mean you almost pushed some changed history with "--force"
which would have lost others' changes? Use of this option is
discouraged on shared branches for this very reason. But if you do
use it, the remote will tell you the hash of the old branch so you can
undo the damage.
But if you did not use --force, then you were not in danger of being
bit. Git would have prevented the push in that case.
> Why ... not design it to [optionally] DO a fetch and THEN declare
> whether it is up to date?
It's because `git status` does not talk to the remote server, by
design. The only Git commands that do talk to the remote are push,
pull and fetch. All the rest work off-line and they do so
consistently.
Imagine `git status` did what you requested; that is, it first did a
fetch and then reported the status. Suppose someone pushed a commit
to the remote immediately after your fetch completed. Now git will
still report "up to date" but it will be wrong as soon as the remote
finishes adding the new push. Yet the "up to date" message will
remain on your console, lying to you. If you leave and come back in
two days, the message will remain there even if it is no longer
correct.
So you should accept that `git status` tells you the status with
respect to your most recent fetch, and that you are responsible for
the timing of the most recent fetch. To have git try to do otherwise
would be misleading.
> Or change the message to tell what it really
> did, e.g. "Your branch was up-to-date with 'origin/master' when last
> checked at {timestamp}"? Or even just say, "Do a fetch to find out
> whether your branch is up to date"?
These are reasonable suggestions, but i don't think the extra wording
adds anything for most users. Adding a timestamp seems generally
useful, but it could get us into other trouble since we have to depend
on outside sources for timestamps. :-\
^ permalink raw reply
* idea: light-weight pull requests
From: Paul Wise @ 2017-02-07 0:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
Hi all,
I had an idea that might be interesting to git folks:
light-weight pull requests:
Anonymous and ssh/http-identified users should be able to push just
using git, within the refs/pull/ namespace, to any non-existent branch
name or to a branch they created when previously identified, without
forking off a new repository.
Advantages:
Removes the need to look up who to send the pull request notification
to since configuring that is up to the project itself.
Removes the annoying scenario of having lots of remotes that have been
removed after the corresponding pull request was closed.
Moves popular git hosting services from primarily a model of forests of
forks to one of contributions to well maintained ongoing projects.
Allows users to use their preferred git clients to issue pull requests
instead of using web interfaces of popular git hosting services.
Creates a new standard for contributing to repositories on all git
repository hosting services.
Contributions from people without an account on those services are
possible.
Contributions from people without any git repository hosting of their
own are possible.
Contributions from people who don't use or dislike MUAs are possible.
Disadvantages:
Pull request spam, could be mitigated with configuration options.
Extra configuration and complexity on the server side. This is once
only and means less complexity on the pull requester side.
Will not work with typical setups where the git/http/ssh user does not
have write access to the repositories. A workaround could be some sort
of hybrid-repository setup with the new refs and objects in a second
repository which would be shared by all pull requesters.
--
bye,
pabs
http://bonedaddy.net/pabs3/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: git-daemon shallow checkout fail
From: Bob Proulx @ 2017-02-07 0:56 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20170206171225215133282@bob.proulx.com>
Bob Proulx wrote:
> 17:20:40.590177 pkt-line.c:46 packet: clone< 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/1.9.1
The evidence of it running the wrong version being the 1.9.1 which is
not the bits I built.
> Therefore it looks like it is invoking some other command by a hard
> coded path and avoiding PATH to my development bits. It must be
> invoking some other binary. I will get more agressive about disabling
> the packaged version and hopefully find out which one.
I did and of course it is /usr/bin/git-upload-pack and if I disable
that binary then git-daemon no longer operates.
error: cannot run upload-pack: No such file or directory
But shouldn't it find git-upload-pack from PATH? Since I have
git-upload-pack installed in PATH? Apparently not. At least not when
invoking as /path/to/git-daemon directly.
In any case with the all of your very good help, especially the
version echo print, guiding me to the problem that I was able to make
this work.
cd /run/git && env -i HOME=/run/git PATH=$HOME/src/git-stuff/git:/usr/bin:/bin $HOME/src/git-stuff/git/git --exec-path=$HOME/src/git-stuff/git daemon --export-all --base-path=/srv/git --verbose
That works for the git-daemon. It does not require me to modify
anything else on the system. Good enough. Problem solved.
Thanks!
Bob
^ permalink raw reply
* Re: idea: light-weight pull requests
From: Santiago Torres @ 2017-02-07 0:57 UTC (permalink / raw)
To: Paul Wise; +Cc: git
In-Reply-To: <1486427537.16949.42.camel@bonedaddy.net>
[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]
Hello, pabs.
IMHO, the notion of a PR/MR is more specific to Git repository
management tools (e.g., GitHub, GitLab). They all have specific
concepts/ways to manage the way how their hosted repositories behave ---
and I believe this flexibility is one of the beauties in Git . I could
see how this could be implemented by tools like this rather easily
(e.g., using symlinks + inotify or something less hacky).
I'm wondering if standardizing this would be more interesting to those
communities?
I would like to see what becomes of this.
Cheers!
-Santiago.
On Tue, Feb 07, 2017 at 08:32:17AM +0800, Paul Wise wrote:
> Hi all,
>
> I had an idea that might be interesting to git folks:
>
> light-weight pull requests:
>
> Anonymous and ssh/http-identified users should be able to push just
> using git, within the refs/pull/ namespace, to any non-existent branch
> name or to a branch they created when previously identified, without
> forking off a new repository.
>
> Advantages:
>
> Removes the need to look up who to send the pull request notification
> to since configuring that is up to the project itself.
>
> Removes the annoying scenario of having lots of remotes that have been
> removed after the corresponding pull request was closed.
>
> Moves popular git hosting services from primarily a model of forests of
> forks to one of contributions to well maintained ongoing projects.
>
> Allows users to use their preferred git clients to issue pull requests
> instead of using web interfaces of popular git hosting services.
>
> Creates a new standard for contributing to repositories on all git
> repository hosting services.
>
> Contributions from people without an account on those services are
> possible.
>
> Contributions from people without any git repository hosting of their
> own are possible.
>
> Contributions from people who don't use or dislike MUAs are possible.
>
> Disadvantages:
>
> Pull request spam, could be mitigated with configuration options.
>
> Extra configuration and complexity on the server side. This is once
> only and means less complexity on the pull requester side.
>
> Will not work with typical setups where the git/http/ssh user does not
> have write access to the repositories. A workaround could be some sort
> of hybrid-repository setup with the new refs and objects in a second
> repository which would be shared by all pull requesters.
>
> --
> bye,
> pabs
>
> http://bonedaddy.net/pabs3/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)
From: Jacob Keller @ 2017-02-07 1:17 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Karthik Nayak, Git mailing list
In-Reply-To: <CAM0VKjmhO9NQLz9TDv5M3OhxSBt-JdjaouVT0pTA-a6mGaF4_A@mail.gmail.com>
On Mon, Feb 6, 2017 at 4:24 PM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
>> * sg/completion-refs-speedup (2017-02-06) 13 commits
>> - squash! completion: fill COMPREPLY directly when completing refs
>> - completion: fill COMPREPLY directly when completing refs
>> - completion: list only matching symbolic and pseudorefs when completing refs
>> - completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
>> - completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery
>> - completion: let 'for-each-ref' strip the remote name from remote branches
>> - completion: let 'for-each-ref' and 'ls-remote' filter matching refs
>> - completion: don't disambiguate short refs
>> - completion: don't disambiguate tags and branches
>> - completion: support excluding full refs
>> - completion: support completing full refs after '--option=refs/<TAB>'
>> - completion: wrap __git_refs() for better option parsing
>> - completion: remove redundant __gitcomp_nl() options from _git_commit()
>> (this branch uses sg/completion.)
>>
>> Will hold.
>> This seems to break 9902 when merged to 'pu'.
>
> All failing tests fail with the same error:
>
> fatal: unrecognized %(refname:strip=2) argument: strip=2
>
> That's because of this topic:
>
>> * kn/ref-filter-branch-list (2017-01-31) 20 commits
>> (merged to 'next' on 2017-01-31 at e7592a5461)
>> + branch: implement '--format' option
>> + branch: use ref-filter printing APIs
>> + branch, tag: use porcelain output
>> + ref-filter: allow porcelain to translate messages in the output
>> + ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
>> + ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
>> + ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
>> + ref-filter: rename the 'strip' option to 'lstrip'
>
> And in particular this commit, which, well, does what it's subject
> says it's doing, thus breaking backwards compatibility.
>
What about making strip a deprecated variant of lstrip?
Thanks,
Jake
^ 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