* Re: possible 'git cp'/how does git detect copies
From: Mircea Bardac @ 2008-06-27 13:16 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <8aa486160806270557w20ce622co1099bceec7bc90f9@mail.gmail.com>
Hi,
Santi Béjar wrote:
> On Fri, Jun 27, 2008 at 14:40, Mircea Bardac <dev@mircea.bardac.net> wrote:
>> I was looking today at duplicating a file but, I soon realized that there is
>> no 'git cp' command (this was the "deductive approach to git commands",
>> starting from git mv/rm/...). How does "git diff -C" detect copies (-C is
>> used for this, according to the documentation)?
>
> Did you followed the "See also −−find−copies−harder."?
I knew this from before but for some reason I forgot about it when I
tried it now. The documentation for "git diff -C" is a bit misleading. I
have originally tested on git 1.5.2.something and the documentation for
-C didn't point to --find-copies-harder. I've quickly installed 1.5.6.1
to test the behavior but not the man pages.
Looking over the online docs for 1.5.6.1, it appears that there is now a
reference to --find-copies-harder.
Even so, saying just that "Detect copies as well as renames." is not
enough, as it assumes that there is no restriction on the detection process.
From --find-copies-harder
"For performance reasons, by default, -C option finds copies only if the
original file of the copy was modified in the same changeset." should be
moved to -C.
>> On a very simple test, I couldn't see this working. I just copied one file,
>> added it, committed the change, ran "git diff -C HEAD^!". There is no place
>> saying that it's contents is copied from some other file (both files are in
>> the repository now).
>>
>> "git blame -C new_copied_file" also doesn't show the commits for the
>> original file.
>
> git blame -C -C new_copied_file
Ah, duplicating the parameter. Looking better over these options I have
noticed that --find-copies-harder for "git diff" can also be replaced
with an extra -C. A little bit of consistency would help: either
"-C -C", either "--find-copies-harder" in both git blame/diff. Removing
from the documentation the deprecated version but keeping the
implementation for backwards compatibility might be a solution.
Many thanks,
Mircea
P.S. I know that patches are encouraged and technically it's pretty
simple to create a documentation patch, but I have not yet formed myself
a workflow for sending patches via Git to a maillist (this is a pending
task for me)
--
http://mircea.bardac.net
^ permalink raw reply
* Re: [PATCH 12/13] Build in merge
From: Miklos Vajna @ 2008-06-27 13:17 UTC (permalink / raw)
To: Olivier Marin; +Cc: Olivier Marin, Junio C Hamano, git
In-Reply-To: <4864E574.70700@freesurf.fr>
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
On Fri, Jun 27, 2008 at 03:04:52PM +0200, Olivier Marin <dkr@freesurf.fr> wrote:
> >> + if (diff_use_color_default == -1)
> >> + diff_use_color_default = git_use_color_default;
> >> +
> >> argc = parse_options(argc, argv, builtin_merge_options,
> >> builtin_merge_usage, 0);
> >
> > Have you tried this?
>
> I did. I forget to say that it's on top of your patch, sorry.
Aah. I should have noticed that.
I see now, your hunk is necessary when color.diff and diff.color is not
set but color.ui is.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: possible 'git cp'/how does git detect copies
From: Miklos Vajna @ 2008-06-27 13:09 UTC (permalink / raw)
To: Pierre Habouzit, Mircea Bardac, git
In-Reply-To: <20080627130006.GC17898@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Fri, Jun 27, 2008 at 03:00:06PM +0200, Pierre Habouzit <madcoder@debian.org> wrote:
> If you really need it, you can and an alias alias.cp=!cp and be done
> with it ;P
Actually that's not that easy. git-mv moves untracked files and adds
tracked files to the index as well. So such a git-cp would have to copy
tracked and untracked files, and add tracked files to the index.
I did it in the past:
http://thread.gmane.org/gmane.comp.version-control.git/72388/focus=73347
but then we agreed about it's better not encouraging copy-and-paste.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: possible 'git cp'/how does git detect copies
From: Johannes Sixt @ 2008-06-27 13:05 UTC (permalink / raw)
To: Mircea Bardac; +Cc: git
In-Reply-To: <4864DFB6.3050204@mircea.bardac.net>
Mircea Bardac schrieb:
> I was looking today at duplicating a file but, I soon realized that
> there is no 'git cp' command (this was the "deductive approach to git
> commands", starting from git mv/rm/...). How does "git diff -C" detect
> copies (-C is used for this, according to the documentation)?
>
> On a very simple test, I couldn't see this working. I just copied one
> file, added it, committed the change, ran "git diff -C HEAD^!". There is
> no place saying that it's contents is copied from some other file (both
> files are in the repository now).
>
> "git blame -C new_copied_file" also doesn't show the commits for the
> original file.
>
> This is all with 1.5.6.1.
>
> I am probably missing something here... but I can't produce an example
> of copied contents that actually works. Any hint would be appreciated.
If you modify the original file in the same commit, then you should see
the copy. Otherwise, you can try git diff -C -C aka --find-copies-harder.
-- Hannes
^ permalink raw reply
* Re: [PATCH] commit-tree: lift completely arbitrary limit of 16 parents
From: Johannes Schindelin @ 2008-06-27 13:02 UTC (permalink / raw)
To: Johannes Sixt, gitster; +Cc: Len Brown, git
In-Reply-To: <4864E472.3070301@viscovery.net>
Hi,
On Fri, 27 Jun 2008, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > @@ -69,18 +63,16 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> >
> > check_valid(tree_sha1, OBJ_TREE);
> > for (i = 2; i < argc; i += 2) {
> > + unsigned char sha1[40];
>
> unsigned char sha1[20];
>
> is sufficient here, /me thinks.
Ooops. Completely correct.
Junio, want me to fix it up? Or do you want me not to bother with this
patch at all?
Ciao,
Dscho
^ permalink raw reply
* Re: octopus limit
From: Miklos Vajna @ 2008-06-27 13:04 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Len Brown, git
In-Reply-To: <vpqbq1n5qv2.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
On Fri, Jun 27, 2008 at 08:33:37AM +0200, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> There's a patch around which should remove this limitation (I think
> it's the builtin-ification of merge).
It's in 'pu', so in case you really need it *now*, then just get git.git
and build the 'pu' branch.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 12/13] Build in merge
From: Olivier Marin @ 2008-06-27 13:04 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Olivier Marin, Junio C Hamano, git
In-Reply-To: <20080627125443.GK29404@genesis.frugalware.org>
Miklos Vajna a écrit :
> On Fri, Jun 27, 2008 at 01:03:20PM +0200, Olivier Marin <dkr+ml.git@free.fr> wrote:
>> Absolutely. And also color.ui. The following patch should do the trick:
>>
>> diff --git a/builtin-merge.c b/builtin-merge.c
>> index 98adca5..cf557f7 100644
>> --- a/builtin-merge.c
>> +++ b/builtin-merge.c
>> @@ -7,6 +7,7 @@
>> */
>>
>> #include "cache.h"
>> +#include "color.h"
>> #include "parse-options.h"
>> #include "builtin.h"
>> #include "run-command.h"
>> @@ -712,6 +713,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
>> git_config(git_merge_config, NULL);
>> git_config(git_diff_ui_config, NULL);
>>
>> + if (diff_use_color_default == -1)
>> + diff_use_color_default = git_use_color_default;
>> +
>> argc = parse_options(argc, argv, builtin_merge_options,
>> builtin_merge_usage, 0);
>
> Have you tried this?
I did. I forget to say that it's on top of your patch, sorry.
> First, you need to call git_get_colorbool_config(), second this won't
> respect diff.color, while my patch does.
git_get_colorbool_config() is called via git_diff_ui_config.
Olivier.
^ permalink raw reply
* Re: [PATCH 12/13] Build in merge
From: Miklos Vajna @ 2008-06-27 13:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Olivier Marin, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0806271255240.9925@racer>
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
On Fri, Jun 27, 2008 at 12:56:02PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > + char hex[41];
> > +
> > + memcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV), 41);
>
> Maybe strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV)) would be more
> intuitive?
Ah yes. Changed.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] commit-tree: lift completely arbitrary limit of 16 parents
From: Johannes Sixt @ 2008-06-27 13:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Len Brown, git
In-Reply-To: <alpine.DEB.1.00.0806271324010.9925@racer>
Johannes Schindelin schrieb:
> @@ -69,18 +63,16 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
>
> check_valid(tree_sha1, OBJ_TREE);
> for (i = 2; i < argc; i += 2) {
> + unsigned char sha1[40];
unsigned char sha1[20];
is sufficient here, /me thinks.
-- Hannes
^ permalink raw reply
* Re: possible 'git cp'/how does git detect copies
From: Pierre Habouzit @ 2008-06-27 13:00 UTC (permalink / raw)
To: Mircea Bardac; +Cc: git
In-Reply-To: <4864DFB6.3050204@mircea.bardac.net>
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
On Fri, Jun 27, 2008 at 12:40:22PM +0000, Mircea Bardac wrote:
> I was looking today at duplicating a file but, I soon realized that there
> is no 'git cp' command (this was the "deductive approach to git
> commands", starting from git mv/rm/...). How does "git diff -C" detect
> copies (-C is used for this, according to the documentation)?
By comparing if files (blobs) are alike. It has some heuristics to
guess which files have good changes to be copies or renames of each
others. But it recomputes the information each time.
> On a very simple test, I couldn't see this working. I just copied one
> file, added it, committed the change, ran "git diff -C HEAD^!". There is
> no place saying that it's contents is copied from some other file (both
> files are in the repository now).
>
> "git blame -C new_copied_file" also doesn't show the commits for the
> original file.
You probably want to use -C -C -M actually.
> I found this older thread [1] on "git cp" but the discussion appears to
> have stalled at some point. If there is indeed no use of a "git cp"
> command, I would like at least some info on how content copies are being
> detected, since I haven't seen this working.
If you really need it, you can and an alias alias.cp=!cp and be done
with it ;P
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 2/2] clone: respect url.insteadOf setting in global configs
From: Johannes Schindelin @ 2008-06-27 12:56 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailinglist, Daniel Barkalow, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0806271353350.9925@racer>
When we call "git clone" with a url that has a rewrite rule in either
$HOME/.gitconfig or /etc/gitconfig, the URL can be different from
what the command line expects it to be.
So, let's use the URL as the remote structure has it, not the literal
string from the command line.
Noticed by Pieter de Bie.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-clone.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 965b5fc..8dda52a 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -463,7 +463,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
refs = clone_local(path, git_dir);
else {
struct remote *remote = remote_get(argv[0]);
- struct transport *transport = transport_get(remote, argv[0]);
+ struct transport *transport =
+ transport_get(remote, remote->url[0]);
if (!transport->get_refs_list || !transport->fetch)
die("Don't know how to clone %s", transport->url);
--
1.5.6.173.gde14c
^ permalink raw reply related
* [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Johannes Schindelin @ 2008-06-27 12:55 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailinglist, Daniel Barkalow, Junio C Hamano
In-Reply-To: <27C25D70-0BFC-4362-A771-C7CAD89BC198@ai.rug.nl>
After initializing the config in the newly-created repository, we
need to unset GIT_CONFIG so that the global configs are read again.
Noticed by Pieter de Bie.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 27 Jun 2008, Pieter de Bie wrote:
> I sometimes use url.insteadOf to create a shortcut to a central
> repository. For example, having something like[*1*]
>
> [url "git://repo.or.cz/git/"]
> insteadOf = "repo:"
>
> in my global gitconfig allows me to do a 'git fetch
> repo:dscho.git'. I'd also like to use that with git clone :).
> Currently if I try that, I get
>
> Vienna:~ pieter$ git clone repo:dscho.git
> Initialize dscho/.git
> Initialized empty Git repository in /Users/pieter/dscho/.git/
> ssh: Error resolving hostname repo: nodename nor servname provided,
> or not known
> fatal: The remote end hung up unexpectedly
>
> [...]
>
> Is there an easy fix for this?
Yes ;-)
builtin-clone.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 17baa20..965b5fc 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -424,6 +424,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
fprintf(stderr, "Initialize %s\n", git_dir);
init_db(option_template, option_quiet ? INIT_DB_QUIET : 0);
+ /*
+ * At this point, the config exists, so we do not need the
+ * environment variable. We actually need to unset it, too, to
+ * re-enable parsing of the global configs.
+ */
+ unsetenv(CONFIG_ENVIRONMENT);
+
if (option_reference)
setup_reference(git_dir);
--
1.5.6.173.gde14c
^ permalink raw reply related
* Re: possible 'git cp'/how does git detect copies
From: Santi Béjar @ 2008-06-27 12:57 UTC (permalink / raw)
To: Mircea Bardac; +Cc: git
In-Reply-To: <4864DFB6.3050204@mircea.bardac.net>
On Fri, Jun 27, 2008 at 14:40, Mircea Bardac <dev@mircea.bardac.net> wrote:
> I was looking today at duplicating a file but, I soon realized that there is
> no 'git cp' command (this was the "deductive approach to git commands",
> starting from git mv/rm/...). How does "git diff -C" detect copies (-C is
> used for this, according to the documentation)?
Did you followed the "See also −−find−copies−harder."?
>From the man page
--find-copies-harder::
For performance reasons, by default, `-C` option finds copies only
if the original file of the copy was modified in the same
changeset. This flag makes the command
inspect unmodified files as candidates for the source of
copy. This is a very expensive operation for large
projects, so use it with caution. Giving more than one
`-C` option has the same effect.
>
> On a very simple test, I couldn't see this working. I just copied one file,
> added it, committed the change, ran "git diff -C HEAD^!". There is no place
> saying that it's contents is copied from some other file (both files are in
> the repository now).
>
> "git blame -C new_copied_file" also doesn't show the commits for the
> original file.
git blame -C -C new_copied_file
^ permalink raw reply
* Re: [PATCH 12/13] Build in merge
From: Miklos Vajna @ 2008-06-27 12:54 UTC (permalink / raw)
To: Olivier Marin; +Cc: Junio C Hamano, git
In-Reply-To: <4864C8F8.9020501@free.fr>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On Fri, Jun 27, 2008 at 01:03:20PM +0200, Olivier Marin <dkr+ml.git@free.fr> wrote:
> Absolutely. And also color.ui. The following patch should do the trick:
>
> diff --git a/builtin-merge.c b/builtin-merge.c
> index 98adca5..cf557f7 100644
> --- a/builtin-merge.c
> +++ b/builtin-merge.c
> @@ -7,6 +7,7 @@
> */
>
> #include "cache.h"
> +#include "color.h"
> #include "parse-options.h"
> #include "builtin.h"
> #include "run-command.h"
> @@ -712,6 +713,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> git_config(git_merge_config, NULL);
> git_config(git_diff_ui_config, NULL);
>
> + if (diff_use_color_default == -1)
> + diff_use_color_default = git_use_color_default;
> +
> argc = parse_options(argc, argv, builtin_merge_options,
> builtin_merge_usage, 0);
Have you tried this?
First, you need to call git_get_colorbool_config(), second this won't
respect diff.color, while my patch does.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* possible 'git cp'/how does git detect copies
From: Mircea Bardac @ 2008-06-27 12:40 UTC (permalink / raw)
To: git
I was looking today at duplicating a file but, I soon realized that
there is no 'git cp' command (this was the "deductive approach to git
commands", starting from git mv/rm/...). How does "git diff -C" detect
copies (-C is used for this, according to the documentation)?
On a very simple test, I couldn't see this working. I just copied one
file, added it, committed the change, ran "git diff -C HEAD^!". There is
no place saying that it's contents is copied from some other file (both
files are in the repository now).
"git blame -C new_copied_file" also doesn't show the commits for the
original file.
This is all with 1.5.6.1.
I am probably missing something here... but I can't produce an example
of copied contents that actually works. Any hint would be appreciated.
I found this older thread [1] on "git cp" but the discussion appears to
have stalled at some point. If there is indeed no use of a "git cp"
command, I would like at least some info on how content copies are being
detected, since I haven't seen this working.
[1] http://kerneltrap.org/mailarchive/git/2008/2/3/705424
Many thanks,
Mircea
--
http://mircea.bardac.net
^ permalink raw reply
* BUG (v1.5.6.1): ./configure missing check for zlib.h
From: Mircea Bardac @ 2008-06-27 12:30 UTC (permalink / raw)
To: git
$ ./configure
configure: CHECKS for programs
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ANSI C... none needed
checking for gar... no
checking for ar... ar
checking for gtar... no
checking for tar... tar
checking for asciidoc... no
configure: CHECKS for libraries
checking for SHA1_Init in -lcrypto... no
checking for SHA1_Init in -lssl... no
checking for curl_global_init in -lcurl... no
checking for XML_ParserCreate in -lexpat... no
checking for iconv in -lc... yes
checking for deflateBound in -lz... no
checking for socket in -lc... yes
configure: CHECKS for header files
checking how to run the C preprocessor... cc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for old iconv()... no
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for struct dirent.d_ino... yes
checking for struct dirent.d_type... yes
checking for struct sockaddr_storage... yes
checking for struct addrinfo... yes
checking for getaddrinfo... yes
checking whether formatted IO functions support C99 size specifiers... yes
checking whether system succeeds to read fopen'ed directory... no
checking whether snprintf() and/or vsnprintf() return bogus value... no
configure: CHECKS for library functions
checking for strcasestr... yes
checking for memmem... yes
checking for strlcpy... no
checking for strtoumax... yes
checking for setenv... yes
checking for unsetenv... yes
checking for mkdtemp... yes
configure: CHECKS for site configuration
configure: creating ./config.status
config.status: creating config.mak.autogen
$ make
GIT_VERSION = 1.5.6.1
* new build flags or prefix
CC daemon.o
In file included from daemon.c:1:
cache.h:9:18: error: zlib.h: No such file or directory
make: *** [daemon.o] Error 1
(installing zlib1g-dev on Ubuntu 7.10 fixed the problem)
--
Mircea
http://mircea.bardac.net
^ permalink raw reply
* [PATCH] commit-tree: lift completely arbitrary limit of 16 parents
From: Johannes Schindelin @ 2008-06-27 12:24 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0806271259440.9925@racer>
There is no really good reason to have a merge with more than 16
parents, but we have a history of giving our users rope.
Combined with the fact that there was no good reason for that
arbitrary limit in the first place, here is an all-too-easy to fix.
Kind of wished-for by Len Brown.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 27 Jun 2008, Johannes Schindelin wrote:
> On Thu, 26 Jun 2008, Len Brown wrote:
>
> > it would be nice if a merge of more than 16 branches failed
> > right at the start, rather than chunking along doing merges and then
> > giving up, leaving my repo in an intermediate state.
>
> FWIW I think the rewrite of git-merge as a builtin, which is
> currently in the works, lifts the limit. However, this is only true if
> you do not use a custom script which calls commit-tree.
And here is a patch to fix commit-tree.
builtin-commit-tree.c | 43 ++++++++++++++++++++-----------------------
1 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index e5e4bdb..5931a92 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -24,26 +24,20 @@ static void check_valid(unsigned char *sha1, enum object_type expect)
typename(expect));
}
-/*
- * Having more than two parents is not strange at all, and this is
- * how multi-way merges are represented.
- */
-#define MAXPARENT (16)
-static unsigned char parent_sha1[MAXPARENT][20];
-
static const char commit_tree_usage[] = "git-commit-tree <sha1> [-p <sha1>]* < changelog";
-static int new_parent(int idx)
+static void new_parent(struct commit *parent, struct commit_list **parents_p)
{
- int i;
- unsigned char *sha1 = parent_sha1[idx];
- for (i = 0; i < idx; i++) {
- if (!hashcmp(parent_sha1[i], sha1)) {
+ unsigned char *sha1 = parent->object.sha1;
+ struct commit_list *parents;
+ for (parents = *parents_p; parents; parents = parents->next) {
+ if (!hashcmp(parents->item->object.sha1, sha1)) {
error("duplicate parent %s ignored", sha1_to_hex(sha1));
- return 0;
+ return;
}
+ parents_p = &parents->next;
}
- return 1;
+ commit_list_insert(parent, parents_p);
}
static const char commit_utf8_warn[] =
@@ -54,7 +48,7 @@ static const char commit_utf8_warn[] =
int cmd_commit_tree(int argc, const char **argv, const char *prefix)
{
int i;
- int parents = 0;
+ struct commit_list *parents = NULL;
unsigned char tree_sha1[20];
unsigned char commit_sha1[20];
struct strbuf buffer;
@@ -69,18 +63,16 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
check_valid(tree_sha1, OBJ_TREE);
for (i = 2; i < argc; i += 2) {
+ unsigned char sha1[40];
const char *a, *b;
a = argv[i]; b = argv[i+1];
if (!b || strcmp(a, "-p"))
usage(commit_tree_usage);
- if (parents >= MAXPARENT)
- die("Too many parents (%d max)", MAXPARENT);
- if (get_sha1(b, parent_sha1[parents]))
+ if (get_sha1(b, sha1))
die("Not a valid object name %s", b);
- check_valid(parent_sha1[parents], OBJ_COMMIT);
- if (new_parent(parents))
- parents++;
+ check_valid(sha1, OBJ_COMMIT);
+ new_parent(lookup_commit(sha1), &parents);
}
/* Not having i18n.commitencoding is the same as having utf-8 */
@@ -94,8 +86,13 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
* different order of parents will be a _different_ changeset even
* if everything else stays the same.
*/
- for (i = 0; i < parents; i++)
- strbuf_addf(&buffer, "parent %s\n", sha1_to_hex(parent_sha1[i]));
+ while (parents) {
+ struct commit_list *next = parents->next;
+ strbuf_addf(&buffer, "parent %s\n",
+ sha1_to_hex(parents->item->object.sha1));
+ free(parents);
+ parents = next;
+ }
/* Person/date information */
strbuf_addf(&buffer, "author %s\n", git_author_info(IDENT_ERROR_ON_NO_NAME));
--
1.5.6.173.gde14c
^ permalink raw reply related
* git serve
From: Michael J Gruber @ 2008-06-27 12:19 UTC (permalink / raw)
To: git
Hi there
I added a small subsection to the wiki at
http://git.or.cz/gitwiki/Aliases
I hope it's OK to just go ahead and edit like I did.
I love the power of git aliases. This one shows how easy it is to
implement a "hg serve" alike "git serve".
In order to be able to use "git serve" from a subdir of the repo without
much scripting (git-rev-parse --git-dir) my alias uses the fact that
non-git aliases (beginning with "!") are executed with the top-level dir
as cwd. Is this documented/guaranteed?
Michael
P.S.: I always wondered why there's no default "view = !gitk"...
^ permalink raw reply
* Re: octopus limit
From: Johannes Schindelin @ 2008-06-27 12:00 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0806262243130.2988@localhost.localdomain>
Hi,
On Thu, 26 Jun 2008, Len Brown wrote:
> it would be nice if a merge of more than 16 branches failed right at the
> start, rather than chunking along doing merges and then giving up,
> leaving my repo in an intermediate state.
FWIW I think the rewrite of git-merge as a builtin, which is currently in
the works, lifts the limit. However, this is only true if you do not use
a custom script which calls commit-tree.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 12/13] Build in merge
From: Johannes Schindelin @ 2008-06-27 11:56 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Olivier Marin, Junio C Hamano, git
In-Reply-To: <20080627010609.GJ29404@genesis.frugalware.org>
Hi,
On Fri, 27 Jun 2008, Miklos Vajna wrote:
> diff --git a/builtin-merge.c b/builtin-merge.c
> index cc04d01..77de9e8 100644
> --- a/builtin-merge.c
> +++ b/builtin-merge.c
> @@ -836,9 +836,12 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> /* Again the most common case of merging one remote. */
> struct strbuf msg;
> struct object *o;
> + char hex[41];
> +
> + memcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV), 41);
Maybe strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV)) would be more
intuitive?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 12/13] Build in merge
From: Olivier Marin @ 2008-06-27 11:03 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20080627010609.GJ29404@genesis.frugalware.org>
Miklos Vajna a écrit :
>
> This should respect diff.color:
Absolutely. And also color.ui. The following patch should do the trick:
diff --git a/builtin-merge.c b/builtin-merge.c
index 98adca5..cf557f7 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -7,6 +7,7 @@
*/
#include "cache.h"
+#include "color.h"
#include "parse-options.h"
#include "builtin.h"
#include "run-command.h"
@@ -712,6 +713,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
git_config(git_merge_config, NULL);
git_config(git_diff_ui_config, NULL);
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
Olivier.
^ permalink raw reply related
* Re: is rebase the same as merging every commit?
From: しらいしななこ @ 2008-06-27 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Jeske, git
In-Reply-To: <7vzlp7n1j4.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> "David Jeske" <jeske@willowmail.com> writes:
>
>> If I understand it right (and that's a BIG if), it's the same as doing a merge
>> of C into G where every individual commit in the C-line is individually
>> committed into the new C' line.
>>
>> ...........-------------A---B---C
>> ........../ / / /
>> ........./ /---A'--B'--C' topic
>> ......../ /
>> ....D---E---F---G - master
>>
>>
>> (1) Is the above model a valid explanation?
>
> I would presume that the resulting trees A' in the second picture and in
> the first picture would be the same, so are B' and C'. But that is only
> true when commits between A and C do not have any duplicate with the
> development that happened between E and G.
Sorry, but I think you are wrong, Junio.
Rebase can be used to backport changes, not just porting your changes forward, using --onto option:
..........maint
............1-------A'--B'--C'
.........../ . . . <-- ???
........../.......A---B---C
........./......./
......../......./
.......0--...--D---E---F---G - master
Here, A, B, C that are based on D (that is way ahead of the top of the maintenance branch 1) is rebased to the maintenance branch.
But in this case, A' is *not* a merge between 1 and A. For A' to be a merge between 1 and A, it *must* contain all the development that happened up to 1 and all the development that happened up to A since these two branches were forked (that is 0 in the above picture).
Instead, the difference to go from 1 to A' is similar to the difference to go from D to A. It does not and must not include anything that happened between 0 and D. That is not a merge.
I agree that your explanation why A is not recorded as a parent of A' is right for the philosophical reason (the purpose of rebasing to create A' is so that you do not have to record them). But from the point-of-view of correctness of commit history, I think A must not be recorded as a parent of A', either.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Using url.insteadOf in git-clone
From: Pieter de Bie @ 2008-06-27 9:35 UTC (permalink / raw)
To: Git Mailinglist; +Cc: Daniel Barkalow, Junio C Hamano
Hi,
I sometimes use url.insteadOf to create a shortcut to a central
repository.
For example, having something like[*1*]
[url "git://repo.or.cz/git/"]
insteadOf = "repo:"
in my global gitconfig allows me to do a 'git fetch repo:dscho.git'.
I'd also
like to use that with git clone :). Currently if I try that, I get
Vienna:~ pieter$ git clone repo:dscho.git
Initialize dscho/.git
Initialized empty Git repository in /Users/pieter/dscho/.git/
ssh: Error resolving hostname repo: nodename nor servname provided, or
not known
fatal: The remote end hung up unexpectedly
Which I think comes from the fact that the global config isn't read in
by
remote.c when running git clone.
Now, I seem to remember there was a good reason for this (both builtin-
clone
and git-clone.sh have the same behaviour). Also, trying to quickly
hack in
something failed for me, even though it seems like a trivial change to
make
for someone more familiar with the code path.
Is there an easy fix for this?
- Pieter
[1] This is not really true. If I try that, I get an error:
Vienna:git pieter$ git fetch -v repo:dscho.git
fatal: I don't handle protocol 'it'
If I change the url to "ggit://.." it does work. It seems there is an
off-by-one
error somewhere? It does work for another url.insteadOf I have in my
global
config though..
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Petr Baudis @ 2008-06-27 8:50 UTC (permalink / raw)
To: Robert Anderson; +Cc: Git Mailing List
In-Reply-To: <9af502e50806262350t6e794a92g7751147f1882965@mail.gmail.com>
Hi,
On Thu, Jun 26, 2008 at 11:50:06PM -0700, Robert Anderson wrote:
> Seems to me the concept of the "index" is a half-baked version of what
> I really want, which is the ability to factor a working tree's changes
> into its constituent parts in preparation for committing them. The
> index provides some very nice facilities to factor out changes in a
> working tree into a "staging area", but the fundamental flaw of this
> in my view is that this "staging area" is not instantiated as a tree,
> so it cannot be compiled and/or tested before committing.
>
> Consider a facility where the state you want to commit next is built
> up in the current working directory, and the original set of changes
> exists in some proto-space like the index currently inhabits, where
> you can query and manipulate that state, but it isn't instantiated in
> your working tree.
I wanted to suggest using commit and commit --amend, but I realized
that frankly, I don't understand quite what are you wanting to do.
Through the process, are you preparing a sequence of two commits at
once, or merely a single commit? With s/--prep/--cached/ and throwing
git prep away completely, it's not clear to me how would what you
present be different at all from just using index - could you point out
what is actually different in your workflow compared to the prep
workflow you propose?
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: Errors building git-1.5.6 from source on Mac OS X 10.4.11
From: Ifejinelo Onyiah @ 2008-06-27 8:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0806261142r37f84187qf5ff043e1913b4fb@mail.gmail.com>
2008/6/26 Alex Riesen <raa.lkml@gmail.com>:
> 2008/6/26 Ifejinelo Onyiah <nelo.onyiah@googlemail.com>:
>> 2008/6/25 Alex Riesen <raa.lkml@gmail.com>:
>>> Ifejinelo Onyiah, Wed, Jun 25, 2008 15:20:39 +0200:
>>>>
>>>> They all run fine but when I issue the make test command, it dies at
>>>> the following:
>>>>
>>>> % make test
>>>>
>>>> ... TRUNCATED OUTPUT ...
>>>>
>>>> *** t2004-checkout-cache-temp.sh ***
>>>> * FAIL 1: preparation
>>>>
>>>
>>> If you don't mind helping the investigation a bit, could you please go
>>> into the t/ directory and run
>>>
>>> bash -x t2004-checkout-cache-temp.sh -d -v -i
>>>
>>> and post the output here?
>>
>> I ran that command and it seemed to run with no problems. I have
>> provided the output in 2 attached text files. I hope that is ok.
>
> could you try the command _without_ "bash -x"?
> Like this:
>
> cd t
> ./t2004-checkout-cache-temp.sh -d -v -i
>
I've just done that and here's the output:
io1@mib19412i[00m:~/Desktop/git-1.5.6/t$ ./t2004-checkout-cache-temp.sh -d -v -i
* expecting success:
mkdir asubdir &&
echo tree1path0 >path0 &&
echo tree1path1 >path1 &&
echo tree1path3 >path3 &&
echo tree1path4 >path4 &&
echo tree1asubdir/path5 >asubdir/path5 &&
git update-index --add path0 path1 path3 path4 asubdir/path5 &&
t1=$(git write-tree) &&
rm -f path* .merge_* out .git/index &&
echo tree2path0 >path0 &&
echo tree2path1 >path1 &&
echo tree2path2 >path2 &&
echo tree2path4 >path4 &&
git update-index --add path0 path1 path2 path4 &&
t2=$(git write-tree) &&
rm -f path* .merge_* out .git/index &&
echo tree2path0 >path0 &&
echo tree3path1 >path1 &&
echo tree3path2 >path2 &&
echo tree3path3 >path3 &&
git update-index --add path0 path1 path2 path3 &&
t3=$(git write-tree)
* ok 1: preparation
* expecting success:
rm -f path* .merge_* out .git/index &&
git read-tree $t1 &&
git checkout-index --temp -- path1 >out &&
test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path1 &&
p=$(cut "-d " -f1 out) &&
test -f $p &&
test $(cat $p) = tree1path1
* ok 2: checkout one stage 0 to temporary file
* expecting success:
rm -f path* .merge_* out .git/index &&
git read-tree $t1 &&
git checkout-index -a --temp >out &&
test $(wc -l <out) = 5 &&
for f in path0 path1 path3 path4 asubdir/path5
do
test $(grep $f out | cut "-d " -f2) = $f &&
p=$(grep $f out | cut "-d " -f1) &&
test -f $p &&
test $(cat $p) = tree1$f
done
* ok 3: checkout all stage 0 to temporary files
* expecting success:
rm -f path* .merge_* out .git/index &&
git read-tree -m $t1 $t2 $t3
* ok 4: prepare 3-way merge
* expecting success:
rm -f path* .merge_* out &&
git checkout-index --stage=2 --temp -- path1 >out &&
test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path1 &&
p=$(cut "-d " -f1 out) &&
test -f $p &&
test $(cat $p) = tree2path1
* ok 5: checkout one stage 2 to temporary file
* expecting success:
rm -f path* .merge_* out &&
git checkout-index --all --stage=2 --temp >out &&
test $(wc -l <out) = 3 &&
for f in path1 path2 path4
do
test $(grep $f out | cut "-d " -f2) = $f &&
p=$(grep $f out | cut "-d " -f1) &&
test -f $p &&
test $(cat $p) = tree2$f
done
* ok 6: checkout all stage 2 to temporary files
* expecting success:
rm -f path* .merge_* out &&
git checkout-index --stage=all --temp -- path0 >out &&
test $(wc -l <out) = 0
git-checkout-index: path0 does not exist at stage 4
* ok 7: checkout all stages/one file to nothing
* expecting success:
rm -f path* .merge_* out &&
git checkout-index --stage=all --temp -- path1 >out &&
test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path1 &&
cut "-d " -f1 out | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test -f $s3 &&
test $(cat $s1) = tree1path1 &&
test $(cat $s2) = tree2path1 &&
test $(cat $s3) = tree3path1)
* ok 8: checkout all stages/one file to temporary files
* expecting success:
rm -f path* .merge_* out &&
git checkout-index --stage=all --temp -- path2 >out &&
test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path2 &&
cut "-d " -f1 out | (read s1 s2 s3 &&
test $s1 = . &&
test -f $s2 &&
test -f $s3 &&
test $(cat $s2) = tree2path2 &&
test $(cat $s3) = tree3path2)
* ok 9: checkout some stages/one file to temporary files
* expecting success:
rm -f path* .merge_* out &&
git checkout-index -a --stage=all --temp >out &&
test $(wc -l <out) = 5
* ok 10: checkout all stages/all files to temporary files
* expecting success:
test x$(grep path0 out | cut "-d " -f2) = x
* ok 11: -- path0: no entry
* expecting success:
test $(grep path1 out | cut "-d " -f2) = path1 &&
grep path1 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test -f $s3 &&
test $(cat $s1) = tree1path1 &&
test $(cat $s2) = tree2path1 &&
test $(cat $s3) = tree3path1)
* ok 12: -- path1: all 3 stages
* expecting success:
test $(grep path2 out | cut "-d " -f2) = path2 &&
grep path2 out | cut "-d " -f1 | (read s1 s2 s3 &&
test $s1 = . &&
test -f $s2 &&
test -f $s3 &&
test $(cat $s2) = tree2path2 &&
test $(cat $s3) = tree3path2)
* ok 13: -- path2: no stage 1, have stage 2 and 3
* expecting success:
test $(grep path3 out | cut "-d " -f2) = path3 &&
grep path3 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test $s2 = . &&
test -f $s3 &&
test $(cat $s1) = tree1path3 &&
test $(cat $s3) = tree3path3)
* ok 14: -- path3: no stage 2, have stage 1 and 3
* expecting success:
test $(grep path4 out | cut "-d " -f2) = path4 &&
grep path4 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test $s3 = . &&
test $(cat $s1) = tree1path4 &&
test $(cat $s2) = tree2path4)
* ok 15: -- path4: no stage 3, have stage 1 and 3
* expecting success:
test $(grep asubdir/path5 out | cut "-d " -f2) = asubdir/path5 &&
grep asubdir/path5 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test $s2 = . &&
test $s3 = . &&
test $(cat $s1) = tree1asubdir/path5)
* ok 16: -- asubdir/path5: no stage 2 and 3 have stage 1
* expecting success:
(cd asubdir &&
git checkout-index -a --stage=all >out &&
test $(wc -l <out) = 1 &&
test $(grep path5 out | cut "-d " -f2) = path5 &&
grep path5 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f ../$s1 &&
test $s2 = . &&
test $s3 = . &&
test $(cat ../$s1) = tree1asubdir/path5)
)
* ok 17: checkout --temp within subdir
* expecting success:
rm -f path* .merge_* out .git/index &&
ln -s b a &&
git update-index --add a &&
t4=$(git write-tree) &&
rm -f .git/index &&
git read-tree $t4 &&
git checkout-index --temp -a >out &&
test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = a &&
p=$(cut "-d " -f1 out) &&
test -f $p &&
test $(cat $p) = b
* ok 18: checkout --temp symlink
* passed all 18 test(s)
io1@mib19412i[00m:~/Desktop/git-1.5.6/t$
^ 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