* [PATCH] docs: brush up obsolete bits of git-fsck manpage
From: Jeff King @ 2011-12-16 11:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
After the description and options, the fsck manpage contains
some discussion about what it does. Over time, this
discussion has become somewhat obsolete, both in content and
formatting. In particular:
1. There are many options now, so starting the discussion
with "It tests..." makes it unclear whether we are
talking about the last option, or about the tool in
general. Let's start a new "discussion" section and
make our antecedent more clear.
2. It gave an example for --unreachable using for-each-ref
to mention all of the heads, saying that it will do "a
_lot_ of verification". This is hopelessly out-of-date,
as giving no arguments will check much more (reflogs,
the index, non-head refs).
3. It goes on to mention tests "to be added" (like tree
object sorting). We now have these tests.
Signed-off-by: Jeff King <peff@peff.net>
---
I posted this here:
http://thread.gmane.org/gmane.comp.version-control.git/181673/focus=181701
and I think it simply got lost in the discussion.
We ended up discussing the possibility of deprecating refs on the
command-line to fsck. I still think that's reasonable, but in the
meantime, this patch is a reasonable improvement.
Documentation/git-fsck.txt | 26 ++++++++------------------
1 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 0a17b42..6c47395 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -81,30 +81,20 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
progress status even if the standard error stream is not
directed to a terminal.
-It tests SHA1 and general object sanity, and it does full tracking of
-the resulting reachability and everything else. It prints out any
-corruption it finds (missing or bad objects), and if you use the
-'--unreachable' flag it will also print out objects that exist but
-that aren't reachable from any of the specified head nodes.
-
-So for example
-
- git fsck --unreachable HEAD \
- $(git for-each-ref --format="%(objectname)" refs/heads)
+DISCUSSION
+----------
-will do quite a _lot_ of verification on the tree. There are a few
-extra validity tests to be added (make sure that tree objects are
-sorted properly etc), but on the whole if 'git fsck' is happy, you
-do have a valid tree.
+git-fsck tests SHA1 and general object sanity, and it does full tracking
+of the resulting reachability and everything else. It prints out any
+corruption it finds (missing or bad objects), and if you use the
+'--unreachable' flag it will also print out objects that exist but that
+aren't reachable from any of the specified head nodes (or the default
+set, as mentioned above).
Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
-Of course, "valid tree" doesn't mean that it wasn't generated by some
-evil person, and the end result might be crap. git is a revision
-tracking system, not a quality assurance system ;)
-
Extracted Diagnostics
---------------------
--
1.7.7.4.13.g57bf4
^ permalink raw reply related
* [PATCH] pretty: give placeholders to reflog identity
From: Jeff King @ 2011-12-16 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When doing a reflog walk, you can get some information about
the reflog (such as the subject line), but not the identity
information (i.e., name and email).
Let's make those available, mimicing the options for author
and committer identity.
Signed-off-by: Jeff King <peff@peff.net>
---
Initial posting and discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/185043
Response was positive, but we were in 1.7.8 release freeze, so you asked
me to hold and re-post.
Documentation/pretty-formats.txt | 4 ++++
pretty.c | 25 +++++++++++++++++++++++++
reflog-walk.c | 12 ++++++++++++
reflog-walk.h | 1 +
t/t6006-rev-list-format.sh | 6 ++++++
5 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 561cc9f..880b6f2 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -132,6 +132,10 @@ The placeholders are:
- '%N': commit notes
- '%gD': reflog selector, e.g., `refs/stash@\{1\}`
- '%gd': shortened reflog selector, e.g., `stash@\{1\}`
+- '%gn': reflog identity name
+- '%gN': reflog identity name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
+- '%ge': reflog identity email
+- '%gE': reflog identity email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
- '%gs': reflog subject
- '%Cred': switch color to red
- '%Cgreen': switch color to green
diff --git a/pretty.c b/pretty.c
index 230fe1c..1580299 100644
--- a/pretty.c
+++ b/pretty.c
@@ -822,6 +822,23 @@ static void rewrap_message_tail(struct strbuf *sb,
c->indent2 = new_indent2;
}
+static int format_reflog_person(struct strbuf *sb,
+ char part,
+ struct reflog_walk_info *log,
+ enum date_mode dmode)
+{
+ const char *ident;
+
+ if (!log)
+ return 2;
+
+ ident = get_reflog_ident(log);
+ if (!ident)
+ return 2;
+
+ return format_person_part(sb, part, ident, strlen(ident), dmode);
+}
+
static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -963,6 +980,14 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
if (c->pretty_ctx->reflog_info)
get_reflog_message(sb, c->pretty_ctx->reflog_info);
return 2;
+ case 'n':
+ case 'N':
+ case 'e':
+ case 'E':
+ return format_reflog_person(sb,
+ placeholder[1],
+ c->pretty_ctx->reflog_info,
+ c->pretty_ctx->date_mode);
}
return 0; /* unknown %g placeholder */
case 'N':
diff --git a/reflog-walk.c b/reflog-walk.c
index da71a85..c7095b7 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -294,6 +294,18 @@ void get_reflog_message(struct strbuf *sb,
strbuf_add(sb, info->message, len);
}
+const char *get_reflog_ident(struct reflog_walk_info *reflog_info)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return NULL;
+
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ return info->email;
+}
+
void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
diff --git a/reflog-walk.h b/reflog-walk.h
index 7bd2cd4..afb1ae3 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -14,6 +14,7 @@ extern void show_reflog_message(struct reflog_walk_info *info, int,
enum date_mode);
extern void get_reflog_message(struct strbuf *sb,
struct reflog_walk_info *reflog_info);
+extern const char *get_reflog_ident(struct reflog_walk_info *reflog_info);
extern void get_reflog_selector(struct strbuf *sb,
struct reflog_walk_info *reflog_info,
enum date_mode dmode,
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index d918cc0..4442790 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -267,6 +267,12 @@ test_expect_success '%gd shortens ref name' '
test_cmp expect.gd-short actual.gd-short
'
+test_expect_success 'reflog identity' '
+ echo "C O Mitter:committer@example.com" >expect &&
+ git log -g -1 --format="%gn:%ge" >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'oneline with empty message' '
git commit -m "dummy" --allow-empty &&
git commit -m "dummy" --allow-empty &&
--
1.7.7.4.13.g57bf4
^ permalink raw reply related
* Re: How to commit incomplete changes?
From: Hallvard Breien Furuseth @ 2011-12-16 12:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7v8vmdl62s.fsf@alter.siamese.dyndns.org>
[Neal Kreitzinger]
> I assume by 'generated changes' you mean the automerge in git...
No. And to your questions of why I want this with unpublished work:
No. Like I wrote, I'm talking about published commits.
[Junio C Hamano]
> My reading of the "need to split" example was not "bulk of work plus fixes
> to mistakes". Imagine you are working on somebody else's code and for some
> reason you want to do
>
> s/setenv/xsetenv/g
>
> all over the code, and also add a wrapper to implement xsetenv() function.
Yes - except there is no "mistakes" since it's deliberate. I'd do
s/setenv/xsetenv/g, which does too little (misses some preprocessor
stuff) or is too greedy, then commit anyway and clean up in next commit.
I could make and commit a much more complicated script to do it all, but
that's unhelpful when trying to read what the heck the change is doing.
And who knows what it'd do when run on a somewhat different codebase.
That example matches a future internal API change. My current issue
is changes generated with 'autoreconf' - after cleaning up an utter
libtool/automake mess by hand, which will break things if I don't
autoreconf in the same commmit.
> You _could_ do it in one single commit, but what happens when you try to
> adjust to the updated upstream code, which may have added new callsites to
> setenv()?
Indeed. In this case, it'd be when cherry-picking from the devel branch
to the release branch. These still differ too much, a legacy of our old
CVS workflow.
> If you keep it as two patches, one is mechanical (i.e. s/setenv/xsetenv/g)
> and the other is manual (i.e. implementation of xsetenv()), then you can
> discard the text of the "mechanical" one from the old series and instead
> run the substitution on the updated code, and then cherry-pick the
> "manual" one.
Yes. I'd order it in a sequence which never broke anything if I could.
Well, come to think of it: Possibly I could introduce some new code
which would only exist for the sake of patching over the temporary
breakage, and then delete that code again 2-3 commits later. In this
case, I'd among other things create an obsolete libtool.m4 which is
currently hiding inside aclocal.m4. Not sure if that makes more sense
than just having a few broken commits.
--
Hallvard
^ permalink raw reply
* Re: How to commit incomplete changes?
From: Hallvard Breien Furuseth @ 2011-12-16 12:58 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Junio C Hamano, git
In-Reply-To: <hbf.20111216xubv@bombur.uio.no>
I wrote:
>[Neal Kreitzinger]
>> I assume by 'generated changes' you mean the automerge in git...
>
> No. And to your questions of why I want this with unpublished work:
> No. Like I wrote, I'm talking about published commits.
Wait, I see - as-yet unpublished commits, yes. Which seem best to me to
publish that way. And which will get cherry-picked later, after commit
and testing.
--
Hallvard
^ permalink raw reply
* Any tips for improving the performance of cloning large repositories?
From: Alex Bennee @ 2011-12-16 13:02 UTC (permalink / raw)
To: git
Hi,
We've migrated our old CVS repository into GIT without too many
issues. However now we are rolling out the usage of the new repository
we are hitting some performance bottlenecks, especially on the initial
clone (something our buildbot instance does a lot).
Our repo is large, my .git is around 2.5G although the central repo
has a 1.7Gb single pack file. However some machines handle the cloning
better than others. For one thing the clone process seems to involve
the receiving side needing a large glob of memory which causes
problems when there is memory pressure.
I've tried tweaking the pack size from unlimited to 256m but this
seems to have increased the clone time as the receiving end attempts
to re-pack everything back into an uber-pack.
Another thing that I've noticed is very high systime on the receiving
machines as ethernet and disk I/O is heavily hit.
So what I'm looking for are some tips on how I can tweak
configurations to make the clone process a little less I/O and memory
heavy. Any suggestions?
One thing I did try was a rsync'ed local repo in /var/cache/repos
which the clone command used for reference with something like:
git clone --local --reference /var/cache/repo.git git://repo/repo.git
But that didn't help as it seems to copy the whole thing anyway.
--
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
^ permalink raw reply
* Re: Any tips for improving the performance of cloning large repositories?
From: Hallvard Breien Furuseth @ 2011-12-16 13:11 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <CAJ-05NPP7aCcr_SYxLYk8U1entDMv0aF2Me3cTGmOLjYqFKUOA@mail.gmail.com>
Alex Bennee writes:
> We've migrated our old CVS repository into GIT without too many
> issues. However now we are rolling out the usage of the new repository
> we are hitting some performance bottlenecks, especially on the initial
> clone (something our buildbot instance does a lot).
Do you often need to clone from a remote? Instead of cloning from a
local (git clone --mirror) which gets auto-updated from the remote.
Could the buildbot make do with a shallow repo, clone --depth <num>?
--
Hallvard
^ permalink raw reply
* Re: Any tips for improving the performance of cloning large repositories?
From: Hallvard Breien Furuseth @ 2011-12-16 13:39 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <hbf.20111216yufz@bombur.uio.no>
I wrote:
> Do you often need to clone from a remote? Instead of cloning from a
> local (git clone --mirror) which gets auto-updated from the remote.
Er, obviously not, since you tried that with rsync. Create the mirror
with 'git clone --mirror', then update it with 'git fetch' rather than
rsync.
--
Hallvard
^ permalink raw reply
* Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Johannes Sixt @ 2011-12-16 14:00 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Brandon Casey
In-Reply-To: <20111216110000.GA15676@sigill.intra.peff.net>
Am 12/16/2011 12:00, schrieb Jeff King:
> static const char *builtin_attr[] = {
...
> + "*.c diff=cpp",
> + "*.cc diff=cpp",
> + "*.cxx diff=cpp",
> + "*.cpp diff=cpp",
> + "*.h diff=cpp",
> + "*.hpp diff=cpp",
Please don't do this. It would be a serious regression for C++ coders, and
some C coders as well. The built-in hunk header patterns are severly
broken and don't work well with C++ code. I know for sure that the
following are not recognized:
- template declarations, e.g. template<class T> func(T x);
- constructor definitionss, e.g. MyClass::MyClass()
- functions that return references, e.g. const string& func()
- function definitions along the GNU coding style, e.g.
void
the_func ()
I am currently using this pattern (but I'm sure it can be optimized) with
an appropriate xcpp attribute:
[diff "xcpp"]
xfuncname = "!^[
\\t]*[a-zA-Z_][a-zA-Z_0-9]*[^()]*:[[:space:]]*$\n^[a-zA-Z_][a-zA-Z_0-9]*.*"
(modulo MUA line wrapping).
-- Hannes
^ permalink raw reply
* Re: Any tips for improving the performance of cloning large repositories?
From: Seth Robertson @ 2011-12-16 14:14 UTC (permalink / raw)
To: Hallvard Breien Furuseth; +Cc: Alex Bennee, git
In-Reply-To: <hbf.20111216zcin@bombur.uio.no>
In message <hbf.20111216zcin@bombur.uio.no>, Hallvard Breien Furuseth writes:
I wrote:
> Do you often need to clone from a remote? Instead of cloning from a
> local (git clone --mirror) which gets auto-updated from the remote.
Er, obviously not, since you tried that with rsync. Create the mirror
with 'git clone --mirror', then update it with 'git fetch' rather than
rsync.
If you really need to perform a full clone from the buildbot with or
without a different working directory (for instance if you have
buildbots/checkout users running in parallel where multiple users need
a consistent HEAD for multiple sequential operations) then instead
consider cloning with --reference or --shared. There are severe
restrictions on what you should do with aggressive sharing (man
git-clone), but if all you are doing is normal checkouts, tags,
commits, etc, then it would be just fine. Of course remember to add a
remote for the real upstream if you are planning on pushing
changes/tags back.
-Seth Robertson
^ permalink raw reply
* Re: [PATCH] Gitweb: Avoid warnings when a repo does not have a valid HEAD
From: Jakub Narebski @ 2011-12-16 14:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Ratterman, git
In-Reply-To: <7vty51lbb0.fsf@alter.siamese.dyndns.org>
On Thu, 15 Dec 2011, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> Joe Ratterman <jratt0@gmail.com> writes:
>>
>>> It is possible that the HEAD reference does not point to an existing
>>> branch. When viewing such a repository in gitweb, a message like this
>>> one was sent to the error log:
>>>
>>> gitweb.cgi: Use of uninitialized value in string eq at /usr/src/git/gitweb/gitweb.cgi line 5115.
>>>
>> ..., but in that case a repository with
>> a HEAD that points at an unborn branch _and_ have other refs that do point
>> at existing commit is already screwed-up, so if we want to be extremely
>> pedantic then perhaps ...
>>
>> my $curr = ((defined $head && exists $ref{"id"} && defined $ref{"id"})
my $curr = ((defined $head && defined $ref{"id"})
is enough, because '!exists $hash{key}' implies '!defined $hash{key}'
(though reverse is not true).
>> ? ($ref{"id"} eq $head)
>> : 0);
>
> Just in case, I was not suggesting to update the patch to look like the
> above by "if we want to be extremely pedantic".
>
> After all, that error message in the log may be a good thing that notifies
> the site administrators about a suspicious repository so that it can be
> fixed (even though it was not a designed "feature" but something that
> happens to work).
Well, but for that those error messages should describe error; the above
is quite hard to translate to
warning: HEAD points to an unborn branch in repository foo.git
BTW. we should probably warn about this situation more clear, perhaps
by showing warning instead of empty place where subject of current commit
is usually shown.
Anyway git marks up branches (sic!) that _point to_ the same commit as
HEAD because we calculate it anyway, at least for 'summary' view.
Better solution would be to examine HEAD (either using Perl, or using
"git symbolic-ref") to get _name_ of current branch. I'd rather avoid
yet another command call.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Any tips for improving the performance of cloning large repositories?
From: Alex Bennee @ 2011-12-16 15:28 UTC (permalink / raw)
To: Seth Robertson; +Cc: Hallvard Breien Furuseth, git
In-Reply-To: <201112161414.pBGEExLJ006769@no.baka.org>
On 16 December 2011 14:14, Seth Robertson <in-gitvger@baka.org> wrote:
>
> In message <hbf.20111216zcin@bombur.uio.no>, Hallvard Breien Furuseth writes:
>
> I wrote:
> > Do you often need to clone from a remote? Instead of cloning from a
> > local (git clone --mirror) which gets auto-updated from the remote.
>
> Er, obviously not, since you tried that with rsync. Create the mirror
> with 'git clone --mirror', then update it with 'git fetch' rather than
> rsync.
>
> If you really need to perform a full clone from the buildbot with or
> without a different working directory (for instance if you have
> buildbots/checkout users running in parallel where multiple users need
> a consistent HEAD for multiple sequential operations) then instead
> consider cloning with --reference or --shared.
Well that's counter intuitive....
- reverting the original repo to one big pack speeds up the clone
- adding a --local --reference mirror slows it down
Timings:
14:41 ajb@vsbldhost/i686 [ajb] >time git clone git://engbot/repo.git
test-clone-bigpack.git
Initialized empty Git repository in /scratch/ajb/test-clone-bigpack.git/.git/
remote: Counting objects: 371220, done.
remote: Compressing objects: 100% (88900/88900), done.
remote: Total 371220 (delta 274586), reused 371220 (delta 274586)
Receiving objects: 100% (371220/371220), 1.78 GiB | 20.10 MiB/s, done.
Resolving deltas: 100% (274586/274586), done.
Checking out files: 100% (42909/42909), done.
real 8m53.008s
user 2m53.151s
sys 7m16.339s
14:53 ajb@vsbldhost/i686 [ajb] >time git clone --local --reference
/var/cache/repos/repo.git git://engbot/repo.git te
st-clone-local.git
Initialized empty Git repository in /scratch/ajb/test-clone-local.git/.git/
Checking out files: 100% (42909/42909), done.
real 14m6.333s
user 1m6.844s
sys 12m44.676s
Two things are odd. The first is the clone "hung" at around 22%
checking out the files for ~ 10 minutes before finishing the remaining
70% in a few seconds. Secondly is seems in both cases the systime is
quite high.
--
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
^ permalink raw reply
* Re: git-p4.skipSubmitEdit
From: Michael Horowitz @ 2011-12-16 15:38 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Luke Diamand, L. A. Linden Levy, git
In-Reply-To: <20111020011610.GA7292@arf.padd.com>
All,
It appears that this change has introduced a bug that causes submit to
fail every time if you do not skip the submit edit.
From what I can tell, this is because the new edit_template method
does not return True at the end.
Thanks,
Mike
On Wed, Oct 19, 2011 at 9:16 PM, Pete Wyckoff <pw@padd.com> wrote:
> luke@diamand.org wrote on Tue, 18 Oct 2011 18:53 +0100:
>> Looks good, one minor nit (see below) and a comment.
> [..]
>> >+ # invoke the editor
>> >+ if os.environ.has_key("P4EDITOR"):
>> >+ editor = os.environ.get("P4EDITOR")
>> >+ else:
>> >+ editor = read_pipe("git var GIT_EDITOR").strip()
>> >+ system(editor + " " + template_file)
>>
>> This is where we should really check the return code. However, doing
>> so seems to break lots of the existing tests so it's not as easy as
>> it looks.
>
> Indeed. I'll not fix that now, but agree it should be.
>
>> >+
>> >+ # If the file was not saved, prompt to see if this patch should
>> >+ # be skipped. But skip this verification step if configured so.
>> >+ if gitConfig("git-p4.skipSubmitEditCheck") == "true":
>> >+ print "return true for skipSubmitEditCheck"
>>
>> You print a helpful/annoying(?) message here, but not further up at
>> skipSubmitEdit?
>
> Aargh. Leaked debug code. Thanks for noticing. I got rid of
> it.
>
> -- Pete
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* git-p4 using notes
From: Michael Horowitz @ 2011-12-16 16:07 UTC (permalink / raw)
To: git
For those of you using git-p4 because of a company requirement to use
Perforce, but really wish you could use git only, the most frustrating
part is the fact that when changes are submitted, the commit message
is rewritten to include a reference to the P4 change number which is
used by the sync. When syncing back changes, this causes the commit
hash to be different, and so blows away your old commit and any parent
commit references and such.
I read someplace, I can't remember where at this point, that if git-p4
used notes to write the P4 change information, that would not impact
the commit hash, so when merging back, things would not be
overwritten, and you can maintain branches and commit history properly
in git.
I just ran into this project, where it seems that someone has
re-written git-p4 to use notes: https://github.com/ermshiperete/git-p4
I was wondering if any of the maintainers of git-p4 has considered
this, and might want to leverage this work to merge into the main git
repo, possibly with an option to choose between the two behaviors.
Thanks,
Mike
^ permalink raw reply
* Re: How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-16 16:22 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Git Mailing List
In-Reply-To: <874nx1korf.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> I am using git from master branch and wanted to try the signed pull
> request. I have pushed the signed tag to repo.or.cz, but not sure how to
> generate pull request with signed tag information ? git-pull-request
> insist on a branch on the server and put the branch details in the
> pull-request text, It do add tag description but not the tag name and
> still put "repo-name branch" name in the txt. Shouldn't that be
> "repo-name tag-name" so that one can cut-paste that in pull request ?
Yeah, you are right.
^ permalink raw reply
* Re* How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-16 16:56 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <874nx1korf.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> I am using git from master branch and wanted to try the signed pull
> request. I have pushed the signed tag to repo.or.cz, but not sure how to
> generate pull request with signed tag information?
The correct script should grok the following command line:
$ git request-pull v1.7.7.4 git://git.kernel.org/pub/scm/git/git.git v1.7.7.5
and include
are available in the git repository at
git://git.kernel.org/.../git.git tag v1.7.7.5
for you to fetch changes up to 66c1...
but we didn't loosen the code that inspects the publishing repository to
allow asking for a tag that points at an older part of the history to be
pulled.
Here is an update.
-- >8 --
Subject: request-pull: update the "pull" command generation logic
The old code that insisted on asking for the tip of a branch to be pulled
were not updated when we started allowing for a tag to be pulled. When a
tag points at an older part of the history and there is no branch that
points at the tagged commit, the script failed to say which ref is to be
pulled.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 46 +++++++++++++++++++++++++++++++++++++---------
1 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index c6a5b7a..7b5c777 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -57,12 +57,40 @@ headrev=$(git rev-parse --verify "$head"^0) || exit
merge_base=$(git merge-base $baserev $headrev) ||
die "fatal: No commits in common between $base and $head"
-find_matching_branch="/^$headrev "'refs\/heads\//{
- s/^.* refs\/heads\///
- p
- q
-}'
-branch=$(git ls-remote "$url" | sed -n -e "$find_matching_branch")
+# $head is the token given from the command line. If a ref with that
+# name exists at the remote and their values match, we should use it.
+# Otherwise find a ref that matches $headrev.
+find_matching_ref='
+ sub abbr {
+ my $ref = shift;
+ if ($ref =~ s|refs/heads/||) {
+ return $ref;
+ } elsif ($ref =~ s|refs/tags/||) {
+ return "tag $ref";
+ } else {
+ return $ref;
+ }
+ }
+
+ my ($exact, $found);
+ while (<STDIN>) {
+ my ($sha1, $ref, $deref) = /^(\S+)\s+(\S+?)(\^\{\})?$/;
+ next unless ($sha1 eq $ARGV[1]);
+ $found = abbr($ref);
+ if ($ref =~ m|/\Q$ARGV[0]\E$|) {
+ $exact = $found;
+ last;
+ }
+ }
+ if ($exact) {
+ print "$exact\n";
+ } elsif ($found) {
+ print "$found\n";
+ }
+'
+
+ref=$(git ls-remote "$url" | perl -e "$find_matching_ref" "$head" "$headrev")
+
url=$(git ls-remote --get-url "$url")
git show -s --format='The following changes since commit %H:
@@ -71,7 +99,7 @@ git show -s --format='The following changes since commit %H:
are available in the git repository at:
' $baserev &&
-echo " $url${branch+ $branch}" &&
+echo " $url${ref+ $ref}" &&
git show -s --format='
for you to fetch changes up to %H:
@@ -81,7 +109,7 @@ for you to fetch changes up to %H:
if test -n "$branch_name"
then
- echo "(from the branch description for $branch local branch)"
+ echo "(from the branch description for $branch_name local branch)"
echo
git config "branch.$branch_name.description"
fi &&
@@ -101,7 +129,7 @@ fi &&
git shortlog ^$baserev $headrev &&
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
-if test -z "$branch"
+if test -z "$ref"
then
echo "warn: No branch of $url is at:" >&2
git show -s --format='warn: %h: %s' $headrev >&2
^ permalink raw reply related
* Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Junio C Hamano @ 2011-12-16 17:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, git, Brandon Casey
In-Reply-To: <4EEB4F13.2010402@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 12/16/2011 12:00, schrieb Jeff King:
>> static const char *builtin_attr[] = {
> ...
>> + "*.c diff=cpp",
>> + "*.cc diff=cpp",
>> + "*.cxx diff=cpp",
>> + "*.cpp diff=cpp",
>> + "*.h diff=cpp",
>> + "*.hpp diff=cpp",
>
> Please don't do this. It would be a serious regression for C++ coders, and
> some C coders as well. The built-in hunk header patterns are severly
> broken and don't work well with C++ code.
I do not often do C++, but I tend to agree wrt C.
^ permalink raw reply
* Re: Any tips for improving the performance of cloning large repositories?
From: Junio C Hamano @ 2011-12-16 17:08 UTC (permalink / raw)
To: Alex Bennee; +Cc: Seth Robertson, Hallvard Breien Furuseth, git
In-Reply-To: <CAJ-05NPbRmyx=a+U7BK4rNShBgaXj+g-Bwc1aBDDb3N0VPBW=A@mail.gmail.com>
Alex Bennee <kernel-hacker@bennee.com> writes:
> Well that's counter intuitive....
>
> - reverting the original repo to one big pack speeds up the clone
> - adding a --local --reference mirror slows it down
Neither is. Read what "--local" says in the help text of clone. It
disables the git aware clever optimization.
^ permalink raw reply
* Re: [PATCH v3 2/3] grep: enable threading with -p and -W using lazy attribute lookup
From: Junio C Hamano @ 2011-12-16 17:34 UTC (permalink / raw)
To: Johannes Sixt
Cc: Thomas Rast, git, Junio C Hamano, René Scharfe, Jeff King,
Eric Herman
In-Reply-To: <4EEAFFAF.8030003@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> This is the first time we use pthread_mutex_t in a header file. We need at
> least the following squashed in. An alternative would be to include
> "thread-utils.h", but thread-utils is really more about implementation
> helpers functions, not about types,...
builtin/grep.c already uses thread-utils.h since 5b594f4 (Threaded grep,
2010-01-25), so does builtin/pack-objects.c since 833e3df (pack-objects:
Add runtime detection of online CPU's, 2008-02-22), so it may be simpler
to do so in grep.h instead.
diff --git a/builtin/grep.c b/builtin/grep.c
index bc23c3c..6474eed 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -17,7 +17,6 @@
#include "grep.h"
#include "quote.h"
#include "dir.h"
-#include "thread-utils.h"
static char const * const grep_usage[] = {
"git grep [options] [-e] <pattern> [<rev>...] [[--] <path>...]",
diff --git a/grep.h b/grep.h
index 15d227c..dd4c65e 100644
--- a/grep.h
+++ b/grep.h
@@ -133,8 +133,11 @@ extern struct grep_opt *grep_opt_dup(const struct grep_opt *opt);
extern int grep_threads_ok(const struct grep_opt *opt);
#ifndef NO_PTHREADS
-/* Mutex used around access to the attributes machinery if
- * opt->use_threads. Must be initialized/destroyed by callers! */
+#include "thread-utils.h"
+/*
+ * Mutex used around access to the attributes machinery if
+ * opt->use_threads. Must be initialized/destroyed by callers!
+ */
extern pthread_mutex_t grep_attr_mutex;
#endif
^ permalink raw reply related
* [BUG] attribute "eol" with "crlf"
From: Ralf Thielow @ 2011-12-16 17:44 UTC (permalink / raw)
To: git
There's a bug in git-1.7.8 if you use the attribute "eol" with "crlf".
Steps to reproduce:
- add and commit a text file which uses 0d0a for line breaks
7465 7374 0d0a 0d0a 7465 7374 0d0a test....test..
- add ".gitattributes" with "*.txt eol=crlf"
- change a line in the file
- execute "git checkout [file]"
The result is:
7465 7374 0d0d 0a0d 0d0a 7465 7374 0d0d test......test..
0d0a was replaced by 0d0d0a.
^ permalink raw reply
* Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Mark Levedahl @ 2011-12-16 17:51 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Brandon Casey
In-Reply-To: <20111216110000.GA15676@sigill.intra.peff.net>
On 12/16/2011 06:00 AM, Jeff King wrote:
> + "*.m diff=objc",
Please don't do this: Matlab files also use .m as a suffix, and there is
little to no compatibility between objective c and Matlab syntax.
Mark
^ permalink raw reply
* [PATCH] Adding hooks.directory config option; wiring into run_hook
From: Christopher Dale @ 2011-12-16 18:00 UTC (permalink / raw)
To: git
>From 92a34696bb4e76ae7a967666234f13d04858bb68 Mon Sep 17 00:00:00 2001
From: Christopher Dale <chrelad@gmail.com>
Date: Fri, 16 Dec 2011 10:55:26 -0600
Subject: [PATCH] Adding hooks.directory config option; wiring into run_hook
The new hooks.directory config option allows each git repository to
specify the location of the hooks for that repository. The default
remains $GIT_DIR/hooks. The ability to change the hooks directory is
necessary when stuck in an environment with enhanced security and
trusted path execution policies. These systems require that any file
that can be executed exhibit at least the following characteristics:
* The executable, it's directory, and each directory above it are
not writable.
Since the hooks directory is within a directory that by it's very nature
requires write permissions, hooks are a non-starter in git's current
state. This patch aims to allow a (most likely bare) repo to have it's
hooks directory customized to a location that meets the above
requirements.
I'm not terribly good at C++, so please let me know if I need to fix
anything. I saw that there were a bunch of scripts that have
GIT_DIR/hooks hard-coded in them. Since I'm not familiar with those
scripts, I will leave them alone for now. Maybe someone that is familiar
with the scripts can integrate the new configuration option into them?
---
Documentation/config.txt | 5 +++++
contrib/completion/git-completion.bash | 1 +
run-command.c | 25 +++++++++++++++++++++++--
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8a7d2d4..c23417c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1226,6 +1226,11 @@ help.autocorrect::
value is 0 - the command will be just shown but not executed.
This is the default.
+hooks.directory::
+ Override the default hook directory location GIT_DIR/hooks. This can be
+ usefull if you are in an environment that has trusted path execution for
+ example.
+
http.proxy::
Override the HTTP proxy, normally configured using the 'http_proxy'
environment variable (see linkgit:curl[1]). This can be overridden
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index cc1bdf9..066948e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2177,6 +2177,7 @@ _git_config ()
help.autocorrect
help.browser
help.format
+ hooks.directory
http.lowSpeedLimit
http.lowSpeedTime
http.maxRequests
diff --git a/run-command.c b/run-command.c
index 1c51043..2e5fa16 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "diff.h"
#include "run-command.h"
#include "exec_cmd.h"
#include "argv-array.h"
@@ -65,6 +66,7 @@ static int execv_shell_cmd(const char **argv)
#ifndef WIN32
static int child_err = 2;
static int child_notifier = -1;
+static const char *hook_directory = NULL;
static void notify_parent(void)
{
@@ -603,6 +605,14 @@ int finish_async(struct async *async)
#endif
}
+static int git_hook_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "hooks.directory"))
+ return git_config_pathname(&hook_directory, var, value);
+
+ return git_diff_ui_config(var, value, cb);
+}
+
int run_hook(const char *index_file, const char *name, ...)
{
struct child_process hook;
@@ -612,11 +622,22 @@ int run_hook(const char *index_file, const char
*name, ...)
va_list args;
int ret;
- if (access(git_path("hooks/%s", name), X_OK) < 0)
+ // If this is not reset to NULL, then strange stuff happens
+ hook_directory = NULL;
+
+ // Load the configuration for hooks.directory
+ git_config(git_hook_config, NULL);
+
+ // If the configuration is not set for hooks directory, set it to the
+ // default GIT_PATH/hooks directory that we all know and love.
+ if(hook_directory == NULL)
+ hook_directory = git_path("hooks");
+
+ if (access(mkpath("%s/%s", hook_directory, name), X_OK) < 0)
return 0;
va_start(args, name);
- argv_array_push(&argv, git_path("hooks/%s", name));
+ argv_array_push(&argv, mkpath("%s/%s", hook_directory, name));
while ((p = va_arg(args, const char *)))
argv_array_push(&argv, p);
va_end(args);
--
1.7.5.2.353.g5df3e
^ permalink raw reply related
* Re: [BUG] attribute "eol" with "crlf"
From: Junio C Hamano @ 2011-12-16 18:03 UTC (permalink / raw)
To: Ralf Thielow; +Cc: git
In-Reply-To: <CAN0XMO+OOdTJ+aNMSc2G3RVc7Wfypr4+7dU3US9GVAmMiSJ7cg@mail.gmail.com>
Can you bisect?
^ permalink raw reply
* Re: [PATCH] Adding hooks.directory config option; wiring into run_hook
From: Junio C Hamano @ 2011-12-16 18:06 UTC (permalink / raw)
To: Christopher Dale; +Cc: git
In-Reply-To: <CADQnX_e76LzuRUDOKFOsRHU=e8Cw+qh5x1BdW5HMEdMmP5PaHg@mail.gmail.com>
Christopher Dale <chrelad@gmail.com> writes:
> ...
> trusted path execution policies. These systems require that any file
> that can be executed exhibit at least the following characteristics:
>
> * The executable, it's directory, and each directory above it are
> not writable.
>
> Since the hooks directory is within a directory that by it's very nature
> requires write permissions,...
Sorry, but I am not interested at all. If you can write into $GIT_DIR/config
then you can point at any directory with hooks.directory and that would mean
it would defeat your "trusted path execution policies".
^ permalink raw reply
* Re: [BUG] attribute "eol" with "crlf"
From: Matthieu Moy @ 2011-12-16 18:21 UTC (permalink / raw)
To: Ralf Thielow; +Cc: git
In-Reply-To: <CAN0XMO+OOdTJ+aNMSc2G3RVc7Wfypr4+7dU3US9GVAmMiSJ7cg@mail.gmail.com>
Ralf Thielow <ralf.thielow@googlemail.com> writes:
> There's a bug in git-1.7.8 if you use the attribute "eol" with "crlf".
>
> Steps to reproduce:
> - add and commit a text file which uses 0d0a for line breaks
> 7465 7374 0d0a 0d0a 7465 7374 0d0a test....test..
> - add ".gitattributes" with "*.txt eol=crlf"
> - change a line in the file
> - execute "git checkout [file]"
>
> The result is:
> 7465 7374 0d0d 0a0d 0d0a 7465 7374 0d0d test......test..
It seems to me to be the expected behavior. You committed a file whose
line endings are not normalized to LF in the repository, and asked for a
conversion LF -> CRLF on checkout, which Git did.
Git can't know exactly the moment when you edit .gitattributes, so it
can't do the conversion at the time you add the eol=crlf attribute. It
does it on checkout.
> 0d0a was replaced by 0d0d0a.
I'd say 0a (LF) was replaced by 0d0a (CRLF).
What behavior would you have expected?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Adding hooks.directory config option; wiring into run_hook
From: Christopher Dale @ 2011-12-16 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxasie6k.fsf@alter.siamese.dyndns.org>
Okidokee, thanks for your feedback :)
On Fri, Dec 16, 2011 at 12:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christopher Dale <chrelad@gmail.com> writes:
>
>> ...
>> trusted path execution policies. These systems require that any file
>> that can be executed exhibit at least the following characteristics:
>>
>> * The executable, it's directory, and each directory above it are
>> not writable.
>>
>> Since the hooks directory is within a directory that by it's very nature
>> requires write permissions,...
>
> Sorry, but I am not interested at all. If you can write into $GIT_DIR/config
> then you can point at any directory with hooks.directory and that would mean
> it would defeat your "trusted path execution policies".
^ 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