Re: [PATCH] configure.ac: loosen FREAD_READS_DIRECTORIES test program
On 2017-06-14 01:30:18, Jeff King wrote: > On Wed, Jun 14, 2017 at 01:15:44AM -0400, Jeff King wrote: > > Actually, I'm not sure if configure.ac is wrong, or the new uses of > > FREAD_READS_DIRECTORIES. Because the test configure.ac actually > > checks: > > Poking around more, I think the best thing is to just update the > configure script. The rationale is below. > > -- >8 -- > Subject: [PATCH] configure.ac: loosen FREAD_READS_DIRECTORIES test > program Yes, this patch fixes t1308. I also ran the whole test suite with the patch, everything succeeds. Thanks, Øyvind N 60.376° E 5.3334° OpenPGP fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 17e7451e-50f0-11e7-a287-db5caa6d21d3 signature.asc Description: PGP signature
Re: t1308-config-set.sh fails on current master
Hi, Jonathan, thanks for having a look at this.
On 2017-06-13 18:25:35, Jonathan Nieder wrote:
> Øyvind A. Holm wrote:
> > t1308-config-set.sh fails on current master
> > (v2.13.1-449-g02a2850ad58e). The error is introduced by commit
> > e2d90fd1c33a ("config.mak.uname: set FREAD_READS_DIRECTORIES for
> > Linux and FreeBSD"). Reverting the commit results in a conflict, but
> > the test works on the commit before, 02912f477586.
> >
> > Tested on
> >
> > Debian GNU/Linux 8.8 (jessie)
> > Linux Mint 18 Sarah
>
> Interesting. I'm not able to reproduce it, but of course that doesn't
> mean much.
I'll admit that I have a somewhat special build system, but it's been
working great since I created it 7 months ago, and I run the test suite
every time I install a new git. I'm using the Makefile located at
https://gitlab.com/sunny256/src-other/blob/master/devel/git/Makefile
It's only doing regular stuff like "make configure", "./configure", etc,
but I'm mentioning it in case the Makefile reveals something
interesting. The git installation is in a non-standard location, the
newest version of git I've installed is for example located under
/usr/src-other/pool/git.master.v2.13.1-394-g41dd4330a121/ .
> What is the output of the following command?
>
> ./t1308-config-set.sh --run=1,23 -x -v -i
Initialized empty Git repository in
/home/sunny/src/git/src-other/devel/git/git/t/trash
directory.t1308-config-set/.git/
expecting success:
cat >.git/config <<-\EOF
[case]
penguin = very blue
Movie = BadPhysics
UPPERCASE = true
MixedCase = true
my =
foo
baz = sam
[Cores]
WhatEver = Second
baz = bar
[cores]
baz = bat
[CORES]
baz = ball
[my "Foo bAr"]
hi = mixed-case
[my "FOO BAR"]
hi = upper-case
[my "foo bar"]
hi = lower-case
[case]
baz = bat
baz = hask
[lamb]
chop = 65
head = none
[goat]
legs = 4
head = true
skin = false
nose = 1
horns
EOF
+ cat
ok 1 - setup default config
skipping test: get value for a simple key
check_config get_value case.penguin "very blue"
ok 2 # skip get value for a simple key (--run)
skipping test: get value for a key with value as an empty string
check_config get_value case.my ""
ok 3 # skip get value for a key with value as an empty string (--run)
skipping test: get value for a key with value as NULL
check_config get_value case.foo "(NULL)"
ok 4 # skip get value for a key with value as NULL (--run)
skipping test: upper case key
check_config get_value case.UPPERCASE "true" &&
check_config get_value case.uppercase "true"
ok 5 # skip upper case key (--run)
skipping test: mixed case key
check_config get_value case.MixedCase "true" &&
check_config get_value case.MIXEDCASE "true" &&
check_config get_value case.mixedcase "true"
ok 6 # skip mixed case key (--run)
skipping test: key and value with mixed case
check_config get_value case.Movie "BadPhysics"
ok 7 # skip key and value with mixed case (--run)
skipping test: key with case sensitive subsection
check_config get_value "my.Foo bAr.hi" "mixed-case" &&
check_config get_value "my.FOO BAR.hi" "upper-case" &&
check_config get_value "my.foo bar.hi" "lower-case"
ok 8 # skip key with case sensitive subsection (--run)
skipping test: key with case insensitive section header
check_config get_value cores.baz "ball" &&
check_config get_value Cores.baz "ball" &&
check_config get_value CORES.baz "ball" &&
check_config get_value coreS.baz "ball"
ok 9 # skip key with case insensitive section header (--run)
skipping test: key with case insensitive section header & variable
check_config get_value CORES.BAZ "ball" &&
check_config get_value cores.baz "ball" &&
check_config get_value cores.BaZ "ball" &&
check_config get_value cOreS.bAz "ball"
ok 10 # skip key with case insensitive section header & variable (--run)
skipping test: find value with misspelled key
check_config expect_code 1 get_value "my.fOo Bar.hi&quo
t1308-config-set.sh fails on current master
t1308-config-set.sh fails on current master (v2.13.1-449-g02a2850ad58e).
The error is introduced by commit e2d90fd1c33a ("config.mak.uname: set
FREAD_READS_DIRECTORIES for Linux and FreeBSD"). Reverting the commit
results in a conflict, but the test works on the commit before,
02912f477586.
Tested on
Debian GNU/Linux 8.8 (jessie)
Linux Mint 18 Sarah
Test output:
$ ./t1308-config-set.sh
ok 1 - setup default config
ok 2 - get value for a simple key
ok 3 - get value for a key with value as an empty string
ok 4 - get value for a key with value as NULL
ok 5 - upper case key
ok 6 - mixed case key
ok 7 - key and value with mixed case
ok 8 - key with case sensitive subsection
ok 9 - key with case insensitive section header
ok 10 - key with case insensitive section header & variable
ok 11 - find value with misspelled key
ok 12 - find value with the highest priority
ok 13 - find integer value for a key
ok 14 - find string value for a key
ok 15 - check line error when NULL string is queried
ok 16 - find integer if value is non parse-able
ok 17 - find bool value for the entered key
ok 18 - find multiple values
ok 19 - find value from a configset
ok 20 - find value with highest priority from a configset
ok 21 - find value_list for a key from a configset
ok 22 - proper error on non-existent files
not ok 23 - proper error on directory "files"
#
# echo "Error (-1) reading configuration file a-directory."
>expect &&
# mkdir a-directory &&
# test_expect_code 2 test-config configset_get_value foo.bar
a-directory 2>output &&
# grep "^warning:" output &&
# grep "^Error" output >actual &&
# test_cmp expect actual
#
ok 24 - proper error on non-accessible files
ok 25 - proper error on error in default config files
ok 26 - proper error on error in custom config files
ok 27 - check line errors for malformed values
ok 28 - error on modifying repo config without repo
ok 29 - iteration shows correct origins
# failed 1 among 29 test(s)
1..29
$
Øyvind
N 60.376° E 5.3334°
OpenPGP fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5
2daabdde-509d-11e7-a17a-db5caa6d21d3
signature.asc
Description: PGP signature
[BUG] b9c8e7f2fb6e breaks git bisect visualize
Commit b9c8e7f2fb6e ("prefix_ref_iterator: don't trim too much") breaks
git bisect visualize, this reproduces the bug:
$ git bisect start
$ git bisect bad
$ git bisect good HEAD^^
$ git bisect visualize
fatal: BUG: attempt to trim too many characters
$
Reverting b9c8e7f2fb6e makes git bisect visualize work again.
Tested on Debian GNU/Linux 8.8 (jessie).
Øyvind
N 60.37604° E 5.9°
OpenPGP fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5
dcacbb24-5094-11e7-b7e4-db5caa6d21d3
signature.asc
Description: PGP signature
Git just passed Subversion on openhub.net
openhub.net has a comparion of the number of public repositories on the net, based on searching public hosting services on the net. Git just passed Subversion after the number of Git repositories has exploded lately. It seems as lots of new repositories were created after cpython changed to Git in February. I've been tracking the development on <https://www.openhub.net/repositories/compare> since 2014-08, and all the data since then are availble on https://gitlab.com/sunny256/openhub-repositories and https://github.com/sunny256/openhub-repositories Current status: https://gitlab.com/sunny256/openhub-repositories/blob/master/status.txt SVG graphs are available on https://gitlab.com/sunny256/openhub-repositories/tree/master/graph Regards, Øyvind +-| Øyvind A. Holm <su...@sunbase.org> - N 60.37604° E 5.9° |-+ | OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc | | Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 | +| 27e0042e-3985-11e7-b3fc-db5caa6d21d3 |-+ signature.asc Description: PGP signature
Re: SHA1 collisions found
On 2017-02-25 00:05:34, Jakub Narębski wrote:
> W dniu 24.02.2017 o 23:53, Santiago Torres pisze:
> > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:
> > > I have just read on ArsTechnica[1] that while Git repository could
> > > be corrupted (though this would require attackers to spend great
> > > amount of resources creating their own collision, while as said
> > > elsewhere in this thread allegedly easy to detect), putting two
> > > proof-of-concept different PDFs with same size and SHA-1 actually
> > > *breaks* Subversion. Repository can become corrupt, and stop
> > > accepting new commits.
> >
> > From what I understood in the thread[1], it was the combination of
> > svn + git-svn together. I think Arstechnica may be a little bit
> > sensationalistic here.
>
> > [1] https://bugs.webkit.org/show_bug.cgi?id=168774#c27
>
> Thanks for the link. It looks like the problem was with svn itself
> (couldn't checkout, couldn't sync), but repository is recovered now,
> though not protected against the problem occurring again.
>
> Well, anyone with Subversion installed (so not me) can check it for
> himself/herself... though better do this with separate svnroot.
I tested this yesterday by adding the two PDF files to a Subversion
repository, and found that it wasn't able to clone ("checkout" in svn
speak) the repository after the two files had been committed. I posted
the results to the svn-dev mailing list, the thread is at
<https://svn.haxx.se/dev/archive-2017-02/0142.shtml>.
It seems as it only breaks the working copy because the pristine copies
are identified with a SHA1 sum, but the FSFS repository backend seems to
cope with it.
Regards,
Øyvind
+-| Øyvind A. Holm <su...@sunbase.org> - N 60.37604° E 5.9° |-+
| OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |
| Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 |
+| 41517b2c-fae7-11e6-9521-db5caa6d21d3 |-+
signature.asc
Description: PGP signature
Re: SHA1 collisions found
On 2017-02-23 11:09:32, Linus Torvalds wrote: > I'm aware of the fsck checks, but I have to admit I wasn't aware of > 'transfer.fsckobjects'. I should turn that on myself. > > Or maybe git should just turn it on by default? The problem with this is that there are many repos with errors out there, for example coreutils.git and nasm.git, which complains about "missingSpaceBeforeDate: invalid author/committer line - missing space before date". There are also lots of repositories bitten by the Github bug from back in 2011 where they zero-padded the file modes, git clone aborts with "zeroPaddedFilemode: contains zero-padded file modes". Paranoid as I am, I'm using fetch.fsckObjects and receive.fsckObjects set to "true", but that means I'm not able to clone repositories with these kind of errors, have to use the alias fclone = clone -c "fetch.fsckObjects=false" So enabling them by default will create problems among users. Of course, one solution would be to turn these kind of errors into warnings so the clone isn't aborted. Reagards, Øyvind +-| Øyvind A. Holm <su...@sunbase.org> - N 60.37604° E 5.9° |-+ | OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc | | Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 | +| c7e47a18-fa06-11e6-ad93-db5caa6d21d3 |-+ signature.asc Description: PGP signature
Re: [PATCH v2 7/7] Makefile: add a knob to enable the use of Asciidoctor
On 2017-01-23 04:09:17, brian m. carlson wrote:
> On Mon, Jan 23, 2017 at 03:57:13AM +0100, Øyvind A. Holm wrote:
> > On 2017-01-22 02:41:56, brian m. carlson wrote:
> > > While Git has traditionally built its documentation using
> > > AsciiDoc, some people wish to use Asciidoctor for speed or other
> > > reasons. Add a Makefile knob, USE_ASCIIDOCTOR, that sets various
> > > options in order to produce acceptable output. For HTML output,
> > > XHTML5 was chosen, since the AsciiDoc options also produce XHTML,
> > > albeit XHTML 1.1.
> >
> > I applied and tested the patches on the current master, commit
> > 787f75f0567a ("Sixth batch for 2.12"), and "make doc" with
> > USE_ASCIIDOCTOR fails:
> >
> > [...]
> >
> > $ asciidoctor --version
> > Asciidoctor 0.1.4 [http://asciidoctor.org]
>
> I think you need a newer version of Asciidoctor. I fixed one or two
> issues upstream in 1.5.2, I think, that made it work properly.
I've tried on Linux Mint 18 with Asciidoctor 1.5.4 now, and it works
there, so the version is probably too old, yes.
> You could try to do the build with the "html5" target instead of
> "xhtml5" and see if that works. If so, we could switch to that
> instead if we want to support older Asciidoctor versions.
It went a little better, but after a while it died with
$ make doc USE_ASCIIDOCTOR=1
[Cut 249 lines]
GEN technical/api-index.txt
ASCIIDOC technical/api-index.html
ASCIIDOC git-init-db.xml
sed "s|@@MAN_BASE_URL@@|file:///home/sunny/share/doc/git-doc/|"
manpage-base-url.xsl.in > manpage-base-url.xsl
XMLTO git-init-db.1
xmlto:
/home/sunny/src/git/src-other/devel/git/git/Documentation/git-init-db.xml does
not validate (status 3)
xmlto: Fix document syntax or use --skip-validation option
/home/sunny/src/git/src-other/devel/git/git/Documentation/git-init-db.xml:5:
element article: validity error : root and DTD name do not match 'article' and
'manpage'
Document
/home/sunny/src/git/src-other/devel/git/git/Documentation/git-init-db.xml does
not validate
Makefile:343: recipe for target 'git-init-db.1' failed
make[1]: *** [git-init-db.1] Error 13
make[1]: Leaving directory
'/home/sunny/src/git/src-other/devel/git/git/Documentation'
Makefile:2091: recipe for target 'doc' failed
make: *** [doc] Error 2
$
and that's fair enough, since the generated html isn't well-formed.
Adding --skip-validation to XMLTO_EXTRA gave a slightly different
result:
GEN technical/api-index.txt
ASCIIDOC technical/api-index.html
ASCIIDOC git-init-db.xml
sed "s|@@MAN_BASE_URL@@|file:///home/sunny/share/doc/git-doc/|"
manpage-base-url.xsl.in > manpage-base-url.xsl
XMLTO git-init-db.1
Note: namesp. cut : stripped namespace before processing
git-init-db(1)
Note: namesp. cut : processing stripped document
git-init-db(1)
Erro: no refentry: No refentry elements found in "git-init-db(1)
git-init-db(1)
Makefile:343: recipe for target 'git-init-db.1' failed
make[1]: *** [git-init-db.1] Error 1
make[1]: Leaving directory
'/home/sunny/src/git/src-other/devel/git/git/Documentation'
Makefile:2091: recipe for target 'doc' failed
make: *** [doc] Error 2
$
But frankly, this probably isn't a showstopper. Even though this is the
newest stable version of Debian, Asciidoctor 0.1.4 was released
2013-09-05, 3y5m ago. USE_ASCIIDOCTOR isn't the default, so people can
build the docs with asciidoc, and that works in Debian 8.7.
Regards,
Øyvind
+-| Øyvind A. Holm <su...@sunbase.org> - N 60.37604° E 5.9° |-+
| OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |
| Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 |
+| 1698e7f6-e257-11e6-bfa0-db5caa6d21d3 |-+
signature.asc
Description: PGP signature
Re: [PATCH v2 7/7] Makefile: add a knob to enable the use of Asciidoctor
On 2017-01-22 02:41:56, brian m. carlson wrote:
> While Git has traditionally built its documentation using AsciiDoc, some
> people wish to use Asciidoctor for speed or other reasons. Add a
> Makefile knob, USE_ASCIIDOCTOR, that sets various options in order to
> produce acceptable output. For HTML output, XHTML5 was chosen, since
> the AsciiDoc options also produce XHTML, albeit XHTML 1.1.
I applied and tested the patches on the current master, commit
787f75f0567a ("Sixth batch for 2.12"), and "make doc" with
USE_ASCIIDOCTOR fails:
$ git clean -fxd && make doc USE_ASCIIDOCTOR=1
Removing Documentation/cmd-list.made
Removing Documentation/cmds-ancillaryinterrogators.txt
Removing Documentation/cmds-ancillarymanipulators.txt
Removing Documentation/cmds-foreignscminterface.txt
Removing Documentation/cmds-mainporcelain.txt
Removing Documentation/cmds-plumbinginterrogators.txt
Removing Documentation/cmds-plumbingmanipulators.txt
Removing Documentation/cmds-purehelpers.txt
Removing Documentation/cmds-synchelpers.txt
Removing Documentation/cmds-synchingrepositories.txt
Removing Documentation/doc.dep
Removing Documentation/mergetools-diff.txt
Removing Documentation/mergetools-list.made
Removing Documentation/mergetools-merge.txt
Removing GIT-VERSION-FILE
GIT_VERSION = 2.11.0.460.g218feb5a0e89
make -C Documentation all
make[1]: Entering directory
'/home/sunny/src/git/src-other/devel/git/git/Documentation'
GEN mergetools-list.made
GEN cmd-list.made
GEN doc.dep
make[2]: Entering directory '/home/sunny/src/git/src-other/devel/git/git'
make[2]: 'GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory '/home/sunny/src/git/src-other/devel/git/git'
make[2]: Entering directory '/home/sunny/src/git/src-other/devel/git/git'
make[2]: 'GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory '/home/sunny/src/git/src-other/devel/git/git'
ASCIIDOC git-init-db.html
Couldn't find a view in @views for document
Use --trace for backtrace
Makefile:330: recipe for target 'git-init-db.html' failed
make[1]: *** [git-init-db.html] Error 1
make[1]: Leaving directory
'/home/sunny/src/git/src-other/devel/git/git/Documentation'
Makefile:2091: recipe for target 'doc' failed
make: *** [doc] Error 2
2017-01-23 03:50:05 sunny@sunbase:~/src/git/src-other/devel/git/git
(tp-bmc-asciidoctor)
$ lsb_release -d
Description:Debian GNU/Linux 8.7 (jessie)
$ asciidoctor --version
Asciidoctor 0.1.4 [http://asciidoctor.org]
I installed Asciidoctor with a standard "apt-get install asciidoctor",
do I need to install more packages?
The build is broken by patch #7 ("Makefile: add a knob to enable the use
of Asciidoctor"), the other commits seems to work, though I haven't
tested them all individually yet. Standard "make doc" works.
Regards,
Øyvind
+-| Øyvind A. Holm <su...@sunbase.org> - N 60.37604° E 5.9° |-+
| OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |
| Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 |
+| 60bceb4e-e116-11e6-8fac-db5caa6d21d3 |-+
signature.asc
Description: PGP signature
Re: [PATCH 6/7] Documentation: move dblatex arguments into variable
On 2017-01-21 21:59:11, brian m. carlson wrote: > Our dblatex invocation uses several style components from the AsciiDoc > distribution, but those components are not available when building with > Asciidoctor. Move the command line arguments into a variable so it can > be overridden by the user or makefile configuration options. > [...] > - $(DBLATEX) -o $@+ -p $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.xsl -s > $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.sty $< && \ > + $(DBLATEX) $-o $@+ (DBLATEX_COMMON) $< && \ It looks as the dollar sign is in the wrong place, should be in front of (DBLATEX_COMMON). Regards, Øyvind +-| Øyvind A. Holm <su...@sunbase.org> - N 60.37604° E 5.9° |-+ | OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc | | Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 | +| 61815930-e03e-11e6-b4f4-db5caa6d21d3 |-+ signature.asc Description: PGP signature
Re: [PATCH 1/3] Documentation/stash: remove mention of git reset --hard
On 2017-01-21 20:08:02, Thomas Gummerer wrote: > Don't mention git reset --hard in the documentation for git stash save. > It's an implementation detail that doesn't matter to the end user and > thus shouldn't be exposed to them. > [...] > + Save your local modifications to a new 'stash', and revert the > + the changes in the working tree to match the index. The patch contains a duplicated "the". Regards, Øyvind +-| Øyvind A. Holm <su...@sunbase.org> - N 60.37604° E 5.9° |-+ | OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc | | Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 | +| 42073b1c-e041-11e6-bae1-db5caa6d21d3 |-+ signature.asc Description: PGP signature
Re: git-testadd: Execute a command with only the staged changes in Git applied
On 29 July 2016 at 00:38, Junio C Hamano <gits...@pobox.com> wrote:
> Øyvind A. Holm <su...@sunbase.org> writes:
> > Jakub Narębski <jna...@gmail.com> wrote:
> > > I wonder if using `git worktree` instead of `git clone` (well,
> > > local clone uses hardlinks, so it is not that costly as it looks
> > > like) would be a better solution.
> >
> > That's an interesting idea. Have to test it out. This is the result
> > from the current master in linux.git:
> >
> > With clone:
> > ...
> > With worktree:
> > ...
> >
> > Both tests were run with cold cache ("echo 3
> > >/proc/sys/vm/drop_caches" as root). It seems as there's no
> > >difference, and that git clone is as fast as it can get without
> > >breaking physical laws. And we probably shouldn't do that. :)
>
> I expect that writing the 55k+ files in the working tree would
> dominate the cost. Local clone would make some hardlinks in .git
> (including ones in .git/object/*) but the cost of that would not be
> too high as long as the repository is well packed; "git worktree"
> would reduce that part of the cost from "git clone", but both incur
> the cost of "checkout", i.e. actually populating the new working tree.
>
> Does the test directory even need to look anything like Git? In other
> words, would it suffice if it resembled the result of running "git
> archive | tar xf -"? I suspect that it would not make much
> difference, either, for the same reason, though ;-).
Using git archive saved 1.6 seconds:
$ mkdir testdir; git archive HEAD | (cd testdir && time tar x)
real0m8.881s
user0m0.440s
sys 0m2.740s
$
But when .git is missing in the subdir, git apply doesn't work. Can't
think of any way to get that to work without involving patch(1) and
friends, and then the binary diffs goes out of the window.
But I'm quite satisfied with 10.4 seconds with cold diskcache and >55K
files. Very impressive, actually.
- Øyvind
--
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-testadd: Execute a command with only the staged changes in Git applied
On 28 July 2016 at 21:31, Jakub Narębski <jna...@gmail.com> wrote:
> W dniu 2016-07-28 o 18:56, Øyvind A. Holm pisze:
> > Øyvind A. Holm <su...@sunbase.org> writes:
> > > This is a script I created some weeks ago, and I've found it to be
> > > immensely useful. Here is a snippet from git-testadd --help:
> > > [...]
> > > This script clones the repository to the directory
> > > ".testadd.tmp" in the current directory and applies the staged
> > > chenges there (unless -u/--unmodified or -p/--pristine is
> > > specified), chdirs to the same relative directory in the clone
> > > and executes the command specified on the command line there.
> >
> > That's correct, the test clone is entirely separated from the
> > working copy, and you can keep working while the tests are running
> > in the clone. Combined with git-gui and/or "git add -p/git reset
> > -p", it's easy to tweak the staged changes until things are ok.
>
> I wonder if using `git worktree` instead of `git clone` (well, local
> clone uses hardlinks, so it is not that costly as it looks like) would
> be a better solution.
That's an interesting idea. Have to test it out. This is the result from
the current master in linux.git:
With clone:
$ time git testadd pwd
git-testadd: Using ".testadd.tmp" as destination directory
Cloning into '.testadd.tmp'...
done.
Checking out files: 100% (55256/55256), done.
git-testadd: Applying staged changes
git-testadd: Executing "pwd" in /home/sunny/src/test-wt/.testadd.tmp
/home/sunny/src/test-wt/.testadd.tmp
real0m10.464s
user0m5.983s
sys 0m2.790s
$
With worktree:
$ time git worktree add testaddtmp
Preparing testaddtmp (identifier testaddtmp)
Checking out files: 100% (55256/55256), done.
HEAD is now at 194dc87 Add braces to avoid "ambiguous ‘else’" compiler
warnings
real0m10.343s
user0m6.010s
sys 0m2.523s
$
Both tests were run with cold cache ("echo 3 >/proc/sys/vm/drop_caches"
as root). It seems as there's no difference, and that git clone is as
fast as it can get without breaking physical laws. And we probably
shouldn't do that. :)
Z poważaniem,
Øyvind
--
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-testadd: Execute a command with only the staged changes in Git applied
On 28 July 2016 at 18:37, Junio C Hamano <gits...@pobox.com> wrote: > Øyvind A. Holm <su...@sunbase.org> writes: > > This is a script I created some weeks ago, and I've found it to be > > immensely useful. Here is a snippet from git-testadd --help: > > > > If you have lots of unrelated uncommitted changes in the current > > repository and want to split up the commit, how can you easily > > check if the changes passes the test suite? With all the other > > unrelated changes it can be hard to make sure that only relevant > > changes becomes part of the commit, and that they don't result in > > regressions. This script clones the repository to the directory > > ".testadd.tmp" in the current directory and applies the staged > > chenges there (unless -u/--unmodified or -p/--pristine is > > specified), chdirs to the same relative directory in the clone and > > executes the command specified on the command line there. > > So in short, this solves the same problem as "git stash --keep" but in > a more scalable way, in the sense that "git stash --keep" allows you > to instantiate what you have in the index so that your working tree > can be used for such a test, but you cannot do anything else while you > are waiting for the test to finish, and "testadd" allows you to keep > hacking in the working tree while a test runs in its own temporary > checkout (and presumably you can have more than one running, which > would allow you to scale more)? That's correct, the test clone is entirely separated from the working copy, and you can keep working while the tests are running in the clone. Combined with git-gui and/or "git add -p/git reset -p", it's easy to tweak the staged changes until things are ok. Also, there is a -l/--label option that creates a clone directory with the name ".testadd-[LABEL].tmp", so you can have several test clones at the same time, all with different staged changes. There is also a -r/--ref option that tries to apply the staged changes onto another commit, and the command will only run if the apply succeeds. Also, this won't create dangling heads like "git stash --keep" does. Øyvind -- 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
git-testadd: Execute a command with only the staged changes in Git applied
This is a script I created some weeks ago, and I've found it to be immensely useful. Here is a snippet from git-testadd --help: If you have lots of unrelated uncommitted changes in the current repository and want to split up the commit, how can you easily check if the changes passes the test suite? With all the other unrelated changes it can be hard to make sure that only relevant changes becomes part of the commit, and that they don't result in regressions. This script clones the repository to the directory ".testadd.tmp" in the current directory and applies the staged chenges there (unless -u/--unmodified or -p/--pristine is specified), chdirs to the same relative directory in the clone and executes the command specified on the command line there. The script is well-tested, and also have a test suite you can run to make sure it works on your *nix system. Place git-testadd.t in a subdirectory one level under the script location, chdir to that directory and execute "./git-testadd.t". It also works with binary files. Available from https://gitlab.com/sunny256/utils/raw/master/git-testadd https://gitlab.com/sunny256/utils/raw/master/tests/git-testadd.t It's also on GitHub, just replace "gitlab" with "github" in the URLs. And of course, ideas and patches for new functionality/fixes are always welcome. Øyvind -- 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
t5516-fetch-push.sh fails with current master (74301d6)
When building from current master (74301d6, "Sync with maint", 2015-10-20), test #75 in t5516-fetch-push.sh fails: *** t5516-fetch-push.sh *** ok 1 - setup ok 2 - fetch without wildcard [Snip 70 lines] ok 73 - fetch exact SHA1 ok 74 - shallow fetch reachable SHA1 (but not a ref), allowtipsha1inwant=true not ok 75 - deny fetch unreachable SHA1, allowtipsha1inwant=true # # mk_empty testrepo && # ( # cd testrepo && # git config uploadpack.allowtipsha1inwant $configallowtipsha1inwant && # git commit --allow-empty -m foo && # git commit --allow-empty -m bar && # git commit --allow-empty -m xyz # ) && # SHA1_1=$(git --git-dir=testrepo/.git rev-parse HEAD^^) && # SHA1_2=$(git --git-dir=testrepo/.git rev-parse HEAD^) && # SHA1_3=$(git --git-dir=testrepo/.git rev-parse HEAD) && # ( # cd testrepo && # git reset --hard $SHA1_2 && # git cat-file commit $SHA1_1 && # git cat-file commit $SHA1_3 # ) && # mk_empty shallow && # ( # cd shallow && # test_must_fail git fetch ../testrepo/.git $SHA1_3 && # test_must_fail git fetch ../testrepo/.git $SHA1_1 && # git --git-dir=../testrepo/.git config uploadpack.allowreachablesha1inwant true && # git fetch ../testrepo/.git $SHA1_1 && # git cat-file commit $SHA1_1 && # test_must_fail git cat-file commit $SHA1_2 && # git fetch ../testrepo/.git $SHA1_2 && # git cat-file commit $SHA1_2 && # test_must_fail git fetch ../testrepo/.git $SHA1_3 # ) # ok 76 - shallow fetch reachable SHA1 (but not a ref), allowtipsha1inwant=false ok 77 - deny fetch unreachable SHA1, allowtipsha1inwant=false ok 78 - fetch follows tags by default ok 79 - pushing a specific ref applies remote.$name.push as refmap ok 80 - with no remote.$name.push, it is not used as refmap ok 81 - with no remote.$name.push, upstream mapping is used ok 82 - push does not follow tags by default ok 83 - push --follow-tag only pushes relevant tags ok 84 - push --no-thin must produce non-thin pack ok 85 - pushing a tag pushes the tagged object ok 86 - push into bare respects core.logallrefupdates ok 87 - fetch into bare respects core.logallrefupdates ok 88 - receive.denyCurrentBranch = updateInstead ok 89 - updateInstead with push-to-checkout hook # failed 1 among 89 test(s) 1..89 make[2]: *** [t5516-fetch-push.sh] Error 1 make[2]: Leaving directory `/home/sunny/src/other/git/build-git/t' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/sunny/src/other/git/build-git/t' make: *** [test] Error 2 (Removed indents to reduce email wrapping) OS: Debian GNU/Linux 7.9 (wheezy) gcc (Debian 4.7.2-5) 4.7.2 Regards, Øyvind -- 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: t5516-fetch-push.sh fails with current master (74301d6)
On 21 October 2015 at 03:40, Øyvind A. Holm <su...@sunbase.org> wrote: > When building from current master (74301d6, "Sync with maint", > 2015-10-20), test #75 in t5516-fetch-push.sh fails If it's of any value, the contents from t/trash\ directory.t5516-fetch-push/ can be downloaded from <http://tmp.sunbase.org/trash_directory.t5516-fetch-push.tar.gz>. Regards, Øyvind -- 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: t5516-fetch-push.sh fails with current master (74301d6)
On 21 October 2015 at 04:01, Øyvind A. Holm <su...@sunbase.org> wrote: > On 21 October 2015 at 03:40, Øyvind A. Holm <su...@sunbase.org> wrote: > > When building from current master (74301d6, "Sync with maint", > > 2015-10-20), test #75 in t5516-fetch-push.sh fails Hm, seems as I'm unable to reproduce the failure. That's strange, I have an automated build script I've been using for years, so the build environment is unchanged from the previous builds. I'll investigate this a bit and come back if there's anything newsworthy. In the meantime, sorry about the noise. Regards, Øyvind -- 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: VCS popularity
On 1 April 2015 at 00:03, David Lang da...@lang.hm wrote: On Tue, 31 Mar 2015, Øyvind A. Holm wrote: openhub.net (formerly ohloh.net) has an interesting comparison of the number of public repositories on the net, based on searches of popular hosting services. This comparison is available at https://www.openhub.net/repositories/compare and shows an estimated market share between Bazaar, CVS, Git, Mercurial and Subversion. I've been monitoring this since 2014-08-05 to see how things were developing, and it's a good indication of the popularity of the various version control systems. number of repositories is an interesting datapoint, but activity in the repos would be far more interesting. There are a lot of repos of various types out there that haven't been touched for years. I do agree on that. Many repositories won't be deleted if they are converted to other VC systems to avoid breaking links and so on. What I found pretty interesting is the relative growth between the various systems. That's why I created the graphs that show creation of new repositories since August 2014 instead, for example https://github.com/sunny256/openhub-repositories/blob/master/graph/relative-zoom.svg - Øyvind -- 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
VCS popularity
openhub.net (formerly ohloh.net) has an interesting comparison of the number of public repositories on the net, based on searches of popular hosting services. This comparison is available at https://www.openhub.net/repositories/compare and shows an estimated market share between Bazaar, CVS, Git, Mercurial and Subversion. I've been monitoring this since 2014-08-05 to see how things were developing, and it's a good indication of the popularity of the various version control systems. I've created a repository at https://github.com/sunny256/openhub-repositories where the project scripts and data files are stored, along with graphs in SVG format. The graphs are pretty interesting: https://github.com/sunny256/openhub-repositories/blob/master/graph/relative.svg Graphs of relative growth between the various version control systems. https://github.com/sunny256/openhub-repositories/blob/master/graph/relative-zoom.svg Zoomed-in version of relative.svg. Git goes through the ceiling. https://github.com/sunny256/openhub-repositories/blob/master/graph/repos.svg Total number of repositories. - Øyvind -- 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: VCS popularity
On 1 April 2015 at 00:20, Junio C Hamano gits...@pobox.com wrote: Øyvind A. Holm su...@sunbase.org writes: The graphs are pretty interesting: https://github.com/sunny256/openhub-repositories/blob/master/graph/relative.svg Graphs of relative growth between the various version control systems. This plots us at a bit over 8000. What does this number mean, exactly? Since 2014-08-01, the number of Git repositories Ohloh knows about has grown 8000-fold? Or is it just 80-fold (8000%) growth? Or 8000 more repositories were created? Yes, relative.svg and relative-zoom.svg show the number of new repositories found by Open Hub. To be specific, these are the numbers: Bazaar: 75 CVS: 59 Git: 8230 Mercurial: 215 Subversion: 607 These numbers can of course be discussed, but as a source, I believe Open Hub should be one of the more objective ones. - Øyvind -- 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
[PATCH] git-notes.txt: Explain how to transfer notes between repos
The documentation for git notes did not mention anywhere how to transfer notes between repositories, create a section that explains this topic. Signed-off-by: Øyvind A. Holm su...@sunbase.org --- Documentation/git-notes.txt | 39 +++ 1 file changed, 39 insertions(+) diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 310f0a5..4237bec 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -264,6 +264,45 @@ prior to the merge, these will also be removed by this notes merge strategy. +TRANSFERRING NOTES ACROSS REPOSITORIES +-- + +Notes are not transferred by default when using the standard +fetch/push commands, but has be done explicitly. To fetch all notes +from a particular remote, use + + +$ git fetch origin refs/notes/*:refs/notes/* + + +`git fetch` can be configured to automatically fetch notes from a +remote with this command: + + +$ git config --add remote.origin.fetch +refs/notes/*:refs/notes/* + + +To transfer notes to a remote repository: + + +$ git push origin refs/notes/* + + +If you don't want to fetch or push all notes stored under +`refs/notes/`, replace the asterisk with the specific type of notes +you want to transfer: + + +$ git fetch origin refs/notes/commits:refs/notes/commits + + +or + + +$ git push origin refs/notes/commits + + + EXAMPLES -- 2.1.0.127.g0c72b98 -- 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: Tackling Git Limitations with Singular Large Line-seperated Plaintext files
On 30 June 2014 14:56, Jakub Narębski jna...@gmail.com wrote: Linus Torvalds wrote: .. even there, there's another issue. With enough memory, the diff itself should be fairly reasonable to do, but we do not have any sane *format* for diffing those kinds of things. The regular textual diff is line-based, and is not amenable to comparing two long lines. You'll just get a diff that says the two really long lines are different. The binary diff option should work, but it is a horrible output format, and not very helpful. It contains all the relevant data (copy this chunk from here to here), but it's then shown in a binary encoding that isn't really all that useful if you want to say what are the differences between these two chromosomes. There is also --word-diff[=mode] word-based textual diff, and I think one can abuse --word-diff-regex=regex for character-based diff... or maybe not, as regex specifies word characters, not words or word separators. Yes, I have this alias defined: dww = diff --word-diff --word-diff-regex=. It creates nice diffs on a character level. Sometimes specifying --patience to this helps. -- Øyvind -- 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
[PATCH] .gitignore: Add git-verify-commit
builtin/verify-commit.c was added in commit d07b00b (verify-commit: scriptable commit signature verification, 2014-06-23), update .gitignore to ignore the generated file. Signed-off-by: Øyvind A. Holm su...@sunbase.org --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 42294e5..edb1dcf 100644 --- a/.gitignore +++ b/.gitignore @@ -165,6 +165,7 @@ /git-upload-archive /git-upload-pack /git-var +/git-verify-commit /git-verify-pack /git-verify-tag /git-web--browse -- 2.0.1.563.g66f467c -- 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: t5150-request-pull.sh fails on newest master in Debian
On 9 July 2014 03:18, David Turner dtur...@twopensource.com wrote: On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote: On 3 July 2014 23:55, Øyvind A. Holm su...@sunbase.org wrote: When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5 (64-bit), t5150-request-pull.sh fails when compiling with [snip] FYI, t5150-request-pull.sh passes all tests now on newest master (v2.0.1-474-g72c7794) in Debian. There are two new commits on master since I wrote this, and the commit that makes things work again is 4602f1a (diff-tree: call free_commit_list() instead of duplicating its code). Reverting this commit brings the failure back. The whole thing is still a mystery to me, though. I can't see why this should have anything to do with the use of ./configure --prefix. The problem only happens when a ref with an allowed wildcard winds up on a page boundary (with the wildcard before the page boundary). This depends intricately on the details of memory allocation, so pretty much anything could make it come and go. Aha, that makes sense. Sheer luck that the results were that consistent during testing, then. Does the fix I posted work for you? If not, let me know and I'll look into it more. Sorry, didn't notice you posted that to the list. Today I learned that Gmail doesn't put mails adressed to me and the list in the inbox. :( The commit fixed it, yes. Thanks for the patch. It now works on both Debian servers. Have run all tests on one of the servers, and will repeat on other machines, too. Thanks, Øyvind -- 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] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page
On 7 July 2014 20:05, Junio C Hamano gits...@pobox.com wrote: David Turner dtur...@twopensource.com writes: When a ref crosses a memory page boundary, we restart the parsing at the beginning with the bytewise code. Pass the original flags to that code, rather than the current flags. Good. I've run the whole test suite with this patch applied, and it fixes the problem on 64-bit Debian 7.5. I probably should add: Reported-by: Øyvind A. Holm su...@sunbase.org before your sign-off. Thanks. :) Cheers, Øyvind -- 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: t5150-request-pull.sh fails on newest master in Debian
On 3 July 2014 23:55, Øyvind A. Holm su...@sunbase.org wrote: When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5 (64-bit), t5150-request-pull.sh fails when compiling with $ make configure $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ cd t $ ./t5150-request-pull.sh FYI, t5150-request-pull.sh passes all tests now on newest master (v2.0.1-474-g72c7794) in Debian. There are two new commits on master since I wrote this, and the commit that makes things work again is 4602f1a (diff-tree: call free_commit_list() instead of duplicating its code). Reverting this commit brings the failure back. The whole thing is still a mystery to me, though. I can't see why this should have anything to do with the use of ./configure --prefix. I tested several variants with and without ./configure --prefix, all tests were run several times and were reproducible every time. Was this --prefix thing just a red herring, or is it linked to this in some way? Also, the only file this commit touches is builtin/diff-tree.c, and this file hasn't been modified since 2011. Does anyone know what's going on here? Cheers, Øyvind -- 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: t5150-request-pull.sh fails on newest master in Debian
On 5 July 2014 03:58, David Turner dtur...@twopensource.com wrote: On Sat, 2014-07-05 at 02:09 +0200, Øyvind A. Holm wrote: snip The test works. Seems as there's something fishy about the use of --prefix in this specific commit (v2.0.1-472-g6f92e5f). Ok, now I can reproduce on my linode box (haven't tried it locally yet). I'll try to get a fix up once I figure out what's up. Awesome. I've done some more ./configure --prefix testing, and this is the result: # --prefix is set to non-existing directory ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f # ./t5150-request-pull.sh fails. # --prefix is set to non-existing directory, use trailing slash ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f/ # ./t5150-request-pull.sh fails. # --prefix is set to existing directory ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-442-g7fe6834 # ./t5150-request-pull.sh fails. # --prefix is set to existing directory ./configure --prefix=/usr/local # ./t5150-request-pull.sh succeeds. # --prefix is set to existing directory ./configure --prefix=/usr/local/varprg # ./t5150-request-pull.sh succeeds. # --prefix is set to non-existing directory ./configure --prefix=/usr/local/varprg/a-long-directory-name-which-does-not-exist # ./t5150-request-pull.sh succeeds. ./configure --prefix=/usr/local/varprg/git.master.a-long-directory-name-which-does-not-exist # ./t5150-request-pull.sh succeeds. So it's something with names like git.master.v2.0.1-472-g6f92e5f that ./configure --prefix is picky about. When testing this last night, I pushed the following branches to https://github.com/sunny256/git where I added all compiled files in various stages with git add -f .: t5150-fail.configure-without-prefix Succeeds. ./configure t5150-fail.configure-with-prefix Fails. ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f t5150-fail.configure-prefix-usr-local Succeeds. ./configure --prefix=/usr/local Maybe something will turn up by diffing those branches. I've got to leave for now, but will have a look at this later tonight. Cheers, Øyvind -- 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: t5150-request-pull.sh fails on newest master in Debian
On 4 July 2014 22:22, David Turner dtur...@twopensource.com wrote: On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote: When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5 (64-bit), t5150-request-pull.sh fails when compiling with $ make configure $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make $ cd t $ ./t5150-request-pull.sh Are you sure you're not running under valgrind? I can reproduce the test failures when I run under valgrind because I didn't add the right stuff to the suppression files (patch to follow). Nope, no valgrind involved here, it's not even installed on those two servers. The two server setups differ quite much, one of them I use for all kind of things, the other is a dedicated web server with not much else except Apache and some essential stuff I can't live without installed. I also just went ahead and got a Linode running Debian 7.5 (64-bit), and I still can't reproduce the problem. Now that's what I call commitment. :) Do you have any additional reproduction info that I need here? I build new gits pretty much every time Junio pushes new stuff to kernel.org, and I'm using this script which takes care of everything: https://github.com/sunny256/utils/blob/master/build-git I have a README at https://github.com/sunny256/utils/blob/master/README.build-git.md where I have listed all packages I install from apt-get before I build the thing. The script I used to test with git bisect is at https://github.com/sunny256/utils/blob/testfail.t5150-fail-g6f92e5f/testfail , it simulates what the build-git script does. The test works if I run a plain make using the standard Makefile without ./configure . Hm, interesting. When I don't use --prefix as mentioned above, just a $ make configure $ ./configure $ make $ cd t $ ./t5150-request-pull.sh The test works. Seems as there's something fishy about the use of --prefix in this specific commit (v2.0.1-472-g6f92e5f). I'll dig more into this thing now to see what's going on. Сенсорно Ваш, Øyvind -- 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: Show containing branches in log?
On 2 July 2014 16:50, Robert Dailey rcdailey.li...@gmail.com wrote: I know that with the `git branch` command I can determine which branches contain a commit. Is there a way to represent this graphically with `git log`? Sometimes I just have a commit, and I need to find out what branch contains that commit. The reason why `git branch --contains` doesn't solve this problem for me is that it names almost all branches because of merge commits. Too much ancestry has been built since this commit, so there is no way to find the closest branch that contains that commit. Is there a way to graphically see what is the nearest named ref to the specified commit in the logs? I have created a script for just this functionality which I use very often, and have created a gist with the files at https://gist.github.com/sunny256/2eb583f21e0ffcfe994f, I think it should solve your problem. It contains these files: git-wn wn means What's New and will create a visual graph of all commits which has a specified ref as ancestor. It also needs the following script, just put it into your $PATH somewhere: git-lc lc means List branches Containing this commit and generates a list of all branches containing a specified ref. The files originates from https://github.com/sunny256/utils, but I've modified them in the gist to make your life easier. :) Hope that helps, Øyvind -- 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
t5150-request-pull.sh fails on newest master in Debian
When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5
(64-bit), t5150-request-pull.sh fails when compiling with
$ make configure
$ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
$ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
$ make
$ cd t
$ ./t5150-request-pull.sh
I have attached the output of t5150-request-pull.sh, but in case the
attachment doesn't go through, I've also pasted it at
https://gist.github.com/sunny256/0f6ff7ffee26224dbe12. This happened
on two virtual servers (64 bit) hosted on Linode, with this
configuration:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 7.5 (wheezy)
Release:7.5
Codename: wheezy
$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Both servers are (of course) updated with new packages from apt-get.
The test worked on my laptop which runs Ubuntu Studio 13.10. Have tried
recompiling several times, and it fails on Debian every time.
git bisect says the bad commit is 6f92e5ff3 (Merge branch
'dt/refs-check-refname-component-sse, 2014-07-02 12:53:07 -0700), but
that's a merge. Both parent commits works, so could this be an evil
merge?
When compiling parent commit 745224e test 6 is disabled, could that be
the reason?
Parent commit a02ad88 passes all 7 tests.
Cheers,
Øyvind
*** t5150-request-pull.sh ***
not ok 1 - setup
#
#
# git init --bare upstream.git
# git init --bare downstream.git
# git clone upstream.git upstream-private
# git clone downstream.git local
#
# trash_url=file://$TRASH_DIRECTORY
# downstream_url=$trash_url/downstream.git/
# upstream_url=$trash_url/upstream.git/
#
# (
# cd upstream-private
# cat -\EOT mnemonic.txt
# Thirtey days hath November,
# Aprile, June, and September:
# EOT
# git add mnemonic.txt
# test_tick
# git commit -m \Thirty days\, a reminder of month
lengths
# git tag -m version 1 -a initial
# git push --tags origin master
# )
# (
# cd local
# git remote add upstream $trash_url/upstream.git
# git fetch upstream
# git pull upstream master
# cat -\EOT mnemonic.txt
# Of twyecescore-eightt is but eine,
# And all the remnante be thrycescore-eine.
# O’course Leap yare comes an’pynes,
# Ev’rie foure yares, gote it ryghth.
# An’twyecescore-eight is but twyecescore-nyne.
# EOT
# git add mnemonic.txt
# test_tick
# git commit -m More detail
# git tag -m version 2 -a full
# git checkout -b simplify HEAD^
# mv mnemonic.txt mnemonic.standard
# cat -\EOT mnemonic.clarified
# Thirty days has September,
# All the rest I can’t remember.
# EOT
# git add -N mnemonic.standard mnemonic.clarified
# git commit -a -m Adapt to use modern, simpler English
#
# But keep the old version, too, in case some people prefer it.
# git checkout master
# )
#
#
ok 2 - setup: two scripts for reading pull requests
not ok 3 - pull request when forgot to push
#
#
# rm -fr downstream.git
# git init --bare downstream.git
# (
# cd local
# git checkout initial
# git merge --ff-only master
# test_must_fail git request-pull initial
$downstream_url \
# 2../err
# )
# grep No match for commit .* err
# grep Are you sure you pushed err
#
#
not ok 4 - pull request after push
#
#
# rm -fr downstream.git
# git init --bare downstream.git
# (
# cd local
# git checkout initial
# git merge --ff-only master
# git push origin master:for-upstream
# git request-pull initial origin master:for-upstream
../request
# )
# sed -nf read-request.sed request digest
# cat digest
# {
# read task
# read repository
# read branch
# } digest
# (
# cd
Re: t5150-request-pull.sh fails on newest master in Debian
On 3 July 2014 23:55, Øyvind A. Holm su...@sunbase.org wrote: When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5 (64-bit), t5150-request-pull.sh fails when compiling with $ make configure $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make $ cd t $ ./t5150-request-pull.sh That's a copy+paste error, ignore the second make. :-P Cheers, Øyvind -- 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: t5150-request-pull.sh fails on newest master in Debian
On 4 July 2014 00:34, Øyvind A. Holm su...@sunbase.org wrote: On 4 July 2014 00:16, David Turner dtur...@twopensource.com wrote: On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote: When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5 (64-bit), t5150-request-pull.sh fails when compiling with [...] Interesting! I wonder if the problem is with the compiler or with my code. I don't happen to have a Debian box handy; would it be possible for you to compile refs.c to assembly language (gcc -S) and send me the output? That would help me track down the problem. Sure! I have attached refs.s from v2.0.1-472-g6f92e5f . If someone else is interested in the assembly output, it's available from http://sunbase.org/t5150-fail/refs.s.gz. Didn't send it to the list, it's 128KB. Cheers again, Øyvind -- 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
[PATCH] RelNotes/2.0.0: Grammar and typo fixes
Signed-off-by: Øyvind A. Holm su...@sunbase.org
---
Documentation/RelNotes/2.0.0.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/RelNotes/2.0.0.txt b/Documentation/RelNotes/2.0.0.txt
index e6911ac..35e353e 100644
--- a/Documentation/RelNotes/2.0.0.txt
+++ b/Documentation/RelNotes/2.0.0.txt
@@ -68,7 +68,7 @@ UI, Workflows Features
e.g. key-id in --gpg-sign=key-id).
* The pattern to find where the function begins in C/C++ used in
- diff and grep -p have been updated to help C++ source better.
+ diff and grep -p has been updated to help C++ source better.
* git rebase learned to interpret a lone - as @{-1}, the
branch that we were previously on.
@@ -98,7 +98,7 @@ UI, Workflows Features
tree-wide operation even when run inside a subdirectory of a
working tree.
- * git add path is the same as git add -A path now.
+ * git add path is the same as git add -A path now.
* core.statinfo configuration variable, which is a
never-advertised synonym to core.checkstat, has been removed.
@@ -137,7 +137,7 @@ UI, Workflows Features
* git pull can be told to only accept fast-forward by setting the
new pull.ff configuration.
- * git reset learned -N option, which does not reset the index
+ * git reset learned the -N option, which does not reset the index
fully for paths the index knows about but the tree-ish the command
resets to does not (these paths are kept as intend-to-add entries).
@@ -156,11 +156,11 @@ Performance, Internal Implementation, etc.
easy interface.
* The bitmap-index feature from JGit has been ported, which should
- significantly improve performance when serving objects form a
+ significantly improve performance when serving objects from a
repository that uses it.
* The way git log --cc shows a combined diff against multiple
- parents have been optimized.
+ parents has been optimized.
* The prefixcmp() and suffixcmp() functions are gone. Use
starts_with() and ends_with(), and also consider if skip_prefix()
--
2.0.0.rc2
--
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: Handling empty directories in Git
On 8 April 2014 16:47, Olivier LE ROY olivier_le_...@yahoo.com wrote: Hello, I have a project under SVN with contains empty directories. I would like to move this project on a Git server, still handling empty directories. The solution: put a .gitignore file in each empty directory to have them recognized by the Git database cannot work, because some scripts in my projects test the actual emptiness of the directories. Is there any expert able to tell me: this cannot be done in Git, or this can be done by the following trick, or why there is no valuable reason to maintain empty directories under version control? Git doesn't support storage of empty directories, but there are ways around it. As you say, you could place empty files in every directory, but I've never liked this concept. Instead, I use a couple of scripts to store/restore empty directories: https://gist.github.com/sunny256/419015 This creates a file called .emptydirs at the top of the repo, and it can easily be implemented into scripts and build processes. Greetings, Øyvind -- 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
10000 tests
So this showed up after running the test suite of current master at v1.8.2.1-501-gd2949c7: fixed 0 success 9838 failed 0 broken 83 total 1 Ten thousand tests is worth celebrating. Congratulations! :) Regards, Øyvind -- 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: What's cooking in git.git (Apr 2013, #05; Mon, 15)
On 16 April 2013 01:25, Jeff King p...@peff.net wrote: On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote: [Graduated to master] [...] * jk/http-error-messages (2013-04-06) 9 commits (merged to 'next' on 2013-04-11 at 7a03981) [...] ...the tip of your current master does not currently pass the test suite[1]. [...] [1] I know you always test master before pushing it out, but I suspect you do not run the GIT_TEST_HTTPD tests. The failures are in t5541 and t5551. Ah, that explains why the test suite passed here, I built a new version an hour ago from current master (v1.8.2.1-418-gaec3f77, 2013-04-15 12:45:15 -0700), and no errors were found. I build new gits almost every day for testing purposes (master, and next and maint very often) on several machines with different setups, and of course also to have the newest version. I'd like to run as many tests as possible. Is there any list of environment variables or make directives available to enable most of them? Regards, Øyvind -- 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
[PATCH] configure.ac: Add missing comma to CC_LD_DYNPATH
From: Øyvind A. Holm su...@sunbase.org
40bfbde (build: don't duplicate substitution of make variables,
2012-09-11) breaks make by removing a necessary comma at the end of
CC_LD_DYNPATH=-rpath in line 414.
When executing ./configure --with-zlib=PATH, this resulted in
[...]
CC xdiff/xhistogram.o
AR xdiff/lib.a
LINK git-credential-store
/usr/bin/ld: bad -rpath option
collect2: ld returned 1 exit status
make: *** [git-credential-store] Error 1
$
during make.
Signed-off-by: Øyvind A. Holm su...@sunbase.org
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index da1f41f..c85888c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -411,7 +411,7 @@ else
LDFLAGS=${SAVE_LDFLAGS}
])
if test $git_cv_ld_wl_rpath = yes; then
- CC_LD_DYNPATH=-Wl,-rpath
+ CC_LD_DYNPATH=-Wl,-rpath,
else
AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
SAVE_LDFLAGS=${LDFLAGS}
--
1.8.0.rc0.18.gf84667d
--
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
[PATCH] configure.ac: Add missing comma to CC_LD_DYNPATH
From: Øyvind A. Holm su...@sunbase.org
40bfbde (build: don't duplicate substitution of make variables,
2012-09-11) breaks make by removing a necessary comma at the end of
CC_LD_DYNPATH=-rpath in line 414 and 423.
When executing ./configure --with-zlib=PATH, this resulted in
[...]
CC xdiff/xhistogram.o
AR xdiff/lib.a
LINK git-credential-store
/usr/bin/ld: bad -rpath option
collect2: ld returned 1 exit status
make: *** [git-credential-store] Error 1
$
during make.
Signed-off-by: Øyvind A. Holm su...@sunbase.org
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index da1f41f..ea79ea2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -411,7 +411,7 @@ else
LDFLAGS=${SAVE_LDFLAGS}
])
if test $git_cv_ld_wl_rpath = yes; then
- CC_LD_DYNPATH=-Wl,-rpath
+ CC_LD_DYNPATH=-Wl,-rpath,
else
AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
SAVE_LDFLAGS=${LDFLAGS}
@@ -420,7 +420,7 @@ else
LDFLAGS=${SAVE_LDFLAGS}
])
if test $git_cv_ld_rpath = yes; then
- CC_LD_DYNPATH=-rpath
+ CC_LD_DYNPATH=-rpath,
else
CC_LD_DYNPATH=
AC_MSG_WARN([linker does not support runtime path to dynamic
libraries])
--
1.8.0.rc1
--
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] configure.ac: Add missing comma to CC_LD_DYNPATH
On 9 October 2012 19:05, Junio C Hamano gits...@pobox.com wrote: Øyvind A. Holm su...@sunbase.org writes: 40bfbde (build: don't duplicate substitution of make variables, 2012-09-11) breaks make by removing a necessary comma at the end of CC_LD_DYNPATH=-rpath in line 414 and 423. The earlier one is a cut-and-paste-error regression. Isn't the one at line 423 from before 40bfbde, though? If that is the case, I'm a bit hesitant to take that part of this patch without a second opinion. It looks like it is, yes. More accurately, from 798a945 way back in 2008. If it hasn't caused any trouble since then, it probably won't. :) The line was changed in 40bfbde, though, but AC_SUBST doesn't contain a comma, so to be on the safe side, the first patch should be used. But I made a minor copy+paste error in the commit message of that patch: CC_LD_DYNPATH=-rpath in line 414. should be CC_LD_DYNPATH=-Wl,-rpath in line 414. Just a minor, but slightly annoying detail. Regards, Øyvind -- 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
