* 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
* Re: git subtree error (just how do you expect me to merge 0 trees?)
From: greened @ 2013-01-01 1:44 UTC (permalink / raw)
To: Drew Crawford; +Cc: git@vger.kernel.org
In-Reply-To: <FBE22FDC-5800-40C8-9778-82DFD27579F6@drewcrawfordapps.com>
Drew Crawford <drew@drewcrawfordapps.com> writes:
> I noticed today that if you leave off the branch name from git subtree like so:
>
> $ git subtree add --prefix somewhere -m "adding CDH as subtree" path/to/repo
> warning: read-tree: emptying the index with no arguments is deprecated; use --empty
> fatal: just how do you expect me to merge 0 trees?
>
> The error message is not particularly helpful (and seems to actually be in read-subtree?) The solution in my case was to add the branch name on the end of the command.
>
> Ideally it would be better to emit an error-message from a script higher up the calling chain that would be more descriptive about the problem (such as suggesting no branch is specified).--
Good idea. I'll code it up.
-David
^ permalink raw reply
* Re: [DOCBUG] git subtree synopsis needs updating
From: greened @ 2013-01-01 1:47 UTC (permalink / raw)
To: Yann Dirson; +Cc: Herman van Rink, git list
In-Reply-To: <20121024162947.2c1edc50@chalon.bertin.fr>
Yann Dirson <dirson@bertin.fr> writes:
> Ah, it's nice to see subtree updates. Any plans to get them merged anytime soon ?
As soon as there is one patch per feature that applies cleanly to
contrib/ and testcases use the native git test facility.
These patches should be submitted to the mailing list for review.
-David
^ permalink raw reply
* Re: git subtree error (just how do you expect me to merge 0 trees?)
From: greened @ 2013-01-01 2:09 UTC (permalink / raw)
To: Drew Crawford; +Cc: git@vger.kernel.org
In-Reply-To: <FBE22FDC-5800-40C8-9778-82DFD27579F6@drewcrawfordapps.com>
Drew Crawford <drew@drewcrawfordapps.com> writes:
> Ideally it would be better to emit an error-message from a script
> higher up the calling chain that would be more descriptive about the
> problem (such as suggesting no branch is specified).--
I'm looking at implementing this but I need a bit of help from the git
experts.
git-subtree add accepts either a refspec or a path to a repository and a
refspec. With one positional option, git-subtree add simply assumes
it's a refspec. Is there an easy way to check whether a string is a
proper refspec? Even better would be a way to check if a string is a
path to a git repository.
-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