* Re: friendlier names
From: Junio C Hamano @ 2009-01-27 19:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, David Abrahams, git
In-Reply-To: <m37i4gy2z6.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> It is a bit of pity that "git add" was overloaded to also add new
> contents and not only add new file (and its contents!), instead of
> having new command "git stage" to be porcelain version of
> "git update-index" porcelain. And perhaps "git resolved" to only
> mark resolved entries (so e.g. "git resolved ." would not add new
> files, nor add new contents of files which were not in conflict).
I do not think so.
People who are taught with various means (including "git stage" alias)
understand that you prepare the contents you want to record in the commit
you are about to make by updating the contents registered in the index aka
staging area, then you do not need "git resolved".
You resolve, you have the desired content in your work tree, and you
register the updated contents from your work tree to the index aka staging
area, in exactly the same way as you do when you want to include updated
contents for any commit.
^ permalink raw reply
* Re: Building Documentation in Cygwin
From: Junio C Hamano @ 2009-01-27 20:05 UTC (permalink / raw)
To: Tim Visher; +Cc: Tay Ray Chuan, git
In-Reply-To: <c115fd3c0901271127q2a7f0f58i59ff446060982fd7@mail.gmail.com>
Tim Visher <tim.visher@gmail.com> writes:
> On Tue, Jan 27, 2009 at 1:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> The xml toolchain has a tendency to download dtds from the original source
>> with a way for you (typically your distribution) to tell it to use a
>> locally installed version. "Can build online, fail when offline" is a
>> sign that it is not using the local copy.
>
> Sounds like we're on the same page. I'm not familiar enough with any
> of these tools to know how to do anything about that. Does anyone
> know how to explicitly inform xmlto to use a local DTD? I have it
> installed, as far as I know, via cygwin (the docbook-xml42 package)
> but I don't know how to tell xmlto about it.
>
> Thanks in advance!
I do not know how Cygwin packages things, but here is an exchange I had
with k.org admin when they updated the machine I prepare the preformatted
documentation pages and I had similar trouble.
-- >8 -- from here -- >8 --
/usr/share/sgml/docbook/xmlcatalog on master.kernel.org is empty:
$ ls -l /usr/share/sgml/docbook/xmlcatalog
-rw-r--r-- 1 root root 236 2008-06-30 06:51 /usr/share/sgml/docbook/xmlcatalog
$ cat /usr/share/sgml/docbook/xmlcatalog
<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"/>
On a good machine, however, it is much larger:
$ ls -l /usr/share/sgml/docbook/xmlcatalog
-rw-r--r-- 1 root root 7907 Jul 4 14:08 /usr/share/sgml/docbook/xmlcatalog
$ grep docbookx /usr/share/sgml/docbook/xmlcatalog
<public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN" uri="xml-dtd-4.1.2-1.0-35.fc9/docbookx.dtd"/>
<public publicId="-//OASIS//DTD DocBook XML V4.2//EN" uri="xml-dtd-4.2-1.0-35.fc9/docbookx.dtd"/>
<public publicId="-//OASIS//DTD DocBook XML V4.3//EN" uri="xml-dtd-4.3-1.0-35.fc9/docbookx.dtd"/>
<public publicId="-//OASIS//DTD DocBook XML V4.4//EN" uri="xml-dtd-4.5-1.0-35.fc9/docbookx.dtd"/>
The lack of these entries seems to cause the processing to go to the
network instead of using the files locally installed.
-- 8< -- to here -- 8< --
and a response I got from them:
-- >8 -- from here -- >8 --
Hmmm tried reinstalling docbook-dtds-1.0-35.fc9.noarch.rpm and things
seem to have showed up like your expecting - clearly a bad dependency in
the rpm. Anyway give it a whirl.
-- 8< -- to here -- 8< --
After that exchange, things did work much better.
I hope the above (words like "docbook-dtds") has enough hints for you to
find corresponding set of packages on Cygwin to additionally install or
futz with to get the formatting working.
^ permalink raw reply
* Re: [PATCH 1/6] t3404 & t3411: undo copy&paste
From: Junio C Hamano @ 2009-01-27 21:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephen Haberman, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901271845380.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Rather than copying and pasting, which is prone to lead to fixes
> missing in one version, move the fake-editor generator to t/t3404/.
>
> While at it, fix a typo that causes head-scratching: use
> ${SHELL_PATH-/bin/sh} instead of $SHELL_PATH.
I've learned to be cautious whenever I see "while at it".
> diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
> new file mode 100644
> index 0000000..8c8caab
> --- /dev/null
> +++ b/t/lib-rebase.sh
> @@ -0,0 +1,36 @@
> +#!/bin/sh
> +
> +set_fake_editor () {
> + echo "#!${SHELL_PATH-/bin_sh}" >fake-editor.sh
It is unclear why you would want to do this. It was unclear what "typo"
you were referring to in your commit log message, either.
The tests are supposed to run under the shell the user specified, so if
there is a case you found that $SHELL_PATH is unset, that is a bug we
would want to fix, and ${SHELL_PATH-/bin/sh} is sweeping the problem under
the rug to make it harder to fix, isn't it?
I would understand if it were
${SHELL_PATH?"SHELL_PATH Not Set --- bug in tests?"}
though.
Besides, it's /bin/sh, not /bin_sh ;-)
> + cat >> fake-editor.sh <<\EOF
> +case "$1" in
> +*/COMMIT_EDITMSG)
> + test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
> + test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
> + exit
> + ;;
> +esac
> +test -z "$EXPECT_COUNT" ||
> + test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
> + exit
> +test -z "$FAKE_LINES" && exit
> +grep -v '^#' < "$1" > "$1".tmp
> +rm -f "$1"
> +cat "$1".tmp
> +action=pick
> +for line in $FAKE_LINES; do
> + case $line in
> + squash|edit)
> + action="$line";;
> + *)
> + echo sed -n "${line}s/^pick/$action/p"
> + sed -n "${line}p" < "$1".tmp
> + sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
I looked at the output from this and wondered what these "sed -n" shown in
the "-v" output were about last night. I do think it is a good idea to
show what edit was done to the insn stream, but I suspect it may be easier
to read the output if you did this instead:
> + sed -n "${line}p" < "$1".tmp
> + sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
> + sed -n "${line}s/^pick/$action/p" < "$1".tmp
^ permalink raw reply
* Re: [PATCH 2/6] lib-rebase.sh: Document what set_fake_editor() does
From: Junio C Hamano @ 2009-01-27 21:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephen Haberman, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901271846340.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> rnyn
> Make it easy for other authors to use rebase tests' fake-editor.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Perhaps a very welcome addition, except that I did not find rnyn in my
dictionary, and the patch textually depends on /bin_sh bug ;-)
^ permalink raw reply
* Re: [PATCH 3/6] lib-rebase.sh: introduce test_commit() and test_merge() helpers
From: Junio C Hamano @ 2009-01-27 21:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephen Haberman, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901271847070.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This may want to live in test-lib.sh instead.
Yeah, I tend to agree.
> diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
> index cda7778..37430f3 100644
> --- a/t/lib-rebase.sh
> +++ b/t/lib-rebase.sh
> @@ -46,3 +46,29 @@ EOF
> test_set_editor "$(pwd)/fake-editor.sh"
> chmod a+x fake-editor.sh
> }
> +
> +# Call test_commit with the arguments "<message> [<file> [<contents>]]"
> +#
> +# This will commit a file with the given contents and the given commit
> +# message. It will also add a tag with <message> as name.
> +#
> +# Both <file> and <contents> default to <message>.
> +
> +test_commit () {
> + file=$2
> + test -z "$2" && file=$(echo "$1" | tr 'A-Z' 'a-z')
file=${2:-$(echo "$1" | tr 'A-Z' 'a-z')}
might be more consistent with this:
> + echo ${3-$1} > $file &&
and may be easier to read.
I'd suggest dquoting argument to echo above, i.e. "${3-$1}", and all the
references to positional arguments in the remainder of the patch, though.
> + git add $file &&
as well as "$file" here.
> + test_tick &&
> + git commit -m $1 &&
> + git tag $1
> +}
> +
> +# Call test_merge with the arguments "<message> <commit>", where <commit>
> +# can be a tag pointing to the commit-to-merge.
> +
> +test_merge () {
> + test_tick &&
> + git merge -m $1 $2 &&
> + git tag $1
> +}
> --
> 1.6.1.482.g7d54be
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 21:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: zlib, valgrind-users, Mark Brown, Jeff King, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0901271006060.3123@localhost.localdomain>
Hi,
[Cc'ed the valgrind-users list, maybe the valgrind Gods can see that our
case is pretty strange, and tell us what we do wrong.]
Note to valgrind experts: this is _not_ about the Conditional thing in
zlib, but about an uninitialized byte _in the middle_ of the zlib output
buffer.
On Tue, 27 Jan 2009, Linus Torvalds wrote:
> Hmm. The zlib faq has a note about zlib doing a conditional on
> uninitialized memory that doesn't matter, and that is what the
> suppression should be about (to avoid a warning about "Conditional jump
> or move depends on uninitialised value").
>
> But that one is documented to not matter for the actual output (zlib
> FAQ#36).
>
> It's possible that zlib really does leave padding bytes around that
> literally don't matter, and that don't get initialized. That really
> would be bad, because it means that the output of git wouldn't be
> repeatable. But I doubt this is the case - original git used to actually
> do the SHA1 over the _compressed_ data, which was admittedly a totally
> and utterly broken design (and we fixed it), but it did work. Maybe it
> worked by luck, but I somehow doubt it.
>
> Some googling did find this:
>
> http://mailman.few.vu.nl/pipermail/sysprog/2008-October/000298.html
>
> which looks very similar: an uninitialized byte in the middle of a
> deflate() packet.
>
> Anyway, I'm just going to Cc 'zlib@gzip.org', since this definitely is
> _not_ the same issue as in the FAQ, and we're not the only ones seeing it.
>
> [...]
>
> Dscho wrote:
>
> > Yet, the buffer in question is 195 bytes, stream.total_count (which
> > totally agrees with size - stream.avail_out) says it is 58 bytes, and
> > valgrind says that the byte with offset 51 is uninitialized.
>
> The thing to note here is that what we are passing in to "write_buffer()"
> is _exactly_ what zlib deflated for us:
>
> - 'compressed' is the allocation, and is what we used to initialize
> 'stream.next_out' with (at the top of the code sequence above)
>
> - 'size' is gotten from 'stream.total_out' at the end of the compression.
>
> Oh Gods of zlib, please hear our plea for clarification..
To help ye Gods, I put together this almost minimal C program:
-- snip --
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <zlib.h>
int main(int argc, char **argv)
{
const char hdr[] = {
0x74, 0x72, 0x65, 0x65, 0x20, 0x31, 0x36, 0x35,
0x00,
};
int hdrlen = sizeof(hdr);
const char buf[] = {
0x31, 0x30, 0x30, 0x36, 0x34, 0x34, 0x20, 0x66,
0x69, 0x6c, 0x65, 0x31, 0x00, 0x10, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x31, 0x30, 0x30, 0x36, 0x34, 0x34, 0x20,
0x66, 0x69, 0x6c, 0x65, 0x32, 0x00, 0x20, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x31, 0x30, 0x30, 0x36, 0x34, 0x34,
0x20, 0x66, 0x69, 0x6c, 0x65, 0x33, 0x00, 0x30,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x31, 0x30, 0x30, 0x36, 0x34,
0x34, 0x20, 0x66, 0x69, 0x6c, 0x65, 0x34, 0x00,
0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x31, 0x30, 0x30, 0x36,
0x34, 0x34, 0x20, 0x66, 0x69, 0x6c, 0x65, 0x35,
0x00, 0x50, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00,
};
int len = sizeof(buf);
z_stream stream;
unsigned char *compressed;
int size, ret, i;
FILE *out;
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, Z_BEST_SPEED);
size = 8 + deflateBound(&stream, len+hdrlen);
compressed = malloc(size);
if (!compressed)
return 1;
stream.next_out = compressed;
stream.avail_out = size;
stream.next_in = (unsigned char *)hdr;
stream.avail_in = hdrlen;
while ((ret = deflate(&stream, 0)) == Z_OK)
/* nothing */;
/* deflate() returns Z_BUF_ERROR at this point */
stream.next_in = (unsigned char *)buf;
stream.avail_in = len;
ret = deflate(&stream, Z_FINISH);
if (ret != Z_STREAM_END)
return 1;
if (deflateEnd(&stream) != Z_OK)
return 1;
out = fopen("/dev/null", "w");
fwrite(compressed + 51, 51, 1, out);
fwrite(compressed + 51, 1, 1, stderr);
fflush(out);
fclose(out);
free(compressed);
return 0;
}
-- snap --
... which produces this output...
-- snip --
==6348== Memcheck, a memory error detector.
==6348== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==6348== Using LibVEX rev exported, a library for dynamic binary translation.
==6348== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==6348== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework.
==6348== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==6348== For more details, rerun with: -v
==6348==
==6348== Use of uninitialised value of size 8
==6348== at 0x4E2FC5B: (within /usr/lib/libz.so.1.2.3.3)
==6348== by 0x4E317B6: (within /usr/lib/libz.so.1.2.3.3)
==6348== by 0x4E2DF9C: (within /usr/lib/libz.so.1.2.3.3)
==6348== by 0x4E2E654: deflate (in /usr/lib/libz.so.1.2.3.3)
==6348== by 0x400957: main (valgrind-testcase.c:60)
==6348==
==6348== Syscall param write(buf) points to uninitialised byte(s)
==6348== at 0x5103D50: write (in /lib/libc-2.6.1.so)
==6348== by 0x50A9AE2: _IO_file_write (in /lib/libc-2.6.1.so)
==6348== by 0x50A9748: (within /lib/libc-2.6.1.so)
==6348== by 0x50A9A4B: _IO_file_xsputn (in /lib/libc-2.6.1.so)
==6348== by 0x509FDBA: fwrite (in /lib/libc-2.6.1.so)
==6348== by 0x4009D7: main (valgrind-testcase.c:69)
==6348== Address 0x53da87b is 51 bytes inside a block of size 195 alloc'd
==6348== at 0x4C222CB: malloc (in /usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so)
==6348== by 0x4008D7: main (valgrind-testcase.c:45)
,==6348==
==6348== Syscall param write(buf) points to uninitialised byte(s)
==6348== at 0x5103D50: write (in /lib/libc-2.6.1.so)
==6348== by 0x50A9AE2: _IO_file_write (in /lib/libc-2.6.1.so)
==6348== by 0x50A9748: (within /lib/libc-2.6.1.so)
==6348== by 0x50A9A83: _IO_do_write (in /lib/libc-2.6.1.so)
==6348== by 0x50AA048: _IO_file_sync (in /lib/libc-2.6.1.so)
==6348== by 0x509EDB9: fflush (in /lib/libc-2.6.1.so)
==6348== by 0x4009E0: main (valgrind-testcase.c:70)
==6348== Address 0x4020000 is not stack'd, malloc'd or (recently) free'd
==6348==
==6348== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 15 from 4)
==6348== malloc/free: in use at exit: 0 bytes in 0 blocks.
==6348== malloc/free: 7 allocs, 7 frees, 268,835 bytes allocated.
==6348== For counts of detected errors, rerun with: -v
==6348== Use --track-origins=yes to see where uninitialised values come from
==6348== All heap blocks were freed -- no leaks are possible.
-- snap --
Note that the error only occurs when fwrite()ing to stderr, not
any other file.
This is with valgrind compiled from a git-svn mirror updated today, i.e.
valgrind-3.5.0.SVN.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/6] t3404 & t3411: undo copy&paste
From: Johannes Schindelin @ 2009-01-27 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Haberman, Thomas Rast, git
In-Reply-To: <7v7i4g31lj.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 27 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Rather than copying and pasting, which is prone to lead to fixes
> > missing in one version, move the fake-editor generator to t/t3404/.
> >
> > While at it, fix a typo that causes head-scratching: use
> > ${SHELL_PATH-/bin/sh} instead of $SHELL_PATH.
>
> I've learned to be cautious whenever I see "while at it".
Heh.
> > diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
> > new file mode 100644
> > index 0000000..8c8caab
> > --- /dev/null
> > +++ b/t/lib-rebase.sh
> > @@ -0,0 +1,36 @@
> > +#!/bin/sh
> > +
> > +set_fake_editor () {
> > + echo "#!${SHELL_PATH-/bin_sh}" >fake-editor.sh
>
> It is unclear why you would want to do this. It was unclear what "typo"
> you were referring to in your commit log message, either.
>
> The tests are supposed to run under the shell the user specified, so if
> there is a case you found that $SHELL_PATH is unset, that is a bug we
> would want to fix, and ${SHELL_PATH-/bin/sh} is sweeping the problem under
> the rug to make it harder to fix, isn't it?
I call the scripts directly, and I do not think it would be a good idea to
force the user to use GIT_TEST_OPTS and make when calling the script
directly is so much easier. Plus, this way I can pass "sh -x $SCRIPT"
easily.
I am really puzzled that it works, BTW. With an empty SHELL_PATH,
apparently.
> Besides, it's /bin/sh, not /bin_sh ;-)
Right. The commit message was right, at least!
> > + cat >> fake-editor.sh <<\EOF
> > +case "$1" in
> > +*/COMMIT_EDITMSG)
> > + test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
> > + test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
> > + exit
> > + ;;
> > +esac
> > +test -z "$EXPECT_COUNT" ||
> > + test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
> > + exit
> > +test -z "$FAKE_LINES" && exit
> > +grep -v '^#' < "$1" > "$1".tmp
> > +rm -f "$1"
> > +cat "$1".tmp
> > +action=pick
> > +for line in $FAKE_LINES; do
> > + case $line in
> > + squash|edit)
> > + action="$line";;
> > + *)
> > + echo sed -n "${line}s/^pick/$action/p"
> > + sed -n "${line}p" < "$1".tmp
> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
>
> I looked at the output from this and wondered what these "sed -n" shown
> in the "-v" output were about last night. I do think it is a good idea
> to show what edit was done to the insn stream, but I suspect it may be
> easier to read the output if you did this instead:
>
> > + sed -n "${line}p" < "$1".tmp
> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp
Probably. It is for debugging, anyway. As everything you only see with
-v.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/6] lib-rebase.sh: Document what set_fake_editor() does
From: Johannes Schindelin @ 2009-01-27 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Haberman, Thomas Rast, git
In-Reply-To: <7v3af431iz.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 27 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > rnyn
> > Make it easy for other authors to use rebase tests' fake-editor.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
>
> Perhaps a very welcome addition, except that I did not find rnyn in my
> dictionary, and the patch textually depends on /bin_sh bug ;-)
Oh, that? It is perfectly *snarf* normal. Just my *pucker* Tourette
syndrome kicking in.
Ciao,
Dscho
^ permalink raw reply
* git-am annoyance
From: Sverre Rabbelier @ 2009-01-27 22:07 UTC (permalink / raw)
To: Git Mailinglist
Heya,
Observe what happens if, on accident, rather than running a alias
(amendall), the 'tab' didn't catch on:
$ git am
^C
$ # ok, now what do I do?
$ git status
# On branch checker-caching
nothing to commit (working directory clean)
$ # looks like everything is ok, great
$ # ... some time later
$ # same thing happens
$ git am
cat: /home/sverre/code/Melange/.git/rebase-apply/next: No such file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/utf8: No such file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/keep: No such file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/threeway: No such
file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/apply-opt: No such
file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/sign: No such file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/next: No such file or directory
/usr/local/libexec/git-core//git-am: line 319: test: : integer
expression expected
/usr/local/libexec/git-core//git-am: line 326: test: : integer
expression expected
$ # whoops?!
Wouldn't it be nice if "git am" without any arguments just prints a
usage message? Either that, or provides you with a way to bail out? Or
if it'd clean up after itself so that it doesn't crash?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Charles Bailey @ 2009-01-27 22:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git
In-Reply-To: <20090126225835.GB10118@mit.edu>
On Mon, Jan 26, 2009 at 05:58:35PM -0500, Theodore Tso wrote:
> I was the original author of mergetool, and for a while I was the
> person that was reviewing and managing the mergetool patches for
> Junio. Unfortunately, in the last couple of months I just haven't had
> the time keep up with the various mergetool proposed patch updates.
>
> So maybe it's time for me to hand it off to someone who has the time
> and interest in continuing to hack mergetool, and has the necessary
> "good taste" and such that Junio would be willing to trust that person
> to be the git mergetool patch wrangler?
>
> - Ted
A quick blame session has shown that after Ted I've probably touched
the next most number of lines of mergetool. It's a crude measure and
not necessarily a sign of competence, I admit.
Although not rolling in spare time, I feel I'd be able review
mergetool patches at roughly the rate that they tend to appear at the
moment.
Given the above, if I pass the "good taste" and "Junio trust" tests I
feel that I should offer my services as mergetool patch wrangler.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Nanako Shiraishi @ 2009-01-27 22:10 UTC (permalink / raw)
To: Stephen Haberman
Cc: Johannes Schindelin, git, spearce, Thomas Rast, Bjrn Steinbrink
In-Reply-To: <20090127092117.d13f24e7.stephen@exigencecorp.com>
Quoting Stephen Haberman <stephen@exigencecorp.com>:
> My primary pain point with rebase-i-p has been rebasing a branch that
> has merged in another branch that has a lot of commits on it. E.g.:
>
> a -- b -- c origin/feature
> \
> d -- e feature
> /
> ... g origin/master
>
> Where e is merging in, say, a latest release that had a few hundred
> commits in the master branch. After resolving conflicts/etc. in e, I
> want to rebase d..e from a to be on c.
Sorry for asking a basic question, but if "feature" is a topic branch for advance the feature, why are you merging origin/master into it? Doesn't it blur the theme of the branch by including "development of the feature and all the random things that happened while it was being developed in other places"?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [EGIT PATCH] Throw created exception
From: Robin Rosenberg @ 2009-01-27 22:11 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../org/spearce/jgit/lib/UnpackedObjectLoader.java | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/UnpackedObjectLoader.java b/org.spearce.jgit/src/org/spearce/jgit/lib/UnpackedObjectLoader.java
index 0560c3a..f2cae87 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/UnpackedObjectLoader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/UnpackedObjectLoader.java
@@ -89,7 +89,7 @@ public UnpackedObjectLoader(final Repository db, final AnyObjectId id)
/**
* Construct an ObjectLoader from a loose object's compressed form.
- *
+ *
* @param compressed
* entire content of the loose object file.
* @throws CorruptObjectException
@@ -187,7 +187,7 @@ private void decompress(final AnyObjectId id, final Inflater inf, int p)
throw coe;
}
if (p != objectSize)
- new CorruptObjectException(id, "incorrect length");
+ throw new CorruptObjectException(id, "incorrect length");
}
public int getType() {
--
1.6.1.285.g35d8b
^ permalink raw reply related
* Re: git-am annoyance
From: Junio C Hamano @ 2009-01-27 22:30 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0901271407i4406d5e6u6db1df9e5a7bdc4f@mail.gmail.com>
Sverre Rabbelier <alturin@gmail.com> writes:
> Observe what happens if, on accident, rather than running a alias
> (amendall), the 'tab' didn't catch on:
> $ git am
> ^C
It wants to read from the stdin as "git am < mbox" is a valid usage.
A patch to detect that the input was killed with ^C and clean things up
would be welcome. Also we may be able to detect "-t 0", too.
> $ # ok, now what do I do?
Here is one thing you could do.
$ PS1=': $(__git_ps1 "%s"); '
: master|AM/REBASE;
: master|AM/REBASE; git am --abort
But you are right. We should be able to detect this.
I think it was just people who often use "am" are so used to correctly the
command that the state where no state files are created didn't happen
often and never reported the breakage.
^ permalink raw reply
* [PATCH v2 0/6] rebase simplifications
From: Johannes Schindelin @ 2009-01-27 22:34 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <7v7i4g31lj.fsf@gitster.siamese.dyndns.org>
Changes vs v1:
removed the "rnyn" blurt (which probably marsk me as Alpine user...)
removed the SHELL_PATH handling; it is a miracle to me why it works, but
I'd rather not meddle with the magic now that you pointed it out
Moved test_commit and test_merge into test-lib.sh
Fixed the quoting in test_commit and test_merge
AFAIR that's all...
Johannes Schindelin (6):
t3404 & t3411: undo copy&paste
lib-rebase.sh: Document what set_fake_editor() does
test-lib.sh: introduce test_commit() and test_merge() helpers
Simplify t3410
Simplify t3411
Simplify t3412
t/README | 18 ++++
t/lib-rebase.sh | 48 +++++++++++
t/t3404-rebase-interactive.sh | 37 +--------
t/t3410-rebase-preserve-dropped-merges.sh | 124 ++++++++---------------------
t/t3411-rebase-preserve-around-merges.sh | 103 +++++-------------------
t/t3412-rebase-root.sh | 28 ++-----
t/test-lib.sh | 26 ++++++
7 files changed, 159 insertions(+), 225 deletions(-)
create mode 100644 t/lib-rebase.sh
^ permalink raw reply
* [PATCH v2 1/6] t3404 & t3411: undo copy&paste
From: Johannes Schindelin @ 2009-01-27 22:34 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <7v7i4g31lj.fsf@gitster.siamese.dyndns.org>
Rather than copying and pasting, which is prone to lead to fixes
missing in one version, move the fake-editor generator to t/t3404/.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/lib-rebase.sh | 36 ++++++++++++++++++++++++++++
t/t3404-rebase-interactive.sh | 37 +++--------------------------
t/t3411-rebase-preserve-around-merges.sh | 38 +++--------------------------
3 files changed, 44 insertions(+), 67 deletions(-)
create mode 100644 t/lib-rebase.sh
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
new file mode 100644
index 0000000..762ffcf
--- /dev/null
+++ b/t/lib-rebase.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+set_fake_editor () {
+ echo "#!$SHELL_PATH" >fake-editor.sh
+ cat >> fake-editor.sh <<\EOF
+case "$1" in
+*/COMMIT_EDITMSG)
+ test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
+ test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
+ exit
+ ;;
+esac
+test -z "$EXPECT_COUNT" ||
+ test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
+ exit
+test -z "$FAKE_LINES" && exit
+grep -v '^#' < "$1" > "$1".tmp
+rm -f "$1"
+cat "$1".tmp
+action=pick
+for line in $FAKE_LINES; do
+ case $line in
+ squash|edit)
+ action="$line";;
+ *)
+ echo sed -n "${line}s/^pick/$action/p"
+ sed -n "${line}p" < "$1".tmp
+ sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
+ action=pick;;
+ esac
+done
+EOF
+
+ test_set_editor "$(pwd)/fake-editor.sh"
+ chmod a+x fake-editor.sh
+}
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 2cc8e7a..3592403 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -10,6 +10,10 @@ that the result still makes sense.
'
. ./test-lib.sh
+. ../lib-rebase.sh
+
+set_fake_editor
+
# set up two branches like this:
#
# A - B - C - D - E
@@ -61,39 +65,6 @@ test_expect_success 'setup' '
git tag I
'
-echo "#!$SHELL_PATH" >fake-editor.sh
-cat >> fake-editor.sh <<\EOF
-case "$1" in
-*/COMMIT_EDITMSG)
- test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
- test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
- exit
- ;;
-esac
-test -z "$EXPECT_COUNT" ||
- test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
- exit
-test -z "$FAKE_LINES" && exit
-grep -v '^#' < "$1" > "$1".tmp
-rm -f "$1"
-cat "$1".tmp
-action=pick
-for line in $FAKE_LINES; do
- case $line in
- squash|edit)
- action="$line";;
- *)
- echo sed -n "${line}s/^pick/$action/p"
- sed -n "${line}p" < "$1".tmp
- sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
- action=pick;;
- esac
-done
-EOF
-
-test_set_editor "$(pwd)/fake-editor.sh"
-chmod a+x fake-editor.sh
-
test_expect_success 'no changes are a nop' '
git rebase -i F &&
test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch2" &&
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index aacfaae..6a1586a 100755
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -5,44 +5,14 @@
test_description='git rebase preserve merges
-This test runs git rebase with and tries to squash a commit from after a merge
-to before the merge.
+This test runs git rebase with -p and tries to squash a commit from after
+a merge to before the merge.
'
. ./test-lib.sh
-# Copy/paste from t3404-rebase-interactive.sh
-echo "#!$SHELL_PATH" >fake-editor.sh
-cat >> fake-editor.sh <<\EOF
-case "$1" in
-*/COMMIT_EDITMSG)
- test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
- test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
- exit
- ;;
-esac
-test -z "$EXPECT_COUNT" ||
- test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
- exit
-test -z "$FAKE_LINES" && exit
-grep -v '^#' < "$1" > "$1".tmp
-rm -f "$1"
-cat "$1".tmp
-action=pick
-for line in $FAKE_LINES; do
- case $line in
- squash|edit)
- action="$line";;
- *)
- echo sed -n "${line}s/^pick/$action/p"
- sed -n "${line}p" < "$1".tmp
- sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
- action=pick;;
- esac
-done
-EOF
+. ../lib-rebase.sh
-test_set_editor "$(pwd)/fake-editor.sh"
-chmod a+x fake-editor.sh
+set_fake_editor
# set up two branches like this:
#
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH v2 2/6] lib-rebase.sh: Document what set_fake_editor() does
From: Johannes Schindelin @ 2009-01-27 22:34 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <7v7i4g31lj.fsf@gitster.siamese.dyndns.org>
Make it easy for other authors to use rebase tests' fake-editor.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/lib-rebase.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 762ffcf..260a231 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -1,5 +1,17 @@
#!/bin/sh
+# After setting the fake editor with this function, you can
+#
+# - override the commit message with $FAKE_COMMIT_MESSAGE,
+# - amend the commit message with $FAKE_COMMIT_AMEND
+# - check that non-commit messages have a certain line count with $EXPECT_COUNT
+# - rewrite a rebase -i script with $FAKE_LINES in the form
+#
+# "[<lineno1>] [<lineno2>]..."
+#
+# If a line number is prefixed with "squash" or "edit", the respective line's
+# command will be replaced with the specified one.
+
set_fake_editor () {
echo "#!$SHELL_PATH" >fake-editor.sh
cat >> fake-editor.sh <<\EOF
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH v2 3/6] test-lib.sh: introduce test_commit() and test_merge() helpers
From: Johannes Schindelin @ 2009-01-27 22:34 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <7v7i4g31lj.fsf@gitster.siamese.dyndns.org>
Often we just need to add a commit with a given (short) name, that will
be tagged with the same name. Now, relatively complicated graphs can be
constructed easily and in a clear fashion:
test_commit A &&
test_commit B &&
git checkout A &&
test_commit C &&
test_merge D B
will construct this graph:
A - B
\ \
C - D
For simplicity, files whose name is the lower case version of the commit
message (to avoid a warning about ambiguous names) will be committed, with
the corresponding commit messages as contents.
If you need to provide a different file/different contents, you can use
the more explicit form
test_commit $MESSAGE $FILENAME $CONTENTS
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/README | 18 ++++++++++++++++++
t/test-lib.sh | 25 +++++++++++++++++++++++++
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index 8f12d48..f208cf1 100644
--- a/t/README
+++ b/t/README
@@ -212,6 +212,24 @@ library for your script to use.
is to summarize successes and failures in the test script and
exit with an appropriate error code.
+ - test_tick
+
+ Make commit and tag names consistent by setting the author and
+ committer times to defined stated. Subsequent calls will
+ advance the times by a fixed amount.
+
+ - test_commit <message> [<filename> [<contents>]]
+
+ Creates a commit with the given message, committing the given
+ file with the given contents (default for both is to reuse the
+ message string), and adds a tag (again reusing the message
+ string as name). Calls test_tick to make the SHA-1s
+ reproducible.
+
+ - test_merge <message> <commit-or-tag>
+
+ Merges the given rev using the given message. Like test_commit,
+ creates a tag and calls test_tick before committing.
Tips for Writing Tests
----------------------
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 41d5a59..c1839f7 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -193,6 +193,31 @@ test_tick () {
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
}
+# Call test_commit with the arguments "<message> [<file> [<contents>]]"
+#
+# This will commit a file with the given contents and the given commit
+# message. It will also add a tag with <message> as name.
+#
+# Both <file> and <contents> default to <message>.
+
+test_commit () {
+ file=${2:-$(echo "$1" | tr 'A-Z' 'a-z')}
+ echo "${3-$1}" > "$file" &&
+ git add "$file" &&
+ test_tick &&
+ git commit -m "$1" &&
+ git tag "$1"
+}
+
+# Call test_merge with the arguments "<message> <commit>", where <commit>
+# can be a tag pointing to the commit-to-merge.
+
+test_merge () {
+ test_tick &&
+ git merge -m "$1" "$2" &&
+ git tag "$1"
+}
+
# You are not expected to call test_ok_ and test_failure_ directly, use
# the text_expect_* functions instead.
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH v2 4/6] Simplify t3410
From: Johannes Schindelin @ 2009-01-27 22:34 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <7v7i4g31lj.fsf@gitster.siamese.dyndns.org>
Use test_commit() and test_merge(), reducing the code while making the
intent clearer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t3410-rebase-preserve-dropped-merges.sh | 124 ++++++++---------------------
1 files changed, 35 insertions(+), 89 deletions(-)
diff --git a/t/t3410-rebase-preserve-dropped-merges.sh b/t/t3410-rebase-preserve-dropped-merges.sh
index 5816415..c49143a 100755
--- a/t/t3410-rebase-preserve-dropped-merges.sh
+++ b/t/t3410-rebase-preserve-dropped-merges.sh
@@ -22,47 +22,17 @@ rewritten.
# where B, D and G touch the same file.
test_expect_success 'setup' '
- : > file1 &&
- git add file1 &&
- test_tick &&
- git commit -m A &&
- git tag A &&
- echo 1 > file1 &&
- test_tick &&
- git commit -m B file1 &&
- : > file2 &&
- git add file2 &&
- test_tick &&
- git commit -m C &&
- echo 2 > file1 &&
- test_tick &&
- git commit -m D file1 &&
- : > file3 &&
- git add file3 &&
- test_tick &&
- git commit -m E &&
- git tag E &&
- git checkout -b branch1 A &&
- : > file4 &&
- git add file4 &&
- test_tick &&
- git commit -m F &&
- git tag F &&
- echo 3 > file1 &&
- test_tick &&
- git commit -m G file1 &&
- git tag G &&
- : > file5 &&
- git add file5 &&
- test_tick &&
- git commit -m H &&
- git tag H &&
- git checkout -b branch2 F &&
- : > file6 &&
- git add file6 &&
- test_tick &&
- git commit -m I &&
- git tag I
+ test_commit A file1 &&
+ test_commit B file1 1 &&
+ test_commit C file2 &&
+ test_commit D file1 2 &&
+ test_commit E file3 &&
+ git checkout A &&
+ test_commit F file4 &&
+ test_commit G file1 3 &&
+ test_commit H file5 &&
+ git checkout F &&
+ test_commit I file6
'
# A - B - C - D - E
@@ -72,68 +42,44 @@ test_expect_success 'setup' '
# I -- G2 -- J -- K I -- K
# G2 = same changes as G
test_expect_success 'skip same-resolution merges with -p' '
- git checkout branch1 &&
+ git checkout H &&
! git merge E &&
- echo 23 > file1 &&
- git add file1 &&
- git commit -m L &&
- git checkout branch2 &&
- echo 3 > file1 &&
- git commit -a -m G2 &&
+ test_commit L file1 23 &&
+ git checkout I &&
+ test_commit G2 file1 3 &&
! git merge E &&
- echo 23 > file1 &&
- git add file1 &&
- git commit -m J &&
- echo file7 > file7 &&
- git add file7 &&
- git commit -m K &&
- GIT_EDITOR=: git rebase -i -p branch1 &&
- test $(git rev-parse branch2^^) = $(git rev-parse branch1) &&
+ test_commit J file1 23 &&
+ test_commit K file7 file7 &&
+ git rebase -i -p L &&
+ test $(git rev-parse HEAD^^) = $(git rev-parse L) &&
test "23" = "$(cat file1)" &&
- test "" = "$(cat file6)" &&
- test "file7" = "$(cat file7)" &&
-
- git checkout branch1 &&
- git reset --hard H &&
- git checkout branch2 &&
- git reset --hard I
+ test "I" = "$(cat file6)" &&
+ test "file7" = "$(cat file7)"
'
# A - B - C - D - E
# \ \ \
-# F - G - H -- L \ --> L
-# \ | \
-# I -- G2 -- J -- K I -- G2 -- K
+# F - G - H -- L2 \ --> L2
+# \ | \
+# I -- G3 --- J2 -- K2 I -- G3 -- K2
# G2 = different changes as G
test_expect_success 'keep different-resolution merges with -p' '
- git checkout branch1 &&
+ git checkout H &&
! git merge E &&
- echo 23 > file1 &&
- git add file1 &&
- git commit -m L &&
- git checkout branch2 &&
- echo 4 > file1 &&
- git commit -a -m G2 &&
+ test_commit L2 file1 23 &&
+ git checkout I &&
+ test_commit G3 file1 4 &&
! git merge E &&
- echo 24 > file1 &&
- git add file1 &&
- git commit -m J &&
- echo file7 > file7 &&
- git add file7 &&
- git commit -m K &&
- ! GIT_EDITOR=: git rebase -i -p branch1 &&
+ test_commit J2 file1 24 &&
+ test_commit K2 file7 file7 &&
+ test_must_fail git rebase -i -p L2 &&
echo 234 > file1 &&
git add file1 &&
- GIT_EDITOR=: git rebase --continue &&
- test $(git rev-parse branch2^^^) = $(git rev-parse branch1) &&
+ git rebase --continue &&
+ test $(git rev-parse HEAD^^^) = $(git rev-parse L2) &&
test "234" = "$(cat file1)" &&
- test "" = "$(cat file6)" &&
- test "file7" = "$(cat file7)" &&
-
- git checkout branch1 &&
- git reset --hard H &&
- git checkout branch2 &&
- git reset --hard I
+ test "I" = "$(cat file6)" &&
+ test "file7" = "$(cat file7)"
'
test_done
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH v2 6/6] Simplify t3412
From: Johannes Schindelin @ 2009-01-27 22:35 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <7v7i4g31lj.fsf@gitster.siamese.dyndns.org>
Use the newly introduced test_commit() and test_merge() helpers.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t3412-rebase-root.sh | 28 +++++++---------------------
1 files changed, 7 insertions(+), 21 deletions(-)
diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
index 3d8ff67..9fc528f 100755
--- a/t/t3412-rebase-root.sh
+++ b/t/t3412-rebase-root.sh
@@ -7,23 +7,13 @@ Tests if git rebase --root --onto <newparent> can rebase the root commit.
. ./test-lib.sh
test_expect_success 'prepare repository' '
- echo 1 > A &&
- git add A &&
- git commit -m 1 &&
- echo 2 > A &&
- git add A &&
- git commit -m 2 &&
+ test_commit 1 A &&
+ test_commit 2 A &&
git symbolic-ref HEAD refs/heads/other &&
rm .git/index &&
- echo 3 > B &&
- git add B &&
- git commit -m 3 &&
- echo 1 > A &&
- git add A &&
- git commit -m 1b &&
- echo 4 > B &&
- git add B &&
- git commit -m 4
+ test_commit 3 B &&
+ test_commit 1b A 1 &&
+ test_commit 4 B
'
test_expect_success 'rebase --root expects --onto' '
@@ -103,9 +93,7 @@ test_expect_success 'pre-rebase got correct input (5)' '
test_expect_success 'set up merge history' '
git checkout other^ &&
git checkout -b side &&
- echo 5 > C &&
- git add C &&
- git commit -m 5 &&
+ test_commit 5 C &&
git checkout other &&
git merge side
'
@@ -132,9 +120,7 @@ test_expect_success 'set up second root and merge' '
git symbolic-ref HEAD refs/heads/third &&
rm .git/index &&
rm A B C &&
- echo 6 > D &&
- git add D &&
- git commit -m 6 &&
+ test_commit 6 D &&
git checkout other &&
git merge third
'
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH v2 5/6] Simplify t3411
From: Johannes Schindelin @ 2009-01-27 22:35 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <7v7i4g31lj.fsf@gitster.siamese.dyndns.org>
Use test_commit() and test_merge(). This way, it is harder to forget to
tag, or to call test_tick before committing.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t3411-rebase-preserve-around-merges.sh | 65 ++++++++----------------------
1 files changed, 17 insertions(+), 48 deletions(-)
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index 6a1586a..6533505 100755
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -21,27 +21,13 @@ set_fake_editor
# -- C1 --
test_expect_success 'setup' '
- touch a &&
- touch b &&
- git add a &&
- git commit -m A1 &&
- git tag A1
- git add b &&
- git commit -m B1 &&
- git tag B1 &&
- git checkout -b branch &&
- touch c &&
- git add c &&
- git commit -m C1 &&
- git checkout master &&
- touch d &&
- git add d &&
- git commit -m D1 &&
- git merge branch &&
- touch f &&
- git add f &&
- git commit -m F1 &&
- git tag F1
+ test_commit A1 &&
+ test_commit B1 &&
+ test_commit C1 &&
+ git reset --hard B1 &&
+ test_commit D1 &&
+ test_merge E1 C1 &&
+ test_commit F1
'
# Should result in:
@@ -52,7 +38,7 @@ test_expect_success 'setup' '
#
test_expect_success 'squash F1 into D1' '
FAKE_LINES="1 squash 3 2" git rebase -i -p B1 &&
- test "$(git rev-parse HEAD^2)" = "$(git rev-parse branch)" &&
+ test "$(git rev-parse HEAD^2)" = "$(git rev-parse C1)" &&
test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" &&
git tag E2
'
@@ -70,32 +56,15 @@ test_expect_success 'squash F1 into D1' '
# And rebase G1..M1 onto E2
test_expect_success 'rebase two levels of merge' '
- git checkout -b branch2 A1 &&
- touch g &&
- git add g &&
- git commit -m G1 &&
- git checkout -b branch3 &&
- touch h
- git add h &&
- git commit -m H1 &&
- git checkout -b branch4 &&
- touch i &&
- git add i &&
- git commit -m I1 &&
- git tag I1 &&
- git checkout branch3 &&
- touch j &&
- git add j &&
- git commit -m J1 &&
- git merge I1 --no-commit &&
- git commit -m K1 &&
- git tag K1 &&
- git checkout branch2 &&
- touch l &&
- git add l &&
- git commit -m L1 &&
- git merge K1 --no-commit &&
- git commit -m M1 &&
+ test_commit G1 &&
+ test_commit H1 &&
+ test_commit I1 &&
+ git checkout -b branch3 H1 &&
+ test_commit J1 &&
+ test_merge K1 I1 &&
+ git checkout -b branch2 G1 &&
+ test_commit L1 &&
+ test_merge M1 K1 &&
GIT_EDITOR=: git rebase -i -p E2 &&
test "$(git rev-parse HEAD~3)" = "$(git rev-parse E2)" &&
test "$(git rev-parse HEAD~2)" = "$(git rev-parse HEAD^2^2~2)" &&
--
1.6.1.482.g7d54be
^ permalink raw reply related
* Re: Heads up: major rebase -i -p rework coming up
From: Stephen Haberman @ 2009-01-27 22:36 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Schindelin, git, spearce, Thomas Rast, Bjrn Steinbrink
In-Reply-To: <20090128071054.6117@nanako3.lavabit.com>
> > a -- b -- c origin/feature
> > \
> > d -- e feature
> > /
> > ... g origin/master
> Sorry for asking a basic question, but if "feature" is a topic branch
> for advance the feature, why are you merging origin/master into it?
> Doesn't it blur the theme of the branch by including "development of
> the feature and all the random things that happened while it was being
> developed in other places"?
We merged origin/master because a release had just happened (e.g. master
moved from 1.0 -> 1.1), and when QA looks at origin/feature, they wanted
to see it integrated with the latest release (e.g. 1.1).
Now, granted, if feature was a private/unpublished branch, we would
rebase the entire thing (a/b/c) on top of master (g), but a/b/c has
already been published to our bug tracker, email lists, and other
developers who are collaborating on origin/feature, so between polluting
feature with a merge from master and changing the published hashes, we
chose the merge.
- Stephen
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Junio C Hamano @ 2009-01-27 22:37 UTC (permalink / raw)
To: Charles Bailey; +Cc: Theodore Tso, git
In-Reply-To: <20090127220947.GA21319@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> On Mon, Jan 26, 2009 at 05:58:35PM -0500, Theodore Tso wrote:
> ...
> A quick blame session has shown that after Ted I've probably touched
> the next most number of lines of mergetool. It's a crude measure and
> not necessarily a sign of competence, I admit.
>
> Although not rolling in spare time, I feel I'd be able review
> mergetool patches at roughly the rate that they tend to appear at the
> moment.
>
> Given the above, if I pass the "good taste" and "Junio trust" tests I
> feel that I should offer my services as mergetool patch wrangler.
Competence certainly counts to a certain extent, but volunteerism,
willingness, and enthusiasm count too.
Taste is sometimes a relative thing and we can make sure where we agree to
disagree on the list case by case basis.
Most importantly, anybody who will suffer when the tool breaks will be
much better person than I to look after it. That is one of the largest
ingredient in the "trust" factor.
Thanks.
^ permalink raw reply
* Re: git-am annoyance
From: Sverre Rabbelier @ 2009-01-27 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailinglist
In-Reply-To: <7vr62o1iww.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 23:30, Junio C Hamano <gitster@pobox.com> wrote:
> It wants to read from the stdin as "git am < mbox" is a valid usage.
Ah, ofcourse, that makes sense :).
> A patch to detect that the input was killed with ^C and clean things up
> would be welcome. Also we may be able to detect "-t 0", too.
What is '-t 0'? How would one detect this in bash?
>> $ # ok, now what do I do?
>
> Here is one thing you could do.
>
> $ PS1=': $(__git_ps1 "%s"); '
> : master|AM/REBASE;
> : master|AM/REBASE; git am --abort
Ugh, I couldn't even get that thing to work :P.
> But you are right. We should be able to detect this.
That would be nice indeed.
> I think it was just people who often use "am" are so used to correctly the
> command that the state where no state files are created didn't happen
> often and never reported the breakage.
Ok, am glad I reported it then, now it's a known issue at least.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Geoffrey Lee @ 2009-01-27 22:41 UTC (permalink / raw)
To: git
In-Reply-To: <20090127122456.0df531c3.stephen@exigencecorp.com>
On Tue, Jan 27, 2009 at 10:24 AM, Stephen Haberman
<stephen@exigencecorp.com> wrote:
> It kind of works on my Vista 64-bit system--I do not see the shell
> extensions in the native Windows Explorer (which is 64 bit), but I do
> see the shell extensions in an Explorer replacement I use (Xplorer2)
> that is 32-bit.
>
> I've seen other oddities in 32-bit vs. 64-bit programs--e.g. my alt tab
> replacement (Joe), which is 32-bit, works great with 32-bit programs
> but cannot remove focus from 64-bit programs (IE, Windows Explorer,
> etc.). Ironically, very few of the programs I use are 64-bit, so I get
> by with the alt tab replacement.
>
> - Stephen
>
Thanks! It seems that 64-bit explorer.exe will not load 32-bit shell
extensions. At least now I know I'm not going crazy. :)
-Geoffrey Lee
^ permalink raw reply
* Re: [PATCH 1/6] t3404 & t3411: undo copy&paste
From: Junio C Hamano @ 2009-01-27 22:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephen Haberman, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901272254450.14855@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > + sed -n "${line}p" < "$1".tmp
>> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
>> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp
>
>
> Probably. It is for debugging, anyway. As everything you only see with
> -v.
Exactly. That is why I'd rather want to see what exact insn sequence is
being fed to the "rebase -i". Because I'd be debugging my new test or
changes to "rebase -i", not debugging fake-editor's use of sed.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox