* 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: 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
* 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: [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: 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] 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: 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: 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
* 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: 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
* 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
* [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
* [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] use custom rename score during --follow
From: Jeff King @ 2011-12-16 11:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If you provide a custom rename score on the command line,
like:
git log -M50 --follow foo.c
it is completely ignored, and there is no way to --follow
with a looser rename score. Instead, let's use the same
rename score that will be used for generating diffs. This is
convenient, and mirrors what we do with the break-score.
You can see an example of it being useful in git.git:
$ git log --oneline --summary --follow \
Documentation/technical/api-string-list.txt
86d4b52 string-list: Add API to remove an item from an unsorted list
1d2f80f string_list: Fix argument order for string_list_append
e242148 string-list: add unsorted_string_list_lookup()
0dda1d1 Fix two leftovers from path_list->string_list
c455c87 Rename path_list to string_list
create mode 100644 Documentation/technical/api-string-list.txt
$ git log --oneline --summary -M40 --follow \
Documentation/technical/api-string-list.txt
86d4b52 string-list: Add API to remove an item from an unsorted list
1d2f80f string_list: Fix argument order for string_list_append
e242148 string-list: add unsorted_string_list_lookup()
0dda1d1 Fix two leftovers from path_list->string_list
c455c87 Rename path_list to string_list
rename Documentation/technical/{api-path-list.txt => api-string-list.txt} (47%)
328a475 path-list documentation: document all functions and data structures
530e741 Start preparing the API documents.
create mode 100644 Documentation/technical/api-path-list.txt
You could have two separate rename scores, one for following
and one for diff. But almost nobody is going to want that,
and it would just be unnecessarily confusing. Besides which,
we re-use the diff results from try_to_follow_renames for
the actual diff output, which means having them as separate
scores is actively wrong. E.g., with the current code, you
get:
$ git log --oneline --diff-filter=R --name-status \
-M90 --follow git.spec.in
27dedf0 GIT 0.99.9j aka 1.0rc3
R084 git-core.spec.in git.spec.in
f85639c Rename the RPM from "git" to "git-core"
R098 git.spec.in git-core.spec.in
The first one should not be considered a rename by the -M
score we gave, but we print it anyway, since we blindly
re-use the diff information from the follow (which uses the
default score). So this could also be considered simply a
bug-fix, as with the current code "-M" is completely ignored
when using "--follow".
Signed-off-by: Jeff King <peff@peff.net>
---
I posted this a long time ago as a "you could do it like this" patch:
http://thread.gmane.org/gmane.comp.version-control.git/160681
but never actually dug more to make sure it wasn't having any weird
effects on the diff output. As it turns out, I think it is not only not
having a bad effect, but is actively fixing a bug. :)
tree-diff.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 7a51d09..28ad6db 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -209,6 +209,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->pathspec.raw[0];
diff_opts.break_opt = opt->break_opt;
+ diff_opts.rename_score = opt->rename_score;
paths[0] = NULL;
diff_tree_setup_paths(paths, &diff_opts);
if (diff_setup_done(&diff_opts) < 0)
--
1.7.7.4.13.g57bf4
^ permalink raw reply related
* [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-12-16 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey
We already provide sane hunk-header patterns for specific
languages.
However, the user has to manually map common extensions to
use them. It's not that hard to do, but it's an extra step
that the user might not even know is an option. Let's be
nice and do it automatically.
It could be a problem in the future if the builtin userdiff
drivers started growing more invasive options, like
automatically claiming to be non-binary (e.g., setting
diff.cpp.binary = false by default), but right now we do not
do that, so it should be safe. To help safeguard against
future changes, we add a new test to t4012 making sure that
we don't consider binary files as text by their extension.
We also have to update t4018, which assumed that without a
.gitattributes file, we would receive the default funcname
pattern for a file matching "*.java". Changing this behavior
is not covering up a regression, but rather the feature
working as intended.
Signed-off-by: Jeff King <peff@peff.net>
---
I forgot to send this out in time for v1.7.8.
Prior discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/180103
and here:
http://thread.gmane.org/gmane.comp.version-control.git/181253
The list of extensions is collected from those threads. The tests are
new since the last time I posted (and the t4018 is slightly different
than what you queued in pu).
I punted on the question of case-sensitivity. Brandon mentioned using
fnmatch_icase to handle this, which sounds sane, but I think it is
really a separate topic.
attr.c | 24 ++++++++++++++++++++++++
t/t4012-diff-binary.sh | 13 +++++++++++++
t/t4018-diff-funcname.sh | 10 +++++++++-
3 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/attr.c b/attr.c
index 76b079f..2ad7cc4 100644
--- a/attr.c
+++ b/attr.c
@@ -306,6 +306,30 @@ static void free_attr_elem(struct attr_stack *e)
static const char *builtin_attr[] = {
"[attr]binary -diff -text",
+ "*.html diff=html",
+ "*.htm diff=html",
+ "*.java diff=java",
+ "*.perl diff=perl",
+ "*.pl diff=perl",
+ "*.php diff=php",
+ "*.py diff=python",
+ "*.rb diff=ruby",
+ "*.bib diff=bibtex",
+ "*.tex diff=tex",
+ "*.c diff=cpp",
+ "*.cc diff=cpp",
+ "*.cxx diff=cpp",
+ "*.cpp diff=cpp",
+ "*.h diff=cpp",
+ "*.hpp diff=cpp",
+ "*.cs diff=csharp",
+ "*.[Ff] diff=fortran",
+ "*.[Ff][0-9][0-9] diff=fortran",
+ "*.m diff=objc",
+ "*.mm diff=objc",
+ "*.pas diff=pascal",
+ "*.pp diff=pascal",
+ "*.lpr diff=pascal",
NULL,
};
diff --git a/t/t4012-diff-binary.sh b/t/t4012-diff-binary.sh
index 2d9f9a0..b2fc807 100755
--- a/t/t4012-diff-binary.sh
+++ b/t/t4012-diff-binary.sh
@@ -90,4 +90,17 @@ test_expect_success 'diff --no-index with binary creation' '
test_cmp expected actual
'
+test_expect_success 'binary files are not considered text by file extension' '
+ echo Q | q_to_nul >binary.c &&
+ git add binary.c &&
+ cat >expect <<-\EOF &&
+ diff --git a/binary.c b/binary.c
+ new file mode 100644
+ index 0000000..1f2a4f5
+ Binary files /dev/null and b/binary.c differ
+ EOF
+ git diff --cached binary.c >actual &&
+ test_cmp expect actual
+'
+
test_done
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 4bd2a1c..a6227ef 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -124,7 +124,9 @@ do
done
test_expect_success 'default behaviour' '
- rm -f .gitattributes &&
+ cat >.gitattributes <<-\EOF &&
+ *.java diff=default
+ EOF
test_expect_funcname "public class Beer\$"
'
@@ -187,4 +189,10 @@ test_expect_success 'alternation in pattern' '
test_expect_funcname "public static void main("
'
+test_expect_success 'custom diff drivers override built-in extension matches' '
+ test_config diff.foo.funcname "int special" &&
+ echo "*.java diff=foo" >.gitattributes &&
+ test_expect_funcname "int special"
+'
+
test_done
--
1.7.7.4.13.g57bf4
^ permalink raw reply related
* git 1.7.7.5
From: Jonathan Nieder @ 2011-12-16 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
I noticed that v1.7.7.5 was tagged a few days ago (b36dcd72), but
there is no corresponding tarball at
http://code.google.com/p/git-core/downloads/list
Will there be an official tarball?
I don't mind either way, but it would be useful to know whether
distributors should make their own or just wait.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] Add '-P' as a synonym for '--no-pager' in the git command
From: Matthieu Moy @ 2011-12-16 9:30 UTC (permalink / raw)
To: Joe Ratterman; +Cc: gitster, git
In-Reply-To: <1323982541-18995-1-git-send-email-jratt0@gmail.com>
Joe Ratterman <jratt0@gmail.com> writes:
> Also, add both -P|--no-pager to the existing -p|--paginate in bash
> completion.
A good commit message should always answer the question "why?". In this
case, I really don't see why this is needed. If you don't like Git's
auto-paginate feature, turn it off with core.pager or pager.<cmd>. If
you like it, you very rarely need --no-pager (IIRC, I'm the one who
introduced --no-pager, and I don't think I've ever used it outside a
script).
So, I'd rather keep -P free in case we need it later for something
really useful (or possibly a better commit message).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v3 2/3] grep: enable threading with -p and -W using lazy attribute lookup
From: Johannes Sixt @ 2011-12-16 8:22 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Junio C Hamano, René Scharfe, Jeff King, Eric Herman
In-Reply-To: <138b930c0c96029f2fb9a816e73e70a4d5bce1de.1323723759.git.trast@student.ethz.ch>
Am 12/12/2011 22:16, schrieb Thomas Rast:
> diff --git a/grep.h b/grep.h
> index a652800..15d227c 100644
> --- a/grep.h
> +++ b/grep.h
> @@ -115,6 +115,7 @@ struct grep_opt {
> int show_hunk_mark;
> int file_break;
> int heading;
> + int use_threads;
> void *priv;
>
> void (*output)(struct grep_opt *opt, const void *data, size_t size);
> @@ -131,4 +132,10 @@ struct grep_opt {
> 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! */
> +extern pthread_mutex_t grep_attr_mutex;
> +#endif
> +
> #endif
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, and therefore does not look right to
be #included in a header.
---
grep.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/grep.h b/grep.h
index 15d227c..754b270 100644
--- a/grep.h
+++ b/grep.h
@@ -133,6 +133,7 @@ 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
+#include <pthread.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;
--
1.7.8.1436.gb3021
^ permalink raw reply related
* Re: error: insufficient permission
From: Manish Patel @ 2011-12-16 8:09 UTC (permalink / raw)
To: git
In-Reply-To: <4AB73A07.3020703@bioinf.uni-leipzig.de>
Very simple.. just find out .git directory give 0777 permission to objects
dir.. such as..
chmod -R 0777 objects
--
View this message in context: http://git.661346.n2.nabble.com/error-insufficient-permission-tp3683868p7099986.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Revisiting metadata storage
From: Jonathan Nieder @ 2011-12-16 7:52 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Richard Hartmann, Ronan Keryell, Git List
In-Reply-To: <CAE1pOi2TGWmFErcKhQu-a37JjLh22O1zFYoBaVRyfBDFjOTE9Q@mail.gmail.com>
Hilco Wijbenga wrote:
> Right now every rebase means a full (and almost
> completely unnecessary) rebuild.
It sounds like what you are suffering from is that "git rebase" uses
the worktree as its workspace instead of doing all that work
in-memory, right?
If I were in your situation, I would do the following:
1. Don't rebase so often. When wanting to take advantage of features
from a new upstream version, use "git merge" to pull it in. Only
rebase when it is time to make the history presentable for other
people.
This way, "git log --first-parent" will give easy access to
the intermediate versions you have hacked on and tested recently.
2. When history gets ugly and you want to rebase to make the series
easier to make sense of, use a separate workdir:
$ git branch tmp; # make a copy to rebase
$ cd ..
$ git new-workdir repo rebase-scratch tmp
$ cd rebase-scratch
$ git rebase -i origin/master
...
$ cd ..
$ rm -fr rebase-scratch
$ cd repo
$ git diff HEAD tmp; # Does the rebased version look better?
$ git reset --keep tmp; # Yes. Use it.
$ git branch -d tmp
3. Once the rebased history looks reasonably good, be sure to rebase
one final time and test each commit before submitting for other
people's use.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Branch names with slashes
From: Johannes Sixt @ 2011-12-16 7:02 UTC (permalink / raw)
To: Leonardo Kim; +Cc: git
In-Reply-To: <CAGcUY13TOodu1BO3DCoNnVvNZ9QkWAbD-RmyqQX6P1q6tcO+yg@mail.gmail.com>
Am 12/14/2011 11:17, schrieb Leonardo Kim:
> Branch names can contain slashes, so we can use 'development/foo' as a
> branch name. If I choose 'development' as a branch name, it doesn't
> work. There is a directory named development at '.git/refs/heads'
> directory. So we cannot create a file named development for
> 'refs/heads/development'.
>
> An error message may occurs like below. Unfortunately, It is not of help to me.
> 'error: 'refs/heads/development/foo' exists; cannot create
> 'refs/heads/development'.
>
> I think that dealing with a file system and an error message above is
> not sufficient for a novice like me. I hope that it should be
> improved.
Sorry, I don't see anything in the error message that makes a connection
between refs and a file system; it only says "foo/bar exists; cannot
create foo". I really don't see how this can be improved to avoid confusion.
-- Hannes
^ permalink raw reply
* How to generate pull-request with info of signed tag
From: Aneesh Kumar K.V @ 2011-12-16 6:35 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
Hi,
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 ?
-aneesh
^ permalink raw reply
* Re: How to commit incomplete changes?
From: Tomas Carnecky @ 2011-12-16 1:49 UTC (permalink / raw)
To: Hallvard B Furuseth; +Cc: git
In-Reply-To: <4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no>
On 12/15/11 12:24 AM, Hallvard B Furuseth wrote:
> I'm about to commit some small edits which go together with bigger
> generated changes. It seems both more readable and more cherry-pick-
> friendly to me to keep these in separate commits.
Why do you store generated code? Usually you only store what is
absolutely necessary. That means generated code should be generated as
needed (part of the build process for example).
tom
^ permalink raw reply
* Re: How to commit incomplete changes?
From: Junio C Hamano @ 2011-12-16 0:21 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Hallvard B Furuseth, git
In-Reply-To: <4EEA79E0.4070700@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> writes:
> A main purpose for the squash and fixup options is ...
> "To make it look like you
> did it all perfectly without making any mistakes" (or a reasonable
> facsimile thereof). You insights on the cherry-picking of fixes is
> interesting, but makes no sense in the context of unpublished work.
> Why would you need to cherry-pick fixes to mistakes that have not yet
> been propagated (published)?
> ...
> I assume by 'generated changes' you mean the automerge in git...
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.
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()?
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.
If you did the mechanical one first, the resulting code would not compile
(lacks xsetenv() implementation), and then the second "manual" one would
"fix" it. In this simplified example, it is easy to flip the orders and
keep things work, but then you would get a complaint from clever compiler
or linker that xsetenv() implementation is defined but nobody uses it,
which is another kind of breakage. So it _is_ possible that you cannot
avoid breaking the system inside two patches, making them "all-or-none"
series.
^ permalink raw reply
* What's cooking in git.git (Dec 2011, #05; Thu, 15)
From: Junio C Hamano @ 2011-12-16 0:11 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'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* ef/setenv-putenv (2011-12-14) 2 commits
- compat/setenv.c: error if name contains '='
- compat/setenv.c: update errno when erroring out
(this branch is used by ef/x-setenv-putenv.)
* jk/maint-do-not-feed-stdin-to-tests (2011-12-15) 1 commit
- test-lib: redirect stdin of tests
* jn/test-cleanup-7006 (2011-12-14) 1 commit
- test: errors preparing for a test are not special
* nd/war-on-nul-in-commit (2011-12-15) 3 commits
- commit_tree(): refuse commit messages that contain NULs
- Convert commit_tree() to take strbuf as message
- merge: abort if fails to commit
* jk/git-prompt (2011-12-12) 10 commits
- contrib: add credential helper for OS X Keychain
- Makefile: OS X has /dev/tty
- Makefile: linux has /dev/tty
- credential: use git_prompt instead of git_getpass
- prompt: use git_terminal_prompt
- add generic terminal prompt function
- refactor git_getpass into generic prompt function
- move git_getpass to its own source file
- imap-send: don't check return value of git_getpass
- imap-send: avoid buffer overflow
(this branch uses jk/credentials.)
Will merge to 'next' after taking another look.
* mh/ref-api-rest (2011-12-12) 35 commits
- repack_without_ref(): call clear_packed_ref_cache()
- read_packed_refs(): keep track of the directory being worked in
- is_refname_available(): query only possibly-conflicting references
- refs: read loose references lazily
- read_loose_refs(): take a (ref_entry *) as argument
- struct ref_dir: store a reference to the enclosing ref_cache
- sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
- add_entry(): take (ref_entry *) instead of (ref_dir *)
- search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
- add_ref(): take (ref_entry *) instead of (ref_dir *)
- read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
- find_ref(): take (ref_entry *) instead of (ref_dir *)
- is_refname_available(): take (ref_entry *) instead of (ref_dir *)
- get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
- get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
- refs: wrap top-level ref_dirs in ref_entries
- get_ref_dir(): keep track of the current ref_dir
- do_for_each_ref(): only iterate over the subtree that was requested
- refs: sort ref_dirs lazily
- sort_ref_dir(): do not sort if already sorted
- refs: store references hierarchically
- refs.c: rename ref_array -> ref_dir
- struct ref_entry: nest the value part in a union
- check_refname_component(): return 0 for zero-length components
- free_ref_entry(): new function
- refs.c: reorder definitions more logically
- is_refname_available(): reimplement using do_for_each_ref_in_array()
- names_conflict(): simplify implementation
- names_conflict(): new function, extracted from is_refname_available()
- repack_without_ref(): reimplement using do_for_each_ref_in_array()
- do_for_each_ref_in_arrays(): new function
- do_for_each_ref_in_array(): new function
- do_for_each_ref(): correctly terminate while processesing extra_refs
(this branch uses mh/ref-api.)
The API for extra anchoring points may require rethought first; that would
hopefully make the "ref" part a lot simpler.
--------------------------------------------------
[Graduated to "master"]
* bc/maint-apply-check-no-patch (2011-12-05) 2 commits
(merged to 'next' on 2011-12-09 at fc780cd)
+ builtin/apply.c: report error on failure to recognize input
+ t/t4131-apply-fake-ancestor.sh: fix broken test
* cn/maint-lf-to-crlf-filter (2011-11-28) 1 commit
(merged to 'next' on 2011-12-09 at c374d14)
+ convert: track state in LF-to-CRLF filter
* jk/maint-1.6.2-upload-archive (2011-11-21) 1 commit
+ archive: don't let remote clients get unreachable commits
(this branch is used by jk/maint-upload-archive.)
* jk/maint-fetch-status-table (2011-12-09) 1 commit
(merged to 'next' on 2011-12-09 at 159415e)
+ fetch: create status table using strbuf
* jk/maint-upload-archive (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 03deb16)
+ Merge branch 'jk/maint-1.6.2-upload-archive' into jk/maint-upload-archive
(this branch uses jk/maint-1.6.2-upload-archive.)
* jl/submodule-status-failure-report (2011-12-08) 1 commit
(merged to 'next' on 2011-12-09 at 53eb3b3)
+ diff/status: print submodule path when looking for changes fails
* jn/branch-move-to-self (2011-11-28) 2 commits
(merged to 'next' on 2011-12-09 at 7d27260)
+ Allow checkout -B <current-branch> to update the current branch
+ branch: allow a no-op "branch -M <current-branch> HEAD"
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
(merged to 'next' on 2011-12-09 at 7662e58)
+ gitweb: Add navigation to select side-by-side diff
+ gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
+ t9500: Add basic sanity tests for side-by-side diff in gitweb
+ t9500: Add test for handling incomplete lines in diff by gitweb
+ gitweb: Give side-by-side diff extra CSS styling
+ gitweb: Add a feature to show side-by-side diff
+ gitweb: Extract formatting of diff chunk header
+ gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
* ks/tag-cleanup (2011-12-09) 1 commit
(merged to 'next' on 2011-12-09 at cbea045)
+ git-tag: introduce --cleanup option
* nd/ignore-might-be-precious (2011-11-28) 2 commits
(merged to 'next' on 2011-12-09 at 1a94553)
+ checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
+ Merge branch 'nd/maint-ignore-exclude' into nd/ignore-might-be-precious
* tj/maint-imap-send-remove-unused (2011-11-23) 2 commits
(merged to 'next' on 2011-12-09 at 877cc11)
+ Merge branch 'maint' into tj/imap-send-remove-unused
+ imap-send: Remove unused 'use_namespace' variable
* tr/userdiff-c-returns-pointer (2011-12-06) 1 commit
(merged to 'next' on 2011-12-09 at 0b6a092)
+ userdiff: allow * between cpp funcname words
--------------------------------------------------
[Cooking]
* ci/stripspace-docs (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at 35b2cdf)
+ Update documentation for stripspace
* jk/maint-mv (2011-12-12) 5 commits
(merged to 'next' on 2011-12-13 at 58caedb)
+ mv: be quiet about overwriting
+ mv: improve overwrite warning
+ mv: make non-directory destination error more clear
+ mv: honor --verbose flag
+ docs: mention "-k" for both forms of "git mv"
* jk/maint-snprintf-va-copy (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at d37a7e1)
+ compat/snprintf: don't look at va_list twice
* jn/maint-sequencer-fixes (2011-12-12) 7 commits
(merged to 'next' on 2011-12-13 at 5b3950c)
+ revert: stop creating and removing sequencer-old directory
+ Revert "reset: Make reset remove the sequencer state"
+ revert: do not remove state until sequence is finished
+ revert: allow single-pick in the middle of cherry-pick sequence
+ revert: pass around rev-list args in already-parsed form
+ revert: allow cherry-pick --continue to commit before resuming
+ revert: give --continue handling its own function
(this branch is used by rr/revert-cherry-pick.)
* mh/ref-api (2011-12-12) 16 commits
(merged to 'next' on 2011-12-15 at d65a830)
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ repack_without_ref(): remove temporary
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
(this branch is used by mh/ref-api-rest.)
Later part split out to expedite moving the earlier good bits forward.
* nd/resolve-ref (2011-12-13) 3 commits
(merged to 'next' on 2011-12-13 at c7002e9)
+ Rename resolve_ref() to resolve_ref_unsafe()
+ Convert resolve_ref+xstrdup to new resolve_refdup function
+ revert: convert resolve_ref() to read_ref_full()
* tr/grep-threading (2011-12-12) 3 commits
- grep: disable threading in non-worktree case
- grep: enable threading with -p and -W using lazy attribute lookup
- grep: load funcname patterns for -W
Will merge to 'next' after taking another look.
* tr/pty-all (2011-12-12) 3 commits
- t/lib-terminal: test test-terminal's sanity
- test-terminal: set output terminals to raw mode
- test-terminal: give the child an empty stdin TTY
* jc/push-ignore-stale (2011-12-14) 2 commits
- push: --ignore-stale option
- set_ref_status_for_push(): use transport-flags abstraction
* jk/fetch-no-tail-match-refs (2011-12-13) 4 commits
(merged to 'next' on 2011-12-13 at 805c018)
+ connect.c: drop path_match function
+ fetch-pack: match refs exactly
+ t5500: give fully-qualified refs to fetch-pack
+ drop "match" parameter from get_remote_heads
* jk/maint-push-over-dav (2011-12-13) 2 commits
(merged to 'next' on 2011-12-13 at 45e376c)
+ http-push: enable "proactive auth"
+ t5540: test DAV push with authentication
* rr/revert-cherry-pick (2011-12-15) 6 commits
- t3502, t3510: clarify cherry-pick -m failure
- t3510 (cherry-pick-sequencer): use exit status
- revert: simplify getting commit subject in format_todo()
- revert: tolerate extra spaces, tabs in insn sheet
- revert: make commit subjects in insn sheet optional
- revert: free msg in format_todo()
(this branch uses jn/maint-sequencer-fixes.)
Picked up only the earlier bits that are reasonably clear for now.
* ew/keepalive (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 1b5d5c4)
+ enable SO_KEEPALIVE for connected TCP sockets
* jc/checkout-m-twoway (2011-12-15) 3 commits
(merged to 'next' on 2011-12-15 at cc64fed)
+ checkout_merged(): squelch false warning from some gcc
(merged to 'next' on 2011-12-11 at b61057f)
+ Test 'checkout -m -- path'
(merged to 'next' on 2011-12-09 at c946009)
+ checkout -m: no need to insist on having all 3 stages
* tr/cache-tree (2011-12-06) 5 commits
(merged to 'next' on 2011-12-13 at e0da64d)
+ reset: update cache-tree data when appropriate
+ commit: write cache-tree data when writing index anyway
+ Refactor cache_tree_update idiom from commit
+ Test the current state of the cache-tree optimization
+ Add test-scrap-cache-tree
* jc/commit-amend-no-edit (2011-12-08) 5 commits
(merged to 'next' on 2011-12-09 at b9cfa4e)
+ test: commit --amend should honor --no-edit
+ commit: honour --no-edit
+ t7501 (commit): modernize style
+ test: remove a porcelain test that hard-codes commit names
+ test: add missing "&&" after echo command
Will merge to 'master'.
* rr/test-chaining (2011-12-11) 7 commits
(merged to 'next' on 2011-12-13 at b08445e)
+ t3401: use test_commit in setup
+ t3401: modernize style
+ t3040 (subprojects-basic): fix '&&' chaining, modernize style
+ t1510 (worktree): fix '&&' chaining
+ t3030 (merge-recursive): use test_expect_code
+ test: fix '&&' chaining
+ t3200 (branch): fix '&&' chaining
* aw/rebase-i-stop-on-failure-to-amend (2011-11-30) 1 commit
(merged to 'next' on 2011-12-09 at a117e83)
+ rebase -i: interrupt rebase when "commit --amend" failed during "reword"
Will merge to 'master'.
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
(this branch uses jc/stream-to-pack.)
Not ready. At least pack-objects and fsck need to learn the new encoding
for the series to be usable locally, and then index-pack/unpack-objects
needs to learn it to be used remotely.
* jh/fast-import-notes (2011-11-28) 3 commits
(merged to 'next' on 2011-12-09 at 2b01132)
+ fast-import: Fix incorrect fanout level when modifying existing notes refs
+ t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling
+ t9301: Fix testcase covering up a bug in fast-import's notes fanout handling
Will merge to 'master'.
* jk/credentials (2011-12-12) 14 commits
(merged to 'next' on 2011-12-12 at 7a6d658)
+ t: add test harness for external credential helpers
+ credentials: add "store" helper
+ strbuf: add strbuf_add*_urlencode
+ Makefile: unix sockets may not available on some platforms
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ credential: make relevance of http path configurable
+ credential: add credential.*.username
+ credential: apply helper config
+ http: use credential API to get passwords
+ credential: add function for parsing url components
+ introduce credentials API
+ t5550: fix typo
+ test-lib: add test_config_global variant
(this branch is used by jk/git-prompt.)
Later part split out to expedite moving the earlier good bits forward.
* jk/upload-archive-use-start-command (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 88cb83a)
+ upload-archive: use start_command instead of fork
Will merge to 'master'.
* ab/enable-i18n (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 65af8cd)
+ i18n: add infrastructure for translating Git with gettext
* jc/signed-commit (2011-11-29) 5 commits
- gpg-interface: allow use of a custom GPG binary
- pretty: %G[?GS] placeholders
- test "commit -S" and "log --show-signature"
- log: --show-signature
- commit: teach --gpg-sign option
Not exactly urgent.
* jc/stream-to-pack (2011-12-01) 5 commits
(merged to 'next' on 2011-12-09 at d0fd605)
+ bulk-checkin: replace fast-import based implementation
+ csum-file: introduce sha1file_checkpoint
+ finish_tmp_packfile(): a helper function
+ create_tmp_packfile(): a helper function
+ write_pack_header(): a helper function
(this branch is used by jc/split-blob.)
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. The codepath to
move data from worktree to repository is made aware of streaming, just
like the checkout codepath that goes the other way, which was done in the
previous "large file support" topic in the 1.7.7 cycle.
Will merge to 'master'.
^ 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