Re: [PATCH (Apple Git) 01/13] .gitignore: Remove *.s as it matches *.S on case insensitive filesystem
Sent from my iPhone... > On Jan 31, 2019, at 09:57, Junio C Hamano wrote: > > Jeremy Huddleston Sequoia writes: > >>> What you probably want instead is >>> >>># Accommodate for case-insensitive filesystems where *.s would catch >>>!ppc/sha1ppc.S >>> >>> after the `*.[aos]` line. >> >> Thanks for the suggestion. I didn't know that was possible with >> .gitignore. That's a much better solution. > > I still do not see what problem you need a "solution" for in the > first place---I saw a few comments asking it in the thread, but saw > no answer. ppc/sha1ppc.S is already tracked, so any modification > you make in the working tree can be added to the index with "git > add" and "git status" would report when you have modification to > that file in the working tree, without any such extra entry in > .gitignore, no? I originally saw this because the .gitignore was present in the tarball, and we would only update to new versions by pulling in the newer tarball. This resulted in *.S not being included in our repo. When I switched to having upstream be a subtree instead of an extracted tarball, I noticed this difference when comparing the source code difference between the tarball based approach and the git subtree approach. This would have implications for anyone doing something similar or to anyone intending to add new assembly files to the tree (since they wouldn’t show up in status or get added with add -A),
Re: [PATCH (Apple Git) 12/13] Enable support for Xcode.app-bundled gitconfig
> On Jan 30, 2019, at 16:01, Jonathan Nieder wrote: > > Hi, > > Jeremy Huddleston Sequoia wrote: > >> Unfortunately, I was quick to celebrate. This picks up the bundled >> file instead of a system-wide file. I'd love it if we could still >> honor system-wide config/attributes in addition to >> RUNTIME_PREFIX-relative ones (eg: user overrides system which >> overrides distribution). I worry that as is, we'd stop referencing >> the system-wide configs which might confuse users. >> >> Is that something you'd be interested in, or should we just continue >> to maintain our separate patches? > > For the internal deployment at Google, what we've done is to put an > [include] path directive in the global gitconfig: > > [include] > path = /usr/share/git-core/config > > Users can edit the global git config in etc, but the distributed > config at /usr/share/git-core/config is read-only as part of the > distributed package. > > We considered making an upstream change to bake in the distributed > config in the git binary but decided that this way is a little > nicer since it lets people comment out the include.path setting if > they want to e.g. for experimentation. It's also more explicit > (hence easier to understand). > > Would a similar approach work for your setup? Can you say a little > more about how you'd like things to work from an end-user pov? That might work. I could put this in the Xcode.app gitconfig: [include] path = /private/etc/gitconfig Would that result in /private/etc/gitconfig's taking precedence or Xcode.app's? Is there anything analogous I could do for gitattributes?
Re: [PATCH (Apple Git) 12/13] Enable support for Xcode.app-bundled gitconfig
> On Jan 30, 2019, at 13:09, Jeremy Huddleston Sequoia
> wrote:
>
>
>
>> On Jan 30, 2019, at 11:32, Johannes Schindelin
>> wrote:
>>
>> Hi Jeremy,
>>
>> On Tue, 29 Jan 2019, Jeremy Huddleston Sequoia wrote:
>>
>>>> On Jan 29, 2019, at 3:10 PM, Junio C Hamano wrote:
>>>>
>>>> Jeremy Huddleston Sequoia writes:
>>>>
>>>>> Useful for setting up osxkeychain in Xcode.app's gitconfig
>>>>>
>>>>> Signed-off-by: Jeremy Huddleston Sequoia
>>>>> ---
>>>>
>>>> A concern shared with 13/13 is this.
>>>>
>>>> While it may not hurt too much to look at one extra location even on
>>>> non-Apple platform, it probably is a mistake to have this xcode
>>>> specific change in generic part of the system like config.c or
>>>> attr.c. For that matter, would it make sense to force Apple uses to
>>>> look at one extra location in the first place? In other words, we
>>>> already have "system wide" location (i.e. system_path(ETC_GITCONFIG))
>>>> defined so system owners can give reasonable default to its users.
>>>> The value of not using that facility and instead adding yet another
>>>> place is dubious.
>>>
>>> This allows for per-distribution configuration and could be useful for
>>> other applications as well that want customizations specific to their
>>> install of git. For our specific use case, we do not want to munge the
>>> system policy when installing Xcode. Prior to doing things this way, we
>>> were just changing the default in our distributed git binary, but this
>>> seems a bit more flexible.
>>
>> I think you misunderstood Junio, thinking that he referred to
>> /etc/gitconfig. He did not. system_path(ETC_GITCONFIG) refers to
>> /etc/gitconfig, where is that runtime prefix when
>> compiled with RUNTIME_PREFIX.
>
> Oh! Awesome. I didn't even notice this was a thing. That would exactly
> solve our use case. I'll give that a whirl. That likely allows us to
> eliminate these two patches completely!
Unfortunately, I was quick to celebrate. This picks up the bundled file
instead of a system-wide file. I'd love it if we could still honor system-wide
config/attributes in addition to RUNTIME_PREFIX-relative ones (eg: user
overrides system which overrides distribution). I worry that as is, we'd stop
referencing the system-wide configs which might confuse users.
Is that something you'd be interested in, or should we just continue to
maintain our separate patches?
>
>> So you can definitely have your own per-distribution configuration: it
>> lives in that very /etc/gitconfig where the portable Git is
>> installed.
>>
>> And since we have that nice facility, I agree with Junio that we probably
>> do not even need an extra config, certainly not one just introduced for
>> XCode.
>>
>> Ciao,
>> Johannes
>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> config.c | 13 +
>>>>> config.h | 2 ++
>>>>> 2 files changed, 15 insertions(+)
>>>>>
>>>>> diff --git a/config.c b/config.c
>>>>> index ff521eb27a..656bfef8ab 100644
>>>>> --- a/config.c
>>>>> +++ b/config.c
>>>>> @@ -1631,6 +1631,14 @@ const char *git_etc_gitconfig(void)
>>>>> return system_wide;
>>>>> }
>>>>>
>>>>> +const char *git_xcode_gitconfig(void)
>>>>> +{
>>>>> + static const char *xcode_config;
>>>>> + if (!xcode_config)
>>>>> + xcode_config = system_path("share/git-core/gitconfig");
>>>>> + return xcode_config;
>>>>> +}
>>>>> +
>>>>> /*
>>>>> * Parse environment variable 'k' as a boolean (in various
>>>>> * possible spellings); if missing, use the default value 'def'.
>>>>> @@ -1673,6 +1681,11 @@ static int do_git_config_sequence(const struct
>>>>> config_options *opts,
>>>>> else
>>>>> repo_config = NULL;
>>>>>
>>>>> + current_parsing_scope = CONFIG_SCOPE_XCODE;
>>>>> + if (git_config_system() && git_xcode_gitconfig() &&
>>>>> !access_or_die(git_xcode_g
Re: [PATCH (Apple Git) 12/13] Enable support for Xcode.app-bundled gitconfig
> On Jan 30, 2019, at 11:32, Johannes Schindelin
> wrote:
>
> Hi Jeremy,
>
> On Tue, 29 Jan 2019, Jeremy Huddleston Sequoia wrote:
>
>>> On Jan 29, 2019, at 3:10 PM, Junio C Hamano wrote:
>>>
>>> Jeremy Huddleston Sequoia writes:
>>>
>>>> Useful for setting up osxkeychain in Xcode.app's gitconfig
>>>>
>>>> Signed-off-by: Jeremy Huddleston Sequoia
>>>> ---
>>>
>>> A concern shared with 13/13 is this.
>>>
>>> While it may not hurt too much to look at one extra location even on
>>> non-Apple platform, it probably is a mistake to have this xcode
>>> specific change in generic part of the system like config.c or
>>> attr.c. For that matter, would it make sense to force Apple uses to
>>> look at one extra location in the first place? In other words, we
>>> already have "system wide" location (i.e. system_path(ETC_GITCONFIG))
>>> defined so system owners can give reasonable default to its users.
>>> The value of not using that facility and instead adding yet another
>>> place is dubious.
>>
>> This allows for per-distribution configuration and could be useful for
>> other applications as well that want customizations specific to their
>> install of git. For our specific use case, we do not want to munge the
>> system policy when installing Xcode. Prior to doing things this way, we
>> were just changing the default in our distributed git binary, but this
>> seems a bit more flexible.
>
> I think you misunderstood Junio, thinking that he referred to
> /etc/gitconfig. He did not. system_path(ETC_GITCONFIG) refers to
> /etc/gitconfig, where is that runtime prefix when
> compiled with RUNTIME_PREFIX.
Oh! Awesome. I didn't even notice this was a thing. That would exactly solve
our use case. I'll give that a whirl. That likely allows us to eliminate
these two patches completely!
> So you can definitely have your own per-distribution configuration: it
> lives in that very /etc/gitconfig where the portable Git is
> installed.
>
> And since we have that nice facility, I agree with Junio that we probably
> do not even need an extra config, certainly not one just introduced for
> XCode.
>
> Ciao,
> Johannes
>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> config.c | 13 +
>>>> config.h | 2 ++
>>>> 2 files changed, 15 insertions(+)
>>>>
>>>> diff --git a/config.c b/config.c
>>>> index ff521eb27a..656bfef8ab 100644
>>>> --- a/config.c
>>>> +++ b/config.c
>>>> @@ -1631,6 +1631,14 @@ const char *git_etc_gitconfig(void)
>>>>return system_wide;
>>>> }
>>>>
>>>> +const char *git_xcode_gitconfig(void)
>>>> +{
>>>> + static const char *xcode_config;
>>>> + if (!xcode_config)
>>>> + xcode_config = system_path("share/git-core/gitconfig");
>>>> + return xcode_config;
>>>> +}
>>>> +
>>>> /*
>>>> * Parse environment variable 'k' as a boolean (in various
>>>> * possible spellings); if missing, use the default value 'def'.
>>>> @@ -1673,6 +1681,11 @@ static int do_git_config_sequence(const struct
>>>> config_options *opts,
>>>>else
>>>>repo_config = NULL;
>>>>
>>>> + current_parsing_scope = CONFIG_SCOPE_XCODE;
>>>> + if (git_config_system() && git_xcode_gitconfig() &&
>>>> !access_or_die(git_xcode_gitconfig(), R_OK, 0))
>>>> + ret += git_config_from_file(fn, git_xcode_gitconfig(),
>>>> + data);
>>>> +
>>>>current_parsing_scope = CONFIG_SCOPE_SYSTEM;
>>>>if (git_config_system() && !access_or_die(git_etc_gitconfig(), R_OK, 0))
>>>>ret += git_config_from_file(fn, git_etc_gitconfig(),
>>>> diff --git a/config.h b/config.h
>>>> index ee5d3fa7b4..f848423d28 100644
>>>> --- a/config.h
>>>> +++ b/config.h
>>>> @@ -115,6 +115,7 @@ extern int git_config_rename_section_in_file(const
>>>> char *, const char *, const c
>>>> extern int git_config_copy_section(const char *, const char *);
>>>> extern int git_config_copy_section_in_file(const char *, const char *,
>>>> const char *);
>>>> extern const char *git_etc_gitconfig(void);
>>>> +extern const char *git_xcode_gitconfig(void);
>>>> extern int git_env_bool(const char *, int);
>>>> extern unsigned long git_env_ulong(const char *, unsigned long);
>>>> extern int git_config_system(void);
>>>> @@ -131,6 +132,7 @@ enum config_scope {
>>>>CONFIG_SCOPE_GLOBAL,
>>>>CONFIG_SCOPE_REPO,
>>>>CONFIG_SCOPE_CMDLINE,
>>>> + CONFIG_SCOPE_XCODE,
>>>> };
>>>>
>>>> extern enum config_scope current_config_scope(void);
>>
>>
Re: [PATCH (Apple Git) 10/13] Support for Xcode.app co-exestince and relocation
> On Jan 30, 2019, at 11:26, Johannes Schindelin
> wrote:
>
> Hi Jeremy,
>
> On Tue, 29 Jan 2019, Jeremy Huddleston Sequoia wrote:
>
>> This patch has been trimmed down significantly from its original version
>> when rebasing on top of git 2.18 because git 2.18 included support for
>> runtime prefix support for darwin, making this patch mostly duplicative.
>>
>> The remaining changes are needed to ensure that git-perl can find the
>> subversion perl module (which relocates with it) and handle relocation
>> of python scripts.
>>
>> Signed-off-by: Jeremy Huddleston Sequoia
>
> I am really curious about this kind of problem now. Is it that you want to
> bundle a Perl inside a portable Git, and that Perl is not at all
> relocatable and so you force Git to pretend that it is?
Not exactly, although that's an interesting problem as well.
In our specific case, Xcode.app is a relocatable bundle that contains the Xcode
application, SDKs, toolchains, useful command line tools including git and svn,
and more. perl is distributed with the system in /usr/bin/perl and not with
Xcode.
git-svn uses requires the perl modules that ship with subversion. Since
subversion ships with Xcode, those perl modules are packaged inside of Xcode,
and the system perl has no logic to locate modules in various apps on the
system as that would be an abstraction violation, IMO.
This patch changes the perl template to allow git-svn (or any other perl based
tool installed by git) to locate these subversion perl modules within
Xcode.app. It requires the perl script itself to have been executed from
within Xcode.app, which is why this complicates testing out of the build
directory as discussed in patch 2 in the series.
The /usr/local/versioner/perl/versions logic there is specific to our build
infrastructure, but if you're interested in taking something like this, I could
come up with a better way to generalize it.
The issues for python are similar to for perl, but I forget the specifics
around what exactly was failing in the python case.
> Ciao,
> Johannes
>
>> ---
>> Makefile | 3 +++
>> .../runtime_prefix.template.pl| 25 +++
>> 2 files changed, 28 insertions(+)
>>
>> diff --git a/Makefile b/Makefile
>> index 60711d6abe..97f46444f5 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -2171,6 +2171,7 @@ GIT-PERL-HEADER: $(PERL_HEADER_TEMPLATE)
>> GIT-PERL-DEFINES Makefile
>> sed -e 's=@@PATHSEP@@=$(pathsep)=g' \
>> -e "s=@@INSTLIBDIR@@=$$INSTLIBDIR=g" \
>> -e 's=@@PERLLIBDIR_REL@@=$(perllibdir_relative_SQ)=g' \
>> +-e 's=@@PERLVERSION@@=$(shell grep DEFAULT
>> /usr/local/versioner/perl/versions | sed 's:^.*= *\([^ ]*\)$$:\1:')=g' \
>> -e 's=@@GITEXECDIR_REL@@=$(gitexecdir_relative_SQ)=g' \
>> -e 's=@@LOCALEDIR_REL@@=$(localedir_relative_SQ)=g' \
>> $< >$@+ && \
>> @@ -2206,6 +2207,8 @@ $(SCRIPT_PYTHON_GEN): GIT-CFLAGS GIT-PREFIX
>> GIT-PYTHON-VARS
>> $(SCRIPT_PYTHON_GEN): % : %.py
>> $(QUIET_GEN)$(RM) $@ $@+ && \
>> sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
>> +-e 's|\(os\.getenv("GITPYTHONLIB"\)[^)]*)|\1,"@@INSTLIBDIR@@")|' \
>> +-e
>> 's|"@@INSTLIBDIR@@"|os.path.realpath(os.path.dirname(sys.argv[0])) +
>> "/../../share/git-core/python"|g' \
>> $< >$@+ && \
>> chmod +x $@+ && \
>> mv $@+ $@
>> diff --git a/perl/header_templates/runtime_prefix.template.pl
>> b/perl/header_templates/runtime_prefix.template.pl
>> index 9d28b3d863..b0b6b0bef1 100644
>> --- a/perl/header_templates/runtime_prefix.template.pl
>> +++ b/perl/header_templates/runtime_prefix.template.pl
>> @@ -1,3 +1,28 @@
>> +# BEGIN XCODE RUNTIME_PREFIX generated code
>> +BEGIN {
>> +use File::Spec;
>> +my $PERLVERSION = "@@PERLVERSION@@";
>> +if ($^V =~ m/v([0-9]+).([0-9]+)/) {
>> +$PERLVERSION = $1.".".$2;
>> +}
>> +my $__prefix = File::Spec->rel2abs( __FILE__ );
>> +
>> +if ($__prefix =~ m/\/libexec\/git-core\// ) {
>> +$__prefix =~ s/\/libexec\/git-core\/.*//;
>> +unshift @INC, $__prefix . "/share/git-core/perl";
>> +unshift @INC, $__prefix .
>> "/../Library/Perl/".$PERLVERSION."/darwin-thread-multi-2level";
>> +} elsif ($__prefix =~ m/\/bin\// ) {
>> +$
Re: [PATCH (Apple Git) 09/13] Use symbolic links rather than hard links for files in libexec
> On Jan 30, 2019, at 11:15, Johannes Schindelin > wrote: > > Hi Jeremy, > > On Wed, 30 Jan 2019, Jeremy Huddleston Sequoia wrote: > >>> On Jan 30, 2019, at 01:50, brian m. carlson >>> wrote: >>> >>> On Tue, Jan 29, 2019 at 11:38:15AM -0800, Jeremy Huddleston Sequoia wrote: >>>> See >>> >>> It's my understanding that Radars aren't public. Could you summarize the >>> reasons behind this change in the commit message for those of us who >>> don't have access to view this issue? >> >> There was a bug in some tool in our packaging pipeline that resulted in >> hardlinks not being preserved. That was fixed, but I decided to leave >> these as symlinks anyways in case users did a file operation on >> Xcode.app that didn't preserve hard links. >> >> The point here is that it would probably be nice to have hard vs soft be >> a configuration option. > > Your patch does not make it a configuration option. (Or a build option, > which would probably be the more appropriate thing to do here.) > > You need not spend the time on this, though, as Ævar already did, in > ad874608d8c9 (Makefile: optionally symlink libexec/git-core binaries to > bin/git, 2018-03-13), which made it in v2.18.0 already. All you need to do > is to define INSTALL_SYMLINKS. Oh great, thanks! I missed that when doing the last rebase.
Re: [PATCH (Apple Git) 06/13] Set Apple Git version during build
> On Jan 30, 2019, at 05:43, Johannes Schindelin > wrote: > > Hi Jeremy, > > On Tue, 29 Jan 2019, Jeremy Huddleston Sequoia wrote: > >> Signed-off-by: Jeremy Huddleston Sequoia >> --- >> GIT-VERSION-GEN | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN >> index d1a2814ec7..6fb90854b9 100755 >> --- a/GIT-VERSION-GEN >> +++ b/GIT-VERSION-GEN >> @@ -3,6 +3,10 @@ >> GVF=GIT-VERSION-FILE >> DEF_VER=v2.20.1 >> >> +if [ -n "$RC_ProjectSourceVersion" ] ; then >> +DEF_VER="$DEF_VER (Apple Git-$RC_ProjectSourceVersion)" >> +fi > > This seems awfully specific to a very specific setup. It won't work when > building from a Git checkout, either, as `DEF_VER` is not even used then. Yes. This one was one of the ones I thought obviously fell into the "this is certainly not upstreamable, but let's discuss a general solution to this problem" category. Sorry if that wasn't clear. > And the existing facility is the `version` file. Since you want to build > this in some sort of automated fashion anyway, you should probably execute > > sed -n "s/^DEF_VER=\\(.*\\)/\\1 (Apple Git-$RC_ProjectSourceVersion)/p" > \ > version > > in your automation script. As a bonus, this will work with any unpatched > Git source code, too! Oh nice! Thanks for getting rid of one of our patches. > > Ciao, > Johannes > >> + >> LF=' >> ' >> >> -- >> 2.20.0 (Apple Git-115) >> >>
Re: [PATCH (Apple Git) 05/13] t5701: git --version can have SP in it
> On Jan 30, 2019, at 05:36, Johannes Schindelin > wrote: > > Hi Jeremy, > > On Tue, 29 Jan 2019, Jeremy Huddleston Sequoia wrote: > >> Signed-off-by: Jeremy Huddleston Sequoia > > > That commit message is again very short. Only because I remember the > previous patch's commit message do I have a clue what this is about. Yeah, I became lax with commit messages when I was under the impression that the git community was not interested engaging with Apple. I should have taken a pass through these commits before sending, but I half expected these patches to be ignored. I am delighted to see that I was wrong and will go back and provide more details in the ones that I feel are upstreamable like this one. > You definitely need to write something here about customized forks of Git > adding suffixes including spaces to the Git version. > > And you will need to state where those spaces are converted to dots in > Git's capability advertisement. The reason for this requirement: should > that logic change at any stage in the future, your patch will fail, > somebody will investigate and find this commit and *needs* a helpful > commit message. Thanks, I'll add you to the CC of this patch, so you can critique my wording in the updated message. > >> --- >> t/t5701-git-serve.sh | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/t/t5701-git-serve.sh b/t/t5701-git-serve.sh >> index ae79c6bbc0..7bc25700fa 100755 >> --- a/t/t5701-git-serve.sh >> +++ b/t/t5701-git-serve.sh >> @@ -7,7 +7,7 @@ test_description='test git-serve and server commands' >> test_expect_success 'test capability advertisement' ' >> cat >expect <<-EOF && >> version 2 >> -agent=git/$(git version | cut -d" " -f3) >> +agent=git/$(git --version | sed -e "s/git version //" -e "s/ /\./g") > > This `git version` needs to be anchored, Good catch, thanks. > and it would be much conciser to > use `-e "y/ /./"`, which even BSD sed understands according to > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html Also done, thanks. > > Ciao, > Johannes > >> ls-refs >> fetch=shallow >> server-option >> -- >> 2.20.0 (Apple Git-115) >> >>
Re: [PATCH (Apple Git) 01/13] .gitignore: Remove *.s as it matches *.S on case insensitive filesystem
> On Jan 30, 2019, at 04:42, Johannes Schindelin > wrote: > > Hi Jeremy, > > On Wed, 30 Jan 2019, Jeremy Huddleston Sequoia wrote: > >>> On Jan 30, 2019, at 03:33, Eric Sunshine wrote: >>> >>> On Tue, Jan 29, 2019 at 3:11 PM Jeremy Huddleston Sequoia >>> wrote: >>>> This was causing problems with ppc/sha1ppc.S >>> >>> What problems, exactly? >> >> The file is ignored, but it shouldn't be. > > As somebody who sometimes (pretty rarely, but definitely more than once a > year) generates the assembler files to have a deeper look, I really > understand why *.s is ignored, and I think it should stay ignored. > > What you probably want instead is > > # Accommodate for case-insensitive filesystems where *.s would catch > !ppc/sha1ppc.S > > after the `*.[aos]` line. Thanks for the suggestion. I didn't know that was possible with .gitignore. That's a much better solution. I was expecting this to just stay in our series as upstreamable, but I'm glad you pointed this out. I got to learn something new and offload a patch. Thanks! I'll now be able include this in my followup series of patches that I think can be upstreamed! =) > Ciao, > Johannes > >> >>> >>>> Signed-off-by: Jeremy Huddleston Sequoia >>>> --- >>>> diff --git a/.gitignore b/.gitignore >>>> @@ -195,7 +195,7 @@ >>>> -*.[aos] >>>> +*.[ao] >> >>
Re: [PATCH (Apple Git) 03/13] t0500: New regression test for git add of a path that contains a .git directory
> On Jan 30, 2019, at 05:12, Johannes Schindelin > wrote: > > Hi Jeremy, > > On Tue, 29 Jan 2019, Jeremy Huddleston Sequoia wrote: > >> Signed-off-by: Jeremy Huddleston Sequoia > > As Eric pointed out, commits with such a vanishing commit message are > very, very sad commits. And somewhere, a kitten dies every time you submit > such a commit. Yes. I removed the commit message once upstream git finally fixed the issue and the commit message no longer applied. I didn't add a new verbose message because I was under the impression the git community did not want to receive any contribuitions (bug reports, feedback, upstreamed patches) from Apple, and the radar provided all the reference I needed. If that situation is changing (as it seems to possibly be), I'm happy to update this with details about the issue. Here's the thread from 2011-2014 about the issue. --- Begin Message --- FWIW, it seems that this bug was addressed by ddc2a6281595fd24ea01497c496f88c40a59562f Thanks Martin, now we're no longer carrying around an extra patch for our build of git ;) --Jeremy > On Oct 17, 2011, at 14:55, Jeremy Huddleston wrote: > > ping. Did you get my response below with extra details? I just got a > duplicate bug report, so it apparently effects people... > > Please let me know if I can be of further assistance. > > On Oct 11, 2011, at 2:17 PM, Jeremy Huddleston wrote: > >> Thanks for your response Junio. The text of the original bug report is >> below. >> >> I created a git bisect test script which bisected the problem and found out >> that the difference was that the trailing / was removed by your code change. >> git treats paths with a trailing / differently. I don't know *why* it >> treats them differently, but it does. >> >> There's nothing "special" about JustDoItGit.tar.bz2 except that it contains >> a .git dir and has a file layout that works with the bisect script I wrote. >> You can test this yourself by: >> >> mkdir -p ~/tmp/PR-10238070 >> cd ~/tmp/PR-10238070 >> tar xjf JustDoItGit.tar.bz2 >> cd ~/git-checkout >> /path/to/test_10238070.sh >> >> Here's the original report: >> >> I've tracked the cause of ' ##snipped title##' down >> to a regression in git. >> >> Unzip the attached JustDoItGit.zip project and replace the path in the >> following commands to the unzipped location on your system: >> >> #delete git in /usr/bin/git >> sudo rm -r /usr/bin/git >> #link it to /usr/local/bin/git since that's where ditto will place the new >> bits >> sudo ln -s /usr/local/bin/git /usr/bin/git >> >> # first, install git 1.7.3.2 to verify that the bug does not reproduce >> sudo ditto ~rc/Software/Slate/Roots/Git/Git-14~19.root/ / >> sudo rm -r /Users//MyGitRepo.gitdir >> git --git-dir=/Users//MyGitRepo.gitdir init --bare --quiet >> git --git-dir=/Users//MyGitRepo.gitdir --work-tree=/ add -- >> /Users//Desktop/JustDoItGit/ >> /Users//Desktop/JustDoItGit/JustDoItGit/JustDoItGitAppDelegate.h >> /Users//Desktop/JustDoItGit/JustDoItGitTests >> git --git-dir=/Users//MyGitRepo.gitdir --work-tree=/ commit -m "Hello." >> >> The expected result of the commit is something like "18 files changed, 7364 >> insertions". If that's what you get, great, now keep going. >> >> sudo rm -r /Users//MyGitRepo.gitdir >> # install the slate version of git, 1.7.5.4 >> sudo ditto ~rc/Software/Slate/Roots/Git/Git-19.root~2/ / >> sudo rm -r /Users//MyGitRepo.gitdir >> git --git-dir=/Users//MyGitRepo.gitdir init --bare --quiet >> git --git-dir=/Users//MyGitRepo.gitdir --work-tree=/ add -- >> /Users//Desktop/JustDoItGit/ >> /Users//Desktop/JustDoItGit/JustDoItGit/JustDoItGitAppDelegate.h >> /Users//Desktop/JustDoItGit/JustDoItGitTests >> git --git-dir=/Users//MyGitRepo.gitdir --work-tree=/ commit -m "Hello." >> >> The expected result is what's above, something like "18 files changed, 7364 >> insertions". But the actual result is that only the root folder >> "/Users//Desktop/JustDoItGit is added >> >> This is a problem because it subsequently causes >> ##snipped title## >> >> … and therefore breaks Xcode's snapshots feature. >> >> >> >> On Oct 11, 2011, at 10:45, Junio C Hamano wrote: >> >>> Jeremy Huddleston writes: >>> >>>> real_path will strip the trailing / from provided paths. This fixes >>>> a regression introduced in 18e051a3981f38db085
Re: [PATCH (Apple Git) 02/13] test-lib: Export PERL5LIB for testing git-svn
Sent from my iPhone...
> On Jan 30, 2019, at 04:51, Johannes Schindelin
> wrote:
>
> Hi Jeremy,
>
> On Tue, 29 Jan 2019, Jeremy Huddleston Sequoia wrote:
>
>>> On Jan 29, 2019, at 2:47 PM, Junio C Hamano wrote:
>>>
>>> Jeremy Huddleston Sequoia writes:
>>>
>>>> Signed-off-by: Jeremy Huddleston Sequoia
>>>> ---
>>>> t/test-lib.sh | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>
>>> This obviously won't be acceptable as-is to my tree. Shouldn't this
>>> be something to be dealt with in config.mak.uname or something that
>>> is meant to define platform-specific customization?
>>
>> The issue here is that we're not locating relocatable perl modules
>> during testing. This is a general problem with testing RUNTIME_PREFIX
>> configurations, and a more general solution to this sledgehammer would
>> be appropriate. I don't think config.mak.uname really makes sense since
>> it's a general RUNTIME_PREFIX issue and not specifically a darwin issue.
>
> First of all, as others have pointed out, this code is very, very specific
> to Darwin (not only xcode-select but also Library/Perl/ are very, very
> specific to that platform, I would even argue it is not even
> Darwin-specific but instead macOS specific because bare-bones Darwin does
> not have Library/Perl/, does it?).
Yes. I first pointed that out in my emails to Peff and in my 00 email ;).
Peff requested that I send all of our changes (even ones I considered not
upstreamable) in order to discuss possible generalized solutions that could
apply to others as well.
> So you *definitely* want to put that code into guards testing for that
> platform (I do not think config.mak.uname is the correct place, though, as
> it should be accessible to test scripts when run directly, i.e. not
> through `make`).
It isn’t applicable to anyone outside of Apple internal build engineers (or
maybe folks like OpenDarwin building from our OSS perl and python drops too) as
it is specific to Apple’s build systems.
However a generalized solution would be useful to others.
> But let's take a huge step back first: why? What is the exact problem this
> commit tries to solve? The commit message unfortunately does not really
> leave me any wiser.
>
> So I am left with the unfortunate position of having to guess, which is
> not really a good use of both of our time. If I allow myself to indulge in
> the guessing game, I would guess that whatever `perl` executable is used
> in your scenario picks up some unfortunate environment variable that
> overrides its internal defaults where to look for Perl modules.
The issue is with RUNTIME_PREFIX. git’s RUNTINE_PREFIX support assumes that it
is the only thing being relocated. However, with Xcode, svn and its perl
modules are relocated as well. In order to test git-svn, we need to locate
those perl modules. Patch 10 takes care of this when running from the
installed location, but we have no svn in the appropriate relative location
from the build directory, so we add the explicit path here.
> And that simply should not be the case. We are very careful to set
> GITPERLLIB in bin-wrappers/, *not* PERL5LIB.
>
> And when we build Git on macOS agents in Travis or Azure Pipelines and
> then run the test suite, I fail to see any Perl-related error that looks
> like it could be solved by this here patch.
>
> In short: this commit is in dear want of a more substantive commit
> message, and most likely in search for a different solution.
Yes, a number of these patches (like this one) were requested to be sent to the
list in order to spark a discussion for another generalized solution and not to
be merged into mainline.
Is there a notation that would help to call that out on the commit? I figured
it was pretty obvious that this was one of those.
>
> Ciao,
> Johannes
>
>>
>>>
>>>>
>>>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>>>> index 0f1faa24b2..4060a53f56 100644
>>>> --- a/t/test-lib.sh
>>>> +++ b/t/test-lib.sh
>>>> @@ -1017,6 +1017,9 @@ fi
>>>>
>>>> GITPERLLIB="$GIT_BUILD_DIR"/perl/build/lib
>>>> export GITPERLLIB
>>>> +PERL_VERSION=$(grep DEFAULT /usr/local/versioner/perl/versions | sed
>>>> 's:^.*= *\([^ ]*\)$:\1:')
>>>> +PERL5LIB="$GIT_BUILD_DIR"/perl:"$(xcode-select
>>>> -p)"/Library/Perl/$PERL_VERSION
>>>> +export PERL5LIB
>>>> test -d "$GIT_BUILD_DIR"/templates/blt || {
>>>>error "You haven't built things yet, have you?"
>>>> }
>>
>>
Re: [PATCH (Apple Git) 09/13] Use symbolic links rather than hard links for files in libexec
> On Jan 30, 2019, at 01:50, brian m. carlson > wrote: > > On Tue, Jan 29, 2019 at 11:38:15AM -0800, Jeremy Huddleston Sequoia wrote: >> See > > It's my understanding that Radars aren't public. Could you summarize the > reasons behind this change in the commit message for those of us who > don't have access to view this issue? There was a bug in some tool in our packaging pipeline that resulted in hardlinks not being preserved. That was fixed, but I decided to leave these as symlinks anyways in case users did a file operation on Xcode.app that didn't preserve hard links. The point here is that it would probably be nice to have hard vs soft be a configuration option.
Re: [PATCH (Apple Git) 01/13] .gitignore: Remove *.s as it matches *.S on case insensitive filesystem
> On Jan 30, 2019, at 03:33, Eric Sunshine wrote: > > On Tue, Jan 29, 2019 at 3:11 PM Jeremy Huddleston Sequoia > wrote: >> This was causing problems with ppc/sha1ppc.S > > What problems, exactly? The file is ignored, but it shouldn't be. > >> Signed-off-by: Jeremy Huddleston Sequoia >> --- >> diff --git a/.gitignore b/.gitignore >> @@ -195,7 +195,7 @@ >> -*.[aos] >> +*.[ao]
Re: [PATCH (Apple Git) 02/13] test-lib: Export PERL5LIB for testing git-svn
Sent from my iPhone...
> On Jan 29, 2019, at 15:59, SZEDER Gábor wrote:
>
>> On Tue, Jan 29, 2019 at 03:46:07PM -0800, Jeremy Huddleston Sequoia wrote:
>>
>>
>>> On Jan 29, 2019, at 2:47 PM, Junio C Hamano wrote:
>>>
>>> Jeremy Huddleston Sequoia writes:
>>>
>>>> Signed-off-by: Jeremy Huddleston Sequoia
>>>> ---
>>>> t/test-lib.sh | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>
>>> This obviously won't be acceptable as-is to my tree. Shouldn't this
>>> be something to be dealt with in config.mak.uname or something that
>>> is meant to define platform-specific customization?
>>
>> The issue here is that we're not locating relocatable perl modules
>> during testing. This is a general problem with testing
>> RUNTIME_PREFIX configurations, and a more general solution to this
>> sledgehammer would be appropriate. I don't think config.mak.uname
>> really makes sense since it's a general RUNTIME_PREFIX issue and not
>> specifically a darwin issue.
>
> But this patch is very darwin-specific ...
>
>>>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>>>> index 0f1faa24b2..4060a53f56 100644
>>>> --- a/t/test-lib.sh
>>>> +++ b/t/test-lib.sh
>>>> @@ -1017,6 +1017,9 @@ fi
>>>>
>>>> GITPERLLIB="$GIT_BUILD_DIR"/perl/build/lib
>>>> export GITPERLLIB
>>>> +PERL_VERSION=$(grep DEFAULT /usr/local/versioner/perl/versions | sed
>>>> 's:^.*= *\([^ ]*\)$:\1:')
>>>> +PERL5LIB="$GIT_BUILD_DIR"/perl:"$(xcode-select
>>>> -p)"/Library/Perl/$PERL_VERSION
>
> ... because what other platforms could possibly have 'xcode-select'
> installed!? Consequently:
>
> $ ./t-basic.sh
> grep: /usr/local/versioner/perl/versions: No such file or directory
> ./t-basic.sh: 1154: ./test-lib.sh: xcode-select: not found
> ok 1 - verify that the running shell supports "local"
> ok 2 - .git/objects should be empty after git init in an empty repo
> ok 3 - .git/objects should have 3 subdirectories
> ok 4 - success is reported like this
> not ok 5 - pretend we have a fully passing test suite
> <...>
> # failed 29 among 82 test(s)
Yes. This is one of the patches that I said in the 00 message would certainly
not be upstreamable but for which we should find a general solution to the
problem if one is available.
>
>
>
>>>> +export PERL5LIB
>>>> test -d "$GIT_BUILD_DIR"/templates/blt || {
>>>>error "You haven't built things yet, have you?"
>>>> }
>>
Re: [PATCH (Apple Git) 12/13] Enable support for Xcode.app-bundled gitconfig
> On Jan 29, 2019, at 3:10 PM, Junio C Hamano wrote:
>
> Jeremy Huddleston Sequoia writes:
>
>> Useful for setting up osxkeychain in Xcode.app's gitconfig
>>
>> Signed-off-by: Jeremy Huddleston Sequoia
>> ---
>
> A concern shared with 13/13 is this.
>
> While it may not hurt too much to look at one extra location even on
> non-Apple platform, it probably is a mistake to have this xcode
> specific change in generic part of the system like config.c or
> attr.c. For that matter, would it make sense to force Apple uses to
> look at one extra location in the first place? In other words, we
> already have "system wide" location (i.e. system_path(ETC_GITCONFIG))
> defined so system owners can give reasonable default to its users.
> The value of not using that facility and instead adding yet another
> place is dubious.
This allows for per-distribution configuration and could be useful for other
applications as well that want customizations specific to their install of git.
For our specific use case, we do not want to munge the system policy when
installing Xcode. Prior to doing things this way, we were just changing the
default in our distributed git binary, but this seems a bit more flexible.
>
>
>
>
>
>
>
>> config.c | 13 +
>> config.h | 2 ++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/config.c b/config.c
>> index ff521eb27a..656bfef8ab 100644
>> --- a/config.c
>> +++ b/config.c
>> @@ -1631,6 +1631,14 @@ const char *git_etc_gitconfig(void)
>> return system_wide;
>> }
>>
>> +const char *git_xcode_gitconfig(void)
>> +{
>> +static const char *xcode_config;
>> +if (!xcode_config)
>> +xcode_config = system_path("share/git-core/gitconfig");
>> +return xcode_config;
>> +}
>> +
>> /*
>> * Parse environment variable 'k' as a boolean (in various
>> * possible spellings); if missing, use the default value 'def'.
>> @@ -1673,6 +1681,11 @@ static int do_git_config_sequence(const struct
>> config_options *opts,
>> else
>> repo_config = NULL;
>>
>> +current_parsing_scope = CONFIG_SCOPE_XCODE;
>> +if (git_config_system() && git_xcode_gitconfig() &&
>> !access_or_die(git_xcode_gitconfig(), R_OK, 0))
>> +ret += git_config_from_file(fn, git_xcode_gitconfig(),
>> +data);
>> +
>> current_parsing_scope = CONFIG_SCOPE_SYSTEM;
>> if (git_config_system() && !access_or_die(git_etc_gitconfig(), R_OK, 0))
>> ret += git_config_from_file(fn, git_etc_gitconfig(),
>> diff --git a/config.h b/config.h
>> index ee5d3fa7b4..f848423d28 100644
>> --- a/config.h
>> +++ b/config.h
>> @@ -115,6 +115,7 @@ extern int git_config_rename_section_in_file(const char
>> *, const char *, const c
>> extern int git_config_copy_section(const char *, const char *);
>> extern int git_config_copy_section_in_file(const char *, const char *, const
>> char *);
>> extern const char *git_etc_gitconfig(void);
>> +extern const char *git_xcode_gitconfig(void);
>> extern int git_env_bool(const char *, int);
>> extern unsigned long git_env_ulong(const char *, unsigned long);
>> extern int git_config_system(void);
>> @@ -131,6 +132,7 @@ enum config_scope {
>> CONFIG_SCOPE_GLOBAL,
>> CONFIG_SCOPE_REPO,
>> CONFIG_SCOPE_CMDLINE,
>> +CONFIG_SCOPE_XCODE,
>> };
>>
>> extern enum config_scope current_config_scope(void);
Re: [PATCH (Apple Git) 02/13] test-lib: Export PERL5LIB for testing git-svn
> On Jan 29, 2019, at 2:47 PM, Junio C Hamano wrote:
>
> Jeremy Huddleston Sequoia writes:
>
>> Signed-off-by: Jeremy Huddleston Sequoia
>> ---
>> t/test-lib.sh | 3 +++
>> 1 file changed, 3 insertions(+)
>
> This obviously won't be acceptable as-is to my tree. Shouldn't this
> be something to be dealt with in config.mak.uname or something that
> is meant to define platform-specific customization?
The issue here is that we're not locating relocatable perl modules during
testing. This is a general problem with testing RUNTIME_PREFIX configurations,
and a more general solution to this sledgehammer would be appropriate. I don't
think config.mak.uname really makes sense since it's a general RUNTIME_PREFIX
issue and not specifically a darwin issue.
>
>>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index 0f1faa24b2..4060a53f56 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -1017,6 +1017,9 @@ fi
>>
>> GITPERLLIB="$GIT_BUILD_DIR"/perl/build/lib
>> export GITPERLLIB
>> +PERL_VERSION=$(grep DEFAULT /usr/local/versioner/perl/versions | sed
>> 's:^.*= *\([^ ]*\)$:\1:')
>> +PERL5LIB="$GIT_BUILD_DIR"/perl:"$(xcode-select
>> -p)"/Library/Perl/$PERL_VERSION
>> +export PERL5LIB
>> test -d "$GIT_BUILD_DIR"/templates/blt || {
>> error "You haven't built things yet, have you?"
>> }
[PATCH (Apple Git) 11/13] Fix problem found from running the test suite.
From: Matt Wright
Signed-off-by: Matt Wright
---
git-svn.perl | 30 ++
1 file changed, 30 insertions(+)
diff --git a/git-svn.perl b/git-svn.perl
index 050f2a36f4..d29730be3b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1815,6 +1815,36 @@ sub complete_url_ls_init {
sub verify_ref {
my ($ref) = @_;
+
+ if ($ref =~ /^(.*)\^0$/) {
+ my $baseref = $1;
+ my $p = "$ENV{GIT_DIR}/$baseref";
+ $p = "$ENV{GIT_DIR}/refs/remotes/$baseref" unless -e $p;
+ $p = "$ENV{GIT_DIR}/refs/$baseref" unless -e $p;
+ $p = "$ENV{GIT_DIR}/refs/heads/$baseref" unless -e $p;
+
+ my $resolved = undef;
+ if (-e $p) {
+ open FH, $p;
+ $resolved = ;
+ chomp $resolved;
+ close FH;
+ } elsif (-e "$ENV{GIT_DIR}/packed-refs") {
+ open FH, "$ENV{GIT_DIR}/packed-refs";
+ while () {
+ if ($_ =~ /^([0-9a-fA-F]+)
((refs\/)?(remotes\/|heads\/|\/)?$baseref)$/) {
+ $resolved = $1;
+ last;
+ }
+ }
+ }
+
+ if (defined($resolved)) {
+ return verify_ref("$1^0") if $resolved =~ /^ref: (.*)$/;
+ return $resolved
+ }
+ }
+
eval { command_oneline([ 'rev-parse', '--verify', $ref ],
{ STDERR => 0 }); };
}
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 02/13] test-lib: Export PERL5LIB for testing git-svn
Signed-off-by: Jeremy Huddleston Sequoia
---
t/test-lib.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0f1faa24b2..4060a53f56 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1017,6 +1017,9 @@ fi
GITPERLLIB="$GIT_BUILD_DIR"/perl/build/lib
export GITPERLLIB
+PERL_VERSION=$(grep DEFAULT /usr/local/versioner/perl/versions | sed 's:^.*=
*\([^ ]*\)$:\1:')
+PERL5LIB="$GIT_BUILD_DIR"/perl:"$(xcode-select -p)"/Library/Perl/$PERL_VERSION
+export PERL5LIB
test -d "$GIT_BUILD_DIR"/templates/blt || {
error "You haven't built things yet, have you?"
}
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 13/13] Enable support for Xcode.app-bundled gitattributes
Signed-off-by: Jeremy Huddleston Sequoia
---
attr.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/attr.c b/attr.c
index eaece6658d..1b87905d4a 100644
--- a/attr.c
+++ b/attr.c
@@ -823,6 +823,14 @@ static const char *git_etc_gitattributes(void)
return system_wide;
}
+static const char *git_xcode_gitattributes(void)
+{
+ static const char *xcode_gitattributes;
+ if (!xcode_gitattributes)
+ xcode_gitattributes =
system_path("share/git-core/gitattributes");
+ return xcode_gitattributes;
+}
+
static const char *get_home_gitattributes(void)
{
if (!git_attributes_file)
@@ -864,6 +872,9 @@ static void bootstrap_attr_stack(const struct index_state
*istate,
/* system-wide frame */
if (git_attr_system()) {
+ e = read_attr_from_file(git_xcode_gitattributes(), 1);
+ push_stack(stack, e, NULL, 0);
+
e = read_attr_from_file(git_etc_gitattributes(), 1);
push_stack(stack, e, NULL, 0);
}
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 12/13] Enable support for Xcode.app-bundled gitconfig
Useful for setting up osxkeychain in Xcode.app's gitconfig
Signed-off-by: Jeremy Huddleston Sequoia
---
config.c | 13 +
config.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/config.c b/config.c
index ff521eb27a..656bfef8ab 100644
--- a/config.c
+++ b/config.c
@@ -1631,6 +1631,14 @@ const char *git_etc_gitconfig(void)
return system_wide;
}
+const char *git_xcode_gitconfig(void)
+{
+ static const char *xcode_config;
+ if (!xcode_config)
+ xcode_config = system_path("share/git-core/gitconfig");
+ return xcode_config;
+}
+
/*
* Parse environment variable 'k' as a boolean (in various
* possible spellings); if missing, use the default value 'def'.
@@ -1673,6 +1681,11 @@ static int do_git_config_sequence(const struct
config_options *opts,
else
repo_config = NULL;
+ current_parsing_scope = CONFIG_SCOPE_XCODE;
+ if (git_config_system() && git_xcode_gitconfig() &&
!access_or_die(git_xcode_gitconfig(), R_OK, 0))
+ ret += git_config_from_file(fn, git_xcode_gitconfig(),
+ data);
+
current_parsing_scope = CONFIG_SCOPE_SYSTEM;
if (git_config_system() && !access_or_die(git_etc_gitconfig(), R_OK, 0))
ret += git_config_from_file(fn, git_etc_gitconfig(),
diff --git a/config.h b/config.h
index ee5d3fa7b4..f848423d28 100644
--- a/config.h
+++ b/config.h
@@ -115,6 +115,7 @@ extern int git_config_rename_section_in_file(const char *,
const char *, const c
extern int git_config_copy_section(const char *, const char *);
extern int git_config_copy_section_in_file(const char *, const char *, const
char *);
extern const char *git_etc_gitconfig(void);
+extern const char *git_xcode_gitconfig(void);
extern int git_env_bool(const char *, int);
extern unsigned long git_env_ulong(const char *, unsigned long);
extern int git_config_system(void);
@@ -131,6 +132,7 @@ enum config_scope {
CONFIG_SCOPE_GLOBAL,
CONFIG_SCOPE_REPO,
CONFIG_SCOPE_CMDLINE,
+ CONFIG_SCOPE_XCODE,
};
extern enum config_scope current_config_scope(void);
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 03/13] t0500: New regression test for git add of a path that contains a .git directory
Signed-off-by: Jeremy Huddleston Sequoia
---
t/t0500-apple.sh | 40
1 file changed, 40 insertions(+)
create mode 100755 t/t0500-apple.sh
diff --git a/t/t0500-apple.sh b/t/t0500-apple.sh
new file mode 100755
index 00..d5f79237a8
--- /dev/null
+++ b/t/t0500-apple.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+#
+# Copyright (c) 2012-2016 Apple Inc.
+#
+# Tests for regressions found by Apple Inc. for issues that upstream does not
+# want to fix or accept tests for.
+
+
+test_description='Apple Inc. specific tests'
+
+. ./test-lib.sh
+
+TESTROOT=$(pwd)
+
+#
+#
+# This test case addresses a regression introduced between v1.7.3 and v1.7.5
+# git bisect good v1.7.3
+# git bisect bad v1.7.5
+# ...
+# found 18e051a3981f38db08521bb61ccf7e4571335353
+
+test_expect_success ' -- git add of a path that
contains a .git directory' '
+ rm -rf .git &&
+ mkdir -p orig/sub/dir/otherdir &&
+ cd orig/sub &&
+ echo "1" > dir/file &&
+ echo "2" > dir/otherdir/file &&
+ git init --quiet &&
+ git add -A &&
+ git commit -m "Initial Commit" --quiet &&
+ cd - > /dev/null &&
+ git init --bare --quiet "${TESTROOT}/git_dir.git" &&
+ git --git-dir="${TESTROOT}/git_dir.git" --work-tree=/ add -f --
"${TESTROOT}/orig/sub/" &&
+ git --git-dir="${TESTROOT}/git_dir.git" --work-tree=/ add -f --
"${TESTROOT}/orig/" &&
+ git --git-dir="${TESTROOT}/git_dir.git" --work-tree=/ commit -m
"Commit." |
+ grep -q "2 files changed, 2 insertions"
+'
+
+test_done
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 07/13] HTML documentation is not provided with Apple's git. Make the error message more on point.
Signed-off-by: Jeremy Huddleston Sequoia
---
builtin/help.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/help.c b/builtin/help.c
index 7739a5c155..e001b6157c 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -383,7 +383,7 @@ static void get_html_page_path(struct strbuf *page_path,
const char *page)
if (!strstr(html_path, "://")) {
if (stat(mkpath("%s/git.html", html_path), &st)
|| !S_ISREG(st.st_mode))
- die("'%s': not a documentation directory.", html_path);
+ die("HTML documentation is not provided by this
distribution of git.");
}
strbuf_init(page_path, 0);
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 10/13] Support for Xcode.app co-exestince and relocation
This patch has been trimmed down significantly from its original version
when rebasing on top of git 2.18 because git 2.18 included support for
runtime prefix support for darwin, making this patch mostly duplicative.
The remaining changes are needed to ensure that git-perl can find the
subversion perl module (which relocates with it) and handle relocation
of python scripts.
Signed-off-by: Jeremy Huddleston Sequoia
---
Makefile | 3 +++
.../runtime_prefix.template.pl| 25 +++
2 files changed, 28 insertions(+)
diff --git a/Makefile b/Makefile
index 60711d6abe..97f46444f5 100644
--- a/Makefile
+++ b/Makefile
@@ -2171,6 +2171,7 @@ GIT-PERL-HEADER: $(PERL_HEADER_TEMPLATE) GIT-PERL-DEFINES
Makefile
sed -e 's=@@PATHSEP@@=$(pathsep)=g' \
-e "s=@@INSTLIBDIR@@=$$INSTLIBDIR=g" \
-e 's=@@PERLLIBDIR_REL@@=$(perllibdir_relative_SQ)=g' \
+ -e 's=@@PERLVERSION@@=$(shell grep DEFAULT
/usr/local/versioner/perl/versions | sed 's:^.*= *\([^ ]*\)$$:\1:')=g' \
-e 's=@@GITEXECDIR_REL@@=$(gitexecdir_relative_SQ)=g' \
-e 's=@@LOCALEDIR_REL@@=$(localedir_relative_SQ)=g' \
$< >$@+ && \
@@ -2206,6 +2207,8 @@ $(SCRIPT_PYTHON_GEN): GIT-CFLAGS GIT-PREFIX
GIT-PYTHON-VARS
$(SCRIPT_PYTHON_GEN): % : %.py
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
+ -e 's|\(os\.getenv("GITPYTHONLIB"\)[^)]*)|\1,"@@INSTLIBDIR@@")|' \
+ -e
's|"@@INSTLIBDIR@@"|os.path.realpath(os.path.dirname(sys.argv[0])) +
"/../../share/git-core/python"|g' \
$< >$@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/perl/header_templates/runtime_prefix.template.pl
b/perl/header_templates/runtime_prefix.template.pl
index 9d28b3d863..b0b6b0bef1 100644
--- a/perl/header_templates/runtime_prefix.template.pl
+++ b/perl/header_templates/runtime_prefix.template.pl
@@ -1,3 +1,28 @@
+# BEGIN XCODE RUNTIME_PREFIX generated code
+BEGIN {
+use File::Spec;
+my $PERLVERSION = "@@PERLVERSION@@";
+if ($^V =~ m/v([0-9]+).([0-9]+)/) {
+$PERLVERSION = $1.".".$2;
+}
+my $__prefix = File::Spec->rel2abs( __FILE__ );
+
+if ($__prefix =~ m/\/libexec\/git-core\// ) {
+$__prefix =~ s/\/libexec\/git-core\/.*//;
+unshift @INC, $__prefix . "/share/git-core/perl";
+unshift @INC, $__prefix .
"/../Library/Perl/".$PERLVERSION."/darwin-thread-multi-2level";
+} elsif ($__prefix =~ m/\/bin\// ) {
+$__prefix =~ s/\/bin\/.*//;
+unshift @INC, $__prefix . "/share/git-core/perl";
+unshift @INC, $__prefix .
"/../Library/Perl/".$PERLVERSION."/darwin-thread-multi-2level";
+} elsif ( $__prefix =~ m/\/usr\// ) {
+$__prefix =~ s/\/usr\/.*/\/usr/;
+unshift @INC, $__prefix . "/share/git-core/perl";
+unshift @INC, $__prefix .
"/../Library/Perl/".$PERLVERSION."/darwin-thread-multi-2level";
+}
+}
+# END XCODE RUNTIME_PREFIX generated code.
+
# BEGIN RUNTIME_PREFIX generated code.
#
# This finds our Git::* libraries relative to the script's runtime path.
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 04/13] t4014: git --version can have SP in it
480871e09e ("format-patch: show base info before email signature",
2016-09-07) added a helper function to recreate the signature at the end
of the e-mail, i.e. "-- " line followed by the version string of Git,
using output from "git --version" and stripping everything before the last
SP.
Because the default Git version string looks like "git version
2.10.0-1-g480871e09e", this was mostly OK, but people can change this
version string to arbitrary thing while compiling, which can break the
assumption if they had SP in it. Notably, Apple ships modified Git with
" (Apple Git-xx)" appended to its version number.
Instead, come up with the version string by stripping the "git version "
from the beginning.
Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae
Signed-off-by: Jeremy Huddleston Sequoia
Reviewed-by: Josh Triplett
---
t/t4014-format-patch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 909c743c13..414c56fcff 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -757,7 +757,7 @@ test_expect_success 'format-patch --ignore-if-in-upstream
HEAD' '
git format-patch --ignore-if-in-upstream HEAD
'
-git_version="$(git --version | sed "s/.* //")"
+git_version="$(git --version | sed "s/git version //")"
signature() {
printf "%s\n%s\n\n" "-- " "${1:-$git_version}"
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 01/13] .gitignore: Remove *.s as it matches *.S on case insensitive filesystem
This was causing problems with ppc/sha1ppc.S Signed-off-by: Jeremy Huddleston Sequoia --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 0d77ea5894..a5db584576 100644 --- a/.gitignore +++ b/.gitignore @@ -195,7 +195,7 @@ *.deb /git.spec *.exe -*.[aos] +*.[ao] *.py[co] .depend/ *.gcda -- 2.20.0 (Apple Git-115)
[PATCH (Apple Git) 09/13] Use symbolic links rather than hard links for files in libexec
See Signed-off-by: Jeremy Huddleston Sequoia --- Makefile | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 1a44c811aa..60711d6abe 100644 --- a/Makefile +++ b/Makefile @@ -2065,10 +2065,7 @@ version.sp version.s version.o: EXTRA_CPPFLAGS = \ git rev-parse -q --verify HEAD 2>/dev/null)"' $(BUILT_INS): git$X - $(QUIET_BUILT_IN)$(RM) $@ && \ - ln $< $@ 2>/dev/null || \ - ln -s $< $@ 2>/dev/null || \ - cp $< $@ + $(QUIET_BUILT_IN)ln -fs $< $@ command-list.h: generate-cmdlist.sh command-list.txt @@ -2387,7 +2384,6 @@ git-remote-testsvn$X: remote-testsvn.o GIT-LDFLAGS $(GITLIBS) $(VCSSVN_LIB) $(REMOTE_CURL_ALIASES): $(REMOTE_CURL_PRIMARY) $(QUIET_LNCP)$(RM) $@ && \ - ln $< $@ 2>/dev/null || \ ln -s $< $@ 2>/dev/null || \ cp $< $@ -- 2.20.0 (Apple Git-115)
[PATCH (Apple Git) 06/13] Set Apple Git version during build
Signed-off-by: Jeremy Huddleston Sequoia --- GIT-VERSION-GEN | 4 1 file changed, 4 insertions(+) diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN index d1a2814ec7..6fb90854b9 100755 --- a/GIT-VERSION-GEN +++ b/GIT-VERSION-GEN @@ -3,6 +3,10 @@ GVF=GIT-VERSION-FILE DEF_VER=v2.20.1 +if [ -n "$RC_ProjectSourceVersion" ] ; then + DEF_VER="$DEF_VER (Apple Git-$RC_ProjectSourceVersion)" +fi + LF=' ' -- 2.20.0 (Apple Git-115)
[PATCH (Apple Git) 00/13] Differences between git-2.20.1 and Apple Git-116
Xcode 10.2 Beta 1 contains Apple Git-116. A couple months ago, Peff encouraged me to re-send our changes in a patch series to the mailing list, so here they are! As reference, these (and past patch series for Apple Git) are availale at: https://github.com/jeremyhu/git Some of these patches are upstreamable as is, but othes represent areas where customization options could be provided upstream to allow similar behavior. Note that I am very grateful for the recent changes in mainline to support RUNTIME_PREFIX on darwin. It almost completely replaced our RUNTIME_PREFIX implementation and made the few remaining changes much more maintainale. Please integrate the changes that are upstreamable and let's use the others as a starting point for discussing how to accomplish the same effect through configuration options or other means. Thanks, Jeremy
[PATCH (Apple Git) 08/13] git mergetool/difftool doesn't list 'opendiff' as an available tool on 10.8
See
Signed-off-by: Jeremy Huddleston Sequoia
---
git-mergetool--lib.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 83bf52494c..f85be7406f 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -273,9 +273,9 @@ list_merge_tool_candidates () {
then
if test -n "$GNOME_DESKTOP_SESSION_ID"
then
- tools="meld opendiff kdiff3 tkdiff xxdiff $tools"
+ tools="meld kdiff3 tkdiff xxdiff $tools"
else
- tools="opendiff kdiff3 tkdiff xxdiff meld $tools"
+ tools="kdiff3 tkdiff xxdiff meld $tools"
fi
tools="$tools gvimdiff diffuse diffmerge ecmerge"
tools="$tools p4merge araxis bc codecompare"
@@ -288,6 +288,8 @@ list_merge_tool_candidates () {
tools="$tools emerge vimdiff"
;;
esac
+
+ tools="opendiff $tools"
}
show_tool_help () {
--
2.20.0 (Apple Git-115)
[PATCH (Apple Git) 05/13] t5701: git --version can have SP in it
Signed-off-by: Jeremy Huddleston Sequoia --- t/t5701-git-serve.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5701-git-serve.sh b/t/t5701-git-serve.sh index ae79c6bbc0..7bc25700fa 100755 --- a/t/t5701-git-serve.sh +++ b/t/t5701-git-serve.sh @@ -7,7 +7,7 @@ test_description='test git-serve and server commands' test_expect_success 'test capability advertisement' ' cat >expect <<-EOF && version 2 - agent=git/$(git version | cut -d" " -f3) + agent=git/$(git --version | sed -e "s/git version //" -e "s/ /\./g") ls-refs fetch=shallow server-option -- 2.20.0 (Apple Git-115)
Re: Strange bug with "git log" - pdftotext?
I discovered it was an issue with the version of Git for Windows I was using. Upgraded to the latest version and it works now. -- Best regards, Jeremy Morton (Jez) On 30/07/2018 16:37, Jeff King wrote: On Mon, Jul 30, 2018 at 01:49:46PM +0100, Jeremy Morton wrote: I'm trying to search my git log history for a particular term - "unobtrusive" - so I run this command: git log -S unobtrusive --oneline When I do this, this is displayed and I'm in an interactive less terminal or something: pdftotext version 4.00 [...] That's definitely weird. My guess is that the repository has some .gitattributes set up to diff pdf files in a particular way, and you have some matching config that tries to call pdftotext. What does: git config --list | grep ^diff say? I'd expect to see an external or textconv option there running pdftotext. Another option is that your pager is somehow set up to call pdftotext, but that seems much more nonsensical to use the tool there (but try "git var GIT_PAGER" and "git config pager.log" to check). -Peff
Strange bug with "git log" - pdftotext?
I'm trying to search my git log history for a particular term - "unobtrusive" - so I run this command: git log -S unobtrusive --oneline When I do this, this is displayed and I'm in an interactive less terminal or something: pdftotext version 4.00 Copyright 1996-2017 Glyph & Cog, LLC Usage: pdftotext [options] [] -f : first page to convert -l : last page to convert -layout : maintain original physical layout -simple : simple one-column page layout -table : similar to -layout, but optimized for tables -lineprinter : use strict fixed-pitch/height layout -raw : keep strings in content stream order -fixed : assume fixed-pitch (or tabular) text -linespacing : fixed line spacing for LinePrinter mode -clip: separate clipped text -nodiag : discard diagonal text -enc : output text encoding name -eol : output end-of-line convention (unix, dos, or mac) -nopgbrk : don't insert page breaks between pages -bom : insert a Unicode BOM at the start of the text file -opw : owner password (for encrypted files) -upw : user password (for encrypted files) -q : don't print any messages or errors -cfg : configuration file to use in place of .xpdfrc -v : print copyright and version info : When I hit the down arrow, it scrolls down, repeating this output infinitely until I hit 'q'. What is going on here?? -- Best regards, Jeremy Morton (Jez)
editing for your photos
How are you doing today? We have not heard from you yet. Are you still interested in our photo retouching services? We mainly do: e-commerce products photo retouching jewelry photos retouching model beauty/skin retouching wedding photo editing also photo cutting out, clipping path You may choose to send us a photo for testing which you can check our quality. Regards, Jeremy
Re: Subscribing Apple people to git-secur...@googlegroups.com
> On Jul 10, 2018, at 5:27 AM, Ævar Arnfjörð Bjarmason wrote: > > On Tue, Jul 3, 2018 at 3:36 PM, Jeff King wrote: >> On Mon, Jul 02, 2018 at 01:15:19PM -0700, Jeremy Huddleston Sequoia wrote: >> >>>> I hope that maybe they're also interested in reducing the overall >>>> diff between upstream Git and what ships with XCode. Last time I >>>> looked (which was admittedly a while ago), a lot of the changes >>>> seemed like things that could probably be considered upstream. >>> >>> I'm very very interested in having reduced differences between what we >>> ship in Xcode and what is upstream. I've been maintaining a repo with >>> our patches that I rebase as we move forward, in the hope that these >>> changes might be useful to others and a derivative of them might >>> eventually be accepted upstream. See >>> https://github.com/jeremyhu/git/commits/master for the current set of >>> changes that are in our shipping git (currently on top of 2.17.1). >> >> Thanks for sharing. Skimming over it, I see: >> >> - several of the changes look related to run-time relocation. There was >> a series that shipped in v2.18.0 related to this, so that may reduce >> your diff once you rebase. >> >> - The xcode_gitattributes() bits aren't likely to go upstream as-is. >> But possibly these could ship as a default $sysconfdir/gitattributes? >> >> - the rest look like assorted little fixes that probably could go >> upstream > > Jeremy, could you elaborate on what > https://github.com/jeremyhu/git/commit/61b42bc5d2 was about? I.e. > where was this discussed & tests for this refused? > > Seems sensible to me to have this in some form, but the test as-is > seems to be a general regression test, not Apple-specific, so it would > need to be changed somewhat, or does it only happen with some other > custom patch of yours? It was a bug in upstream git and not a bug specific to an Apple change. We haven't traditionally had many custom changes on our end. The few we have, we didn't feel they were appropriate or were often rejected when we tried (eg: using CommonCrypto and Security.framework, this one, etc.). For this particular case, I discussed the bug with the committer (Carlo) and reviewer (Junio) of the commit (18e051a3981f38db08521bb61ccf7e4571335353) via email back in October 2011. My proposed fix and test were never accepted. As such, we continued to ship my patch in Xcode's git and MacPorts' git until the underlying bug was actually fixed by someone else in 2014 (ddc2a6281595fd24ea01497c496f88c40a59562f + 655ee9ea3e6c0af57d320e84723ec3bf656cdbf7). I kept the test in our test suite to ensure we didn't regress. Here's the final post from that thread after the fix in 2014: --- Begin Message --- FWIW, it seems that this bug was addressed by ddc2a6281595fd24ea01497c496f88c40a59562f Thanks Martin, now we're no longer carrying around an extra patch for our build of git ;) --Jeremy > On Oct 17, 2011, at 14:55, Jeremy Huddleston wrote: > > ping. Did you get my response below with extra details? I just got a > duplicate bug report, so it apparently effects people... > > Please let me know if I can be of further assistance. > > On Oct 11, 2011, at 2:17 PM, Jeremy Huddleston wrote: > >> Thanks for your response Junio. The text of the original bug report is >> below. >> >> I created a git bisect test script which bisected the problem and found out >> that the difference was that the trailing / was removed by your code change. >> git treats paths with a trailing / differently. I don't know *why* it >> treats them differently, but it does. >> >> There's nothing "special" about JustDoItGit.tar.bz2 except that it contains >> a .git dir and has a file layout that works with the bisect script I wrote. >> You can test this yourself by: >> >> mkdir -p ~/tmp/PR-10238070 >> cd ~/tmp/PR-10238070 >> tar xjf JustDoItGit.tar.bz2 >> cd ~/git-checkout >> /path/to/test_10238070.sh >> >> Here's the original report: >> >> I've tracked the cause of ' ##snipped title##' down >> to a regression in git. >> >> Unzip the attached JustDoItGit.zip project and replace the path in the >> following commands to the unzipped location on your system: >> >> #delete git in /usr/bin/git >> sudo rm -r /usr/bin/git >> #link it to /usr/local/bin/git since that's where ditto will place the new >> bits >> sudo ln -s /usr/local/bin/git /usr/bin/git >> >&
Re: Subscribing Apple people to git-secur...@googlegroups.com
+Akila Hi, Replies inline. > On Jul 2, 2018, at 12:50, Jeff King wrote: > > On Mon, Jul 02, 2018 at 09:29:41PM +0200, Christian Couder wrote: > >> When people complained a month ago about the MacOS package on >> https://git-scm.com/ not being up-to-date after the Git security >> release, I got in touch with Apple people GitLab has been working with >> to see if they could help on this. > > Unfortunately I don't think this will quite solve the issue we had, just > because people get their copy of Git in various ways. So Homebrew > updated pretty promptly, but people going to git-scm.com to find a > binary package were left without help. Likewise, this will help people > getting Git as part of XCode, but not people gettin the package from > git-scm.com. > > All that said, I'm happy to get as many binary packagers into the loop > as early as possible. It can only help, even if it doesn't solve all > problems. :) > >> Please add these addresses to the git-security mailing list: >>jerem...@apple.com >>akils...@apple.com >>dt-...@group.apple.com > > Done. > >> Please add these GitHub accounts to the cabal repo: >>jeremyhu > > Done. > >>productsecurityOSSapple > > I couldn't find that account. Is it maybe a team name within the apple > org or something? This is the account name I got from Akila. Akila, can you please work with Jeff to get this sorted? In the mean time, I have access. > I am also personally very happy with the Apple developers' willingness >> to get involved and help. > > Yes, welcome aboard! > > I hope that maybe they're also interested in reducing the overall diff > between upstream Git and what ships with XCode. Last time I looked > (which was admittedly a while ago), a lot of the changes seemed like > things that could probably be considered upstream. I'm very very interested in having reduced differences between what we ship in Xcode and what is upstream. I've been maintaining a repo with our patches that I rebase as we move forward, in the hope that these changes might be useful to others and a derivative of them might eventually be accepted upstream. See https://github.com/jeremyhu/git/commits/master for the current set of changes that are in our shipping git (currently on top of 2.17.1). Thanks, Jeremy > > -Peff
Re: [PATCH v2] packfile: Correct zlib buffer handling
Hi, On Wed, Jun 13, 2018 at 1:38 PM, Junio C Hamano wrote: > Eric Sunshine writes: > >>> + buffer[size] = 0; /* assure that the buffer is still terminated */ >> >> I think we normally use '\0' for NUL on this project rather than simply 0. >> >> The comment is also effectively pure noise since it merely repeats >> what the code already states clearly (especially when the code says >> "buffer[size] = '\0';"), so dropping the comment altogether would be >> reasonable. > > Actually, I'd prefer to have comment there, but not about "what this > line does" (which is useless, as you pointed out) but about "why do > we do this seemingly redundant clearing". > > Here is what I tentatively came up with. > > -- >8 -- > From: Jeremy Linton > Date: Wed, 13 Jun 2018 09:22:07 -0500 > Subject: [PATCH] packfile: correct zlib buffer handling > > The buffer being passed to zlib includes a NUL terminator that git > needs to keep in place. unpack_compressed_entry() attempts to detect > the case that the source buffer hasn't been fully consumed by > checking to see if the destination buffer has been over consumed. > > This causes a problem, that more recent zlib patches have been > poisoning the unconsumed portions of the buffer which overwrites > the NUL byte, while correctly returning length and status. > > Let's place the NUL at the end of the buffer after inflate returns > to assure that it doesn't result in problems for git even if its > been overwritten by zlib. > > Signed-off-by: Jeremy Linton > Signed-off-by: Junio C Hamano > --- > packfile.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/packfile.c b/packfile.c > index 4a5fe7ab18..d555699217 100644 > --- a/packfile.c > +++ b/packfile.c > @@ -1422,6 +1422,9 @@ static void *unpack_compressed_entry(struct packed_git > *p, > return NULL; > } > > + /* versions of zlib can clobber unconsumed portion of outbuf */ > + buffer[size] = '\0'; > + > return buffer; > } > > -- > 2.18.0-rc1-1-g6f333ff2fb This is all fine with me, the original comment was an attempt to indicate that the original null may not have been there anymore too.. Shall I resubmit it as above, or can it be picked up like this?
[PATCH v2] packfile: Correct zlib buffer handling
The buffer being passed to zlib includes a null terminator that git needs to keep in place. unpack_compressed_entry() attempts to detect the case that the source buffer hasn't been fully consumed by checking to see if the destination buffer has been over consumed. This causes a problem, that more recent zlib patches have been poisoning the unconsumed portions of the buffer which overwrites the null, while correctly returning length and status. Let's replace the null at the end of the buffer to assure that if its been overwritten by zlib it doesn't result in problems for git. Signed-off-by: Jeremy Linton --- packfile.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/packfile.c b/packfile.c index 7c1a2519f..8db5d90ca 100644 --- a/packfile.c +++ b/packfile.c @@ -1433,6 +1433,8 @@ static void *unpack_compressed_entry(struct packed_git *p, return NULL; } + buffer[size] = 0; /* assure that the buffer is still terminated */ + return buffer; } -- 2.13.6
Re: [PATCH] packfile: Correct zlib buffer handling
Hi,
Sorry about the delay here (bit of a mix-up and didn't reply to the list).
(see inline )
On Sun, May 27, 2018 at 9:41 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Duy Nguyen writes:
>>
>>> On Sun, May 27, 2018 at 1:57 AM, Junio C Hamano wrote:
(trimming)
>
> Specifically, I was worried about this assertion:
>
> Lets rely on the fact that the source buffer will only be fully
> consumed when the when the destination buffer is inflated to the
> correct size.
>
> which I think is the exact bad thinking that caused troubles for us
> in the past; isn't the explanation in 456cdf6e ("Fix loose object
> uncompression check.", 2007-03-19) relevant here?
>
> - stream.avail_out = size + 1;
> + stream.avail_out = size;
> ...
> stream.next_in = in;
> st = git_inflate(&stream, Z_FINISH);
> if (!stream.avail_out)
> - break; /* the payload is larger than it should be */
> + break; /* done, st indicates if source fully consumed
> */
> curpos += stream.next_in - in;
> } while (st == Z_OK || st == Z_BUF_ERROR);
> git_inflate_end(&stream);
> if ((st != Z_STREAM_END) || stream.total_out != size) {
> free(buffer);
> return NULL;
> }
>
> With minimum stream.avail_out without slack, when !avail_out, i.e.
> when we fully filled the output buffer, it could be that we had
> correct input that deflates to the correct size, in which case we
> are happy---st would say Z_STREAM_END, we would leave the loop
> because it is neither OK nor BUF_ERROR, and total_out would report
> the size we expected. Or the input zlib stream may have ended with
> bytes that express "this concludes the stream", and the input bytes
> before that was sufficient to construct the original payload fully,
> and we may have just fed the bytes before that "this concludes the
> stream" to git_inflate().
>
> In such a case, we haven't consumed all the avail_in. We may
> already have all the correct output, i.e. !avail_out, but because we
> haven't consumed the "this concludes the stream", st is not
> STREAM_END in such a case.
If I understand correctly your concerned the avail_in is longer than
what is required to fill the output buffer..
I'm fairly sure that won't result in a Z_STREAM_END, as you rightfully
point out, but the loop _will_ terminate due to the output buffer
being full and then since its not Z_STREAM_END the
unpack_compressed_entry fails, as it should.
>
> Our existing while() loop, with one-byte slack in avail_out, would
> have let us continue and the next iteration of the loop would have
> consumed the input without producing any more output (i.e. avail_out
> would have been left to 1 in both of these final two rounds) and we
> would have exited the loop. After calling inflate_end(), we would
> have noticed STREAM_END and correct size and we would have been
> happy.
Your assuming that zlib will terminate with an error, but a fully
decompressed buffer, because it hasn't consumed the entire input
buffer. I don't think that is how it works (its not how the
documentation is written, nor the bits of code i've looked at seem to
work, which granted i'm not a zlib maintainer).
>
> The updated code would handle this latter case rather badly, no? We
> leave the loop early, notice st is not STREAM_END, and be very
> unhappy, because this patch did not give us to consume the very end
> of the input stream and left the loop early.
Your correct if the above case is a valid zlib behavior then there
would be a problem. But, I don't think the termination is dicated by
insufficient output space until there is an attempt to utilize that
space.
>
>>> This yields two problems, first a single byte overrun won't be detected
>>> properly because the Z_STREAM_END will then be set, but the null
>>> terminator will have been overwritten.
>
> Because we compare total_out and size at the end, we would detect it
> as an error in this function, no? Then zlib overwriting NUL would
> not be a problem, as we would free the buffer and return NULL, no?
>
>>> The other problem is that
>>> more recent zlib patches have been poisoning the unconsumed portions
>>> of the buffers which also overwrites the null, while correctly
>>> returning length and status.
>
> Isn't that a bug in zlib, though? Or do they do that deliberately?
>
> I think a workaround with lower impact would be to manually restore
> NUL at the end of the buffer.
I agree, just resetting the NULL its likely safer, and I will repost a
patch soon which if nothing else makes git more robust to errant zlib
behavior.
[PATCH] packfile: Correct zlib buffer handling
The buffer being passed to zlib includes a null terminator that
git needs to keep in place. unpack_compressed_entry() attempts to
detect the case that the source buffer hasn't been fully consumed
by checking to see if the destination buffer has been over consumed.
This yields two problems, first a single byte overrun won't be detected
properly because the Z_STREAM_END will then be set, but the null
terminator will have been overwritten. The other problem is that
more recent zlib patches have been poisoning the unconsumed portions
of the buffers which also overwrites the null, while correctly
returning length and status.
Lets rely on the fact that the source buffer will only be fully
consumed when the when the destination buffer is inflated to the
correct size. We can do this by passing zlib the correct buffer size
and properly checking the return status. The latter check actually
already exists if the buffer size is correct.
Signed-off-by: Jeremy Linton
---
packfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/packfile.c b/packfile.c
index 7c1a2519f..245eb3204 100644
--- a/packfile.c
+++ b/packfile.c
@@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
return NULL;
memset(&stream, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size + 1;
+ stream.avail_out = size;
git_inflate_init(&stream);
do {
@@ -1424,7 +1424,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
if (!stream.avail_out)
- break; /* the payload is larger than it should be */
+ break; /* done, st indicates if source fully consumed */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end(&stream);
--
2.13.6
[PATCH] packfile: Correct zlib buffer handling
The buffer being passed to zlib includes a null terminator that
git needs to keep in place. unpack_compressed_entry() attempts to
detect the case that the source buffer hasn't been fully consumed
by checking to see if the destination buffer has been over consumed.
This yields two problems, first a single byte overrun won't be detected
properly because the Z_STREAM_END will then be set, but the null
terminator will have been overwritten. The other problem is that
more recent zlib patches have been poisoning the unconsumed portions
of the buffers which also overwrites the null, while correctly
returning length and status.
Lets rely on the fact that the source buffer will only be fully
consumed when the when the destination buffer is inflated to the
correct size. We can do this by passing zlib the correct buffer size
and properly checking the return status. The latter check actually
already exists if the buffer size is correct.
Signed-off-by: Jeremy Linton
---
packfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/packfile.c b/packfile.c
index 7c1a2519f..245eb3204 100644
--- a/packfile.c
+++ b/packfile.c
@@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
return NULL;
memset(&stream, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size + 1;
+ stream.avail_out = size;
git_inflate_init(&stream);
do {
@@ -1424,7 +1424,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
if (!stream.avail_out)
- break; /* the payload is larger than it should be */
+ break; /* done, st indicates if source fully consumed */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end(&stream);
--
2.13.6
Re: Null pointer dereference in git-submodule
Reply-To:
Hmm... That's weird. I can reproduce it on 3 independant systems with
versions 2.16.2 up, although it does not work with version 2.11.0.
Anyway, I figured out how to reproduce this bug. It is caused when a
submodule is added and then the directory it resides in is moved or
deleted without commiting. For example:
git init
git submodule add https://github.com/git/git git
mv git git.BAK
git submodule status #this command segfaults
cheers
Jeremy
In-Reply-To:
On Sat, Mar 24, 2018 at 09:42:57PM +0100, René Scharfe wrote:
> Am 24.03.2018 um 18:42 schrieb Jeremy Feusi:
> > Hi,
> > While bootstrapping a gnu repository I noticed that git segfaulted when
> > called as "git submodule status". After compiling git with address
> > sanitizer and minimizing the directory I finally narrowed it down to the
> > files which I have attached as a tar archive. Here is a detailed backtrace:
> >
> > AddressSanitizer:DEADLYSIGNAL
> > =
> > ==63400==ERROR: AddressSanitizer: SEGV on unknown address 0x
> > (pc 0x00c27a93 bp 0x7ffdcb4eec10 sp 0x7ffdcb4eeb80 T0)
> > ==63400==The signal is caused by a READ memory access.
> > ==63400==Hint: address points to the zero page.
> > #0 0xc27a92 in refs_read_raw_ref /home/jfe/git/refs.c:1451:20
> > #1 0xc174a6 in refs_resolve_ref_unsafe /home/jfe/git/refs.c:1493:7
> > #2 0xc1826a in refs_read_ref_full /home/jfe/git/refs.c:224:6
> > #3 0xc26d53 in refs_head_ref /home/jfe/git/refs.c:1314:7
> > #4 0x8071e6 in status_submodule
> > /home/jfe/git/builtin/submodule--helper.c:658:7
> > #5 0x806a89 in status_submodule_cb
> > /home/jfe/git/builtin/submodule--helper.c:699:2
> > #6 0x80523e in for_each_listed_submodule
> > /home/jfe/git/builtin/submodule--helper.c:438:3
> > #7 0x7f7e9a in module_status
> > /home/jfe/git/builtin/submodule--helper.c:732:2
> > #8 0x7efd69 in cmd_submodule__helper
> > /home/jfe/git/builtin/submodule--helper.c:1859:11
> > #9 0x51e024 in run_builtin /home/jfe/git/git.c:346:11
> > #10 0x5192c2 in handle_builtin /home/jfe/git/git.c:554:8
> > #11 0x51d0f0 in run_argv /home/jfe/git/git.c:606:4
> > #12 0x518600 in cmd_main /home/jfe/git/git.c:683:19
> > #13 0x8501d6 in main /home/jfe/git/common-main.c:43:9
> > #14 0x7f49fdaf2f29 in __libc_start_main
> > (/lib/x86_64-linux-gnu/libc.so.6+0x20f29)
> > #15 0x41f4b9 in _start
> > (/home/jfe/git/inst/libexec/git-core/git+0x41f4b9)
> >
> > AddressSanitizer can not provide additional info.
> > SUMMARY: AddressSanitizer: SEGV /home/jfe/git/refs.c:1451:20 in
> > refs_read_raw_ref
> > ==63400==ABORTING
> >
> > As mentioned above, this bug is triggered by issuing the command
> > "git submodule status" while in the attached directory.
> >
> > This bug was confirmed on Debian with version 2.16.1 and
> > 2.17.0.rc1.35.g90bbd502d as well as on Arch Linux with version 2.16.2
> > where further output is given by git:
> >
> > /usr/lib/git-core/git-submodule: line 979: 8119 Segmentation fault
> > (core dumped) git ${wt_prefix:+-C "$wt_prefix"} ${prefix:+--super-prefix
> > "$prefix"} submodule--helper status ${GIT_QUIET:+--quiet}
> > ${cached:+--cached} ${recursive:+--recursive} "$@"
> >
>
> You may have minimized too much. With the patch below I get:
>
> fatal: no ref store in submodule 'gnulib'
>
> I guess you'll get a different one in your original repo.
>
> The patch seems like a good idea in any case, though.
>
> -- >8 --
> Subject: [PATCH] submodule: check for NULL return of get_submodule_ref_store()
>
> refs_head_ref() requires a valid ref_store pointer to be given as its
> first argument. get_submodule_ref_store() can return NULL. Exit and
> report the failure to find a ref store in that case instead of
> segfaulting.
>
> Reported-by: Jeremy Feusi
> Signed-off-by: Rene Scharfe
> ---
> builtin/submodule--helper.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index ee020d4749..0f74e81005 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -654,9 +654,11 @@ static void status_submodule(const char *path, const
> struct object_id *ce_oid,
>displaypath);
> } else if (!(flags & OPT_CACHED)) {
> struct object_id oid;
> + struct ref_store *refs = get_submodule_ref_store(path);
>
> - if (refs_head_ref(get_submodule_ref_store(path),
> - handle_submodule_head_ref, &oid))
> + if (!refs)
> + die(_("no ref store in submodule '%s'"), path);
> + if (refs_head_ref(refs, handle_submodule_head_ref, &oid))
> die(_("could not resolve HEAD ref inside the "
> "submodule '%s'"), path);
>
> --
> 2.16.3
Null pointer dereference in git-submodule
Hi,
While bootstrapping a gnu repository I noticed that git segfaulted when
called as "git submodule status". After compiling git with address
sanitizer and minimizing the directory I finally narrowed it down to the
files which I have attached as a tar archive. Here is a detailed backtrace:
AddressSanitizer:DEADLYSIGNAL
=
==63400==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x00c27a93 bp 0x7ffdcb4eec10 sp 0x7ffdcb4eeb80 T0)
==63400==The signal is caused by a READ memory access.
==63400==Hint: address points to the zero page.
#0 0xc27a92 in refs_read_raw_ref /home/jfe/git/refs.c:1451:20
#1 0xc174a6 in refs_resolve_ref_unsafe /home/jfe/git/refs.c:1493:7
#2 0xc1826a in refs_read_ref_full /home/jfe/git/refs.c:224:6
#3 0xc26d53 in refs_head_ref /home/jfe/git/refs.c:1314:7
#4 0x8071e6 in status_submodule
/home/jfe/git/builtin/submodule--helper.c:658:7
#5 0x806a89 in status_submodule_cb
/home/jfe/git/builtin/submodule--helper.c:699:2
#6 0x80523e in for_each_listed_submodule
/home/jfe/git/builtin/submodule--helper.c:438:3
#7 0x7f7e9a in module_status /home/jfe/git/builtin/submodule--helper.c:732:2
#8 0x7efd69 in cmd_submodule__helper
/home/jfe/git/builtin/submodule--helper.c:1859:11
#9 0x51e024 in run_builtin /home/jfe/git/git.c:346:11
#10 0x5192c2 in handle_builtin /home/jfe/git/git.c:554:8
#11 0x51d0f0 in run_argv /home/jfe/git/git.c:606:4
#12 0x518600 in cmd_main /home/jfe/git/git.c:683:19
#13 0x8501d6 in main /home/jfe/git/common-main.c:43:9
#14 0x7f49fdaf2f29 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x20f29)
#15 0x41f4b9 in _start (/home/jfe/git/inst/libexec/git-core/git+0x41f4b9)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/jfe/git/refs.c:1451:20 in
refs_read_raw_ref
==63400==ABORTING
As mentioned above, this bug is triggered by issuing the command
"git submodule status" while in the attached directory.
This bug was confirmed on Debian with version 2.16.1 and
2.17.0.rc1.35.g90bbd502d as well as on Arch Linux with version 2.16.2
where further output is given by git:
/usr/lib/git-core/git-submodule: line 979: 8119 Segmentation fault (core
dumped) git ${wt_prefix:+-C "$wt_prefix"} ${prefix:+--super-prefix "$prefix"}
submodule--helper status ${GIT_QUIET:+--quiet} ${cached:+--cached}
${recursive:+--recursive} "$@"
cheers
Jeremy
min-man.tar.gz
Description: application/gzip
feature request: git-config: Add conditional include for gitbranch
Use Case == Jeremy is a developer for Debian and Ubuntu. The same repository is used for both Debian and Ubuntu packaging but with different branches. For commits to the debian/master branch, Jeremy wants to use his @debian.org email address. For commits to the ubuntu/master branch, Jeremy wants to use his @ubuntu.com email. Proposal === The includeIf feature of git-config could be extended to offer a gitbranch conditional include in addition to the gitdir conditional include it already offers. Thanks, Jeremy Bicha
Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Did this ever get anywhere? If not why not? It would be very useful to me to be able to clone recursively by default, especially considering you can't use 'alias' to override the existing 'clone' command. -- Best regards, Jeremy Morton (Jez) On 06/06/2014 06:26, Heiko Voigt wrote: On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote: Jens Lehmann writes: We had two settings in mind,... So what if clone would just do an "git submodule init" for now when "submodule.autoinit" is set but "submodule.autoupdate" isn't [?] ... and a single "submodule.auto" setting would be what users really want? I do not offhand think of a sensible scenario where you want to init a submodule once but do not want to update it when the superproject changes. Even if the user uses the mode to detach the submodule HEAD, i.e. the branches in submodules do not matter and the whole tree is described by the superproject's commit and gitlinks recorded in it, the user would want the new objects necessary for the updated superproject, which means a submodule that is init'ed (whether it is via "git submodule init" or the submodule.autoinit variable) must be updated. So I am not sure why a user wants to disable autoupdate in the first place. For the same reason, setting submodule.*.update to none would not make much sense, either. Perhaps I am missing something. Unless the user is very conservative and suspects that these recursive behaviour we are going to bolt on to various commands could be buggy and untrustworthy, in which case the user might want to manually run "git submodule update", or even run "git fetch" after going there while bypassing the whole "git submodule". But I do not think that is healthy in the longer run. I think autoupdate is mainly there for the transition phase. Since submodule can e.g. contain a lot of files a checkout would take much longer. Similar to when Jens implemented the recursive diff, many people were annoyed by the new files showing up and some with the impact on performance (thats why we have the --ignore-submodules option). In case of very big submodules and people already ignore their diff it might even be necessary that the update is only done manually. E.g. for a big media repository. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.10.1 test regression in t3700-add.sh
> On Oct 10, 2016, at 10:41, Junio C Hamano wrote:
>
> Jeremy Huddleston Sequoia writes:
>
>> Actually, looks like that as just a rabbit hole. The real issue
>> looks to be because an earlier test drops down xfoo3 as a symlink,
>> which causes this test to fail due to the collision. I'll get out
>> a patch in a bit.
>
> [administrivia: please don't top-post, it is extremely hard to
> follow what is going on]
>
> There indeed is a test that creates xfoo3 as a symbolic link and
> leaves it in the filesystem pointing at xfoo2 much earlier in the
> sequence. It seems that later one of the "add ignore-errors" tests
> (there are two back-to-back) runs "git reset --hard" to make it (and
> other symbolic links that are similarly named) go away, namely this
> part of the code:
>
>test_expect_success POSIXPERM,SANITY 'git add --ignore-errors' '
>git reset --hard &&
>date >foo1 &&
>date >foo2 &&
>chmod 0 foo2 &&
>test_must_fail git add --verbose --ignore-errors . &&
>git ls-files foo1 | grep foo1
>'
>
>rm -f foo2
>
>test_expect_success POSIXPERM,SANITY 'git add (add.ignore-errors)' '
>git config add.ignore-errors 1 &&
>git reset --hard &&
>date >foo1 &&
>date >foo2 &&
>chmod 0 foo2 &&
>test_must_fail git add --verbose . &&
>git ls-files foo1 | grep foo1
>'
>rm -f foo2
>
> "git reset --hard" in the first one, because these symbolic links
> are not in the index at that point in the sequence, would leave them
> untracked and in the working tree. Then "add" is told to be
> non-atomic with "--ignore-errors", adding them to the index while
> reporting a failure. When the test after that runs "git reset --hard"
> again, because these symlinks are in the index (and not in HEAD),
> they are removed from the working tree.
>
> And that is why normal people won't see xfoo3 in later tests, like
> the one you had trouble with.
>
> Are you running without SANITY by any chance (I am not saying that
> you are doing a wrong thing--just trying to make sure I am guessing
> along the correct route)?
Ah, yep. That's the ticket:
ok 23 # skip git add should fail atomically upon an unreadable file (missing
SANITY of POSIXPERM,SANITY)
ok 24 # skip git add --ignore-errors (missing SANITY of POSIXPERM,SANITY)
ok 25 # skip git add (add.ignore-errors) (missing SANITY of POSIXPERM,SANITY)
ok 26 # skip git add (add.ignore-errors = false) (missing SANITY of
POSIXPERM,SANITY)
ok 27 # skip --no-ignore-errors overrides config (missing SANITY of
POSIXPERM,SANITY)
I dug into it a bit, and since I'm running the tests during a staging phase
which runs as root, !SANITY gets set. Should be solvable by essentially
breaking test out into post-build instead of pre-install. Thanks for the
pointer there.
> If that is the issue, then I think the right correction would be to
> make sure that the files that an individual test expects to be
> missing from the file system is indeed missing by explicitly
> removing it, perhaps like this.
>
> I also notice that the problematic test uses "chmod 755"; don't we
> need POSIXPERM prerequisite on this test, too, I wonder?
>
> Thanks.
>
> -- >8 --
> t3700: fix broken test under !SANITY
>
> An "add --chmod=+x" test recently added by 610d55af0f ("add: modify
> already added files when --chmod is given", 2016-09-14) used "xfoo3"
> as a test file. The paths xfoo[1-3] were used by earlier tests for
> symbolic links but they were expected to have been removed by the
> test script reached this new test.
>
> The removal with "git reset --hard" however happened in tests that
> are protected by POSIXPERM,SANITY prerequisites. Platforms and test
> environments that lacked these would have seen xfoo3 as a leftover
> symbolic link, pointing somewhere else, and chmod test would have
> given a wrong result.
>
>
>
> t/t3700-add.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> index 924a266126..53c0cb6dea 100755
> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -350,6 +350,7 @@ test_expect_success POSIXPERM,SYMLINKS 'git add
> --chmod=+x with symlinks' '
> '
>
> test_expect_success 'git add --chmod=[+-]x changes index with already added
> file' '
> + rm -f foo3 xfoo
Re: [PATCH] t3700-add.sh: Avoid filename collission between tests which could lead to test failure
> On Oct 10, 2016, at 09:44, Junio C Hamano wrote: > > Jeremy Huddleston Sequoia writes: > >> Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c >> Signed-off-by: Jeremy Huddleston Sequoia >> CC: Thomas Gummerer >> CC: Junio C Hamano > > This is also under-explained. Was the test broken for everybody and > you are the first to report, or was your environment somehow different > that the existing problem was revealed there first? There is nothing obviously different about my environment. I'd expect this test to fail for everyone that runs the entire test because xfoo3 is not cleaned up after this earlier test: test_expect_success \ 'git update-index --add: Test that executable bit is not used...' \ 'git config core.filemode 0 && test_ln_s_add xfoo2 xfoo3 && # runs git update-index --add test_mode_in_index 12 xfoo3' If anyone ran the test by itself or otherwise skipped the 'git update-index --add: Test that executable bit is not used...' test, they would not encounter the issue. However, the normal case is to run all of the tests, so I would expect everyone to be tripping over this issue. If they're not, then that itself might be indicative of another bug because clearly that previous test just added xfoo3 as a symlink. --Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER
> On Oct 10, 2016, at 09:42, Junio C Hamano wrote:
>
> Jeremy Huddleston Sequoia writes:
>
>> Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae
>
> Please be considerate to future readers of "git log" to help them
> avoid mistakes earlier commits made that caused you troubles.
>
> This line by itself without any explanation of what was broken is
> quite useless as a commit message. What can the readers do? They'd
> go back and say "git show 480871e09" and then what? The test added
> or modified by the commit has been working quite well for others
> since it was made, so it is very likely the reader wouldn't be able
> to tell if anything is wrong in it.
>
> You would help if you said what is different in _your_ environment
> from others who have happily been running and passing this test for
> others to understand and learn from your fix. What is it?
>
> The "Adjust ... distro changes" in the title offers some hint but it
> could be more explicit. Please write something along this line
> instead.
>
>Subject: t4014: git --version can have SP in it
>
>480871e09e ("format-patch: show base info before email
>signature", 2016-09-07) added a helper function to recreate the
>signature at the end of the e-mail, i.e. "-- " line followed by
>the version string of Git, using output from "git --version" and
>stripping everything before the last SP.
>
>Because the default Git version string looks like "git version
>2.10.0-1-g480871e09e", this was mostly OK, but people can change
>this version string to arbitrary thing while compiling, which
>can break the assumption if they had SP in it. Notably, Apple
>ships modified Git with " (Apple Git-xx)" appended to its
>version number.
>
>Instead, come up with the version string by stripping the "git
>version " from the beginning.
Ok, I'll add that explanation to the commit message, thanks.
>
>> Signed-off-by: Jeremy Huddleston Sequoia
>
> Good.
>
>> CC: Josh Triplett
>> CC: Junio C Hamano
>
> Please don't do this in your log message. These belong to your
> e-mail headers, not here.
Sorry, we do that consistently on other projects during the review process, so
git send-email picks them up and adds them automatically for each patch being
sent out. It's quite useful, actually.
>
>> ---
>> t/t4014-format-patch.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
>> index 8d90a6e..33f6940 100755
>> --- a/t/t4014-format-patch.sh
>> +++ b/t/t4014-format-patch.sh
>> @@ -754,7 +754,7 @@ test_expect_success 'format-patch
>> --ignore-if-in-upstream HEAD' '
>> git format-patch --ignore-if-in-upstream HEAD
>> '
>>
>> -git_version="$(git --version | sed "s/.* //")"
>> +git_version="$(git --version | sed "s/git version //")"
>
> Anchor the fixed prefix to the beginning, so that we can protect
> ourselves from another distro that would add "git version" in the
> middle of their arbitrary versioning scheme ;-). I.e.
>
>sed "s/^git version //"
Ok.
>
>>
>> signature() {
>> printf "%s\n%s\n\n" "-- " "${1:-$git_version}"
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER
> On Oct 10, 2016, at 06:10, Jeff King wrote: > > On Sun, Oct 09, 2016 at 07:53:23PM -0700, Jeremy Huddleston Sequoia wrote: > >> Subject: Re: [PATCH] t4014-format-patch: Adjust git_version regex to better >> handle distro changes to DEF_VER >> >> Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae >> Signed-off-by: Jeremy Huddleston Sequoia > > I see there was a discussion elsewhere on the list about exactly what > you are putting into DEF_VAR that causes the problem. Perhaps the commit > message here would be a good place to mention that, why the current > regex breaks it, and why your new version fixes not only it, but other > possible values of DEF_VAR. Thanks, I've added this blurb: For example, git distributed with Apple's Xcode reports a version like: git version 2.9.3 (Apple Git-75) Apple started doing this to help customers distinguish between different versions of their packaged git which have the same base version (eg: with different patches applied). smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER
> On Oct 9, 2016, at 20:04, Josh Triplett wrote:
>
> On October 9, 2016 7:53:23 PM PDT, Jeremy Huddleston Sequoia
> wrote:
>> Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae
>> Signed-off-by: Jeremy Huddleston Sequoia
>> CC: Josh Triplett
>> CC: Junio C Hamano
>
> Looks reasonable to me. Didn't realize git versions could have spaces.
> Reviewed-by: Josh Triplett
Thanks, Josh.
If anyone feels strongly that they shouldn't, I'd be happy to change our
DEF_VER patch to play nicer.
cf
https://github.com/jeremyhu/git/commit/f99905d0752d923e5ec61e14c675a300c6d04284
>
>> t/t4014-format-patch.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
>> index 8d90a6e..33f6940 100755
>> --- a/t/t4014-format-patch.sh
>> +++ b/t/t4014-format-patch.sh
>> @@ -754,7 +754,7 @@ test_expect_success 'format-patch
>> --ignore-if-in-upstream HEAD' '
>> git format-patch --ignore-if-in-upstream HEAD
>> '
>>
>> -git_version="$(git --version | sed "s/.* //")"
>> +git_version="$(git --version | sed "s/git version //")"
>>
>> signature() {
>> printf "%s\n%s\n\n" "-- " "${1:-$git_version}"
>
>
smime.p7s
Description: S/MIME cryptographic signature
[PATCH] t3700-add.sh: Avoid filename collission between tests which could lead to test failure
Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c Signed-off-by: Jeremy Huddleston Sequoia CC: Thomas Gummerer CC: Junio C Hamano --- t/t3700-add.sh | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/t/t3700-add.sh b/t/t3700-add.sh index 924a266..3ccb19b 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -354,11 +354,11 @@ test_expect_success 'git add --chmod=[+-]x changes index with already added file git add foo3 && git add --chmod=+x foo3 && test_mode_in_index 100755 foo3 && - echo foo >xfoo3 && - chmod 755 xfoo3 && - git add xfoo3 && - git add --chmod=-x xfoo3 && - test_mode_in_index 100644 xfoo3 + echo foo >xfoo4 && + chmod 755 xfoo4 && + git add xfoo4 && + git add --chmod=-x xfoo4 && + test_mode_in_index 100644 xfoo4 ' test_expect_success POSIXPERM 'git add --chmod=[+-]x does not change the working tree' ' -- 2.10.1
Re: git 2.10.1 test regression in t3700-add.sh
> On Oct 9, 2016, at 20:22, Jeremy Huddleston Sequoia > wrote: > > The issue is that the whitespace before the filename in $(git ls-files -s > "$2") is a tab, and test_mode_in_index only looks for a space. Actually, looks like that as just a rabbit hole. The real issue looks to be because an earlier test drops down xfoo3 as a symlink, which causes this test to fail due to the collision. I'll get out a patch in a bit. > >> < > >> On Oct 9, 2016, at 19:51, Jeremy Huddleston Sequoia >> wrote: >> >> >>> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia >>> wrote: >>> >>> Hi Thomas, >>> >>> I wanted to let you know that this patch of yours, which landed in git >>> 2.10.1, introduced some test failures, seen on macOS. >>> >>> Let me know if you need any additional information to track these down. >>> >>> Thanks, >>> Jeremy >>> >>> not ok 40 - git add --chmod=[+-]x changes index with already added file >>> # >>> # echo foo >foo3 && >>> # git add foo3 && >>> # git add --chmod=+x foo3 && >>> # test_mode_in_index 100755 foo3 && >>> # echo foo >xfoo3 && >>> # chmod 755 xfoo3 && >>> # git add xfoo3 && >>> # git add --chmod=-x xfoo3 && >>> # test_mode_in_index 100644 xfoo3 >>> # >>> >>> commit 610d55af0f082f6b866dc858e144c03d8ed4424c >>> Author: Thomas Gummerer >>> Date: Wed Sep 14 22:07:47 2016 +0100 >>> >>> add: modify already added files when --chmod is given >>> >>> When the chmod option was added to git add, it was hooked up to the diff >>> machinery, meaning that it only works when the version in the index >>> differs from the version on disk. >>> >>> As the option was supposed to mirror the chmod option in update-index, >>> which always changes the mode in the index, regardless of the status of >>> the file, make sure the option behaves the same way in git add. >>> >>> Signed-off-by: Thomas Gummerer >>> Signed-off-by: Junio C Hamano >> >> >> This failure looks odd. I'll dig into it a bit more as it looks like >> something odd is going on here... >> >> expecting success: >> echo foo >foo3 && >> git add foo3 && >> git add --chmod=+x foo3 && >> test_mode_in_index 100755 foo3 && >> echo foo >xfoo3 && >> chmod 755 xfoo3 && >> git add xfoo3 && >> git add --chmod=-x xfoo3 && >> test_mode_in_index 100644 xfoo3 >> >> pass >> cannot chmod 'xfoo3'fail >> 12 c5c4ca97a3a080c32920941b665e94a997901491 0xfoo3 >> not ok 40 - git add --chmod=[+-]x changes index with already added file >> # >> #echo foo >foo3 && >> #git add foo3 && >> #git add --chmod=+x foo3 && >> #test_mode_in_index 100755 foo3 && >> #echo foo >xfoo3 && >> #chmod 755 xfoo3 && >> #git add xfoo3 && >> #git add --chmod=-x xfoo3 && >> #test_mode_in_index 100644 xfoo3 >> # >> > smime.p7s Description: S/MIME cryptographic signature
Re: git 2.10.1 test regression in t3700-add.sh
The issue is that the whitespace before the filename in $(git ls-files -s "$2") is a tab, and test_mode_in_index only looks for a space. >< > On Oct 9, 2016, at 19:51, Jeremy Huddleston Sequoia > wrote: > > >> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia >> wrote: >> >> Hi Thomas, >> >> I wanted to let you know that this patch of yours, which landed in git >> 2.10.1, introduced some test failures, seen on macOS. >> >> Let me know if you need any additional information to track these down. >> >> Thanks, >> Jeremy >> >> not ok 40 - git add --chmod=[+-]x changes index with already added file >> # >> #echo foo >foo3 && >> #git add foo3 && >> #git add --chmod=+x foo3 && >> #test_mode_in_index 100755 foo3 && >> #echo foo >xfoo3 && >> #chmod 755 xfoo3 && >> #git add xfoo3 && >> #git add --chmod=-x xfoo3 && >> #test_mode_in_index 100644 xfoo3 >> # >> >> commit 610d55af0f082f6b866dc858e144c03d8ed4424c >> Author: Thomas Gummerer >> Date: Wed Sep 14 22:07:47 2016 +0100 >> >> add: modify already added files when --chmod is given >> >> When the chmod option was added to git add, it was hooked up to the diff >> machinery, meaning that it only works when the version in the index >> differs from the version on disk. >> >> As the option was supposed to mirror the chmod option in update-index, >> which always changes the mode in the index, regardless of the status of >> the file, make sure the option behaves the same way in git add. >> >> Signed-off-by: Thomas Gummerer >> Signed-off-by: Junio C Hamano > > > This failure looks odd. I'll dig into it a bit more as it looks like > something odd is going on here... > > expecting success: > echo foo >foo3 && > git add foo3 && > git add --chmod=+x foo3 && > test_mode_in_index 100755 foo3 && > echo foo >xfoo3 && > chmod 755 xfoo3 && > git add xfoo3 && > git add --chmod=-x xfoo3 && > test_mode_in_index 100644 xfoo3 > > pass > cannot chmod 'xfoo3'fail > 12 c5c4ca97a3a080c32920941b665e94a997901491 0 xfoo3 > not ok 40 - git add --chmod=[+-]x changes index with already added file > # > # echo foo >foo3 && > # git add foo3 && > # git add --chmod=+x foo3 && > # test_mode_in_index 100755 foo3 && > # echo foo >xfoo3 && > # chmod 755 xfoo3 && > # git add xfoo3 && > # git add --chmod=-x xfoo3 && > # test_mode_in_index 100644 xfoo3 > # > smime.p7s Description: S/MIME cryptographic signature
[PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER
Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae
Signed-off-by: Jeremy Huddleston Sequoia
CC: Josh Triplett
CC: Junio C Hamano
---
t/t4014-format-patch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 8d90a6e..33f6940 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -754,7 +754,7 @@ test_expect_success 'format-patch --ignore-if-in-upstream
HEAD' '
git format-patch --ignore-if-in-upstream HEAD
'
-git_version="$(git --version | sed "s/.* //")"
+git_version="$(git --version | sed "s/git version //")"
signature() {
printf "%s\n%s\n\n" "-- " "${1:-$git_version}"
--
2.10.1 (Apple Git-99)
Re: git 2.10.1 test regression in t4014-format-patch.sh
> On Oct 9, 2016, at 17:18, Josh Triplett wrote:
>
> On October 9, 2016 5:15:22 PM PDT, Jeremy Huddleston Sequoia
> wrote:
>> Hey Josh,
>>
>> Hope you're doing well.
>>
>> I wanted to let you know that this patch of yours, which landed in git
>> 2.10.1, introduced some test failures, seen on macOS.
>>
>> Let me know if you need any additional information to track these down.
>>
>> Thanks,
>> Jeremy
>>
>>
>> not ok 65 - format-patch default signature
>> #
>> #git format-patch --stdout -1 | tail -n 3 >output &&
>> #signature >expect &&
>> #test_cmp expect output
>> #
>>
>> not ok 132 - format-patch --base
>> #
>> #git checkout side &&
>> #git format-patch --stdout --base=HEAD~3 -1 | tail -n 7 >actual
>> &&
>> #echo >expected &&
>> #echo "base-commit: $(git rev-parse HEAD~3)" >>expected &&
>> #echo "prerequisite-patch-id: $(git show --patch HEAD~2 | git
>> patch-id --stable | awk "{print \$1}")" >>expected &&
>> #echo "prerequisite-patch-id: $(git show --patch HEAD~1 | git
>> patch-id --stable | awk "{print \$1}")" >>expected &&
>> #signature >> expected &&
>> #test_cmp expected actual
>> #
>
> Can you run the test with the option to show the expected and actual strings?
> Did the testsuite run with the wrong git somehow?
Nope, it's the right version being tested. The failure seems due to your
git_version change not liking our formatting
$ git --version
git version 2.10.1 (Apple Git-99)
(the 'Apple Git-XX' being added because this was from a build that had Apple's
patch series, including
https://github.com/jeremyhu/git/commit/f99905d0752d923e5ec61e14c675a300c6d04284)
We modify DEF_VER, which confused your regex. Simple patch inc in a separate
email.
Thanks,
Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: git 2.10.1 test regression in t3700-add.sh
> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia > wrote: > > Hi Thomas, > > I wanted to let you know that this patch of yours, which landed in git > 2.10.1, introduced some test failures, seen on macOS. > > Let me know if you need any additional information to track these down. > > Thanks, > Jeremy > > not ok 40 - git add --chmod=[+-]x changes index with already added file > # > # echo foo >foo3 && > # git add foo3 && > # git add --chmod=+x foo3 && > # test_mode_in_index 100755 foo3 && > # echo foo >xfoo3 && > # chmod 755 xfoo3 && > # git add xfoo3 && > # git add --chmod=-x xfoo3 && > # test_mode_in_index 100644 xfoo3 > # > > commit 610d55af0f082f6b866dc858e144c03d8ed4424c > Author: Thomas Gummerer > Date: Wed Sep 14 22:07:47 2016 +0100 > >add: modify already added files when --chmod is given > >When the chmod option was added to git add, it was hooked up to the diff >machinery, meaning that it only works when the version in the index >differs from the version on disk. > >As the option was supposed to mirror the chmod option in update-index, >which always changes the mode in the index, regardless of the status of >the file, make sure the option behaves the same way in git add. > >Signed-off-by: Thomas Gummerer >Signed-off-by: Junio C Hamano This failure looks odd. I'll dig into it a bit more as it looks like something odd is going on here... expecting success: echo foo >foo3 && git add foo3 && git add --chmod=+x foo3 && test_mode_in_index 100755 foo3 && echo foo >xfoo3 && chmod 755 xfoo3 && git add xfoo3 && git add --chmod=-x xfoo3 && test_mode_in_index 100644 xfoo3 pass cannot chmod 'xfoo3'fail 12 c5c4ca97a3a080c32920941b665e94a997901491 0 xfoo3 not ok 40 - git add --chmod=[+-]x changes index with already added file # # echo foo >foo3 && # git add foo3 && # git add --chmod=+x foo3 && # test_mode_in_index 100755 foo3 && # echo foo >xfoo3 && # chmod 755 xfoo3 && # git add xfoo3 && # git add --chmod=-x xfoo3 && # test_mode_in_index 100644 xfoo3 # smime.p7s Description: S/MIME cryptographic signature
git 2.10.1 test regression in t3700-add.sh
Hi Thomas, I wanted to let you know that this patch of yours, which landed in git 2.10.1, introduced some test failures, seen on macOS. Let me know if you need any additional information to track these down. Thanks, Jeremy not ok 40 - git add --chmod=[+-]x changes index with already added file # # echo foo >foo3 && # git add foo3 && # git add --chmod=+x foo3 && # test_mode_in_index 100755 foo3 && # echo foo >xfoo3 && # chmod 755 xfoo3 && # git add xfoo3 && # git add --chmod=-x xfoo3 && # test_mode_in_index 100644 xfoo3 # commit 610d55af0f082f6b866dc858e144c03d8ed4424c Author: Thomas Gummerer Date: Wed Sep 14 22:07:47 2016 +0100 add: modify already added files when --chmod is given When the chmod option was added to git add, it was hooked up to the diff machinery, meaning that it only works when the version in the index differs from the version on disk. As the option was supposed to mirror the chmod option in update-index, which always changes the mode in the index, regardless of the status of the file, make sure the option behaves the same way in git add. Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano smime.p7s Description: S/MIME cryptographic signature
git 2.10.1 test regression in t4014-format-patch.sh
Hey Josh,
Hope you're doing well.
I wanted to let you know that this patch of yours, which landed in git 2.10.1,
introduced some test failures, seen on macOS.
Let me know if you need any additional information to track these down.
Thanks,
Jeremy
not ok 65 - format-patch default signature
#
# git format-patch --stdout -1 | tail -n 3 >output &&
# signature >expect &&
# test_cmp expect output
#
not ok 132 - format-patch --base
#
# git checkout side &&
# git format-patch --stdout --base=HEAD~3 -1 | tail -n 7 >actual
&&
# echo >expected &&
# echo "base-commit: $(git rev-parse HEAD~3)" >>expected &&
# echo "prerequisite-patch-id: $(git show --patch HEAD~2 | git
patch-id --stable | awk "{print \$1}")" >>expected &&
# echo "prerequisite-patch-id: $(git show --patch HEAD~1 | git
patch-id --stable | awk "{print \$1}")" >>expected &&
# signature >> expected &&
# test_cmp expected actual
#
commit 480871e09ed2e5275b4ba16b278681e5a8c122ae
Author: Josh Triplett
Date: Wed Sep 7 18:12:01 2016 -0700
format-patch: show base info before email signature
Any text below the "-- " for the email signature gets treated as part of
the signature, and many mail clients will trim it from the quoted text
for a reply. Move it above the signature, so people can reply to it
more easily.
Similarly, when producing the patch as a MIME attachment, the
original code placed the base info after the attached part, which
would be discarded. Move the base info to the end of the part,
still inside the part boundary.
Add tests for the exact format of the email signature, and add tests
to ensure that the base info appears before the email signature when
producing a plain-text output, and that it appears before the part
boundary when producing a MIME attachment.
Signed-off-by: Josh Triplett
Signed-off-by: Junio C Hamano
smime.p7s
Description: S/MIME cryptographic signature
Reference a submodule branch instead of a commit
At the moment, supermodules must reference a given commit in each of its submodules. If one is in control of a submodule and it changes on a regular basis, this can cause a lot of overhead with "submodule updated" commits in the supermodule. It would be useful of git allows the option of referencing a submodule's branch instead of a given submodule commit. How about adding this functionality? -- Best regards, Jeremy Morton (Jez)
Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Did this ever get anywhere? Can we recursively update submodules with
"git pull" in the supermodule now?
--
Best regards,
Jeremy Morton (Jez)
On 04/06/2014 10:30, Chris Packham wrote:
Add a config option that will cause clone to recurse into submodules as
if the --recurse-submodules option had been specified on the command
line. This can be overridden with the --no-recurse-submodules option.
Signed-off-by: Chris Packham
---
On 04/06/14 09:05, Junio C Hamano wrote:
Mara Kim writes:
Apologies if this question has been asked already, but what is the
reasoning behind making git clone not recursive (--recursive) by
default?
The primary reason why submodules are separate repositories is not
to require people to have everything. Some people want recursive,
some others don't, and the world is not always "majority wins" (not
that I am saying that majority will want recursive).
Inertia, aka backward compatibility and not surprising existing
users, plays some role when deciding the default.
Also, going --recursive when the user did not want is a lot more
expensive mistake to fix than not being --recursive when the user
wanted to.
Having said all that, I do not mean to say that I am opposed to
introduce some mechanism to let the users express their preference
between recursive and non-recursive better, so that "git clone"
without an explicit --recursive (or --no-recursive) can work to
their taste. A configuration in $HOME/.gitconfig might be a place
to start, even though that has the downside of assuming that the
given user would want to use the same settings for all his projects,
which may not be the case in practice.
And here's a quick proof of concept. Not sure about the config variable name
and it could probably do with a negative test as well.
builtin/clone.c | 9 +
t/t7407-submodule-foreach.sh | 17 +
2 files changed, 26 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index b12989d..92aea81 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -734,6 +734,14 @@ static void write_refspec_config(const char*
src_ref_prefix,
strbuf_release(&value);
}
+static int git_clone_config(const char *key, const char *value, void *data)
+{
+ if (!strcmp(key, "clone.recursesubmodules"))
+ option_recursive = git_config_bool(key, value);
+
+ return 0;
+}
+
int cmd_clone(int argc, const char **argv, const char *prefix)
{
int is_bundle = 0, is_local;
@@ -759,6 +767,7 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
junk_pid = getpid();
packet_trace_identity("clone");
+ git_config(git_clone_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_clone_options,
builtin_clone_usage, 0);
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 7ca10b8..fc2c189 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -307,6 +307,23 @@ test_expect_success 'use "update --recursive nested1" to
checkout all submodules
)
'
+test_expect_success 'use "git clone" with clone.recursesubmodules to checkout
all submodules' '
+ git config --local clone.recursesubmodules true&&
+ git clone super clone7&&
+ (
+ cd clone7&&
+ git rev-parse --resolve-git-dir .git&&
+ git rev-parse --resolve-git-dir sub1/.git&&
+ git rev-parse --resolve-git-dir sub2/.git&&
+ git rev-parse --resolve-git-dir sub3/.git&&
+ git rev-parse --resolve-git-dir nested1/.git&&
+ git rev-parse --resolve-git-dir nested1/nested2/.git&&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/.git&&
+ git rev-parse --resolve-git-dir
nested1/nested2/nested3/submodule/.git
+ )&&
+ git config --local --unset clone.recursesubmodules
+'
+
test_expect_success 'command passed to foreach retains notion of stdin' '
(
cd super&&
Autoupdate / autoinit submodules?
Apologies if this has already been discussed, but did any of the proposed patches to allow .gitmodules to be configured for a submodule to be automatically recursive cloned and/or automatically updated on pull make it in yet? My use-case for submodules - which is shared libraries - almost always requires a recursive clone, so having to remember the --recursive param (or to use an alias) is annoying (and I usually forget), and it usually requires pulling the latest master on a "git pull", too. I think both of these things should be able to be automated through git module configuration. -- Best regards, Jeremy Morton (Jez)
Re: 2.9.2 test failures on macOS
> On Aug 3, 2016, at 07:35, Johannes Schindelin
> wrote:
>
> Hi Jeremy,
>
> On Wed, 3 Aug 2016, Jeremy Huddleston Sequoia wrote:
>
>> I have two test failures to report in git 2.9.2 on macOS:
>>
>>
>> t3210-pack-refs.sh has not changed between 2.8.4 and 2.9.2. This test
>> passed fine with 2.8.4, but it now fails with 2.9.2 at:
>>
>> not ok 26 - retry acquiring packed-refs.lock
>> #
>> #LOCK=.git/packed-refs.lock &&
>> #>"$LOCK" &&
>> #test_when_finished "wait; rm -f $LOCK" &&
>> #{
>> #( sleep 1 ; rm -f $LOCK ) &
>> #} &&
>> #git -c core.packedrefstimeout=3000 pack-refs --all --prune
>> #
>>
>> ===
>>
>> t3700-add.sh recently added the 'git add --chmod=-x stages an executable
>> file with -x' test. This test passes when run as a normal user but fails
>> when run as root:
>>
>> $ ./t3700-add.sh
>> ...
>> # passed all 40 test(s)
>> 1..40
>>
>> $ sudo ./t3700-add.sh
>> ...
>> not ok 39 - git add --chmod=-x stages an executable file with -x
>> #
>> #echo foo >xfoo1 &&
>> #chmod 755 xfoo1 &&
>> #git add --chmod=-x xfoo1 &&
>> #case "$(git ls-files --stage xfoo1)" in
>> #100644" "*xfoo1) echo pass;;
>> #*) echo fail; git ls-files --stage xfoo1; (exit 1);;
>> #esac
>> #
>> # failed 1 among 40 test(s)
>> 1..40
>
> I tried to write up all I know about debugging test failures here:
>
> https://github.com/git-for-windows/git/wiki/Running-Git's-regression-tests#running-individual-tests
>
> Could you give it a try and diagnose the breakage further? (The output you
> provided is unfortunately not enough to determine what went wrong.)
Another report indicates that the second was a known failure already. As for
the first one:
~/tmp/test $ git init
Initialized empty Git repository in /Users/jeremy/tmp/test/.git/
~/tmp/test (master) $ touch .git/packed-refs.lock
~/tmp/test (master) $ git -c core.packedrefstimeout=3000 pack-refs --all --prune
fatal: Unable to create '/Users/jeremy/tmp/test/.git/packed-refs.lock': File
exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
--
I just tried this again with 2.8.4, and I see the same failure. I could've
sworn that 2.8.4 passed all tests when I tested it back in June.
smime.p7s
Description: S/MIME cryptographic signature
2.9.2 test failures on macOS
I have two test failures to report in git 2.9.2 on macOS:
t3210-pack-refs.sh has not changed between 2.8.4 and 2.9.2. This test passed
fine with 2.8.4, but it now fails with 2.9.2 at:
not ok 26 - retry acquiring packed-refs.lock
#
# LOCK=.git/packed-refs.lock &&
# >"$LOCK" &&
# test_when_finished "wait; rm -f $LOCK" &&
# {
# ( sleep 1 ; rm -f $LOCK ) &
# } &&
# git -c core.packedrefstimeout=3000 pack-refs --all --prune
#
===
t3700-add.sh recently added the 'git add --chmod=-x stages an executable file
with -x' test. This test passes when run as a normal user but fails when run
as root:
$ ./t3700-add.sh
...
# passed all 40 test(s)
1..40
$ sudo ./t3700-add.sh
...
not ok 39 - git add --chmod=-x stages an executable file with -x
#
# echo foo >xfoo1 &&
# chmod 755 xfoo1 &&
# git add --chmod=-x xfoo1 &&
# case "$(git ls-files --stage xfoo1)" in
# 100644" "*xfoo1) echo pass;;
# *) echo fail; git ls-files --stage xfoo1; (exit 1);;
# esac
#
# failed 1 among 40 test(s)
1..40
smime.p7s
Description: S/MIME cryptographic signature
Re: Allow git alias to override existing Git commands
On 11/11/2015 09:51, Sitaram Chamarty wrote: I can only repeat what I said before: it's not all black and white. Reducing the opportunity to make mistakes is useful for everyone, even expetrs. Especially stuff that you may have setup aeons ago and hits you only aeons later when something (supposedly unrelated) somewhere else changes and you didn't remember and you tear your hair out. Not when it reduces useful functionality for experts, it's not. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Allow git alias to override existing Git commands
On 11/11/2015 04:48, Sitaram Chamarty wrote: A lot of things in Unix do follow that "give you rope to hang yourself" philosophy. I used to (and to *some* extent still do) think like that, but some years of supporting normal users trying to do stuff has taught me it's not always that simple. I can easily see someone blogging some cool way to do something, and a less savvy user uses that in his gitconfig, and gets burned later (possibly much later, enough that he does not easily make the connection!) We're not talking about "normal users" here, that's what Google Chrome is for. We're talking about Git users using the commandline client. They ought to know what they're doing and if they don't, they're screwed anyway because there are quite a few gotchas with Git. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Allow git alias to override existing Git commands
On 10/11/2015 18:12, Stefan Beller wrote: On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton wrote: It's recently come to my attention that the "git alias" config functionality ignores all aliases that would override existing Git commands. This seems like a bad idea to me. This ensures that the plumbing commands always work as expected. As scripts *should* only use plumbing commands, the scripts should work with high probability despite all the crazy user configuration/aliases. I just disagree with this. If a user chooses to override their Git commands, it's their problem. Why should Git care about this? It should provide the user with the option to do this, and if the user ruins scripts because of their aliases, it is not Git's problem. What you are doing is taking away power from users to use git aliases to their full potential. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Allow git alias to override existing Git commands
It's recently come to my attention that the "git alias" config functionality ignores all aliases that would override existing Git commands. This seems like a bad idea to me. For example, I wanted to setup "git clone" to automatically act as "git clone --recursive". Sure I could do it in the shell, but it's more of a pain - any tutorial I set up about doing it would have to worry about what shell the user was using - and if you're going to make that argument, why have "git alias" at all? It can all be done from the shell. Obviously I could also use a different alias that wasn't an existing Git command for this behaviour, but that would rather defeat the point: I want "git clone" to have different functionality. If I remembered to use a different Git command, I might as well remember to type "git clone --recursive". Also, if a future Git command were introduced with the same name as my alias, my alias's functionality would suddenly be ignored, giving unexpected behaviour. The reasoning behind this that it's "to avoid confusion and troubles with script usage" seems to be at odds with the general Git mentality that the user is given lots of power, and if they screw it up it's basically just user error. For example, Git doesn't *have* to allow you to rebase. It's a potentially dangerous operation, so why is it allowed? It might "cause confusion and troubles". On the other hand, by disallowing the overriding of existing Git commands through aliases you are preventing a lot of useful functionality that those aliases might be used for. So I think you should either allow Git aliases to override existing Git commands by default, or at least provide a config option that allows the user to say that this should happen. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Running interpret-trailers automatically on each commit?
Yeah but it's kind of useless to me having it on each commit on a per-repo basis (and even then, only with hooks). -- Best regards, Jeremy Morton (Jez) On 28/08/2015 18:06, Junio C Hamano wrote: Jeremy Morton writes: I see that interpret-trailers has been added by default in git 2.5.0. However the documentation isn't that great and I can't tell whether it gets run automatically when I do a "git commit". My guess is that it doesn't - that you have to set up a hook to get it to run each commit. All correct, except that it happend in 2.2 timeframe. A new experimental feature is shipped, so that people can gain experience with it and come up with the best practice in their hooks, and then laster we may fold the best practice into somewhere deeper in the system. We are still in the early "ship an experimental feature to let people play with it" stage. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Running interpret-trailers automatically on each commit?
I see that interpret-trailers has been added by default in git 2.5.0. However the documentation isn't that great and I can't tell whether it gets run automatically when I do a "git commit". My guess is that it doesn't - that you have to set up a hook to get it to run each commit. As far as I can tell, there is no way to configure global git hooks. Sure, you can set init.templatedir but that only applies for newly-init'ed or cloned repos. So if I have 50 repos on my hard drive I still have to go through every one of them and set up a hook for it. Basically, am I right in thinking that there is *still* no way for me to configure git (on a global, not per-repo basis) to automatically tack a trailer onto every commit message? For the record, I want that trailer to be the current branch name. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
utf-8 filename woes
Hi, I have a git version 1.7.1 running on Scientific Linux 6. When a filename with UTF-8 is present in a tree-ish the "git archive" command crashes: %% *** buffer overflow detected ***: git terminated === Backtrace: = /lib64/libc.so.6(__fortify_fail+0x37)[0x32c1502527] /lib64/libc.so.6[0x32c1500410] /lib64/libc.so.6[0x32c14ff869] /lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x32c1474639] /lib64/libc.so.6(_IO_vfprintf+0x11d8)[0x32c14451a8] /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x32c14ff90d] /lib64/libc.so.6(__sprintf_chk+0x7f)[0x32c14ff84f] git[0x4620bc] git[0x4616bc] git[0x4bd832] git[0x4bda79] git[0x4bda79] git[0x4613e1] git[0x4623ed] git[0x4612ed] git[0x40caf3] git[0x4041a1] git[0x404382] /lib64/libc.so.6(__libc_start_main+0xfd)[0x32c141ed5d] git[0x403ba9] === Memory map: 0040-0051 r-xp fd:00 4121 /usr/bin/git %% Installing the git-debuginfo package gave no additional information. The symptom does not show on a Fedora 21 system with git 2.1.0 (and I note that gitk properly shows those filenames on f21, and does not on sl6). Is this a known and fixed issue, or something my sl6 system needs installing? -- Thanks, Jeremy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Importing from RTC to GIT
We are currently investigating whether to move from RTC (source control) to GIT and wanted to find out if there is more information available than what we have found in http://stackoverflow.com/questions/23928927/how-to-migrate-from-rtc-jazz-to-git We really need to preserve the version history of all artifacts and wanted to see if there is an import utility available to do this. If not, we can go through and import off of our milestone baselines in separate workspaces but this can be fairly time consuming for us to grab all needed baselines that we will want to preserve. We are not planning on archiving RTC so getting the history out for all versioned artifacts is extremely important. Thanks, Jeremy Davis ALM Architect Idaho State Insurance Fund Phone: 208-332-2586 Cell Phone: 970-215-2945 Email: jda...@idahosif.org Website: www.idahosif.org -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Branch list by date
I built this terribly-written alias because I wanted to see a list of branches by date of commit. The output looks like this: $ git bbd 11 months ago pipette_editor 7 weeks ago ensure-ie-rendering-edge 6 weeks ago strings-yml 5 weeks ago message-when-validation-fails 4 weeks ago new-parsers 11 days ago tax 8 hours ago search 7 hours ago browse 16 minutes ago master 8 seconds ago org-read And the alias, in all its glory: [alias] bbd = "!export head=$(git symbolic-ref HEAD); git for-each-ref --sort=committerdate --format 'color=$(if [[ %(refname) = $head ]]; then printf \"\\e[32m\"; fi); printf \"\\e[01;30m%%15s\\e(B\\e[m %%s%%s\\n\" %(committerdate:relative) $color %(refname:short)' refs/heads/ --shell | sh" I write this missive with dual purpose: firstly to share a potentially useful tool, and secondly to suggest that this feature (with a less mind-wrenchingly disgusting implementation) might be included in mainline git, as for example `git branch [-t] | [--by-time]`. Until the ocean swallows us all, j -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: files deleted with no record?
we're all using source tree. I'm really interested to try and
reproduce this so I'll find some time today to do it.
Thanks again
On Fri, Jun 27, 2014 at 6:56 AM, Jeremy Scott wrote:
> Hi. Thanks for getting back to me.
>
> here is a screenshot from source tree to visualise the scenario:
>
> https://drive.google.com/file/d/0B-Wn7DfHsuhyTEVkRHAzeGVZelpMWjFxZW1kbVBKVlNab3pR/edit?usp=sharing
>
> I will attempt a script to reproduce this later today.
>
> Thanks
>
>
>
>
>
>
>
>
>
> On Fri, Jun 27, 2014 at 5:53 AM, Philip Oakley wrote:
>>
>> From: "Phil Hord"
>>
>>> On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott
>>> wrote:
>>>>
>>>> I just encountered a situation where a merge was made, with no
>>>> apparent changes in files (ie no log), but the result was that some
>>>> files were deleted.
>>>>
>>>> person A adds some files
>>>> person B adds some files from the same point
>>>
>>>
>>> You mean from the same point in history, right? Not files with the
>>> same filename or path?
>>>
>>>> person B commits and pushes.
>>>> person A commits -- now merge is required
>>>> a few more commits on top of person B's commit
>>>
>>>
>>> I don't understand this step. Who adds a few more commits on top of B
>>> and why?
>>>
>>>> person A merges - this removes the files that B added. There is no log
>>>> of the files being deleted
>>
>>
>> A similar issue, by reference, just came up on the [git-users] list. The
>> reference was:
>> 1. http://randyfay.com/content/avoiding-git-disasters-gory-story
>>
>> In that case the problem was a mixture of tools and misunderstandings.
>>
>> It may not be the same as your case, but could give insights into what's
>> happening between different developers.
>>
>> Which Tools are You, person A and Person B using, with --version?
>>
>>>
>>> This sounds like an "evil merge" (see man gitglossary, and google),
>>> but it's not clear to me how you arrived here.
>>>
>>> When I tried to reproduce your issue with this script, it did not
>>> remove any files unexpectedly:
>>> --->8---
>>> #!/bin/sh
>>>
>>> set -e
>>> mkdir foo && cd foo && git init
>>> echo foo > foo && git add foo && git commit -mfoo
>>>
>>> git checkout -b PersonA master
>>> echo bar > bar && git add bar
>>> git commit -m"PersonA: bar"
>>>
>>> git checkout -b PersonB master
>>> echo baz > baz && git add baz
>>> git commit -m"PersonB: baz"
>>>
>>> echo foo-conflict >> foo && git add foo
>>> git commit -m"PersonB: foo"
>>>
>>> git checkout PersonA
>>> echo foo-different >> foo && git add foo
>>> git commit -m"PersonA: foo (conflicts with PersonB)"
>>>
>>> git log --oneline --all --stat
>>>
>>> if ! git merge PersonB ; then
>>> git checkout PersonA foo
>>> git commit --no-edit
>>> fi
>>> git log --oneline --graph --stat
>>> --->8---
>>>
>>> A sneaky issue with merges is that they do not have a clear way to
>>> show patch information -- the diff between the commit and its ancestor
>>> -- because they have multiple ancestors. You can show diffs for a
>>> merge relative to each of its parents, but it is not usually done for
>>> you automatically. This is why making changes in a merge which are
>>> not actually required for the merge is bad ("evil").
>>>
>>>> Clearly this is possible - was this a user error?
>>>
>>>
>>> Probably, but we'd need to see how the user got there.
>>> --
>>
>> Philip
>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: files deleted with no record?
Hi. Thanks for getting back to me.
here is a screenshot from source tree to visualise the scenario:
https://drive.google.com/file/d/0B-Wn7DfHsuhyTEVkRHAzeGVZelpMWjFxZW1kbVBKVlNab3pR/edit?usp=sharing
I will attempt a script to reproduce this later today.
Thanks
On Fri, Jun 27, 2014 at 5:53 AM, Philip Oakley wrote:
> From: "Phil Hord"
>
>> On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott
>> wrote:
>>>
>>> I just encountered a situation where a merge was made, with no
>>> apparent changes in files (ie no log), but the result was that some
>>> files were deleted.
>>>
>>> person A adds some files
>>> person B adds some files from the same point
>>
>>
>> You mean from the same point in history, right? Not files with the
>> same filename or path?
>>
>>> person B commits and pushes.
>>> person A commits -- now merge is required
>>> a few more commits on top of person B's commit
>>
>>
>> I don't understand this step. Who adds a few more commits on top of B and
>> why?
>>
>>> person A merges - this removes the files that B added. There is no log
>>> of the files being deleted
>
>
> A similar issue, by reference, just came up on the [git-users] list. The
> reference was:
> 1. http://randyfay.com/content/avoiding-git-disasters-gory-story
>
> In that case the problem was a mixture of tools and misunderstandings.
>
> It may not be the same as your case, but could give insights into what's
> happening between different developers.
>
> Which Tools are You, person A and Person B using, with --version?
>
>>
>> This sounds like an "evil merge" (see man gitglossary, and google),
>> but it's not clear to me how you arrived here.
>>
>> When I tried to reproduce your issue with this script, it did not
>> remove any files unexpectedly:
>> --->8---
>> #!/bin/sh
>>
>> set -e
>> mkdir foo && cd foo && git init
>> echo foo > foo && git add foo && git commit -mfoo
>>
>> git checkout -b PersonA master
>> echo bar > bar && git add bar
>> git commit -m"PersonA: bar"
>>
>> git checkout -b PersonB master
>> echo baz > baz && git add baz
>> git commit -m"PersonB: baz"
>>
>> echo foo-conflict >> foo && git add foo
>> git commit -m"PersonB: foo"
>>
>> git checkout PersonA
>> echo foo-different >> foo && git add foo
>> git commit -m"PersonA: foo (conflicts with PersonB)"
>>
>> git log --oneline --all --stat
>>
>> if ! git merge PersonB ; then
>> git checkout PersonA foo
>> git commit --no-edit
>> fi
>> git log --oneline --graph --stat
>> --->8---
>>
>> A sneaky issue with merges is that they do not have a clear way to
>> show patch information -- the diff between the commit and its ancestor
>> -- because they have multiple ancestors. You can show diffs for a
>> merge relative to each of its parents, but it is not usually done for
>> you automatically. This is why making changes in a merge which are
>> not actually required for the merge is bad ("evil").
>>
>>> Clearly this is possible - was this a user error?
>>
>>
>> Probably, but we'd need to see how the user got there.
>> --
>
> Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
files deleted with no record?
I just encountered a situation where a merge was made, with no apparent changes in files (ie no log), but the result was that some files were deleted. person A adds some files person B adds some files from the same point person B commits and pushes. person A commits -- now merge is required a few more commits on top of person B's commit person A merges - this removes the files that B added. There is no log of the files being deleted Clearly this is possible - was this a user error? Thanks -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk's truncated tags
On 27/05/14 13:12, Ondrej Oprala wrote: Hi, is there any way to display full tag names in gitk, for tag names longer than 16 characters? The way 1.8.x did things? The offending commit is 4399fe3 and reverting it restores my preferred view, too (there was slight entanglement with 76d64ca which I ignored). -- Cheers, Jeremy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 29/04/2014 12:47, Christian Couder wrote: Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) You may need to write a small script for that. Then you just need the "trailer.m-o-b.command" config value to point to your script. ... or whatever. And also how about some logic to be able to say that if you're committing to the "master" branch, the trailer doesn't get inserted at all? You can script that too. But it would be nicer if the logic were built-in, then you wouldn't have to share some script with your work colleagues. :-) -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 29/04/2014 12:47, Christian Couder wrote: Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) You may need to write a small script for that. Then you just need the "trailer.m-o-b.command" config value to point to your script. ... or whatever. And also how about some logic to be able to say that if you're committing to the "master" branch, the trailer doesn't get inserted at all? You can script that too. But it would be nicer if the logic were built-in, then you wouldn't have to share some script with your work colleagues. :-) -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 28/04/2014 17:37, Junio C Hamano wrote: Christian Couder writes: From: Junio C Hamano Christian Couder writes: ... + trailer. After some alphanumeric characters, it can contain + some non alphanumeric characters like ':', '=' or '#' that will + be used instead of ':' to separate the token from the value in + the trailer, though the default ':' is more standard. I assume that this is for things like bug #538 and the configuration would say something like: [trailer "bug"] key = "bug #" For completeness (of this example), the bog-standard s-o-b would look like Signed-off-by: Christian Couder and the configuration for it that spell the redundant "key" would be: [trailer "Signed-off-by"] key = "Signed-off-by: " Yeah, but you can use the following instead: [trailer "s-o-b"] key = "Signed-off-by: " One thing I'm not quite understanding is where the "Christian Couder" bit comes from. So you've defined the trailer token and key, but interpret-trailers then needs to get the value it will give for the key from somewhere. Does it have to just be hardcoded in? We probably want some way to get various variables like current branch name, current git version, etc. So in the case of always adding a trailer for the branch that the commit was checked in to at the time (Developed-on, Made-on-branch, Author-branch, etc. [I think my favourite is Made-on-branch]), you'd want something like: [trailer "m-o-b"] key = "Made-on-branch: " value = "$currentBranch" ... resulting in the trailer (for example): Made-on-branch: pacman-minigame Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) ... or whatever. And also how about some logic to be able to say that if you're committing to the "master" branch, the trailer doesn't get inserted at all? -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:17, Felipe Contreras wrote: I don't seem to what? I'm the one arguing for change, and I sent the patches to fix this default behavior. Well maybe you should work on phrasing things better - you come across as quite negative. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:01, Felipe Contreras wrote: Jeremy Morton wrote: On 27/04/2014 20:33, Johan Herland wrote: The problem is not really "less tidy commit trees" - by which I gather you mean history graphs that are non-linear. IMHO, the history graph should reflect parallel/branched development when that is useful. Blindly rebasing everything into a single line is IMHO just as bad as doing all your work directly on master and blindly running "git pull" between each of your own commits (which results in a lot of useless merges). The merge commits themselves are not the problem. Merge commits are a tool, and when used properly (to introduce topics to the master branch like described above) they are a good tool. When abused (like blindly running "git pull" and accepting useless "merge bubbles") they create more problems than they solve. Sounds like the default behaviour of "git pull" might not be ideal if it easily causes these problems. It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we have the patches to fix it, but it's not going to change. The Git project doesn't welcome change. Well, you sure don't seem to. Why are there so many "no-can-do" people on this list? :-) -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:09, Johan Herland wrote: On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton wrote: On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat>.git/hooks/commit-msg< "\$1.new" mv "\$1.new" "\$1" EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer "git-branch: \$(git name-rev --name-only HEAD)" "\$1"> "\$1.new" It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv "\$1.new" "\$1"' command. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. It's a hack, but it works surprisingly well in practice (assuming that you and your co-workers all agree that this is an acceptable approach): 1. Write the hook script and add it to your project (in a git-hooks subdir or something) 2. Add a post-checkout hook to install the first hook and the post-checkout hook itself into the user's .git/hooks/ dir. 3. Tell your co-workers to run the post-checkout hook script manually the first time. After that, the script should take care of updating itself and any hooks that you add to the project. ...Johan I don't understand why the co-workers need to run the post-checkout hook script manually the first time? -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:02, David Kastrup wrote: Jeremy Morton writes: On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. And I don't _want_ that branch name to be recorded. The whole point of a distributed version control system is that it's nobody else's business how I organize my work before submitting it. Well it would be optional, so obviously you wouldn't be forced to share the branch name. It's not like we're trying to "pry in" to your private development. It's a way of choosing to share what you may consider to be useful contextual information about the commit. I don't want to have people tell me when submitting patches "but can't you give this a better branch name?" and then have to use git filter-branch or whatever else to get the branch name removed. As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. It is _totally_ useless information in a distributed development model. Why would or should anybody be concerned what private branches some submitter has developed his patches in? Why should anybody be concerned about what commit message some submitter has typed in for his commit? They could just read the source code to see what has changed, right? Because the commit message is a way for the submitter to try and make it easier for the people looking at the commit to understand what the commit is doing. In the same way, a meaningful branch name may also make it easier for people looking at the commit to understand what it is doing, or what part of the application it is affecting, or what group of commits it is a part of. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat>.git/hooks/commit-msg< "\$1.new" mv "\$1.new" "\$1" EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer "git-branch: \$(git name-rev --name-only HEAD)" "\$1"> "\$1.new" It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv "\$1.new" "\$1"' command. Best, Christian. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 03:30, Sitaram Chamarty wrote: On 04/28/2014 01:03 AM, Johan Herland wrote: Yeah, sure. Author and Date (and Committer, for that matter) is just metadata, and the current branch name is simply just another kind of metadata. All of them are more-or-less free-form text fields, and off no they're not. In strictly controlled environments they form part of the audit record for the source code. Yes they can be faked (explicitly), but -- again in strictly controlled environments -- that can be limited to "before it was first pushed". Why these specific headers as part of the audit record, though? Aren't you just arbitrarily defining them as part of the audit record? -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. But why do you need that information? As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. I might include a bug# in the branch name so I don't have to keep typing it in every commit message, or I might just have a handy short description of what part of the application this branch is modifying (like my "pacman-minigame" example). -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 27/04/2014 22:40, James Denholm wrote: Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. In which case, refer to whatever system you use. If you aren't using a ticketing system, have the line "Relates-to: Water cooler conversation with Bob on July 28th" or whatever the patches relate to. (Arguably, though, the better solution is to use a ticketing system, or anything that allows discussion to be easily referenced.) Well, as I said elsewhere in this discussion, Git should provide that functionality built-in, IMHO. It would be good to be able to set a one-liner in my .gitconfig to tag each commit with a "branch checked into" trailer. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 27/04/2014 20:33, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:
On 27/04/2014 10:09, Johan Herland wrote:
As far as I can tell from that discussion, the general opposition to
encoding the branch name as a structural part of the commit object is that,
for some people's workflows, it would be unhelpful and/or misleading. Well
fair enough then - why don't we make it a setting that is off by default,
and can easily be switched on? That way the people for whom tagging the
branch name would be useful have a very easy way to switch it on.
Therefore, the most pragmatic and constructive thing to do at this
point, is IMHO to work within the confines of the existing commit
object structure. I actually believe using commit message trailers
like "Made-on-branch: frotz" in addition to some helpful
infrastructure (hooks, templates, git-interpret-trailers, etc.) should
get you pretty much exactly what you want. And if this feature turns
out to be extremely useful for a lot of users, we can certainly
consider changing the commit object format in the future.
OK, fair enough. So I guess what I'd like to see, then, is good
built-in functionality in Git for these commit message trailers, so that
they are very easy to turn on. I'd like to be able to tell
co-developers to add a one-liner to their git config file rather than
some post-commit script.
I know
that for the workflows I personally have used in the past, such tagging
would be very useful. Quite often I have been looking through the Git log
and wondered what feature a commit was "part of", because I have feature
branches. Just knowing that branch name would be really useful, but the
branch has since been deleted... and in the case of a ff-merge (which I
thought was recommended in Git if possible), the branch name is completely
gone.
True. The branch name is - for better or worse - simply not considered
very important by Git, and a Git commit is simply not considered (by
Git at least) to "be part of" or otherwise "belong to" any branch.
Please understand that I know this full well. :-) I'm saying that the
'ephemeral' pointers' names are, in themselves, useful - if, like me,
you give them meaningful names. What I'm proposing is pretty much an
automatic tagging (somehow...) of each commit with the current branch
name (if one is available); information that carries roughly the same
weight as the commit message. It could be crap, but equally it could be
very useful, in some workflows. I think most of us can agree on that.
seems to only have come up a few times on the mailing list. This is
But it has come up more than once, which would seem to indicate that I'm
not the only one with this request. ;-)
IINM, Mercurial does this differently, so that may be a better fit for
"If I'm Not Mistaken" - I had to look that one up.
the workflows where keeping track of branch names is very important.
Nah, I had a look at Mercurial and I think I prefer Git - this branch
name thing is just my one bugbear. I definitely prefer Git's concept of
a staging area rather than just committing all changes. To do that in
Mercurial you have to use mq and all the different (IMHO unintuative)
commands that entails, and if you accidentally "mq commit" then you
screw everything up. :-) Mercurial also discourages history rewriting
(ie. cleaning up of messy commits), which Git doesn't. I prefer Git's
approach here too.
Yeah, sure. Author and Date (and Committer, for that matter) is just
metadata, and the current branch name is simply just another kind of
metadata. All of them are more-or-less free-form text fields, and off
the top of my head, I can't really say that if we were to design Git
from scratch today, they wouldn't all become optional trailers (or
headers, or what-have-you).
However, we're not designing Git from scratch, and we have to work
with what is already there...
Fair point.
The branch name can provide useful
contextual information. For instance, let's say I'm developing a suite
of
games. If the commit message says "Added basic options dialog", it might
be
useful to see that the branch name is "pacman-minigame" indicating that
the
commit pertains to the options dialog in the Pacman minigame.
In that partcular case, ISTM that the context ("pacman-minigame")
would actually be better preserved elsewhere. E.g. the commits touch
files in a particular "minigames/pacman" subdir, or you prefix the
context in the commit message ("pacman-minigame: Added basic options
dialog"). Also, such a "topic" branch is often tied to a specific
Again, this is a pain because you have to remember to manually tag every
commit message with "pacman-minigame", and it takes up precious space in t
Re: Recording the current branch on each commit?
On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it would
be useful if, along with the Author and Date, git recorded the name of the
current branch on each commit.
This has been discussed multiple times in the past. One example here:
http://thread.gmane.org/gmane.comp.version-control.git/229422
I believe the current conclusion (if any) is that encoding such
information as a _structural_ part of the commit object is not useful.
See the old thread(s) for the actual pro/con arguments.
As far as I can tell from that discussion, the general opposition to
encoding the branch name as a structural part of the commit object is
that, for some people's workflows, it would be unhelpful and/or
misleading. Well fair enough then - why don't we make it a setting that
is off by default, and can easily be switched on? That way the people
for whom tagging the branch name would be useful have a very easy way to
switch it on. I know that for the workflows I personally have used in
the past, such tagging would be very useful. Quite often I have been
looking through the Git log and wondered what feature a commit was "part
of", because I have feature branches. Just knowing that branch name
would be really useful, but the branch has since been deleted... and in
the case of a ff-merge (which I thought was recommended in Git if
possible), the branch name is completely gone.
That said, you are of course free to add this information to your own
commit messages, by appending something like "Made-on-branch: frotz".
In a company setting, you can even create a commit message template or
(prepare-)commit-msg hook to have this line created automatically for
you and your co-workers. You could even append such information
retroactively to existing commits with "git notes". There is also the
current interpret-trailers effort by Christian Couder [1] that should
be useful in creating and managing such lines.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/245874
Well I guess that's another way of doing it. So, why aren't Author and
Date trailers? They don't seem any more fundamental to me than branch
name. I mean the only checkin information you really *need* is the
checksum, and commit's parents. The Author and Date are just extra
pieces of information you might find useful sometimes, right? A bit
like some people might find branch checkin name useful sometimes...?
The branch name can provide useful
contextual information. For instance, let's say I'm developing a suite of
games. If the commit message says "Added basic options dialog", it might be
useful to see that the branch name is "pacman-minigame" indicating that the
commit pertains to the options dialog in the Pacman minigame.
In that partcular case, ISTM that the context ("pacman-minigame")
would actually be better preserved elsewhere. E.g. the commits touch
files in a particular "minigames/pacman" subdir, or you prefix the
context in the commit message ("pacman-minigame: Added basic options
dialog"). Also, such a "topic" branch is often tied to a specific
Again, this is a pain because you have to remember to manually tag every
commit message with "pacman-minigame", and it takes up precious space in
the (already short) commit message.
issue in some bug/issue tracker, and it would in any case be natural
to mention the bug/issue ID in the commit message, at which point the
tracker can provide more context and discussion.
I think it would only be natural to mention the bug# in the final commit
that actually fixes the bug or implements the feature, not the checkins
leading up to that. And, it's still not *guaranteed* that the coder
will remember to put the bug# in even that commit message.
Basically,
I'm saying that well-named branches can and do carry useful contextual
information that oughtn't to be thrown away. Currently, when you delete
that branch, you lose the branch name altogether.
Some would argue that branches are not always well-named... But
But when they are, why should that info be thrown away? When they're
not well-named, they can be ignored (or the branch name recording
feature can be turned off!)
anyway, if the branch ends up getting merged to the mainline, the
merge commit defaults to a message like "Merge branch
'pacman-minigame'".
Only if it's a non-ff merge, which results in less tidy commit trees,
and hence is often recommended against. Whatsmore, tracking down which
branch a commit pertains to is still rather difficult using this
approach. You can go back through the history and find "Merge branc
Re: Recording the current branch on each commit?
On 27/04/2014 09:51, Robin Rosenberg wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says "Added basic options dialog", it might be useful to see that the branch name is "pacman-minigame" indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? Branch names are usually poorly named, so often you don't lose much. One way Speak for yourself - I give my branches useful names. :-) I definitely feel that I am often losing useful contextual information by throwing away the branch name. some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. A very popular way of tracking context is to add some id, such as a bugzilla issue number, to the header or footer of the commit message. Often a branch contains many issues, but the branch itself isn't very interesting. Tools like gitblit, gitweb, gerrit etc can easily be configured to link to the issue using a regular expression. Yes, and I have done this kind of thing in the past. However you really don't want to put the bug# on every single commit pertaining to that bug; you have to go to the effort of looking the bug# up every time, you'll sometimes forget, and besides it takes up space that could be used for a commit message. As short commit messages are valued in Git, it's particularly bad to waste space this way. Much better would be to include the bug# as part of the branch name, and then if you record the branch name upon checkin you always get a reference to the bug#. Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Recording the current branch on each commit?
Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says "Added basic options dialog", it might be useful to see that the branch name is "pacman-minigame" indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad git log behavior with multiple glob path arguments
On Wed, Mar 5, 2014 at 3:01 AM, Duy Nguyen wrote: > On Wed, Mar 5, 2014 at 12:56 PM, Jeremy Nickurak wrote: >> git log seems to understand globs in the last path argument, and the >> last path argument only. I didn't see anything in the git log man page >> expressly saying this was to be expected, but it does seem like it >> ought to work for all the arguments or none of them. > > What version did you use? We have a fix in the same area, > e4ddb05 (tree_entry_interesting: match against all pathspecs - > 2014-01-25), and it's in v1.8.5.5 and v1.9.0 So close! :) 1.8.5.3 >> Note that glob matching doesn't seem to occur unless '--' is included. > > do you mean "git log" does not run at all and complains about > disambiguation, or it runs but nothing is filtered? It complains about disambiguation: $ mkdir -p ~/tmp; cd ~/tmp; git init; echo hello > hello.txt; git add hello.txt; git commit -m hello; echo "Without --:"; git log --oneline '*.txt'; echo "With --:"; git log --oneline -- '*.txt'; Reinitialized existing Git repository in /home/nickuj/tmp/.git/ On branch master nothing to commit, working directory clean Without --: fatal: ambiguous argument '*.txt': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' With --: 78ff378 hello -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bad git log behavior with multiple glob path arguments
git log seems to understand globs in the last path argument, and the last path argument only. I didn't see anything in the git log man page expressly saying this was to be expected, but it does seem like it ought to work for all the arguments or none of them. Here's a little shell script I ended up using to convince myself I wasn't going crazy. I'd expect the same output for all of the git log test, since they all specify (either with globs or not) all the files added to the repository. Alternatively, if globs aren't expected to work, I'd at least expect all the glob tests to return nothing. Note that glob matching doesn't seem to occur unless '--' is included. I'm not exactly clear on why that is. #!/bin/sh TESTREPO="$(pwd)/bad-glob-test-repo" rm -rf "$TESTREPO" echo "Running tests in $TESTREPO" mkdir "$TESTREPO" cd "$TESTREPO" mkdir subdira mkdir subdirb mkdir subdirc git init echo a > subdira/file.txt echo b > subdirb/file.txt echo c > subdirc/file.txt git add subdira/file.txt git commit -m 'a' git add subdirb/file.txt git commit -m 'b' git add subdirc/file.txt git commit -m 'c' echo Glob Test 1: git log --oneline -- 'subdira/*.txt' 'subdirb/*.txt' 'subdirc/*.txt' git log --oneline -- 'subdira/*.txt' 'subdirb/*.txt' 'subdirc/*.txt' echo Glob Test 2: git log --oneline -- 'subdira/*.txt' 'subdirc/*.txt' 'subdirb/*.txt' git log --oneline -- 'subdira/*.txt' 'subdirc/*.txt' 'subdirb/*.txt' echo Glob Test 3: git log --oneline -- 'subdirb/*.txt' 'subdira/*.txt' 'subdirc/*.txt' git log --oneline -- 'subdirb/*.txt' 'subdira/*.txt' 'subdirc/*.txt' echo Glob Test 4: git log --oneline -- 'subdirb/*.txt' 'subdirc/*.txt' 'subdira/*.txt' git log --oneline -- 'subdirb/*.txt' 'subdirc/*.txt' 'subdira/*.txt' echo Glob Test 5: git log --oneline -- 'subdirc/*.txt' 'subdira/*.txt' 'subdirb/*.txt' git log --oneline -- 'subdirc/*.txt' 'subdira/*.txt' 'subdirb/*.txt' echo Glob Test 6: git log --oneline -- 'subdirc/*.txt' 'subdirb/*.txt' 'subdira/*.txt' git log --oneline -- 'subdirc/*.txt' 'subdirb/*.txt' 'subdira/*.txt' echo Explicit Test 1: git log --oneline -- 'subdira/file.txt' 'subdirb/file.txt' 'subdirc/file.txt' git log --oneline -- 'subdira/file.txt' 'subdirb/file.txt' 'subdirc/file.txt' echo Explicit Test 2: git log --oneline -- 'subdira/file.txt' 'subdirc/file.txt' 'subdirb/file.txt' git log --oneline -- 'subdira/file.txt' 'subdirc/file.txt' 'subdirb/file.txt' echo Explicit Test 3: git log --oneline -- 'subdirb/file.txt' 'subdira/file.txt' 'subdirc/file.txt' git log --oneline -- 'subdirb/file.txt' 'subdira/file.txt' 'subdirc/file.txt' echo Explicit Test 4: git log --oneline -- 'subdirb/file.txt' 'subdirc/file.txt' 'subdira/file.txt' git log --oneline -- 'subdirb/file.txt' 'subdirc/file.txt' 'subdira/file.txt' echo Explicit Test 5: git log --oneline -- 'subdirc/file.txt' 'subdira/file.txt' 'subdirb/file.txt' git log --oneline -- 'subdirc/file.txt' 'subdira/file.txt' 'subdirb/file.txt' echo Explicit Test 6: git log --oneline -- 'subdirc/file.txt' 'subdirb/file.txt' 'subdira/file.txt' git log --oneline -- 'subdirc/file.txt' 'subdirb/file.txt' 'subdira/file.txt' -- Jeremy Nickurak -= Email/XMPP: -= jer...@nickurak.ca =- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Setting per-repository configuration for git
Hello everybody I am looking into the git configuration mechanism and there seem to be a "hole" in use cases I'm trying to figure out... git configurations can be saved at various places * /etc/gitconfig : system-wide configuration * ~/.gitconfig : user-wide configuration * .git/config : repository-wide configuration however I can't find a way to have the repository's configuration saved and transmited with the repository in a way similar to how .gitignore is transmitted... Saving some configuration information within a repository is not unknown in git. .gitignore does it, and submodule configuration does it to. I think it's important to have a way to have configuration options be saved in a repository (and overridable with .git/config which is local-repository only) because a lot of configurationoptions are meant to express repository policies (triangular workflows, merge vs rebase, mail vs push) and it would make sense to have them transmitted that way. Knowing how mature git is I can only assume that this has already been discussed and that there is a good reason not to do it. Is it because of hooks ? would it break something I don't see in git ? git (the project) shouldn't enforce policies on repositories, but I think it makes sense for repositories to have a way to set default policies on their clone... Thx Cordialement Jérémy Rosen +33 (0)1 42 68 28 04 fight key loggers : write some perl using vim Open Wide Ingenierie 23, rue Daviel 75012 Paris - France www.openwide.fr -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFE: support change-id generation natively
for those of us that are not using gerrit... what is a change-id (semantically, I got from your mail that it is some sort of unit id set at commit time) and in what way is it different from the commit-id ? Cordialement Jérémy Rosen +33 (0)1 42 68 28 04 fight key loggers : write some perl using vim Open Wide Ingenierie 23, rue Daviel 75012 Paris - France www.openwide.fr - Mail original - > Hello Git Community, > > TL;DR: > It would be a really nice enhancement if the commit command natively > supported _optionally_ injecting a "Change-Id: I000..." footer in the > last paragraph of the commit message template and then substituting > the > "I000..." value, on commit, with a generated value _without_ having > to > rely on a per-repository, native hook or a global hook that affects > every local repository. > > Full Request: > Gerrit has established the change-id footer as a prominent and > wide-spread collaboration identifier. For those contributing new > patches to a Gerrit server, it is required to either use EGit/JGit > (Eclipse) to generate commits [1] OR to use a commit hook script with > native git to insert a change-id footer during the commit process > [2]. > This per-repository hook script requirement is an obstacle. These > communities would be better served and it would lower the > contribution > barrier for many open source projects if native git supported > change-id > generation & injection. > > I acknowledge that not everyone uses nor wants to use Gerrit and the > change-id footer. That is fine, but it would be a _tremendous_ > usability improvement for those contributing to open source projects > (myself included) if something like a "--change-id" flag was > implemented and maybe even a config setting to always generate a > change-id on commit (EGit currently supports this as > "gerrit.createchangeid=true"). > > Sadly, my C skills are lacking as I live mostly in the world of > managed > code, but I'd be very happy to cheer for a change-id champion; I > suspect > there are some out there who might rally to this cause. > > Thanks for your consideration. > James Moger > gitblit.com > > [1] > https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/api/CommitCommand.java?h=stable-3.1#n288 > [2] > http://gerrit-documentation.googlecode.com/svn/Documentation/2.0/cmd-hook-commit-msg.html > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/2] status: always show tracking branch even no change
> > But this will not work if there is no change between the current > branch and its upstream. Always report upstream tracking info > even if there is no difference, so that "git status" is consistent > for checking tracking info for current branch. E.g. > > $ git status > # On branch feature1 > # Your branch is identical to 'github/feature1'. > ... > > $ git status -bs > ## feature1...github/feature1 > ... > > $ git checkout feature1 > Already on 'feature1' > Your branch is identical to 'github/feature1'. > ... > nitpicking, but shouldn't this be worded as "up to date" rather than "identical" ? The reason is that identical gives the idea that the two branch happen to be on the same commit wheras "up to date" gives the idea that there is a special relationship between these two particular branches. We are not just listing all branches on the same commit as us, we are actively telling you about this branch because it's interesting to you. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Makefile: Fix APPLE_COMMON_CRYPTO with BLK_SHA1
Thanks Brian, Reviewed-by: Jeremy Huddleston Sequoia On Aug 5, 2013, at 8:59, Brian Gernhardt wrote: > It used to be that APPLE_COMMON_CRYPTO did nothing when BLK_SHA1 was > set. But APPLE_COMMON_CRYPTO is now used for more than just SHA1 (see > 3ef2bca) so make sure that the appropriate libraries are always set. > > Signed-off-by: Brian Gernhardt > --- > Makefile | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 82f2e22..7051956 100644 > --- a/Makefile > +++ b/Makefile > @@ -1182,6 +1182,9 @@ ifdef NEEDS_SSL_WITH_CRYPTO > else > LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto > endif > +ifdef APPLE_COMMON_CRYPTO > + LIB_4_CRYPTO += -framework Security -framework CoreFoundation > +endif > endif > ifdef NEEDS_LIBICONV > ifdef ICONVDIR > @@ -1413,7 +1416,6 @@ ifdef PPC_SHA1 > LIB_H += ppc/sha1.h > else > ifdef APPLE_COMMON_CRYPTO > - LIB_4_CRYPTO += -framework Security -framework CoreFoundation > COMPAT_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL > SHA1_HEADER = > else > -- > 1.8.4.rc1.384.g0976a17.dirty > smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 2/3] OS X: Fix redeclaration of die warning
Thanks Brian, Reviewed-by: Jeremy Huddleston Sequoia On Aug 5, 2013, at 8:59, Brian Gernhardt wrote: > compat/apple-common-crypto.h uses die() in one of its macros, but was > included in git-compat-util.h before the definition of die. > > Fix by simply moving the relevant block after the die/error/warning > declarations. > > Signed-off-by: Brian Gernhardt > --- > > Not sure if this is the best place to move it to, but it's the earliest it can > be in the file without causing errors. (Namely that clang has to guess what > die() means in apple-common-crypto.h and guesses differently than the actual > definition.) > > git-compat-util.h | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/git-compat-util.h b/git-compat-util.h > index af5f6bb..d60e28d 100644 > --- a/git-compat-util.h > +++ b/git-compat-util.h > @@ -129,16 +129,6 @@ > #include > #endif > > -#ifndef NO_OPENSSL > -#ifdef APPLE_COMMON_CRYPTO > -#include "compat/apple-common-crypto.h" > -#else > -#include > -#include > -#endif /* APPLE_COMMON_CRYPTO */ > -#include > -#endif /* NO_OPENSSL */ > - > #if defined(__MINGW32__) > /* pull in Windows compatibility stuff */ > #include "compat/mingw.h" > @@ -340,6 +330,16 @@ extern NORETURN void die_errno(const char *err, ...) > __attribute__((format (prin > extern int error(const char *err, ...) __attribute__((format (printf, 1, 2))); > extern void warning(const char *err, ...) __attribute__((format (printf, 1, > 2))); > > +#ifndef NO_OPENSSL > +#ifdef APPLE_COMMON_CRYPTO > +#include "compat/apple-common-crypto.h" > +#else > +#include > +#include > +#endif /* APPLE_COMMON_CRYPTO */ > +#include > +#endif /* NO_OPENSSL */ > + > /* > * Let callers be aware of the constant return value; this can help > * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though, > -- > 1.8.4.rc1.384.g0976a17.dirty > smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] imap-send: use Apple's Security framework for base64 encoding
Hi David,
Thanks for massaging it to apply to master and cleaning up the style conflicts.
On Jul 27, 2013, at 13:31, David Aguilar wrote:
> From: Jeremy Huddleston
>
> Use Apple's supported functions for base64 encoding instead
> of the deprecated OpenSSL functions.
>
> Signed-off-by: Jeremy Huddleston
> Signed-off-by: David Aguilar
> ---
> This is Jeremy's original patch rebased onto the latest master.
>
> Jeremy, the only way I could get this to work was to suppress inclusion of
> openssl/sha.h by defining HEADER_SHA_H. This can be removed when we have
> replacements for openssl/x509v3.h.
>
> Makefile| 1 +
> imap-send.c | 85 ++---
> 2 files changed, 82 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 0600eb4..4c40665 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1413,6 +1413,7 @@ ifdef PPC_SHA1
> LIB_H += ppc/sha1.h
> else
> ifdef APPLE_COMMON_CRYPTO
> + LIB_4_CRYPTO += -framework Security -framework CoreFoundation
> COMPAT_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL
> SHA1_HEADER =
> else
> diff --git a/imap-send.c b/imap-send.c
> index d6b65e2..3fd9c0e 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -22,14 +22,11 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
>
> -#include "cache.h"
> -#include "exec_cmd.h"
> -#include "run-command.h"
> -#include "prompt.h"
> #ifdef NO_OPENSSL
> typedef void *SSL;
> #else
> #ifdef APPLE_COMMON_CRYPTO
> +/* git-compat-util.h overwrites ctype.h; this must be included first */
> #include
> #define HMAC_CTX CCHmacContext
> #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len)
> @@ -37,12 +34,23 @@ typedef void *SSL;
> #define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash)
> #define HMAC_CTX_cleanup(ignore)
> #define EVP_md5() kCCHmacAlgMD5
> +
> +#if __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
> +#define APPLE_LION_OR_NEWER
> +#include
> +#define HEADER_SHA_H /* suppress inclusion of openssl/sha.h */
> +#endif
> +
> #else
> #include
> #include
> #endif
> #include
> #endif
> +#include "cache.h"
> +#include "exec_cmd.h"
> +#include "run-command.h"
> +#include "prompt.h"
>
> static const char imap_send_usage[] = "git imap-send < ";
>
> @@ -877,6 +885,75 @@ static void imap_close_store(struct imap_store *ctx)
> free(ctx);
> }
>
> +#ifdef APPLE_LION_OR_NEWER
> +#define EVP_DecodeBlock git_CC_EVP_DecodeBlock
> +#define EVP_EncodeBlock git_CC_EVP_EncodeBlock
> +#define error_check(pattern, err) \
> + do { \
> + if (err) { \
> + die(pattern, (long)CFErrorGetCode(err)); \
> + } \
> + } while(0)
> +
> +static int git_CC_EVP_EncodeBlock(unsigned char *out,
> + const unsigned char *in, int inlen)
> +{
> + CFErrorRef err;
> + SecTransformRef encoder;
> + CFDataRef input, output;
> + CFIndex length;
> +
> + encoder = SecEncodeTransformCreate(kSecBase64Encoding, &err);
> + error_check("SecEncodeTransformCreate failed: %ld", err);
> +
> + input = CFDataCreate(kCFAllocatorDefault, in, inlen);
> + SecTransformSetAttribute(encoder, kSecTransformInputAttributeName,
> + input, &err);
> + error_check("SecTransformSetAttribute failed: %ld", err);
> +
> + output = SecTransformExecute(encoder, &err);
> + error_check("SecTransformExecute failed: %ld", err);
> +
> + length = CFDataGetLength(output);
> + CFDataGetBytes(output, CFRangeMake(0, length), out);
> +
> + CFRelease(output);
> + CFRelease(input);
> + CFRelease(encoder);
> +
> + return (int)strlen((const char *)out);
> +}
> +
> +static int git_CC_EVP_DecodeBlock(unsigned char *out,
> + const unsigned char *in, int inlen)
> +{
> + CFErrorRef err;
> + SecTransformRef decoder;
> + CFDataRef input, output;
> + CFIndex length;
> +
> + decoder = SecDecodeTransformCreate(kSecBase64Encoding, &err);
> + error_check("SecEncodeTransformCreate failed: %ld", err);
> +
> + input = CFDataCreate(kCFAllocatorDefault, in, inlen);
> + SecTransformSetAttribute(decoder, kSecTransformInputAttributeName,
> + input, &err);
> + error_check("SecTransformSetAttribute failed: %ld", err);
> +
> + output = SecTransformExecute(decoder, &err);
> + error_check("SecTransformExecute failed: %ld", err);
> +
> + length = CFDataGetLength(output);
> + CFDataGetBytes(output, CFRangeMake(0, length), out);
> +
> + CFRelease(output);
> + CFRelease(input);
> + CFRelease(decoder);
> +
> + return (int)strlen((const char *)out);
> +}
> +#endif /* APPLE_LION_OR_NEWER */
> +
> #ifndef NO_OPENSSL
>
> /*
> --
> 1.8.3.2.804.g0da7a53.dirty
>
smime.p7s
Description: S/MIME cryptographic signature
Re: first parent, commit graph layout, and pull merge direction
- Mail original - > On Thu, May 23, 2013 at 5:06 AM, Andreas Krey wrote: > [snip] > > ... > >> Don't do that, then. > > > > :-) Problem is, in this case 'I' expands to about > > 1<<7 people I need to educate on this. > > This is a feature of `git pull` that I really despise. I really wish > `git pull` treated the remote as the first parent in its merge > operation. > seconded... github's network pages (which display the commit graph of projects) seems to follow the "first parent at the top" rule and the pull merges are standing out as "wrong" because of that... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] show: obey --textconv for blobs
> > git show --textconv HEAD~4:binary-gob | less > > > > but I doubt it is a good idea to turn it on by default this late in > > the game. > > Exactly. I certainly do not mind it as an option, and I am on the > fence > regarding it as a default (I think it might have been a sane thing to > do > from the start, but at this point the change-of-behavior makes me > hesitate). So I am perfectly willing to go either way, depending on > what > others think. > some features detect if they are piping to a terminal... couldn't we do something like that ? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
