* [PATCH] Allow installing in the traditional way
From: Junio C Hamano @ 2008-07-28 7:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In an earlier commit c70a8d9 (Makefile: Do not install a copy of 'git' in
$(gitexecdir), 2008-07-21), we tried to avoid installing two git, one in
/usr/bin/git and the other in /usr/libexec/git-core/git. It mistakenly
removed the only copy of git when gitexecdir and bindir are set to the
same directory, i.e. the traditional layout.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 7e30b30..52c67c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1362,7 +1362,10 @@ endif
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
- $(RM) "$$execdir/git$X" && \
+ if test "z$$bindir" != "z$$execdir"; \
+ then \
+ $(RM) "$$execdir/git$X"; \
+ fi && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
--
1.6.0.rc1
^ permalink raw reply related
* [PATCH] Allow building without any git installed
From: Junio C Hamano @ 2008-07-28 7:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
This is a follow-up patch to 49fa65a (Allow the built-in exec path to be
relative to the command invocation path, 2008-07-23). Without specific
gitexecdir passed from the command line, git-gui's build procedure would
try to figure out the value for it by running an installed git.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 798a2f2..7e30b30 100644
--- a/Makefile
+++ b/Makefile
@@ -1067,7 +1067,7 @@ endif
all::
ifndef NO_TCLTK
- $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) all
+ $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
--
1.6.0.rc1
^ permalink raw reply related
* Re: GTP/0.1 terminology 101: commit reels and references
From: Sam Vilain @ 2008-07-28 7:02 UTC (permalink / raw)
To: Joshua Roys; +Cc: gittorrent, git, Jonas Fonseca
In-Reply-To: <488D42B6.4030701@gmail.com>
Josh, I'm cc:'ing the main list with this one as well, as I think it
falls into the scope of discussions of wider interest than the rfc- and
implementation-specific discussions that (I envisaged would) happen on
the gittorrent list.
On Sun, 2008-07-27 at 23:53 -0400, Joshua Roys wrote:
> Here's some terms, as best as I understand them.
>
> The *Commit Reel* is a sequence of objects between two reference points,
> sorted in a deterministic fashion. The two reference points are
> *Reference* objects, or a signed tag containing a collection of git refs
> (similar to the output from `git show-ref`).
Yes, that's right. We have the two slightly ambiguous terms, "refs",
which mean the same thing as the rest of git, and "References", which
are more like .git/packed-refs. Perhaps this is a good time to pick a
better name. "Slice" would be an accurate term, though it's certainly
tempting to pick another term from the tape taxonomy, such as "Splice"¹
or "Mark"².
> Commit reels can also, and generally do, include the objects required
> for a specific commit.
Yes. The only times where they wouldn't contain all the objects
required for the commits within the reel, is when those objects happened
to be contained by a previous reel.
This is one of the design decisions which I think may be a mistake; a
less expensive to calculate definition of a reel would be *all* objects
between the starting and ending Reference objects. The current
definition requires a hash index of objects in each reel, which must be
consulted once for all objects when creating the reel index.
> As an example, a commit reel could be the set of objects between the
> v2.6.25 and v2.6.26 tags of the Linux kernel. The only thing we would
> need added to those tags is the list of heads (and tags) at the time of
> the tagging.
Correct. It represents all of the changes in a given repository over a
period of time.
> Those two structures form the basis for two *Peer Wire Protocol* (PWP)
> messages, Reels and References.
>
> Any questions, corrections, or rotten vegetables?
No, I think that's all good so far...
Cheers,
Sam.
¹ - see
http://en.wikipedia.org/wiki/Reel-to-reel_audio_tape_recording#Description
² - as used by the old unix "mt", see eg
http://docs.sun.com/app/docs/doc/816-0210/6m6nb7mf3?a=view
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-28 6:44 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080728063838.GB4234@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> t2103-update-index-ignore-missing.sh still broken on Windows because
> of stat.st_size being 0 for directories there.
I recall we did not reach a useful conclusion of that discussion.
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Junio C Hamano @ 2008-07-28 6:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Shawn O. Pearce
In-Reply-To: <7v3aly5zz3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
>> On Donnerstag, 24. Juli 2008, Junio C Hamano wrote:
>>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>>> > It also fixes 'make install' of git-gui as well (sigh!) by not exporting
>>> > gitexecdir - assuming that Shawn applies the git-gui patch.
>>>
>>> Yeah, this seems to break the install quite badly without git-gui patch.
>>
>> If you squash this in, we don't need the git-gui patch.
>
> Thanks.
>
> I think this patch makes _more_ sense than the git-gui patch, actually.
>
> Within the context of git.git project, we would want to force the
> installation directory of git-gui portion to be consistent with the main
> project.
What I wanted to say with the above is that the main Makefile is what has
its own special need from git-gui/Makefile's point of view, so passing
such customization from the main Makefile makes a lot of sense.
I think this is also needed; I noticed it while trying the "build on a
machine without any git installed" exercise.
diff --git a/Makefile b/Makefile
index 798a2f2..52c67c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1067,7 +1067,7 @@ endif
all::
ifndef NO_TCLTK
- $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) all
+ $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
^ permalink raw reply related
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: Junio C Hamano @ 2008-07-28 6:39 UTC (permalink / raw)
To: gitzilla; +Cc: Johannes Sixt, git
In-Reply-To: <7vabg2v83o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> This new action needs to be in a conditional to keep it from removing
>> the ONLY git executable when bindir and execdir are the same dir.
>
> Heh, I love bug reports that come immediately after I tag the tip of
> 'master' as -rc1.
This should do, but to be very honest, I really hate the output from the
foreach that precedes this section.
Makefile | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 798a2f2..92df61c 100644
--- a/Makefile
+++ b/Makefile
@@ -1362,7 +1362,10 @@ endif
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
- $(RM) "$$execdir/git$X" && \
+ if test "z$$bindir" != "z$$execdir"; \
+ then \
+ $(RM) "$$execdir/git$X"; \
+ fi && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
^ permalink raw reply related
* Re: GIT 1.6.0-rc1
From: Alex Riesen @ 2008-07-28 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy73myim5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Mon, Jul 28, 2008 02:09:38 +0200:
> Ok, so I tagged and pushed it out. There still is the "git mv" bugfix
> from Pasky that is parked in 'next' but other than that I think this is
> pretty much "it" for 1.6.0 feature-wise.
>
> Major parts of the changes since 1.6.0-rc0 consists of documentation and
> tests portability; there is nothing surprising nor scary.
t2103-update-index-ignore-missing.sh still broken on Windows because
of stat.st_size being 0 for directories there.
http://thread.gmane.org/gmane.comp.version-control.git/89370
^ permalink raw reply
* [PATCH] Make use of stat.ctime configurable
From: Alex Riesen @ 2008-07-28 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <7v1w1f155p.fsf@gitster.siamese.dyndns.org>
because there are situations where it produces too much false
positives. Like when file system crawlers keep changing it when
scanning and using the ctime for marking scanned files.
The default is to allow use of ctime.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Sun, Jul 27, 2008 21:46:42 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > because there are situations where it produces too much false
> > positives. Like when file system crawlers keep changing it when
> > scanning and using the ctime for marking scanned files.
>
> This justification is good and I am very inclined to advocate for its
> inclusion in 1.6.0, but any new configuration needs to be in the
> documentation.
Done.
> It appears there is "gui.trustmtime"; shouldn't this be called
> "core.trustctime" or something?
Getting old... I even called the global flag trust_file_ctime!
Corrected. Changed trust_file_ctime to trust_ctime.
Documentation/config.txt | 7 +++++++
Documentation/git-update-index.txt | 5 +++++
cache.h | 1 +
config.c | 4 ++++
environment.c | 1 +
read-cache.c | 2 +-
6 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1a13abc..552c134 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -149,6 +149,13 @@ core.safecrlf::
`core.autocrlf`, git will reject the file. The variable can
be set to "warn", in which case git will only warn about an
irreversible conversion but continue the operation.
+
+core.trustctime::
+ If false, the ctime differences between the index and the
+ working copy are ignored; useful when the inode change time
+ is regularly modified by something outside Git (file system
+ crawlers and some backup systems).
+ See linkgit:git-update-index[1]. True by default.
+
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 6b930bc..1d9d81a 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -323,6 +323,11 @@ from symbolic link to regular file.
The command looks at `core.ignorestat` configuration variable. See
'Using "assume unchanged" bit' section above.
+The command also looks at `core.trustctime` configuration variable.
+It can be useful when the inode change time is regularly modified by
+something outside Git (file system crawlers and backup systems use
+ctime for marking files processed) (see linkgit:git-config[1]).
+
SEE ALSO
--------
diff --git a/cache.h b/cache.h
index 4b6c0a6..2475de9 100644
--- a/cache.h
+++ b/cache.h
@@ -423,6 +423,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);
/* Environment bits from configuration mechanism */
extern int trust_executable_bit;
+extern int trust_ctime;
extern int quote_path_fully;
extern int has_symlinks;
extern int ignore_case;
diff --git a/config.c b/config.c
index 1e066c7..53f04a0 100644
--- a/config.c
+++ b/config.c
@@ -341,6 +341,10 @@ static int git_default_core_config(const char *var, const char *value)
trust_executable_bit = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, "core.trustctime")) {
+ trust_ctime = git_config_bool(var, value);
+ return 0;
+ }
if (!strcmp(var, "core.quotepath")) {
quote_path_fully = git_config_bool(var, value);
diff --git a/environment.c b/environment.c
index 4a88a17..0c6d11f 100644
--- a/environment.c
+++ b/environment.c
@@ -13,6 +13,7 @@ char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int user_ident_explicitly_given;
int trust_executable_bit = 1;
+int trust_ctime = 1;
int has_symlinks = 1;
int ignore_case;
int assume_unchanged;
diff --git a/read-cache.c b/read-cache.c
index 6c08803..1cae361 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -197,7 +197,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
}
if (ce->ce_mtime != (unsigned int) st->st_mtime)
changed |= MTIME_CHANGED;
- if (ce->ce_ctime != (unsigned int) st->st_ctime)
+ if (trust_ctime && ce->ce_ctime != (unsigned int) st->st_ctime)
changed |= CTIME_CHANGED;
if (ce->ce_uid != (unsigned int) st->st_uid ||
--
1.6.0.rc0.76.g581e
^ permalink raw reply related
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: Junio C Hamano @ 2008-07-28 6:24 UTC (permalink / raw)
To: gitzilla; +Cc: Johannes Sixt, git
In-Reply-To: <488D104F.8080005@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Johannes Sixt wrote:
> [...]
>>
>> diff --git a/Makefile b/Makefile
>> index 551bde9..cbab4f9 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1335,6 +1335,7 @@ endif
>> '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
>> fi
>> $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
>> + $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
>> ifneq (,$X)
>> $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
>> endif
>
> This new action needs to be in a conditional to keep it from removing
> the ONLY git executable when bindir and execdir are the same dir.
Heh, I love bug reports that come immediately after I tag the tip of
'master' as -rc1.
^ permalink raw reply
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Junio C Hamano @ 2008-07-28 6:18 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin, Miklos Vajna
In-Reply-To: <200807280810.20922.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Yeah, but what is quite confusing I think is that a merge base seems to be
> defined as "an as good as possible _common_ ancestor" but in this case, the
> result of "git merge-base A B C" is not an ancestor of C (even with --all
> option). So perhaps we need a better definition.
See my other message. "git merge-base A B C" is not the best common
ancestors across A B and C. It is the best common ancestors between A and
a commit that is a merge between B and C.
By defining/explaining it that way, you can avoid the "Huh, are you
talking about OR or AND" question you would inevitably get when you say
"Common ancestor of A and B or A and C". Also in "git merge-base A B C",
A is fundamentally different from any other commit; a commit being (or not
being) common between A and B (or A and C) is what we care about a lot,
but a commit being (or not being) common between B and C does not matter
in this computation.
^ permalink raw reply
* Re: [PATCH] init: handle empty "template" parameter, was Re: fetch refspec foo/* matches foo*
From: Jeff King @ 2008-07-28 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vljzmv8mm.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 27, 2008 at 11:13:37PM -0700, Junio C Hamano wrote:
> Thanks, it seems that I keep forgetting to apply this patch after saying
> to myself "Heh, it obviously is the correct thing to do".
That is why you have other developers to nag you. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] init: handle empty "template" parameter, was Re: fetch refspec foo/* matches foo*
From: Junio C Hamano @ 2008-07-28 6:13 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20080728060204.GC7294@sigill.intra.peff.net>
Thanks, it seems that I keep forgetting to apply this patch after saying
to myself "Heh, it obviously is the correct thing to do".
^ permalink raw reply
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-28 6:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Miklos Vajna
In-Reply-To: <7vabg43pcp.fsf@gitster.siamese.dyndns.org>
Le dimanche 27 juillet 2008, Junio C Hamano a écrit :
>
> The point of merge_bases_many() is that it allows you to compute a merge
> base between a commit and another commit that does not yet exist which is
> a merge across all others.
>
> o---o---o---o---C
> / :
> / o---o---o---B..(M)
> / / :
> ---o---*---o---o---o---A..(X)
>
> Suppose you have commits A, B and C, and you would want to come up with
> an Octopus merge X across these three commits. Because our low-level
> merge machinery works always on two trees with one common ancestor tree,
> we would first create a tree that is a merge between B and C (which is
> marked as (M) in the picture), and then merge the tree of (M) and A using
> common ancestor between (M) and A.
>
> If we did not have merge_bases_many(), we would actually create (M) as a
> real commit, and compute merge base between A and (M), which is marked as
> "*" in the picture. The use of merge_bases_many() allows us to run the
> same merge base computation without actually creating commit (M).
> Instead of computing merge-base between A and (M), you can ask for the
> merge base between A ("the first commit") and B, C ("the other commits")
> to obtain the same answer "*".
Yeah, but what is quite confusing I think is that a merge base seems to be
defined as "an as good as possible _common_ ancestor" but in this case, the
result of "git merge-base A B C" is not an ancestor of C (even with --all
option). So perhaps we need a better definition.
> Base between A and B is that "*", and you are correct to say that it is
> an ancestor of the "*" that is output from the command; base between A
> and C is the parent of "*", and again you are correct to say it is
> ancestor of the "*" that is output from the command.
>
> But if we output any other commit between "*" and A from the command, it
> still satisifies your condition. "The merge base between A and each of
> B, C,... should be an ancestor of what is output". In order to satisify
> your condition, in the extreme case, we could even output A. Both the
> merge base between A and B, and the merge base between A and C, would be
> an ancestor of A.
>
> So your description may not be incorrect, but I think it completely
> misses the point of what is being computed.
>
> > Author
> > ------
> > diff --git a/builtin-merge-base.c b/builtin-merge-base.c
> > index 1cb2925..f2c9756 100644
> > --- a/builtin-merge-base.c
> > +++ b/builtin-merge-base.c
> > @@ -2,9 +2,11 @@
> > #include "cache.h"
> > #include "commit.h"
> >
> > -static int show_merge_base(struct commit *rev1, struct commit *rev2,
> > int show_all) +static int show_merge_base(struct commit *rev1, int
> > prev2_nr, + struct commit **prev2, int show_all)
> > {
> > - struct commit_list *result = get_merge_bases(rev1, rev2, 0);
> > + struct commit_list *result = get_merge_bases_many(rev1, prev2_nr,
> > + prev2, 0);
>
> This is just style, but if you must break lines somewhere, I'd prefer to
> have prev2_nr and prev2 on the same line, like this:
>
> struct commit_list *result = get_merge_bases_many(rev1,
> prev2_nr, prev2, 0);
>
> because they logically belong to each other. Further, I think this
> 84-column single-line statement is perfectly fine as well in this case:
>
> struct commit_list *result = get_merge_bases_many(rev1, prev2_nr, prev2,
> 0);
>
> I would probably do this myself in this case, though:
>
> struct commit_list *result;
>
> result = get_merge_bases_many(rev1, prev2_nr, prev2, 0);
I used that in v3.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] init: handle empty "template" parameter, was Re: fetch refspec foo/* matches foo*
From: Jeff King @ 2008-07-28 6:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807261511490.26810@eeepc-johanness>
On Sat, Jul 26, 2008 at 03:13:26PM +0200, Johannes Schindelin wrote:
> > Also, while I have your attention, Junio, here is another bug fix
> > that should go into 1.6.0. I posted the patch as a "how about this" deep
> > in a thread and got no response (which means no complaints, right?).
>
> Again it is in a thread...
Heh. Point taken.
My meaning was "you, Junio, did not see this because it was in another
thread, so I am pointing it out to you" but the irony of the rest of the
statement was lost on me during the original writing.
> I deem this patch obviously correct, and your reasoning as to what an
> empty parameter should mean makes sense.
Thank you for reviewing, anyway. ;)
Here is a re-post with a test for the new behavior added in (and an
extra test just to make sure --template works at all. It does get used
by test-lib, so we were implicitly checking it to some degree, but it's
entirely possible that it could fail and the tests wouldn't necessarily
notice (e.g., if it accidentally used an installed set of templates
instead)).
-- >8 --
init: handle empty "template" parameter
If a user passes "--template=", then our template parameter
is blank. Unfortunately, copy_templates() assumes it has at
least one character, and does all sorts of bad things like
reading from template[-1] and then proceeding to link all of
'/' into the .git directory.
This patch just checks for that condition in copy_templates
and aborts. As a side effect, this means that --template=
now has the meaning "don't copy any templates."
---
builtin-init-db.c | 2 ++
t/t0001-init.sh | 26 ++++++++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 38b4fcb..baf0d09 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -117,6 +117,8 @@ static void copy_templates(const char *template_dir)
template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
if (!template_dir)
template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
+ if (!template_dir[0])
+ return;
strcpy(template_path, template_dir);
template_len = strlen(template_path);
if (template_path[template_len-1] != '/') {
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 2a38d98..620da5b 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -141,4 +141,30 @@ test_expect_success 'reinit' '
test_cmp again/empty again/err2
'
+test_expect_success 'init with --template' '
+ mkdir template-source &&
+ echo content >template-source/file &&
+ (
+ mkdir template-custom &&
+ cd template-custom &&
+ git init --template=../template-source
+ ) &&
+ test_cmp template-source/file template-custom/.git/file
+'
+
+test_expect_success 'init with --template (blank)' '
+ (
+ mkdir template-plain &&
+ cd template-plain &&
+ git init
+ ) &&
+ test -f template-plain/.git/info/exclude &&
+ (
+ mkdir template-blank &&
+ cd template-blank &&
+ git init --template=
+ ) &&
+ ! test -f template-blank/.git/info/exclude
+'
+
test_done
--
1.6.0.rc1.155.gd3310
^ permalink raw reply related
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Junio C Hamano @ 2008-07-28 5:58 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1217224228-31303-2-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> ... It is either used as
> 'bin/git' (1 directory) or as 'libexec/git-core/git-*'
> (2 directories).
I thought Hannes already fixed that one; we shouldn't have the latter.
^ permalink raw reply
* [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Steffen Prohaska @ 2008-07-28 5:50 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <1217224228-31303-1-git-send-email-prohaska@zib.de>
This might solve a fundamental problem we have with the
computation of system directories based on relative paths
in combination with the new gitexecpath 'libexec/git-core'.
The problem is that the program 'git' is hardlinked to
directories with different depth. It is either used as
'bin/git' (1 directory) or as 'libexec/git-core/git-*'
(2 directories). Thus, using the same relative path
in system_path() yields different results when starting from the
two locations. I recognized the problem because /etc/gitconfig
is no longer be read.
The patch below might fix the problem by always calling 'bin/git'
for builtin commands. The computation in system_path() would
always start from 'bin' and thus yields predictable results. I
am not sure however if it fully solves the problem because other
code paths might run the dashed forms directly.
I think the only way to verify correctness would be to stop
installing the dashed forms for builtins. If they were not
installed they could not be called. The only entry point for all
builtins would be 'bin/git'. I don't think we want to stop
installing the dashed forms right away.
So what shall we do?
Steffen
-- 8< --
We prefer running the dashless form, so we should use it in
MinGW's start_command(), too.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
run-command.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/run-command.c b/run-command.c
index 6e29fdf..a3b28a6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -119,9 +119,8 @@ int start_command(struct child_process *cmd)
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
- const char *sargv0 = cmd->argv[0];
+ const char **sargv = cmd->argv;
char **env = environ;
- struct strbuf git_cmd;
if (cmd->no_stdin) {
s0 = dup(0);
@@ -165,9 +164,7 @@ int start_command(struct child_process *cmd)
}
if (cmd->git_cmd) {
- strbuf_init(&git_cmd, 0);
- strbuf_addf(&git_cmd, "git-%s", cmd->argv[0]);
- cmd->argv[0] = git_cmd.buf;
+ cmd->argv = prepare_git_cmd(cmd->argv);
}
cmd->pid = mingw_spawnvpe(cmd->argv[0], cmd->argv, env);
@@ -175,9 +172,9 @@ int start_command(struct child_process *cmd)
if (cmd->env)
free_environ(env);
if (cmd->git_cmd)
- strbuf_release(&git_cmd);
+ free(cmd->argv);
- cmd->argv[0] = sargv0;
+ cmd->argv = sargv;
if (s0 >= 0)
dup2(s0, 0), close(s0);
if (s1 >= 0)
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 1/2] Refactor, adding prepare_git_cmd(const char **argv)
From: Steffen Prohaska @ 2008-07-28 5:50 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
prepare_git_cmd(const char **argv) adds a first entry "git" to
the array argv. The new array is allocated on the heap. It's
the caller's responsibility to release it with free(). The code
was already present in execv_git_cmd() but could not be used from
outside. Now it can also be called for preparing the command list
in the MinGW codepath in run-command.c.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
exec_cmd.c | 7 ++++++-
exec_cmd.h | 1 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 0ed768d..ce6741e 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -78,7 +78,7 @@ void setup_path(void)
strbuf_release(&new_path);
}
-int execv_git_cmd(const char **argv)
+const char **prepare_git_cmd(const char **argv)
{
int argc;
const char **nargv;
@@ -91,6 +91,11 @@ int execv_git_cmd(const char **argv)
for (argc = 0; argv[argc]; argc++)
nargv[argc + 1] = argv[argc];
nargv[argc + 1] = NULL;
+ return nargv;
+}
+
+int execv_git_cmd(const char **argv) {
+ const char **nargv = prepare_git_cmd(argv);
trace_argv_printf(nargv, "trace: exec:");
/* execvp() can only ever return if it fails */
diff --git a/exec_cmd.h b/exec_cmd.h
index 0c46cd5..594f961 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -5,6 +5,7 @@ extern void git_set_argv_exec_path(const char *exec_path);
extern void git_set_argv0_path(const char *path);
extern const char* git_exec_path(void);
extern void setup_path(void);
+extern const char **prepare_git_cmd(const char **argv);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
extern const char *system_path(const char *path);
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* Re: [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Junio C Hamano @ 2008-07-28 5:46 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin, Miklos Vajna, Jakub Narebski
In-Reply-To: <20080728065023.743930d6.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Before this patch "git merge-base" accepted only 2 arguments, so
> only merge bases between 2 references could be computed.
>
> The purpose of this patch is to make "git merge-base" accept more
> than 2 arguments, so that the merge bases between the first given
> reference and all the other references can be computed.
After thinking about this a bit more, I think that saying "we now allow
computing merge base between more than 2" is misleading.
I ended up rewriting almost all the lines. The points are:
* The command is still about computing merge-bases between two commits,
and one of these two commits is the first command line argument as
before. With more than one remaining commits on the command line, you
can specify a hypothetical commit that is a merge between all of them.
* We did not formally define what a merge-base is. Define it.
* With a proper definition of merge-base as "best common ancestors", with
the definition of "good/better/best" between common ancestors, we do
not have to say anything redundant about --all. It outputs all merge
bases, as opposed to one chosen at random.
* Have definition and give illustrations in a new Discussion section.
---
Documentation/git-merge-base.txt | 77 ++++++++++++++++++++++++++++++++-----
1 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
index 1a7ecbf..fd4b5c9 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -8,26 +8,81 @@ git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
-'git merge-base' [--all] <commit> <commit>
+'git merge-base' [--all] <commit> <commit>...
DESCRIPTION
-----------
-'git-merge-base' finds as good a common ancestor as possible between
-the two commits. That is, given two commits A and B, `git merge-base A
-B` will output a commit which is reachable from both A and B through
-the parent relationship.
+'git-merge-base' finds best common ancestor(s) between two commits to use
+in a three-way merge. One common ancestor is 'better' than another common
+ancestor if the latter is an ancestor of the former. A common ancestor
+that does not have any better common ancestor than it is a 'best common
+ancestor', i.e. a 'merge base'. Note that there can be more than one
+merge bases between two commits.
-Given a selection of equally good common ancestors it should not be
-relied on to decide in any particular way.
-
-The 'git-merge-base' algorithm is still in flux - use the source...
+Among the two commits to compute their merge bases, one is specified by
+the first commit argument on the command line; the other commit is a
+(possibly hypothetical) commit that is a merge across all the remaining
+commits on the command line. As the most common special case, giving only
+two commits from the command line means computing the merge base between
+the given two commits.
OPTIONS
-------
--all::
- Output all common ancestors for the two commits instead of
- just one.
+ Output all merge bases for the commits, instead of just one.
+
+DISCUSSION
+----------
+
+Given two commits 'A' and 'B', `git merge-base A B` will output a commit
+which is reachable from both 'A' and 'B' through the parent relationship.
+
+For example, with this topology:
+
+ o---o---o---B
+ /
+ ---o---1---o---o---o---A
+
+the merge base between 'A' and 'B' is '1'.
+
+Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the
+merge base between 'A' and an hypothetical commit 'M', which is a merge
+between 'B' and 'C'. For example, with this topology:
+
+ o---o---o---o---C
+ /
+ / o---o---o---B
+ / /
+ ---2---1---o---o---o---A
+
+the result of `git merge-base A B C` is '1'. This is because the
+equivalent topology with a merge commit 'M' between 'B' and 'C' is:
+
+
+ o---o---o---o---o
+ / \
+ / o---o---o---o---M
+ / /
+ ---2---1---o---o---o---A
+
+and the result of `git merge-base A M` is '1'. Commit '2' is also a
+common ancestor between 'A' and 'M', but '1' is a better common ancestor,
+because '2' is an ancestor of '1'. Hence, '2' is not a merge base.
+
+When the history involves criss-cross merges, there can be more than one
+'best' common ancestors between two commits. For example, with this
+topology:
+
+ ---1---o---A
+ \ /
+ X
+ / \
+ ---2---o---o---B
+
+both '1' and '2' are merge-base of A and B. Neither one is better than
+the other (both are 'best' merge base). When `--all` option is not given,
+it is unspecified which best one is output.
Author
------
^ permalink raw reply related
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-28 5:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807271631470.5526@eeepc-johanness>
Le dimanche 27 juillet 2008, Johannes Schindelin a écrit :
> Hi,
>
> On Sun, 27 Jul 2008, Christian Couder wrote:
> > diff --git a/builtin-merge-base.c b/builtin-merge-base.c
> > index 1cb2925..f2c9756 100644
> > --- a/builtin-merge-base.c
> > +++ b/builtin-merge-base.c
> > @@ -38,15 +48,22 @@ int cmd_merge_base(int argc, const char **argv,
> > const char *prefix) usage(merge_base_usage);
> > argc--; argv++;
> > }
> > - if (argc != 3)
> > + if (argc < 3)
> > usage(merge_base_usage);
> > - if (get_sha1(argv[1], rev1key))
> > - die("Not a valid object name %s", argv[1]);
> > - if (get_sha1(argv[2], rev2key))
> > - die("Not a valid object name %s", argv[2]);
> > - rev1 = lookup_commit_reference(rev1key);
> > - rev2 = lookup_commit_reference(rev2key);
> > - if (!rev1 || !rev2)
> > +
> > + rev1 = get_commit_reference(argv[1]);
> > + if (!rev1)
> > return 1;
>
> Why do you special case rev1? Is it so special? Just handle it together
> with all of the other arguments!
>
> IOW have one commit array, and do not call it "prev".
Ok, I have done that in v3.
> > - return show_merge_base(rev1, rev2, show_all);
> > + argc--; argv++;
> > +
> > + do {
> > + struct commit *rev2 = get_commit_reference(argv[1]);
> > + if (!rev2)
> > + return 1;
> > + ALLOC_GROW(prev2, prev2_nr + 1, prev2_alloc);
> > + prev2[prev2_nr++] = rev2;
> > + argc--; argv++;
> > + } while (argc > 1);
>
> Now, this is ugly. You know beforehand the _exact_ number of arguments,
> and yet you dynamically grow the array?
You are right. I guess I dealt too much with complex parsing of arguments
where you can have options everywhere, and perhaps I also felt somewhat
guilty for not having used ALLOC_GROW before, or something.
> Also, why do you use a do { }
> while(), when a for () would be much, much clearer?
Well, we already know that there are at least 2 commits to parse, so it
feels a little bit wastefull to check first again. Also the code to parse
the [--all|-a] option before use a while loop with "argc--; argv++;" at the
end, so I think it is more coherent like that.
Thanks,
Christian.
> BTW I seem to recall that get_merge_bases_many() was _not_ the same as
> get_merge_octopus(). Could you please remind me what _many() does?
>
> Ciao,
> Dscho
^ permalink raw reply
* Re: [PATCH] make sure parsed wildcard refspec ends with slash
From: Jeff King @ 2008-07-28 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vsktv3l9k.fsf_-_@gitster.siamese.dyndns.org>
On Sat, Jul 26, 2008 at 11:15:51PM -0700, Junio C Hamano wrote:
> > I have a nagging suspicion that it might be a simpler and cleaner change
> > to change parse_refspec_internal() to keep the trailing slash, instead of
> > dropping it. Then the check you added is not needed (the trailing slash
> > guarantees that the pattern matches at the hierarchy boundary), neither
> > any of the change in this patch.
>
> This is the other variant, and it turns out that I was right. Among the
> 64-18 = 46 new lines, 30 are from the new test file. Two existing
> "matching part is followed by '/'" tests are removed.
Looks like you have already applied it, but I will chime in that of the
two, I think this is the more sensible change. Stripping the '/' felt
like a loss of information to me. IIRC, when "support only /*" was
discussed, the thinking was "let's keep it tight now, and we can loosen
it later." Keeping the '/' means that the code is much more sane if
other globbing rules come in the future.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Junio C Hamano @ 2008-07-28 5:37 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin, Miklos Vajna, Jakub Narebski
In-Reply-To: <20080728065023.743930d6.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Before this patch "git merge-base" accepted only 2 arguments, so
> only merge bases between 2 references could be computed.
>
> The purpose of this patch is to make "git merge-base" accept more
> than 2 arguments, so that the merge bases between the first given
> reference and all the other references can be computed.
I have trouble with this wording, but I'll comment on the documentation
part in a separate message.
> +static struct commit *get_commit_reference(const char *arg)
> +{
> + unsigned char revkey[20];
> + if (get_sha1(arg, revkey))
> + die("Not a valid object name %s", arg);
> + return lookup_commit_reference(revkey);
> +}
This returns a NULL when you feed a tree to the command, and...
> int cmd_merge_base(int argc, const char **argv, const char *prefix)
> {
> + struct commit **rev;
> int show_all = 0;
> + int rev_nr = 0;
>
> git_config(git_default_config, NULL);
>
> @@ -38,15 +48,18 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
> usage(merge_base_usage);
> argc--; argv++;
> }
> + if (argc < 3)
> usage(merge_base_usage);
> +
> + rev = xmalloc((argc - 1) * sizeof(*rev));
> +
> + do {
> + struct commit *r = get_commit_reference(argv[1]);
> + if (!r)
> + return 1;
... the command silently exits with 1.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-28 5:30 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807272148030.3486@nehalem.linux-foundation.org>
On Sun, 27 Jul 2008, Linus Torvalds wrote:
>
> And it's why gitk can start printing out the history _before_ three
> seconds has passed. And that's really really important.
Btw, the reason it's really really important is that "three seconds" can
actually easily be "three minutes" - if the project is big, or if you
simply don't have everything in the cache, so you actually need to do tons
of IO to generate the whole history.
So every normal operation absolutely _must_ be incremental and not rely on
any calculation of the whole history in order to then simplify it.
Of course, post-processing is fine for some things. For example, in the
thread I pointed you to originally (see filter-branch + full-history in
google, or look in some git archive) I suggested a post-processing of the
merge history for filter-branch. I suspect it's very acceptable for _that_
kind of use to "batch" things up and not do them with partial knowledge.
But this incremental thing is why I for example suggest people should use
"git gui blame" instead of "git blame" when looking for problems - because
the latter cannot be done incrementally, and as a result can cause really
irritating delays (exactly because it basically needs to synchronously
walk back to the beginning of history).
The kernel repo, btw, is pretty small in this regard. The cases that
caused much more pain were the insane KDE ones that were something like
ten times the size. We've optimized things pretty aggressively, but...
Btw, if I sound irritated, it's because we had all these discussions about
three _years_ ago when git got started. This is not a new issue. It's
hard.
I've been pushing on people to do things incrementally very hard over the
last few years because it's such a _huge_ usability issue.
For example, I've pointed you to the incremental nature of "gitk" as an
example of how things should work, but that's actually fairly recent: it
wasn't that long ago that "gitk" used to pass in "--topo-order" or
"--date-order" to the core git revision machinery, and that actually is
another of those "global" operations that you need the whole history for.
So gitk actually used to pause for three seconds (or ten. or thirty)
before it would show the results. I'm really happy to report that Paul
finally did the (trivial) topo-sort in gitk, meaning that he could re-sort
it as necessary and keep things incremental. It was one of my biggest UI
gripes for the longest time (and I wasted time adding a special "partial
output mode" that gitk didn't even then end up using because Paul did
things the right way).
Btw, from a git log viewer standpoint, the "merge history simplification"
is all the exact same problem as the "--topo-order" flag is: you could
use the (incremental and very verbose)
git log --full-history --parents
output as the base-line, and then you could do the commit simplification
of things interactively.
But "git log" itself cannot do it by default, since that would mean that
git log itself would have to wait for the whole history to be generated.
That's because output to a pipe is fundamentally linear (ie it cannot
"re-write" the things it has already shown as it finds a simplification:
there is no incremental way to rewrite things "after the fact").
Linus
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-28 5:00 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807280141140.6791@localhost.localdomain>
On Mon, 28 Jul 2008, Roman Zippel wrote:
>
> Of course I did:
>
> $ git log --parents --name-only --full-history lib/vsprintf.c | grep -e ^commit | wc -l
> 5929
>
> This is same amount of commits as for gitk.
OF COURSE it's the same numbr of commits. That's what gitk uses. That's
what you *have* to use.
You don't actually understand how git works, do you?
> These are the same 20 commits (with parents) from a simple git-log.
So what? The point I tried to make is that _any_ algorithm that gets the
above case right by actually simplifying the commits "post facto" probably
gets any case right. You tried to find some more interestign case, but you
missed the whole point - even the "simple" case is quite hard enough.
IOW, don't look for anythign more difficult, because if you do, you don't
understand the problem to begin with!
Do you not understand that the problem is that "post facto" isn't actually
acceptable? Have you looked at all at the revision reading code? Hmm?
The regular merge simplification does the simplification _before_ it has
gathered the whole history of commits. And that is really really
important.
And I realize that you don't even seem to understand the difference. But
to simplify it for you, let me give you a challenge. Try this:
time sh -c "git log --parents --full-history lib/vsprintf.c | head"
and if it takes noticeably more than a tenth of a second on my machine,
you lose.
Because that's roughly what it takes right now, and it's what means that
effectively the normal log is instantaneous. It's why you can start
looking at the log without waiting for three seconds, even though the
_full_ log may take three seconds to compute (ok, on my machine it takes
2.3s, but whatever).
And it's why gitk can start printing out the history _before_ three
seconds has passed. And that's really really important.
Try it. Really. Just do "gitk lib/vsprintf.c" and look at how it does
things incrementally. It doesn't wait for a couple of seconds and then
show things.
Absolutely EVERYTHING in git would be totally trivial if you did it all
based on generating first the whole history, and then simplifying it from
there. But git would be unusably slow in real life, and it would scale
_horribly_ badly with history size.
So _all_ the normal code actually generates the history INCREMENTALLY, and
it absolutely _has_ to work that way.
Linus
^ permalink raw reply
* Re: [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Steffen Prohaska @ 2008-07-28 5:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
In-Reply-To: <20080727212405.GA10075@spearce.org>
On Jul 27, 2008, at 11:24 PM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> The new execdir has is two levels below the root directory, while
>> the old execdir 'bin' was only one level below. This commit
>> adapts the discovery of oguilib that uses relative paths
>> accordingly.
> ...
>> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
>> index 940677c..baccd57 100755
>> --- a/git-gui/git-gui.sh
>> +++ b/git-gui/git-gui.sh
>> @@ -52,7 +52,9 @@ catch {rename send {}} ; # What an evil concept...
>> set oguilib {@@GITGUI_LIBDIR@@}
>> set oguirel {@@GITGUI_RELATIVE@@}
>> if {$oguirel eq {1}} {
>> - set oguilib [file dirname [file dirname [file normalize $argv0]]]
>> + set oguilib [file dirname \
>> + [file dirname \
>> + [file dirname [file normalize $argv0]]]]
>> set oguilib [file join $oguilib share git-gui lib]
>
> Hmmph. This actually comes up incorrectly on my system. The issue
> appears to be `git --exec-path` gives me $prefix/libexec/git-core,
> and git-gui installs its library into $prefix/libexec/share, which
> is wrong. It should have gone to $prefix/share.
I am not seeing this problem because I am installing using the
toplevel makefile, which sets and exports sharedir to $prefix/share.
> I wonder if this is better. Your other two patches seem fine.
>
> --8<--
> [PATCH] git-gui: Correct installation of library to be $prefix/share
>
> We always wanted the library for git-gui to install into the
> $prefix/share directory, not $prefix/libexec/share. All of
> the files in our library are platform independent and may
> be reused across systems, like any other content stored in
> the share directory.
>
> Our computation of where our library should install to was broken
> when git itself started installing to $prefix/libexec/git-core,
> which was one level down from where we expected it to be.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> Makefile | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b19fb2d..f72ab6c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -32,6 +32,9 @@ endif
> ifndef gitexecdir
> gitexecdir := $(shell git --exec-path)
> endif
> +ifeq (git-core,$(notdir $(gitexecdir)))
> + gitexecdir := $(patsubst %/,%,$(dir $(gitexecdir)))
> +endif
But gitexecdir has the correct value, no? gitexecdir is used
at several places in the makefile. It seems wrong to strip
'git-core' from gitexecdir. But I must admit that I do not
understand all the details of git-gui's Makefile. So maybe
you know better.
Isn't only the computation of sharedir based on gitexecdir wrong?
> ifndef sharedir
> sharedir := $(dir $(gitexecdir))share
and could be replaced with this (instead of your patch):
ifndef sharedir
+ifeq (git-core,$(notdir $(gitexecdir)))
+ sharedir := $(dir $(patsubst %/,%,$(dir $(gitexecdir))))share
+else
sharedir := $(dir $(gitexecdir))share
endif
+endif
Steffen
^ permalink raw reply
* [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-28 4:50 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin; +Cc: Miklos Vajna, Jakub Narebski
Before this patch "git merge-base" accepted only 2 arguments, so
only merge bases between 2 references could be computed.
The purpose of this patch is to make "git merge-base" accept more
than 2 arguments, so that the merge bases between the first given
reference and all the other references can be computed.
This is easily implemented because the "get_merge_bases_many"
function in "commit.c" already implements the needed computation.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-merge-base.txt | 27 +++++++++++++++--------
builtin-merge-base.c | 43 ++++++++++++++++++++++++-------------
commit.h | 2 +
3 files changed, 48 insertions(+), 24 deletions(-)
I only changed the code (according to what Dscho asked) not the
documentation in this version as I had not much time and I need
to think more about it.
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
index 1a7ecbf..463c230 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -8,26 +8,35 @@ git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
-'git merge-base' [--all] <commit> <commit>
+'git merge-base' [--all] <commit> <commit>...
DESCRIPTION
-----------
-'git-merge-base' finds as good a common ancestor as possible between
-the two commits. That is, given two commits A and B, `git merge-base A
-B` will output a commit which is reachable from both A and B through
-the parent relationship.
+'git-merge-base' finds as good common ancestors as possible between
+the first commit and the other commits. The default behavior is to
+output only one as good as possible common ancestor, called a merge
+base.
+
+For example, given two commits A and B, `git merge-base A B` will
+output a commit which is reachable from both A and B through the
+parent relationship.
+
+Given three commits A, B and C, `git merge-base A B C` will output a
+commit which is reachable through the parent relationship from both A
+and B, or from both A and C.
Given a selection of equally good common ancestors it should not be
relied on to decide in any particular way.
-The 'git-merge-base' algorithm is still in flux - use the source...
-
OPTIONS
-------
--all::
- Output all common ancestors for the two commits instead of
- just one.
+ Output all merge bases for the commits instead of just one. No
+ merge bases in the output should be an ancestor of another
+ merge base in the output. Each common ancestor of the first
+ commit and any of the other commits passed as arguments,
+ should be an ancestor of one of the merge bases in the output.
Author
------
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 1cb2925..881363f 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -2,9 +2,11 @@
#include "cache.h"
#include "commit.h"
-static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_all)
+static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
{
- struct commit_list *result = get_merge_bases(rev1, rev2, 0);
+ struct commit_list *result;
+
+ result = get_merge_bases_many(rev[0], rev_nr - 1, rev + 1, 0);
if (!result)
return 1;
@@ -20,13 +22,21 @@ static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_al
}
static const char merge_base_usage[] =
-"git merge-base [--all] <commit-id> <commit-id>";
+"git merge-base [--all] <commit-id> <commit-id>...";
+
+static struct commit *get_commit_reference(const char *arg)
+{
+ unsigned char revkey[20];
+ if (get_sha1(arg, revkey))
+ die("Not a valid object name %s", arg);
+ return lookup_commit_reference(revkey);
+}
int cmd_merge_base(int argc, const char **argv, const char *prefix)
{
- struct commit *rev1, *rev2;
- unsigned char rev1key[20], rev2key[20];
+ struct commit **rev;
int show_all = 0;
+ int rev_nr = 0;
git_config(git_default_config, NULL);
@@ -38,15 +48,18 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
usage(merge_base_usage);
argc--; argv++;
}
- if (argc != 3)
+ if (argc < 3)
usage(merge_base_usage);
- if (get_sha1(argv[1], rev1key))
- die("Not a valid object name %s", argv[1]);
- if (get_sha1(argv[2], rev2key))
- die("Not a valid object name %s", argv[2]);
- rev1 = lookup_commit_reference(rev1key);
- rev2 = lookup_commit_reference(rev2key);
- if (!rev1 || !rev2)
- return 1;
- return show_merge_base(rev1, rev2, show_all);
+
+ rev = xmalloc((argc - 1) * sizeof(*rev));
+
+ do {
+ struct commit *r = get_commit_reference(argv[1]);
+ if (!r)
+ return 1;
+ rev[rev_nr++] = r;
+ argc--; argv++;
+ } while (argc > 1);
+
+ return show_merge_base(rev, rev_nr, show_all);
}
diff --git a/commit.h b/commit.h
index 77de962..4829a5c 100644
--- a/commit.h
+++ b/commit.h
@@ -121,6 +121,8 @@ int read_graft_file(const char *graft_file);
struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
+extern struct commit_list *get_merge_bases_many(struct commit *one,
+ int n, struct commit **twos, int cleanup);
extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
extern int register_shallow(const unsigned char *sha1);
--
1.6.0.rc0.43.g00eb.dirty
^ permalink raw reply related
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