* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Jeff King @ 2012-10-29 6:18 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: git, Junio C Hamano
In-Reply-To: <20121029060524.GB4457@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 02:05:24AM -0400, Jeff King wrote:
> > i have a file with exactly 12288(0x3000) bytes in the repository.
> > When the file is loaded, the data is placed luckily so the data end
> > falls at a page boundary.
> > Later diff_grep() calls regexec() which calls strlen() on the loaded buffer
> > and ends up reading beyond the actual data into the next page
> > which is not allocated and causes a pagefault.
> > Or it could possibly (randomly) match the regex on data that is not
> > actually part of a file...
>
> Yuck. For the most part, we treat blob content (and generally most
> object content) as a sized buffer. However, there are some spots which,
> either through laziness or because a code interface expects a string, we
> pass the value as a string. This works because the object-reading code
> puts an extra NUL at the end of our buffer to handle just such an
> instance. So we might prematurely end if the object contains embedded
> NULs, but we would never read past the end.
>
> The code to read the output of a textconv filter does not do this
> explicitly. I would think it would get it for free by virtue of reading
> into a strbuf, though. I'll try to investigate.
I can't seem to replicate the problem here, even under valgrind. Do you
have a minimal test case?
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: improve the example of overriding LESS via core.pager
From: Jeff King @ 2012-10-29 6:26 UTC (permalink / raw)
To: Patrick Palka; +Cc: git
In-Reply-To: <1351455166-2579-1-git-send-email-patrick@parcs.ath.cx>
On Sun, Oct 28, 2012 at 04:12:46PM -0400, Patrick Palka wrote:
> You can override an option set in the LESS variable by simply prefixing
> the command line option with `-+`. This is more robust than the previous
> example if the default LESS options are to ever change.
Yeah, the current description is quite tortured and complex. I wondered
if there might be some reason, but I think it is simply that fee7545 was
over-zealous in adopting the original text. Yours is much more sensible.
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] gitk: simplify file filtering
From: Johannes Sixt @ 2012-10-29 6:46 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Paul Mackerras
In-Reply-To: <1351185801-18543-2-git-send-email-felipe.contreras@gmail.com>
Am 10/25/2012 19:23, schrieb Felipe Contreras:
> git diff is perfectly able to do this with '-- files', no need for
> manual filtering.
It would have been very useful if you summarized what the code did before
this change.
As for the change itself, it seems to make sense to use git diff's path
limiting instead of some home-grown method.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/2] gitk: handle --full-diff correctly
From: Johannes Sixt @ 2012-10-29 6:52 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Paul Mackerras
In-Reply-To: <1351185801-18543-3-git-send-email-felipe.contreras@gmail.com>
Am 10/25/2012 19:23, schrieb Felipe Contreras:
> Otherwise the files are missing from the diff, and the list of files.
>
> We do this by creating a limitdiffs variable specific for the view which
> can be turned of by using --full-diff.
It would be very helpful if you described the problem. "Try it yourself"
is not the answer. In particular, what does "correctly" mean in this
context? Isn't the subject more like "gitk: handle --full-diff" in the
sense that it wasn't handled at all previously and it did what it happened
to do?
The patch breaks gitk's builtin "limit to listed paths" option - with the
patch, the option is only honored at startup, but not when it is changed
during the session when --full-diff is not given. Don't know what should
happen if it is given.
-- Hannes
^ permalink raw reply
* Re: [PATCH] replace: parse revision argument for -d
From: Jeff King @ 2012-10-29 6:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <807340e40adb1fc97cd97161fe1fabd292bc79c3.1351258394.git.git@drmicha.warpmail.net>
On Fri, Oct 26, 2012 at 03:33:27PM +0200, Michael J Gruber wrote:
> for (p = argv; *p; p++) {
> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
> + q = *p;
> + if (get_sha1(q, sha1))
> + warning("Failed to resolve '%s' as a valid ref; taking it literally.", q);
> + else
> + q = sha1_to_hex(sha1);
Doesn't get_sha1 already handle this for 40-byte sha1s (and for anything
else, it would not work anyway)?
-Peff
^ permalink raw reply
* Re: [PATCH v2] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-29 7:06 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <003101cdb29f$7c8d9490$75a8bdb0$@schmitz-digital.de>
On Thu, Oct 25, 2012 at 12:57:10PM +0200, Joachim Schmitz wrote:
> diff --git a/Makefile b/Makefile
> index f69979e..35380dd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> MKDIR_WO_TRAILING_SLASH = YesPlease
> # RFE 10-120912-4693 submitted to HP NonStop development.
> NO_SETITIMER = UnfortunatelyYes
> +
> + # for 'make test'
> + # some test don't work with /bin/diff, some fail with /bin/tar
> + # some need bash, and some need /usr/local/bin in PATH first
> + SHELL_PATH=/usr/local/bin/bash
> + SANE_TOOL_PATH=/usr/local/bin
I think we can drop these comments, as the reasoning really should just
go in the commit message.
> + # as of H06.25/J06.14, we might better use this
> + #SHELL_PATH=/usr/coreutils/bin/bash
> + #SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
Is there any reason not to put both into the default SANE_TOOL_PATH? If
/usr/coreutils/bin does not exist on older versions, it will be a
harmless no-op. I guess we arestuck with picking one $SHELL_PATH,
though.
-Peff
^ permalink raw reply
* Re: [PATCH] Teach rm to remove submodules when given with a trailing '/'
From: Johannes Sixt @ 2012-10-29 7:11 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List, Jeff King
In-Reply-To: <508DBF92.9090200@web.de>
Am 10/29/2012 0:28, schrieb Jens Lehmann:
> + /* Remove trailing '/' from directories to find submodules in the index */
> + for (i = 0; i < argc; i++) {
> + size_t pathlen = strlen(argv[i]);
> + if (pathlen && is_directory(argv[i]) && (argv[i][pathlen - 1] == '/'))
> + argv[i] = xmemdupz(argv[i], pathlen - 1);
> + }
> +
> pathspec = get_pathspec(prefix, argv);
> refresh_index(&the_index, REFRESH_QUIET, pathspec, NULL, NULL);
That's wrong: Either move the check below get_pathspec() (which normalizes
backslashes to forward-slashes on Windows) or use is_dir_sep().
But isn't it somewhat dangerous to check pathspec for existance in the
worktree without interpreting them? Think of magic pathspec syntax (that
we do not have yet, but which may materialize sometime in the future).
-- Hannes
^ permalink raw reply
* Re: gitweb
From: Jakub Narębski @ 2012-10-29 7:12 UTC (permalink / raw)
To: Jeff King; +Cc: rh, git
In-Reply-To: <20121029052815.GA30186@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 6:28 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Oct 28, 2012 at 04:56:47PM -0700, rh wrote:
>
>> I'm not using gitweb I was thinking about using it and was looking at the
>> cgi and saw this in this file:
>> https://github.com/git/git/blob/master/gitweb/gitweb.perl
>>
>> I think I understand the intention but the outcome is wrong.
>>
>> our %highlight_ext = (
>> # main extensions, defining name of syntax;
>> # see files in /usr/share/highlight/langDefs/ directory
>> map { $_ => $_ }
>> qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make),
>> # alternate extensions, see /etc/highlight/filetypes.conf
>> 'h' => 'c',
[...]
> Yeah, this is wrong. The first map will eat the rest of the list, and
> you will get "h => h", "cxx => cxx", and so forth. I do not know this
> chunk of code, but that does not seem like it is the likely intent.
>
> You could fix it with extra parentheses:
>
> our %he = (
> (map { $_ => $_ } qw(py c cpp ...)),
> 'h' => 'c',
> (map { $_ => 'sh' } qw(bash zsh ksh)),
> ... etc ...
> );
>
>> I think the intent is better met with this, (the print is for show)
>>
>> our %he = ();
>> $he{'h'} = 'c';
>> $he{$_} = $_ for (qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make));
>> $he{$_} = 'cpp' for (qw(cxx c++ cc));
[...]
> That is more readable to me (though it does lose the obviousness that it
> is a variable initialization).
>
> Looks like this was broken since 592ea41 (gitweb: Refactor syntax
> highlighting support, 2010-04-27). I do not use gitweb (nor highlight)
> at all, but I'd guess the user-visible impact is that "*.h" files are
> not correctly highlighted
>
> Jakub, can you confirm the intent and a fix like the one above makes
> things better?
Yes, either of those makes things better.
> (unless highlight does this extension mapping
> itself, but then why are we doing it here?).
Highlight does extension mapping itself... but for that it needs file name,
and not to be feed file contents from pipe.
--
Jakub Narebski
^ permalink raw reply
* Re: git push tags
From: Angelo Borsotti @ 2012-10-29 7:13 UTC (permalink / raw)
To: Philip Oakley; +Cc: Chris Rorvick, Johannes Sixt, git
In-Reply-To: <4B8097A9D6854CDFA27E7CF6574B37BA@PhilipOakley>
Hi,
Pro Git, By Scott Chacon says:
2.6
"Like most VCSs, Git has the ability to tag specific points in
history as being important.
Generally, people use this functionality to mark release points (v1.0,
and so on)."
2.6.2:
"A [lightweight] tag is very much like a branch that does not change ..."
Clearly, tags are not the same as branches. They are there for a
different purpose. If they were exactly the same as branches, there
would be no need for them.
Of course, they share some behaviors with branches, and there are
several commands that handle them in the same way, but the key point
is that they do not change, or at least they do not do that by
default. The ability to force changes of tags is there only to correct
tags that might have set tags to the wrong points by mistake.
So, what I am telling is that this property must be preserved
consistently across all commands, including git-push.
-Angelo
^ permalink raw reply
* Re: gitweb
From: Jeff King @ 2012-10-29 7:14 UTC (permalink / raw)
To: Jakub Narębski; +Cc: rh, git
In-Reply-To: <CANQwDwd6EP94PEFkEcx8gBX1B5+-95qtjGMD6iU3ao8G+rCbLw@mail.gmail.com>
On Mon, Oct 29, 2012 at 08:12:46AM +0100, Jakub Narębski wrote:
> > Jakub, can you confirm the intent and a fix like the one above makes
> > things better?
>
> Yes, either of those makes things better.
Thanks.
> > (unless highlight does this extension mapping
> > itself, but then why are we doing it here?).
>
> Highlight does extension mapping itself... but for that it needs file name,
> and not to be feed file contents from pipe.
Ah, that makes sense.
Richard, do you want to roll a patch that fixes it?
-Peff
^ permalink raw reply
* Re: [PATCH] submodule status: remove unused orig_* variables
From: Jeff King @ 2012-10-29 7:27 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Phil Hord, Git Mailing List, phil.hord
In-Reply-To: <508DA58C.2040504@web.de>
On Sun, Oct 28, 2012 at 10:37:16PM +0100, Jens Lehmann wrote:
> When renaming orig_args to orig_flags in 98dbe63d (submodule: only
> preserve flags across recursive status/update invocations) the call site
> of the recursive cmd_status was forgotten. At that place orig_args is
> still passed into the recursion, which is always empty since then. This
> did not break anything because the orig_flags logic is not needed at all
> when a function from the submodule script is called with eval, as that
> inherits all the variables set by the option parsing done in the first
> level of the recursion.
>
> Now that we know that orig_flags and orig_args aren't needed at all,
> let's just remove them from cmd_status().
>
> Thanks-to: Phil Hord <hordp@cisco.com>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
I'll replace your earlier fix (which just fixes the s/args/flags/ and
adds a test) with Phil's patch, and this on top.
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH 0/7] Move code from builtin to libgit.a
From: Jeff King @ 2012-10-29 7:43 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1351266835-22610-1-git-send-email-pclouds@gmail.com>
On Fri, Oct 26, 2012 at 10:53:48PM +0700, Nguyen Thai Ngoc Duy wrote:
> These two are big code moves, basically all {fetch,send}-pack code.
> While I think this is good cleanup (I get surprise every time I look
> at transport.c and it leads to buitin/fetch-pack.c), this is probably
> not a good idea if we have on flight topics, which may cause lots of
> conflicts for you and Junio. Fortunately we don't at the moment.
>
> Nguyễn Thái Ngọc Duy (7):
> Move try_merge_command and checkout_fast_forward to libgit.a
> Move estimate_bisect_steps to libgit.a
> Move print_commit_list to libgit.a
> Move setup_diff_pager to libgit.a
> send-pack: move core code to libgit.a
> fetch-pack: remove global (static) configuration variable "args"
> fetch-pack: move core code to libgit.a
This does not seem to disturb anything in pu, so I am very tempted.
I tweaked the last one, which removed the inclusion of pkt-line.h from
builtin/fetch-pack.c; it is still needed by the use of packet_read_line
when reading stateless rpc refs from stdin (caught by "-Wall -Werror").
-Peff
^ permalink raw reply
* Re: [PATCH] Add -S, --gpg-sign option to manpage of "git commit"
From: Jeff King @ 2012-10-29 7:49 UTC (permalink / raw)
To: Tom Jones; +Cc: git
In-Reply-To: <20121023225101.189E57D4C@ralph.oxix.org>
On Sun, Oct 21, 2012 at 08:46:37PM +0100, Tom Jones wrote:
> git commit -S, --gpg-sign was mentioned in the program's help message,
> but not in the manpage.
>
> This adds an equivalent entry for the option in the manpage.
>
> Signed-off-by: Tom Jones <tom@oxix.org>
Thanks. This slipped through the cracks last week, but I've picked it up
now.
> DESCRIPTION
> -----------
> @@ -276,6 +276,10 @@ configuration variable documented in linkgit:git-config[1].
> commit message template when using an editor to prepare the
> default commit message.
>
> +-S[<keyid>]::
> +--gpg-sign[=<keyid>]::
> + GPG-sign commit.
> +
Potentially we could say more (like how to verify), but I will leave
that for somebody to build on top if they want.
-Peff
^ permalink raw reply
* Re: git push tags
From: Angelo Borsotti @ 2012-10-29 8:12 UTC (permalink / raw)
To: Philip Oakley; +Cc: Chris Rorvick, Johannes Sixt, git
In-Reply-To: <CAB9Jk9BmMMDLsY=kU5o-c4XF6fN3O44h_vXe3d=WF-W9HTBh_g@mail.gmail.com>
Hi,
to let the owner of a remote repository (one on which git-push
deposits objects) disallow
others to change tags, a key on its config file could be used.
An option on git-push, or environment variable, or key in config file
of the repo from which git-push takes objects do not help in enforcing
the policy not to update tags in the remote repo.
-Angelo
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Jeff King @ 2012-10-29 8:50 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Michael J Gruber
In-Reply-To: <1351396453-29042-1-git-send-email-felipe.contreras@gmail.com>
On Sun, Oct 28, 2012 at 04:54:00AM +0100, Felipe Contreras wrote:
> I've ported the tests from hg-git and made sure that the output from remote-hg
> matches the output of hg-git. With these extensive tests I would consider this
> one ready for wide use. Not only do the tests pass, I've compared the generated
> repos of a few projects, and the SHA-1's are exactly the same :)
Sounds cool. Unfortunately, the test script hangs for me, after starting
up xxdiff (!).
pstree reveals that it is "hg" that starts it, but I didn't investigate
beyond that.
-Peff
^ permalink raw reply
* Re: [PATCH] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-10-29 9:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121029065836.GC5102@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 29.10.2012 07:58:
> On Fri, Oct 26, 2012 at 03:33:27PM +0200, Michael J Gruber wrote:
>
>> for (p = argv; *p; p++) {
>> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
>> + q = *p;
>> + if (get_sha1(q, sha1))
>> + warning("Failed to resolve '%s' as a valid ref; taking it literally.", q);
>> + else
>> + q = sha1_to_hex(sha1);
>
> Doesn't get_sha1 already handle this for 40-byte sha1s (and for anything
> else, it would not work anyway)?
What is "this"???
So far, "git replace -d <rev>" only accepts a full sha1, because it uses
it literally as a ref name "resf/replace/<rev>" without resolving anything.
The patch makes it so that <rev> gets resolved to a sha1 even if it is
abbreviated, and then it gets used.
Or do you mean the warning?
Michael
^ permalink raw reply
* Re: [PATCH] replace: parse revision argument for -d
From: Jeff King @ 2012-10-29 9:04 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <508E4637.2060903@drmicha.warpmail.net>
On Mon, Oct 29, 2012 at 10:02:47AM +0100, Michael J Gruber wrote:
> Jeff King venit, vidit, dixit 29.10.2012 07:58:
> > On Fri, Oct 26, 2012 at 03:33:27PM +0200, Michael J Gruber wrote:
> >
> >> for (p = argv; *p; p++) {
> >> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
> >> + q = *p;
> >> + if (get_sha1(q, sha1))
> >> + warning("Failed to resolve '%s' as a valid ref; taking it literally.", q);
> >> + else
> >> + q = sha1_to_hex(sha1);
> >
> > Doesn't get_sha1 already handle this for 40-byte sha1s (and for anything
> > else, it would not work anyway)?
>
> What is "this"???
>
> So far, "git replace -d <rev>" only accepts a full sha1, because it uses
> it literally as a ref name "resf/replace/<rev>" without resolving anything.
>
> The patch makes it so that <rev> gets resolved to a sha1 even if it is
> abbreviated, and then it gets used.
>
> Or do you mean the warning?
Sorry, yeah, I meant the warning and fallback.
If I understand correctly, the fallback will never work unless we are
fed a 40-byte sha1. But get_sha1 should always return a 40-byte sha1
without doing any further processing.
-Peff
^ permalink raw reply
* Re: [PATCH] gitk: Do not select file list entries during diff loading
From: Stefan Haller @ 2012-10-29 8:56 UTC (permalink / raw)
To: Peter Oberndorfer, git; +Cc: Paul Mackerras
In-Reply-To: <508B08CB.5060702@arcor.de>
Peter Oberndorfer <kumbayo84@arcor.de> wrote:
> Please review/test the patch carefully before applying,
> since i do not often work with tcl/tk :-)
The patch makes perfect sense to me. (I'm not a great tcl coder either
though, and not very familiar with the gitk code; so another review
would be helpful.)
Just one minor suggestion:
> proc scrolltext {f0 f1} {
> - global searchstring cmitmode ctext
> + global searchstring cmitmode ctext ctext_last_scroll_pos
> global suppress_highlighting_file_for_this_scrollpos
>
> + .bleft.bottom.sb set $f0 $f1
> + if {$searchstring ne {}} {
> + searchmarkvisible 0
> + }
> +
> set topidx [$ctext index @0,0]
> + if {$topidx eq $ctext_last_scroll_pos} return
> + set ctext_last_scroll_pos $topidx
> +
> if {![info exists suppress_highlighting_file_for_this_scrollpos]
> || $topidx ne $suppress_highlighting_file_for_this_scrollpos} {
> highlightfile_for_scrollpos $topidx
> }
>
> catch {unset suppress_highlighting_file_for_this_scrollpos}
> -
> - .bleft.bottom.sb set $f0 $f1
> - if {$searchstring ne {}} {
> - searchmarkvisible 0
> - }
> }
I don't like early returns, they can easily become a source of bugs when
someone adds more code to the end of a function without realizing that
there's an early return in the middle. I'd much rather say something
like
if {$topidx ne $ctext_last_scroll_pos} {
if {![info exists suppress_highlighting_file_for_this_scrollpos]
|| $topidx ne $suppress_highlighting_file_for_this_scrollpos} {
highlightfile_for_scrollpos $topidx
}
set ctext_last_scroll_pos $topidx
}
-Stefan
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: git push tags
From: Michael Haggerty @ 2012-10-29 9:58 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: Philip Oakley, Chris Rorvick, Johannes Sixt, git
In-Reply-To: <CAB9Jk9AOBGL785rSo1FLQd4pKpHRdvmJ21wWsZ=L0z7SF=6Suw@mail.gmail.com>
I agree with you that it is too easy to create chaos by changing tags in
a published repository and that git should do more to prevent this from
happening without explicit user forcing. The fact that git internally
handles tags similarly to other references is IMO an excuse for the
current behavior, but not a justification.
On 10/29/2012 09:12 AM, Angelo Borsotti wrote:
> to let the owner of a remote repository (one on which git-push
> deposits objects) disallow
> others to change tags, a key on its config file could be used.
> An option on git-push, or environment variable, or key in config file
> of the repo from which git-push takes objects do not help in enforcing
> the policy not to update tags in the remote repo.
If your remote repository is managed using gitolite, you can institute
restrictions on changing tags via the gitolite config.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-10-29 10:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121029090419.GA29464@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 29.10.2012 10:04:
> On Mon, Oct 29, 2012 at 10:02:47AM +0100, Michael J Gruber wrote:
>
>> Jeff King venit, vidit, dixit 29.10.2012 07:58:
>>> On Fri, Oct 26, 2012 at 03:33:27PM +0200, Michael J Gruber wrote:
>>>
>>>> for (p = argv; *p; p++) {
>>>> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
>>>> + q = *p;
>>>> + if (get_sha1(q, sha1))
>>>> + warning("Failed to resolve '%s' as a valid ref; taking it literally.", q);
>>>> + else
>>>> + q = sha1_to_hex(sha1);
>>>
>>> Doesn't get_sha1 already handle this for 40-byte sha1s (and for anything
>>> else, it would not work anyway)?
>>
>> What is "this"???
>>
>> So far, "git replace -d <rev>" only accepts a full sha1, because it uses
>> it literally as a ref name "resf/replace/<rev>" without resolving anything.
>>
>> The patch makes it so that <rev> gets resolved to a sha1 even if it is
>> abbreviated, and then it gets used.
>>
>> Or do you mean the warning?
>
> Sorry, yeah, I meant the warning and fallback.
>
> If I understand correctly, the fallback will never work unless we are
> fed a 40-byte sha1. But get_sha1 should always return a 40-byte sha1
> without doing any further processing.
You do understand correctly, and I misunderstood get_sha1(). I does not
check for the presence of that sha1 in the object db, so that it
succeeds no matter what, that is: if it's valid hex. So I should
probably rewrite the error handling: no more need to check for lengths.
Michael
^ permalink raw reply
* Re: git push tags
From: Kacper Kornet @ 2012-10-29 10:10 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: Philip Oakley, Chris Rorvick, Johannes Sixt, git
In-Reply-To: <CAB9Jk9AOBGL785rSo1FLQd4pKpHRdvmJ21wWsZ=L0z7SF=6Suw@mail.gmail.com>
On Mon, Oct 29, 2012 at 09:12:52AM +0100, Angelo Borsotti wrote:
> Hi,
> to let the owner of a remote repository (one on which git-push
> deposits objects) disallow
> others to change tags, a key on its config file could be used.
> An option on git-push, or environment variable, or key in config file
> of the repo from which git-push takes objects do not help in enforcing
> the policy not to update tags in the remote repo.
It think these are two separate issues:
1. Enforcing policy that the server should not accept changes in
existing tags. This can be easily done with hooks.
2. Perform operation: push my tag if and only if it doesn't overwrite
tag which already exists on the server. I think currently it is not possible
with git.
--
Kacper
^ permalink raw reply
* What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Jeff King @ 2012-10-29 10:21 UTC (permalink / raw)
To: git
What's cooking in git.git (Oct 2012, #09; Mon, 29)
--------------------------------------------------
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 second batch of topics has graduated to master. Most of the new
topics have been minor bugfixes or documentation updates, so I've merged
a lot of those to master.
You can find the changes described here in the integration branches of
my repository at:
git://github.com/peff/git.git
Until Junio returns, kernel.org and the other "usual" places will not be
updated.
--------------------------------------------------
[New Topics]
* fc/completion-test-simplification (2012-10-29) 2 commits
- completion: simplify __gitcomp test helper
- completion: refactor __gitcomp related tests
Clean up completion tests.
Will merge to 'next'.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
* jk/maint-diff-grep-textconv (2012-10-28) 1 commit
- diff_grep: use textconv buffers for add/deleted files
(this branch is used by jk/pickaxe-textconv.)
Fixes inconsistent use of textconv with "git log -G".
Will merge to 'next'.
* jk/pickaxe-textconv (2012-10-28) 2 commits
- pickaxe: use textconv for -S counting
- pickaxe: hoist empty needle check
(this branch uses jk/maint-diff-grep-textconv.)
Use textconv filters when searching with "log -S".
Waiting for a sanity check and review from Junio.
* km/maint-doc-git-reset (2012-10-29) 1 commit
(merged to 'next' on 2012-10-29 at cdb4e8f)
+ doc: git-reset: make "<mode>" optional
Will merge to 'master' in the third batch.
* mh/maint-parse-dirstat-fix (2012-10-29) 1 commit
- parse_dirstat_params(): use string_list to split comma-separated string
Cleans up some code and avoids a potential bug.
Will merge to 'next'.
* nd/builtin-to-libgit (2012-10-29) 7 commits
- fetch-pack: move core code to libgit.a
- fetch-pack: remove global (static) configuration variable "args"
- send-pack: move core code to libgit.a
- Move setup_diff_pager to libgit.a
- Move print_commit_list to libgit.a
- Move estimate_bisect_steps to libgit.a
- Move try_merge_command and checkout_fast_forward to libgit.a
Code cleanups so that libgit.a does not depend on anything in the
builtin/ directory.
Some of the code movement is pretty big, but there doesn't seem to be
any conflicts with topics in flight.
Will merge to 'next'.
* ph/maint-submodule-status-fix (2012-10-29) 2 commits
- submodule status: remove unused orig_* variables
- t7407: Fix recursive submodule test
Cleans up some leftover bits from an earlier submodule change.
Will merge to 'next'.
* pp/maint-doc-pager-config (2012-10-29) 1 commit
(merged to 'next' on 2012-10-29 at 434fbd0)
+ Documentation: improve the example of overriding LESS via core.pager
Will merge to 'master' in the third batch.
* rf/maint-mailmap-off-by-one (2012-10-28) 1 commit
(merged to 'next' on 2012-10-29 at 8c2214b)
+ mailmap: avoid out-of-bounds memory access
Will merge to 'master' in the third batch.
* sz/maint-submodule-reference-arg (2012-10-26) 1 commit
(merged to 'next' on 2012-10-29 at 1aab03c)
+ submodule add: fix handling of --reference=<repo> option
Will merge to 'master' in the third batch.
* tb/maint-t9200-case-insensitive (2012-10-28) 1 commit
(merged to 'next' on 2012-10-29 at 62af90c)
+ Fix t9200 on case insensitive file systems
Will merge to 'master' in the third batch.
* tj/maint-doc-commit-sign (2012-10-29) 1 commit
(merged to 'next' on 2012-10-29 at 44c61a0)
+ Add -S, --gpg-sign option to manpage of "git commit"
Will merge to 'master' in the third batch.
--------------------------------------------------
[Graduated to "master"]
* jc/grep-pcre-loose-ends (2012-10-09) 7 commits
(merged to 'next' on 2012-10-25 at 2ea9b27)
+ log: honor grep.* configuration
+ log --grep: accept --basic-regexp and --perl-regexp
+ log --grep: use the same helper to set -E/-F options as "git grep"
+ revisions: initialize revs->grep_filter using grep_init()
+ grep: move pattern-type bits support to top-level grep.[ch]
+ grep: move the configuration parsing logic to grep.[ch]
+ builtin/grep.c: make configuration callback more reusable
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally. The early part of this series is a fix for it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/maint-http-init-not-in-result-handler (2012-10-12) 2 commits
(merged to 'next' on 2012-10-25 at 59d3687)
+ http: do not set up curl auth after a 401
+ remote-curl: do not call run_slot repeatedly
Further clean-up to the http codepath that picks up results after
cURL library is done with one request slot.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/sh-setup-in-filter-branch (2012-10-18) 2 commits
(merged to 'next' on 2012-10-25 at 3879f0e)
+ filter-branch: use git-sh-setup's ident parsing functions
+ git-sh-setup: refactor ident-parsing functions
Will merge to 'master' in the second batch after 1.8.0 ships.
* jl/submodule-add-by-name (2012-09-30) 2 commits
(merged to 'next' on 2012-10-25 at a322082)
+ submodule add: Fail when .git/modules/<name> already exists unless forced
+ Teach "git submodule add" the --name option
If you remove a submodule, in order to keep the repository so that
"git checkout" to an older commit in the superproject history can
resurrect the submodule, the real repository will stay in $GIT_DIR
of the superproject. A later "git submodule add $path" to add a
different submodule at the same path will fail. Diagnose this case
a bit better, and if the user really wants to add an unrelated
submodule at the same path, give the "--name" option to give it a
place in $GIT_DIR of the superproject that does not conflict with
the original submodule.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jl/submodule-rm (2012-09-29) 1 commit
(merged to 'next' on 2012-10-25 at 0fb5876)
+ submodule: teach rm to remove submodules unless they contain a git directory
"git rm submodule" cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/grep-true-path (2012-10-12) 1 commit
(merged to 'next' on 2012-10-25 at 1c7d320)
+ grep: stop looking at random places for .gitattributes
"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/status-long (2012-10-18) 1 commit
(merged to 'next' on 2012-10-25 at ff1b3a0)
+ status: add --long output format option
Allow an earlier "--short" option on the command line to be
countermanded with the "--long" option for "git status" and "git
commit".
Will merge to 'master' in the second batch after 1.8.0 ships.
* rs/branch-del-symref (2012-10-18) 5 commits
(merged to 'next' on 2012-10-25 at c2cd358)
+ branch: show targets of deleted symrefs, not sha1s
+ branch: skip commit checks when deleting symref branches
+ branch: delete symref branch, not its target
+ branch: factor out delete_branch_config()
+ branch: factor out check_branch_commit()
(this branch is used by jh/update-ref-d-through-symref.)
A symbolic ref refs/heads/SYM was not correctly removed with
"git branch -d SYM"; the command removed the ref pointed by
SYM instead.
Will merge to 'master' in the second batch after 1.8.0 ships.
--------------------------------------------------
[Stalled]
* 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.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* 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-10-07) 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.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- 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 ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* 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 reroll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* mh/ceiling (2012-10-29) 8 commits
- 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.
* mo/cvs-server-cleanup (2012-10-26) 11 commits
(merged to 'next' on 2012-10-29 at 4e70622)
+ Use character class for sed expression instead of \s
(merged to 'next' on 2012-10-25 at c70881d)
+ cvsserver status: provide real sticky info
+ cvsserver: cvs add: do not expand directory arguments
+ cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
+ cvsserver: split up long lines in req_{status,diff,log}
+ cvsserver: clean up client request handler map comments
+ cvsserver: remove unused functions _headrev and gethistory
+ cvsserver update: comment about how we shouldn't remove a user-modified file
+ cvsserver: add comments about database schema/usage
+ cvsserver: removed unused sha1Or-k mode from kopts_from_path
+ cvsserver t9400: add basic 'cvs log' test
(this branch is tangled with mo/cvs-server-updates.)
Cleanups to prepare for mo/cvs-server-updates.
Will merge to 'master' in the fourth batch.
* mo/cvs-server-updates (2012-10-16) 20 commits
- 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
(merged to 'next' on 2012-10-25 at c70881d)
+ cvsserver status: provide real sticky info
+ cvsserver: cvs add: do not expand directory arguments
+ cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
+ cvsserver: split up long lines in req_{status,diff,log}
+ cvsserver: clean up client request handler map comments
+ cvsserver: remove unused functions _headrev and gethistory
+ cvsserver update: comment about how we shouldn't remove a user-modified file
+ cvsserver: add comments about database schema/usage
+ cvsserver: removed unused sha1Or-k mode from kopts_from_path
+ cvsserver t9400: add basic 'cvs log' test
(this branch is tangled with mo/cvs-server-cleanup.)
Needs review by folks interested in cvsserver.
* ta/doc-cleanup (2012-10-25) 6 commits
- Documentation: build html for all files in technical and howto
- Documentation/howto: convert plain text files to asciidoc
- Documentation/technical: convert plain text files to asciidoc
- Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
- Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
- Split over-long synopsis in git-fetch-pack.txt into several lines
Misapplication of a patch fixed; the ones near the tip needs to
update the links to point at the html files, though.
Needs follow-up on Junio's comment above.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
- Fix "git diff --stat" for interesting - but empty - file changes
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.
Needs some test updates.
* jc/prettier-pretty-note (2012-10-26) 11 commits
- Doc User-Manual: Patch cover letter, three dashes, and --notes
- Doc format-patch: clarify --notes use case
- Doc notes: Include the format-patch --notes option
- Doc SubmittingPatches: Mention --notes option after "cover letter"
- Documentation: decribe format-patch --notes
- format-patch --notes: show notes after three-dashes
- format-patch: append --signature after notes
- pretty_print_commit(): do not append notes message
- pretty: prepare notes message at a centralized place
- format_note(): simplify API
- pretty: remove reencode_commit_message()
Now that Philip has submitted some documentation updates, this is
looking more ready.
Will merge to 'next'.
* sz/maint-curl-multi-timeout (2012-10-19) 1 commit
- Fix potential hang in https handshake
Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
Detect this and reduce the wait timeout in such a case.
Will merge to 'next'.
* jc/same-encoding (2012-10-18) 1 commit
- reencode_string(): introduce and use same_encoding()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
Will merge to 'next' after fixing up commit message.
* nd/tree-walk-enum-cleanup (2012-10-19) 1 commit
- tree-walk: use enum interesting instead of integer
Will merge to 'next'.
* cr/cvsimport-local-zone (2012-10-16) 1 commit
- git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
Will merge to 'next'.
* fc/completion-send-email-with-format-patch (2012-10-16) 1 commit
- completion: add format-patch options to send-email
Will merge to 'next'.
* fc/zsh-completion (2012-10-29) 3 commits
- completion: add new zsh completion
- completion: add new __gitcompadd helper
- completion: get rid of empty COMPREPLY assignments
Needs comments from completion folks.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- 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.
Extra set of eyeballs appreciated.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- 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; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* rs/lock-correct-ref-during-delete (2012-10-16) 1 commit
(merged to 'next' on 2012-10-25 at 9341eea)
+ refs: lock symref that is to be deleted, not its target
When "update-ref -d --no-deref SYM" tried to delete a symbolic ref
SYM, it incorrectly locked the underlying reference pointed by SYM,
not the symbolic ref itself.
Will merge to 'master' in the fourth batch.
* as/check-ignore (2012-10-29) 13 commits
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- 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
(this branch uses nd/attr-match-optim-more; is tangled with nd/wildmatch.)
Duy helped to reroll this.
Expecting another re-roll.
* js/format-2047 (2012-10-18) 7 commits
(merged to 'next' on 2012-10-25 at 76d91fe)
+ format-patch tests: check quoting/encoding in To: and Cc: headers
+ format-patch: fix rfc2047 address encoding with respect to rfc822 specials
+ format-patch: make rfc2047 encoding more strict
+ format-patch: introduce helper function last_line_length()
+ format-patch: do not wrap rfc2047 encoded headers too late
+ format-patch: do not wrap non-rfc2047 headers too early
+ utf8: fix off-by-one wrapping of text
Fixes many rfc2047 quoting issues in the output from format-patch.
Will merge to 'master' in the fourth batch.
* km/send-email-compose-encoding (2012-10-25) 5 commits
(merged to 'next' on 2012-10-29 at d7d2bb4)
+ git-send-email: add rfc2047 quoting for "=?"
+ git-send-email: introduce quote_subject()
+ git-send-email: skip RFC2047 quoting for ASCII subjects
+ git-send-email: use compose-encoding for Subject
(merged to 'next' on 2012-10-25 at 5447367)
+ git-send-email: introduce compose-encoding
"git send-email --compose" can let the user create a non-ascii
cover letter message, but there was not a way to mark it with
appropriate content type before sending it out.
Further updates fix subject quoting.
Will merge to 'master' in the fourth batch.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-25 at 79565a1)
+ coloured git-prompt: paint detached HEAD marker in red
+ Fix up colored git-prompt
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
Will 'cook' in next.
* 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.
* nd/wildmatch (2012-10-15) 13 commits
(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 uses nd/attr-match-optim-more; is tangled with as/check-ignore.)
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'.
* 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.
* nd/attr-match-optim-more (2012-10-15) 7 commits
(merged to 'next' on 2012-10-25 at 09f70ce)
+ attr: more matching optimizations from .gitignore
+ gitignore: make pattern parsing code a separate function
+ exclude: split pathname matching code into a separate function
+ exclude: fix a bug in prefix compare optimization
+ exclude: split basename matching code into a separate function
+ exclude: stricten a length check in EXC_FLAG_ENDSWITH case
+ Merge commit 'f9f6e2c' into nd/attr-match-optim-more
(this branch is used by as/check-ignore and nd/wildmatch.)
Start laying the foundation to build the "wildmatch" after we can
agree on its desired semantics.
Will merge to 'master' in the fourth batch.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
. pretty: support %>> that steal trailing spaces
. pretty: support truncating in %>, %< and %><
. pretty: support padding placeholders, %< %> and %><
. pretty: two phase conversion for non utf-8 commits
. utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
. utf8.c: move display_mode_esc_sequence_len() for use by other functions
. pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
. pretty: split parsing %C into a separate function
. pretty: share code between format_decoration and show_decorations
This causes warnings with -Wuninitialized, so I've ejected it from pu
for the time being.
* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit
- get_fetch_map(): tighten checks on dest refs
This was split out from discarded jc/maint-push-refs-all topic.
Will merge to 'next'.
* jh/symbolic-ref-d (2012-10-21) 1 commit
- git symbolic-ref --delete $symref
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.
It is already possible to remove a symbolic ref with "update-ref -d
--no-deref", but it may be a good addition for completeness.
Will merge to 'next'.
* jh/update-ref-d-through-symref (2012-10-21) 2 commits
- Fix failure to delete a packed ref through a symref
- t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
* gb/maint-doc-svn-log-window-size (2012-10-26) 1 commit
(merged to 'next' on 2012-10-29 at ee50b22)
+ Document git-svn fetch --log-window-size parameter
Will merge to 'master' in the third batch.
* jk/config-ignore-duplicates (2012-10-29) 9 commits
(merged to 'next' on 2012-10-29 at 67fa0a2)
+ builtin/config.c: Fix a sparse warning
(merged to 'next' on 2012-10-25 at 233df08)
+ git-config: use git_config_with_options
+ git-config: do not complain about duplicate entries
+ git-config: collect values instead of immediately printing
+ git-config: fix regexp memory leaks on error conditions
+ git-config: remove memory leak of key regexp
+ t1300: test "git config --get-all" more thoroughly
+ t1300: remove redundant test
+ t1300: style updates
Drop duplicate detection from git-config; this lets it
better match the internal config callbacks, which clears up
some corner cases with includes.
Will cook in 'next'.
* mm/maint-doc-remote-tracking (2012-10-25) 1 commit
(merged to 'next' on 2012-10-25 at 80f1592)
+ Documentation: remote tracking branch -> remote-tracking branch
We long ago hyphenated "remote-tracking branch"; this
catches some new instances added since then.
Will merge to 'master' in the third batch.
* ph/pull-rebase-detached (2012-10-25) 1 commit
(merged to 'next' on 2012-10-25 at 73d9d14)
+ git-pull: Avoid merge-base on detached head
Avoids spewing error messages when using "pull --rebase" on a
detached HEAD.
Will merge to 'master' in the third batch.
* ph/submodule-sync-recursive (2012-10-29) 2 commits
- Add tests for submodule sync --recursive
- Teach --recursive to submodule sync
Adds "--recursive" option to submodule sync.
Will merge to 'next'.
* po/maint-refs-replace-docs (2012-10-25) 1 commit
(merged to 'next' on 2012-10-25 at 3874c9d)
+ Doc repository-layout: Show refs/replace
The refs/replace hierarchy was not mentioned in the
repository-layout docs.
Will merge to 'master' in the third batch.
* sl/maint-configure-messages (2012-10-25) 1 commit
(merged to 'next' on 2012-10-25 at e1d7ecd)
+ configure: fix some output message
Minor message fixes for the configure script.
Will merge to 'master' in the third batch.
^ permalink raw reply
* Re: [PATCH 4/5] diff: introduce diff.submoduleFormat configuration variable
From: Ramkumar Ramachandra @ 2012-10-29 10:30 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git List
In-Reply-To: <506C4161.3040201@web.de>
Jens Lehmann wrote:
> Am 02.10.2012 21:44, schrieb Jens Lehmann:
>> Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
>>> Introduce a diff.submoduleFormat configuration variable corresponding
>>> to the '--submodule' command-line option of 'git diff'.
>>
>> Nice. Maybe a better name would be "diff.submodule", as this sets the
>> default for the "--submodule" option of diff?
>>
>> And I think you should also test in t4041 that "--submodule=short"
>> overrides the config setting.
>
> We also need tests which show that setting that config to "log" does
> not break one of the many users of "git diff" ("stash", "rebase" and
> "format-patch" come to mind, most probably I missed some others). I
> suspect we'll have to add "--submodule=short" options to some call
> sites to keep them working with submodule changes.
Um, why would "stash", "rebase" or "format-patch" be affected by this
setting? They don't operate on submodules at all. To be sure, I ran
all the tests with the following diff and nothing broke.
Confused,
Ram
-- 8< --
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 514282c..904a81c 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -608,6 +608,8 @@ fi
# in subprocesses like git equals our $PWD (for pathname comparisons).
cd -P "$test" || exit 1
+git config test.submodule log
+
this_test=${0##*/}
this_test=${this_test%%-*}
for skp in $GIT_SKIP_TESTS
^ permalink raw reply related
* Re: git push tags
From: Jeff King @ 2012-10-29 10:38 UTC (permalink / raw)
To: Michael Haggerty
Cc: Angelo Borsotti, Philip Oakley, Chris Rorvick, Johannes Sixt, git
In-Reply-To: <508E532F.2010109@alum.mit.edu>
On Mon, Oct 29, 2012 at 10:58:07AM +0100, Michael Haggerty wrote:
> I agree with you that it is too easy to create chaos by changing tags in
> a published repository and that git should do more to prevent this from
> happening without explicit user forcing. The fact that git internally
> handles tags similarly to other references is IMO an excuse for the
> current behavior, but not a justification.
I would have expected git to at least complain about updating an
annotated tag with another annotated tag. But it actually uses the same
fast-forward rule, just on the pointed-to commits. So a fast-forward
annotated re-tag will throw away the old tag object completely. Which
seems a bit crazy to me.
It seems like a no-brainer to me that annotated tags should not replace
each other without a force, no matter where in the refs hierarchy they
go.
For lightweight tags, I think it's more gray. They are just pointers
into history. Some projects may use them to tag immutable official
versions, but I also see them used as shared bookmarks. Requiring "-f"
may make the latter use more annoying. On the other hand, bookmark tags
tend not to be pushed, or if they are, it is part of a mirror-like
backup which should be forcing all updates anyway.
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-29 10:45 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029053401.GB30186@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
On Mon, Oct 29, 2012 at 01:34:01AM -0400, Jeff King wrote:
> On Sun, Oct 28, 2012 at 06:34:31PM -0400, W. Trevor King wrote:
>
> > On Sun, Oct 28, 2012 at 02:59:33PM -0700, Shawn Pearce wrote:
> > > Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
> > > updates the parent project as if you had done:
> > >
> > > $ git submodule foreach 'git checkout $(git config --file
> > > $toplevel/.gitmodules submodule.$name.branch) && git pull'
> > > $ git commit -a -m "Updated submodules"
> > > $ git push
> >
> > Ah, good, then we *are* all using the option for the same thing.
>
> That makes me more comfortable. Your patch adds support for setting the
> variable initially. Does it need any special magic for maintenance, or
> is it something that would always be updated by hand?
Everyone we've heard from so far interprets the setting as “pull from
$branch in the remote repository $url to update the submodule”. With
Phil's export, that would become
$ git submodule foreach 'git checkout "$submodule_branch" && git pull'
$ git commit -a -m "Updated submodules"
$ git push
As Nahor mentioned on the 23rd, there are a number of ways that the
upstream branch could disappear, but Git has no way to know what the
new branch setting should be. This means that even if we make “pull
from $branch” interpretation official, we still couldn't do anything
slick about updating it. So, yes, it will be updated by hand.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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