* Re: A note on merging conflicts..
From: Daniel Barkalow @ 2006-07-01 23:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011905030.9789@iabervon.org>
On Sat, 1 Jul 2006, Daniel Barkalow wrote:
> Actually, I think that it would work to have object flags "LEFT" and
> "RIGHT", mark b with left, mark c with right, and mark anything with both
> LEFT and RIGHT as UNINTERESTING as we go through the revisions. The
> time-ordering problem with symmetric difference isn't absent with regular
> difference, and, assuming that b..c works in the tricky cases, the same
> logic should handle symmetric difference.
That is: (this only has the logic portion, and it's against master, so it
isn't actually a really working patch or anything; also, it doesn't handle
"--not a...b" correctly, whatever that should mean)
---
diff --git a/revision.c b/revision.c
index 6a6952c..c21d332 100644
--- a/revision.c
+++ b/revision.c
@@ -351,6 +351,9 @@ static void add_parents_to_list(struct r
return;
commit->object.flags |= ADDED;
+ if (commit->object.flags & LEFT && commit->objects.flags & RIGHT)
+ commit->object.flags |= UNINTERESTING;
+
/*
* If the commit is uninteresting, don't try to
* prune parents - we want the maximal uninteresting
@@ -781,8 +784,13 @@ int setup_revisions(int argc, const char
struct object *exclude;
struct object *include;
- exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
- include = get_reference(revs, next, sha1, flags);
+ if (symmetric) {
+ exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
+ include = get_reference(revs, next, sha1, flags);
+ } else {
+ exclude = get_reference(revs, this, from_sha1, flags | LEFT_HALF);
+ include = get_reference(revs, next, sha1, flags | RIGHT_HALF);
+ }
if (!exclude || !include)
die("Invalid revision range %s..%s", arg, next);
diff --git a/revision.h b/revision.h
index 7d85b0f..93421e6 100644
--- a/revision.h
+++ b/revision.h
@@ -9,6 +9,8 @@
#define BOUNDARY (1u<<5)
#define BOUNDARY_SHOW (1u<<6)
#define ADDED (1u<<7) /* Parents already parsed and added? */
+#define LEFT_HALF (1u<<8) /* Reachable from start of dotdotdot */
+#define RIGHT_HALF (1u<<9) /* Reachable from end of dotdotdot */
struct rev_info;
struct log_info;
--
1.2.4
^ permalink raw reply related
* Re: [PATCH 1/3] Add get_merge_bases_clean()
From: Johannes Schindelin @ 2006-07-01 23:43 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20060701232926.GA2513@lsrfire.ath.cx>
Hi,
On Sun, 2 Jul 2006, Rene Scharfe wrote:
> Also move the object flags used in get_merge_bases() out of the range
> defined in revision.h. This fixes the "66ae0c77...ced9456a
> 89719209...262a6ef7" test of the ... operator which is introduced with
> the next patch.
Of COURSE! *hits his head on the table; table breaks; has to buy a new
table*
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Git.pm: Remove PerlIO usage from Git.xs
From: Petr Baudis @ 2006-07-01 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
PerlIO_*() is not portable before 5.7.3, according to ppport.h, and it's
more clear what is going on when we do it in the Perl part of the Git module
anyway.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/Git.pm | 14 +++++++++++++-
perl/Git.xs | 56 +++++++++++++++++++++++++-------------------------------
2 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 0581447..b4ee88b 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -511,7 +511,19 @@ are involved.
=cut
-# Implemented in Git.xs.
+sub hash_object {
+ my ($self, $type, $file) = _maybe_self(@_);
+
+ # hash_object_* implemented in Git.xs.
+
+ if (ref($file) eq 'GLOB') {
+ my $hash = hash_object_pipe($type, fileno($file));
+ close $file;
+ return $hash;
+ } else {
+ hash_object_file($type, $file);
+ }
+}
diff --git a/perl/Git.xs b/perl/Git.xs
index 3030ba9..cb23261 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -104,42 +104,36 @@ CODE:
}
char *
-xs_hash_object(type, file)
+xs_hash_object_pipe(type, fd)
char *type;
- SV *file;
+ int fd;
CODE:
{
unsigned char sha1[20];
- if (SvTYPE(file) == SVt_RV)
- file = SvRV(file);
-
- if (SvTYPE(file) == SVt_PVGV) {
- /* Filehandle */
- PerlIO *pio;
-
- pio = IoIFP(sv_2io(file));
- if (!pio)
- croak("You passed me something weird - a dir glob?");
- /* XXX: I just hope PerlIO didn't read anything from it yet.
- * --pasky */
- if (index_pipe(sha1, PerlIO_fileno(pio), type, 0))
- croak("Unable to hash given filehandle");
- /* Avoid any nasty surprises. */
- PerlIO_close(pio);
-
- } else {
- /* String */
- char *path = SvPV_nolen(file);
- int fd = open(path, O_RDONLY);
- struct stat st;
-
- if (fd < 0 ||
- fstat(fd, &st) < 0 ||
- index_fd(sha1, fd, &st, 0, type))
- croak("Unable to hash %s", path);
- close(fd);
- }
+ if (index_pipe(sha1, fd, type, 0))
+ croak("Unable to hash given filehandle");
+ RETVAL = sha1_to_hex(sha1);
+}
+OUTPUT:
+ RETVAL
+
+char *
+xs_hash_object_file(type, path)
+ char *type;
+ char *path;
+CODE:
+{
+ unsigned char sha1[20];
+ int fd = open(path, O_RDONLY);
+ struct stat st;
+
+ if (fd < 0 ||
+ fstat(fd, &st) < 0 ||
+ index_fd(sha1, fd, &st, 0, type))
+ croak("Unable to hash %s", path);
+ close(fd);
+
RETVAL = sha1_to_hex(sha1);
}
OUTPUT:
^ permalink raw reply related
* [PATCH 3/3] Make clear_commit_marks() clean harder
From: Rene Scharfe @ 2006-07-01 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Linus Torvalds
In-Reply-To: <7vpsgpccak.fsf@assigned-by-dhcp.cox.net>
Don't care if objects have been parsed or not and don't stop when we
reach a commit that is already clean -- its parents could be dirty.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
commit.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/commit.c b/commit.c
index 593414d..70a4eff 100644
--- a/commit.c
+++ b/commit.c
@@ -397,13 +397,12 @@ void clear_commit_marks(struct commit *c
{
struct commit_list *parents;
+ if (!commit)
+ return;
parents = commit->parents;
commit->object.flags &= ~mark;
while (parents) {
- struct commit *parent = parents->item;
- if (parent && parent->object.parsed &&
- (parent->object.flags & mark))
- clear_commit_marks(parent, mark);
+ clear_commit_marks(parents->item, mark);
parents = parents->next;
}
}
--
1.4.1.rc2.gfc04
^ permalink raw reply related
* [PATCH 2/3] Add '...' operator for revisions
From: Rene Scharfe @ 2006-07-01 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Linus Torvalds
In-Reply-To: <7vpsgpccak.fsf@assigned-by-dhcp.cox.net>
'A...B' is a shortcut for 'A B --not $(git-merge-base --all A B)'.
This XOR-like operation is called symmetric difference in set
theory.
The symbol '...' has been chosen because it's rather similar to the
existing '..' operator and the somewhat more natural caret ('^') is
already taken.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/git-rev-list.txt | 14 ++++++++++++
revision.c | 48 +++++++++++++++++++++++++++++++++-------
2 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index ad6d14c..6c370e1 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -15,6 +15,7 @@ SYNOPSIS
[ \--sparse ]
[ \--no-merges ]
[ \--remove-empty ]
+ [ \--not ]
[ \--all ]
[ \--topo-order ]
[ \--parents ]
@@ -37,6 +38,14 @@ not in 'baz'".
A special notation <commit1>..<commit2> can be used as a
short-hand for {caret}<commit1> <commit2>.
+Another special notation is <commit1>...<commit2> which is useful for
+merges. The resulting set of commits is the symmetric difference
+between the two operands. The following two commands are equivalent:
+
+------------
+$ git-rev-list A B --not $(git-merge-base --all A B)
+$ git-rev-list A...B
+------------
OPTIONS
-------
@@ -93,6 +102,11 @@ OPTIONS
--remove-empty::
Stop when a given path disappears from the tree.
+--not::
+ Reverses the meaning of the '{caret}' prefix (or lack
+ thereof) for all following revision specifiers, up to
+ the next `--not`.
+
--all::
Pretend as if all the refs in `$GIT_DIR/refs/` are
listed on the command line as <commit>.
diff --git a/revision.c b/revision.c
index b963f2a..9eb0b6d 100644
--- a/revision.c
+++ b/revision.c
@@ -536,6 +536,18 @@ void init_revisions(struct rev_info *rev
diff_setup(&revs->diffopt);
}
+static void add_pending_commit_list(struct rev_info *revs,
+ struct commit_list *commit_list,
+ unsigned int flags)
+{
+ while (commit_list) {
+ struct object *object = &commit_list->item->object;
+ object->flags |= flags;
+ add_pending_object(revs, object, sha1_to_hex(object->sha1));
+ commit_list = commit_list->next;
+ }
+}
+
/*
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
@@ -771,27 +783,45 @@ int setup_revisions(int argc, const char
unsigned char from_sha1[20];
const char *next = dotdot + 2;
const char *this = arg;
+ int symmetric = *next == '.';
+ unsigned int flags_exclude = flags ^ UNINTERESTING;
+
*dotdot = 0;
+ next += symmetric;
+
if (!*next)
next = "HEAD";
if (dotdot == arg)
this = "HEAD";
if (!get_sha1(this, from_sha1) &&
!get_sha1(next, sha1)) {
- struct object *exclude;
- struct object *include;
-
- exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
- include = get_reference(revs, next, sha1, flags);
- if (!exclude || !include)
- die("Invalid revision range %s..%s", arg, next);
+ struct commit *a, *b;
+ struct commit_list *exclude;
+
+ a = lookup_commit_reference(from_sha1);
+ b = lookup_commit_reference(sha1);
+ if (!a || !b) {
+ die(symmetric ?
+ "Invalid symmetric difference expression %s...%s" :
+ "Invalid revision range %s..%s",
+ arg, next);
+ }
if (!seen_dashdash) {
*dotdot = '.';
verify_non_filename(revs->prefix, arg);
}
- add_pending_object(revs, exclude, this);
- add_pending_object(revs, include, next);
+
+ if (symmetric) {
+ exclude = get_merge_bases_clean(a, b);
+ add_pending_commit_list(revs, exclude,
+ flags_exclude);
+ a->object.flags |= flags;
+ } else
+ a->object.flags |= flags_exclude;
+ b->object.flags |= flags;
+ add_pending_object(revs, &a->object, this);
+ add_pending_object(revs, &b->object, next);
continue;
}
*dotdot = '.';
--
1.4.1.rc2.gfc04
^ permalink raw reply related
* [PATCH 1/3] Add get_merge_bases_clean()
From: Rene Scharfe @ 2006-07-01 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Linus Torvalds
In-Reply-To: <7vpsgpccak.fsf@assigned-by-dhcp.cox.net>
Add get_merge_bases_clean(), a wrapper for get_merge_bases() that cleans
up after doing its work and make get_merge_bases() NOT clean up.
Single-shot programs like git-merge-base can use the dirty and fast
version.
Also move the object flags used in get_merge_bases() out of the range
defined in revision.h. This fixes the "66ae0c77...ced9456a
89719209...262a6ef7" test of the ... operator which is introduced with
the next patch.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
All object flags should probably be gathered into one place to avoid
future conflicts.
commit.c | 20 ++++++++++++++++----
commit.h | 1 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/commit.c b/commit.c
index 0431027..593414d 100644
--- a/commit.c
+++ b/commit.c
@@ -849,9 +849,10 @@ void sort_in_topological_order_fn(struct
/* merge-rebase stuff */
-#define PARENT1 1
-#define PARENT2 2
-#define UNINTERESTING 4
+/* bits #0..7 in revision.h */
+#define PARENT1 (1u<< 8)
+#define PARENT2 (1u<< 9)
+#define UNINTERESTING (1u<<10)
static struct commit *interesting(struct commit_list *list)
{
@@ -1080,9 +1081,20 @@ struct commit_list *get_merge_bases(stru
tmp = next;
}
- /* reset flags */
+ return result;
+}
+
+struct commit_list *get_merge_bases_clean(struct commit *rev1,
+ struct commit *rev2)
+{
+ unsigned int flags1 = rev1->object.flags;
+ unsigned int flags2 = rev2->object.flags;
+ struct commit_list *result = get_merge_bases(rev1, rev2);
+
clear_commit_marks(rev1, PARENT1 | PARENT2 | UNINTERESTING);
clear_commit_marks(rev2, PARENT1 | PARENT2 | UNINTERESTING);
+ rev1->object.flags = flags1;
+ rev2->object.flags = flags2;
return result;
}
diff --git a/commit.h b/commit.h
index 89b9dad..3a26e29 100644
--- a/commit.h
+++ b/commit.h
@@ -106,5 +106,6 @@ int register_commit_graft(struct commit_
int read_graft_file(const char *graft_file);
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2);
+extern struct commit_list *get_merge_bases_clean(struct commit *rev1, struct commit *rev2);
#endif /* COMMIT_H */
--
1.4.1.rc2.gfc04
^ permalink raw reply related
* Re: A note on merging conflicts..
From: Daniel Barkalow @ 2006-07-01 23:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011552170.12404@g5.osdl.org>
On Sat, 1 Jul 2006, Linus Torvalds wrote:
> On Sat, 1 Jul 2006, Daniel Barkalow wrote:
> >
> > I think a...b can be computed by (in pseudocode, obviously):
>
> Nope.
>
> > It's basically the original merge-bases code, from way back;
>
> And it has basically the same bug.
>
> It is possible to have
>
> a
> / \
> b c
> |\ /|
> d e f
> \|/
> g
>
> and clearly "e" is the only valid merge-base of b and c.
>
> HOWEVER. It's actually possible that we traverse d, f and g before we even
> look at 'e' (because somebody had a bogus date, and 'e' _looks_ old).
But that wouldn't actually affect b...c, because we don't actually care
that 'e' is the correct merge-base and 'g' is not, because "b c ^e ^g" is
the same as "b c ^e".
Your point is correct, though; if we look at e before c, we could think
that it's interesting when it isn't, so we have to wait until we've
drained the list to output anything.
> So that's why git-merge-base has all that extra "unnecessary" complexity.
> You cannot output anything at all until you've guaranteed that all pending
> objects are uninteresting.
That's not all the complexity in git-merge-base, though. There's a ton
more that's about why e is right and g is wrong in your example, and we
don't care about *that* part in b...c.
Actually, I think that it would work to have object flags "LEFT" and
"RIGHT", mark b with left, mark c with right, and mark anything with both
LEFT and RIGHT as UNINTERESTING as we go through the revisions. The
time-ordering problem with symmetric difference isn't absent with regular
difference, and, assuming that b..c works in the tricky cases, the same
logic should handle symmetric difference.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* INVITATION.....................................................
From: Miss Violet Tesyi @ 2006-07-01 15:40 UTC (permalink / raw)
Dear Friend,
My name is Violet Tesyi, female, working with (WORLD YOUTH ORGANIZATION
FOR HUMAN WELFARE) California, U.S.A. We are organizing a global youths
combined conferences taking place from August 14th-16th 2006 at
California in the United States and in ,Dakar Senegal from August
21th-23th 2006 .In our request to invite people from various countries
around the world, I went in search of e-mails on the web site as a
means of contacting youths and organizations .
*As a result, I picked your e-mail from an N.G.O`s website. If you are interested
to participate and want to represent your country, you may contact the secretariat
of the organizing committee for details and information. You should also
inform them that you were invited to participate by a friend of yours (Violet Tesyi), who is a member of the American Youths 4 Peace and a staff of(WORLD YOUTH ORGANIZATION FOR HUMAN WELFARE).
I believe that we may have the opportunity to meet if you may be willing to participate
in this event. You can also inform youths & NGOs in your country about
these conferences.
The benevolent donors of the Organizing Committee will provide round trip air tickets and accommodation for the period of participants? stay in the U.S., to all registered participants. If you are a holder of passport that may require visa to enter the United States you may inform the conference secretariat at the time of registration, as the organizing committee is responsible for all visa arrangements and travel assistances. Below is the contact address of the conference secretariat (Miss Anny Morre).
EMAIL: icorcar112conferences@comic.com
By Tel/Fax: 1-425-671-3781
Please reply me Via: violet_usa_conference@yahoo.ca
Sincerely,
Violet Tesyi
^ permalink raw reply
* Re: A note on merging conflicts..
From: Johannes Schindelin @ 2006-07-01 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rene Scharfe, git
In-Reply-To: <7vzmftcd60.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 1 Jul 2006, Junio C Hamano wrote:
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
> > I wonder why the two clear_commit_marks() calls at the end of
> > get_merge_bases() are not sufficient, though.
I wonder, too. In all of my tests, this call was sufficient to reset the
marks. I really wonder what happens here. At least one of the three flags
should be set in _any_ commit get_merge_bases() touches. Help!
> I missed to notice that Johannes had added those calls there; we
> should remove them from get_merge_bases().
As you hinted with your patch in another mail: no, we should not. Stuff
them into an if(), yes. But the point of a library function is not to make
it hard on users, but rather to make life easier. The user should _not_
have to investigate which loops to jump through to make use of this
function several times.
> The normal case of git-merge-base calling get_merge_bases() once
> and exiting should NOT have to pay for the clean-up cost at all.
Note that this was partly the reason for my hesitation to propose this
patch for inclusion already. If you make this function a library function,
the main user is _not_ git-merge-base any more. Everybody can use it from
now on.
Ciao,
Dscho
P.S.: I was having to much fun tonight to investigate in detail... Sorry.
^ permalink raw reply
* Re: [PATCH] Add possibility to pass CFLAGS and LDFLAGS specific to the perl subdir
From: Petr Baudis @ 2006-07-01 22:59 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Junio C Hamano, git
In-Reply-To: <20060626222308.G71066338@leonov.stosberg.net>
Dear diary, on Tue, Jun 27, 2006 at 12:23:08AM CEST, I got a letter
where Dennis Stosberg <dennis@stosberg.net> said that...
> Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
> ---
> Makefile | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index f44fbd3..306025d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -94,6 +94,8 @@ CFLAGS = -g -O2 -Wall
> LDFLAGS =
> ALL_CFLAGS = $(CFLAGS)
> ALL_LDFLAGS = $(LDFLAGS)
> +PERL_CFLAGS =
> +PERL_LDFLAGS =
> STRIP ?= strip
>
> prefix = $(HOME)
Just an annotation:
ALL_* means "use these flags for compilation of all the stuff
except perly stuff"
PERL_* means "use these flags for compilation of really all the
stuff"
So "all" might not mean what you think and Perl is stonger than
everything.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: A note on merging conflicts..
From: Linus Torvalds @ 2006-07-01 22:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011754370.9789@iabervon.org>
On Sat, 1 Jul 2006, Daniel Barkalow wrote:
>
> I think a...b can be computed by (in pseudocode, obviously):
Nope.
> It's basically the original merge-bases code, from way back;
And it has basically the same bug.
It is possible to have
a
/ \
b c
|\ /|
d e f
\|/
g
and clearly "e" is the only valid merge-base of b and c.
HOWEVER. It's actually possible that we traverse d, f and g before we even
look at 'e' (because somebody had a bogus date, and 'e' _looks_ old).
Remember: in a distributed system we have no global clock, so any graph
traversal ordering we choose is by definition always arbitrary, even
though we can obviously _try_ to choose one that is efficient in practice
(ie the "sort the heap by date).
So that's why git-merge-base has all that extra "unnecessary" complexity.
You cannot output anything at all until you've guaranteed that all pending
objects are uninteresting.
Linus
^ permalink raw reply
* (unknown),
From: Mark @ 2006-07-01 15:33 UTC (permalink / raw)
To: git
One of your friends used our send-to-a-friend-option: Check this out:
register for job alert, as well as i did - http://job-alert.net
^ permalink raw reply
* Re: [PATCH/RFC] Add git-instaweb, instantly browse the working repo with gitweb
From: Bertrand Jacquin @ 2006-07-01 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <7vwtayh56z.fsf@assigned-by-dhcp.cox.net>
On 6/30/06, Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > I got tired of having to configure gitweb for every repository
> > I work on. I sometimes prefer gitweb to standard GUIs like gitk
> > or gitview; so this lets me automatically configure gitweb to
> > browse my working repository and also opens my browser to it.
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
>
> This is cute but I haven't seen much responses to it yet. Are
> people uninterested?
I am.
--
# Beber : beber@gna.org
# IM : beber@jabber.fr
# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
^ permalink raw reply
* Re: [PATCH] Enable tree (directory) history display
From: Luben Tuikov @ 2006-07-01 22:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606302029310.12404@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> That count of 145 is the number of commits that actually _change_ Makefile
> some way - and some of them really are merges, because they have a content
> merge, and the merge result is thus different from any of the children. So
> that's a real number. So is 136, in some sense - it just says that we
> don't care about commits, even if those commits _do_ end up changing the
> file.
Indeed, I got the same conclusion using different branches.
(Sorry, I thought your email was from Junio in my last email, it was
your analysis after all.)
> But the important part to realize is that the "971" number is always
> wrong. It's never a really valid number. It contains a lot of extra
> merges, but it does _not_ contain enough of them to connect all the dots,
> and it's thus never correct. Either you should drop merges that don't
> change things (in which case you cannot have full connectivity, and
> "--parents" doesn't make sense), or you should keep them all (or at least
> enough to get full connectivity).
Yes, that makes sense.
Ok, I get similar numbers as you do. After the patch, compared to
the simple case of git-rev-list HEAD -- <path spec>, --parents gives
me only one more commit which is the very first hand made kernel
commit ;-) ; --parents --full-history gives me way too many unrelated
commits about 10x as many; --full-history gives me a _complete_ list.
The simple case fails to report a few commits which are
due to merges, which do indeed change files in the path spec.
(--full-history successfully reported those though).
So your patch plus "--full-history" is what I think we want.
Luben
^ permalink raw reply
* Re: A note on merging conflicts..
From: Daniel Barkalow @ 2006-07-01 22:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011115500.12404@g5.osdl.org>
On Sat, 1 Jul 2006, Linus Torvalds wrote:
> That said, it does have a real downside, and that's simply that it can
> take a long time to compute.
I think a...b can be computed by (in pseudocode, obviously):
mark(a, 1);
add(list, a);
mark(b, 2);
add(list, b);
while (interesting(list)) {
if (*list->marks != 3)
output(*list);
for (parent : *list->parents) {
mark(parent, *list->marks);
add(list, parent);
}
}
It's basically the original merge-bases code, from way back; the several
flaws with it for computing a good merge base don't matter if you're just
excluding the merge bases. If you look at the big examples in merge-base.c
(pre-libification), it's obvious that what we want for a...b is everything
marked 1 or 2, and the trickiness in that code is getting things correctly
marked 3 versus 7, which doesn't matter here.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH/RFC (updated)] Add git-instaweb, instantly browse the working repo with gitweb
From: Eric Wong @ 2006-07-01 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtayh56z.fsf@assigned-by-dhcp.cox.net>
I got tired of having to configure gitweb for every repository
I work on. I sometimes prefer gitweb to standard GUIs like gitk
or gitview; so this lets me automatically configure gitweb to
browse my working repository and also opens my browser to it.
Updates from the original patch:
Added Apache/mod_perl2 compatibility if Dennis Stosberg's gitweb
has been applied, too: <20060621130708.Gcbc6e5c@leonov.stosberg.net>
General cleanups in shell code usage.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > I got tired of having to configure gitweb for every repository
> > I work on. I sometimes prefer gitweb to standard GUIs like gitk
> > or gitview; so this lets me automatically configure gitweb to
> > browse my working repository and also opens my browser to it.
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
>
> This is cute but I haven't seen much responses to it yet. Are
> people uninterested?
I've found it very useful myself, but I wouldn't have made it if I
didn't :) It's somewhat of a strange and alien concept in GUIs, and
will probably take some getting used to; but I think it can gain users
quickly because it doesn't rely on any specific toolkits, and can be
expanded to support more HTTP servers.
If anything, it can also serve as short and simple documentation for
setting up gitweb.
.gitignore | 1
Documentation/git-instaweb.txt | 84 ++++++++++++++
Makefile | 16 +++
git-instaweb.sh | 235 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 335 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7b954d5..2bcc604 100644
--- a/.gitignore
+++ b/.gitignore
@@ -46,6 +46,7 @@ git-http-push
git-imap-send
git-index-pack
git-init-db
+git-instaweb
git-local-fetch
git-log
git-lost-found
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
new file mode 100644
index 0000000..7dd393b
--- /dev/null
+++ b/Documentation/git-instaweb.txt
@@ -0,0 +1,84 @@
+git-instaweb(1)
+===============
+
+NAME
+----
+git-instaweb - instantly browse your working repository in gitweb
+
+SYNOPSIS
+--------
+'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+
+'git-instaweb' [--start] [--stop] [--restart]
+
+DESCRIPTION
+-----------
+A simple script to setup gitweb and a web server for browsing the local
+repository.
+
+OPTIONS
+-------
+
+-l|--local::
+ Only bind the web server to the local IP (127.0.0.1).
+
+-d|--httpd::
+ The HTTP daemon command-line that will be executed.
+ Command-line options may be specified here, and the
+ configuration file will be added at the end of the command-line.
+ Currently, lighttpd and apache2 are the only supported servers.
+ (Default: lighttpd)
+
+-m|--module-path::
+ The module path (only needed if httpd is Apache).
+ (Default: /usr/lib/apache2/modules)
+
+-p|--port::
+ The port number to bind the httpd to. (Default: 1234)
+
+-b|--browser::
+
+ The web browser command-line to execute to view the gitweb page.
+ If blank, the URL of the gitweb instance will be printed to
+ stdout. (Default: 'firefox')
+
+--start::
+ Start the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance.
+
+--stop::
+ Stop the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance,
+ nor does it close the browser.
+
+--restart::
+ Restart the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance.
+
+CONFIGURATION
+-------------
+
+You may specify configuration in your .git/config
+
+-----------------------------------------------------------------------
+[instaweb]
+ local = true
+ httpd = apache2 -f
+ port = 4321
+ browser = konqueror
+ modulepath = /usr/lib/apache2/modules
+
+-----------------------------------------------------------------------
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>
+
+Documentation
+--------------
+Documentation by Eric Wong <normalperson@yhbt.net>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index cde619c..83d8922 100644
--- a/Makefile
+++ b/Makefile
@@ -142,7 +142,7 @@ SCRIPT_PYTHON = \
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- git-cherry-pick git-status
+ git-cherry-pick git-status git-instaweb
# The ones that do not have to link with lcrypto, lz nor xdiff.
SIMPLE_PROGRAMS = \
@@ -545,6 +545,20 @@ git-status: git-commit
cp $< $@+
mv $@+ $@
+git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
+ rm -f $@ $@+
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
+ $@.sh | sed \
+ -e 's|@@GITWEB_CGI@@|#!$(PERL_PATH_SQ)|; T; r gitweb/gitweb.cgi' \
+ | sed \
+ -e 's|@@GITWEB_CSS@@||; T; r gitweb/gitweb.css' \
+ > $@+
+ chmod +x $@+
+ mv $@+ $@
+
# These can record GIT_VERSION
git$X git.spec \
$(patsubst %.sh,%,$(SCRIPT_SH)) \
diff --git a/git-instaweb.sh b/git-instaweb.sh
new file mode 100755
index 0000000..51067d9
--- /dev/null
+++ b/git-instaweb.sh
@@ -0,0 +1,235 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Eric Wong
+#
+USAGE='[--start] [--stop] [--restart]
+ [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+ [--module-path=<path> (for Apache2 only)]'
+
+. git-sh-setup
+
+case "$GIT_DIR" in
+/*)
+ fqgitdir="$GIT_DIR" ;;
+*)
+ fqgitdir="$PWD/$GIT_DIR" ;;
+esac
+
+local="`git repo-config --bool --get instaweb.local`"
+httpd="`git repo-config --get instaweb.httpd`"
+browser="`git repo-config --get instaweb.browser`"
+port=`git repo-config --get instaweb.port`
+module_path="`git repo-config --get instaweb.modulepath`"
+
+conf=$GIT_DIR/gitweb/httpd.conf
+
+# Defaults:
+
+# if installed, it doens't need further configuration (module_path)
+test -z "$httpd" && httpd='lighttpd -f'
+
+# probably the most popular browser among gitweb users
+test -z "$browser" && browser='firefox'
+
+# any untaken local port will do...
+test -z "$port" && port=1234
+
+start_httpd () {
+ httpd_only="`echo $httpd | cut -f1 -d' '`"
+ if test "`expr index $httpd_only /`" -eq '1' || \
+ which $httpd_only >/dev/null
+ then
+ $httpd $fqgitdir/gitweb/httpd.conf
+ else
+ # many httpds are installed in /usr/sbin or /usr/local/sbin
+ # these days and those are not in most users $PATHs
+ for i in /usr/local/sbin /usr/sbin
+ do
+ if test -x "$i/$httpd_only"
+ then
+ # don't quote $httpd, there can be
+ # arguments to it (-f)
+ $i/$httpd "$fqgitdir/gitweb/httpd.conf"
+ return
+ fi
+ done
+ fi
+}
+
+stop_httpd () {
+ test -f "$fqgitdir/pid" && kill `cat "$fqgitdir/pid"`
+}
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ --stop|stop)
+ stop_httpd
+ exit 0
+ ;;
+ --start|start)
+ start_httpd
+ exit 0
+ ;;
+ --restart|restart)
+ stop_httpd
+ start_httpd
+ exit 0
+ ;;
+ --local|-l)
+ local=true
+ ;;
+ -d|--httpd|--httpd=*)
+ case "$#,$1" in
+ *,*=*)
+ httpd=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ httpd="$2"
+ shift ;;
+ esac
+ ;;
+ -b|--browser|--browser=*)
+ case "$#,$1" in
+ *,*=*)
+ browser=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ browser="$2"
+ shift ;;
+ esac
+ ;;
+ -p|--port|--port=*)
+ case "$#,$1" in
+ *,*=*)
+ port=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ port="$2"
+ shift ;;
+ esac
+ ;;
+ -m|--module-path=*|--module-path)
+ case "$#,$1" in
+ *,*=*)
+ module_path=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ module_path="$2"
+ shift ;;
+ esac
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+mkdir -p "$GIT_DIR/gitweb/tmp"
+GIT_EXEC_PATH="`git --exec-path`"
+GIT_DIR="$fqgitdir"
+export GIT_EXEC_PATH GIT_DIR
+
+
+lighttpd_conf () {
+ cat > "$conf" <<EOF
+server.document-root = "$fqgitdir/gitweb"
+server.port = $port
+server.modules = ( "mod_cgi" )
+server.indexfiles = ( "gitweb.cgi" )
+server.pid-file = "$fqgitdir/pid"
+cgi.assign = ( ".cgi" => "" )
+mimetype.assign = ( ".css" => "text/css" )
+EOF
+ test "$local" = true && echo 'server.bind = "127.0.0.1"' >> "$conf"
+}
+
+apache2_conf () {
+ test -z "$module_path" && module_path=/usr/lib/apache2/modules
+ mkdir -p "$GIT_DIR/gitweb/logs"
+ bind=
+ test "$local" = true && bind='127.0.0.1:'
+ echo 'text/css css' > $fqgitdir/mime.types
+ cat > "$conf" <<EOF
+ServerRoot "$fqgitdir/gitweb"
+DocumentRoot "$fqgitdir/gitweb"
+PidFile "$fqgitdir/pid"
+Listen $bind$port
+TypesConfig $fqgitdir/mime.types
+DirectoryIndex gitweb.cgi
+EOF
+
+ # check to see if Dennis Stosberg's mod_perl compatibility patch
+ # (<20060621130708.Gcbc6e5c@leonov.stosberg.net>) has been applied
+ if test -f "$module_path/mod_perl.so" && grep '^our $gitbin' \
+ "$GIT_DIR/gitweb/gitweb.cgi" >/dev/null
+ then
+ # favor mod_perl if available
+ cat >> "$conf" <<EOF
+LoadModule perl_module $module_path/mod_perl.so
+PerlPassEnv GIT_DIR
+PerlPassEnv GIT_EXEC_DIR
+<Location /gitweb.cgi>
+ SetHandler perl-script
+ PerlResponseHandler ModPerl::Registry
+ PerlOptions +ParseHeaders
+ Options +ExecCGI
+</Location>
+EOF
+ else
+ # plain-old CGI
+ cat >> "$conf" <<EOF
+LoadModule cgi_module $module_path/mod_cgi.so
+AddHandler cgi-script .cgi
+<Location /gitweb.cgi>
+ Options +ExecCGI
+</Location>
+EOF
+ fi
+}
+
+script='
+s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'`dirname $fqgitdir`'";#;
+s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#;
+s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#;
+s#\(my\|our\) $git_temp =.*#\1 $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+
+gitweb_cgi () {
+ cat > "$1.tmp" <<\EOFGITWEB
+@@GITWEB_CGI@@
+EOFGITWEB
+ sed "$script" "$1.tmp" > "$1"
+ chmod +x "$1"
+ rm -f "$1.tmp"
+}
+
+gitweb_css () {
+ cat > "$1" <<\EOFGITWEB
+@@GITWEB_CSS@@
+EOFGITWEB
+}
+
+gitweb_cgi $GIT_DIR/gitweb/gitweb.cgi
+gitweb_css $GIT_DIR/gitweb/gitweb.css
+
+case "$httpd" in
+*lighttpd*)
+ lighttpd_conf
+ ;;
+*apache2*)
+ apache2_conf
+ ;;
+*)
+ echo "Unknown httpd specified: $httpd"
+ exit 1
+ ;;
+esac
+
+start_httpd
+test -z "$browser" && browser=echo
+$browser http://127.0.0.1:$port
--
1.4.1.rc2.gbf43
^ permalink raw reply related
* Re: [PATCH] autoconf: Use autoconf to write installation directories to config.mak
From: Jakub Narebski @ 2006-07-01 22:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060701213305.GA29115@pasky.or.cz>
On 7/1/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Jun 29, 2006 at 08:23:31PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> It would have been a bit easier to swallow if this whole
>> machinery to build config.mk were somewhere under contrib/ (say
>> in contrib/autoconf), with an instruction to make an "opt-in"
>> symlink "ln -s contrib/autoconf/config.mk config.mk" for people
>> who want to use it in the toplevel INSTALL file, perhaps.
>
> Well, I don't get the point of that - it doesn't make any sense to me to
> require this.
>
> The point of ./configure is to make things easier for the user, so to
> balance that we should make the ./configure harder to _call_ by requiring
> the user to do strange arbitrary steps after calling it.
Easiest way is to output ./configure result to e.g. configure.mak.autoconf,
and include this file just before configure.mak in main Makefile.
Just as in patches (although you have to discard or revert two alternate
mechanism patches)
--
Jakub Narebski
^ permalink raw reply
* [PATCH] Fix errno usage in connect.c
From: Petr Baudis @ 2006-07-01 21:56 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List
In-Reply-To: <118833cc0606280956s4081029ci5b3cd1fdf4b10c97@mail.gmail.com>
Dear diary, on Wed, Jun 28, 2006 at 06:56:12PM CEST, I got a letter
where Morten Welinder <mwelinder@gmail.com> said that...
> It looks like connect.c waits too long before it uses errno in both copies
> of git_tcp_connect_sock. Both close and freeaddrinfo can poke any
> non-zero value in there.
Nice catch.
->8-
errno was used after it could've been modified by a subsequent library call.
Spotted by Morten Welinder.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
connect.c | 18 ++++++++++++------
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/connect.c b/connect.c
index cb4656d..9a87bd9 100644
--- a/connect.c
+++ b/connect.c
@@ -328,7 +328,7 @@ #ifndef NO_IPV6
*/
static int git_tcp_connect_sock(char *host)
{
- int sockfd = -1;
+ int sockfd = -1, saved_errno = 0;
char *colon, *end;
const char *port = STR(DEFAULT_GIT_PORT);
struct addrinfo hints, *ai0, *ai;
@@ -362,9 +362,12 @@ static int git_tcp_connect_sock(char *ho
for (ai0 = ai; ai; ai = ai->ai_next) {
sockfd = socket(ai->ai_family,
ai->ai_socktype, ai->ai_protocol);
- if (sockfd < 0)
+ if (sockfd < 0) {
+ saved_errno = errno;
continue;
+ }
if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
+ saved_errno = errno;
close(sockfd);
sockfd = -1;
continue;
@@ -375,7 +378,7 @@ static int git_tcp_connect_sock(char *ho
freeaddrinfo(ai0);
if (sockfd < 0)
- die("unable to connect a socket (%s)", strerror(errno));
+ die("unable to connect a socket (%s)", strerror(saved_errno));
return sockfd;
}
@@ -387,7 +390,7 @@ #else /* NO_IPV6 */
*/
static int git_tcp_connect_sock(char *host)
{
- int sockfd = -1;
+ int sockfd = -1, saved_errno = 0;
char *colon, *end;
char *port = STR(DEFAULT_GIT_PORT), *ep;
struct hostent *he;
@@ -426,8 +429,10 @@ static int git_tcp_connect_sock(char *ho
for (ap = he->h_addr_list; *ap; ap++) {
sockfd = socket(he->h_addrtype, SOCK_STREAM, 0);
- if (sockfd < 0)
+ if (sockfd < 0) {
+ saved_errno = errno;
continue;
+ }
memset(&sa, 0, sizeof sa);
sa.sin_family = he->h_addrtype;
@@ -435,6 +440,7 @@ static int git_tcp_connect_sock(char *ho
memcpy(&sa.sin_addr, *ap, he->h_length);
if (connect(sockfd, (struct sockaddr *)&sa, sizeof sa) < 0) {
+ saved_errno = errno;
close(sockfd);
sockfd = -1;
continue;
@@ -443,7 +449,7 @@ static int git_tcp_connect_sock(char *ho
}
if (sockfd < 0)
- die("unable to connect a socket (%s)", strerror(errno));
+ die("unable to connect a socket (%s)", strerror(saved_errno));
return sockfd;
}
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply related
* Re: A note on merging conflicts..
From: Junio C Hamano @ 2006-07-01 20:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vveqhccnk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Sat, 1 Jul 2006, Rene Scharfe wrote:
>>>
>>> I wonder why the two clear_commit_marks() calls at the end of
>>> get_merge_bases() are not sufficient, though.
>>
>> Why does that thing check for "parent->object.parsed"?
>
> Oh, I thought I fixed that up when I merged. Sorry.
>
>> Also, it only clears commit marks if they are contiguous, but some commit
>> marking may not be dense (eg, the "UNINTERESTING" mark may have been set
>> by (PARENT1 && PARENT2) triggering, but is not set in the commits that
>> reach it.
>
> That is true.
I'll be offline for a few hours, but if anybody is inclined to
fix this up, I'd appreciate it to be based on top of 7c6f8aa
commit (which is the tip of js/merge-base topic branch).
Perhaps as a starter (not even compile tested)...
diff --git a/commit.c b/commit.c
index 0431027..23ac210 100644
--- a/commit.c
+++ b/commit.c
@@ -397,13 +397,13 @@ void clear_commit_marks(struct commit *c
{
struct commit_list *parents;
- parents = commit->parents;
+ if (!commit)
+ return;
commit->object.flags &= ~mark;
+ parents = commit->parents;
while (parents) {
struct commit *parent = parents->item;
- if (parent && parent->object.parsed &&
- (parent->object.flags & mark))
- clear_commit_marks(parent, mark);
+ clear_commit_marks(parent, mark);
parents = parents->next;
}
}
@@ -1012,7 +1012,8 @@ static void mark_reachable_commits(struc
}
}
-struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2)
+struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2,
+ int cleanup_needed)
{
struct commit_list *list = NULL;
struct commit_list *result = NULL;
@@ -1081,8 +1082,10 @@ struct commit_list *get_merge_bases(stru
}
/* reset flags */
- clear_commit_marks(rev1, PARENT1 | PARENT2 | UNINTERESTING);
- clear_commit_marks(rev2, PARENT1 | PARENT2 | UNINTERESTING);
+ if (cleanup_needed) {
+ clear_commit_marks(rev1, PARENT1 | PARENT2 | UNINTERESTING);
+ clear_commit_marks(rev2, PARENT1 | PARENT2 | UNINTERESTING);
+ }
return result;
}
diff --git a/commit.h b/commit.h
index 89b9dad..53bc697 100644
--- a/commit.h
+++ b/commit.h
@@ -105,6 +105,6 @@ struct commit_graft *read_graft_line(cha
int register_commit_graft(struct commit_graft *, int);
int read_graft_file(const char *graft_file);
-extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2);
+extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup_needed);
#endif /* COMMIT_H */
diff --git a/merge-base.c b/merge-base.c
index b41f76c..59f723f 100644
--- a/merge-base.c
+++ b/merge-base.c
@@ -6,7 +6,7 @@ static int show_all = 0;
static int merge_base(struct commit *rev1, struct commit *rev2)
{
- struct commit_list *result = get_merge_bases(rev1, rev2);
+ struct commit_list *result = get_merge_bases(rev1, rev2, 0);
if (!result)
return 1;
^ permalink raw reply related
* Re: A note on merging conflicts..
From: Junio C Hamano @ 2006-07-01 20:07 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0607011301480.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 1 Jul 2006, Rene Scharfe wrote:
>>
>> I wonder why the two clear_commit_marks() calls at the end of
>> get_merge_bases() are not sufficient, though.
>
> Why does that thing check for "parent->object.parsed"?
Oh, I thought I fixed that up when I merged. Sorry.
> Also, it only clears commit marks if they are contiguous, but some commit
> marking may not be dense (eg, the "UNINTERESTING" mark may have been set
> by (PARENT1 && PARENT2) triggering, but is not set in the commits that
> reach it.
That is true.
^ permalink raw reply
* Re: A note on merging conflicts..
From: Linus Torvalds @ 2006-07-01 20:04 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <44A6CD1D.2000600@lsrfire.ath.cx>
On Sat, 1 Jul 2006, Rene Scharfe wrote:
>
> I wonder why the two clear_commit_marks() calls at the end of
> get_merge_bases() are not sufficient, though.
Why does that thing check for "parent->object.parsed"?
Also, it only clears commit marks if they are contiguous, but some commit
marking may not be dense (eg, the "UNINTERESTING" mark may have been set
by (PARENT1 && PARENT2) triggering, but is not set in the commits that
reach it.
Linus
^ permalink raw reply
* Re: A note on merging conflicts..
From: Junio C Hamano @ 2006-07-01 19:56 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <44A6CD1D.2000600@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> I wonder why the two clear_commit_marks() calls at the end of
> get_merge_bases() are not sufficient, though.
I missed to notice that Johannes had added those calls there; we
should remove them from get_merge_bases().
The normal case of git-merge-base calling get_merge_bases() once
and exiting should NOT have to pay for the clean-up cost at all.
^ permalink raw reply
* Re: [PATCH] Enable tree (directory) history display
From: Luben Tuikov @ 2006-07-01 19:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606301954140.12404@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> Well, with history simplification, we still show merges that are required
> to make the history _complete_, ie say that you had
>
> a
> |
> b
> / \
> c d
> | |
>
> and neither "a" nor "b" actually changed the file, but both "c" and "d"
> did: in this case we have to leave "b" around just because otherwise there
> would be no way to show the _relationship_, even if "b" itself doesn't
> actually change the tree in any way what-so-ever.
I agree. If "c" and/or "d" changed the file but neither "a" nor "b" did,
then by (merge/diff/etc) "inheritance" we do need to leave "b" around.
(This is similar to git-blame/git-annotate which should show "b", so that
we can track down the change to "c" and/or "d".)
> > Can you consider the default case to be simplify_history=1,
> > which is currently the default behaviour of git-rev-list.
>
> Actually, for your case, you don't want _any_ merges, unless those merges
> literally changed the tree from all of the parents.
Yes, that's true. s/all/one or more:
Don't want to show a merge, unless one or more of the parents,
changed the file. If no parent changed the tree, then do not
show the commit.
> I think it would make sense to make that further simplification if the
> "--parents" flag wasn't present.
>
> Hmm. Maybe something like this..
>
> BTW! Junio, I think this patch actually fixes a real bug.
>
> Without this patch, the "--parents --full-history" combination (which
> you'd get if you do something like
>
> gitk --full-history Makefile
>
> or similar) will actually _drop_ merges where all children are identical.
> That's wrong in the --full-history case, because it measn that the graph
> ends up missing lots of entries.
>
> In the process, this also should make
>
> git-rev-list --full-history Makefile
>
> give just the _true_ list of all commits that changed Makefile (and
> properly ignore merges that were identical in one parent), because now
> we're not asking for "--parent", so we don't need the unnecessary merge
> commits to keep the history together.
>
> Luben, does this fix the problem for you?
Given Junio's analysis, and briefly looking at the logic, it does seem
correct. Let me apply it and see what I get, but I think it is a good thing.
Thanks for the patch!
Luben
^ permalink raw reply
* Re: A note on merging conflicts..
From: Rene Scharfe @ 2006-07-01 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vfyhldvd2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> I suspect this has the same problem I pointed out to Kristian's
> attempt to make git-branch a built-in.
>
> Subject: Re: [PATCH] Implement git-branch and git-merge-base as
> built-ins. Date: Thu, 08 Jun 2006 11:53:48 -0700 Message-ID:
> <7vverbsclf.fsf@assigned-by-dhcp.cox.net>
>
> Namely, merge-base code is not set up to be called more than once
> without cleaning things up.
Eek! This is not a nice interface. Your example IDs from the your mail
to Kristian:
$ ./git-rev-list 89719209...262a6ef7 66ae0c77...ced9456a | wc
75 75 3075
$ git-rev-list 89719209 262a6ef7 \
--not $(git-merge-base --all 89719209 262a6ef7) \
--not 66ae0c77 ced9456a \
--not $(git-merge-base --all 66ae0c77 ced9456a) | wc
75 75 3075
$ ./git-rev-list 66ae0c77...ced9456a 89719209...262a6ef7 | wc
76 76 3116
$ git-rev-list 66ae0c77 ced9456a \
--not $(git-merge-base --all 66ae0c77 ced9456a) \
--not 89719209 262a6ef7 \
--not $(git-merge-base --all 89719209 262a6ef7) | wc
75 75 3075
Yep, that doesn't seem right. The additional line is 262a6ef (which is
the merge base for 66ae0c77 and ced9456a btw.). The other 4x 75 lines
match.
I wonder why the two clear_commit_marks() calls at the end of
get_merge_bases() are not sufficient, though.
René
^ permalink raw reply
* Re: A note on merging conflicts..
From: Linus Torvalds @ 2006-07-01 18:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e86ega$gnc$1@sea.gmane.org>
On Sat, 1 Jul 2006, Jakub Narebski wrote:
>
> Caret is used twice, with different meaning. As prefix operator "^" means
> "exclude lineage of commit" (while commit without "^" in front means:
> "include lineage of commit and commit itself"). BTW. why we don't use '!'
> for that?
Using '!' is really nasty with most shells. Avoid, avoid, avoid.
It would be more sensible to use ~ (mathematical negation), but that also
has magic meaning for shell at the beginning of a word..
Linus
^ 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