* Re: [PATCH] Added --export option to git-send-email.
From: Junio C Hamano @ 2008-07-13 22:05 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Eduard - Gabriel Munteanu, ryan, git
In-Reply-To: <32541b130807131444s5e9ea0d6v9610dd5871467fc9@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> So by encoding it this way, someone with a modern mailer could...
Heh, so by that definition Gnus is not modern enough; neither is webmail
interface at gmail.
>From which has originally zero level of >
>From which has one
>>From which has two
>>>From which has three
I am reasonably sure the above will be sent with one, one, two and three
gt before "From". Is your mailer modern enough?
^ permalink raw reply
* Re: [PATCH] gitk - work around stderr redirection on Cygwin
From: Mark Levedahl @ 2008-07-13 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: paulus, git, Eric Blake
In-Reply-To: <7vfxqdqxh7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Mark Levedahl <mlevedahl@gmail.com> writes:
>
>
>> Mark Levedahl wrote:
>>
>>> Cygwin is *still* shipping with antiquated Tcl 8.4.1, and will continue
>>> to do so for the indefinite future. This version does not understand
>>> the "2>@1" redirection syntax, so such redirection of stderr must be
>>> done using sh.
>>>
>> Ping. This bug is in 1.5.6.x, and thus also in the current Cygwin git
>> release: as a result, several gitk context menu items cause
>> errors. (Let me know if I should resend the patch).
>>
>
> In the meantime, is it an option to apply this as a port specific patch
> when Cygwin and whichever distribution ship with old Tcl package their
> binary releases?
>
> Just checking how urgent this issue is (8.4.1 was from Oct 2002 if I am
> not mistaken) for maintainers of Cygwin port, and I am suspecting that
> kernel folks are somewhat busy near/around OLS/KS timeframe (but not me).
>
>
(I didn't trim the message as I've copied the Cygwin git maintainer).
I certainly have this patch in my tree so the folks I supply git to who
use Cygwin have this patch. The question of whether to maintain this out
of tree for the official Cygwin release is up to Eric.
Mark
^ permalink raw reply
* Re: [PATCH] Added --export option to git-send-email.
From: Avery Pennarun @ 2008-07-13 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eduard - Gabriel Munteanu, ryan, git
In-Reply-To: <7vbq11qxfb.fsf@gitster.siamese.dyndns.org>
On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
> >> Sorry, but I am scratching my head here. Shouldn't this "bare From
> >> munging" be like this instead?
> >>
> >> $message =~ s/^From />From /m;
> >
> > That wouldn't be a reversible operation.
>
> So what? Adding Cc: and stuff send-email does are already irreversible
> anyway.
At one point the people who write mailers realized that just munging
"From" to ">From" when putting things into an mbox was irreversible,
ie, there was no way to later display the contents of the mbox without
showing ">From" where "From" was intended.
However, if you always insert _another_ ">" whenever "^>*From" is
detected, then you can also always do the opposite upon displaying to
the user, and the message is effectively not munged. It becomes
simply a part of the mbox file encoding.
So by encoding it this way, someone with a modern mailer could view
the resulting mbox with all the munged text de-mungled. Someone
without a modern mailer would see munging anyhow, so they're no worse
off.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Junio C Hamano @ 2008-07-13 21:38 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git, John Hawley, Jakub Narebski, Petr Baudis
In-Reply-To: <1215738665-5153-1-git-send-email-LeWiemann@gmail.com>
Lea Wiemann <lewiemann@gmail.com> writes:
> Here's some elaboration on why I didn't use or extend Git.pm.
>
> Please note before starting a reply to this: This is not an argument;
> I'm just explaining why I implemented it the way I did. So please
> don't try to argue with me about what I should or should have done....
> ...
> So where do we go with Git.pm and Git::Repo? I would suggest that
> they both stay.
This probably is something the person who mentors you as a GSoC student
should tell you, and shouldn't come from me, but I am going to mention
it anyway.
I thought GSoC program was about giving participants a chance to acquire
skills to work better with open source community, and I firmly believe
that a major component of that skillset is about working with people,
probably even more so than about working with code. Of course you need
have a certain basic coding skills and disciplines, but it is clear to
everybody that you are beyond that threashold already. I would have
preferred to see the first paragraph of yours stated more diplomaticly;
it sounds rather unilateral ultimatum to me.
Having said that, I agree with your reasoning. People who care enough can
help refactoring Git.pm to build on top of Git::Repo (this would include
adding missing Git::WC and possibly others), but I agree that would
largely be outside of the scope of gitweb caching.
This patch was not signed-off, but I assume it was simply forgotten and
not deliberate?
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Junio C Hamano @ 2008-07-13 21:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080713111847.29801.8969.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> When Git sees a string with trailing dot on a place where revision
> range could occur, it will unconditionally append another dot to
> it to help complete a revision range. However, filespec can usually
> occur at such a place as well. I have been hitting this all the time
> lately with
>
> git log git-submodule.<tab>
>
> and the like.
Modulo s/Git/bash-completion/ ;-) I think this makes sense.
> This patch will make Git perform the . -> .. completion in
> __git_complete_revlist only if there is no filename starting with
> the entered prefix available. At few places, filename could not occur
> when calling __git_complete_revlist; however, taking this into account
> did not seem worth complicating the code further.
Theoretically we could take a hint from presense of '--' like d773c63
(bash: offer only paths after '--', 2008-07-08) did. If the command line
has double-dash and the token we are looking at is before it, it cannot be
pathname and this check does not have to trigger. But I agree that is not
worth it, because this "theoretical" solution would mean that the user
needs to something awkward like:
git log v1.5.6. --<C-b><C-b><C-b><TAB>
to take advantage of it.
By the way, the above command line is another "dot" related frustration I
always have. If you try:
git log v1.5.6.<TAB>
the completion code adds a dot unconditionally when I want to choose from
the list of v1.5.6.X tags. Of course, I can work this around by dropping
the last dot before asking for completion, so it is not really a very big
deal, but I mention it here because this annoyance is exactly in the same
league as your "git-submodule.<TAB>" example.
"git show v1.5.6.<TAB>" does complete as expected, which is understandable
(the command does not take range, and completion knows about it -- which
is quite nice).
> contrib/completion/git-completion.bash | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 61581fe..fe24b8c 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -325,7 +325,12 @@ __git_complete_revlist ()
> __gitcomp "$(__git_refs)" "$pfx" "$cur"
> ;;
> *.)
> - __gitcomp "$cur."
> + if ls "$cur"* >/dev/null 2>&1; then
There is a slight Yuck factor for using "ls" here but I do not think of a
better alternative offhand.
Will queue on top of Shawn's previous one. Thanks.
^ permalink raw reply
* Re: [PATCH] bash completion: Improve responsiveness of git-log completion
From: Junio C Hamano @ 2008-07-13 21:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Petr Baudis, Ingo Molnar
In-Reply-To: <20080713023742.GA31760@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio noticed the bash completion has been taking a long time lately....
The credit actually goes to Ingo.
> Petr Baudis tracked it down to 72e5e989b ("bash: Add space after
> unique command name is completed."). Tracing the code showed
> we spent significant time inside of this loop within __gitcomp,
> due to the string copying overhead....
> ...
> Does this make things better? Or worse? I'm not seeing a huge
> difference on my own system. Maybe its too fast these days...
Ingo, I understand you have stopped using the completion long time ago due
to this latency issue. Together with d773c63 (bash: offer only paths
after '--', 2008-07-08) that already is in 'maint' and 'master', this
hopefully would make the completion usable for you again?
^ permalink raw reply
* Re: [PATCH] git-mailinfo: use strbuf's instead of fixed buffers
From: Junio C Hamano @ 2008-07-13 21:37 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Git Mailing List
In-Reply-To: <487A49B4.6000407@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> +static void parse_bogus_from(const struct strbuf *line)
> {
> ...
> +static void handle_from(const struct strbuf *from)
> {
> ...
> if (!at)
> - return bogus_from(line);
> + return parse_bogus_from(from);
That's GCCism isn't it? I'll queue this probably for 'pu' with local
fixups, so no need to resend for this particular issue, though.
^ permalink raw reply
* Re: [PATCH] Added --export option to git-send-email.
From: Junio C Hamano @ 2008-07-13 21:36 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Eduard - Gabriel Munteanu, ryan, git
In-Reply-To: <32541b130807131432j78e5100dyea20893268321466@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
>> Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
>> > + } elsif (defined $export_file) {
>> > + my $mbox_from = "From $raw_from $date";
>> > + $message =~ s/^(>{0,})From/>$1From/m;
>> > + print $out "$mbox_from\n$header\n$message";
>>
>> Sorry, but I am scratching my head here. Shouldn't this "bare From
>> munging" be like this instead?
>>
>> $message =~ s/^From />From /m;
>
> That wouldn't be a reversible operation.
So what? Adding Cc: and stuff send-email does are already irreversible
anyway.
^ permalink raw reply
* Re: [PATCH] gitk - work around stderr redirection on Cygwin
From: Junio C Hamano @ 2008-07-13 21:35 UTC (permalink / raw)
To: Mark Levedahl; +Cc: paulus, git
In-Reply-To: <487A6780.7030500@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> writes:
> Mark Levedahl wrote:
>> Cygwin is *still* shipping with antiquated Tcl 8.4.1, and will continue
>> to do so for the indefinite future. This version does not understand
>> the "2>@1" redirection syntax, so such redirection of stderr must be
>> done using sh.
>
> Ping. This bug is in 1.5.6.x, and thus also in the current Cygwin git
> release: as a result, several gitk context menu items cause
> errors. (Let me know if I should resend the patch).
In the meantime, is it an option to apply this as a port specific patch
when Cygwin and whichever distribution ship with old Tcl package their
binary releases?
Just checking how urgent this issue is (8.4.1 was from Oct 2002 if I am
not mistaken) for maintainers of Cygwin port, and I am suspecting that
kernel folks are somewhat busy near/around OLS/KS timeframe (but not me).
^ permalink raw reply
* Re: [PATCH] Added --export option to git-send-email.
From: Avery Pennarun @ 2008-07-13 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eduard - Gabriel Munteanu, ryan, git
In-Reply-To: <7vskudr11m.fsf@gitster.siamese.dyndns.org>
On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
> Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
> > + } elsif (defined $export_file) {
> > + my $mbox_from = "From $raw_from $date";
> > + $message =~ s/^(>{0,})From/>$1From/m;
> > + print $out "$mbox_from\n$header\n$message";
>
> Sorry, but I am scratching my head here. Shouldn't this "bare From
> munging" be like this instead?
>
> $message =~ s/^From />From /m;
That wouldn't be a reversible operation.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] git-bisect: use dash-less form on git bisect log
From: Junio C Hamano @ 2008-07-13 21:26 UTC (permalink / raw)
To: Christian Couder; +Cc: Miklos Vajna, git
In-Reply-To: <200807130819.24206.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Your patch looks good. But there is also the problem that new bisect logs
> will not be understood by old git. So I wonder if a patch to only read the
> new log should be first commited to the "maint" branch.
I do not think it is worth it. If we are making something long lived like
rerere cache backward incompatible, the approach would be sensible, but
bisect log is about a single session and once you reached the breakage you
would not reuse it. Besides, the bisect log is designed to be executable
shell script so you can always copy it out, edit it if needed and feed
that to shell.
^ permalink raw reply
* Re: [PATCH 0/4] Proposed patches
From: Catalin Marinas @ 2008-07-13 21:10 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git
In-Reply-To: <487A5032.9090307@etek.chalmers.se>
2008/7/13 Lukas Sandström <lukass@etek.chalmers.se>:
> Catalin Marinas wrote:
>> 2008/7/13 Catalin Marinas <catalin.marinas@gmail.com>:
>>> A new post of the proposed patches after implementing Karl's comments.
>>
>> BTW, these are StGIT patches, I forgot to add the prefix in the subject line.
>>
> If you run "git config format.subjectprefix 'StGIT PATCH'" in your repo,
> git format-patch will add the prefix automatically for you.
>
> StGIT might have a similar option.
No, it doesn't, but it would be good to have one. The alternative in
StGIT is to modify the (local) template file.
Thanks,
--
Catalin
^ permalink raw reply
* Re: [PATCH] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Schindelin @ 2008-07-13 20:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <1215981083-10815-5-git-send-email-johannes.sixt@telecom.at>
Hi,
On Sun, 13 Jul 2008, Johannes Sixt wrote:
> [a patch series, with 3 patches from Steffen]
Wow. I like this demonstration how a nice patch series looks like.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation
From: Johannes Schindelin @ 2008-07-13 20:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <1215981083-10815-4-git-send-email-johannes.sixt@telecom.at>
Hi,
On Sun, 13 Jul 2008, Johannes Sixt wrote:
> diff --git a/Makefile b/Makefile
> index 4796565..2bdb9bf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1301,7 +1301,7 @@ remove-dashes:
> ### Installation rules
>
> ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> -template_instdir = $(gitexecdir)/$(template_dir)
> +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
What is this for? Did the original line stop working?
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 8899e31..45f92eb 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -5,6 +5,7 @@
>
> extern char **environ;
> static const char *argv_exec_path;
> +static const char *argv0_path;
>
> static const char *builtin_exec_path(void)
> {
> @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
>
> const char *system_path(const char *path)
> {
> - if (!is_absolute_path(path)) {
> + if (!is_absolute_path(path) && argv0_path) {
> struct strbuf d = STRBUF_INIT;
> - strbuf_addf(&d, "%s/%s", git_exec_path(), path);
> + strbuf_addf(&d, "%s/%s", argv0_path, path);
> path = strbuf_detach(&d, NULL);
> }
> return path;
> }
>
> +void git_set_argv0_path(const char *path)
> +{
> + argv0_path = path;
> +}
> +
> void git_set_argv_exec_path(const char *exec_path)
> {
> argv_exec_path = exec_path;
> @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
> }
> }
>
> -void setup_path(const char *cmd_path)
> +void setup_path(void)
It seems to me that this patch would not do anything different, but with
less code change, if setup_path() would set argv0_path, and not a new
function was introduced.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitk - work around stderr redirection on Cygwin
From: Mark Levedahl @ 2008-07-13 20:37 UTC (permalink / raw)
To: Mark Levedahl, paulus, Junio C Hamano; +Cc: git
In-Reply-To: <1213462668-424-1-git-send-email-mlevedahl@gmail.com>
Mark Levedahl wrote:
> Cygwin is *still* shipping with antiquated Tcl 8.4.1, and will continue
> to do so for the indefinite future. This version does not understand
> the "2>@1" redirection syntax, so such redirection of stderr must be
> done using sh.
>
Ping. This bug is in 1.5.6.x, and thus also in the current Cygwin git
release: as a result, several gitk context menu items cause errors. (Let
me know if I should resend the patch).
Mark
^ permalink raw reply
* [PATCH] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <1215981083-10815-4-git-send-email-johannes.sixt@telecom.at>
If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
it is interpreted relative to the command's invocation path, which usually
is $(bindir).
The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 23 +++++++++++++++--------
exec_cmd.c | 38 ++------------------------------------
2 files changed, 17 insertions(+), 44 deletions(-)
diff --git a/Makefile b/Makefile
index 2bdb9bf..3593e6f 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,10 +1307,17 @@ template_instdir = $(template_dir)
endif
export template_instdir
+ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
+gitexec_instdir = $(shell cd '$(bindir_SQ)/$(gitexecdir_SQ)' && pwd)
+else
+gitexec_instdir = $(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
+
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1318,18 +1325,18 @@ ifndef NO_TCLTK
$(MAKE) -C gitk-git install
$(MAKE) -C git-gui install
endif
- if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
+ if test 'z$(bindir_SQ)' != 'z$(gitexec_instdir_SQ)'; \
then \
ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
- '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \
+ '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' || \
cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
- '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
+ '$(DESTDIR_SQ)$(gitexec_instdir_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' ;)
+ $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' ;)
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+ $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
endif
- ./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
+ ./check_bindir 'z$(bindir_SQ)' 'z$(gitexec_instdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
install-doc:
$(MAKE) -C Documentation install
diff --git a/exec_cmd.c b/exec_cmd.c
index 45f92eb..c236034 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -7,40 +7,6 @@ extern char **environ;
static const char *argv_exec_path;
static const char *argv0_path;
-static const char *builtin_exec_path(void)
-{
-#ifndef __MINGW32__
- return GIT_EXEC_PATH;
-#else
- int len;
- char *p, *q, *sl;
- static char *ep;
- if (ep)
- return ep;
-
- len = strlen(_pgmptr);
- if (len < 2)
- return ep = ".";
-
- p = ep = xmalloc(len+1);
- q = _pgmptr;
- sl = NULL;
- /* copy program name, turn '\\' into '/', skip last part */
- while ((*p = *q)) {
- if (*q == '\\' || *q == '/') {
- *p = '/';
- sl = p;
- }
- p++, q++;
- }
- if (sl)
- *sl = '\0';
- else
- ep[0] = '.', ep[1] = '\0';
- return ep;
-#endif
-}
-
const char *system_path(const char *path)
{
if (!is_absolute_path(path) && argv0_path) {
@@ -75,7 +41,7 @@ const char *git_exec_path(void)
return env;
}
- return builtin_exec_path();
+ return system_path(GIT_EXEC_PATH);
}
static void add_path(struct strbuf *out, const char *path)
@@ -99,7 +65,7 @@ void setup_path(void)
add_path(&new_path, argv_exec_path);
add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
- add_path(&new_path, builtin_exec_path());
+ add_path(&new_path, system_path(GIT_EXEC_PATH));
add_path(&new_path, argv0_path);
if (old_path)
--
1.5.6.2.300.ga3a9
^ permalink raw reply related
* [PATCH] Allow add_path() to add non-existent directories to the path
From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <1215981083-10815-5-git-send-email-johannes.sixt@telecom.at>
This function had used make_absolute_path(); but this function dies if
the directory that contains the entry whose relative path was supplied in
the argument does not exist. This is a problem if the argument is, for
example, "../libexec/git-core", and that "../libexec" does not exist.
Since the resolution of symbolic links is not required for elements in
PATH, we can fall back to using make_nonrelative_path(), which simply
prepends $PWD to the path.
We have to move make_nonrelative_path() alongside make_absolute_path() in
abspath.c so that git-shell can be linked. See 5b8e6f85f.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
abspath.c | 36 ++++++++++++++++++++++++++++++++++++
exec_cmd.c | 2 +-
path.c | 36 ------------------------------------
3 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/abspath.c b/abspath.c
index 4f95a95..99ee1af 100644
--- a/abspath.c
+++ b/abspath.c
@@ -66,3 +66,39 @@ const char *make_absolute_path(const char *path)
return buf;
}
+
+static const char *get_pwd_cwd(void)
+{
+ static char cwd[PATH_MAX + 1];
+ char *pwd;
+ struct stat cwd_stat, pwd_stat;
+ if (getcwd(cwd, PATH_MAX) == NULL)
+ return NULL;
+ pwd = getenv("PWD");
+ if (pwd && strcmp(pwd, cwd)) {
+ stat(cwd, &cwd_stat);
+ if (!stat(pwd, &pwd_stat) &&
+ pwd_stat.st_dev == cwd_stat.st_dev &&
+ pwd_stat.st_ino == cwd_stat.st_ino) {
+ strlcpy(cwd, pwd, PATH_MAX);
+ }
+ }
+ return cwd;
+}
+
+const char *make_nonrelative_path(const char *path)
+{
+ static char buf[PATH_MAX + 1];
+
+ if (is_absolute_path(path)) {
+ if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+ die ("Too long path: %.*s", 60, path);
+ } else {
+ const char *cwd = get_pwd_cwd();
+ if (!cwd)
+ die("Cannot determine the current working directory");
+ if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
+ die ("Too long path: %.*s", 60, path);
+ }
+ return buf;
+}
diff --git a/exec_cmd.c b/exec_cmd.c
index c236034..0ed768d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -50,7 +50,7 @@ static void add_path(struct strbuf *out, const char *path)
if (is_absolute_path(path))
strbuf_addstr(out, path);
else
- strbuf_addstr(out, make_absolute_path(path));
+ strbuf_addstr(out, make_nonrelative_path(path));
strbuf_addch(out, PATH_SEP);
}
diff --git a/path.c b/path.c
index 5983255..16c1d01 100644
--- a/path.c
+++ b/path.c
@@ -291,42 +291,6 @@ int adjust_shared_perm(const char *path)
return 0;
}
-static const char *get_pwd_cwd(void)
-{
- static char cwd[PATH_MAX + 1];
- char *pwd;
- struct stat cwd_stat, pwd_stat;
- if (getcwd(cwd, PATH_MAX) == NULL)
- return NULL;
- pwd = getenv("PWD");
- if (pwd && strcmp(pwd, cwd)) {
- stat(cwd, &cwd_stat);
- if (!stat(pwd, &pwd_stat) &&
- pwd_stat.st_dev == cwd_stat.st_dev &&
- pwd_stat.st_ino == cwd_stat.st_ino) {
- strlcpy(cwd, pwd, PATH_MAX);
- }
- }
- return cwd;
-}
-
-const char *make_nonrelative_path(const char *path)
-{
- static char buf[PATH_MAX + 1];
-
- if (is_absolute_path(path)) {
- if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
- die ("Too long path: %.*s", 60, path);
- } else {
- const char *cwd = get_pwd_cwd();
- if (!cwd)
- die("Cannot determine the current working directory");
- if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
- die ("Too long path: %.*s", 60, path);
- }
- return buf;
-}
-
const char *make_relative_path(const char *abs, const char *base)
{
static char buf[PATH_MAX + 1];
--
1.5.6.2.300.ga3a9
^ permalink raw reply related
* [PATCH] Fix relative built-in paths to be relative to the command invocation
From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <1215981083-10815-3-git-send-email-johannes.sixt@telecom.at>
$(gitexecdir) (as defined in the Makefile) has gained another path
component, but the relative paths in the MINGW section of the Makefile,
which are interpreted relative to it, do not account for it.
Instead of adding another ../ in front of the path, we change the code that
constructs the absolute paths to do it relative to the command's directory,
which is essentially $(bindir). We do it this way because we will also
allow a relative $(gitexecdir) later.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 2 +-
exec_cmd.c | 14 ++++++++++----
exec_cmd.h | 3 ++-
git.c | 5 ++---
receive-pack.c | 2 +-
shell.c | 4 ++--
upload-pack.c | 2 +-
7 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index 4796565..2bdb9bf 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,7 +1301,7 @@ remove-dashes:
### Installation rules
ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(gitexecdir)/$(template_dir)
+template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
else
template_instdir = $(template_dir)
endif
diff --git a/exec_cmd.c b/exec_cmd.c
index 8899e31..45f92eb 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -5,6 +5,7 @@
extern char **environ;
static const char *argv_exec_path;
+static const char *argv0_path;
static const char *builtin_exec_path(void)
{
@@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
const char *system_path(const char *path)
{
- if (!is_absolute_path(path)) {
+ if (!is_absolute_path(path) && argv0_path) {
struct strbuf d = STRBUF_INIT;
- strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+ strbuf_addf(&d, "%s/%s", argv0_path, path);
path = strbuf_detach(&d, NULL);
}
return path;
}
+void git_set_argv0_path(const char *path)
+{
+ argv0_path = path;
+}
+
void git_set_argv_exec_path(const char *exec_path)
{
argv_exec_path = exec_path;
@@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
}
}
-void setup_path(const char *cmd_path)
+void setup_path(void)
{
const char *old_path = getenv("PATH");
struct strbuf new_path;
@@ -94,7 +100,7 @@ void setup_path(const char *cmd_path)
add_path(&new_path, argv_exec_path);
add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
add_path(&new_path, builtin_exec_path());
- add_path(&new_path, cmd_path);
+ add_path(&new_path, argv0_path);
if (old_path)
strbuf_addstr(&new_path, old_path);
diff --git a/exec_cmd.h b/exec_cmd.h
index 7eb94e5..0c46cd5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,8 +2,9 @@
#define GIT_EXEC_CMD_H
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(const char *);
+extern void setup_path(void);
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);
diff --git a/git.c b/git.c
index 7075533..b90c358 100644
--- a/git.c
+++ b/git.c
@@ -470,7 +470,6 @@ int main(int argc, const char **argv)
{
const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help";
char *slash = (char *)cmd + strlen(cmd);
- const char *cmd_path = NULL;
int done_alias = 0;
/*
@@ -483,7 +482,7 @@ int main(int argc, const char **argv)
while (cmd <= slash && !is_dir_sep(*slash));
if (cmd <= slash) {
*slash++ = 0;
- cmd_path = cmd;
+ git_set_argv0_path(cmd);
cmd = slash;
}
@@ -527,7 +526,7 @@ int main(int argc, const char **argv)
* environment, and the $(gitexecdir) from the Makefile at build
* time.
*/
- setup_path(cmd_path);
+ setup_path();
while (1) {
/* See if it's an internal command */
diff --git a/receive-pack.c b/receive-pack.c
index fa653b4..d44c19e 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -482,7 +482,7 @@ int main(int argc, char **argv)
if (!dir)
usage(receive_pack_usage);
- setup_path(NULL);
+ setup_path();
if (!enter_repo(dir, 0))
die("'%s': unable to chdir or not a git archive", dir);
diff --git a/shell.c b/shell.c
index 91ca7de..6a48de0 100644
--- a/shell.c
+++ b/shell.c
@@ -15,7 +15,7 @@ static int do_generic_cmd(const char *me, char *arg)
{
const char *my_argv[4];
- setup_path(NULL);
+ setup_path();
if (!arg || !(arg = sq_dequote(arg)))
die("bad argument");
if (prefixcmp(me, "git-"))
@@ -37,7 +37,7 @@ static int do_cvs_cmd(const char *me, char *arg)
if (!arg || strcmp(arg, "server"))
die("git-cvsserver only handles server: %s", arg);
- setup_path(NULL);
+ setup_path();
return execv_git_cmd(cvsserver_argv);
}
diff --git a/upload-pack.c b/upload-pack.c
index 9f82941..c911e70 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -638,7 +638,7 @@ int main(int argc, char **argv)
if (i != argc-1)
usage(upload_pack_usage);
- setup_path(NULL);
+ setup_path();
dir = argv[i];
--
1.5.6.2.300.ga3a9
^ permalink raw reply related
* [PATCH] help (Windows): Display HTML in default browser using Windows' shell API
From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <1215981083-10815-2-git-send-email-johannes.sixt@telecom.at>
From: Steffen Prohaska <prohaska@zib.de>
The system's default browser for displaying HTML help pages is now used
directly on Windows, instead of launching git-web--browser, which
requires a Unix shell. Avoiding MSYS' bash when possible is good
because it avoids potential path translation issues. In this case it is
not too hard to avoid launching a shell, so let's avoid it.
The Windows-specific code is implemented in compat/mingw.c to avoid
platform-specific code in the main code base. On Windows, open_html is
provided as a define. If open_html is not defined, git-web--browse is
used. This approach avoids platform-specific ifdefs by using
per-function ifdefs. The "ifndef open_html" together with the
introductory comment should sufficiently warn developers, so that they
hopefully will not break this mechanism.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
compat/mingw.c | 21 +++++++++++++++++++++
compat/mingw.h | 3 +++
help.c | 14 +++++++++++++-
3 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 3a05fe7..0ca73f7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
timer_fn = handler;
return old;
}
+
+static const char *make_backslash_path(const char *path) {
+ static char buf[PATH_MAX + 1];
+ char *c;
+
+ if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+ die ("Too long path: %.*s", 60, path);
+
+ for (c = buf; *c; c++) {
+ if (*c == '/')
+ *c = '\\';
+ }
+ return buf;
+}
+
+void mingw_open_html(const char *unixpath)
+{
+ const char *htmlpath = make_backslash_path(unixpath);
+ printf("Launching default browser to display HTML ...\n");
+ ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index 6bc049a..5a3bcee 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -202,6 +202,9 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler);
#define PATH_SEP ';'
#define PRIuMAX "I64u"
+void mingw_open_html(const char *path);
+#define open_html mingw_open_html
+
/*
* helpers
*/
diff --git a/help.c b/help.c
index 0f055bf..52d39b8 100644
--- a/help.c
+++ b/help.c
@@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
strbuf_addf(page_path, "%s/%s.html", html_path, page);
}
+/*
+ * If open_html is not defined in a platform-specific way (see for
+ * example compat/mingw.h), we use the script web--browse to display
+ * HTML.
+ */
+#ifndef open_html
+void open_html(const char *path)
+{
+ execl_git_cmd("web--browse", "-c", "help.browser", path, NULL);
+}
+#endif
+
static void show_html_page(const char *git_cmd)
{
const char *page = cmd_to_page(git_cmd);
@@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd)
get_html_page_path(&page_path, page);
- execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+ open_html(page_path.buf);
}
void help_unknown_cmd(const char *cmd)
--
1.5.6.2.300.ga3a9
^ permalink raw reply related
* [PATCH] Move code interpreting path relative to exec-dir to new function system_path()
From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <7v1w1yupn4.fsf@gitster.siamese.dyndns.org>
From: Steffen Prohaska <prohaska@zib.de>
Expanding system paths relative to git_exec_path can be used for
creating an installation that can be moved to a different directory
without re-compiling. We use this approach for template_dir and the
system wide gitconfig. The Windows installer (msysgit) is an example
for such a setup.
This commit moves common code to a new function system_path(). System
paths that are to be interpreted relative to git_exec_path are passed to
system_path() and the return value is used instead of the original path.
system_path() prefixes a relative path with git_exec_path and leaves
absolute paths unmodified. For example, we now write
template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
[j6t: moved from path.c to exec_cmd.c]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-init-db.c | 14 ++------------
config.c | 11 ++---------
exec_cmd.c | 10 ++++++++++
exec_cmd.h | 2 +-
4 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index e23b843..5ba213a 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -115,18 +115,8 @@ static void copy_templates(const char *template_dir)
if (!template_dir)
template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
- if (!template_dir) {
- /*
- * if the hard-coded template is relative, it is
- * interpreted relative to the exec_dir
- */
- template_dir = DEFAULT_GIT_TEMPLATE_DIR;
- if (!is_absolute_path(template_dir)) {
- struct strbuf d = STRBUF_INIT;
- strbuf_addf(&d, "%s/%s", git_exec_path(), template_dir);
- template_dir = strbuf_detach(&d, NULL);
- }
- }
+ if (!template_dir)
+ template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
strcpy(template_path, template_dir);
template_len = strlen(template_path);
if (template_path[template_len-1] != '/') {
diff --git a/config.c b/config.c
index 2862cc4..1e066c7 100644
--- a/config.c
+++ b/config.c
@@ -581,15 +581,8 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
const char *git_etc_gitconfig(void)
{
static const char *system_wide;
- if (!system_wide) {
- system_wide = ETC_GITCONFIG;
- if (!is_absolute_path(system_wide)) {
- /* interpret path relative to exec-dir */
- struct strbuf d = STRBUF_INIT;
- strbuf_addf(&d, "%s/%s", git_exec_path(), system_wide);
- system_wide = strbuf_detach(&d, NULL);
- }
- }
+ if (!system_wide)
+ system_wide = system_path(ETC_GITCONFIG);
return system_wide;
}
diff --git a/exec_cmd.c b/exec_cmd.c
index da04efe..8899e31 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -40,6 +40,16 @@ static const char *builtin_exec_path(void)
#endif
}
+const char *system_path(const char *path)
+{
+ if (!is_absolute_path(path)) {
+ struct strbuf d = STRBUF_INIT;
+ strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+ path = strbuf_detach(&d, NULL);
+ }
+ return path;
+}
+
void git_set_argv_exec_path(const char *exec_path)
{
argv_exec_path = exec_path;
diff --git a/exec_cmd.h b/exec_cmd.h
index a892355..7eb94e5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -6,6 +6,6 @@ extern const char* git_exec_path(void);
extern void setup_path(const char *);
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);
#endif /* GIT_EXEC_CMD_H */
--
1.5.6.2.300.ga3a9
^ permalink raw reply related
* [PATCH] help.c: Add support for htmldir relative to git_exec_path()
From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <1215981083-10815-1-git-send-email-johannes.sixt@telecom.at>
From: Steffen Prohaska <prohaska@zib.de>
If htmldir (in the Makefile) is a relative path, this path will now be
interpreted relative to git_exec_path. This can be used to create an
installation that can be moved to a different directory without
re-compiling. The Windows installer (msysgit) is an example for such
a setup.
Note that the Makefile maps htmldir to the define GIT_HTML_PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
help.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/help.c b/help.c
index ca9632b..0f055bf 100644
--- a/help.c
+++ b/help.c
@@ -633,13 +633,15 @@ static void show_info_page(const char *git_cmd)
static void get_html_page_path(struct strbuf *page_path, const char *page)
{
struct stat st;
+ const char *html_path = system_path(GIT_HTML_PATH);
/* Check that we have a git documentation directory. */
- if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode))
- die("'%s': not a documentation directory.", GIT_HTML_PATH);
+ if (stat(mkpath("%s/git.html", html_path), &st)
+ || !S_ISREG(st.st_mode))
+ die("'%s': not a documentation directory.", html_path);
strbuf_init(page_path, 0);
- strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page);
+ strbuf_addf(page_path, "%s/%s.html", html_path, page);
}
static void show_html_page(const char *git_cmd)
--
1.5.6.2.300.ga3a9
^ permalink raw reply related
* Re: [PATCH] Added --export option to git-send-email.
From: Junio C Hamano @ 2008-07-13 20:17 UTC (permalink / raw)
To: Eduard - Gabriel Munteanu; +Cc: ryan, git
In-Reply-To: <20080710170735.4c5b237a@linux360.ro>
Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 3564419..53539cf 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -741,6 +747,10 @@ X-Mailer: git-send-email $gitversion
>
> if ($dry_run) {
> # We don't want to send the email.
> + } elsif (defined $export_file) {
> + my $mbox_from = "From $raw_from $date";
> + $message =~ s/^(>{0,})From/>$1From/m;
> + print $out "$mbox_from\n$header\n$message";
Sorry, but I am scratching my head here. Shouldn't this "bare From
munging" be like this instead?
$message =~ s/^From />From /m;
^ permalink raw reply
* Re: found some nice git scripts
From: Petr Baudis @ 2008-07-13 20:12 UTC (permalink / raw)
To: Raimund Bauer; +Cc: git, gitorious
In-Reply-To: <1214599789.6576.1.camel@doriath>
On Fri, Jun 27, 2008 at 10:49:49PM +0200, Raimund Bauer wrote:
> Maybe somebody else find them useful too:
> http://git-wt-commit.rubyforge.org/
Interesting. I wonder if the William Morgan knows about git
show-branch? It provides very similar functionality, but soemwhat
different kind of output; extending it with git-wtf-like functionality
(that is, per-branch "merge status summary", and "flat" view of commits)
might be quite easy and practical for others at the same time.
About, git-publish-branch, again, maybe it would make a great deal of
sense to teach git-push a --track flag?
I understand if the author has not much desire to reimplement this in
C, on the other hand everyone would benefit from builtin support; maybe
someone else gets inspired.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] Improve sed portability
From: Jakub Narebski @ 2008-07-13 20:00 UTC (permalink / raw)
To: Chris Ridd
In-Reply-To: <484FEF71.2030909@isode.com>
Chris Ridd <chris.ridd@isode.com> writes:
> Of course, using a plain old:
>
> echo "$1"
>
> should work well too. Why is printf being used here and not echo,
> anyway?
Uh, because 'echo -n' is not portable enough, and for some reason it
was though that there shouldn't be final newline?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/Test] Build in merge is broken
From: Junio C Hamano @ 2008-07-13 19:11 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Sverre Hvammen Johansen, git
In-Reply-To: <20080713184300.GF10347@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Sun, Jul 13, 2008 at 07:46:59PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> So far what I see is that the input for the reduce_heads() function is
>> (c1, c0, c2, c0, c1). The expected output would be (c1, c2), but the
>> actual output is c2. So I suspect the bug is not in builtin-merge.c
>> itself but in reduce_heads().
>
> This fixes the problem for me. Junio, does the fix looks correct to you
> as well?
You are correct, the "item"s are the highlander (i.e. "there can be only
one") objects but commit-list elements that hold pointers to them are not,
so we need to dereference and compare.
Thanks.
^ 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