* Re: [PATCH 1/4] gitweb: notes feature
From: Giuseppe Bilotta @ 2010-02-07 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Johan Herland, git, Johannes Schindelin
In-Reply-To: <7vock0evs8.fsf@alter.siamese.dyndns.org>
On Sun, Feb 7, 2010 at 7:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Notes are fundamenally metainformation about an _object_ [*1*] and are not
> metainformation about refs. Since whatever magic notation to denote notes
> we choose wants to be applied to an arbitrary commit, it shouldn't be the
> at-brace syntax.
Makes sense. ^{note[:namespace]} is ok for me too btw, although maybe
it looks a little off-base when compared with the tag indicator ^{}
which works, in a sense, in the opposite direction.
> [Footnote]
>
> *1* Yes, I am aware of movements to misuse notes to annotate anything
> after mapping it to a random SHA-1 value, but I think that is outside the
> scope of notes. Our design decision should be based on supporting the
> primary use of annotating an object, and that might still keep such a use
> working, in which case that would be an added bonus. But our design
> shouldn't be constrained by such a secondary use.
BTW, I still think that notes should be attachable to named refs (not
SHA-1, thus) too.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Junio C Hamano @ 2010-02-07 20:25 UTC (permalink / raw)
To: Jeff King; +Cc: Jon Seymour, Johan Herland, git
In-Reply-To: <20100207193320.GB3185@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Or perhaps you would not even want to do a tree-merge between notes at
> all, and would rather see a conflict if two people noted two different
> trees.
I've been thinking about the merge issues, and am starting to suspect that
we might want a merge strategy quite drastically different even for blob
cases. That is one of the reasons why I don't want to see us muddy the
issues by introducing even more complex "tree" case.
Anybody working in the same project can start 'notes' tree with his or her
own root. That is the normal use case for annotating commits for your own
use. For merges inside the history of primary contents that people try to
collaborate to advance, three-way merge pivoting on a common ancestor is a
natural way to reach a satisfactory result. In notes namespace, on the
other hand, the norm is to simply overlay the notes trees, adjusting for
the fan-out. You annotated that commit I was not interested in, while I
annotated this commit you weren't interested in. We have our notes in the
end result, and both of us are happy. If we happen to have annotated the
same commit without knowing what the other was doing, then there is no
sane consolidation---in the most typical case, we would want to keep both,
perhaps concatenating them together. Textual merge becomes the exception
that triggers two "notes" histories happened to have forked from the same
root somehow.
And for that most typical use case, I suspect even the current "notes on
any and all commits for a single purpose are thrown into a one _bag_ that
is a notes tree, and the growth of that bag is made into a history" model
captures sets of notes that is too wide.
Suppose Alice, Bob and I are involved in a project, and we annotate
commits for some shared purpose (say, tracking regressions). Alice and
Bob may independently annotate overlapping set of commits (and hopefully
they have shared root for their notes history as they are collaborating),
and they may even be working together on the same issue, but I may not be
involved in the area. What happens when I pull from Alice and Bob and get
conflicts in notes they produced, especially the only reason I was
interested was because they have new things to say about commits that I am
interested in?
You can end up with conflicts in areas you are not familiar with but Alice
and Bob are in charge of even in the primary content space, but there is a
fundamental difference of this type of conflict in the notes space, I
think. The set of contents in the primary content space are supposed to
make a consistent whole, and there is a topic branch workflow to partition
the work to allow me to easily kick the merge back to them (i.e. I can
tell Alice and Bob to resolve the conflicts between themselves and trust
that what they do between them do not touch outside of their area) without
getting blocked. I don't see a clear workflow to resolve this in the
notes space, especially with the set of operations the current "git notes"
(and obvious and straightforward enhancements of what it does). At least
not yet.
It's like "keeping track of /etc" (or "your home directory"). It is a
misguided thing to do because you are throwing in records of the states of
totally unrelated things into a single history (e.g. "Why does it matter I
added new user frotz to /etc/passwd before I futzed with my sendmail
configuration? ---It shouldn't matter; there shouldn't be ancestry
relationships between these two changes"). I somehow feel that keeping
track of the "growth of the bag of annotations to any and all commits" in
a single history may be making the same mistake.
^ permalink raw reply
* [PATCH 0/2] gitweb: Improve escaping
From: Jakub Narebski @ 2010-02-07 20:47 UTC (permalink / raw)
To: git
Those two patches are dependent on each other only because of single
change in second patch, showcasing the feature.
---
Jakub Narebski (2):
gitweb: esc_html (short) error message in die_error
gitweb: Protect escaping functions against calling on undef
gitweb/gitweb.perl | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* [PATCH 1/2] gitweb: esc_html (short) error message in die_error
From: Jakub Narebski @ 2010-02-07 20:51 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <20100207204539.11146.36972.stgit@localhost.localdomain>
The error message (second argument to die_error) is meant to be short,
one-line text description of given error. A few callers call
die_error with error message containing unescaped user supplied data
($hash, $file_name). Instead of forcing callers to escape data,
simply call esc_html on the parameter.
Note that optional third parameter, which contains detailed error
description, is meant to be HTML formatted, and therefore should be
not escaped.
While at it update esc_html synopsis/usage, and bring default error
description to read 'Internal Server Error' (titlecased).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Alternate solution would be to do escaping in call sites for die_error.
But in error messages shown on 'die' via CGI::Carp qw(fatalsToBrowser)
the error message is HTML escaped, so in fact we are following here
this "calling convention".
Note that for any patch relied on 'Internal server error' as error
message, it must be changed to not fail wrongly.
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a5bc359..e393f65 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3374,7 +3374,7 @@ sub git_footer_html {
"</html>";
}
-# die_error(<http_status_code>, <error_message>)
+# die_error(<http_status_code>, <error_message>[, <detailed_html_description>])
# Example: die_error(404, 'Hash not found')
# By convention, use the following status codes (as defined in RFC 2616):
# 400: Invalid or missing CGI parameters, or
@@ -3389,7 +3389,7 @@ sub git_footer_html {
# or down for maintenance). Generally, this is a temporary state.
sub die_error {
my $status = shift || 500;
- my $error = shift || "Internal server error";
+ my $error = esc_html(shift || "Internal Server Error");
my $extra = shift;
my %http_responses = (
^ permalink raw reply related
* [PATCH 2/2] gitweb: Protect escaping functions against calling on undef
From: Jakub Narebski @ 2010-02-07 20:52 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <20100207204539.11146.36972.stgit@localhost.localdomain>
This is a bit of future-proofing esc_html and friends: when called
with undefined value they would now would return undef... which would
probably mean that error would still occur, but closer to the source
of problem.
This means that we can safely use
esc_html(shift) || "Internal Server Error"
in die_error() instead of
esc_html(shift || "Internal Server Error")
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Without the second part (i.e. the change in die_error) those two
patches would be totally independent.
gitweb/gitweb.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e393f65..c10967c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1145,6 +1145,7 @@ sub validate_refname {
# in utf-8 thanks to "binmode STDOUT, ':utf8'" at beginning
sub to_utf8 {
my $str = shift;
+ return undef unless defined $str;
if (utf8::valid($str)) {
utf8::decode($str);
return $str;
@@ -1157,6 +1158,7 @@ sub to_utf8 {
# correct, but quoted slashes look too horrible in bookmarks
sub esc_param {
my $str = shift;
+ return undef unless defined $str;
$str =~ s/([^A-Za-z0-9\-_.~()\/:@ ]+)/CGI::escape($1)/eg;
$str =~ s/ /\+/g;
return $str;
@@ -1165,6 +1167,7 @@ sub esc_param {
# quote unsafe chars in whole URL, so some charactrs cannot be quoted
sub esc_url {
my $str = shift;
+ return undef unless defined $str;
$str =~ s/([^A-Za-z0-9\-_.~();\/;?:@&=])/sprintf("%%%02X", ord($1))/eg;
$str =~ s/\+/%2B/g;
$str =~ s/ /\+/g;
@@ -1176,6 +1179,8 @@ sub esc_html {
my $str = shift;
my %opts = @_;
+ return undef unless defined $str;
+
$str = to_utf8($str);
$str = $cgi->escapeHTML($str);
if ($opts{'-nbsp'}) {
@@ -1190,6 +1195,8 @@ sub esc_path {
my $str = shift;
my %opts = @_;
+ return undef unless defined $str;
+
$str = to_utf8($str);
$str = $cgi->escapeHTML($str);
if ($opts{'-nbsp'}) {
@@ -3389,7 +3396,7 @@ sub git_footer_html {
# or down for maintenance). Generally, this is a temporary state.
sub die_error {
my $status = shift || 500;
- my $error = esc_html(shift || "Internal Server Error");
+ my $error = esc_html(shift) || "Internal Server Error";
my $extra = shift;
my %http_responses = (
^ permalink raw reply related
* Re: [PATCH 1/4] gitweb: notes feature
From: Jakub Narebski @ 2010-02-07 21:08 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, Johan Herland, git, Johannes Schindelin
In-Reply-To: <cb7bb73a1002071211n23a410f9icc3d4d29179c44ca@mail.gmail.com>
On Sun, 7 Feb 2010, Giuseppe Bilotta wrote:
> On Sun, Feb 7, 2010 at 7:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Notes are fundamenally metainformation about an _object_ [*1*] and are not
> > metainformation about refs. Since whatever magic notation to denote notes
> > we choose wants to be applied to an arbitrary commit, it shouldn't be the
> > at-brace syntax.
>
> Makes sense. ^{note[:namespace]} is ok for me too btw, although maybe
> it looks a little off-base when compared with the tag indicator ^{}
> which works, in a sense, in the opposite direction.
Well, notes refer to objects (commits), but the whole idea of notes
was to have easy mapping in the reverse direction, from object to
its annotations.
We could invent yet another syntax, e.g. ^@{} or ^@{<namespace>}
(following ^@ notation for parents, which can also return multiple SHA1s).
> > [Footnote]
> >
> > *1* Yes, I am aware of movements to misuse notes to annotate anything
> > after mapping it to a random SHA-1 value, but I think that is outside the
> > scope of notes. Our design decision should be based on supporting the
> > primary use of annotating an object, and that might still keep such a use
> > working, in which case that would be an added bonus. But our design
> > shouldn't be constrained by such a secondary use.
>
> BTW, I still think that notes should be attachable to named refs (not
> SHA-1, thus) too.
I have just realized that it is totally no-go. Why? Because names of
refs are local to repository: what is one 'master' might be other 'origin';
what is one 'for-linus' might be other 'from-alan', what's one
'refs/heads/next' might be other 'refs/remotes/origin/next'.
Also I think that there would be problem with renaming and deleting refs.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH 01/10] gitweb: Print to explicit filehandle (preparing for caching)
From: Jakub Narebski @ 2010-02-07 21:32 UTC (permalink / raw)
To: git
In-Reply-To: <0dd15cb3f18e2a26fc834fd3b071e6d3ecc00557.1264198194.git.jnareb@gmail.com>
On Sat, 23 Feb 2010, Jakub Narebski wrote:
> This means replacing
>
> print <something>;
> by
> print {$out} <something>;
>
> and
>
> binmode STDOUT, <layer>;
> by
> binmode $out, <layer>;
[...]
> This patch was written _before_ comment from Junio that it would be
> better to simply use
> print $out <something>;
> and do not try to be too clever.
Actually 'print FILEHANDLE LIST' form is an example of indirect object
syntax in Perl (which for filehandles was present before there were
objects in Perl). In indirect object notation the "first argument"
must be a name, a scalar variable, or a block (like {$out}). If instead
of $out there would be something more complicated, we would have to
use block form ('print {$out[$i]} <sth>', for example).
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] git-gui: check whether systems nice command works or disable it
From: Heiko Voigt @ 2010-02-07 21:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
This fixes issue 394 from msysgit. It seems that the Gnuwin32 project
provides a nice command but it returns a "not implemented" error. To
help users we now try to execute once and disable it in case it fails.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
see: http://code.google.com/p/msysgit/issues/detail?id=394
for more information.
cheers Heiko
git-gui/git-gui.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 1fb3cbf..eec2dc9 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -388,6 +388,9 @@ proc _lappend_nice {cmd_var} {
if {![info exists _nice]} {
set _nice [_which nice]
+ if {[catch {exec $_nice git version}]} {
+ set _nice {}
+ }
}
if {$_nice ne {}} {
lappend cmd $_nice
--
1.7.0.rc1.7.gc0da5
^ permalink raw reply related
* Re: [PATCH] Documentation/SubmittingPatches: fix Gmail workaround advice
From: Jonathan Nieder @ 2010-02-07 21:54 UTC (permalink / raw)
To: Aaron Crane
Cc: Junio C Hamano, git, Sverre Rabbelier, Jacob Helwig,
David Aguilar, Jay Soffian, John Tapsell
In-Reply-To: <bc341e101002071203x52bceaach8d42c6188630f1d1@mail.gmail.com>
Aaron Crane wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> What I am trying to get at is to see if the current imap-send suggestion
>> is fundamentally unworkable with gmail. Perhaps they stopped supporting
>> imap. Perhaps the procedure never worked.
>
> As far as I can determine, the current imap-send suggestion is
> fundamentally unworkable with gmail at the moment. I don't know
> whether it ever used to work, though I've been assuming that it did.
I think it still works, or depending on your perspective, it never did.
As John Tapsell wrote in SubmittingPatches (commit 50dffd4e, 2009-02-19):
| GMail does not appear to have any way to turn off line wrapping in the web
| interface, so this will mangle any emails that you send. You can however
| use any IMAP email client to connect to the google imap server, and forward
| the emails through that. Just make sure to disable line wrapping in that
| email client. Alternatively, use "git send-email" instead.
I am not sure what that means about what SubmittingPatches should say:
should it explain both methods, then?
If I were doing it, I would put the information in the git-imap-send and
git-send-mail man pages as examples. That way, it would be visible for
people submitting patches to _other_ projects, too. The section in
Documentation/SubmittingPatches could be replaced with a pointer.
Jonathan
^ permalink raw reply
* Re: [PATCH] Documentation/SubmittingPatches: fix Gmail workaround advice
From: Jonathan Nieder @ 2010-02-07 22:16 UTC (permalink / raw)
To: Aaron Crane
Cc: Tom Preston-Werner, Junio C Hamano, git, Sverre Rabbelier,
Jacob Helwig, David Aguilar, Jay Soffian, John Tapsell
In-Reply-To: <20100207215311.GA2177@progeny.tock>
Jonathan Nieder wrote:
> Aaron Crane wrote:
>> As far as I can determine, the current imap-send suggestion is
>> fundamentally unworkable with gmail at the moment. I don't know
>> whether it ever used to work, though I've been assuming that it did.
>
> I think it still works, or depending on your perspective, it never did.
Scratch that: it looks like it once did.
http://thread.gmane.org/gmane.comp.version-control.git/99721/focus=99775
Tom, any clues? Are you still able to avoid spurious line wrapping in
gmail?
Jonathan
^ permalink raw reply
* Re: [PATCH] Add a test for a problem in "rebase --whitespace=fix"
From: Björn Gustavsson @ 2010-02-07 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtytsevsd.fsf@alter.siamese.dyndns.org>
2010/2/7 Junio C Hamano <gitster@pobox.com>:
> First, is this a condition that we want to change the behaviour to
> "succeed" later?
Yes, assuming it is possible to fix.
> Imagine that the gap between abc and def block in your example is much
> larger to exceed the number of pre-context lines of your second patch
> (usually 3), and imagine you are the "git apply --whitespace=fix" program
> you have updated to "fix" the preceived problem. You know you earlier
> might have stripped some blank lines at the EOF, but there is nothing that
> tells you if you had only 3 blank lines, or you had even more. How many
> blank lines will you be adding back?
My original idea was to add back exactly the number of lines needed
so that the context lines would match. That can be calculated from
the line numbers of the last line of the pre-image and the line number
in the chunk and by scanning the chunk for blank context lines
(both at the beginning and end of chunk). Since the blanks lines
at the end will be stripped away anyway, I doesn't matter if I add
back fewer lines than were there originally.
Thinking a little more about it, if there is a chunk that starts
beyond the end of file, I could add the number of blanks lines
that is missing up to the beginning of the chunk plus the
number of lines in the chunk itself. That will also take
care of the case that the chunk deletes blanks lines.
(That will probably add too many blanks at the end,
but they will be stripped out again.)
That is my plan. Of course, since I have not attempted
to implement it yet, there could be fatal flaws in it.
Do you see any fatal flaws that I don't see?
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Johan Herland @ 2010-02-07 22:46 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jon Seymour, git
In-Reply-To: <20100207050255.GA17049@coredump.intra.peff.net>
On Sunday 07 February 2010, Jeff King wrote:
> I think I may have been the one to suggest trees or notes at one point.
> But let me clarify that this is not exactly what the OP is proposing in
> this thread.
>
> My suggestion was that some use cases may have many key/value pairs of
> notes for a single sha1. We basically have two options:
>
> 1. store each in a separate notes ref, with each sha1 mapping to
> a blob. The note "name" is the name of the ref.
>
> 2. store notes in a single notes ref, with each sha1 mapping to a
> tree with named sub-notes. The note "name" is the combination of
> ref-name and tree entry name.
>
> The advantage of (1) is that notes are not bound tightly to each other.
> I can distribute the notes tree for one "name" independent of the
> others. The advantage of (2) is that it is faster and smaller. In (1),
> each note has a separate index, and we must traverse each note index
> separately.
>
> In practice, I would expect to use (1) for logically separate datasets.
> For example, automatic bug-tracking notes would go in a different ref
> from human annotations. But I would expect to use (2) if I had, say, 5
> different pieces of bug tracking information and I wanted an easy way to
> refer to them individually.
>
> And a specialized merge for that is straightforward. In the simplest
> case, you simply say "notes of this ref are tree-type, or they are
> blob-type" and then you have no merge problems. But if you want to get
> fancy, you can say that a conflict between "sha1/blob" and
> "sha1/tree/key" should automatically "promote" the first one into
> "sha1/tree/default" or some other canonical name.
>
> Note that all of this is my pie-in-the-sky "here is what I was thinking
> of when I looked at notes a long time ago". I don't care strongly if it
> gets implemented or not at this point; I just wanted to add some context
> to what Johan had in his notes todo list (or maybe I am wrong, and what
> is in his todo list was based on something totally different said by
> somebody else, and I have just confused the issue more. :) ).
No, My TODO item was indeed based on your suggestion (although poorly
represented by me, both in the TODO list, and in my original answer to Jon).
However, note that I don't feel this specific itch myself, so I'm unlikely
to scratch it.
> With respect to the idea of storing an arbitrary tree, I agree it is
> probably too complex with respect to merging. In addition, it makes
> things like "git log --format=%N" confusing. I think you would do better
> to simply store a tree sha1 inside the note blob, and callers who were
> interested in the tree contents could then dereference it and examine as
> they saw fit. The only caveat is that you need some way of telling git
> that the referenced trees are reachable and not to be pruned.
Agreed. Arbitrary trees as notes objects is probably not a good idea.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: notes metadata?
From: Johan Herland @ 2010-02-07 22:57 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Git List, Junio C Hamano
In-Reply-To: <cb7bb73a1002070350j750287abl43de4d936a47acef@mail.gmail.com>
On Sunday 07 February 2010, Giuseppe Bilotta wrote:
> Hello all,
>
> ok, this may sound a little odd especially with the 'notes vs
> metadata' thread going on, but I was wondering: do we store _any_ kind
> of metadata _about_ the notes themselves? If I'm reading the code
> correctly, we have neither author nor date information about the notes
> themselves, so we don't know who added them or when. Is it too late to
> suggest that this kind of metadata be added to notes? Making them
> full-blown commit-style objects is probalby overengineered and wrong
> under many points of view (not to mention probably incompatible with
> current storage), but maybe we can set up a convention that notes
> SHOULD be in pseudo-mbox format? This would mean that when a note is
> created, the template starts with a 'From ' line including the user's
> name & email and note creation date; when editing, the note is again
> augmented with the new author name email and date. Of course the users
> are then free do expunge the From lines if they don't want it (just
> commenting it would be enough, of course). How does the idea sound?
NAK
Notes are stored in a notes tree that is changed by making commits on the
notes ref (see commit_notes() in builtin-notes.c in 'pu'). The commits on
the notes ref are regular commits with the usual commit metadata (author,
date, etc.), so if you're interested in who/when a given note was written,
you can simply point 'git (gui) blame' at the notes tree.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] archive: simplify archive format guessing
From: René Scharfe @ 2010-02-07 23:30 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <4B6E8FD9.7060905@lsrfire.ath.cx>
Here's my patch again, with a reformatted comment, a renamed variable and
two simple tests.
-- >8 --
The code to guess an output archive's format consumed any --format
options and built a new one. Jonathan noticed that it does so in an
unsafe way, risking to overflow the static buffer fmt_opt.
Change the code to keep the existing --format options intact and to only
add a new one if a format could be guessed based on the output file name.
The new option is added as the first one, allowing the existing ones to
overrule it, i.e. explicit --format options given on the command line win
over format guesses, as before.
To simplify the code further, format_from_name() is changed to return the
full --format option, thus no potentially dangerous sprintf() calls are
needed any more.
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-archive.c | 34 ++++++++++++++++------------------
t/t5000-tar-tree.sh | 10 ++++++++++
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/builtin-archive.c b/builtin-archive.c
index 3fb4136..6a887f5 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -70,7 +70,7 @@ static const char *format_from_name(const char *filename)
return NULL;
ext++;
if (!strcasecmp(ext, "zip"))
- return "zip";
+ return "--format=zip";
return NULL;
}
@@ -84,7 +84,7 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
const char *exec = "git-upload-archive";
const char *output = NULL;
const char *remote = NULL;
- const char *format = NULL;
+ const char *format_option = NULL;
struct option local_opts[] = {
OPT_STRING('o', "output", &output, "file",
"write the archive to this file"),
@@ -92,33 +92,31 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
"retrieve the archive from remote repository <repo>"),
OPT_STRING(0, "exec", &exec, "cmd",
"path to the remote git-upload-archive command"),
- OPT_STRING(0, "format", &format, "fmt", "archive format"),
OPT_END()
};
- char fmt_opt[32];
argc = parse_options(argc, argv, prefix, local_opts, NULL,
PARSE_OPT_KEEP_ALL);
if (output) {
create_output_file(output);
- if (!format)
- format = format_from_name(output);
+ format_option = format_from_name(output);
}
- if (format) {
- sprintf(fmt_opt, "--format=%s", format);
- /*
- * We have enough room in argv[] to muck it in place,
- * because either --format and/or --output must have
- * been given on the original command line if we get
- * to this point, and parse_options() must have eaten
- * it, i.e. we can add back one element to the array.
- * But argv[] may contain "--"; we should make it the
- * first option.
- */
+ /*
+ * We have enough room in argv[] to muck it in place, because
+ * --output must have been given on the original command line
+ * if we get to this point, and parse_options() must have eaten
+ * it, i.e. we can add back one element to the array.
+ *
+ * We add a fake --format option at the beginning, with the
+ * format inferred from our output filename. This way explicit
+ * --format options can override it, and the fake option is
+ * inserted before any "--" that might have been given.
+ */
+ if (format_option) {
memmove(argv + 2, argv + 1, sizeof(*argv) * argc);
- argv[1] = fmt_opt;
+ argv[1] = format_option;
argv[++argc] = NULL;
}
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 0037f63..27bfba5 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -189,6 +189,16 @@ test_expect_success 'git archive --format=zip with --output' \
'git archive --format=zip --output=d2.zip HEAD &&
test_cmp d.zip d2.zip'
+test_expect_success 'git archive with --output, inferring format' '
+ git archive --output=d3.zip HEAD &&
+ test_cmp d.zip d3.zip
+'
+
+test_expect_success 'git archive with --output, override inferred format' '
+ git archive --format=tar --output=d4.zip HEAD &&
+ test_cmp b.tar d4.zip
+'
+
$UNZIP -v >/dev/null 2>&1
if [ $? -eq 127 ]; then
say "Skipping ZIP tests, because unzip was not found"
--
1.7.0.rc1
^ permalink raw reply related
* Re: git gc / git repack not removing unused objects?
From: Jon Nelson @ 2010-02-07 23:40 UTC (permalink / raw)
Cc: git
In-Reply-To: <cccedfc61002070948m2491b1e2ua633f125f3573ff9@mail.gmail.com>
On Sun, Feb 7, 2010 at 11:48 AM, Jon Nelson <jnelson@jamponi.net> wrote:
> On Sat, Feb 6, 2010 at 7:16 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Sat, 6 Feb 2010, Jon Nelson wrote:
>>
>>> Last night, the repo size was 153G after removing some commits and
>>> objects by way of git filter-branch.
>>> I'm using "du -sh" in the .git directory to determine the disk usage.
>>>
>>> Before: 136G
>>> git repack -dAl
>>> After: 153G
>>
>> Why are you using -A instead of -a ?
>
> As it turns out, I've been using both -a and -A. I suspect -A is a
> typo on my part.
>
>>> Then, just to make sure of some things, I changed nothing and simply
>>> re-ran "git repack -dAl".
>>> After: 167G
>>
>> Could you run 'git count-objects -v' before and after a repack in such
>> cases as well?
>
> Yes.
>
>>> [pack]
>>> packsizelimit = 256m
>>
>> Why are you using this?
>
> I didn't want my pack files to be too huge. I've bumped that up to 2G.
>
>>> pack.packsizelimit=2M
>
> My ~/.gitconfig normally uses 2M for easy rsyncing. In this repo I
> thought the value was overridden by the project's config (which was
> specifying 256m and now specifies 2048m).
>
> Suboptimal or not, it still doesn't explain why the repo grows with each repack.
>
> Now running:
>
> git count-objects -v ; git repack -ad ; git count-objects -v
The results (two lines of whitespace added for clarity):
turnip:/mnt/backups.git # git count-objects -v ; git repack -ad ; git
count-objects -v
count: 0
size: 0
in-pack: 2408195
packs: 675
size-pack: 174924053
prune-packable: 0
garbage: 0
Counting objects: 266309, done.
Compressing objects: 100% (207820/207820), done.
Writing objects: 100% (266309/266309), done.
Total 266309 (delta 47751), reused 227730 (delta 45117)
count: 0
size: 0
in-pack: 2674504
packs: 686
size-pack: 196517094
prune-packable: 0
garbage: 0
turnip:/mnt/backups.git # du -sh .
188G .
turnip:/mnt/backups.git # find objects -name '*.pack' | wc -l
686
turnip:/mnt/backups.git #
So we went from 136G to 153G to 167G and now 188G.
The oldest .pack file is Jan 29 at 7.0M
The pack files vary considerably in size from 220B to 2.0G
There are 433 packs that are between 200M and 300M in size.
There are 78 packs that are between 500M and 600M in size.
There are 211 packs that are less than 256M in size.
I ran "git prune -v --prune=now" and it claims to have removed nothing
and the exit status was 0.
I hope this helps!
--
Jon
^ permalink raw reply
* Re: [PATCH] Add a test for a problem in "rebase --whitespace=fix"
From: Junio C Hamano @ 2010-02-08 0:15 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <6672d0161002071444lba0f751w3e7e33043e1ec2e8@mail.gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> 2010/2/7 Junio C Hamano <gitster@pobox.com>:
>
>> First, is this a condition that we want to change the behaviour to
>> "succeed" later?
>
> Yes, assuming it is possible to fix.
>
>> Imagine that the gap between abc and def block in your example is much
>> larger to exceed the number of pre-context lines of your second patch
>> (usually 3), and imagine you are the "git apply --whitespace=fix" program
>> you have updated to "fix" the preceived problem. You know you earlier
>> might have stripped some blank lines at the EOF, but there is nothing that
>> tells you if you had only 3 blank lines, or you had even more. How many
>> blank lines will you be adding back?
>
> My original idea was to add back exactly the number of lines needed
> so that the context lines would match. That can be calculated from
> the line numbers of the last line of the pre-image and the line number
> in the chunk and by scanning the chunk for blank context lines
> (both at the beginning and end of chunk). Since the blanks lines
> at the end will be stripped away anyway, I doesn't matter if I add
> back fewer lines than were there originally.
And if it were in the middle like your patch had?
Suppose the first patch in your example ended with 10 blank lines instead
of just one. You apply it with --ws=fix and end up with 3-liner file with
a/b/c. The sender of that patch then builds on top of his copy (still
with 10 blanks at EOF). Perhaps the early part a/b/c might be changed to
a/b/c/1/2 or something. And on top of that change, he adds new text at
the end of the file (after those 10 blank lines) with another patch, like
your example added d/e/f at the end after the gap.
The sender then chooses to cherry pick and gives you only the last patch,
to add d/e/f, for whatever reason. The change in the earlier part to add
1/2 after a/b/c was not suitable for public consumption yet, perhaps. The
patch comes with 3 pre-context lines as usual, what you see begins with
three blank lines, and has an addition of d/e/f.
You have already stripped the blank lines at the end when you applied the
original one; you do not know how many blank lines at the end you lost
when you applied it (and you do not _want_ to record that when applying
either).
You cannot go by the line numbers on the "@@ -l,k +m,n @@" header line you
see in the second patch you received. On that line, only k and n are
reliable numbers (the must match the patch text). l and m are unreliable;
being able to apply even if the text you have at hand does not exactly
match l and m is the whole point of transmitting the change in the patch
format. The _only_ information you have usable at that point is that
there are _at least_ 3 blank lines before the addition, and perhaps the
fact that the hunk ends without post context lines. The latter tells you
that it must apply at the end, but still doesn't tell you how many blanks
you need to add back at EOF before applying the patch.
> Do you see any fatal flaws that I don't see?
I don't know---the above is what I already said in my previous message and
it already looked fatal enough to me.
^ permalink raw reply
* Re: [PATCH] git-gui: check whether systems nice command works or disable it
From: Junio C Hamano @ 2010-02-08 0:21 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <20100207214755.GB3034@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> This fixes issue 394 from msysgit. It seems that the Gnuwin32 project
> provides a nice command but it returns a "not implemented" error. To
> help users we now try to execute once and disable it in case it fails.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
>
> see: http://code.google.com/p/msysgit/issues/detail?id=394
> for more information.
>
> cheers Heiko
>
> git-gui/git-gui.sh | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index 1fb3cbf..eec2dc9 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -388,6 +388,9 @@ proc _lappend_nice {cmd_var} {
>
> if {![info exists _nice]} {
> set _nice [_which nice]
> + if {[catch {exec $_nice git version}]} {
> + set _nice {}
> + }
Where does the output from this "git version" invocation go?
> }
> if {$_nice ne {}} {
> lappend cmd $_nice
> --
> 1.7.0.rc1.7.gc0da5
^ permalink raw reply
* Re: [PATCH] archive: simplify archive format guessing
From: Junio C Hamano @ 2010-02-08 0:45 UTC (permalink / raw)
To: René Scharfe; +Cc: Jonathan Nieder, Dmitry Potapov, git
In-Reply-To: <4B6F4D0C.2010107@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Here's my patch again, with a reformatted comment, a renamed variable and
> two simple tests.
Thanks; will apply to maint and merge upwards.
^ permalink raw reply
* Re: git-grep: option parsing conflicts with prefix-dash searches
From: Junio C Hamano @ 2010-02-08 1:06 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jan Engelhardt, git
In-Reply-To: <20100207044415.GA6622@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Here it is with a commit message and some tests. While it is a minor
> change, we are pretty late in the release cycle, so perhaps it is best
> to leave it post-1.7.0 just to be on the safe side.
Your explanation that "-- marks the end of options" makes perfect sense
and it is not inconsistent with what we do either. "grep" is an oddball
that among its non-option arguments the first one _can_ be a non-path
(namely, the single pattern you are looking for), but with your patch,
that logic is nicely expressed, too.
I am tempted to push it into 1.7.0 but I'd keep it in 'next' for now.
Thanks.
^ permalink raw reply
* Unix root dir as a work tree
From: João Carlos Mendes Luís @ 2010-02-08 1:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]
Hi,
Sorry if this is a FAQ, but I could not find any reference.
I have been using CVS as a version control system for unix
configuration files for a long time. I know it has some limitations,
and I know git also has its. But I expect to work around all of them
using etckeeper.
The problem is that etckeeper was created with /etc only in mind,
and I want to keep track of important files everywhere, not only below
/etc (think /opt, /usr/local). The obvious solution appear to create
the repository at the system root, and not at /etc, but it did not
work. I think, because of a bug.
Now, I have a patch that appears to work, but since I am a beginner
to git, I don't know if this is the best way to implement it, if it has
any side effects, or even if it works for other operating systems
(probably they don't even have the bug). Would any git wizard care to
look at it, check if it is ok, and maybe commit in HEAD or give me any
advice against my patch?
Please, don't give me any answers like "don't use your root as a
repo". I am a system admin for a long time, and I know what I want and
what are the risks and benefits involved.
Thanks in advance,
Jonny
[-- Attachment #2: git-1.5.5.6-setup-work_dir-root.patch --]
[-- Type: text/x-patch, Size: 465 bytes --]
--- a/setup.c 2010-02-07 22:50:40.000000000 -0200
+++ b/setup.c 2010-02-07 22:51:56.000000000 -0200
@@ -413,7 +413,12 @@
inside_git_dir = 0;
if (!work_tree_env)
inside_work_tree = 1;
- git_work_tree_cfg = xstrndup(cwd, offset);
+ if ( cwd[0] == '/' && offset == 0 ) {
+ git_work_tree_cfg = xstrndup(cwd, 1);
+ }
+ else {
+ git_work_tree_cfg = xstrndup(cwd, offset);
+ }
if (check_repository_format_gently(nongit_ok))
return NULL;
if (offset == len)
^ permalink raw reply
* Re: Unix root dir as a work tree
From: Nguyen Thai Ngoc Duy @ 2010-02-08 2:03 UTC (permalink / raw)
To: João Carlos Mendes Luís; +Cc: git
In-Reply-To: <4B6F6971.6000106@jonny.eng.br>
2010/2/8 João Carlos Mendes Luís <jonny@jonny.eng.br>:
> Hi,
>
> Sorry if this is a FAQ, but I could not find any reference.
>
> I have been using CVS as a version control system for unix configuration
> files for a long time. I know it has some limitations, and I know git also
> has its. But I expect to work around all of them using etckeeper.
>
> The problem is that etckeeper was created with /etc only in mind, and I
> want to keep track of important files everywhere, not only below /etc (think
> /opt, /usr/local). The obvious solution appear to create the repository at
> the system root, and not at /etc, but it did not work. I think, because of
> a bug.
>
> Now, I have a patch that appears to work, but since I am a beginner to git,
> I don't know if this is the best way to implement it, if it has any side
> effects, or even if it works for other operating systems (probably they
> don't even have the bug). Would any git wizard care to look at it, check if
> it is ok, and maybe commit in HEAD or give me any advice against my patch?
How did you set GIT_DIR and GIT_WORK_TREE? What command failed?
--
Duy
^ permalink raw reply
* Re: git gc / git repack not removing unused objects?
From: Nicolas Pitre @ 2010-02-08 2:11 UTC (permalink / raw)
To: Jon Nelson; +Cc: git
In-Reply-To: <cccedfc61002071540l7019d5d0mc4666dbd81189064@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2334 bytes --]
On Sun, 7 Feb 2010, Jon Nelson wrote:
> On Sat, Feb 6, 2010 at 7:16 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >On Sat, 6 Feb 2010, Jon Nelson wrote:
> >> packsizelimit = 256m
> >
> > Why are you using this?
>
> I didn't want my pack files to be too huge. I've bumped that up to 2G.
>
> >> pack.packsizelimit=2M
>
> My ~/.gitconfig normally uses 2M for easy rsyncing. In this repo I
> thought the value was overridden by the project's config (which was
> specifying 256m and now specifies 2048m).
Why do you synchronize with rsync? Why not a simple 'git fetch' which
is likely to be much faster in any case?
> Suboptimal or not, it still doesn't explain why the repo grows with each repack.
That's strange indeed. Except that ...
> turnip:/mnt/backups.git # git count-objects -v ; git repack -ad ; git
> count-objects -v
> count: 0
> size: 0
> in-pack: 2408195
> packs: 675
> size-pack: 174924053
> prune-packable: 0
> garbage: 0
>
> Counting objects: 266309, done.
> Compressing objects: 100% (207820/207820), done.
> Writing objects: 100% (266309/266309), done.
> Total 266309 (delta 47751), reused 227730 (delta 45117)
>
> count: 0
> size: 0
> in-pack: 2674504
> packs: 686
> size-pack: 196517094
> prune-packable: 0
> garbage: 0
You previously had 2408195 packed objects and after the repack this is
2674504. The difference is 266309, which incidentally is the number of
objects 'git repack' counted.
If that 266309 object count is stable between repack attempts (and it
should), then something is failing to clean up the old packs. If I
remember right, you were playing with modifications to git-repack.sh
lately? It is well possible that you broke it.
I tried to simulate your setup but I'm regretting it now. My test repo
expanded to 10x its original size with 900 packs. Git is also painfully
slow now while I'm trying to repack it properly back into a single pack.
However I wasn't able to reproduce your repository growth. Please
retest with a vanilla Git version.
I think you should really consider using an unlimited pack size. Not
only you'll save quite a lot of disk space, but Git will be much faster
too. And Git itself is far more efficient than rsync at keeping Git
repositories in sync, regardless of pack sizes (unless you have too many
packs of course).
Nicolas
^ permalink raw reply
* Re: Unix root dir as a work tree
From: Nguyen Thai Ngoc Duy @ 2010-02-08 2:18 UTC (permalink / raw)
To: João Carlos Mendes Luís; +Cc: git
In-Reply-To: <4B6F6971.6000106@jonny.eng.br>
2010/2/8 João Carlos Mendes Luís <jonny@jonny.eng.br>:
> Now, I have a patch that appears to work, but since I am a beginner to git,
> I don't know if this is the best way to implement it, if it has any side
> effects, or even if it works for other operating systems (probably they
> don't even have the bug). Would any git wizard care to look at it, check if
> it is ok, and maybe commit in HEAD or give me any advice against my patch?
Hmm.. I guess you put .git at root directory so you needed your patch.
I haven't tried it yet because I don't have root access here.
Anyway you may also need the below patch. Please report back if any
Git operation that does not work under your setup.
diff --git a/setup.c b/setup.c
index 710e2f3..d31dcb8 100644
--- a/setup.c
+++ b/setup.c
@@ -25,7 +25,7 @@ const char *prefix_path(const char *prefix, int len,
const char *path)
len = strlen(work_tree);
total = strlen(sanitized) + 1;
if (strncmp(sanitized, work_tree, len) ||
- (sanitized[len] != '\0' && sanitized[len] != '/')) {
+ (len > 1 && sanitized[len] != '\0' && sanitized[len] != '/')) {
error_out:
die("'%s' is outside repository", orig);
}
--
Duy
^ permalink raw reply related
* [ANNOUNCE] Git 1.7.0.rc2
From: Junio C Hamano @ 2010-02-08 2:18 UTC (permalink / raw)
To: git
A release candidate Git 1.7.0.rc2 is available at the usual places
for testing:
http://www.kernel.org/pub/software/scm/git/
git-1.7.0.rc2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.7.0.rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.7.0.rc2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.7.0.rc2-1.fc11.$arch.rpm (RPM)
Hopefully this is the final -rc before the real thing in a few days.
----------------------------------------------------------------
Git v1.7.0 Release Notes (draft)
========================
Notes on behaviour change
-------------------------
* "git push" into a branch that is currently checked out (i.e. pointed by
HEAD in a repository that is not bare) is refused by default.
Similarly, "git push $there :$killed" to delete the branch $killed
in a remote repository $there, when $killed branch is the current
branch pointed at by its HEAD, will be refused by default.
Setting the configuration variables receive.denyCurrentBranch and
receive.denyDeleteCurrent to 'ignore' in the receiving repository
can be used to override these safety features.
* "git send-email" does not make deep threads by default when sending a
patch series with more than two messages. All messages will be sent
as a reply to the first message, i.e. cover letter.
It has been possible to configure send-email to send "shallow thread"
by setting sendemail.chainreplyto configuration variable to false. The
only thing this release does is to change the default when you haven't
configured that variable.
* "git status" is not "git commit --dry-run" anymore. This change does
not affect you if you run the command without argument.
* "git diff" traditionally treated various "ignore whitespace" options
only as a way to filter the patch output. "git diff --exit-code -b"
exited with non-zero status even if all changes were about changing the
ammount of whitespace and nothing else. and "git diff -b" showed the
"diff --git" header line for such a change without patch text.
In this release, the "ignore whitespaces" options affect the semantics
of the diff operation. A change that does not affect anything but
whitespaces is reported with zero exit status when run with
--exit-code, and there is no "diff --git" header for such a change.
* External diff and textconv helpers are now executed using the shell.
This makes them consistent with other programs executed by git, and
allows you to pass command-line parameters to the helpers. Any helper
paths containing spaces or other metacharacters now need to be
shell-quoted. The affected helpers are GIT_EXTERNAL_DIFF in the
environment, and diff.*.command and diff.*.textconv in the config
file.
* The --max-pack-size argument to 'git repack', 'git pack-objects', and
'git fast-import' was assuming the provided size to be expressed in MiB,
unlike the corresponding config variable and other similar options accepting
a size value. It is now expecting a size expressed in bytes, with a possible
unit suffix of 'k', 'm', or 'g'.
Updates since v1.6.6
--------------------
(subsystems)
* "git fast-import" updates; adds "option" and "feature" to detect the
mismatch between fast-import and the frontends that produce the input
stream.
* "git svn" support of subversion "merge tickets" and miscellaneous fixes.
* "gitk" updates.
* "gitweb" updates (code clean-up, load checking etc.)
(portability)
* Some more MSVC portability patches for msysgit port.
* Minimum Pthreads emulation for msysgit port.
(performance)
* More performance improvement patches for msysgit port.
(usability, bells and whistles)
* More commands learned "--quiet" and "--[no-]progress" options.
* Various commands given by the end user (e.g. diff.type.textconv,
and GIT_EDITOR) can be specified with command line arguments. E.g. it
is now possible to say "[diff "utf8doc"] textconv = nkf -w".
* "sparse checkout" feature allows only part of the work tree to be
checked out.
* HTTP transfer can use authentication scheme other than basic
(i.e./e.g. digest).
* Switching from a version of superproject that used to have a submodule
to another version of superproject that no longer has it did not remove
the submodule directory when it should (namely, when you are not
interested in the submodule at all and didn't clone/checkout).
* A new attribute conflict-marker-size can be used to change the size of
the conflict markers from the default 7; this is useful when tracked
contents (e.g. git-merge documentation) have strings that resemble the
conflict markers.
* A new syntax "<branch>@{upstream}" can be used on the command line to
substitute the name of the "upstream" of the branch. Missing branch
defaults to the current branch, so "git fetch && git merge @{upstream}"
will be equivalent to "git pull".
* "git branch --set-upstream" can be used to update the (surprise!) upstream
i.e. where the branch is supposed to pull and merge from (or rebase onto).
* "git checkout A...B" is a way to detach HEAD at the merge base between
A and B.
* "git checkout -m path" to reset the work tree file back into the
conflicted state works even when you already ran "git add path" and
resolved the conflicts.
* "git commit --date='<date>'" can be used to override the author date
just like "git commit --author='<name> <email>'" can be used to
override the author identity.
* "git commit --no-status" can be used to omit the listing of the index
and the work tree status in the editor used to prepare the log message.
* "git commit" warns a bit more aggressively until you configure user.email,
whose default value almost always is not (and fundamentally cannot be)
what you want.
* "git difftool" has been extended to make it easier to integrate it
with gitk.
* "git fetch --all" can now be used in place of "git remote update".
* "git grep" does not rely on external grep anymore. It can use more than
one threads to accelerate the operation.
* "git grep" learned "--quiet" option.
* "git log" and friends learned "--glob=heads/*" syntax that is a more
flexible way to complement "--branches/--tags/--remotes".
* "git merge" learned to pass options specific to strategy-backends. E.g.
- "git merge -Xsubtree=path/to/directory" can be used to tell the subtree
strategy how much to shift the trees explicitly.
- "git merge -Xtheirs" can be used to auto-merge as much as possible,
while discarding your own changes and taking merged version in
conflicted regions.
* "git push" learned "git push origin --delete branch", a syntactic sugar
for "git push origin :branch".
* "git push" learned "git push --set-upstream origin forker:forkee" that
lets you configure your "forker" branch to later pull from "forkee"
branch at "origin".
* "git rebase --onto A...B" means the history is replayed on top of the
merge base between A and B.
* "git rebase -i" learned new action "fixup", that squashes the change
but does not affect existing log message.
* "git rebase -i" also learned --autosquash option, that is useful
together with the new "fixup" action.
* "git remote" learned set-url subcommand, to update (surprise!) url
for an existing remote nickname.
* "git rerere" learned "forget path" subcommand. Together with "git
checkout -m path" it will be useful when you recorded a wrong
resolution.
* Use of "git reset --merge" has become easier when resetting away a
conflicted mess left in the work tree.
* "git rerere" had rerere.autoupdate configuration but there was no way
to countermand it from the command line; --no-rerere-autoupdate option
given to "merge", "revert", etc. fixes this.
* "git status" learned "-s(hort)" output format.
(developers)
* The infrastructure to build foreign SCM interface has been updated.
* Many more commands are now built-in.
* THREADED_DELTA_SEARCH is no more. If you build with threads, delta
compression will always take advantage of it.
Fixes since v1.6.6
------------------
All of the fixes in v1.6.6.X maintenance series are included in this
release, unless otherwise noted.
* "git branch -d branch" used to refuse deleting the branch even when
the branch is fully merged to its upstream branch if it is not merged
to the current branch. It now deletes it in such a case.
* "git config -f <relative path>" run from a subdirectory misbehaved.
65807ee (builtin-config: Fix crash when using "-f <relative path>"
from non-root dir, 2010-01-26) may be merged to older maintenance
branches.
* "git fast-import" did not correctly handle large blobs that may
bust the pack size limit.
* When using "git status" or asking "git diff" to compare the work tree
with something, they used to consider that a checked-out submodule with
uncommitted changes is not modified; this could cause people to forget
committing these changes in the submodule before committing in the
superproject. They now consider such a change as a modification and
"git diff" will append a "-dirty" to the work tree side when generating
patch output or when used with the --submodule option.
^ permalink raw reply
* What's cooking in git.git (Feb 2010, #02; Sun, 07)
From: Junio C Hamano @ 2010-02-08 2:19 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
There shouldn't be anything exciting to see here right now. Please test
"master" branch to avoid giving regressions to end users; we are at
1.7.0-rc2 and I am hoping that we can release the 1.7.0 on the 10th.
--------------------------------------------------
[New Topics]
* sp/maint-push-sideband (2010-02-05) 6 commits
- receive-pack: Send hook output over side band #2
- receive-pack: Wrap status reports inside side-band-64k
- receive-pack: Refactor how capabilities are shown to the client
- send-pack: demultiplex a sideband stream with status data
- run-command: support custom fd-set in async
- run-command: Allow stderr to be a caller supplied pipe
(this branch is used by sp/push-sideband.)
Based on 1.6.5 maintenance track
* sp/push-sideband (2010-02-05) 0 commits
(this branch uses sp/maint-push-sideband.)
And my conflict resolution in #ifdef WINDOWS codepath (meaning: untested,
please check).
* ac/cvsimport-revision-mapping (2010-02-06) 1 commit
- cvsimport: new -R option: generate .git/cvs-revisions mapping
* jc/maint-1.6.3-imap-send-bool-config-fix (2010-02-06) 1 commit
- imap-send: fix longstanding configuration parser bug
* js/rebase-origin-x (2010-02-05) 1 commit
- [RFC w/o test and incomplete] rebase: add -x option to record original commit name
* rs/git-dir-cleanup (2010-02-06) 2 commits
(merged to 'next' on 2010-02-06 at ef8ab9b)
+ Resurrect "git grep --no-index"
+ setenv(GIT_DIR) clean-up
* jc/typo (2010-02-03) 1 commit
- Typofixes outside documentation area
* jk/grep-double-dash (2010-02-06) 1 commit
(merged to 'next' on 2010-02-07 at 2ac040d)
+ accept "git grep -- pattern"
--------------------------------------------------
[Cooking]
* jn/maint-makedepend (2010-01-26) 5 commits
- Makefile: drop dependency on $(wildcard */*.h)
- Makefile: clean up http-walker.o dependency rules
- Makefile: remove wt-status.h from LIB_H
- Makefile: make sure test helpers are rebuilt when headers change
- Makefile: add missing header file dependencies
(this branch is used by jn/makedepend and jn/master-makedepend.)
These look sensible clean-up that could go to maint later.
* jn/master-makedepend (2010-01-26) 0 commits
(this branch uses jn/maint-makedepend; is used by jn/makedepend.)
This is to help merging the clean-up to "master".
* jn/makedepend (2010-01-31) 9 commits
- Makefile: always remove .depend directories on 'make clean'
- Makefile: tuck away generated makefile fragments in .depend
- Teach Makefile to check header dependencies
- Makefile: list standalone program object files in PROGRAM_OBJS
- Makefile: lazily compute header dependencies
- Makefile: list generated object files in OBJECTS
- Makefile: disable default implicit rules
- Makefile: rearrange dependency rules
- Makefile: transport.o depends on branch.h now
(this branch uses jn/maint-makedepend and jn/master-makedepend.)
And this is to build on top. I don't want to touch build infrastructure
during the pre-release freeze too much to avoid the last minute hassles
that is only discovered when I try to cut RPMs; hence this will stay out
of 'master' until 1.7.0 ships.
* jc/checkout-detached (2010-01-29) 1 commit
- Reword "detached HEAD" notification
* jc/maint-fix-test-perm (2010-01-30) 2 commits
- lib-patch-mode.sh: Fix permission
- t6000lib: Fix permission
* jh/gitweb-caching (2010-01-30) 1 commit
- gitweb: Add an option to force version match
* jn/makefile-script-lib (2010-01-31) 1 commit
- Do not install shell libraries executable
* mv/request-pull-modernize (2010-01-29) 1 commit
- request-pull: avoid mentioning that the start point is a single commit
* cc/reset-keep (2010-01-19) 5 commits
- reset: disallow using --keep when there are unmerged entries
- reset: disallow "reset --keep" outside a work tree
- Documentation: reset: describe new "--keep" option
- reset: add test cases for "--keep" option
- reset: add option "--keep" to "git reset"
* jh/notes (2010-01-27) 23 commits
- builtin-notes: Add "add" subcommand for appending to note objects
- builtin-notes: Add "list" subcommand for listing note objects
- Documentation: Generalize git-notes docs to 'objects' instead of 'commits'
- builtin-notes: Add "prune" subcommand for removing notes for missing objects
- Notes API: prune_notes(): Prune notes that belong to non-existing objects
- t3305: Verify that removing notes triggers automatic fanout consolidation
- builtin-notes: Add "remove" subcommand for removing existing notes
- Teach builtin-notes to remove empty notes
- Teach notes code to properly preserve non-notes in the notes tree
- t3305: Verify that adding many notes with git-notes triggers increased fanout
- t3301: Verify successful annotation of non-commits
- Builtin-ify git-notes
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: write_notes_tree(): Store the notes tree in the database
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: remove_note(): Remove note objects from the notes tree structure
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Add tests for checking correct handling of $GIT_NOTES_REF and core.notesRef
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Cosmetic fixes to notes.c
* jc/grep-author-all-match-implicit (2010-01-17) 1 commit
- "log --author=me --grep=it" should find intersection, not union
^ 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