* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Jeff King @ 2012-11-14 19:02 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Torsten Bögershausen, git
In-Reply-To: <50A2F17D.4010907@gmail.com>
On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote:
> On 11/13/2012 03:45 PM, Torsten Bögershausen wrote:
> >>* ml/cygwin-mingw-headers (2012-11-12) 1 commit
> >> - Update cygwin.c for new mingw-64 win32 api headers
> >>
> >> Make git work on newer cygwin.
> >>
> >> Will merge to 'next'.
> >(Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)
> >(And thanks for maintaining git)
> >
> >Is everybody using cygwin happy with this?
> >
> >I managed to compile on a fresh installed cygwin,
> >but failed to compile under 1.7.7, see below.
> >Is there a way we can achieve to compile git both under "old" and "new" cygwin 1.7 ?
> >Or is this not worth the effort?
> >
> I found no version info defined that could be used to automatically
> switch between the old and current headers. You can always
>
> make V15_MINGW_HEADERS=1 ...
>
> to force using the old set if you do not wish to update your installation.
Should we keep the code change, then, but not flip the default (i.e.,
make people on the newer version opt into it)? I am not clear on how
common the newer include system is. Of course, auto-detecting would be
the ideal.
-Peff
^ permalink raw reply
* Re: [PATCH 1/6] ident: make user_ident_explicitly_given private
From: Jeff King @ 2012-11-14 19:11 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Santi Béjar
In-Reply-To: <20121114164457.GA6858@elie.Belkin>
On Wed, Nov 14, 2012 at 08:44:57AM -0800, Jonathan Nieder wrote:
> > -#define IDENT_NAME_GIVEN 01
> > -#define IDENT_MAIL_GIVEN 02
> > -#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
> > -extern int user_ident_explicitly_given;
> > extern int user_ident_sufficiently_given(void);
>
> In v1.5.6-rc0~56^2 (2008-05-04) "user_ident_explicitly_given" was
> introduced as a global for communication between config, ident, and
> builtin-commit. In v1.7.0-rc0~72^2 (2010-01-07) readers switched to
> using the common wrapper user_ident_sufficiently_given(). After
> v1.7.11-rc1~15^2~18 (2012-05-21) the var is only written in ident.c,
> and the variable can finally be made static.
Thanks for digging up the history. I remembered trying to do this before
during the ident refactoring that went into v1.7.11, but it didn't work
then for some reason (I think it was probably an earlier iteration of
the series, and then I forgot to revisit it during the final one).
I'll add your explanation to the commit message if I re-roll.
-Peff
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Phil Hord @ 2012-11-14 19:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <7vfw4caxkh.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Phil Hord <hordp@cisco.com> writes:
>
>> Consider the usage:
>>
>> git status # show work-tree status
>> git status --short # show short work-tree status
>> git status --tokens # show work-tree status in token form
> OK, your --tokens is more about *how* things are output, but it is
> unclear how it would interact with --short. I had an impression
> that you are basing your output on the short output, whose existing
> record include "##" (that shows the branch names and states), and
> "MM", "A " and friends (that show the per-file states), by adding
> new record types that shows tree-wide states.
I am, but I don't much care for the "##" prefix, especially when
combined with --null, for example. I'm inclined to remove it when
--short is not provided, specifically to give scripts an easier time of
parsing. But scripts are likely to need "--porcelain" as well, and
currently that implies "--short". But I suppose another combination
could be meaningful.
# tokens only
$ git status --tree
changed-files
# tokens and short-status
$ git status --tree --short
## changed-files
M foo.txt
# short-status only
$ git status --porcelain
M foo.txt
# tokens only?
$ git status --tree --porcelain
changed-files
I think this spaghettify's the ui too much. Maybe this instead:
# undecorated tokens only
$ git status --tree=porcelain
changed-files
>
>> But maybe "--tokens" has some better meaning that someone will want to
>> use in the future. I'm not married to it. But "git status" already
>> means "Show the working tree status". So "git status --show-tree-state"
>> sounds redundant or meaningless.
> I didn't mean to say that you have to spell out all these words;
> "show" and "state" are redundant.
>
> The important part is that unlike the existing "per-file" state the
> "status" command is showing, the option is to add "tree-wide" state
> to the output, and my suggestion was to pick a word that makes it
> clear, rather than using "output is done using tokens" without
> saying "what is being output in tokenized form".
Thanks for clarifying.
Phil
^ permalink raw reply
* Re: [PATCH 3/6] var: accept multiple variables on the command line
From: Jeff King @ 2012-11-14 19:26 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121114170148.GB6858@elie.Belkin>
On Wed, Nov 14, 2012 at 09:01:48AM -0800, Jonathan Nieder wrote:
> > DESCRIPTION
> > -----------
> > -Prints a git logical variable.
> > +Prints one or more git logical variables, separated by newlines.
> > +
> > +Note that some variables may contain newlines themselves
>
> Maybe a -z option to NUL-terminate values would be useful some day.
Yeah, I thought about that but stopped short. The intended caller in my
series is Git.pm, whose command() splits on newlines. Although it is
perl...I suspect doing:
local $/ = "\0";
my @entries = command(...);
would work. For ident variables, we know they don't contain a newline,
though.
> > --- a/builtin/var.c
> > +++ b/builtin/var.c
> > @@ -73,8 +73,7 @@ static int show_config(const char *var, const char *value, void *cb)
> >
> > int cmd_var(int argc, const char **argv, const char *prefix)
> > {
> > - const char *val = NULL;
> > - if (argc != 2)
> > + if (argc < 2)
> > usage(var_usage);
> >
> > if (strcmp(argv[1], "-l") == 0) {
>
> What should happen if I pass "-l" followed by other arguments?
Good catch. Probably we should just call usage() once we see "-l"
and (argc > 2), which matches the previous behavior. I don't see much
point in listing specific variables after having listed them all.
I was also tempted to convert to parse_options, but I don't think that
really buys us anything (we could detect the option in "git var foo -l
bar", but since we are not going to do anything useful in such a case,
there is not much point).
> > + test_tick &&
> > + echo "A U Thor <author@example.com> 1112911993 -0700" >expect &&
>
> Do we need to hardcode the timestamp? Something like
>
> test_cmp_filtered () {
> expect=$1 actual=$2 &&
> sed -e 's/[0-9][0-9]* [-+][0-9][0-9][0-9][0-9]/TIMESTAMP" \
> <"$actual" >"$actual.filtered" &&
> test_cmp "$expect" "$actual.filtered"
> }
No, we don't have to. I was just hoping to keep the tests simple by not
doing any parsing trickery. The test_tick keeps it stable, but as you
note, it is not robust to reordering. I think it would be sufficient to
just put $GIT_COMMITTER_DATE into the expected output.
I'll fix both in a re-roll.
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
From: René Scharfe @ 2012-11-14 19:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nguyễn Thái Ngọc Duy, Git Mailing List,
Junio C Hamano, schnhrr
In-Reply-To: <CA+55aFynRG-CbSp-aLoo1iZTvfBWMgt6kwrPiQjSZJ0ZzraDKQ@mail.gmail.com>
Am 13.11.2012 20:50, schrieb Linus Torvalds:
> On Tue, Nov 13, 2012 at 11:40 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> I have to wonder why you care? As far as I'm concerned, the only valid
>> space is space, TAB and CR/LF.
>>
>> Anything else is *noise*, not space. What's the reason for even caring?
>
> Btw, expanding the whitespace selection may actually be very
> counter-productive. It is used primarily for things like removing
> extraneous space at the end of lines etc, and for that, the current
> selection of SPACE, TAB and LF/CR is the right thing to do.
>
> Adding things like FF etc - that are *technically* whitespace, but
> aren't the normal kind of silent whitespace - is potentially going to
> change things too much. People might *want* a form-feed in their
> messages, for all we know.
The patch was motivated by the integration of the wildmatch library,
which exposes named character classes to users. It replaces a call of
fnmatch in match_pathname. Users probably expect [:space:] to mean the
same in git as in other programs.
I never saw a vertical tab and I can't imagine what it's used for. I'd
expect form-feeds to be matched as space, though. Didn't see them very
often, admittedly.
Nevertheless, it's unfortunate that we have an isspace() that *almost*
does what the widely known thing of the same name does. I'd shy away
from changing git's version directly, because it's used more than a
hundred times in the code, and estimating the impact of adding \v and \f
to it. Perhaps renaming it to isgitspace() is a good first step,
followed by adding a "standard" version of isspace() for wildmatch?
René
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Junio C Hamano @ 2012-11-14 19:35 UTC (permalink / raw)
To: Phil Hord
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <50A3ED8A.9080604@cisco.com>
Phil Hord <hordp@cisco.com> writes:
> # tokens and short-status
> $ git status --tree --short
> ## changed-files
> M foo.txt
Hrm, how will the existing readers of the output avoid getting
confused by this overloading of "##", which has meant the current
branch information?
> # tokens only?
> $ git status --tree --porcelain
> changed-files
It probably is simpler for parsers of the --porcelain format if you
(1) always used first two bytes as the record type, and (2) avoided
using "##" that is already used for the tree-wide status.
Just a thought.
^ permalink raw reply
* Re: [PATCH 4/6] var: provide explicit/implicit ident information
From: Jeff King @ 2012-11-14 19:53 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121114170657.GC6858@elie.Belkin>
On Wed, Nov 14, 2012 at 09:06:57AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Internally, we keep track of whether the author or committer
> > ident information was provided by the user, or whether it
> > was implicitly determined by the system. However, there is
> > currently no way for external programs or scripts to get
> > this information
>
> What are the intended semantics? If my machine has /etc/mailname
> filled out, is that an implicit identity? How about if I set the
> EMAIL envvar but not GIT_COMMITTER_EMAIL?
>
> If external scripts are going to start using this mechanism, they will
> need answers to these questions to support users that run into
> configuration problems. A few words on this in the documentation
> could probably help.
The intent is to make git's internal rules (whatever they may be)
available to calling scripts. But I agree those rules should be spelled
out now that they are becoming a more visible interface. I'll update the
documentation.
> On most machines I have the EMAIL envvar set explicitly, but in the
> recent past I relied on /etc/mailname on some others, so I'm also
> genuinely curious about the use case here (and too lazy to dig it up).
Right now EMAIL is explicit, but `id`@`cat /etc/mailname` is not. I
think changing that would be a separate issue, though (and I'm not sure
whether it is a good idea; my /etc/mailname is not an email address I
would want to use).
-Peff
^ permalink raw reply
* Re: [PATCH 5/6] Git.pm: teach "ident" to query explicitness
From: Jeff King @ 2012-11-14 19:54 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121114171213.GD6858@elie.Belkin>
On Wed, Nov 14, 2012 at 09:12:13AM -0800, Jonathan Nieder wrote:
> > --- a/perl/Git.pm
> > +++ b/perl/Git.pm
> > @@ -737,7 +737,7 @@ sub remote_refs {
> > }
> >
> >
> > -=item ident ( TYPE | IDENTSTR )
> > +=item ident ( TYPE | IDENTSTR [, options] )
> >
> > =item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
> >
> > @@ -750,6 +750,10 @@ and either returns it as a scalar string or as an array with the fields parsed.
> > Alternatively, it can take a prepared ident string (e.g. from the commit
> > object) and just parse it.
> >
> > +If the C<explicit> option is set to 1, the returned array will contain an
> > +additional boolean specifying whether the ident was configure explicitly by the
> > +user.
>
> s/configure/configured/
>
> I'd suggest adding "See GIT_COMMITTER_EXPLICIT in git-var(1) for
> details" to make the semantics crystal clear. What do you think?
Good suggestion. Thanks.
-Peff
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Junio C Hamano @ 2012-11-14 19:57 UTC (permalink / raw)
To: Phil Hord
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <7v7gpoasf4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Phil Hord <hordp@cisco.com> writes:
>
>> # tokens and short-status
>> $ git status --tree --short
>> ## changed-files
>> M foo.txt
>
> Hrm, how will the existing readers of the output avoid getting
> confused by this overloading of "##", which has meant the current
> branch information?
That was a stupid question.
Existing readers do not know to give --tree to the command, so they
are perfectly OK.
It is however not OK for new readers that wants to read these
tree-wide state and also branch information.
^ permalink raw reply
* Re: [PATCH 6/6] send-email: do not prompt for explicit repo ident
From: Jeff King @ 2012-11-14 20:05 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121114171827.GE6858@elie.Belkin>
On Wed, Nov 14, 2012 at 09:18:27AM -0800, Jonathan Nieder wrote:
> > The test scripts need to be adjusted to not expect a prompt
> > for the sender, since they always have the author explicitly
> > defined in the environment. Unfortunately, we cannot
> > reliably test that prompting still happens in the implicit
> > case, as send-email will produce inconsistent results
> > depending on the machine config (if we cannot find a FQDN,
> > "git var" will barf, causing us to exit early;
>
> At first this sounded like a bug to me --- how could the user keep
> working without the sysadmin intervening?
>
> But then I remembered that the user can set her name and email in
> .gitconfig and probably would want to in such a setup anyway.
Right. They would already have to to make commits, for example.
> When someone writes such a test, I think it could check that git
> either prompts or writes a message advising to configure the user
> email, no? Waiting until later for that seems fine to me, though.
Yes. The problem is that the behavior and output are dependent on
factors outside the test suite, so we would have to check that one of
the possible expected outcomes happens. But I think there are really
only two such outcomes (neglecting that the ident itself can have
arbitrary content, but we do not have to check the actual content).
-Peff
^ permalink raw reply
* git init shared=group with a subdir
From: petesea @ 2012-11-14 20:00 UTC (permalink / raw)
To: git
I believe there may be a bug when initializing a new repository relating
to the directory permissions when the --shared=group option is used and
the repository is within a sub-directory.
The following will create the "test.git" directory with 2775 permissions
(which is as expected):
$ ls -ld test.git
ls: cannot access test.git: No such file or directory
$ git init --bare --shared=group test.git
Initialized empty shared Git repository in /tmp/test.git/
$ ls -ld test.git
drwxrwsr-x 7 pete users 4096 2012-11-14 11:15 test.git
This following will also create the "test.git" directory with 2775
permissions, BUT the "subdir" directory ends up with 755 permissions:
$ ls -ld subdir
ls: cannot access subdir: No such file or directory
$ git init --bare --shared=group subdir/test.git
Initialized empty shared Git repository in /tmp/subdir/test.git/
$ ls -ld subdir subdir/test.git
drwxr-xr-x 3 pete users 4096 2012-11-14 11:16 subdir
drwxrwsr-x 7 pete users 4096 2012-11-14 11:16 subdir/test.git
Assuming the "subdir" directory doesn't already exist and is created by
the "git init" command AND the --shared=group option is used, then
shouldn't the "subdir" directory also have 2775 permissions?
^ permalink raw reply
* Re: Bug? Subtree merge seems to choke on trailing slashes.
From: Junio C Hamano @ 2012-11-14 20:11 UTC (permalink / raw)
To: Jack O'Connor; +Cc: git
In-Reply-To: <CA+6di1nsWOGXjchOc3SZ2FL79zGzgNqjOJyN0zf8Yb8GbXCpbA@mail.gmail.com>
"Jack O'Connor" <oconnor663@gmail.com> writes:
> Do I have the right list for bug reports? Apologies if not.
Yes.
> On Tue, Nov 6, 2012 at 5:58 PM, Jack O'Connor <oconnor663@gmail.com> wrote:
>>
>> 2) I try to merge more upstream changes on top of that with the
>> following command:
>> git merge --strategy-option=subtree='test/' $upstream_stuff
>> 3) Git fails with an obscure error:
>> fatal: entry not found in tree daf4d0f0a20b8b6ec007be9fcafeac84a6eba4f0
I'd expect --strategy-option=subtree=./test, ././test (or ./test/
for that matter) would fail in a similar way, too.
What happens if you do not give an unnecessary '/' at the end?
If it works, I'd say that it falls into "dr. it hurts when I twist
my arm this way---don't do it then" category.
^ permalink raw reply
* Re: [PATCH 6/6] send-email: do not prompt for explicit repo ident
From: Jeff King @ 2012-11-14 20:26 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121114200505.GA13317@sigill.intra.peff.net>
On Wed, Nov 14, 2012 at 12:05:05PM -0800, Jeff King wrote:
> > When someone writes such a test, I think it could check that git
> > either prompts or writes a message advising to configure the user
> > email, no? Waiting until later for that seems fine to me, though.
>
> Yes. The problem is that the behavior and output are dependent on
> factors outside the test suite, so we would have to check that one of
> the possible expected outcomes happens. But I think there are really
> only two such outcomes (neglecting that the ident itself can have
> arbitrary content, but we do not have to check the actual content).
Actually, I think the simplest thing is to add a prerequisite, like:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 489bc80..8d192ff 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -738,6 +738,14 @@ test_lazy_prereq UTF8_NFD_TO_NFC '
esac
'
+test_lazy_prereq IMPLICIT_IDENT '
+ sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ git var GIT_AUTHOR_IDENT &&
+ # double check that we were not polluted by config
+ test "$(git var GIT_AUTHOR_EXPLICIT)" = 0
+'
+
# When the tests are run as root, permission tests will report that
# things are writable when they shouldn't be.
test -w / || test_set_prereq SANITY
We can't have one test machine that will cover all of the cases, but
given that the test suite is run by many people across many machines, we
will get coverage (and I know that some people have machines which would
not pass that prereq, because I got test failure reports during the last
ident refactoring).
I'll include something like that in my re-roll (and it should let us
test "git commit" more thoroughly, too).
-Peff
^ permalink raw reply related
* Re: git init shared=group with a subdir
From: Junio C Hamano @ 2012-11-14 20:29 UTC (permalink / raw)
To: petesea; +Cc: git
In-Reply-To: <alpine.OSX.2.00.1211141107180.737@nikto-air>
petesea@bigfoot.com writes:
> $ ls -ld subdir
> ls: cannot access subdir: No such file or directory
> $ git init --bare --shared=group subdir/test.git
> Initialized empty shared Git repository in /tmp/subdir/test.git/
> $ ls -ld subdir subdir/test.git
> drwxr-xr-x 3 pete users 4096 2012-11-14 11:16 subdir
> drwxrwsr-x 7 pete users 4096 2012-11-14 11:16 subdir/test.git
>
> Assuming the "subdir" directory doesn't already exist and is created
> by the "git init" command AND the --shared=group option is used, then
> shouldn't the "subdir" directory also have 2775 permissions?
People who access this "test.git" does not need to be able to write
into subdir/foobar, so the lack of w bit for the group is perfectly
fine, no? Depending on to whom you would want to expose things
other than "test.git" in "subdir", the desirable set of the
permission bits on "subdir" itself would be different, but the "git
init" command line does not give us enough information to infer what
exact mode is needed.
At least we should give r-x to the parent directories for the
classes of users to whom we give rwx to the repository itself. In
your example, since we give rwx to user=pete and group=users on
"test.git", "subdir" should have r-x (or better) for user=pete and
group=users, so that result happens to be correct.
But I do not think we did the right thing by design but it turned
out to be correct by accident. If your umask were 077 or something
tight, I suspect that we end up creating "subdir" with "rwx------",
and group members wouldn't be able to access "test.git". We may
want to loosen it down to "rwxr-x---" in such a case, but doing so
unconditionally risks exposing things inside "subdir" other than
"test.git" to your group members, and worse yet, we would be doing
so without telling the user. If your umask is set to a tight value,
it is likely that you did so on purpose, and it is debatable if it
is a good thing to do. It is safer to create these leading
directories like "subdir" honoring the umask, give the user a chance
to make sure that other things in "subdir" can be exposed to people
who have access to "test.git", and let the user handle the
permission (perhaps running "chmod g+rx subdir" as necessary). And
that is the behaviour you are observing, I think.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Torsten Bögershausen @ 2012-11-14 21:13 UTC (permalink / raw)
To: Jeff King; +Cc: Mark Levedahl, Torsten Bögershausen, git
In-Reply-To: <20121114190228.GA3860@sigill.intra.peff.net>
On 14.11.12 20:02, Jeff King wrote:
> On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote:
>
>> On 11/13/2012 03:45 PM, Torsten Bögershausen wrote:
>>>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit
>>>> - Update cygwin.c for new mingw-64 win32 api headers
>>>>
>>>> Make git work on newer cygwin.
>>>>
>>>> Will merge to 'next'.
>>> (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)
>>> (And thanks for maintaining git)
>>>
>>> Is everybody using cygwin happy with this?
>>>
>>> I managed to compile on a fresh installed cygwin,
>>> but failed to compile under 1.7.7, see below.
>>> Is there a way we can achieve to compile git both under "old" and "new" cygwin 1.7 ?
>>> Or is this not worth the effort?
>>>
>> I found no version info defined that could be used to automatically
>> switch between the old and current headers. You can always
>>
>> make V15_MINGW_HEADERS=1 ...
>>
>> to force using the old set if you do not wish to update your installation.
>
> Should we keep the code change, then, but not flip the default (i.e.,
> make people on the newer version opt into it)? I am not clear on how
> common the newer include system is. Of course, auto-detecting would be
> the ideal.
>
> -Peff
There are a couple of things which we may want consider:
a) the name V15_MINGW_HEADERS:
It indicates that this is true for Version 1.5 (of what?)
If I assume Cygwin version 1.5 , then this name is confusing.
Even cygwin versions like 1.7.7 use the same (or similar) include files as 1.5
A better name could be CYGWIN_USE_MINGW_HEADERS (or the like) and to revert the logic.
b) Autodetection:
(Just loud thinking), running
$grep mingw /usr/include/w32api/winsock2.h
* This file is part of the mingw-w64 runtime package.
#include <_mingw_unicode.h>
on cygwin 1.7.17 indicates that we can use grep in the Makefile to autodetect the "mingw headers"
Something like this in Makefile:
+ifeq ($(shell grep mingw /usr/include/w32api/winsock2.h />/dev/null 2>/dev/null && echo y),y)
+ CYGWIN_USE_MINGW_HEADERS=YesPlease
+endif
c) I'm not sure if we want to change cygwin.c or git-compat-util.h for this.
I can prepare a proper patch within the next couple of days
/Torsten
^ permalink raw reply
* Re: creation of empty branches
From: Junio C Hamano @ 2012-11-14 21:27 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Angelo Borsotti, git
In-Reply-To: <CAH5451mkcszgJxziKn3q3OwSDM-qQ71PtT5+UWb=PG7VYAcFyQ@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> Since git branch has the default behaviour to create a branch 'in the
> background' it makes sense to fail when trying to create a new branch
> this way from an empty branch. The error message should be improved to
> handle this edge case in a nicer way. If we allow for renaming empty
> branches (described below) then the message can be even more helpful.
> Instead of
> fatal: Not a valid object name: 'master'.
> perhaps
> fatal: Cannot create branch 'foo' from empty branch 'master'. To
> rename 'master' use 'git branch -m master foo'.
The first new sentence is a definite improvement, but I do not think
the advice in the second sentence is necessarily a good idea,
because it is dubious that the user is likely to have wanted to
rename 'master' to something else. "git branch foo master" (or its
moral equivalent "git checkout -b foo" while on master) is a wish to
have a history that ends in 'foo' *forked* from history of 'master',
but because you do not even have anything on 'master' yet, you
cannot fork the history, as you explained earlier (snipped). In
that sense, 'empty branch' is a slight misnomer---as far as "git
branch foo master" is concerned, the 'master' branch does not yet
exist (and that is why we often call it an "unborn branch", not
"empty").
fatal: cannot fork master's history that does not exist yet.
would be more accurate description of the situation.
> So explicitly, I am proposing the following behaviour changes:
>
> When trying to create a new branch without specifying a start point,
> if HEAD points to an empty branch, error with a more useful message
> that assumes the user might want to rename the empty branch.
I do not think that is the right assumption in the first place. It
is very likely that the user does not yet know how Git works when
she attempts to fork from a history that does not exist. It is also
very likely that she is expecting, after "git branch foo master"
succeeds when 'master' is yet to be born, have two branches 'foo'
and 'master', so that "git checkout foo" and "git checkout master"
can be done subsequently.
But that expectation is wrong, and it would help the user in the
longer run to correct that expectation. "We assume you wanted to
rename 'master' to 'foo'" is a logical consequence that changing
HEAD that points at an unborn 'master' to point at an unborn 'foo'
is the best (or closest) thing the user can do, *if* the user
understands that the current branch being unborn is a special state
and there can only be one such unborn branch (that is, the current
one). The user who gets this error message, however, clearly does
not understand that, so it is not a logical consequence to her at
all. The advice does not help her, but instead invites "No, I did
not want to rename it, I wanted to have 'foo' without losing
'master'", leading to even more confusion.
> When trying to create a new branch whilst specifying an empty branch
> as the start point,
> if HEAD points to the same empty branch that is listed as the start
> point, error with a more useful message that assumes the user might
> want to rename the empty branch.
> otherwise error due to invalid ref
See above (for all the other cases, too).
^ permalink raw reply
* What's cooking in git.git (Nov 2012, #04; Wed, 14)
From: Junio C Hamano @ 2012-11-14 22:42 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Big thanks go to Jeff who curated topics in flight while I was on
vacation. I merged a couple of topics to 'next', and will start
merging what he marked for 'master' after giving them a final look
by the end of the week.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jl/submodule-rm (2012-11-14) 1 commit
- docs: move submodule section
* sg/complete-help-undup (2012-11-14) 1 commit
- completion: remove 'help' duplicate from porcelain commands
--------------------------------------------------
[Stalled]
* 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.
* 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 re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
* 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.
--------------------------------------------------
[Cooking]
* jk/maint-gitweb-xss (2012-11-12) 1 commit
(merged to 'next' on 2012-11-14 at 7a667bc)
+ gitweb: escape html in rss title
Fixes an XSS vulnerability in gitweb.
* jk/send-email-sender-prompt (2012-11-13) 6 commits
- send-email: do not prompt for explicit repo ident
- Git.pm: teach "ident" to query explicitness
- var: provide explicit/implicit ident information
- var: accept multiple variables on the command line
- ident: keep separate "explicit" flags for author and committer
- ident: make user_ident_explicitly_given private
Avoid annoying sender prompt in git-send-email, but only when it is
safe to do so.
Needs review.
* mg/replace-resolve-delete (2012-11-13) 1 commit
(merged to 'next' on 2012-11-14 at fa785ae)
+ replace: parse revision argument for -d
Be more user friendly to people using "git replace -d".
* ml/cygwin-mingw-headers (2012-11-12) 1 commit
- Update cygwin.c for new mingw-64 win32 api headers
Make git work on newer cygwin.
Will merge to 'next'.
* mo/cvs-server-updates (2012-10-16) 10 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
Needs review by folks interested in cvsserver.
* ta/doc-cleanup (2012-10-25) 6 commits
(merged to 'next' on 2012-11-13 at e11fafd)
+ 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
Will merge to 'master' in the sixth batch.
* 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-11-13) 12 commits
(merged to 'next' on 2012-11-14 at 7230f26)
+ format-patch: add a blank line between notes and diffstat
(merged to 'next' on 2012-11-04 at 40e3e48)
+ 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()
Emit the notes attached to the commit in "format-patch --notes"
output after three-dashes.
Will merge to 'master' in the fifth batch.
* jc/same-encoding (2012-11-04) 1 commit
(merged to 'next' on 2012-11-04 at 54991f2)
+ 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 'master' in the fifth batch.
* cr/cvsimport-local-zone (2012-11-04) 2 commits
(merged to 'next' on 2012-11-04 at 292f0b4)
+ cvsimport: work around perl tzset issue
+ git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
Will merge to 'master' in the fifth batch.
* 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
There were some comments on this, but I wasn't clear on the outcome.
Need to take a closer look.
* 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?
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- 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
Duy helped to reroll this.
Expecting a re-roll.
* 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
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.
* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit
(merged to 'next' on 2012-11-04 at eda85ef)
+ get_fetch_map(): tighten checks on dest refs
This was split out from discarded jc/maint-push-refs-all topic.
Will merge to 'master' in the fifth batch.
* jh/symbolic-ref-d (2012-10-21) 1 commit
(merged to 'next' on 2012-11-04 at b0762f5)
+ 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 'master' in the fifth batch.
* 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.
Need to check reviews, but is probably ready for 'next'.
* 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 merge to 'master' in the sixth batch.
* ph/submodule-sync-recursive (2012-10-29) 2 commits
(merged to 'next' on 2012-11-04 at a000f78)
+ Add tests for submodule sync --recursive
+ Teach --recursive to submodule sync
Adds "--recursive" option to submodule sync.
Will merge to 'master' in the fifth batch.
* fc/completion-test-simplification (2012-10-29) 2 commits
- completion: simplify __gitcomp test helper
- completion: refactor __gitcomp related tests
Clean up completion tests.
There were some comments on the list.
Expecting a re-roll.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review.
* jk/maint-diff-grep-textconv (2012-10-28) 1 commit
(merged to 'next' on 2012-11-04 at 790337b)
+ 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 'master' in the fifth batch.
* 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.
* as/maint-doc-fix-no-post-rewrite (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at 117a91e)
+ commit: fixup misplacement of --no-post-rewrite description
Will merge to 'master' in the fifth batch.
* fc/remote-bzr (2012-11-08) 5 commits
- remote-bzr: update working tree
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- remote-bzr: add simple tests
- Add new remote-bzr transport helper
New remote helper for bzr.
Will merge to 'next'.
* fc/remote-hg (2012-11-12) 20 commits
- remote-hg: avoid bad refs
- remote-hg: try the 'tip' if no checkout present
- remote-hg: fix compatibility with older versions of hg
- remote-hg: add missing config for basic tests
- remote-hg: the author email can be null
- remote-hg: add option to not track branches
- remote-hg: add extra author test
- remote-hg: add tests to compare with hg-git
- remote-hg: add bidirectional tests
- test-lib: avoid full path to store test results
- remote-hg: add basic tests
- remote-hg: fake bookmark when there's none
- remote-hg: add compat for hg-git author fixes
- remote-hg: add support for hg-git compat mode
- remote-hg: match hg merge behavior
- remote-hg: make sure the encoding is correct
- remote-hg: add support to push URLs
- remote-hg: add support for remote pushing
- remote-hg: add support for pushing
- Add new remote-hg transport helper
New remote helper for hg.
Will merge to 'next'.
* jk/maint-http-half-auth-fetch (2012-10-31) 2 commits
(merged to 'next' on 2012-11-09 at af69926)
+ remote-curl: retry failed requests for auth even with gzip
+ remote-curl: hoist gzip buffer size to top of post_rpc
Fixes fetch from servers that ask for auth only during the actual
packing phase. This is not really a recommended configuration, but it
cleans up the code at the same time.
Will merge to 'master' in the sixth batch.
* js/hp-nonstop (2012-10-30) 1 commit
(merged to 'next' on 2012-11-09 at fe58205)
+ fix 'make test' for HP NonStop
Will merge to 'master' in the fifth batch.
* kb/preload-index-more (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at a750ebd)
+ update-index/diff-index: use core.preloadindex to improve performance
Use preloadindex in more places, which has a nice speedup on systems
with slow stat calls (and even on Linux).
Will merge to 'master' in the sixth batch.
* mh/notes-string-list (2012-11-08) 5 commits
(merged to 'next' on 2012-11-09 at 7a4c58c)
+ string_list_add_refs_from_colon_sep(): use string_list_split()
+ notes: fix handling of colon-separated values
+ combine_notes_cat_sort_uniq(): sort and dedup lines all at once
+ Initialize sort_uniq_list using named constant
+ string_list: add a function string_list_remove_empty_items()
Improve the asymptotic performance of the cat_sort_uniq notes merge
strategy.
Will merge to 'master' in the fifth batch.
* mh/strbuf-split (2012-11-04) 4 commits
(merged to 'next' on 2012-11-09 at fa984b1)
+ strbuf_split*(): document functions
+ strbuf_split*(): rename "delim" parameter to "terminator"
+ strbuf_split_buf(): simplify iteration
+ strbuf_split_buf(): use ALLOC_GROW()
Cleanups and documentation for strbuf_split.
Will merge to 'master' in the fifth batch.
* mm/maint-doc-commit-edit (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at 8dab7f5)
+ Document 'git commit --no-edit' explicitly
Will merge to 'master' in the fifth batch.
* cr/push-force-tag-update (2012-11-12) 5 commits
- push: update remote tags only with force
- push: flag updates that require force
- push: flag updates
- push: add advice for rejected tag reference
- push: return reject reasons via a mask
Require "-f" for push to update a tag, even if it is a fast-forward.
Needs review.
I'm undecided yet on whether the goal is the right thing to do, but it
does prevent some potential mistakes. I haven't looked closely at the
implementation itself; review from interested parties would be helpful.
* fc/fast-export-fixes (2012-11-08) 14 commits
- fast-export: don't handle uninteresting refs
- fast-export: make sure updated refs get updated
- fast-export: fix comparison in tests
- fast-export: trivial cleanup
- remote-testgit: make clear the 'done' feature
- remote-testgit: report success after an import
- remote-testgit: exercise more features
- remote-testgit: cleanup tests
- remote-testgit: remove irrelevant test
- remote-testgit: get rid of non-local functionality
- Add new simplified git-remote-testgit
- Rename git-remote-testgit to git-remote-testpy
- remote-testgit: fix direction of marks
- fast-export: avoid importing blob marks
Improvements to fix fast-export bugs, including how refs pointing to
already-seen commits are handled. An earlier 4-commit version of this
series looked good to me, but this much-expanded version has not seen
any comments.
Looks like it has been re-rolled, but I haven't checked it out yet.
Needs review.
* mg/maint-pull-suggest-upstream-to (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at bd74252)
+ push/pull: adjust missing upstream help text to changed interface
Follow-on to the new "--set-upstream-to" topic from v1.8.0 to avoid
suggesting the deprecated "--set-upstream".
Will merge to 'master' in the fifth batch.
* mh/alt-odb-string-list-cleanup (2012-11-08) 2 commits
(merged to 'next' on 2012-11-13 at 2bf41d9)
+ link_alt_odb_entries(): take (char *, len) rather than two pointers
+ link_alt_odb_entries(): use string_list_split_in_place()
Cleanups in the alternates code. Fixes a potential bug and makes the
code much cleaner.
Will merge to 'master' in the sixth batch.
* pf/editor-ignore-sigint (2012-11-11) 5 commits
- launch_editor: propagate SIGINT from editor to git
- run-command: do not warn about child death by SIGINT
- run-command: drop silent_exec_failure arg from wait_or_whine
- launch_editor: ignore SIGINT while the editor has control
- launch_editor: refactor to use start/finish_command
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Some people raised issues with emacsclient, which are addressed by this
re-roll. It should probably also handle SIGQUIT, and there were a
handful of other review comments.
Expecting a re-roll.
* pp/gitweb-config-underscore (2012-11-08) 1 commit
- gitweb: make remote_heads config setting work
The key "gitweb.remote_heads" is not legal git config; this maps it to
"gitweb.remoteheads".
Junio raised a good point about the implementation for three-level
variables.
Expecting a re-roll.
* pw/maint-p4-rcs-expansion-newline (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at e90cc7c)
+ git p4: RCS expansion should not span newlines
I do not have p4 to play with, but looks obviously correct to me.
Will merge to 'master' in the sixth batch.
* rh/maint-gitweb-highlight-ext (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at c57d856)
+ gitweb.perl: fix %highlight_ext mappings
Fixes a clever misuse of perl's list interpretation.
Will merge to 'master' in the sixth batch.
* rr/submodule-diff-config (2012-11-08) 3 commits
- submodule: display summary header in bold
- diff: introduce diff.submodule configuration variable
- Documentation: move diff.wordRegex from config.txt to diff-config.txt
Lets "git diff --submodule=log" become the default via configuration.
Almost there. Looks like a new version has been posted, but I haven't
picked it up yet.
Needs review.
^ permalink raw reply
* Re: "git am" crash (builtin/apply.c:2108) + small repro
From: Junio C Hamano @ 2012-11-14 22:50 UTC (permalink / raw)
To: Alexey Spiridonov; +Cc: git, Björn Gustavsson, Nguyen Thai Ngoc Duy
In-Reply-To: <CAOKKMFE=gwF4d+R2SD+3eRWqvZwkAt2hX8aPT8fvcwEZXiZbuQ@mail.gmail.com>
Alexey Spiridonov <snarkmaster@gmail.com> writes:
> Thanks for looking into this, guys!
>
> I seem to run into this with some regularity, but my setting is
> apply.whitespace=strip rather than 'fix'.
'strip' is an old synonym for 'fix'.
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Andreas Schwab @ 2012-11-14 23:15 UTC (permalink / raw)
To: Douglas Mencken; +Cc: Torsten Bögershausen, Ramsay Jones, git
In-Reply-To: <CACYvZ7g7nCgQmcnwJYxvx5hJ+Y8rCQOBQyWYLZOt8NT5BTwTrw@mail.gmail.com>
Douglas Mencken <dougmencken@gmail.com> writes:
>>>> I cannot reproduce the problem (on openSUSE 12.2).
>>>
>>> You do need multiple CPU/multi-core machine, as I got it.
>>
>> Which is what I have.
>
> Then try to build *vanilla* git 1.8.0,
Which is what I did.
> not OpenSuSE's one (with a lot of patches inside srcrpm).
Which lot of patches?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Fwd: Local clones aka forks disk size optimization
From: Javier Domingo @ 2012-11-14 23:42 UTC (permalink / raw)
To: git
In-Reply-To: <CALZVapmG+HL0SQx8zx=Cfz5pWv84hJq90x-7VdjA0m2Z4dC34A@mail.gmail.com>
Hi,
I have come up with this while doing some local forks for work.
Currently, when you clone a repo using a path (not file:/// protocol)
you get all the common objects linked.
But as you work, each one will continue growing on its way, although
they may have common objects.
Is there any way to avoid this? I mean, can something be done in git,
that it checks for (when pulling) the same objects in the other forks?
Thought this doesn't make much sense in clients, when you have to
maintain 20 forks of very big projects in server side, it eats
precious disk space.
I don't know how if this should have [RFC] in the subject or what. But
here is my idea.
As hardlinking is already done by git, if it checked for how many
links there are for its files, it would be able to find other dirs
where to search. The easier way is checking for the most ancient pack.
Hope you like this idea,
Javier Domingo
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Angelo Borsotti @ 2012-11-14 23:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chris Rorvick, git, Drew Northup, Michael Haggerty, Philip Oakley,
Johannes Sixt, Kacper Kornet, Jeff King, Felipe Contreras
In-Reply-To: <7vmwykay4n.fsf@alter.siamese.dyndns.org>
Hi Junio,
> That is an independent issue of deciding to accept or reject
> receiving a push from outside, no?
Yes, it is. Actually I thought some means to let the owner do decide
what to accept were already present (the pushNonFastForward config
key), and going along this avenue I thought it could be appropriate to
extent this a bit.
-Angelo
On 14 November 2012 18:32, Junio C Hamano <gitster@pobox.com> wrote:
> Angelo Borsotti <angelo.borsotti@gmail.com> writes:
>
>> actually, I proposed to add a key in config files, e.g.
>> pushTagsNoChange to be set in the remote repo do disallow changes to
>> tags, similar to pushNonFastForward that disallows non-fastforward
>> changes to branches. I still have the impression that this is simple
>> and clear, and allows the owner of the remote repository to enforce
>> the policy s/he wants on her/his repository.
>
> That is an independent issue of deciding to accept or reject
> receiving a push from outside, no? You can implement any such
> policy in the pre-receive hook on the receiving end with a simple
> and clear manner, instead of adding specific logic to enforce a
> single hardcoded policy to the code that is flipped on with a
> configuration variable.
>
> In any case, I thought this series was about users who run "push"
> voluntarily stopping themselves from pushing updates to tags that
> may happen to fast-forward, so if we were to go with the
> configuration route, the suggestion would be more like
>
> [push]
> updateNeedsForce = refs/tags/:refs/frotz/
>
> or perhaps
>
> [remote "origin"]
> updateNeedsForce = refs/tags/:refs/frotz/
>
> if we want to configure it per-remote, to specify that you would
> need to say "--force" to update the refs in the listed hierarchies.
>
> Then your patch series could become just the matter of declaring
> that the value of push.updateNeedsForce, when unspecified, defaults
> to "refs/tags/".
>
^ permalink raw reply
* Re: creation of empty branches
From: Andrew Ardill @ 2012-11-15 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Angelo Borsotti, git
In-Reply-To: <7vmwyjan96.fsf@alter.siamese.dyndns.org>
On 15 November 2012 08:27, Junio C Hamano <gitster@pobox.com> wrote:
> ... "git branch foo master" (or its
> moral equivalent "git checkout -b foo" while on master) is a wish to
> have a history that ends in 'foo' *forked* from history of 'master',
> but because you do not even have anything on 'master' yet, you
> cannot fork the history, as you explained earlier (snipped). In
> that sense, 'empty branch' is a slight misnomer---as far as "git
> branch foo master" is concerned, the 'master' branch does not yet
> exist (and that is why we often call it an "unborn branch", not
> "empty").
>
> fatal: cannot fork master's history that does not exist yet.
>
> would be more accurate description of the situation.
So in the situation where a start-point is an unborn branch (ie it is
referenced in HEAD) we should modify the error to show that the unborn
branch is in fact unborn. This is a good improvement I think, as it
catches this edge case and improves understanding of what an unborn
branch is. The term 'fork' is not used at all in branch's man page, so
perhaps a more consistent error message is something like
fatal: 'master' has no history, so we cannot create a new branch from it
Also, currently 'git checkout -b' *will* rename an unborn branch which
is different from the 'git branch' behaviour. Not sure how this
behaviour can be corrected without causing a regression or introducing
potentially confusing error messages for the git branch case.
>> So explicitly, I am proposing the following behaviour changes:
>>
>> When trying to create a new branch without specifying a start point,
>> if HEAD points to an empty branch, error with a more useful message
>> that assumes the user might want to rename the empty branch.
>
> I do not think that is the right assumption in the first place. It
> is very likely that the user does not yet know how Git works when
> she attempts to fork from a history that does not exist. It is also
> very likely that she is expecting, after "git branch foo master"
> succeeds when 'master' is yet to be born, have two branches 'foo'
> and 'master', so that "git checkout foo" and "git checkout master"
> can be done subsequently.
>
> But that expectation is wrong, and it would help the user in the
> longer run to correct that expectation. "We assume you wanted to
> rename 'master' to 'foo'" is a logical consequence that changing
> HEAD that points at an unborn 'master' to point at an unborn 'foo'
> is the best (or closest) thing the user can do, *if* the user
> understands that the current branch being unborn is a special state
> and there can only be one such unborn branch (that is, the current
> one). The user who gets this error message, however, clearly does
> not understand that, so it is not a logical consequence to her at
> all. The advice does not help her, but instead invites "No, I did
> not want to rename it, I wanted to have 'foo' without losing
> 'master'", leading to even more confusion.
I can't speak for others, but I think it is more likely that a new
user who doesn't understand git and tries to use the branch command on
a brand new repository is not trying to fork master's history, but is
rather trying to switch to a different branch. A subversion user might
want to switch from 'master' to 'trunk' as a (somewhat?) common use
case. That is the reasoning behind my recommendation to show how to
rename the branch. Furthermore, we can educate the user about unborn
branches and suggest a possible solution at the same time.
With the new error message from above, something like the following
might be nice.
fatal: 'master' has no history, so we cannot create a new branch from it
hint: A repository can only contain one unborn branch at a time.
hint: To rename a branch use 'git branch -m [<old-branch>] <new-branch>'
I'm not sure about the intended syntax of hint messages but this seems
consistent.
>
>> When trying to create a new branch whilst specifying an empty branch
>> as the start point,
>> if HEAD points to the same empty branch that is listed as the start
>> point, error with a more useful message that assumes the user might
>> want to rename the empty branch.
>> otherwise error due to invalid ref
>
> See above (for all the other cases, too).
>
You didn't address the branch rename command 'git branch -m
[<old-branch>] <new-branch>' (or you included it with the others). I
think it is a significantly different action to creating a new branch,
and should handle unborn branches in the expected way, which is to
rename them. What are your thoughts on that?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH] send-email: add proper default sender
From: Jeff King @ 2012-11-15 0:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Thomas Rast, Junio C Hamano, Jonathan Nieder
In-Reply-To: <CAMP44s3sBj0iYsCLUpiouUB8PXRwLORDEyD_+dWKrSsMP+TOaw@mail.gmail.com>
On Tue, Nov 13, 2012 at 09:35:18PM +0100, Felipe Contreras wrote:
> > Yes, dying would be a regression, in that you would have to configure
> > your name via the environment and re-run rather than type it at the
> > prompt. You raise a good point that for people who _could_ take the
> > implicit default, hitting "enter" is working fine now, and we would lose
> > that. I'd be fine with also just continuing to prompt in the implicit
> > case.
> >
> > But that is a much smaller issue to me than having send-email fail to
> > respect environment variables and silently use user.*, which is what
> > started this whole discussion. And I agree it is worth considering as a
> > regression we should avoid.
>
> It might be smaller, I don't think so. A hypothetical user that was
> relying on GIT_AUTHOR for whatever reason can switch to 'git
> send-email --from' (which is much easier) when they notice the
> failure, the same way somebody relying on fqdn would. The difference
> is that people with fqdn do exist, and they might be relying on this.
>
> Both are small issues, that I agree with.
>
> But the point is that you seem to be very adamant about _my_
> regressions, and not pay much attention about yours.
Really? I mentioned initially the possibility of dying instead of
prompting. You raised the point that it would regress a certain use
case. And then what happened? I said above "you raise a good point[...].
I'd be fine with also just continuing to prompt[...]. I agree it is
worth considering as a regression we should avoid". And then I sent out
a patch series which does not have the regression.
In other words, my suggestion was a bad one, and once it was pointed
out, I did not pursue it. If you want to call that "not paying much
attention", feel free. But I'd much rather you point out problems in my
actual patch series.
> Why do you hold on to my first patch?
Because clearly I am confused by your behavior. You continued to argue
that the initial regression was not worth worrying about. Which I
thought meant you were still interested in pursuing that patch. But if
you are not, then there is not even any point in discussing it. Which
is just fine with me, as that discussion seemed to be going nowhere.
> The second patch doesn't have this issue. It does change the behavior
> of 'git commit', yeah, but I think that's a benefit.
Changing "git commit" is even something I would entertain. It would be a
regression for some people, but at least it buys us something (increased
safety against people making bogus commits and failing to notice the
warning). I'm undecided on whether that is worth it or not.
But when you presented it, as far as I could tell the change in behavior
to "git commit" was accidental (which is why I pointed it out in
response). And as it was in the middle of a discussion about whether
regressions matter, it was not clear to me that your argument was "I
have thought this through and the inconvenience is outweighted by the
benefit" and not "I did not bother to consider the implications for
users who are currently using this feature".
If you want to seriously propose changing the behavior of "git commit",
I think the best thing would be to make a real patch, laying out the
pros and cons in the commit message, and post it. I would not be
surprised if the other list participants have stopped reading our thread
at this point, and the idea is going otherwise unnoticed.
> > So you can either:
> >
> > 1. Reimplement the environment variable lookup that ident.c does,
> > leaving implicit ident logic out completely.
> >
> > 2. Modify ident.c and "git var" to let send-email reuse the logic in
> > ident.c, but avoid dropping the prompt when an implicit ident is
> > used.
> >
> > Doing (2) sounds a lot more maintainable to me in the long run.
>
> Or:
>
> 3. Change the meaning of the STRICT flag so that the values are
> explicit, which has benefits outside 'git send-email'. Yes, this would
> change the behavior in 'git commit' and other tools, but it's worth to
> investigate these changes, and most likely they would be desirable.
Yes, I think that is fine _if_ we want to change git-commit. Which is
not clear to me. If we don't, then it is not an option.
> Or:
>
> 4. Just stop prompting
>
> I already sent a patch for 4. with all the details of why nobody (or
> very few, if any) would be affected negatively.
If doing (2) were really hard, that might be worth considering. But it's
not. I already did it. So I don't see how this is an attractive option,
unless my series is so unpalatable that we would rather accept a
regression.
> > [1/6]: ident: make user_ident_explicitly_given private
> > [2/6]: ident: keep separate "explicit" flags for author and committer
> > [3/6]: var: accept multiple variables on the command line
> > [4/6]: var: provide explicit/implicit ident information
> > [5/6]: Git.pm: teach "ident" to query explicitness
> > [6/6]: send-email: do not prompt for explicit repo ident
>
> I think this adds a lot of code that nobody would use.
A lot of code? It is mostly refactoring, which IMHO makes the resulting
code cleaner, and it increases the utility of "git var", and our test
coverage. If you have review comments, then by all means, respond to the
series.
> > I do not necessarily agree on "git commit". Moreover, I feel like it is
> > a separate issue. My series above _just_ implements the "do not prompt
> > when explicit" behavior. It does not deal with git-commit at all, nor
> > does it address the author/committer fallback questions. Those can
> > easily go on top.
>
> Yes, at the cost of adding a lot of code. If we end up agreeing that
> the changes to 'git commit' are desirable (which I hope at some point
> we will), then this code would be all for nothing.
If we are going to change "git commit" immediately, then I agree there
is not much point merging my series. But even if we do change it, will
we do so immediately? Will there be a deprecation period? If so, then my
series helps send-email in the meantime. And it's already written, so
you do not even have to do anything.
> I want clarify that this is merely a disagreement to at which level
> should we worry about regressions. On one side of the spectrum you
> have projects like GNOME, who don't have any problem breaking the
> user-experience from one release to the next, I'm not proposing
> anything like that. On the other side I think it's you, because I
> don't recall encountering anybody with such an extreme position of
> never introducing a regression ever if there's absolutely no evidence
> that anybody is using certain feature.
I don't think that's a fair characterization of my position. I am fine
with introducing a regression if there is a large benefit to it, and
especially if the regression is mutually exclusive with the benefit. For
example, look at IDENT_STRICT. We used to allow broken email addresses
in commits, and it was _me_ who pushed forward the change to disallow
it. That potentially regressed people who would rather have junk in the
commit objects than configure their identity (e.g., because they are
creating commits on the backend of some automated process). But we
discussed it, and the breakage was worth the increased safety for normal
users. We could not have it both ways, since the safety came at the
expense of switching the default.
But with this topic, we had a too-safe default (a safety prompt that was
sometimes overkill). We can have our cake and eat it, too: drop the
prompt for the overkill cases, but leave the other cases untouched. And
that is what I tried to do in my series. Note that this _still_
regresses certain use cases. What if I have configured my user.email,
but I am expecting send-email to prompt me so I can put in some other
random value. But we can't improve the prompting and leave that case
there; they are mutually exclusive. But IMHO, the benefit outweighs the
possibility of breakage.
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Junio C Hamano @ 2012-11-15 0:09 UTC (permalink / raw)
To: Angelo Borsotti
Cc: Chris Rorvick, git, Drew Northup, Michael Haggerty, Philip Oakley,
Johannes Sixt, Kacper Kornet, Jeff King, Felipe Contreras
In-Reply-To: <7vmwykay4n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Addendum.
> In any case, I thought this series was about users who run "push"
> voluntarily stopping themselves from pushing updates to tags that
> may happen to fast-forward, so if we were to go with the
> configuration route, the suggestion would be more like
>
> [push]
> updateNeedsForce = refs/tags/:refs/frotz/
>
> or perhaps
>
> [remote "origin"]
> updateNeedsForce = refs/tags/:refs/frotz/
>
> if we want to configure it per-remote, to specify that you would
> need to say "--force" to update the refs in the listed hierarchies.
>
> Then your patch series could become just the matter of declaring
> that the value of push.updateNeedsForce, when unspecified, defaults
> to "refs/tags/".
The above is not a "you should do it this way" suggestion, by the
way.
I was just explaining what I meant by "it may be a good feature, but
may not necessarily be limited to refs/tags" in my earlier message
in a different way "... and a possible design that lifts the
limitation may go like this".
I am *not* convinced that the "refs/tags/ is the only special
hierarchy whose contents should not move" is a bad limitation we
should avoid, but if it indeed is a bad limitation, the above is one
possible way to think about avoiding it.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Jeff King @ 2012-11-15 0:16 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Junio C Hamano, Mark Levedahl, git
In-Reply-To: <50A40978.2060504@web.de>
On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote:
> >>>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit
> >>>> - Update cygwin.c for new mingw-64 win32 api headers
> >>>>
> >>>> Make git work on newer cygwin.
> >>>>
> >>>> Will merge to 'next'.
I'm cc-ing Junio in case he missed the discussion; my original plan had
been to move this topic right to 'next' to get exposure from other
cygwin people. But it seems we have already got that, and it might need
re-rolling, so it probably makes sense to hold back until the discussion
reaches a conclusion.
> There are a couple of things which we may want consider:
> a) the name V15_MINGW_HEADERS:
> It indicates that this is true for Version 1.5 (of what?)
> If I assume Cygwin version 1.5 , then this name is confusing.
> Even cygwin versions like 1.7.7 use the same (or similar) include files as 1.5
> A better name could be CYGWIN_USE_MINGW_HEADERS (or the like) and to revert the logic.
Regardless of flipping the logic, I agree that having CYGWIN in the name
makes a lot of sense.
> b) Autodetection:
> (Just loud thinking), running
> $grep mingw /usr/include/w32api/winsock2.h
> * This file is part of the mingw-w64 runtime package.
> #include <_mingw_unicode.h>
>
> on cygwin 1.7.17 indicates that we can use grep in the Makefile to
> autodetect the "mingw headers"
Hmm. Can we rely on the /usr/include bit, though?
I assume a test-compile would be sufficient, but currently we do not do
anything more magic than "uname" in the Makefile itself to determine
defaults. Maybe it would be better to do the detection in the configure
script? And then eventually flip the default in the Makefile once
sufficient time has passed for most people to want the new format (which
would not be necessary for people using autoconf, but would help people
who do not).
-Peff
^ 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