* Re: git.wiki.kernel.org spam ...
From: Johannes Schindelin @ 2012-12-31 17:08 UTC (permalink / raw)
To: rupert THURNER; +Cc: git
In-Reply-To: <CAJs9aZ_Nu9PzYYLc55Lr8E+UefohK+pSUbF5i8Lu4V_gr2KHPw@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 707 bytes --]
Hi Rupert,
On Sat, 29 Dec 2012, rupert THURNER wrote:
> ich hab gesehen, du bist ober-meister des kernle.org git wikis. da
> gibt es ganz schön viel neue user und spam derzeit, zb:
> https://git.wiki.kernel.org/index.php?title=User_talk:Bridgetevans0521&redirect=no
>
> möchtest du das erzeugen von user accounts erschweren, wie zb hier:
> http://kiwix.org/index.php/Special:UserLogin?type=signup&returnto=Main_Page/en
>
> falls du noch leute als admin haben willst, ich melde mich freiwillig,
> ThurnerRupert ist mein account.
Since my trustworthiness was questioned, I have stopped completely with
the maintenance of the Wiki.
The mailing list (Cc:ed) may have additional comments.
Ciao,
Johannes
^ permalink raw reply
* Re: [RFC] pack-objects: compression level for non-blobs
From: Shawn Pearce @ 2012-12-31 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, David Michael Barr, Git Mailing List
In-Reply-To: <20121230213124.GA15946@sigill.intra.peff.net>
This thread is pretty interesting. Unfortunately the holidays have
kept me busy. But I am excited by the work David and Peff are doing.
:-)
On Sun, Dec 30, 2012 at 1:31 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Dec 30, 2012 at 07:53:48PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > $ cd objects/pack && ls
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.commits
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.idx
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.pack
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.parents
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.timestamps
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.trees
>> >
>> > Each file describes the objects in the matching pack. If a new pack is
>> > generated, you'd throw away the old cache files along with the old pack,
>> > and generate new ones. Or not. These are totally optional, and an older
>> > version of git will just ignore them. A newer version will use them if
>> > they're available, and otherwise fallback to the existing code (i.e.,
>> > reading the whole object from the pack). So you can generate them at
>>
>> You have probably thought about this (and I don't have the source to
>> check first), but we may need to version these extra files so we can
>> change the format later if needed. Git versions that do not recognize
>> new versions simply ignore the cahce.
>
> Agreed. The current code has a 4-byte magic, followed by a 4-byte
> version number, followed by a 4-byte record size[1]. Then the data,
> followed by the pack sha1, followed by a sha1 of all of the preceding
> data. So you can verify the validity of any cache file (both its
> checksum, and that it matches the right packfile), just as you can with
> a ".idx" file.
Put the pack sha1 into the header, rather than the trailer. Its really
annoying that you read the header, determine you probably understand
this file, and then have to seek to END-40 to read the pack sha1 and
verify it matches the pack. In an ideal world the pack sha1 would have
been the file name, making this less of an issue, but someone didn't
anticipate repacking the same object set with possibly different
results. :-(
The idx format is kind of wrong here, I wish we had put the pack sha1
into the header. Given that we mmap the files the 20 bytes in front
vs. 20 bytes in the trailer wouldn't have made any difference on
access cost.
>> > Each file is a set of fixed-length records. The "commits" file contains
>> > the sha1 of every commit in the pack (sorted). A binary search of the
>> > mmap'd file gives the position of a particular commit within the list,
>>
>> I think we could avoid storing sha-1 in the cache with Shawn's idea
>> [1]. But now I read it again I fail to see it :(
>>
>> [1] http://article.gmane.org/gmane.comp.version-control.git/206485
>
> Right. My implementation is very similar to what Shawn said there. I.e.,
> the timestamps file is literally 4 bytes times the number of commits.
> The parents file is 40 bytes per commit (2 parents, with a marker to
> indicate "more or less than 2"), though a lot of it is zero bytes.
Hmm, after re-reading [1] I still like my idea better. But I won't
find the time to code it myself, so I'll have to go with whatever
someone else writes. :-)
Since tree pointers are also required when parsing a commit (even if
they might not get used e.g. `git log master`) maybe this should be 16
bytes per commit storing the commit time, tree pointer, and 2 parents,
with the last 3 fields using the N-th object in the sorted sha1 list
in the idx. Sorting the file by pack stream ordering gives you good
locality during rev-list operations and makes it compact if
pack-objects adheres to writing commits before other objects.
Unfortunately this ordering requires the pack reverse index in memory
to translate from sha1 to position in the cache file. Making the
reverse index is a non-trivial cost that may dominate the running time
for smaller traversals, or the startup time for `git log` outputting
to the pager.
> Some alternatives I'm thinking about are:
>
> 1. Using non-fixed-size records, which would allow trivial compression
> of entries like null sha1s. This would mean adding a separate
> lookup table, though, mapping sha1s to offsets. Still, even a
> 32-bit offset is only 4 bytes per commit. If it meant dropping 40
> bytes of zeroes from the 2nd parent field out of half of all
> commits, that would be a win space-wise. It would be a
> double-indirect lookup, but it's constant effort, and only two page
> hits (which would be warm after the first lookup anyway).
Or use a 16 byte fixed width record (see above).
> 2. Storing offsets to objects in the packfile rather than their sha1s.
> This would save a lot of space, but would mean we couldn't refer to
> parents outside of the pack, but that may be OK. This is an
> optimization, and the case we want to target is a fully (or mostly)
> packed repo. It's OK to have the lookup fail and fallback to
> accessing the object.
I glossed over this in both [1] and this message. I think its
perfectly reasonable to require parsing the commit when the commit's
parents are outside of the pack. These edge commits are infrequent
compared to the number of commits within the pack. Just mark them the
same way you mark an octopus merge, so the reader knows the parent
data is not available in the cache. For most repositories the bulk of
the commits will be in a single giant pack that contains history to
the root.
I wouldn't store the byte offsets here, those are possibly 8 bytes
wide on bigger packs. Instead store the Nth position in the pack
stream. Even if you store byte offsets you need to use the pack
reverse index to recover the SHA-1 in log N time. If you store the Nth
position you also use the pack reverse index, but you can fit all
objects from that pack in 4 bytes rather than 8 bytes per reference.
> 3. Dropping the "commits" file and just using the pack-*.idx as the
> index. The problem is that it is sparse in the commit space. So
> just naively storing 40 bytes per entry is going to waste a lot of
> space. If we had a separate index as in (1) above, that could be
> dropped to (say) 4 bytes of offset per object. But still, right now
> the commits file for linux-2.6 is about 7.2M (20 bytes times ~376K
> commits). There are almost 3 million total objects, so even storing
> 4 bytes per object is going to be worse.
Fix pack-objects to behave the way JGit does, cluster commits first in
the pack stream. Now you have a dense space of commits. If I remember
right this has a tiny positive improvement for most rev-list
operations with very little downside.
> 4. Making a new index version that stores the sha1s separated by type.
> This means we can piggy-back on the regular index to get a packed
> list of just commits. But it also means that regular sha1 lookups
> of the objects have to look in several places (unless the caller
> annotates the call to read_sha1_object with "I am expecting this
> sha1 to be a commit"). And of course it means bumping the index
> version, which is a pain. The external index means it can be
> completely optional on top of the current index/pack.
I don't think this is worthwhile.
>> Depending on the use case, we could just generate packv4-like cache
>> for recently-used trees only. I'm not sure how tree cache impact a
>> merge operation on a very large worktree (iow, a lot of trees
>> referenced from HEAD to be inflated). This is something a cache can
>> do, but a new pack version cannot.
>
> I do not care too much about the cost of running merge on a large
> working tree. Of course it's better to make our optimizations as
> generally applicable as possible, but there is a lot of other work going
> on in a merge. The really painful, noticeable, repetitive bits right now
> are:
>
> 1. Running git-prune.
>
> 2. Creating a pack from git-upload-pack.
>
> Which are both just reachability problems. Something like "git log --
> <pathspec>" would also be helped by packv4-ish tree access patterns,
> though, but not by reachability bitmaps. And that may be something
> worth caring about.
blame would also benefit from a packv4-ish tree.
But upload-pack and prune can make massive improvements through
bitmaps, while packv4-ish tree would be only a marginal incremental
improvement. In the case of upload-pack having a bitmap gives you much
more knowledge of the remote's have set, and allows making a smaller
pack, in a lot less time, and a smaller server memory footprint. Now
that we have implemented bitmaps in our servers, I can say you really
don't want to ignore the gains we can get from them. packv4-ish tree
might help some other workloads, but bitmaps provide a better solution
to these reachability problems than anything else we know.
>> Yes. And if narrow clone ever comes, which needs --objects limited by
>> pathspec, we could just produce extra bitmaps for frequently-used
>> pathspecs and only allow narrow clone with those pathspecs.
>
> I hadn't thought about that. But yeah, because of the optional, external
> nature, there's no reason you couldn't have extra bitmap sets for
> specialized situations.
Right. We still need to redo the JGit patch series to eject the
bitmaps into an extension file. :-(
^ permalink raw reply
* Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
From: Jason Holden @ 2012-12-31 18:22 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20121231T103639-635@post.gmane.org>
On Mon, Dec 31, 2012 at 09:40:19AM +0000, Thomas Ackermann wrote:
> Junio C Hamano <gitster <at> pobox.com> writes:
>
> >
> > Thanks; I just realized that nothing in Documentation/ hierarchy
> > mentions these; they are only mentioned in "A Note from the
> > Maintainer" I send out every once in a while (kept in MaintNotes of
> > 'todo' branch):
> >
>
> Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation?
>
> ---
> Thomas
Putting it in Documentation/ would add one more outlier file (Along w/
SubmittingPatches and CodingGuidelines). Documentation/technical seems
too deep. I've got a patch that incorporates the content into the
existing README, but that seems a bit out of place, as the previous content of
README was primarily pointers to other docs.
What about a README.developers at the toplevel?
^ permalink raw reply
* Re: git filter-branch doesn't dereference annotated tags
From: Junio C Hamano @ 2012-12-31 18:31 UTC (permalink / raw)
To: Grégory Pakosz; +Cc: git
In-Reply-To: <CAC_01E174m_6tDwPKZ5P0BUxnLNWUf9p+VkECFosPTzip0sYsA@mail.gmail.com>
Grégory Pakosz <gpakosz@visionobjects.com> writes:
> 1) either make git-filter-branch dereference annotated tags and do
> the verification itself then use the two arguments version of git
> update-ref
> 2) in the case of an annotated tag, pass another <old value> to git update-ref
>
> Please find below a patch that implements solution 1).
> ...
> echo "Ref '$ref' was deleted"
> - git update-ref -m "filter-branch: delete" -d "$ref" $sha1 ||
> + test $(git rev-parse --verify "$ref^{commit}") = $sha1 && git
> update-ref -m "filter-branch: delete" -d "$ref" ||
Thanks. A few comments.
At the design level. Where does this $sha1 come from in the first
place? If a ref that named the annotated tag was deleted, shouldn't
we arrange things so this part of the code receives the $sha1 of the
tag that corresponds to the $ref so that "update-ref -d" can check
that nobody tampered with the repository while the script was
working?
At the implementation level. When the ref being deleted pointed at
a tree or a blob, the original would have correctly removed it, but
will the updated one?
^ permalink raw reply
* Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
From: Junio C Hamano @ 2012-12-31 18:32 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <loom.20121231T103639-635@post.gmane.org>
Thomas Ackermann <th.acker@arcor.de> writes:
>> Thanks; I just realized that nothing in Documentation/ hierarchy
>> mentions these; they are only mentioned in "A Note from the
>> Maintainer" I send out every once in a while (kept in MaintNotes of
>> 'todo' branch):
>
> Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation?
Perhaps. It started as a living document that discusses the state
of affairs as of the time of posting (there are mentions to "the
most recent such release was ...", etc), and because I wanted to
keep it that way (and also I needed somewhere to keep track of it),
I deliberately kept it outside the source tree.
It is an addendum to howto-maintain-git, and what it covers overlaps
with it, so it will need some clean-ups if we want to go the route
you suggest.
Having said all that, I think it is still a good idea to keep the
occasional "A note from he Maintainer" posting on list, and a
version that needs to rever to another document after losing
overlaps with howto-maintain-git will no longer will be suitable
source for it, so...
^ permalink raw reply
* [PATCH] merge --no-edit: do not add comments meant for "--edit" mode
From: Junio C Hamano @ 2012-12-31 18:33 UTC (permalink / raw)
To: git
The credit lines "By" and "Via" to credit authors and committers for
their contributions on the side branch are meant as a hint to the
integrator to decide whom to mention in the log message text. After
the integrator saves the message in the editor, they are meant to go
away and that is why they are commented out.
When a merge is recorded without editing the generated message,
however, its contents do not go through the normal stripspace()
and these lines are left in the merge.
Stop producing them when we know the merge is going to be recorded
without editing, i.e. when --no-edit is given.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin.h | 3 ++-
builtin/fmt-merge-msg.c | 21 ++++++++++++++-------
builtin/merge.c | 1 +
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/builtin.h b/builtin.h
index dffb34e..3ad8d19 100644
--- a/builtin.h
+++ b/builtin.h
@@ -16,7 +16,8 @@ extern const char git_more_info_string[];
extern void prune_packed_objects(int);
struct fmt_merge_msg_opts {
- unsigned add_title:1;
+ unsigned add_title:1,
+ credit_people:1;
int shortlog_len;
};
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 2c4d435..dd1f363 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -232,8 +232,9 @@ static void record_person(int which, struct string_list *people,
{
char *name_buf, *name, *name_end;
struct string_list_item *elem;
- const char *field = (which == 'a') ? "\nauthor " : "\ncommitter ";
+ const char *field;
+ field = (which == 'a') ? "\nauthor " : "\ncommitter ";
name = strstr(commit->buffer, field);
if (!name)
return;
@@ -323,7 +324,8 @@ static void add_people_info(struct strbuf *out,
static void shortlog(const char *name,
struct origin_data *origin_data,
struct commit *head,
- struct rev_info *rev, int limit,
+ struct rev_info *rev,
+ struct fmt_merge_msg_opts *opts,
struct strbuf *out)
{
int i, count = 0;
@@ -335,6 +337,7 @@ static void shortlog(const char *name,
int flags = UNINTERESTING | TREESAME | SEEN | SHOWN | ADDED;
struct strbuf sb = STRBUF_INIT;
const unsigned char *sha1 = origin_data->sha1;
+ int limit = opts->shortlog_len;
branch = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
if (!branch || branch->type != OBJ_COMMIT)
@@ -351,13 +354,15 @@ static void shortlog(const char *name,
if (commit->parents && commit->parents->next) {
/* do not list a merge but count committer */
- record_person('c', &committers, commit);
+ if (opts->credit_people)
+ record_person('c', &committers, commit);
continue;
}
- if (!count)
+ if (!count && opts->credit_people)
/* the 'tip' committer */
record_person('c', &committers, commit);
- record_person('a', &authors, commit);
+ if (opts->credit_people)
+ record_person('a', &authors, commit);
count++;
if (subjects.nr > limit)
continue;
@@ -372,7 +377,8 @@ static void shortlog(const char *name,
string_list_append(&subjects, strbuf_detach(&sb, NULL));
}
- add_people_info(out, &authors, &committers);
+ if (opts->credit_people)
+ add_people_info(out, &authors, &committers);
if (count > limit)
strbuf_addf(out, "\n* %s: (%d commits)\n", name, count);
else
@@ -635,7 +641,7 @@ int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
for (i = 0; i < origins.nr; i++)
shortlog(origins.items[i].string,
origins.items[i].util,
- head, &rev, opts->shortlog_len, out);
+ head, &rev, opts, out);
}
strbuf_complete_line(out);
@@ -690,6 +696,7 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
memset(&opts, 0, sizeof(opts));
opts.add_title = !message;
+ opts.credit_people = 1;
opts.shortlog_len = shortlog_len;
ret = fmt_merge_msg(&input, &output, &opts);
diff --git a/builtin/merge.c b/builtin/merge.c
index e81fde6..c5d3551 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1324,6 +1324,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
memset(&opts, 0, sizeof(opts));
opts.add_title = !have_message;
opts.shortlog_len = shortlog_len;
+ opts.credit_people = (0 < option_edit);
fmt_merge_msg(&merge_names, &merge_msg, &opts);
if (merge_msg.len)
--
1.8.1.rc3.236.g505e3af
^ permalink raw reply related
* Re: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk
From: Jason Holden @ 2012-12-31 18:46 UTC (permalink / raw)
To: git
In-Reply-To: <20121231042736.GA14921@iris.ozlabs.ibm.com>
On Mon, Dec 31, 2012 at 03:27:36PM +1100, Paul Mackerras wrote:
>
> Thanks for the patch. I have a couple of comments about it. First,
> the exec command waits for the process to complete, which means that
> the initial gitk GUI will be unresponsive until the user quits the
> gitk window showing the merge, which could be quite confusing for the
> user.
Good catch. Adding an ampersand on to the exec looks like it fixes
the unresponsiveness. Any issues with that approach?
>
> Secondly, gitk already has support for showing multiple views of a
> repository, that is, different subsets of the commits. Wouldn't it be
> much better to have your new menu item simply create a new view
> showing the merge, rather than creating a whole new window?
I've found when using this feature that I tend to use it in a stack-like
fashion. I tend to want to "push" a merge-view onto the stack, investigate
that view of history for a bit, then "pop" back to my old view. But
you're correct that you can end up with a lot of windows pretty quick.
Any support for stack-like views in the current gui that I missed?
I've got another feature brewing, similiar to the merge-view, where you can
right-click on a file and a new window pops up with the history of just that
file. I tend to use that feature in a stack-like fashion as well.
Maybe the seperate-window/new-view-in-same-window should be a new user
preference?
^ permalink raw reply
* [PATCH v2 0/2] Add MAINTAINERS file and clarify gui workflows
From: Jason Holden @ 2012-12-31 22:19 UTC (permalink / raw)
To: git; +Cc: gitster, th.acker, paulus, patthoyts, worldhello.net,
Jason Holden
Changes since the initial version:
-Added git-po to the MAINTAINERS file and generalized wording that had been
gui-specific
-Fixup some trailing whitespace warnings
Jason Holden (2):
Add top-level maintainers file with email/canonical repository
information
Provide better guidance for submitting patches against upstream
utilities
Documentation/SubmittingPatches | 11 +++++++++++
MAINTAINERS | 21 +++++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 MAINTAINERS
--
1.8.1.rc3.28.g0ab5d1f
^ permalink raw reply
* [PATCH v2 1/2] Add top-level maintainers file with email/canonical repository information
From: Jason Holden @ 2012-12-31 22:19 UTC (permalink / raw)
To: git; +Cc: gitster, th.acker, paulus, patthoyts, worldhello.net,
Jason Holden
In-Reply-To: <1356992375-11116-1-git-send-email-jason.k.holden.swdev@gmail.com>
Certain parts of git have a semi-formalized workflow for
incoming patches. This file documents the maintainers, their area of
specialization, their email address, and their canonical repository against
which patches should be submitted.
Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
---
MAINTAINERS | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 0000000..c3a96b4
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,21 @@
+Core Git/Overall Maintainer:
+ Junio C Hamano <gitster@pobox.com>
+ git://git.kernel.org/pub/scm/git/git.git
+
+
+Certain utilities packaged with git (git-gui, gitk, and git-po) are maintained
+upstream of the core git repository. Their contact information
+and canonical repositories are below. Patches to improve these utilities
+should be made against the tree's referenced below
+
+gitk:
+ Paul Mackerras <paulus@samba.org>
+ git://ozlabs.org/~paulus/gitk
+
+git-gui:
+ Pat Thoyts <patthoyts@users.sourceforge.net>
+ git://repo.or.cz/git-gui
+
+git-po:
+ Jiang Xin <worldhello.net@gmail.com>
+ https://github.com/git-l10n/git-po/
--
1.8.1.rc3.28.g0ab5d1f
^ permalink raw reply related
* [PATCH v2 2/2] Provide better guidance for submitting patches against upstream utilities
From: Jason Holden @ 2012-12-31 22:19 UTC (permalink / raw)
To: git; +Cc: gitster, th.acker, paulus, patthoyts, worldhello.net,
Jason Holden
In-Reply-To: <1356992375-11116-1-git-send-email-jason.k.holden.swdev@gmail.com>
git-gui, gitk, and git-po are maintained upstream of git.
Document this, and the procedure for submitting patches to these tools
Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
---
Documentation/SubmittingPatches | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 75935d5..30b95a8 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -58,6 +58,17 @@ Checklist (and a short version for the impatient):
please test it first by sending email to yourself.
- see below for instructions specific to your mailer
+ Improving upstream utilities (gitk, git-gui, git-po)
+ - gitk, git-gui, and git-po are maintained upstream of Git
+ despite being included in Git's git repository
+ - Patches should be made against the upstream gui repository,
+ and not against the version in Git's git repository
+ - The resulting patch should still be emailed for review
+ to the git mailing list (git@vger.kernel.org), cc'ing the
+ applicable gui maintainer
+ - Please see the MAINTAINER's file for the gui maintainer's contact
+ information and canonical repository location
+
Long version:
I started reading over the SubmittingPatches document for Linux
--
1.8.1.rc3.28.g0ab5d1f
^ permalink raw reply related
* Re: [PATCH v2 1/2] Add top-level maintainers file with email/canonical repository information
From: Jacob Helwig @ 2012-12-31 22:25 UTC (permalink / raw)
To: Jason Holden; +Cc: git, gitster, th.acker, paulus, patthoyts, worldhello.net
In-Reply-To: <1356992375-11116-2-git-send-email-jason.k.holden.swdev@gmail.com>
One minor grammar nit below.
On Mon, Dec 31, 2012 at 2:19 PM, Jason Holden
<jason.k.holden.swdev@gmail.com> wrote:
> Certain parts of git have a semi-formalized workflow for
> incoming patches. This file documents the maintainers, their area of
> specialization, their email address, and their canonical repository against
> which patches should be submitted.
>
> Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
> ---
> MAINTAINERS | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 MAINTAINERS
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> new file mode 100644
> index 0000000..c3a96b4
> --- /dev/null
> +++ b/MAINTAINERS
> @@ -0,0 +1,21 @@
> +Core Git/Overall Maintainer:
> + Junio C Hamano <gitster@pobox.com>
> + git://git.kernel.org/pub/scm/git/git.git
> +
> +
> +Certain utilities packaged with git (git-gui, gitk, and git-po) are maintained
> +upstream of the core git repository. Their contact information
> +and canonical repositories are below. Patches to improve these utilities
> +should be made against the tree's referenced below
Should be "trees", not "tree's" (plural vs. possessive/contraction).
> +
> +gitk:
> + Paul Mackerras <paulus@samba.org>
> + git://ozlabs.org/~paulus/gitk
> +
> +git-gui:
> + Pat Thoyts <patthoyts@users.sourceforge.net>
> + git://repo.or.cz/git-gui
> +
> +git-po:
> + Jiang Xin <worldhello.net@gmail.com>
> + https://github.com/git-l10n/git-po/
> --
> 1.8.1.rc3.28.g0ab5d1f
>
--
Jacob Helwig
http://technosorcery.net/about/me
^ permalink raw reply
* Re: Bug/Enhancement: contrib/subtree should ship with manpage
From: greened @ 2012-12-31 23:13 UTC (permalink / raw)
To: Neil; +Cc: git
In-Reply-To: <CANC5J9HSSuc0OchdoVyQKLhXbLapej714LN3pjG=er4BBm0zoA@mail.gmail.com>
Neil <kngspook@gmail.com> writes:
> Actual: git-subtree.1 fails to be generated because my system doesn't ship
> asciidoc and xmlto.
Well, you need those tools to build ANY git documentation. I just ran a
test to build git-subtree and its documentation and it went just fine.
This is not a bug.
-Dave
^ permalink raw reply
* Re: [PATCH] subtree.sh: Use raw subject and body modifier "%B" instead of "%s%n%n%b"
From: greened @ 2012-12-31 22:57 UTC (permalink / raw)
To: Techlive Zheng; +Cc: git, gitster, apenwarr
In-Reply-To: <87zk5pdn43.fsf@waller.obbligato.org>
greened@obbligato.org writes:
> Techlive Zheng <techlivezheng@gmail.com> writes:
>
>> "%s%n%n%b" is not always equal to "%B". If the commit msg does not have
>> a body, this will append an extra new-line character to the msg title
>> which would cause the splited commit has a new sha1 hash. In most cases,
>> this does not matter, but for a project which did not merged using this
>> script initially, the 'split' command would not genereate the same
>> commits as the orginal which may cause conflicts.
>>
>> Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
>> ---
>> contrib/subtree/git-subtree.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
>> index 920c664..5598210 100755
>> --- a/contrib/subtree/git-subtree.sh
>> +++ b/contrib/subtree/git-subtree.sh
>> @@ -296,7 +296,7 @@ copy_commit()
>> # We're going to set some environment vars here, so
>> # do it in a subshell to get rid of them safely later
>> debug copy_commit "{$1}" "{$2}" "{$3}"
>> - git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' "$1" |
>> + git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' "$1" |
>> (
>> read GIT_AUTHOR_NAME
>> read GIT_AUTHOR_EMAIL
>
> This looks good to me. I assume this passes all the tests. Can you add
> a test for this bug so we don't regress? Junio, I am good with this
> patch as soon as we get a test for the problem.
I've applied this patch to my working copy but I'm not finding that I
can recreate the original problem when the patch is disabled.
I assumed the scenario you're trying to fix is:
- Make some commit C to project A with a one-line message
- work, commit, work...
- Add project A as a subproject
- work, commit, work...
- Split project A off into a separate repository
After this, commit C with the one-line message in the split-off projet
should have the same hash it had before project A was incorporated as a
subproject.
As I understad it, you saw the post-split commit having a different
hash?
Is that right? I am not seeing that problem even without your patch.
I want to make sure I understand what the problem is so I can test for
it.
Thanks!
-David
^ permalink raw reply
* Re: [PATCH] Add --unannotate option to git-subtree
From: greened @ 2012-12-31 23:19 UTC (permalink / raw)
To: Herman van Rink; +Cc: James Nylen, git
In-Reply-To: <5082FC72.4000608@initfour.nl>
Herman van Rink <rink@initfour.nl> writes:
>> Has anybody looked at this?
>>
>> It has been very useful for me.
I am looking at it now.
> The version of subtree in contrib is rather out-dated unfortunately.
It is the official version. What's missing? You have a bunch of
changes that need rework to include into "mainline" but other than that
I am not aware of any major missing pieces. If there are such changes I
would very much like to get them integrated
> Your patch looks interesting though. I can see how this could be useful.
> I've collected a bunch of patches in
> https://github.com/helmo/git/tree/subtree-updates
I hope you will submit your changes for inclusion. Again, I'm not a
gatekeeper but I do want the patches to have proper testcases and
integrate into contrib/subtree.
-David
^ permalink raw reply
* Re: [PATCH] gitk: Replaced "green" with "#00FF00".
From: Paul Mackerras @ 2012-12-31 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Hofmann, git
In-Reply-To: <7v623nmmly.fsf@alter.siamese.dyndns.org>
On Thu, Dec 27, 2012 at 09:27:37AM -0800, Junio C Hamano wrote:
> Peter Hofmann <git-dev@uninformativ.de> writes:
>
> > Subject: Re: [PATCH] gitk: Replaced "green" with "#00FF00".
>
> > gitk looks pretty awkward with Tk 8.6. "green" is simply too dark now
> > because it has changed from "#00FF00" to "#008000".
>
> Your observation "awkward" is somewhat subjective and I am hesitant
> to recommend this change without a better justification. Given the
> reasoning behind the change Tcl/Tk people made, I wouldn't be
> surprised if people coming from webapp world view the "green" color
> rendered by updated Tcl/Tk more natural.
Given that "green" is used as the background color in some places,
e.g. for the boxes containing the names of heads, and that the general
scheme is dark foreground on light background, I agree that #008000 is
too dark in those places.
> Besides, if we are declaring with this patch that we will stick to
> X11 colors and will not adopt W3C colors, the patch shouldn't update
> only "green", but set all the other colors in stone, no? "purple",
> for example, is also different between X11 and W3C.
Purple is only used for octopus merges. I'd like to think of a better
way to use color in representing octopus merges if possible.
> > One could also use "lime" instead of "#00FF00" but that would break
> > compatibility with older versions of Tk.
>
> A better solution might be to make these colors customizable.
Indeed. Some people prefer to have all their windows to have light
foregrounds on dark backgrounds, so they would also benefit from
having more of the colors customizable.
Paul.
^ permalink raw reply
* Re: [PATCH v2 2/2] Provide better guidance for submitting patches against upstream utilities
From: Junio C Hamano @ 2012-12-31 23:39 UTC (permalink / raw)
To: Jason Holden; +Cc: git, th.acker, paulus, patthoyts, worldhello.net
In-Reply-To: <1356992375-11116-3-git-send-email-jason.k.holden.swdev@gmail.com>
Jason Holden <jason.k.holden.swdev@gmail.com> writes:
> git-gui, gitk, and git-po are maintained upstream of git.
> Document this, and the procedure for submitting patches to these tools
>
> Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
> ---
> Documentation/SubmittingPatches | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 75935d5..30b95a8 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -58,6 +58,17 @@ Checklist (and a short version for the impatient):
> please test it first by sending email to yourself.
> - see below for instructions specific to your mailer
>
> + Improving upstream utilities (gitk, git-gui, git-po)
> + - gitk, git-gui, and git-po are maintained upstream of Git
> + despite being included in Git's git repository
> + - Patches should be made against the upstream gui repository,
GUI?
> + and not against the version in Git's git repository
> + - The resulting patch should still be emailed for review
> + to the git mailing list (git@vger.kernel.org), cc'ing the
> + applicable gui maintainer
> + - Please see the MAINTAINER's file for the gui maintainer's contact
GUI?
Perhaps "parts with sub-maintainers' with their own repositories".
In any case, I think it is probably much better not to add a new
file at the top of the tree only to hold twenty-or-so
lines. Instead, add the contents as a footnote to this file and
refer to it from here.
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1
From: Junio C Hamano @ 2013-01-01 0:26 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest feature release Git v1.8.1 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
ac8dced9c3232c0ec6a88d04600a4d0eaf2ba4e3 git-1.8.1.tar.gz
a256fc56c89dc3c8d58b81a2c02dc89299f1f29b git-htmldocs-1.8.1.tar.gz
a9ab9de3fa1781bb5009f5a215374dfc694feb30 git-manpages-1.8.1.tar.gz
Also the following public repositories all have a copy of the v1.8.1
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.1 Release Notes
========================
Backward compatibility notes
----------------------------
In the next major release (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this, and
"git push" will warn about the upcoming change until you set this
variable in this release.
"git branch --set-upstream" is deprecated and may be removed in a
relatively distant future. "git branch [-u|--set-upstream-to]" has
been introduced with a saner order of arguments to replace it.
Updates since v1.8.0
--------------------
UI, Workflows & Features
* Command-line completion scripts for tcsh and zsh have been added.
* "git-prompt" scriptlet (in contrib/completion) can be told to paint
pieces of the hints in the prompt string in colors.
* Some documentation pages that used to ship only in the plain text
format are now formatted in HTML as well.
* We used to have a workaround for a bug in ancient "less" that
causes it to exit without any output when the terminal is resized.
The bug has been fixed in "less" version 406 (June 2007), and the
workaround has been removed in this release.
* When "git checkout" checks out a branch, it tells the user how far
behind (or ahead) the new branch is relative to the remote tracking
branch it builds upon. The message now also advises how to sync
them up by pushing or pulling. This can be disabled with the
advice.statusHints configuration variable.
* "git config --get" used to diagnose presence of multiple
definitions of the same variable in the same configuration file as
an error, but it now applies the "last one wins" rule used by the
internal configuration logic. Strictly speaking, this may be an
API regression but it is expected that nobody will notice it in
practice.
* A new configuration variable "diff.context" can be used to
give the default number of context lines in the patch output, to
override the hardcoded default of 3 lines.
* "git format-patch" learned the "--notes=<ref>" option to give
notes for the commit after the three-dash lines in its output.
* "git log -p -S<string>" now looks for the <string> after applying
the textconv filter (if defined); earlier it inspected the contents
of the blobs without filtering.
* "git log --grep=<pcre>" learned to honor the "grep.patterntype"
configuration set to "perl".
* "git replace -d <object>" now interprets <object> as an extended
SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex
object name.
* "git rm $submodule" used to punt on removing a submodule working
tree to avoid losing the repository embedded in it. Because
recent git uses a mechanism to separate the submodule repository
from the submodule working tree, "git rm" learned to detect this
case and removes the submodule working tree when it is safe to do so.
* "git send-email" used to prompt for the sender address, even when
the committer identity is well specified (e.g. via user.name and
user.email configuration variables). The command no longer gives
this prompt when not necessary.
* "git send-email" did not allow non-address garbage strings to
appear after addresses on Cc: lines in the patch files (and when
told to pick them up to find more recipients), e.g.
Cc: Stable Kernel <stable@k.org> # for v3.2 and up
The command now strips " # for v3.2 and up" part before adding the
remainder of this line to the list of recipients.
* "git submodule add" learned to add a new submodule at the same
path as the path where an unrelated submodule was bound to in an
existing revision via the "--name" option.
* "git submodule sync" learned the "--recursive" option.
* "diff.submodule" configuration variable can be used to give custom
default value to the "git diff --submodule" option.
* "git symbolic-ref" learned the "-d $symref" option to delete the
named symbolic ref, which is more intuitive way to spell it than
"update-ref -d --no-deref $symref".
Foreign Interface
* "git cvsimport" can be told to record timezones (other than GMT)
per-author via its author info file.
* The remote helper interface to interact with subversion
repositories (one of the GSoC 2012 projects) has been merged.
* A new remote-helper interface for Mercurial has been added to
contrib/remote-helpers.
* The documentation for git(1) was pointing at a page at an external
site for the list of authors that no longer existed. The link has
been updated to point at an alternative site.
Performance, Internal Implementation, etc.
* Compilation on Cygwin with newer header files are supported now.
* A couple of low-level implementation updates on MinGW.
* The logic to generate the initial advertisement from "upload-pack"
(i.e. what is invoked by "git fetch" on the other side of the
connection) to list what refs are available in the repository has
been optimized.
* The logic to find set of attributes that match a given path has
been optimized.
* Use preloadindex in "git diff-index" and "git update-index", which
has a nice speedup on systems with slow stat calls (and even on
Linux).
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.0
------------------
Unless otherwise noted, all the fixes since v1.8.0 in the maintenance
track are contained in this release (see release notes to them for
details).
* The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently.
* The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a
BEL output.
* "git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle
it. Work it around by passing a temporary empty file.
* "git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.
* "git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
* A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM
instead.
* Update "remote tracking branch" in the documentation to
"remote-tracking branch".
* "git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.
* The refs/replace hierarchy was not mentioned in the
repository-layout docs.
* Various rfc2047 quoting issues around a non-ASCII name on the
From: line in the output from format-patch have been corrected.
* Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptor to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
A workaround has been added for this.
* For a fetch refspec (or the result of applying wildcard on one),
we always want the RHS to map to something inside "refs/"
hierarchy, but the logic to check it was not exactly right.
(merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint).
* "git diff -G<pattern>" did not honor textconv filter when looking
for changes.
* Some HTTP servers ask for auth only during the actual packing phase
(not in ls-remote phase); this is not really a recommended
configuration, but the clients used to fail to authenticate with
such servers.
(merge 2e736fd jk/maint-http-half-auth-fetch later to maint).
* "git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
* Syntax highlighting in "gitweb" was not quite working.
* RSS feed from "gitweb" had a xss hole in its title output.
* "git config --path $key" segfaulted on "[section] key" (a boolean
"true" spelled without "=", not "[section] key = true").
* "git checkout -b foo" while on an unborn branch did not say
"Switched to a new branch 'foo'" like other cases.
* Various codepaths have workaround for a common misconfiguration to
spell "UTF-8" as "utf8", but it was not used uniformly. Most
notably, mailinfo (which is used by "git am") lacked this support.
* We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* When "--stat-count" hides a diffstat for binary contents, the total
number of added and removed lines at the bottom was computed
incorrectly.
* When "--stat-count" hides a diffstat for unmerged paths, the total
number of affected files at the bottom of the "diff --stat" output
was computed incorrectly.
* "diff --shortstat" miscounted the total number of affected files
when there were unmerged paths.
* "update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
----------------------------------------------------------------
Changes since v1.8.1-rc3 are as follows:
Junio C Hamano (3):
git(1): show link to contributor summary page
Git 1.8.0.3
Git 1.8.1
Max Horn (1):
git-remote-helpers.txt: document invocation before input format
Ramkumar Ramachandra (1):
Documentation: move diff.wordRegex from config.txt to diff-config.txt
Sebastian Leske (4):
git-svn: Document branches with at-sign(@).
git-svn: Recommend use of structure options.
git-svn: Expand documentation for --follow-parent
git-svn: Note about tags.
Simon Oosthoek (1):
make __git_ps1 accept a third parameter in pcmode
Thomas Ackermann (1):
Sort howto documents in howto-index.txt
^ permalink raw reply
* What's cooking in git.git (Dec 2012, #08; Mon, 31)
From: Junio C Hamano @ 2013-01-01 0:26 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch is at 1.8.1; the tip of 'next' will
be rewound soonish to reorder topics that are already well cooked
during the pre-release freeze earlier than the others so that they
can orderly be merged to 'master' after the dust settles, probably
towards the end of this week.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* so/prompt-command (2012-12-26) 1 commit
(merged to 'next' on 2012-12-26 at 27c5683)
+ make __git_ps1 accept a third parameter in pcmode
Gives the same degree of customizability to the new prompt command
mode users as the command substitution mode has.
--------------------------------------------------
[New Topics]
* ap/status-ignored-in-ignored-directory (2012-12-26) 1 commit
- wt-status: Show ignored files in untracked dirs
A topic still in flux; will be redone.
* ta/remove-stale-translated-tut (2012-12-27) 1 commit
- Remove Documentation/pt_BR/gittutorial.txt
Remove a translation of a document that was left stale.
* er/stop-recommending-parsecvs (2012-12-28) 1 commit
- Remove the suggestion to use parsecvs, which is currently broken.
Stop recommending a defunct third-party software.
* as/test-name-alias-uniquely (2012-12-28) 1 commit
- Use longer alias names in subdirectory tests
A few short-and-bland aliases used in the tests were interfering
with git-custom command in user's $PATH.
* jc/maint-fmt-merge-msg-no-edit-lose-credit (2012-12-28) 1 commit
- merge --no-edit: do not credit people involved in the side branch
Stop spending cycles to compute information to be placed on
commented lines in "merge --no-edit".
--------------------------------------------------
[Stalled]
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* fc/remote-bzr (2012-12-13) 10 commits
- (fixup) test-bzr.sh: fix multi-line string assignment
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree upon pushing
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr (v3). With minor fixes, this may be ready
for 'next'.
* mo/cvs-server-updates (2012-12-09) 18 commits
- t9402: Use TABs for indentation
- t9402: Rename check.cvsCount and check.list
- t9402: Simplify git ls-tree
- t9402: Add missing &&; Code style
- t9402: No space after IO-redirection
- t9402: Dont use test_must_fail cvs
- t9402: improve check_end_tree() and check_end_full_tree()
- t9402: sed -i is not portable
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review and Ack (or Nack) from people involved in the remote
helper interface for this to move forward.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-11-26) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* as/check-ignore (2012-12-28) 19 commits
- Add git-check-ignore sub-command
- setup.c: document get_pathspec()
- pathspec.c: extract new validate_path() for reuse
- pathspec.c: move reusable code from builtin/add.c
- add.c: remove unused argument from validate_pathspec()
- add.c: refactor treat_gitlinks()
- dir.c: provide clear_directory() for reclaiming dir_struct memory
- dir.c: keep track of where patterns came from
- dir.c: use a single struct exclude_list per source of excludes
- dir.c: rename free_excludes() to clear_exclude_list()
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
- Improve documentation and comments regarding directory traversal API
- api-directory-listing.txt: update to match code
Rerolled. The early parts looked mostly fine; we may want to split
this into two topics and have the early half progress earlier.
* jc/format-patch-reroll (2012-12-22) 7 commits
- format-patch: add --reroll-count=$N option
- get_patch_filename(): split into two functions
- get_patch_filename(): drop "just-numbers" hack
- get_patch_filename(): simplify function signature
- builtin/log.c: stop using global patch_suffix
- builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
- builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
Needs tests and documentation updates.
* ms/subtree-fixlets (2012-12-22) 2 commits
(merged to 'next' on 2012-12-26 at 1cb26eb)
+ git-subtree: fix typo in manpage
+ git-subtree: ignore git-subtree executable
Will cook in 'next'.
* mz/pick-unborn (2012-12-23) 2 commits
- learn to pick/revert into unborn branch
- tests: move test_cmp_rev to test-lib-functions
Will merge to 'next'.
* nd/retire-fnmatch (2012-12-22) 8 commits
- wildmatch: advance faster in <asterisk> + <literal> patterns
- wildmatch: make a special case for "*/" with FNM_PATHNAME
- Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
- test-wildmatch: add "perf" command to compare wildmatch and fnmatch
- wildmatch: support "no FNM_PATHNAME" mode
- wildmatch: make dowild() take arbitrary flags
- wildmatch: rename constants and update prototype
- compat/fnmatch: respect NO_FNMATCH* even on glibc
(this branch uses nd/wildmatch.)
Replace our use of fnmatch(3) with a more feature-rich wildmatch.
* jc/test-cvs-no-init-in-existing-dir (2012-12-24) 1 commit
(merged to 'next' on 2012-12-26 at 3b93f37)
+ t9200: let "cvs init" create the test repository
Will cook in 'next'.
* os/gitweb-highlight-uncaptured (2012-12-26) 1 commit
- gitweb: fix error when highlight is enabled
Will merge to 'next'.
* jc/merge-blobs (2012-12-26) 5 commits
- merge-tree: fix d/f conflicts
- merge-tree: add comments to clarify what these functions are doing
- merge-tree: lose unused "resolve_directories"
- merge-tree: lose unused "flags" from merge_list
- Which merge_file() function do you mean?
A beginning of a new merge strategy based on the disused merge-tree
proof-of-concept code.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
(merged to 'next' on 2012-12-26 at 2ff59ab)
+ graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
* jc/mkstemp-more-careful-error-reporting (2012-12-18) 1 commit
(merged to 'next' on 2012-12-22 at 18cdaf0)
+ xmkstemp(): avoid showing truncated template more carefully
An earlier patch to save original arguments to mkstemp() away and
use it to report what filename we failed to create incorrectly used
the buffer munged by failing mkstemp().
* jc/maint-test-portability (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at daeed53)
+ t4014: fix arguments to grep
+ t9502: do not assume GNU tar
+ t0200: "locale" may not exist
(this branch is used by jc/test-portability.)
Minor test fixes noticed while running our tests on OpenBSD 5.2,
applicable to 'maint'.
* jc/test-portability (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at 123041b)
+ t9020: use configured Python to run the test helper
+ t3600: Avoid "cp -a", which is a GNUism
+ Merge branch 'jc/maint-test-portability' into 'jc/test-portability'
(this branch uses jc/maint-test-portability.)
The remainder of jc/maint-test-portability, applicable to 'master'.
* jc/maint-fnmatch-old-style-definition (2012-12-19) 1 commit
(merged to 'next' on 2012-12-22 at 540df2c)
+ compat/fnmatch: update old-style definition to ANSI
Update old-style function definition "int foo(bar) int bar; {}"
to "int foo(int bar) {}".
* jk/pathspec-literal (2012-12-19) 1 commit
(merged to 'next' on 2012-12-22 at c794bd6)
+ add global --literal-pathspecs option
Allow scripts to feed literal paths to commands that take
pathspecs, by disabling wildcard globbing.
* da/p4merge-mktemp (2012-12-26) 1 commit
(merged to 'next' on 2012-12-26 at 036938a)
+ mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
Create an empty file in $TMPDIR instead of using an empty file in
the local directory.
* er/python-version-requirements (2012-12-28) 1 commit
- Add checks to Python scripts for version dependencies.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
* mz/oneway-merge-wo-u-no-lstat (2012-12-20) 1 commit
(merged to 'next' on 2012-12-22 at 87bd30e)
+ oneway_merge(): only lstat() when told to update worktree
Optimize "read-tree -m <tree-ish>" without "-u".
* jk/repack-ref-racefix (2012-12-21) 1 commit
(merged to 'next' on 2012-12-22 at 03e1ca9)
+ refs: do not use cached refs in repack_without_ref
Race-fix for pack-refs running in parallel to ref creation.
* rb/http-cert-cred-no-username-prompt (2012-12-21) 1 commit
(merged to 'next' on 2012-12-22 at 9fc28ed)
+ http.c: Avoid username prompt for certifcate credentials
It is wrong to ask for username if the authentication is done by
certificate identity.
* wk/submodule-update-remote (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at 7ddf897)
+ submodule add: If --branch is given, record it in .gitmodules
+ submodule update: add --remote for submodule's upstream changes
+ submodule: add get_submodule_config helper funtion
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.
* cc/no-gitk-build-dependency (2012-12-18) 3 commits
(merged to 'next' on 2012-12-22 at da7b2cf)
+ Makefile: replace "echo 1>..." with "echo >..."
+ Makefile: detect when PYTHON_PATH changes
+ Makefile: remove tracking of TCLTK_PATH
Remove leftover bits from an earlier change to move gitk in its own
subdirectory. Reimplementing the dependency tracking rules needs
to be done in gitk history separately.
* jc/format-color-auto (2012-12-17) 2 commits
(merged to 'next' on 2012-12-18 at 5aaac94)
+ log --format: teach %C(auto,black) to respect color config
+ t6006: clean up whitespace
Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
not color its output when writing to a non-terminal.
Will cook in 'next'.
* ss/svn-prompt (2012-12-17) 3 commits
(merged to 'next' on 2012-12-26 at 1012ae2)
+ git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
+ perl/Git.pm: Honor SSH_ASKPASS as fallback if GIT_ASKPASS is not set
+ git-svn, perl/Git.pm: add central method for prompting passwords
Tweak the way "git svn" asks for password to be in line with the
rest of the system, so that the same SSH/GIT_ASKPASS can be used.
* zk/clean-report-failure (2012-12-17) 1 commit
- git-clean: Display more accurate delete messages
"git clean" states what it is going to remove and then goes on to
remove it, but sometimes it only discovers things that cannot be
removed after recursing into a directory, which makes the output
confusing and even wrong.
Expecting a reroll.
* mp/complete-paths (2012-12-21) 1 commit
- git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
Waiting for area-experts' review.
* ja/directory-attrs (2012-12-17) 1 commit
(merged to 'next' on 2012-12-17 at ced8e73)
+ Add directory pattern matching to attributes
The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does.
Will cook in 'next'.
* jk/mailmap-from-blob (2012-12-13) 5 commits
(merged to 'next' on 2012-12-17 at 14b7cdc)
+ mailmap: default mailmap.blob in bare repositories
+ mailmap: fix some documentation loose-ends for mailmap.blob
+ mailmap: clean up read_mailmap error handling
+ mailmap: support reading mailmap from blobs
+ mailmap: refactor mailmap parsing for non-file sources
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
Will cook in 'next'.
* dm/port (2012-12-19) 4 commits
(merged to 'next' on 2012-12-22 at 8adc198)
+ git-compat-util.h: do not #include <sys/param.h> by default
+ Generalize the inclusion of strings.h
+ Detect when the passwd struct is missing pw_gecos
+ Support builds when sys/param.h is missing
(this branch is used by mk/qnx.)
Add a few more knobs for new platform ports can tweak.
* jk/complete-commit-c (2012-12-15) 1 commit
(merged to 'next' on 2012-12-18 at 75b5f21)
+ completion: complete refs for "git commit -c"
Complete "git commmit -c foo<TAB>" into a refname that begins with
"foo".
Will cook in 'next'.
* jk/error-const-return (2012-12-15) 2 commits
(merged to 'next' on 2012-12-22 at bf2b1cd)
+ silence some -Wuninitialized false positives
+ make error()'s constant return value more visible
Help compilers' flow analysis by making it more explicit that
error() always returns -1, to reduce false "variable used
uninitialized" warnings. Looks somewhat ugly but not too much.
* mk/qnx (2012-12-19) 2 commits
(merged to 'next' on 2012-12-22 at 0473197)
+ Port to QNX
+ Make lock local to fetch_pack
(this branch uses dm/port.)
Port to QNX; we may want to rebase this on top of dm/port topic as
it also wants to use the HAVE_STRINGS_H mechanism it introduces.
* as/test-tweaks (2012-12-20) 7 commits
(merged to 'next' on 2012-12-22 at 7312c6c)
+ tests: paint unexpectedly fixed known breakages in bold red
+ tests: test the test framework more thoroughly
+ tests: refactor mechanics of testing in a sub test-lib
+ tests: change info messages from yellow/brown to cyan
+ tests: paint skipped tests in blue
+ tests: paint known breakages in yellow
+ tests: test number comes first in 'not ok $count - $message'
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
* sp/shortlog-missing-lf (2012-12-11) 2 commits
(merged to 'next' on 2012-12-11 at 64b8429)
+ strbuf_add_wrapped*(): Remove unused return value
+ shortlog: fix wrapping lines of wraplen
When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed to
add a newline after such a line.
Will cook in 'next'.
* ap/log-mailmap (2012-12-27) 10 commits
- log --use-mailmap: optimize for cases without --author/--committer search
- log: add log.mailmap configuration option
- log: grep author/committer using mailmap
- test: Add test for --use-mailmap option
- log: Add --use-mailmap option
- pretty: Use mailmap to display username and email
- mailmap: Add mailmap structure to rev_info and pp
- mailmap: Simplify map_user() interface
- mailmap: Remove buffer length limit in map_user
- Use split_ident_line to parse author and committer
(this branch is used by jc/mailmap.)
Clean up various codepaths around mailmap and teach the "log"
machinery to use it.
Will merge to 'next'.
* jc/fetch-ignore-symref (2012-12-11) 1 commit
(merged to 'next' on 2012-12-17 at 370e2c8)
+ fetch: ignore wildcarded refspecs that update local symbolic refs
Avoid false error from an attempt to update local symbolic ref via
fetch.
Will cook in 'next'.
* md/gitweb-sort-by-age (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at 9f39410)
+ gitweb: Sort projects with undefined ages last
Gitweb showed repositories without any commit at the top in its
age-sorted view, in which the users are interested in looking at
active projects; sorting them at the bottom makes it more useful.
Will cook in 'next'.
* ss/nedmalloc-compilation (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at c1f0d7f)
+ nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2
Will cook in 'next'.
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
(merged to 'next' on 2012-12-11 at 6659fdc)
+ sh-setup: work around "unset IFS" bug in some shells
Will cook in 'next'.
* jc/same-encoding (2012-12-10) 1 commit
(merged to 'next' on 2012-12-17 at 86b41c7)
+ format_commit_message(): simplify calls to logmsg_reencode()
Finishing touches to the series to unify "Do we need to reencode
between these two encodings?" logic.
Will cook in 'next'.
* nd/invalidate-i-t-a-cache-tree (2012-12-15) 4 commits
(merged to 'next' on 2012-12-18 at 33e4488)
+ cache-tree: invalidate i-t-a paths after generating trees
+ cache-tree: fix writing cache-tree when CE_REMOVE is present
+ cache-tree: replace "for" loops in update_one with "while" loops
+ cache-tree: remove dead i-t-a code in verify_cache()
Writing out a tree object when you still have intent-to-add entries
in the index left an incorrect cache-tree data there.
Will cook in 'next'.
* jl/submodule-deinit (2012-12-04) 1 commit
(merged to 'next' on 2012-12-07 at ea772f0)
+ submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Will cook in 'next'.
* pf/editor-ignore-sigint (2012-12-02) 5 commits
(merged to 'next' on 2012-12-07 at 6b04419)
+ launch_editor: propagate signals from editor to git
+ run-command: do not warn about child death from terminal
+ launch_editor: ignore terminal signals while editor has control
+ launch_editor: refactor to use start/finish_command
+ run-command: drop silent_exec_failure arg from wait_or_whine
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Will cook in 'next'.
* bc/append-signed-off-by (2012-11-26) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a re-roll after a review.
* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
(merged to 'next' on 2012-12-03 at d677090)
+ wrap_in_html(): process message in bulk rather than line-by-line
+ wrap_in_html(): use strbuf_addstr_xml_quoted()
+ imap-send: change msg_data from storing (ptr, len) to storing strbuf
+ imap-send: correctly report errors reading from stdin
+ imap-send: store all_msgs as a strbuf
+ lf_to_crlf(): NUL-terminate msg_data::data
+ xml_entities(): use function strbuf_addstr_xml_quoted()
+ Add new function strbuf_add_xml_quoted()
Update imap-send to reuse xml quoting code from http-push codepath,
clean up some code, and fix a small bug.
Will cook in 'next'.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
Will cook in 'next'.
* mh/pthreads-autoconf (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 780600e)
+ configure.ac: fix pthreads detection on Mac OS X
Will cook in 'next'.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT.
Will cook in 'next'.
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
Resurrected from Stalled; the earlier performance fear was
unwarranted.
Will cook in 'next'.
* fc/fast-export-fixes (2012-12-03) 15 commits
(merged to 'next' on 2012-12-03 at f9df523)
+ fast-export: make sure updated refs get updated
+ fast-export: don't handle uninteresting refs
+ fast-export: fix comparison in tests
+ fast-export: trivial cleanup
+ remote-testgit: implement the "done" feature manually
+ remote-testgit: report success after an import
+ remote-testgit: exercise more features
+ remote-testgit: cleanup tests
+ remote-testgit: remove irrelevant test
+ remote-testgit: remove non-local functionality
+ Add new simplified git-remote-testgit
+ Rename git-remote-testgit to git-remote-testpy
+ remote-helpers: fix failure message
+ remote-testgit: fix direction of marks
+ fast-export: avoid importing blob marks
Will cook in 'next'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will cook in 'next'.
* nd/pathspec-wildcard (2012-11-26) 4 commits
(merged to 'next' on 2012-12-03 at eca0fcb)
+ tree_entry_interesting: do basedir compare on wildcard patterns when possible
+ pathspec: apply "*.c" optimization from exclude
+ pathspec: do exact comparison on the leading non-wildcard part
+ pathspec: save the non-wildcard length part
Will cook in 'next'.
* nd/wildmatch (2012-12-15) 15 commits
(merged to 'next' on 2012-12-15 at c734714)
+ t3070: Disable some failing fnmatch tests
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
(this branch is used by nd/retire-fnmatch.)
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* cr/push-force-tag-update (2012-12-03) 10 commits
(merged to 'next' on 2012-12-04 at af2e3a9)
+ push: allow already-exists advice to be disabled
+ push: rename config variable for more general use
+ push: cleanup push rules comment
+ push: clarify rejection of update to non-commit-ish
+ push: require force for annotated tags
+ push: require force for refs under refs/tags/
+ push: flag updates that require force
+ push: keep track of "update" state separately
+ push: add advice for rejected tag reference
+ push: return reject reasons as a bitset
Require "-f" for push to update a tag, even if it is a fast-forward.
Will cook in 'next'.
--------------------------------------------------
[Discarded]
* jc/unpack-file-in-tmpdir (2012-12-19) 1 commit
. unpack-file: allow output to be in $TMPDIR
Throw-away "how about this" to teach unpack-file to use $TMPDIR to
store its output.
Discarded, as da/p4merge-mktemp was rewritten not to require mktemp.
* rj/maint-cygwin-say-color (2012-12-15) 1 commit
. tests: Allow customization of how say_color() prints
Even though I do not think of a cleaner way to do this, I am not
happy with the way how $GIT_TEST_PRINT and $GIT_TEST_PRINT_LN are
interpolated into the command line with token splitting at $IFS.
Discarded, per discussion with the author.
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2013-01-01 0:27 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
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/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch and they
typically are named with three dotted decimal digits. The last such
release was 1.8.1 done on Dec 31, 2012 (or Jan 1, 2013, depending on
where you were when it happened). You can expect that the tip of the
"master" branch is always more stable than any of the released
versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.0.3. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".
The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
design and implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre for helping with packfile design and
implementation issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
cvsserver and cvsimport.
- Paul Mackerras for gitk.
- Eric Wong, David D. Kilzer and Sam Vilain for git-svn.
- Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
Bilotta for maintaining and enhancing gitweb.
- Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
Xin for volunteering to be the l10n coordinator.
- Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
Porcelains.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard for Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
^ permalink raw reply
* [BUG] git fetch --all --tags doesn't fetch remote branches, only tags
From: Dennis Heidsiek @ 2013-01-01 0:43 UTC (permalink / raw)
To: git
Dear Git community,
i think there may be a bug in the fetch command: The command
> $ git fetch --all --tags
> Fetching origin
doesn’t fetch new commits from origin/master, while i see via the web browser of my remote repository that they exist. The same with verbose:
> $ git fetch --all --tags --verbose
> Fetching origin
> From git://repo.or.cz/wortliste
> = [up to date] Trennmuster-20071020 -> Trennmuster-20071020
> = [up to date] Trennmuster-20071223 -> Trennmuster-20071223
> = [up to date] Trennmuster-20080601 -> Trennmuster-20080601
> = [up to date] dehyph-exptl-v0.1 -> dehyph-exptl-v0.1
> = [up to date] dehyph-exptl-v0.11 -> dehyph-exptl-v0.11
> = [up to date] dehyph-exptl-v0.12 -> dehyph-exptl-v0.12
> = [up to date] dehyph-exptl-v0.12.1 -> dehyph-exptl-v0.12.1
> = [up to date] dehyph-exptl-v0.13 -> dehyph-exptl-v0.13
> = [up to date] dehyph-exptl-v0.20 -> dehyph-exptl-v0.20
> = [up to date] dehyph-exptl-v0.22 -> dehyph-exptl-v0.22
> = [up to date] dehyph-exptl-v0.23 -> dehyph-exptl-v0.23
Only if i omit the --tags commit, fetch does what i expect:
> $ git fetch --all --verbose
> Fetching origin
> remote: Counting objects: 13, done.
> remote: Compressing objects: 100% (8/8), done.
> remote: Total 8 (delta 5), reused 0 (delta 0)
> Unpacking objects: 100% (8/8), done.
> From git://repo.or.cz/wortliste
> 7c71430..176027b master -> origin/master
> = [up to date] Keine-Haupttrennstellen-in-zweisilbigen-Wörtern -> origin/Keine-Haupttrennstellen-in-zweisilbigen-Wörtern
> = [up to date] python-skripts -> origin/python-skripts
I think this may be a bug; i’m using my git alias fa = fetch --all --tags --verbose quite often, and it worked in previous versions of Git.
Finnally, i’m using Git 1.8.0.3 under Ubuntu 10.04.4 LTS x86_64 via this PPA: https://launchpad.net/~git-core/+archive/ppa
Thank you for your time reading this and of cause a happy new year!
With best greetings,
Dennis Heidsiek
PS: I’m no subscriber of the Git mailing list.
^ permalink raw reply
* Re: [BUG] git fetch --all --tags doesn't fetch remote branches, only tags
From: Junio C Hamano @ 2013-01-01 1:15 UTC (permalink / raw)
To: Dennis Heidsiek; +Cc: git
In-Reply-To: <50E2311D.8080707@gmail.com>
Dennis Heidsiek <dennis.heidsiek@gmail.com> writes:
> i think there may be a bug in the fetch command: The command
>
>> $ git fetch --all --tags
>> Fetching origin
>
> doesn’t fetch new commits from origin/master, while i see via the
> web browser of my remote repository that they exist.
The "--all" option asks to fetch from all remotes, and "--tags"
option asks to disable the configured fetch refspecs and instead
grab only the tags. It appears that what you observed is exactly
what should happen and in line with the documentation:
$ git help fetch | sed -ne '/^ .*-t.*--tags/,/^$/p'
-t, --tags
This is a short-hand for giving "refs/tags/:refs/tags/" refspec
from the command line, to ask all tags to be fetched and stored
locally. Because this acts as an explicit refspec, the default
refspecs (configured with the remote.$name.fetch variable) are
overridden and not used.
^ permalink raw reply
* Re: [PATCH] Add --unannotate option to git-subtree
From: greened @ 2013-01-01 1:15 UTC (permalink / raw)
To: James Nylen; +Cc: git
In-Reply-To: <CABVa4NinSighUn7GKbzMx9qZj3Ao2dCtEZxUqCPwO9TocZ8Kkg@mail.gmail.com>
James Nylen <jnylen@gmail.com> writes:
> Rather than adding a marker to each commit when splitting out the
> commits back to the subproject, --unannotate removes the specified
> string (or bash glob pattern) from the beginning of the first line of
> the commit message. This enables the following workflow:
I applied the patch to my working copy but it doesn't seem to do
what I'd expect. The test script does something like this:
- create project A
- add file to project A with message "subproj: add F1"
- add file to project A with message "subproj: add F2"
- add project A as a subtree of project B under directory subdir
- add a file to subdir with message "subproj: add F3"
- do a split --unannotate="subproj:"
I expected to see a log with no mention of "subproj" anywhere. Instead
I get:
add F3
subproj: add F2
subproj: add F1
Is this as you intend? Is --unannotate only supposed to strip the
string for commits added when A was a subtree of B?
I guess this behavior makes sense in that the user would want to
see the same commits that existed before A became a subproject.
-David
^ permalink raw reply
* Re: [BUG] git fetch --all --tags doesn't fetch remote branches, only tags
From: Dennis Heidsiek @ 2013-01-01 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbod9d7qg.fsf@alter.siamese.dyndns.org>
Dear Mr. Hamano,
so i /did/ misunderstand the documentation – my fault. Thank you very much for your rapid clarification!
With grateful greetings,
Dennis Heidsiek
^ permalink raw reply
* Re: [BUG?] git-subtree behavior when the -P tree is removed and recreated
From: greened @ 2013-01-01 1:40 UTC (permalink / raw)
To: Tomi Belan; +Cc: Thomas Rast, git, Avery Pennarun
In-Reply-To: <CACUV5odJx1+47ggOAppN7whJhLABrRP-3mRWo8adQqbxF4mA5A@mail.gmail.com>
Tomi Belan <tomi.belan@gmail.com> writes:
> Thanks. Here's one more bump. Avery? David?
I don't know how this is supposed to work, unfortunately. I'm still in
the middle of learning the code...
-David
^ permalink raw reply
* Re: [BUG?] git-subtree behavior when the -P tree is removed and recreated
From: greened @ 2013-01-01 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tomi Belan, Thomas Rast, git, Avery Pennarun
In-Reply-To: <7v8v8uav8t.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Maybe it is a seasonal thing, just before the holiday season, but
> this has been unresponded for a couple of months, not even with a
> "That combination is not supported", or "Thanks for a bug report".
I did finally see this message. I totally admit that I've been pretty
absent. It just happens that I have a ton of paid work to do and
voluteer work unfortunately comes last, after family and after paid
work.
For this bug I honestly don't know what is supposed to happen. I'm
still learning the code. It's a bit of a shell-script mess to be
honest, very hard to follow. That's why it's still in contrib/
and will remain so for a while.
I am more than happy for others to jump in and help out. I'm not a
gatekeeper.
-David
^ 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