* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Junio C Hamano @ 2006-06-18 8:29 UTC (permalink / raw)
To: Florian Forster; +Cc: git
In-Reply-To: <1150609831500-git-send-email-octo@verplant.org>
Florian Forster <octo@verplant.org> writes:
> While most of this patch fixes void-pointer arithmetic and is therefore
> trivial, I had to change the use of a struct with FAMs in `diff-lib.c'. Since
> this is the first time I encountered FAMs it'd probably be a good idea if
> someone who knows would take a look at that.
Thanks. I am very tempted to apply it, but I started to wonder
that in some places it might make sense to convert void* to
char* instead of casting. Undecided.
> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
> index f6310b9..646322d 100644
> --- a/builtin-tar-tree.c
> +++ b/builtin-tar-tree.c
> @@ -34,7 +34,7 @@ static void reliable_write(void *buf, un
> die("git-tar-tree: disk full?");
> }
> size -= ret;
> - buf += ret;
> + buf = (char *) buf + ret;
Please do not add the extra whitespace to align "=".
> @@ -244,14 +244,14 @@ static void convert_date(void *buffer, u
> // "tree <sha1>\n"
> memcpy(new + newlen, buffer, 46);
> newlen += 46;
> - buffer += 46;
> + buffer = (char *) buffer + 46;
> size -= 46;
>
> // "parent <sha1>\n"
> while (!memcmp(buffer, "parent ", 7)) {
> memcpy(new + newlen, buffer, 48);
> newlen += 48;
> - buffer += 48;
> + buffer = (char *) buffer + 48;
> size -= 48;
> }
>
> @@ -275,11 +275,11 @@ static void convert_commit(void *buffer,
>
> if (memcmp(buffer, "tree ", 5))
> die("Bad commit '%s'", (char*) buffer);
> - convert_ascii_sha1(buffer+5);
> - buffer += 46; /* "tree " + "hex sha1" + "\n" */
> + convert_ascii_sha1((char *) buffer + 5);
> + buffer = (char *) buffer + 46; /* "tree " + "hex sha1" + "\n" */
> while (!memcmp(buffer, "parent ", 7)) {
> - convert_ascii_sha1(buffer+7);
> - buffer += 48;
> + convert_ascii_sha1((char *) buffer + 7);
> + buffer = (char *) buffer + 48;
> }
> convert_date(orig_buffer, orig_size, result_sha1);
> }
Hmmmmmmm. Now I start to wonder if changing the type of "void *buffer"
to "char *buffer" is cleaner.
> diff --git a/diff-delta.c b/diff-delta.c
> index 25a798d..8b9172a 100644
> --- a/diff-delta.c
> +++ b/diff-delta.c
> @@ -22,6 +22,7 @@ #include <stdlib.h>
> #include <string.h>
> #include "delta.h"
>
> +#include "git-compat-util.h"
>
> /* maximum hash entry list for the same hash bucket */
> #define HASH_LIMIT 64
> @@ -131,7 +132,7 @@ struct delta_index {
> const void *src_buf;
> unsigned long src_size;
> unsigned int hash_mask;
> - struct index_entry *hash[0];
> + struct index_entry *hash[FLEX_ARRAY];
> };
Good -- I missed this when we did FLEX_ARRAY. Thanks.
> diff --git a/diff-lib.c b/diff-lib.c
> index 2183b41..fdc1173 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -34,21 +34,23 @@ int run_diff_files(struct rev_info *revs
> continue;
>
> if (ce_stage(ce)) {
> - struct {
> - struct combine_diff_path p;
> - struct combine_diff_parent filler[5];
> - } combine;
I admit this part was ugly. The new code does not do any extra
allocations and matches the other use of "struct combine_diff_path"
more closely. Good change.
> @@ -1136,13 +1136,14 @@ int fetch(unsigned char *sha1)
>
> static inline int needs_quote(int ch)
> {
> - switch (ch) {
> - case '/': case '-': case '.':
> - case 'A'...'Z': case 'a'...'z': case '0'...'9':
> + if (((ch >= 'A') && (ch <= 'Z'))
> + || ((ch >= 'a') && (ch <= 'z'))
> + || ((ch >= '0') && (ch <= '9'))
> + || (ch == '/')
> + || (ch == '-')
> + || (ch == '.'))
> return 0;
> - default:
> - return 1;
> - }
> + return 1;
> }
Ugh. Delight of standard compliance X-<.
> diff --git a/http-push.c b/http-push.c
> index 2d9441e..0684e46 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -1077,13 +1077,14 @@ static int fetch_indices(void)
>
> static inline int needs_quote(int ch)
Hmph. Thanks for noticing the duplicated code; maybe move it to
cache.h perhaps?
^ permalink raw reply
* Re: [RFD] gitweb configuration
From: Timo Hirvonen @ 2006-06-18 8:30 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e731ai$su1$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> - use ~/.gitconfig, /etc/gitconfig or some other global git configuration
> file, reading values using '$gitexecdir/git-repo-config'.
> Problem: bootstraping, namely value of $gitexecdir ($gitbin now)
> needs to be set in gitweb.cgi, perhaps during the build process.
Just use "git command" and you don't have to know $gitexecdir.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Florian Forster @ 2006-06-18 8:35 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <44950E32.10904@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 264 bytes --]
Hi Rene,
On Sun, Jun 18, 2006 at 10:26:26AM +0200, Rene Scharfe wrote:
> However, could you split it up a bit?
Sure, I'll follow up on this in a short while..
-octo
--
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFD] gitweb configuration
From: Junio C Hamano @ 2006-06-18 8:38 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606180042w7b4d11dbvbea28b750ddbc6e2@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 6/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> So GIT_CONFIG would be ~/.gitconfig, and GIT_CONFIG_LOCAL would be
>> $GIT_DIR/config or what?
>
> I don't quite follow why gitweb needs a GIT_CONFIG_LOCAL defined.
> Given that it works in a CGI environment, it should read
> $GIT_DIR/config by default, and $GIT_CONFIG if set (from httpd.conf).
I am not Pasky, but I think the intent of the patch is to run
"git repo-config" with GIT_CONFIG pointing at /etc/gitweb.conf
to obtain server-wide configuration (e.g. finding out where
repositories are) and then when serving individual repository
(i.e. after we set up GIT_DIR to point at it) run "git
repo-config" without GIT_CONFIG to read per-repository
configuration. That way we can reuse the configuration parser.
^ permalink raw reply
* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Timo Hirvonen @ 2006-06-18 8:43 UTC (permalink / raw)
To: Florian Forster; +Cc: git
In-Reply-To: <20060618082103.GA1331@verplant.org>
Florian Forster <octo@verplant.org> wrote:
> GCC ignores the FAM in this case and allocates `sizeof (struct
> combine_diff_path)' bytes. However, this is not correct according to
> ANSI and prevents building using other compilers (e.g. Sun cc).
Fair enough.
> To be honest, I don't get the point of FAMs anyways. Why don't we just
> use a pointer to `struct combine_diff_parent' there in the first place?
In general FAMs are used to replace two mallocs with one.
x = malloc(sizeof(struct foo) + 100)
instead of
x = malloc(sizeof(struct foo));
x->y = malloc(100);
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] rebase: Allow merge strategies to be used when rebasing
From: Junio C Hamano @ 2006-06-18 9:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1150599735483-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> This solves the problem of rebasing local commits against an
> upstream that has renamed files.
I think leveraging the merge strategy to perform rebase is
sound, but the selection of merge base for this purpose is quite
different from the regular merge, and I think unfortunately this
patch is probably wrong in letting git-merge choose the merge
base.
But let's mention other things as well.
- You kept the original "format-patch piped to am" workflow
optionally working.
- You check if merge or patch was used for failed rebase and
follow the appropriate codepath while resuming, which is
good.
- The list of commits you generate with tac seem to include
merge commit -- you may want to give --no-merges to
rev-list.
- I do not think we use "tac" elsewhere -- is it portable
enough?
- Exiting with success unconditionally after "git am" feels
wrong. I would do "exit $?" instead of "exit 0" there.
Suppose you have this commit ancestry graph:
----------------------------------------------------------------
Example: git-rebase --onto master A topic
A---B---C topic B'--C' topic
/ --> /
D---E---F---G master D---E---F---G master
----------------------------------------------------------------
This is slightly different from the one at the beginning of the
script. The idea is A turned out to be not so cool, and we
would want to drop it.
> +call_merge () {
> + cmt="$(cat $dotest/`printf %0${prec}d $1`)"
> + echo "$cmt" > "$dotest/current"
> + git-merge $strategy_args "rebase-merge: $cmt" HEAD "$cmt" \
> + || die "$MRESOLVEMSG"
> +}
call_merge is first called with B in cmt, and HEAD is pointing
at G. But the merge in this function makes a merge between B
and G, taking the effect of E->A.
I think the three-way merge you would want here is not between B
and G using E as the pivot, but between B and G using A as the
pivot. That's how cherry-pick and revert works. I would
leverage the interface that is one level lower for this -- the
strategy modules themselves.
git-merge-$strategy $cmt^ -- HEAD $cmt
The strategy modules take merge base(s), double-dash as the
separator, our head and the other head. They do not make commit
themselves (instead they leave working tree and index in
committable state) and signal the results with their exit
status:
0 -- success
1 -- conflicts
2 -- did not handle the merge at all
^ permalink raw reply
* Re: [RFD] gitweb configuration
From: Jakub Narebski @ 2006-06-18 9:12 UTC (permalink / raw)
To: git
In-Reply-To: <20060618113052.660e1017.tihirvon@gmail.com>
Timo Hirvonen wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>
>> - use ~/.gitconfig, /etc/gitconfig or some other global git configuration
>> file, reading values using '$gitexecdir/git-repo-config'.
>> Problem: bootstraping, namely value of $gitexecdir ($gitbin now)
>> needs to be set in gitweb.cgi, perhaps during the build process.
>
> Just use "git command" and you don't have to know $gitexecdir.
First, 'git' might be not in PATH for the webserver user which runs
gitweb.cgi.
Second, I guess that '$gitexecdir/git-repo-config' is/can be faster than
'git repo-config', but if 'git' is in the PATH we can set $gitexecdir from
'git --exec-path'.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFD] gitweb configuration
From: Junio C Hamano @ 2006-06-18 9:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Timo Hirvonen
In-Reply-To: <e735d7$6dq$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Timo Hirvonen wrote:
>
>> Just use "git command" and you don't have to know $gitexecdir.
>
> First, 'git' might be not in PATH for the webserver user which runs
> gitweb.cgi.
For that we would have a chicken-and-egg problem if we make
configuration mechanism based on git-repo-config, so I would say
per-site customization is needed somehow.
Hardcoding the path into gitweb.cgi could be one way.
Hardcoding the path to gitweb per-site configuration file and
implement the logic to parse the configuration file without
using git-repo-config would be another. Even if you wanted to
use "git --exec-path" to bootstrap, not having "git" in the path
would make it, eh, cumbersome.
My gut feeling is that it is sensible to assume git is on
everybody's path -- after all the site is running gitweb and
majority would be using binary packaged distribution, so git
would be installed somewhere sensible and accessible.
So I am with Timo on this one, except that in some cases munging
gitweb.cgi script itself might be needed if the installation
chose to hide git somewhere inaccessible from ordinary users.
^ permalink raw reply
* Re: [RFD] gitweb configuration
From: Jakub Narebski @ 2006-06-18 10:05 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xnu3iol.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> So I am with Timo on this one, except that in some cases munging
> gitweb.cgi script itself might be needed if the installation
> chose to hide git somewhere inaccessible from ordinary users.
^^^^^^^^^^^^^^
The problem is with webserver user (nobody, web, apache, ...),
which might have nonstandard PATH and/or be run from jail/chroot.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFD] gitweb configuration
From: Martin Langhoff @ 2006-06-18 10:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Timo Hirvonen
In-Reply-To: <7v8xnu3iol.fsf@assigned-by-dhcp.cox.net>
On 6/18/06, Junio C Hamano <junkio@cox.net> wrote:
> My gut feeling is that it is sensible to assume git is on
> everybody's path -- after all the site is running gitweb and
> majority would be using binary packaged distribution, so git
> would be installed somewhere sensible and accessible.
+1. In the case of binary packages, the maintainer/packager can drop a
config file in /etc/apache/conf.d , so it's unlikely that munging
actually needs to happen.
cheers,
martin
^ permalink raw reply
* [PATCH 1/3] git-tar-tree: Simplify write_trailer()
From: Rene Scharfe @ 2006-06-18 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Rene Scharfe
We can write the trailer in one or at most two steps; it will always
fit within two blocks. With the last caller of get_record() gone we
can get rid of it.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-tar-tree.c | 40 +++++++++++++++-------------------------
1 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index f6310b9..f646c5b 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -47,31 +47,6 @@ static void write_if_needed(void)
}
}
-/* acquire the next record from the buffer; user must call write_if_needed() */
-static char *get_record(void)
-{
- char *p = block + offset;
- memset(p, 0, RECORDSIZE);
- offset += RECORDSIZE;
- return p;
-}
-
-/*
- * The end of tar archives is marked by 1024 nul bytes and after that
- * follows the rest of the block (if any).
- */
-static void write_trailer(void)
-{
- get_record();
- write_if_needed();
- get_record();
- write_if_needed();
- while (offset) {
- get_record();
- write_if_needed();
- }
-}
-
/*
* queues up writes, so that all our write(2) calls write exactly one
* full block; pads writes to RECORDSIZE
@@ -107,6 +82,21 @@ static void write_blocked(void *buf, uns
write_if_needed();
}
+/*
+ * The end of tar archives is marked by 2*512 nul bytes and after that
+ * follows the rest of the block (if any).
+ */
+static void write_trailer(void)
+{
+ int tail = BLOCKSIZE - offset;
+ memset(block + offset, 0, tail);
+ reliable_write(block, BLOCKSIZE);
+ if (tail < 2 * RECORDSIZE) {
+ memset(block, 0, offset);
+ reliable_write(block, BLOCKSIZE);
+ }
+}
+
static void strbuf_append_string(struct strbuf *sb, const char *s)
{
int slen = strlen(s);
--
1.4.0
^ permalink raw reply related
* [PATCH 3/3] git-tar-tree: no more void pointer arithmetic
From: Rene Scharfe @ 2006-06-18 10:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Rene Scharfe
Noticed by Florian Forster: Use a char pointer when adding offsets,
because void pointer arithmetic is a GNU extension. Const'ify the
function arguments while we're at it.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-tar-tree.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index f646c5b..03dd8be 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -22,8 +22,10 @@ static unsigned long offset;
static time_t archive_time;
/* tries hard to write, either succeeds or dies in the attempt */
-static void reliable_write(void *buf, unsigned long size)
+static void reliable_write(const void *data, unsigned long size)
{
+ const char *buf = data;
+
while (size > 0) {
long ret = xwrite(1, buf, size);
if (ret < 0) {
@@ -51,8 +53,9 @@ static void write_if_needed(void)
* queues up writes, so that all our write(2) calls write exactly one
* full block; pads writes to RECORDSIZE
*/
-static void write_blocked(void *buf, unsigned long size)
+static void write_blocked(const void *data, unsigned long size)
{
+ const char *buf = data;
unsigned long tail;
if (offset) {
--
1.4.0
^ permalink raw reply related
* [PATCH 2/3] git-tar-tree: documentation update
From: Rene Scharfe @ 2006-06-18 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Rene Scharfe
* add example on how to avoid adding a global extended pax header
* don't mention linux anymore, use git itself as an example instead
* update to v1.4.0 ;-)
* append missing :: to the examples
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/git-tar-tree.txt | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index 831537b..f2675c4 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -39,19 +39,24 @@ OPTIONS
Examples
--------
-git tar-tree HEAD | (cd /var/tmp/ && mkdir junk && tar Cxf junk -)::
+git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)::
Create a tar archive that contains the contents of the
latest commit on the current branch, and extracts it in
`/var/tmp/junk` directory.
-git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz
+git tar-tree v1.4.0 git-1.4.0 | gzip >git-1.4.0.tar.gz::
- Create a tarball for v2.6.17 release.
+ Create a tarball for v1.4.0 release.
-git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar
+git tar-tree v1.4.0{caret}\{tree\} git-1.4.0 | gzip >git-1.4.0.tar.gz::
- Get a tarball v0.99 from example.com.
+ Create a tarball for v1.4.0 release, but without a
+ global extended pax header.
+
+git tar-tree --remote=example.com:git.git v1.4.0 >git-1.4.0.tar::
+
+ Get a tarball v1.4.0 from example.com.
Author
------
--
1.4.0
^ permalink raw reply related
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Karl Hasselström @ 2006-06-18 11:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi, git, Yakov Lerner
In-Reply-To: <7vk67gbbe9.fsf@assigned-by-dhcp.cox.net>
On 2006-06-16 22:26:38 -0700, Junio C Hamano wrote:
> I do not know what "stow" is about, but if it is to allow you to run
> make-install to install things in somewhere else, examine the
> result, and then move the result to the real location (implying that
> you should be able to nuke the "somewhere else" after you have done
> so), with the patch, the above sequence would install the binaries
> pointing at a wrong directory, because the second compilation would
> make them point at the temporary installation directory
> ~/usr/stow/git, not the final location ~/usr/.
GNU stow doesn't move installed programs, it just maintains symlinks
to them. You install programs under /usr/local/stow/foo-4.7.11, and
stow sets up symlinks to them under /usr/local. (So for example,
/usr/local/bin/foo would be a symlink to
/usr/local/stow/foo-4.7.11/bin/foo.) This gives you the ability to
nuke an installed program cleanly. And it just works, pathwise, since
the program remains in its original location.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-18 11:47 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Santi, git
In-Reply-To: <20060618112404.GA2446@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> GNU stow doesn't move installed programs, it just maintains symlinks
> to them. You install programs under /usr/local/stow/foo-4.7.11, and
> stow sets up symlinks to them under /usr/local. (So for example,
> /usr/local/bin/foo would be a symlink to
> /usr/local/stow/foo-4.7.11/bin/foo.) This gives you the ability to
> nuke an installed program cleanly. And it just works, pathwise, since
> the program remains in its original location.
Thanks for the explanation.
If that's the case, I think it makes the original problem Santi
brought up a non-issue. In this sequence:
make prefix=/home/santi/usr
make install prefix=/home/santi/usr/stow/git
cd /home/santi/usr/stow/
stow -v git
the building phase could have used the same prefix as the
install phase uses, and git can find its subprograms in
gitexecdir (= ~/usr/stow/git/bin) just fine. It probably is
even slightly more efficient since it does not have to go
through the symlink stow installs.
^ permalink raw reply
* [PATCH] Add renaming-rebase test.
From: Junio C Hamano @ 2006-06-18 11:48 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1150599735483-git-send-email-normalperson@yhbt.net>
This tests Eric's "renaming rebase" patch. It tests only very
basic cases and most of the tests except the last one passes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/t3402-rebase-merge.sh | 96 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/t/t3402-rebase-merge.sh b/t/t3402-rebase-merge.sh
new file mode 100755
index 0000000..8c7a519
--- /dev/null
+++ b/t/t3402-rebase-merge.sh
@@ -0,0 +1,96 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Junio C Hamano
+#
+
+test_description='git rebase --merge test'
+
+. ./test-lib.sh
+
+T="A quick brown fox
+jumps over the lazy dog."
+for i in 1 2 3 4 5 6 7 8 9 10
+do
+ echo "$i $T"
+done >original
+
+test_expect_success setup '
+ git add original &&
+ git commit -m"initial" &&
+ git branch side &&
+ echo "11 $T" >>original &&
+ git commit -a -m"master updates a bit." &&
+
+ echo "12 $T" >>original &&
+ git commit -a -m"master updates a bit more." &&
+
+ git checkout side &&
+ (echo "0 $T" ; cat original) >renamed &&
+ git add renamed &&
+ git update-index --force-remove original &&
+ git commit -a -m"side renames and edits." &&
+
+ tr "[a-z]" "[A-Z]" <original >newfile &&
+ git add newfile &&
+ git commit -a -m"side edits further." &&
+
+ tr "[a-m]" "[A-M]" <original >newfile &&
+ rm -f original &&
+ git commit -a -m"side edits once again." &&
+
+ git branch test-rebase side &&
+ git branch test-rebase-pick side &&
+ git branch test-reference-pick side &&
+ git checkout -b test-merge side
+'
+
+test_expect_success 'reference merge' '
+ git merge -s recursive "reference merge" HEAD master
+'
+
+test_expect_success rebase '
+ git checkout test-rebase &&
+ git rebase --merge master
+'
+
+test_expect_success 'merge and rebase should match' '
+ git diff-tree -r test-rebase test-merge >difference &&
+ if test -s difference
+ then
+ cat difference
+ (exit 1)
+ else
+ echo happy
+ fi
+'
+
+test_expect_success 'rebase the other way' '
+ git reset --hard master &&
+ git rebase --merge side
+'
+
+test_expect_success 'merge and rebase should match' '
+ git diff-tree -r test-rebase test-merge >difference &&
+ if test -s difference
+ then
+ cat difference
+ (exit 1)
+ else
+ echo happy
+ fi
+'
+
+test_expect_success 'picking rebase' '
+ git reset --hard side &&
+ git rebase --merge --onto master side^^ &&
+ mb=$(git merge-base master HEAD) &&
+ if test "$mb" = "$(git rev-parse master)"
+ then
+ echo happy
+ else
+ git show-branch
+ (exit 1)
+ fi
+'
+
+test_done
--
1.4.0.g1910f
^ permalink raw reply related
* Re: What's in git.git
From: Johannes Schindelin @ 2006-06-18 12:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsh75lx1.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 17 Jun 2006, Junio C Hamano wrote:
> Read configuration also from ~/.gitconfig
> repo-config: learn the flag "--no-local"
>
> I see Pasky has proposed another config change (this time,
> not "also from" but "alternatively from") -- I am not sure
> which one is more appropriate. Waiting for Johannes's
> response to Pasky's message and hoping the list can agree on
> a single patch series to apply to "next".
There is one thing I don't like about Pasky's approach: You can change the
config file name to whatever you like, even if no program will read it.
That is why I decided to have a flag instead of an option: to prevent
pilot-errors.
But hey, that is just me.
I cobbled together a patch, which turned out to be rather messy,
introducing "--config-file <file>" to git-repo-config. If people are
interested, I'll clean it up and post it. But then, if you already know
you want to use another config file, you are probably better of just
exporting GIT_CONFIG_FILE and be done with it.
Note that this issue is orthogonal to the need for a user-specific config
file. I still think that this one should go in.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFD] gitweb configuration
From: Petr Baudis @ 2006-06-18 13:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7v64iy505x.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 18, 2006 at 10:38:02AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > On 6/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >> So GIT_CONFIG would be ~/.gitconfig, and GIT_CONFIG_LOCAL would be
> >> $GIT_DIR/config or what?
> >
> > I don't quite follow why gitweb needs a GIT_CONFIG_LOCAL defined.
> > Given that it works in a CGI environment, it should read
> > $GIT_DIR/config by default, and $GIT_CONFIG if set (from httpd.conf).
>
> I am not Pasky, but I think the intent of the patch is to run
> "git repo-config" with GIT_CONFIG pointing at /etc/gitweb.conf
> to obtain server-wide configuration (e.g. finding out where
> repositories are) and then when serving individual repository
> (i.e. after we set up GIT_DIR to point at it) run "git
> repo-config" without GIT_CONFIG to read per-repository
> configuration. That way we can reuse the configuration parser.
Yes, if $GIT_CONFIG is set, git should be guaranteed to read _no_ config
file except $GIT_CONFIG. The intent of $GIT_LOCAL_CONFIG was to make it
possible to just override the per-repo configfile location, but it just
felt nice to have - I don't insist on it so if people think it's useless
additional complexity I'm happy to say that one goodbye.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH 2/3] git-tar-tree: documentation update
From: Rene Scharfe @ 2006-06-18 13:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11506282792065-git-send-email-rene.scharfe@lsrfire.ath.cx>
> * add example on how to avoid adding a global extended pax header
> * don't mention linux anymore, use git itself as an example instead
> * update to v1.4.0 ;-)
> * append missing :: to the examples
Oops, I forgot to mention this change:
> -git tar-tree HEAD | (cd /var/tmp/ && mkdir junk && tar Cxf junk -)::
> +git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)::
>
> Create a tar archive that contains the contents of the
> latest commit on the current branch, and extracts it in
> `/var/tmp/junk` directory.
The new version features less typing and no more path duplication.
René
^ permalink raw reply
* Re: What's in git.git
From: Petr Baudis @ 2006-06-18 13:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606181417090.26803@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> There is one thing I don't like about Pasky's approach: You can change the
> config file name to whatever you like, even if no program will read it.
> That is why I decided to have a flag instead of an option: to prevent
> pilot-errors.
I'm lost here, admittelly not getting your argument. :-(
> I cobbled together a patch, which turned out to be rather messy,
> introducing "--config-file <file>" to git-repo-config. If people are
> interested, I'll clean it up and post it. But then, if you already know
> you want to use another config file, you are probably better of just
> exporting GIT_CONFIG_FILE and be done with it.
$GIT_CONFIG_FILE feels nicer since any other git tool can use it as
well, it's not git-repo-config-specific. But the current intent indeed
is to simply override the location for git-repo-config, thus for the
current purposes if we will have --config-file instead of
GIT_CONFIG_FILE, I will not weep; whatever does the job.
> Note that this issue is orthogonal to the need for a user-specific config
> file. I still think that this one should go in.
I agree as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] Make release tarballs friendlier to older tar versions
From: Rene Scharfe @ 2006-06-18 13:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
git-tar-tree adds an extended pax header to archives if its first
parameter points to a commit. It confuses older tars and isn't
very useful in the case of git anyway, so stop doing it.
Idea: Junio, implementation: Junio. I just wrote it up. :-)
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/Makefile b/Makefile
index 2a1e639..28517f4 100644
--- a/Makefile
+++ b/Makefile
@@ -667,7 +667,7 @@ git.spec: git.spec.in
GIT_TARNAME=git-$(GIT_VERSION)
dist: git.spec git-tar-tree
- ./git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar
+ ./git-tar-tree HEAD^{tree} $(GIT_TARNAME) > $(GIT_TARNAME).tar
@mkdir -p $(GIT_TARNAME)
@cp git.spec $(GIT_TARNAME)
@echo $(GIT_VERSION) > $(GIT_TARNAME)/version
^ permalink raw reply related
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Petr Baudis @ 2006-06-18 13:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yakov Lerner, git
In-Reply-To: <7vver3cxlw.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Jun 14, 2006 at 10:04:43PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - we may want to make the state file a bit more visible (IOW, I
> somewhat do mind the name being dot-git-dot-prefix).
What is the point? It is just a bit of internal build system state made
persistent and shouldn't be interesting for the user, so why give it
extra publicity in the tree?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* git 1.4.0 usability problem
From: Jeff Garzik @ 2006-06-18 13:40 UTC (permalink / raw)
To: Git Mailing List
Now that kernel 2.6.17 is out, I updated all my repositories to be based
against that kernel. And for each repository I updated, my merge was
rejected, due to an error similar to:
> fatal: Untracked working tree file '.gitignore' would be overwritten by merge.
I am only able to merge if I delete files in the working directory, so
that git stops complaining on merge.
This behavior is new with git 1.4.0, which Fedora Extras just added. I
verified that merges work as expected in git 1.3.3, the last version
Fedora Extras shipped prior to 1.4.0.
This behavior is a definite regression, that impacts workflow :(
Here is how to reproduce:
git clone -l $url/torvalds/linux-2.6.git tmp-2.6
cd tmp-2.6
cp .git/refs/tags/v2.6.12 .git/refs/heads/tmp
git checkout -f tmp
git pull . master
# watch OBVIOUS FAST-FORWARD MERGE complain about untracked
# working tree files
Regards,
Jeff
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Karl Hasselström @ 2006-06-18 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi, git
In-Reply-To: <7vzmga1y9k.fsf@assigned-by-dhcp.cox.net>
On 2006-06-18 04:47:19 -0700, Junio C Hamano wrote:
> Thanks for the explanation.
>
> If that's the case, I think it makes the original problem Santi
> brought up a non-issue. In this sequence:
>
> make prefix=/home/santi/usr
> make install prefix=/home/santi/usr/stow/git
> cd /home/santi/usr/stow/
> stow -v git
>
> the building phase could have used the same prefix as the install
> phase uses, and git can find its subprograms in gitexecdir (=
> ~/usr/stow/git/bin) just fine. It probably is even slightly more
> efficient since it does not have to go through the symlink stow
> installs.
Yes, exactly. I've always built git like this:
$ make prefix=/usr/local/stow/git
$ sudo make prefix=/usr/local/stow/git install
$ cd /usr/local/stow
$ sudo stow git
It works for all other programs I've tried too (most of which only
require me to specify the prefix once, with ./configure --prefix=...).
The programs never need to know about the symlinks; they're only there
for when other programs need to access them (via PATH, etc.).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Is there such a thing as a git:// proxy?
From: linux @ 2006-06-18 12:42 UTC (permalink / raw)
To: git
I have several machines tracking kernel.org, and I've been moving away
from downloading patch files periodically (cached very nicely by squid)
to just doing "git pull".
But it seems silly to be sucking four copies of the same data from
kernel.org.
Now, one obvious solution is to have one master copy track kernel.org
and have all the other local machines track that. But then I have to
manually pull the local master every time.
Has anyone put together something that can automatically check
upstream for updates when someone fetches from it?
Ultimately desirable features would, I suppose include:
- Pulling over ssh as well (using auth agent forwarding to pull
from upstream)
- Support for arbitrary projects (so the cache server can handle
"git clone" requests), if I develop a desire to pull an -mm or
-libata-dev or whatever kernel, it will also work.
- Using a single shared object pool for the above.
- Cache cleanup if a project hasn't been used in long enough.
(You'd probably just time out the heads and let git-prune get
rid of the objects.)
- Recycling the pack from the upstream server rather than regenerating it.
- Progress reporting on the upstream fetch (since the point is that
the upstream server pipe is narrower).
- Transparent proxy support
... but I'll settle for the simple solution to start. Perhaps it could
be as simple as a pre-upload hook invoked by git-upload-pack?
This hasn't gotten itchy enough for me to start scratching it myself,
but I figured I'd mention it and see if anyone was interested.
^ 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