* Finally implement "git log --follow"
From: Linus Torvalds @ 2007-06-19 21:22 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Ok, I've really held off doing this too damn long, because I'm lazy, and I
was always hoping that somebody else would do it.
But no, people keep asking for it, but nobody actually did anything, so I
decided I might as well bite the bullet, and instead of telling people
they could add a "--follow" flag to "git log" to do what they want to do,
I decided that it looks like I just have to do it for them..
The code wasn't actually that complicated, in that the diffstat for this
patch literally says "70 insertions(+), 1 deletions(-)", but I will have
to admit that in order to get to this fairly simple patch, you did have to
know and understand the internal git diff generation machinery pretty
well, and had to really be able to follow how commit generation interacts
with generating patches and generating the log.
So I suspect that while I was right that it wasn't that hard, I might have
been expecting too much of random people - this patch does seem to be
firmly in the core "Linus or Junio" territory.
To make a long story short: I'm sorry for it taking so long until I just
did it.
I'm not going to guarantee that this works for everybody, but you really
can just look at the patch, and after the appropriate appreciative noises
("Ooh, aah") over how clever I am, you can then just notice that the code
itself isn't really that complicated.
All the real new code is in the new "try_to_follow_renames()" function. It
really isn't rocket science: we notice that the pathname we were looking
at went away, so we start a full tree diff and try to see if we can
instead make that pathname be a rename or a copy from some other previous
pathname. And if we can, we just continue, except we show *that*
particular diff, and ever after we use the _previous_ pathname.
One thing to look out for: the "rename detection" is considered to be a
singular event in the _linear_ "git log" output! That's what people want
to do, but I just wanted to point out that this patch is *not* carrying
around a "commit,pathname" kind of pair and it's *not* going to be able to
notice the file coming from multiple *different* files in earlier history.
IOW, if you use "git log --follow", then you get the stupid CVS/SVN kind
of "files have single identities" kind of semantics, and git log will just
pick the identity based on the normal move/copy heuristics _as_if_ the
history could be linearized.
Put another way: I think the model is broken, but given the broken model,
I think this patch does just about as well as you can do. If you have
merges with the same "file" having different filenames over the two
branches, git will just end up picking _one_ of the pathnames at the point
where the newer one goes away. It never looks at multiple pathnames in
parallel.
And if you understood all that, you probably didn't need it explained, and
if you didn't understand the above blathering, it doesn't really mtter to
you. What matters to you is that you can now do
git log -p --follow builtin-rev-list.c
and it will find the point where the old "rev-list.c" got renamed to
"builtin-rev-list.c" and show it as such.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
----
NOTE! For obvious enough reasons, I limited the rename following to just
*one* pathname. If somebody wants to extend it to any more, be my guest.
Also, I really might have some silly bug somewhere.
"It Works For Me(tm)", and I tested it with both the git archive and the
kernel (block/ll_rw_block.c) and it worked beautifully, but I'll also
admit that the patch is a bit _too_ clever for my taste normally. The
patch actually looks more straightforward than it really is: that "hook
directly into diff_tree_sha1()" thing is just too damn clever for words.
People who want to improve on it should get rid of the memory leak I
introduced - I decided to not bother cleaning up the whole rename diff
queue, I just reset it. I'm lazy, and I'm a *man*. I do the rough manly
stuff, others can clean up after me.
*Burp*. That hit the spot. *Scratch*
Linus
---
builtin-log.c | 5 ++++
diff.c | 2 +
diff.h | 1 +
revision.c | 4 ++-
tree-diff.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 70 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 0aede76..a26a010 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -58,6 +58,11 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
argc = setup_revisions(argc, argv, rev, "HEAD");
if (rev->diffopt.pickaxe || rev->diffopt.filter)
rev->always_show_header = 0;
+ if (rev->diffopt.follow_renames) {
+ rev->always_show_header = 0;
+ if (rev->diffopt.nr_paths != 1)
+ usage("git logs can only follow renames on one pathname at a time");
+ }
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (!strcmp(arg, "--decorate")) {
diff --git a/diff.c b/diff.c
index 4aa9bbc..9938969 100644
--- a/diff.c
+++ b/diff.c
@@ -2210,6 +2210,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
}
else if (!strcmp(arg, "--find-copies-harder"))
options->find_copies_harder = 1;
+ else if (!strcmp(arg, "--follow"))
+ options->follow_renames = 1;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (!prefixcmp(arg, "--abbrev=")) {
diff --git a/diff.h b/diff.h
index a7ee6d8..9fd6d44 100644
--- a/diff.h
+++ b/diff.h
@@ -55,6 +55,7 @@ struct diff_options {
full_index:1,
silent_on_remove:1,
find_copies_harder:1,
+ follow_renames:1,
color_diff:1,
color_diff_words:1,
has_changes:1,
diff --git a/revision.c b/revision.c
index 1f4590b..7834bb1 100644
--- a/revision.c
+++ b/revision.c
@@ -1230,7 +1230,9 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (revs->prune_data) {
diff_tree_setup_paths(revs->prune_data, &revs->pruning);
- revs->prune_fn = try_to_simplify_commit;
+ /* Can't prune commits with rename following: the paths change.. */
+ if (!revs->diffopt.follow_renames)
+ revs->prune_fn = try_to_simplify_commit;
if (!revs->full_diff)
diff_tree_setup_paths(revs->prune_data, &revs->diffopt);
}
diff --git a/tree-diff.c b/tree-diff.c
index 852498e..42924e9 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -3,6 +3,7 @@
*/
#include "cache.h"
#include "diff.h"
+#include "diffcore.h"
#include "tree.h"
static char *malloc_base(const char *base, int baselen, const char *path, int pathlen)
@@ -290,6 +291,59 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2, const char *base, stru
return 0;
}
+/*
+ * Does it look like the resulting diff might be due to a rename?
+ * - single entry
+ * - not a valid previous file
+ */
+static inline int diff_might_be_rename(void)
+{
+ return diff_queued_diff.nr == 1 &&
+ !DIFF_FILE_VALID(diff_queued_diff.queue[0]->one);
+}
+
+static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, const char *base, struct diff_options *opt)
+{
+ struct diff_options diff_opts;
+ const char *paths[2];
+ int i;
+
+ diff_setup(&diff_opts);
+ diff_opts.recursive = 1;
+ diff_opts.detect_rename = DIFF_DETECT_RENAME;
+ diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
+ diff_opts.single_follow = opt->paths[0];
+ paths[0] = NULL;
+ diff_tree_setup_paths(paths, &diff_opts);
+ if (diff_setup_done(&diff_opts) < 0)
+ die("unable to set up diff options to follow renames");
+ diff_tree(t1, t2, base, &diff_opts);
+ diffcore_std(&diff_opts);
+
+ /* NOTE! Ignore the first diff! That was the old one! */
+ for (i = 1; i < diff_queued_diff.nr; i++) {
+ struct diff_filepair *p = diff_queued_diff.queue[i];
+
+ /*
+ * Found a source? Not only do we use that for the new
+ * diff_queued_diff, we also use that as the path in
+ * the future!
+ */
+ if ((p->status == 'R' || p->status == 'C') && !strcmp(p->two->path, opt->paths[0])) {
+ diff_queued_diff.queue[0] = p;
+ opt->paths[0] = xstrdup(p->one->path);
+ diff_tree_setup_paths(opt->paths, opt);
+ break;
+ }
+ }
+
+ /*
+ * Then, ignore any but the first entry! It might be the old one,
+ * or it might be the rename/copy we found
+ */
+ diff_queued_diff.nr = 1;
+}
+
int diff_tree_sha1(const unsigned char *old, const unsigned char *new, const char *base, struct diff_options *opt)
{
void *tree1, *tree2;
@@ -306,6 +360,11 @@ int diff_tree_sha1(const unsigned char *old, const unsigned char *new, const cha
init_tree_desc(&t1, tree1, size1);
init_tree_desc(&t2, tree2, size2);
retval = diff_tree(&t1, &t2, base, opt);
+ if (opt->follow_renames && diff_might_be_rename()) {
+ init_tree_desc(&t1, tree1, size1);
+ init_tree_desc(&t2, tree2, size2);
+ try_to_follow_renames(&t1, &t2, base, opt);
+ }
free(tree1);
free(tree2);
return retval;
^ permalink raw reply related
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Bill Lear @ 2007-06-19 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Kastrup
In-Reply-To: <7vk5tzwsxn.fsf@assigned-by-dhcp.pobox.com>
On Tuesday, June 19, 2007 at 14:11:32 (-0700) Junio C Hamano writes:
>...
>A one-word guess: CDPATH.
A one-word reply: that-was-correct-thank-you-and-good-guess.
Bill
^ permalink raw reply
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Johannes Schindelin @ 2007-06-19 21:11 UTC (permalink / raw)
To: Bill Lear; +Cc: Alex Riesen, David Kastrup, git
In-Reply-To: <18040.17211.575543.403408@lisa.zopyra.com>
Hi,
On Tue, 19 Jun 2007, Bill Lear wrote:
> (cd blt && tar cf - .) | od -a | head -50
>
> Here is the result of that:
>
> 0000000 / h o m e / b l e a r / b u i l
> 0000020 d / g i t - 1 . 5 . 2 . 2 / t e
> 0000040 m p l a t e s / b l t nl . / nul nul
> 0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
As is easy to see, what has been suggested earlier is true. The cd
(idiotically) outputs the path to stdout.
Hth,
Dscho
^ permalink raw reply
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Junio C Hamano @ 2007-06-19 21:11 UTC (permalink / raw)
To: Bill Lear; +Cc: git, David Kastrup
In-Reply-To: <86k5u0q8q9.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Not sure whether this is the problem: either cd does not understasnd
> the double slashes, or your shell used for scripts has modified cd to
> output some stuff when it is working (people sometimes imprudently
> make shell functions or aliases for this).
>
> Try writing something like
>
> type cd
>
> in a script file and see what output you get.
A one-word guess: CDPATH.
Bill, setting CDPATH in your interactive shell as a shell
variable is Ok, but exporting it as an environment does not make
much sense.
Really.
^ permalink raw reply
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Bill Lear @ 2007-06-19 20:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: David Kastrup, git
In-Reply-To: <20070619200939.GA4180@steel.home>
On Tuesday, June 19, 2007 at 22:09:39 (+0200) Alex Riesen writes:
>Bill Lear, Tue, Jun 19, 2007 18:16:26 +0200:
>> % cat foo
>> set -x
>> type tar
>> type cd
>> (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates && tar xf -)
>
>what would you see if your script contained:
>
> set -x
> (cd blt && tar cf - .) |less
>
>?
>Does the output look like a tar archive to you?
Well, not sure. Lots of gobbledygook.
>Can you share it with us if you're not sure?
Ok, I've tried to send a limited amount of data, hopefully useful. If
I redirect to a file:
(cd blt && tar cf - .) > tar.tar
and then try to view it with tar:
% tar tvf tar.tar
I get the same error as before. I sent the output through
'od' as so:
(cd blt && tar cf - .) | od -a | head -50
Here is the result of that:
0000000 / h o m e / b l e a r / b u i l
0000020 d / g i t - 1 . 5 . 2 . 2 / t e
0000040 m p l a t e s / b l t nl . / nul nul
0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000220 0 0 0 0 7 5 5 nul 0 0 0 1 3 5 0 nul
0000240 0 0 0 0 1 5 4 nul 0 0 0 0 0 0 0 0
0000260 0 0 0 nul 1 0 6 3 5 7 6 5 2 7 4 nul
0000300 0 1 0 7 2 4 nul sp 5 nul nul nul nul nul nul nul
0000320 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000440 nul nul nul nul nul nul nul nul nul nul nul nul nul u s t
0000460 a r sp sp nul b l e a r nul nul nul nul nul nul
0000500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000520 nul nul nul nul nul s o f t w a r e nul nul nul
0000540 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001040 nul nul nul nul nul nul nul nul nul nul nul nul . / d e
0001060 s c r i p t i o n nul nul nul nul nul nul nul
0001100 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001220 0 0 0 0 6 4 4 nul 0 0 0 1 3 5 0 nul
0001240 0 0 0 0 1 5 4 nul 0 0 0 0 0 0 0 0
0001260 0 7 2 nul 1 0 6 3 5 7 6 5 2 7 4 nul
0001300 0 1 3 1 7 1 nul sp 0 nul nul nul nul nul nul nul
0001320 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001440 nul nul nul nul nul nul nul nul nul nul nul nul nul u s t
0001460 a r sp sp nul b l e a r nul nul nul nul nul nul
0001500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0001520 nul nul nul nul nul s o f t w a r e nul nul nul
0001540 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0002040 nul nul nul nul nul nul nul nul nul nul nul nul U n n a
0002060 m e d sp r e p o s i t o r y ; sp
0002100 e d i t sp t h i s sp f i l e sp t
0002120 o sp n a m e sp i t sp f o r sp g i
0002140 t w e b . nl nul nul nul nul nul nul nul nul nul nul
0002160 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003040 nul nul nul nul nul nul nul nul nul nul nul nul . / b r
0003060 a n c h e s / nul nul nul nul nul nul nul nul nul
0003100 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003220 0 0 0 0 7 5 5 nul 0 0 0 1 3 5 0 nul
0003240 0 0 0 0 1 5 4 nul 0 0 0 0 0 0 0 0
0003260 0 0 0 nul 1 0 6 3 5 7 6 5 2 7 3 nul
0003300 0 1 2 5 1 0 nul sp 5 nul nul nul nul nul nul nul
0003320 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
If I run this from the command-line, instead of a script, I get
this (and if it is redirected to a file instead of 'od', tar
can read it):
0000000 . / nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000140 nul nul nul nul 0 0 0 0 7 5 5 nul 0 0 0 1
0000160 3 5 0 nul 0 0 0 0 1 5 4 nul 0 0 0 0
0000200 0 0 0 0 0 0 0 nul 1 0 6 3 5 7 6 5
0000220 2 7 4 nul 0 1 0 7 2 4 nul sp 5 nul nul nul
0000240 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000400 nul u s t a r sp sp nul b l e a r nul nul
0000420 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000440 nul nul nul nul nul nul nul nul nul s o f t w a r
0000460 e nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001000 . / d e s c r i p t i o n nul nul nul
0001020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001140 nul nul nul nul 0 0 0 0 6 4 4 nul 0 0 0 1
0001160 3 5 0 nul 0 0 0 0 1 5 4 nul 0 0 0 0
0001200 0 0 0 0 0 7 2 nul 1 0 6 3 5 7 6 5
0001220 2 7 4 nul 0 1 3 1 7 1 nul sp 0 nul nul nul
0001240 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001400 nul u s t a r sp sp nul b l e a r nul nul
0001420 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0001440 nul nul nul nul nul nul nul nul nul s o f t w a r
0001460 e nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0001500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0002000 U n n a m e d sp r e p o s i t o
0002020 r y ; sp e d i t sp t h i s sp f i
0002040 l e sp t o sp n a m e sp i t sp f o
0002060 r sp g i t w e b . nl nul nul nul nul nul nul
0002100 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003000 . / b r a n c h e s / nul nul nul nul nul
0003020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003140 nul nul nul nul 0 0 0 0 7 5 5 nul 0 0 0 1
0003160 3 5 0 nul 0 0 0 0 1 5 4 nul 0 0 0 0
0003200 0 0 0 0 0 0 0 nul 1 0 6 3 5 7 6 5
0003220 2 7 3 nul 0 1 2 5 1 0 nul sp 5 nul nul nul
0003240 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003400 nul u s t a r sp sp nul b l e a r nul nul
0003420 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0003440 nul nul nul nul nul nul nul nul nul s o f t w a r
0003460 e nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0003500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
Bill
^ permalink raw reply
* Re: Stupid quoting...
From: Olivier Galibert @ 2007-06-19 20:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706191048570.4059@racer.site>
On Tue, Jun 19, 2007 at 10:50:31AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 19 Jun 2007, David Kastrup wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Don't just throw away backwards compatibility, only because it does
> > > not fit your wishes.
> >
> > There is no backwards compatibility involved here _at_ _all_.
>
> I was not talking about Git here. The specification for SMTP is not going
> to change just because you want it. There are still mail servers out there
> which speak 7-bit, and the standard requires you to cope with them.
There are standards to send 8-bit into 7-bit for email, and \xxx is in
none of them. And 8-to-7 encoding for email is not git's job in any
case unless git speaks SMTP directly. 8-to-7 is the mail client
responsability.
OG.
^ permalink raw reply
* Re: git exclude patterns for directory
From: Alex Riesen @ 2007-06-19 20:34 UTC (permalink / raw)
To: jimmy bahuleyan; +Cc: git
In-Reply-To: <20070619200821.GA16423@camelot>
jimmy bahuleyan, Tue, Jun 19, 2007 22:08:21 +0200:
> Is there a way where I could specify a pattern in .git/info/exclude that
> would make git ignore directories.
put it in .gitignore in the top-level directory (just the "IGNORE").
.gitignore works recursively.
^ permalink raw reply
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Alex Riesen @ 2007-06-19 20:09 UTC (permalink / raw)
To: Bill Lear; +Cc: David Kastrup, git
In-Reply-To: <18040.346.208040.842060@lisa.zopyra.com>
Bill Lear, Tue, Jun 19, 2007 18:16:26 +0200:
> % cat foo
> set -x
> type tar
> type cd
> (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates && tar xf -)
what would you see if your script contained:
set -x
(cd blt && tar cf - .) |less
?
Does the output look like a tar archive to you?
Can you share it with us if you're not sure?
^ permalink raw reply
* git exclude patterns for directory
From: jimmy bahuleyan @ 2007-06-19 20:08 UTC (permalink / raw)
To: git
(Please Cc on replies)
I just started using git (yes, newbie ;) and hit a problem that i cant
seem to solve.
Is there a way where I could specify a pattern in .git/info/exclude that
would make git ignore directories.
Suppose I had in each of my project's sub-directories a directory called
'IGNORE/', how do I make git ignore this directory (and all it's
contents)?
I tried putting in
IGNORE/*
but this only takes care of the directory in the root dir. Then I tried
*/IGNORE/*
which doesn't work for dirs at >1 depth. I did read gitignore man page
(and it looks impossible .. ):
So, is there any way I can do this without adding a gitignore file in
each of my sub-directories?
-jb
--
Tact is the art of making a point without making an enemy.
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Johannes Schindelin @ 2007-06-19 19:47 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706191239260.4740@iabervon.org>
Hi,
On Tue, 19 Jun 2007, Daniel Barkalow wrote:
> On Tue, 19 Jun 2007, Johannes Schindelin wrote:
>
> >
> > On Tue, 19 Jun 2007, Daniel Barkalow wrote:
> >
> > > In my branch at: git://iabervon.org/~barkalow/git builtin-fetch
> > >
> > > I have a bunch of not-for-merging history leading up to a C version
> > > of fetch which passes all of the tests except that:
> > >
> > > * it might be fetching too much with --depth.
> >
> > That should be fixable. (If I get more time this week than I expect,
> > I'll do it myself.)
>
> I just haven't taken the time to look at what it's supposed to do
> exactly, since I wasn't paying attention to the discussions there.
Come to think of it, I am not sure that it does the right thing in
existing code either. There are still a bunch of emails regarding shallow
clone in my inbox, awaiting calmer weather.
> > > * bundle isn't implemented.
> >
> > That's an easy one.
>
> Yeah, just a section in transport.c about it, but the functions I need
> aren't available directly and I got distracted until I was looking at my
> list of what tests I'd disabled.
What I meant is not that it is so easy that you should have done it. I
meant that this is so easy you should not bother with it, since I'll
gladly step in once builtin-fetch is otherwise feature complete.
> > > * when a branch config file section refers to a branches/* remote, the
> > > merge setting is used (if one is given), even though this isn't useful
> > > either way.
> >
> > Maybe this is the right time to cut off branches/* and remotes/*?
>
> It's not actually too difficult to support them, except for some weird
> combination cases that nobody would do anyway. I just made the remote.c
> config file parser generate the corresponding configurations from them,
> and the rest of the code doesn't have to care. The only oddity is that I
> had to support having a remote always auto-follow tags, even without
> tracking branches, because that's what branches/* did. But this is
> probably a reasonable thing to support as an option anyway.
As Junio said, I think in the interest of clean code we should
deprecate that, and eventually get rid of it. We could do that even before
builtin-fetch reaches 'next'...
Ciao,
Dscho
^ permalink raw reply
* Re: how to move with history?
From: Oliver Kullmann @ 2007-06-19 19:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070618210743.GA16397@steel.home>
Thanks for all the replies!
Now I see pretty clear; a quick summary
(in case somebody else wants to learn from this):
1.
"git mv file new_file" seems to be (exactly?) equivalent to
mv file new_file
git rm file
git add new_file
(Perhaps this information could be added to the git-mv-documentation?
I would have found it useful (since I had a different expectation).)
2. To do something with the history, for example to rename "file"
to "new_file" also in the whole history, a new repository (or
a new branch) has to be created. Three possibilities:
(a) Using the basic git-functionality, re-creating a repository
by re-creating all commits (with appropriate changes) by "hand"
or "script".
(b) More convenient, the upcoming "git-filter-branch" apparently
makes filtering out easier.
(c) Or, apparently more powerful, with "cg-admin-rewritehis"
(part of the cogito-tool) we have quite a powerful tool
for creating a branch with a (re-created and modified)
history (the documentation explicitely mentions how to
remove a file from history --- that is, in the new branch).
Hope that's correct.
Thanks a lot to all!
Oliver
^ permalink raw reply
* Re: git-gui cannot find share/git-gui under cygwin
From: Mark Levedahl @ 2007-06-19 18:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20070619144928.GA8477@spearce.org>
Shawn O. Pearce wrote:
> Yuck. I'm considering applying the following. It works ok on Mac
> OS X where the bug isn't triggered anyway. ;-) I won't be able to
> test on Cygwin until tomorrow.
>
>
sorry, no joy. The problem is that gitexecdir=/usr/bin, but...
/usr/bin is a Cygwin mount point that points at c:\cygwin\bin.
so...
$ cygpath -m -a /bin
C:/cygwin/bin
$ cygpath -m -a /usr
C:/cygwin/usr
$ cygpath -m -a /usr/bin
C:/cygwin/bin
$ cygpath -m -a /usr/share
C:/cygwin/usr/share
and the result is that both exedir_SQ and libdir_SQ have the value
/usr/share/git-gui-lib
I don't think there is a portable solution here. Maybe just say
if test "$(uname_O)" = Cygwin; then \
GITGUI_RELATIVE=; \
and be done with it.
Mark
^ permalink raw reply
* Directory renames (was Re: blame follows renames, but log doesn't)
From: Steven Grimm @ 2007-06-19 18:28 UTC (permalink / raw)
To: Theodore Tso; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <4677A7EF.500@midwinter.com>
Directory renames can break in more cases than just adding new files.
Here's a demonstration based on a situation I ran into a few minutes ago
on a real-world project.
$ git init
$ mkdir a
$ echo some contents > a/file1
$ echo other contents > a/file2
$ git add a
$ git commit -m "initial commit"
So far so good. Now there's a revision where the files happen to be
identical. (On a new branch for later convenience.)
$ git checkout -b modifybranch
$ echo other contents > a/file1
$ git commit -a -m "commit that makes both files identical"
Now we rename the directory. (Again, the new branch will be used later.)
$ git checkout -b renamebranch
$ git mv a b
$ git commit -m "rename directory"
Make a change to file2.
$ echo more contents from renamebranch >> b/file2
$ git commit -a -m "add contents to file2"
Where did file2's contents come from?
$ git blame b/file2
a7dbcfdc a/file1 (Steven Grimm 2007-06-19 10:36:20 -0700 1) other contents
69a87194 b/file2 (Steven Grimm 2007-06-19 10:43:29 -0700 2) more contents
Which is wrong. The history of file2 has nothing to do with the history
of file1, but git blame thinks it does. However, that's not what blew up
on me in my real-world test; it gets better. Let's say one of the files
changed in a different branch.
$ git checkout master
$ echo a change to file2 in master >> a/file2
$ git commit -a -m "file2 changed"
$ git merge renamebranch
Removed a/file1
Merge made by recursive.
a/file1 | 1 -
a/file2 => b/file1 | 0
b/file2 | 2 ++
3 files changed, 2 insertions(+), 1 deletions(-)
delete mode 100644 a/file1
rename a/file2 => b/file1 (100%)
create mode 100644 b/file2
And this is just completely broken. What it *should* do is give me
b/file1 with "other contents" from renamebranch, and b/file2 with a
merge conflict since I added a different line to it in each branch.
Instead, the merge succeeds with no conflict and applies the change in
my current branch to the wrong file:
$ cat b/file1
other contents
a change to file2 in master
$ cat b/file2
other contents
more contents from renamebranch
There's one more variation on this theme that's broken in a similar but
not identical way (this didn't happen in my real-world scenario but I
ran into it while coming up with the above test case):
$ git checkout modifybranch
$ echo a change to file2 in modifybranch >> a/file2
$ git commit -a -m "a change in modifybranch"
$ git merge renamebranch
CONFLICT (delete/modify): a/file2 deleted in renamebranch and modified
in HEAD. Version HEAD of a/file2 left in tree.
Automatic merge failed; fix conflicts and then commit the result.
This should definitely be a merge conflict, but it shouldn't be *this*
merge conflict. What I'd expect here would be b/file1 == "other
contents" and b/file2 with conflict markers.
$ ls a b
a:
file2
b:
file1 file2
$ cat a/file2
other contents
a change to file2 in modifybranch
$ cat b/file1
other contents
$ cat b/file2
other contents
more contents from renamebranch
In other words, no conflict markers at all, and I still have the old
directory "a" with one of its two files in original form, but not the
other file.
Hope that's illuminating or at least interesting to someone.
-Steve
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Junio C Hamano @ 2007-06-19 17:38 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0706191239260.4740@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> > * when a branch config file section refers to a branches/* remote, the
>> > merge setting is used (if one is given), even though this isn't useful
>> > either way.
>>
>> Maybe this is the right time to cut off branches/* and remotes/*?
>
> It's not actually too difficult to support them, except for some weird
> combination cases that nobody would do anyway. I just made the remote.c
> config file parser generate the corresponding configurations from them,
> and the rest of the code doesn't have to care. The only oddity is that I
> had to support having a remote always auto-follow tags, even without
> tracking branches, because that's what branches/* did. But this is
> probably a reasonable thing to support as an option anyway.
We should support repositories with older layouts for an
eternity in git timescale (that is usually 6mo to a year) after
announcing that they are deprecated (which hasn't happened yet,
but I think everybody agrees that deprecating branches/ and
remotes/ is a sane thing to do in 1.6.0 or so). Even if we give
clear migration path and script, having to convert them all at
once is a nuisance for the users.
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Frank Lichtenheld @ 2007-06-19 17:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0706191655490.4059@racer.site>
On Tue, Jun 19, 2007 at 04:57:21PM +0100, Johannes Schindelin wrote:
> [foo "bar\nbaz"]
> key = value
> gives
>
> foo.barbaz.key=value
for me this gives
foo.barnbaz.key=value
which is the intended behaviour AFAICT
(you mean the actual string '\' 'n' here, right? '\n' gives a syntax
error, also the intended behaviour)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Versioning file system
From: Jakub Narebski @ 2007-06-19 16:52 UTC (permalink / raw)
To: linux-kernel; +Cc: git, linux-fsdevel, git, linux-kernel
In-Reply-To: <6E9A6F9E-8948-40F2-9129-1F1491D49D83@mac.com>
Kyle Moffett wrote:
> On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>>> The question remains is where to implement versioning: directly in
>>> individual filesystems or in the vfs code so all filesystems can
>>> use it?
>>
>> Or not in the kernel at all. I've been doing versioning of the
>> types I described for years with user space code and I don't
>> remember feeling that I compromised in order not to involve the
>> kernel.
>>
>> Of course, if you want to do it with snapshots and COW, you'll have
>> to ask where in the kernel to put that, but that's not a file
>> versioning question; it's the larger snapshot question.
>
> What I think would be particularly interesting in this domain is
> something similar in concept to GIT, except in a file-system
[cut]
How it relates to ext3cow versioning (snapshotting) filesystem,
for example? ext3cow assumes linear history, which simplifies things
a bit.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Jakub Narebski @ 2007-06-19 16:46 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706191037590.4059@racer.site>
Johannes Schindelin wrote:
>> * when a branch config file section refers to a branches/* remote, the
>> merge setting is used (if one is given), even though this isn't useful
>> either way.
>
> Maybe this is the right time to cut off branches/* and remotes/*?
We should read branches/* and remotes/* for a long time; even if people
are using new version of git, their repositories are not necessarily
converted (and IIRC there is only script for remotes -> config, in contrib,
not in core git).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Daniel Barkalow @ 2007-06-19 16:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706191037590.4059@racer.site>
On Tue, 19 Jun 2007, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 19 Jun 2007, Daniel Barkalow wrote:
>
> > In my branch at: git://iabervon.org/~barkalow/git builtin-fetch
> >
> > I have a bunch of not-for-merging history leading up to a C version of
> > fetch which passes all of the tests except that:
> >
> > * it might be fetching too much with --depth.
>
> That should be fixable. (If I get more time this week than I expect, I'll
> do it myself.)
I just haven't taken the time to look at what it's supposed to do exactly,
since I wasn't paying attention to the discussions there.
> > * bundle isn't implemented.
>
> That's an easy one.
Yeah, just a section in transport.c about it, but the functions I need
aren't available directly and I got distracted until I was looking at my
list of what tests I'd disabled.
> > * when a branch config file section refers to a branches/* remote, the
> > merge setting is used (if one is given), even though this isn't useful
> > either way.
>
> Maybe this is the right time to cut off branches/* and remotes/*?
It's not actually too difficult to support them, except for some weird
combination cases that nobody would do anyway. I just made the remote.c
config file parser generate the corresponding configurations from them,
and the rest of the code doesn't have to care. The only oddity is that I
had to support having a remote always auto-follow tags, even without
tracking branches, because that's what branches/* did. But this is
probably a reasonable thing to support as an option anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git-svn: trailing slash in prefix is mandatory with --branches/-b
From: Gerrit Pape @ 2007-06-19 16:47 UTC (permalink / raw)
To: git
Make clear in the documentation that when using --branches/-b and
--prefix with 'init', the prefix must include a trailing slash.
This matches the actual behavior of git-svn, e.g.:
$ git svn init -Ttrunk -treleases -bbranches --prefix xxx \
http://svn.sacredchao.net/svn/quodlibet/
--prefix='xxx' must have a trailing slash '/'
$
This was noticed by R. Vanicat and reported through
http://bugs.debian.org/429443
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/git-svn.txt | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index c0d7d95..0a210e4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -66,9 +66,10 @@ COMMANDS
to the names of remotes if trunk/branches/tags are
specified. The prefix does not automatically include a
trailing slash, so be sure you include one in the
- argument if that is what you want. This is useful if
- you wish to track multiple projects that share a common
- repository.
+ argument if that is what you want. If --branches/-b is
+ specified, the prefix must include a trailing slash.
+ Setting a prefix is useful if you wish to track multiple
+ projects that share a common repository.
'fetch'::
Fetch unfetched revisions from the Subversion remote we are
--
1.5.2.1
^ permalink raw reply related
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Bill Lear @ 2007-06-19 16:16 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86k5u0q8q9.fsf@lola.quinscape.zz>
On Tuesday, June 19, 2007 at 17:12:14 (+0200) David Kastrup writes:
>Bill Lear <rael@zopyra.com> writes:
>>...
>> However, I still get this:
>>
>> install -d -m755 '/opt/git-1.5.2.2/share//git-core/templates/'
> ^^^
>> (cd blt && tar cf - .) | \
>> (cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
> ^^^
>> tar: This does not look like a tar archive
>> tar: Skipping to next header
>> tar: Archive contains obsolescent base-64 headers
>> tar: Error exit delayed from previous errors
>>
>> So, I did a make -k and it worked ok, aside from this error.
>>
>> I copied this line:
>>
>> (cd blt && tar cf - .) | \
>> (cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
> ^^^
>> into a file, chmod +x'd that file, and cd'd into templates and ran
>> the script. I got the same error. I then tried running it by
>> hand from the command line:
>>
>> % cd templates
>> % (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates
>> ^^^
>> && tar xf -)
>>
>> and it worked fine.
>
>Not sure whether this is the problem: either cd does not understasnd
>the double slashes, or your shell used for scripts has modified cd to
>output some stuff when it is working (people sometimes imprudently
>make shell functions or aliases for this).
>
>Try writing something like
>
>type cd
>
>in a script file and see what output you get.
% echo 'type cd' > foo
% chmod +x foo
% ./foo
cd is a shell builtin
% bash --version
GNU bash, version 3.1.17(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
I also tried using the double-slash on the command line. It worked
fine. I tried a single slash from the script and it did not work.
% cd templates
% cat foo
set -x
type tar
type cd
(cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates && tar xf -)
% ./foo
++ type tar
tar is /bin/tar
++ type cd
cd is a shell builtin
++ cd blt
++ tar cf - .
++ cd /opt/git-1.5.2.2/share/git-core/templates
++ tar xf -
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors
Bill
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Jakub Narebski @ 2007-06-19 11:50 UTC (permalink / raw)
To: Johannes Schindelin, Frank Lichtenheld; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706191208300.4059@racer.site>
Johannes Schindelin wrote:
> On Tue, 19 Jun 2007, Frank Lichtenheld wrote:
>> On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:
>>> Another possibility, though, is to say:
>>>
>>> core.some\0where\0core.over\0\0core.the\0core.rainbow\0
>>
>> How do you denote empty values then?
>>
>> [section]
>> key=
>> key
>>
>> this are two very different statements atm (e.g. the one is false and
>> the other one is true).
>>
>> I still think using two different delimiters is the simplest choice.
>
> Okay, good point. But of course, you have to use a delimiter for the key
> name that cannot be part of the keyname. You picked '\n'. The original was
> '='. Both work.
If I remember correctly (and what I checked to be true), while '=' cannot
be part of keyname nor section name, it can be part of subsection name,
therefore it can be part of fuly qualified key name.
The '\n' can _not_ be part of subsection name, therefore it can not be
part of fully qualified key name.
$ cat > conftest <<EOF
[section "sub=section"]
truekey=true
emptykey=
novalkey
EOF
$ GIT_CONFIG=conftest git-config -l
section.sub=section.truekey=true
section.sub=section.emptykey=
section.sub=section.novalkey
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Johannes Schindelin @ 2007-06-19 15:57 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Junio C Hamano, Git Mailing List, Jakub Narebski
In-Reply-To: <20070619152139.GF19725@planck.djpig.de>
Hi,
On Tue, 19 Jun 2007, Frank Lichtenheld wrote:
> On Tue, Jun 19, 2007 at 12:09:18PM +0100, Johannes Schindelin wrote:
> > Okay, good point. But of course, you have to use a delimiter for the key
> > name that cannot be part of the keyname. You picked '\n'. The original was
> > '='. Both work.
>
> No, they actually don't.
Right, I completely forgot that we actually allow all kinds of special
characters, in order to be able to say "branch.<branchname>.merge" for all
kinds of branchnames.
Incidentally, I think I found a bug:
[foo "bar\nbaz"]
key = value
gives
foo.barbaz.key=value
Ciao,
Dscho
^ permalink raw reply
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: David Kastrup @ 2007-06-19 15:12 UTC (permalink / raw)
To: git
In-Reply-To: <18039.60598.264803.940960@lisa.zopyra.com>
Bill Lear <rael@zopyra.com> writes:
> On Tuesday, June 19, 2007 at 16:30:00 (+0200) Marco Roeland writes:
>>On Tuesday June 19th 2007 at 08:50 Bill Lear wrote:
>>>
>>> I checked and there is no iconv package (rpm). I really don't want
>>> to have to temporarily rename a header. I can't hand this out to
>>> the rest of the company, some of whom do not have root access to
>>> be able to rename header files.
>>
>>You might at least investigate if there is somehow another iconv.h
>>header besides the system one under /usr/include, that might have been
>>used by the compiler instead of the standard one from GNU libc.
>
> Ok, I moved all the *iconv* stuff in /usr/local/<blah> and now
> it builds ok.
>
> However, I still get this:
>
> install -d -m755 '/opt/git-1.5.2.2/share//git-core/templates/'
^^^
> (cd blt && tar cf - .) | \
> (cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
^^^
> tar: This does not look like a tar archive
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
> tar: Error exit delayed from previous errors
>
> So, I did a make -k and it worked ok, aside from this error.
>
> I copied this line:
>
> (cd blt && tar cf - .) | \
> (cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
^^^
> into a file, chmod +x'd that file, and cd'd into templates and ran
> the script. I got the same error. I then tried running it by
> hand from the command line:
>
> % cd templates
> % (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates
> ^^^
> && tar xf -)
>
> and it worked fine.
Not sure whether this is the problem: either cd does not understasnd
the double slashes, or your shell used for scripts has modified cd to
output some stuff when it is working (people sometimes imprudently
make shell functions or aliases for this).
Try writing something like
type cd
in a script file and see what output you get.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Frank Lichtenheld @ 2007-06-19 15:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0706191208300.4059@racer.site>
On Tue, Jun 19, 2007 at 12:09:18PM +0100, Johannes Schindelin wrote:
> Okay, good point. But of course, you have to use a delimiter for the key
> name that cannot be part of the keyname. You picked '\n'. The original was
> '='. Both work.
No, they actually don't.
Example:
$ cat .git/config
[foo "bar=baz"]
key = value
[foo]
key = key=value
$ git config -l
foo.bar=baz.key=value
foo.key=key=value
So how do I parse that?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: David Kastrup @ 2007-06-19 14:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706191457440.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 19 Jun 2007, Bill Lear wrote:
>
>> On Tuesday, June 19, 2007 at 14:00:07 (+0100) Johannes Schindelin writes:
>> >
>> >On Tue, 19 Jun 2007, Bill Lear wrote:
>> >
>> >> Also breaks (tar fails) if I do the 'make configure; ./configure'
>> >> route.
>> >
>> >Then there is a test missing in configure.
>>
>> Here is the particular error:
>>
>> install git '/opt/git-1.5.2.2/bin'
>> make -C templates DESTDIR='' install
>> make[1]: Entering directory `/home/blear/build/git-1.5.2.2/templates'
>> install -d -m755 '/opt/git-1.5.2.2/share/git-core/templates/'
>> (cd blt && gtar cf - .) | \
>> (cd '/opt/git-1.5.2.2/share/git-core/templates/' && gtar xf -)
>> gtar: This does not look like a tar archive
>> gtar: Skipping to next header
>> gtar: Archive contains obsolescent base-64 headers
>> gtar: Error exit delayed from previous errors
>> make[1]: *** [install] Error 2
>> make[1]: Leaving directory `/home/blear/build/git-1.5.2.2/templates'
>> make: *** [install] Error 2
>
> WTF? gtar cannot read its own output?
>
> Be that as may, this is not git error.
It is possible that cd is an alias outputting the target of cd.
People do those kind of things. It is also possible that the first cd
fails and thus the first gtar is not run (though tar xf /dev/null is
quiet here, so probably should be at the OP's site, too.).
--
David Kastrup
^ 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