* [updated patch v3 2/2] Improve transport helper exec failure reporting
From: Ilari Liusvaara @ 2009-12-31 18:26 UTC (permalink / raw)
To: git
In-Reply-To: <1262284003-1417-1-git-send-email-ilari.liusvaara@elisanet.fi>
Previously transport-helper exec failure error reporting was pretty
much useless as it didn't report errors from execve, only from pipe
and fork. Now that run-command passes errno from exec, use the
improved support to actually print useful errors if execution fails.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
transport-helper.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 5078c71..73da339 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -31,13 +31,19 @@ static struct child_process *get_helper(struct transport *transport)
helper->out = -1;
helper->err = 0;
helper->argv = xcalloc(4, sizeof(*helper->argv));
- strbuf_addf(&buf, "remote-%s", data->name);
+ strbuf_addf(&buf, "git-remote-%s", data->name);
helper->argv[0] = strbuf_detach(&buf, NULL);
helper->argv[1] = transport->remote->name;
helper->argv[2] = transport->url;
- helper->git_cmd = 1;
- if (start_command(helper))
- die("Unable to run helper: git %s", helper->argv[0]);
+ helper->git_cmd = 0;
+ helper->silent_exec_failure = 1;
+ if (start_command(helper)) {
+ if (errno == ENOENT)
+ die("Unable to find remote helper for \"%s\"",
+ data->name);
+ else
+ die_errno("Unable to run helper %s", helper->argv[0]);
+ }
data->helper = helper;
write_str_in_full(helper->in, "capabilities\n");
--
1.6.6.3.gaa2e1
^ permalink raw reply related
* Re: [Updated PATCH 2/2] Improve transport helper exec failure reporting
From: Johannes Sixt @ 2009-12-31 18:44 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20091231182436.GA1326@Knoppix>
Ilari Liusvaara schrieb:
> On Thu, Dec 31, 2009 at 06:48:02PM +0100, Johannes Sixt wrote:
>> In case 3, it is expected that the child process prints a suitable
>> error message. Therefore, you should start with merely replacing the
>> unconditional
>>
>> exit(127);
>> by
>> if (errno == ENOENT)
>> exit(127);
>> else
>> die_errno("Cannot exec %s", cmd->argv[0]);
>>
>> And then you can think about how you support the ENOENT case better.
>> My proposal for this was to do the PATH lookup manually before the
>> fork(), and then the above conditional would melt down to simply:
>>
>> die_errno("Cannot exec %s", cmd->argv[0]);
>>
>
> The child process can't sanely print anything. Stderr would go to
> who knows where.
Wrong - because:
> Parent process should have much better idea what to
> do with errors.
Very correct. For this reason, the parent process assigns a stderr channel
to the child (or does not do so to inherit its own stderr), and the child
is expected to use it. Errors due to execvp failures are no exception, IMO
(except ENOENT, as always).
-- Hannes
^ permalink raw reply
* Re: [updated patch v3 1/2] Report exec errors from run-command
From: Johannes Sixt @ 2009-12-31 19:03 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1262284003-1417-2-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara schrieb:
> +static inline void force_close(int fd)
> +{
> + /*
> + * The close is deemed success or failed in non-transient way if
> + * close() suceeds, returns EBADF or error other than EINTR or
> + * EAGAIN.
> + */
> + while (close(fd) < 0 && errno != EBADF)
> + if(errno != EINTR && errno != EAGAIN)
> + break;
You are constantly ignoring proposals to iterate only on EINTR and EAGAIN,
but do not make an argument why you do otherwise. Did I miss something?
> cmd->pid = fork();
> - if (!cmd->pid) {
> + if (cmd->pid > 0) {
> + int r = 0, ret;
> + force_close(report_pipe[1]);
> +read_again:
> + if (report_pipe[0] >= 0)
> + r = read(report_pipe[0], &ret, sizeof(ret));
> + if (r < 0 && (errno == EAGAIN || errno == EINTR ||
> + errno == EWOULDBLOCK))
> + goto read_again;
> + else if (r < 0)
> + warning("Can't read exec status report: %s\n",
> + strerror(errno));
> + else if (r == 0)
> + ;
> + else if (r < sizeof(ret)) {
> + warning("Received incomplete exec status report.\n");
> + errno = EBADMSG;
> + } else {
> + failed_errno = ret;
> + /*
> + * Clean up the process that did the failed execution
> + * so no zombies remain.
> + */
> + if(waitpid(cmd->pid, &ret, 0) < 0 && errno == EINTR)
> + /* Nothing. */ ;
> + cmd->pid = -1;
As per Documentation/technical/api-run-command.txt, you should write an
error here, except if (failed_errno==ENOENT && cmd->silent_exec_failure!=0).
> +test_expect_success "reporting ENOENT" \
> +"test-run-command 1"
I wonder what this parameter "1" is good for...
-- Hannes
^ permalink raw reply
* Re: [updated patch v3 2/2] Improve transport helper exec failure reporting
From: Johannes Sixt @ 2009-12-31 19:05 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1262284003-1417-3-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara schrieb:
> + helper->silent_exec_failure = 1;
> + if (start_command(helper)) {
> + if (errno == ENOENT)
> + die("Unable to find remote helper for \"%s\"",
> + data->name);
> + else
> + die_errno("Unable to run helper %s", helper->argv[0]);
When you fix your implementation of start_command() to follow
Documentation/technical/api-run-command.txt, the error message in the else
branch is not needed anymore (and then you can ask yourself whether you
really want to issue your own error message in the case of ENOENT).
-- Hannes
^ permalink raw reply
* Re: git pull -s subtree doesn't work properly
From: Oliver Kullmann @ 2009-12-31 19:38 UTC (permalink / raw)
To: git
In-Reply-To: <20091105180905.GP17628@cs-wsok.swansea.ac.uk>
Hello,
it seems no reply yet (if I understand that web-email-interface
properly); has nobody any idea here, or is it a Git bug,
or my fault?
To me it seems all pretty normal, so I would be glad to get
some reaction.
The situation didn't improve: It seems "subtree" is completely broken ---
it has no idea that the files to be pulled are to be placed in
a subtree. (The pull via "git pull -s subtree CSM41 master" actually
also manages to ignore the ignore-patterns; don't know how this
could happen.)
So shouldn't one use this option?
Or how can I restart?
I would also need in other situations the ability of Git to have one independent repository (say,
at Github), which is also included in some other bigger repository (where it is
not changed, only included) --- how to do so if the "subtree"-mechanism doesn't work?
Hope for some help.
Oliver
On Thu, Nov 05, 2009 at 06:09:05PM +0000, Oliver Kullmann wrote:
> Hello,
>
> using
>
> IntroductionJava> git remote add -f CSM41 /home/kullmann/csoliver/UofT/Java0910/ProgrammingJava/CS-M41_Programs
> IntroductionJava> git merge -s ours --no-commit CSM41/master
> IntroductionJava> git read-tree --prefix=Artikel/Skripte/IntroductionJava/CS_M41/ -u CSM41/master
> IntroductionJava> git commit -m "Einfuegen des CS-M41-Projektes als Verzeichnis CS_M41"
>
> I have imported repository "CS-M41_Programs" into another repository. Later then
> I replaced in the config-file the old url /home/kullmann/csoliver/UofT/Java0910/ProgrammingJava/CS-M41_Programs
> by the new one
>
> [remote "CSM41"]
> url = git://github.com/OKullmann/CS-M41-Programming-in-Java.git
> fetch = +refs/heads/*:refs/remotes/CSM41/*
>
> But now
>
> IntroductionJava> git pull -s subtree CSM41 master
>
> doesn't work anymore: In the CSM41 repository just one file index.html was changed,
> and apparently the merge strategy recognises that the other files haven't
> been changed, while index.html is placed just as if the relative path would
> start from the root of the repository.
>
> IntroductionJava> git pull -s subtree CSM41 master
> remote: Counting objects: 7, done.
> remote: Compressing objects: 100% (3/3), done.
> remote: Total 4 (delta 1), reused 0 (delta 0)
> Unpacking objects: 100% (4/4), done.
> >From git://github.com/OKullmann/CS-M41-Programming-in-Java
> * branch master -> FETCH_HEAD
> CONFLICT (delete/modify): Artikel/LaTeX/SystemStile/Html/index.html deleted in HEAD a
> nd modified in 38b11a96fa009a5b2c24cfc94c0268ab9ca7ce39. Version 38b11a96fa009a5b2c24
> cfc94c0268ab9ca7ce39 of Artikel/LaTeX/SystemStile/Html/index.html left in tree.
> Automatic merge failed; fix conflicts and then commit the result.
>
> IntroductionJava> git status
> # On branch master
> # Unmerged paths:
> # (use "git reset HEAD <file>..." to unstage)
> # (use "git add <file>..." to mark resolution)
> #
> # deleted by us: ../../LaTeX/SystemStile/Html/index.html
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> The path of index.html is Artikel/Skripte/IntroductionJava/CS_M41/Html/index.html.
> Why git thinks that index.html should be placed into another directory Artikel/LaTeX/SystemStile/Html/
> I have no clue (this directory doesn't exist).
>
> Is it possible to tell "git pull" where the subtree really is, or is that
> not really the cause of the problem?
>
> Thanks for your consideration!
>
> Oliver
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Junio C Hamano @ 2009-12-31 19:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <4B3CD74D.7020605@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> to help people set
>
> PAGER=C:\Program Files\cygwin\bin\less
>
> That is, we first try to run the program without the shell, then retry
> wrapped in sh -c.
>
> Wouldn't it be possible to do the same here, assuming that we don't
> have programs such as "editor -f" in the path?
It is a cute idea that covers 70-80% of the cases, as you also have to
assume that you don't have to specify your own pager on a path with IFS
(e.g. "Program files" in your example) and give your parameter to the
pager at the same time, e.g.
PAGER="C:\Program Files\cygwin\bin\less -FRSX"
Because it has its own LESS environment to set FRSX and you can get away
with:
PAGER="C:\Program Files\cygwin\bin\less"
LESS=FRSX
"less" is not a representative example for this issue. In real life I
suspect that custom programs that we don't ship with git (or you don't
ship with msysgit) would lack such a workaround, (and that is why I didn't
say "98% of the cases").
^ permalink raw reply
* [PATCH] Provide a window icon on Windows platforms
From: Kirill @ 2009-12-31 19:57 UTC (permalink / raw)
To: git; +Cc: msysgit
Looks like 37871b73 by Giuseppe Bilotta does not work very well on Windows.
Instead of a former tcl/tk icon, the window has a black square as an icon.
This patch is a copy-paste from Git Gui, which uses a separate .ico file
when it runs on Windows platforms.
---
The patch is in line with what Giuseppe Bilotta proposed in
[PATCH] gitk: try to set program icon on 2008-11-15 23:45:45 GMT
Unfortunately, I could not find any particular reason why that
patch was not applied, but without it, Gitk on Windows does
not look as nice as it could.
The changes in the Makefile were only sanity-checked, not tested in the
full-fledged build or install.
CC to msysGit list is because the changes are actually made and
tested on top of git version 1.6.4.msysgit.0.597.gcd48
gitk-git/Makefile | 3 ++
gitk-git/gitk | 50 ++++++++++++++++++++++++++++++------------------
gitk-git/gitk-gui.ico | Bin 0 -> 3638 bytes
3 files changed, 34 insertions(+), 19 deletions(-)
create mode 100644 gitk-git/gitk-gui.ico
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..dd158bf 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -5,6 +5,7 @@ prefix ?= $(HOME)
bindir ?= $(prefix)/bin
sharedir ?= $(prefix)/share
gitk_libdir ?= $(sharedir)/gitk/lib
+gitk_libdir_SQ = $(subst ','\'',$(gitk_libdir))
msgsdir ?= $(gitk_libdir)/msgs
msgsdir_SQ = $(subst ','\'',$(msgsdir))
@@ -43,10 +44,12 @@ install:: all
$(INSTALL) -m 755 gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(msgsdir_SQ)'
$(foreach p,$(ALL_MSGFILES), $(INSTALL) -m 644 $p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
+ $(INSTALL) -m 644 gitk-gui.ico '$(DESTDIR_SQ)$(gitk_libdir_SQ)'/gitk-gui.ico
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ $(RM) '$(DESTDIR_SQ)$(gitk_libdir_SQ)'/gitk-gui.ico
clean::
$(RM) gitk-wish po/*.msg
diff --git a/gitk-git/gitk b/gitk-git/gitk
index b6a0daa..661904f 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -11248,30 +11248,42 @@ set patchnum 0
set lserial 0
set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
setcoords
-makewindow
-catch {
- image create photo gitlogo -width 16 -height 16
- image create photo gitlogominus -width 4 -height 2
- gitlogominus put #C00000 -to 0 0 4 2
- gitlogo copy gitlogominus -to 1 5
- gitlogo copy gitlogominus -to 6 5
- gitlogo copy gitlogominus -to 11 5
- image delete gitlogominus
+if {$::tcl_platform(platform) eq {windows}} {
+ wm iconbitmap . -default $gitk_libdir/gitk-gui.ico
+ set ::tk::AlwaysShowSelection 1
+
+ # Spoof an X11 display for SSH
+ if {![info exists env(DISPLAY)]} {
+ set env(DISPLAY) :9999
+ }
+} else {
+ catch {
+ image create photo gitlogo -width 16 -height 16
+
+ image create photo gitlogominus -width 4 -height 2
+ gitlogominus put #C00000 -to 0 0 4 2
+ gitlogo copy gitlogominus -to 1 5
+ gitlogo copy gitlogominus -to 6 5
+ gitlogo copy gitlogominus -to 11 5
+ image delete gitlogominus
- image create photo gitlogoplus -width 4 -height 4
- gitlogoplus put #008000 -to 1 0 3 4
- gitlogoplus put #008000 -to 0 1 4 3
- gitlogo copy gitlogoplus -to 1 9
- gitlogo copy gitlogoplus -to 6 9
- gitlogo copy gitlogoplus -to 11 9
- image delete gitlogoplus
+ image create photo gitlogoplus -width 4 -height 4
+ gitlogoplus put #008000 -to 1 0 3 4
+ gitlogoplus put #008000 -to 0 1 4 3
+ gitlogo copy gitlogoplus -to 1 9
+ gitlogo copy gitlogoplus -to 6 9
+ gitlogo copy gitlogoplus -to 11 9
+ image delete gitlogoplus
- image create photo gitlogo32 -width 32 -height 32
- gitlogo32 copy gitlogo -zoom 2 2
+ image create photo gitlogo32 -width 32 -height 32
+ gitlogo32 copy gitlogo -zoom 2 2
- wm iconphoto . -default gitlogo gitlogo32
+ wm iconphoto . -default gitlogo gitlogo32
+ }
}
+
+makewindow
# wait for the window to become visible
tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
diff --git a/gitk-git/gitk-gui.ico b/gitk-git/gitk-gui.ico
new file mode 100644
index 0000000000000000000000000000000000000000..0f7a43d7b544e19581b0be7b6611b8ff9da94434
GIT binary patch
literal 3638
zcmeH~y-S=y5QoR)0>^O>ZLBQRBE&8*l~sa8I>E-;Zb_fQCdC!OIuH=Hvq(Zxr13Af
zDn%SDwTYEQKmyTDNMQ2Jyq=yPs1Vac_ipy%w;%Jovv;?9A|rB7CMSi|mXB?bN7P0~
zoA!$bBAaNBX-;C#uo1>(YBfdXBjjP3dLq1~*J}!Ls?zWGrT?uj`(HmutJRWryDi;r
zSH{N1WPE&FCMG6idU{%BW@cn@aZ%>y=VfkgPG)CkrT5BZVZr6CY>EFc`Lgv>w!VLt
zH=jP^NU?%d%$la6DVm~bXx<Dd=mou?7xaQ2(<*vJuQV!pMW+x$H*`Zc1VeY)PTMU#
zE4kudSxA|r;*##k6b6MsVNe(n2?m8hVNe(phQx$HVNe(p28AKfVNe(p28BUkP)CD9
z;n3i4&j_GU#;an6p~oY`QgB{yR9LjYl3}2;P${q!STZbd6gUbT1&#toh6;`XLxG{d
z5TPq@6c`E&hA$`25aOqK(a!KjbfCg_WmJY5-xa2c(~5%%Q^j|sv$9CVcg1&ZNBTy`
zf5m^re{503e<d~*h6+O^4zX=SC7&LJl03GN7#RKxHiN_Pms=Yg#K7RN;NZb>yP0IL
z7%T>a;V?e}uox4KL55(k@Wxn&Juz4;;*l)zX^34wgTY~N7#s$N!C}ac6AT7}!{9I&
z3@n2&9tMZOVQ?5&8bgP{VQ?560LQ<vm^0BCR9K_XE^v6R9b<}2$$ME^T9W1EWm#ES
zk=4~z+1S{S_4Rex-rkm-ogLZT-Icw)Jvlfyki)}6+5hG8Zf%Y4agXT6cOVMZ%T}x#
zO_xq2wA-6H9e%qOGY;o!5tXa@V|Juw-051(&(43?e-+=={mrvqlsC_RQBR}YME~=n
z)ajhB#ro&flaV*kA8Xv+#Bac*Y5(`rhhhCE-TT8f(9cdD9uxJm{b$>8Pl>C`BzAmH
zIlh;qcy~`ZIvwL=;yA*%OK>LL-BY+X5R1Ee3TOF$eox_-;4c$@P~tE?$*9NK++;)5
v6i*MmhU++{@~mpIp=$PAV}(nHH21Z<!sXp<^QFk^sm7u{=pSf<_MrR&teD_?
literal 0
HcmV?d00001
--
1.6.4.msysgit.0.597.gcd48
^ permalink raw reply related
* Re: [PATCH] Provide a window icon on Windows platforms
From: Jeff Epler @ 2009-12-31 20:02 UTC (permalink / raw)
To: Kirill; +Cc: git, msysgit
In-Reply-To: <1262289470-4208-1-git-send-email-kirillathome@gmail.com>
On Thu, Dec 31, 2009 at 02:57:50PM -0500, Kirill wrote:
> + set ::tk::AlwaysShowSelection 1
> +
> + # Spoof an X11 display for SSH
> + if {![info exists env(DISPLAY)]} {
> + set env(DISPLAY) :9999
> + }
these bits look unrelated and should probably be in a separate
submission.
^ permalink raw reply
* Re: [PATCH] Provide a window icon on Windows platforms
From: Kirill @ 2009-12-31 20:13 UTC (permalink / raw)
To: Jeff Epler; +Cc: git, msysgit
In-Reply-To: <20091231200240.GC13700@unpythonic.net>
On Thu, Dec 31, 2009 at 3:02 PM, Jeff Epler wrote:
> On Thu, Dec 31, 2009 at 02:57:50PM -0500, Kirill wrote:
>> + set ::tk::AlwaysShowSelection 1
>> +
>> + # Spoof an X11 display for SSH
>> + if {![info exists env(DISPLAY)]} {
>> + set env(DISPLAY) :9999
>> + }
>
> these bits look unrelated and should probably be in a separate
> submission.
The only reason this code is here: Git Gui has it in the same section.
Given my total lack of Tcl/Tk skills and deep understanding, I hoped
to fix some other Windows-specific annoyances "by accident".
If Tcl/Tk gurus, for example, Paul Mackerras, say they're wrong, I'll
gladly remove them. If the only objection is the inclusion into the
same patch, I can do that too.
Thanks for your time!
--
Kirill.
^ permalink raw reply
* Re: [PATCH v2] cvsserver: make the output of 'update' more compatible with cvs.
From: Junio C Hamano @ 2009-12-31 20:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Nanako Shiraishi, Sergei Organov, git
In-Reply-To: <46a038f90912310720l4b1cbdebs2b85774ae7e33c0e@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> On Thu, Dec 31, 2009 at 7:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Well, since I don't use cvsserver myself, but this v2 was done with
>> improvements based on some review suggestions, I was waiting for a
>> response or two from people who know better and care more about cvs server
>> emulation than me, which unfortunately didn't happen.
>
> Looks good to me -- good to get it into pu. While I continue to use
> git extensively, I don't use cvsserver anymore, nor work with people
> that do. Might have reason to revisit cvsserver in the near future
> though, to help Moodle transition to git.
>
> That transition will bring a few top-posters and Eclipse lovers to the
> list. Looking past such details, they are fine people who may need a
> little bit of git-newbie help ;-)
>
> happy new year,
Happy new year to you, Nana and Sergei, but not yet in my timezone ;-)
Thanks; I'll forge/add your "Acked-by:" when I queue it.
^ permalink raw reply
* Re: git pull -s subtree doesn't work properly
From: Oliver Kullmann @ 2009-12-31 20:37 UTC (permalink / raw)
To: git
In-Reply-To: <20091231193800.GB19537@cs-wsok.swansea.ac.uk>
Just adding a bit more information about the apparently
wrong behaviour of "-s subtree":
The question is what is the "subtree"??? Apparently git just
looks for the first matching file it finds (!) --- now there is in repository B
a file index.html, and there is index.html in A (while B is to be
merged into A), and thus git apparently deduces that must be
the "subtree". If this is not a bug ...
Does the repository name belong to what specifies a "subtree"?
As one can see below, the repository name has been changed.
For example when creating a repository a Github, then the name
of the repository is not really under control, and also how
Git treats repositories, it seems that the name of the repository
doesn't matter.
In this case we have in A the directory "CS_M41", while in B it was
"CS_M41_Programs"; then later in Github the name of B was further
changed to "CS-M41-Programming-in-Java". Is this an issue (should it be)?
Oliver
P.S. Would renaming CS_M41 in A to CS-M41-Programming-in-Java changed something?
Or would it make things worse?
I tried it, and it doesn't make any change.
On Thu, Dec 31, 2009 at 07:38:00PM +0000, Oliver Kullmann wrote:
> Hello,
>
> it seems no reply yet (if I understand that web-email-interface
> properly); has nobody any idea here, or is it a Git bug,
> or my fault?
>
> To me it seems all pretty normal, so I would be glad to get
> some reaction.
>
> The situation didn't improve: It seems "subtree" is completely broken ---
> it has no idea that the files to be pulled are to be placed in
> a subtree. (The pull via "git pull -s subtree CSM41 master" actually
> also manages to ignore the ignore-patterns; don't know how this
> could happen.)
>
> So shouldn't one use this option?
> Or how can I restart?
>
> I would also need in other situations the ability of Git to have one independent repository (say,
> at Github), which is also included in some other bigger repository (where it is
> not changed, only included) --- how to do so if the "subtree"-mechanism doesn't work?
>
> Hope for some help.
>
> Oliver
>
>
>
> On Thu, Nov 05, 2009 at 06:09:05PM +0000, Oliver Kullmann wrote:
> > Hello,
> >
> > using
> >
> > IntroductionJava> git remote add -f CSM41 /home/kullmann/csoliver/UofT/Java0910/ProgrammingJava/CS-M41_Programs
> > IntroductionJava> git merge -s ours --no-commit CSM41/master
> > IntroductionJava> git read-tree --prefix=Artikel/Skripte/IntroductionJava/CS_M41/ -u CSM41/master
> > IntroductionJava> git commit -m "Einfuegen des CS-M41-Projektes als Verzeichnis CS_M41"
> >
> > I have imported repository "CS-M41_Programs" into another repository. Later then
> > I replaced in the config-file the old url /home/kullmann/csoliver/UofT/Java0910/ProgrammingJava/CS-M41_Programs
> > by the new one
> >
> > [remote "CSM41"]
> > url = git://github.com/OKullmann/CS-M41-Programming-in-Java.git
> > fetch = +refs/heads/*:refs/remotes/CSM41/*
> >
> > But now
> >
> > IntroductionJava> git pull -s subtree CSM41 master
> >
> > doesn't work anymore: In the CSM41 repository just one file index.html was changed,
> > and apparently the merge strategy recognises that the other files haven't
> > been changed, while index.html is placed just as if the relative path would
> > start from the root of the repository.
> >
> > IntroductionJava> git pull -s subtree CSM41 master
> > remote: Counting objects: 7, done.
> > remote: Compressing objects: 100% (3/3), done.
> > remote: Total 4 (delta 1), reused 0 (delta 0)
> > Unpacking objects: 100% (4/4), done.
> > >From git://github.com/OKullmann/CS-M41-Programming-in-Java
> > * branch master -> FETCH_HEAD
> > CONFLICT (delete/modify): Artikel/LaTeX/SystemStile/Html/index.html deleted in HEAD a
> > nd modified in 38b11a96fa009a5b2c24cfc94c0268ab9ca7ce39. Version 38b11a96fa009a5b2c24
> > cfc94c0268ab9ca7ce39 of Artikel/LaTeX/SystemStile/Html/index.html left in tree.
> > Automatic merge failed; fix conflicts and then commit the result.
> >
> > IntroductionJava> git status
> > # On branch master
> > # Unmerged paths:
> > # (use "git reset HEAD <file>..." to unstage)
> > # (use "git add <file>..." to mark resolution)
> > #
> > # deleted by us: ../../LaTeX/SystemStile/Html/index.html
> > #
> > no changes added to commit (use "git add" and/or "git commit -a")
> >
> > The path of index.html is Artikel/Skripte/IntroductionJava/CS_M41/Html/index.html.
> > Why git thinks that index.html should be placed into another directory Artikel/LaTeX/SystemStile/Html/
> > I have no clue (this directory doesn't exist).
> >
> > Is it possible to tell "git pull" where the subtree really is, or is that
> > not really the cause of the problem?
> >
> > Thanks for your consideration!
> >
> > Oliver
> >
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Junio C Hamano @ 2009-12-31 20:37 UTC (permalink / raw)
To: David Aguilar
Cc: Nanako Shiraishi, peff, sam, git, paulus, Markus Heidelberg,
Jay Soffian
In-Reply-To: <20091231071642.GA10067@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> I started the first step:
>
> http://thread.gmane.org/gmane.comp.version-control.git/135613
> http://thread.gmane.org/gmane.comp.version-control.git/135613/focus=135612
Thanks.
> The 2nd patch implements the the --gui option which Markus
> pointed out would be needed to avoid issues such as calling
> "vimdiff" from a console-less gitk:
>
> http://article.gmane.org/gmane.comp.version-control.git/133386
>
> I marked the --gui patch as "RFC" since it introduced a new
> config variable and I want to make sure that we agreed on its
> name. I didn't get any feedback about that patch
> (my fault-- we were in RC freeze and I forgot to CC: Markus).
I don't think "diff.guitool" would hurt. However,...
I think the "--gui" patch is a more or less independent issue to "gitk
runs external diff through difftool", because difftool/mergetool already
have a built-in way to auto-guess which backend to use depending on what
its environment looks like (e.g. do we have $DISPLAY etc.).
The "--gui" patch is about giving a more explicit way for the caller to
control that backend picking decision process and it is more like icing
than a prerequisite for the issue. IOW, I think the end result will be
usable by gitk users even if they do not configure "diff.guitool".
^ permalink raw reply
* Re: [msysGit] [PATCH] Provide a window icon on Windows platforms
From: Pat Thoyts @ 2009-12-31 21:12 UTC (permalink / raw)
To: Kirill; +Cc: git, msysgit
In-Reply-To: <1262289470-4208-1-git-send-email-kirillathome@gmail.com>
2009/12/31 Kirill <kirillathome@gmail.com>:
> Looks like 37871b73 by Giuseppe Bilotta does not work very well on Windows.
> Instead of a former tcl/tk icon, the window has a black square as an icon.
I've been using versions of gitk on Windows with that patch since it
was applied in March and it has been fine. On Windows XP and Windows
7. So there is more to this than you are telling. Are you using
windows via remote desktop? There was a patch committed to Tk a while
ago about the program icon displaying as a black square over remote
desktop. If so, this requires an updated Tk and not a patch to gitk -
tk 8.5.8 should be ok if this is the problem.
^ permalink raw reply
* suppress fatal pathspec errors from "git add"?
From: aaron smith @ 2009-12-31 21:24 UTC (permalink / raw)
To: git
I'm looking through the add documentation, I don't see a way to
suppress fatal pathspec errors? For example, if I'm adding 5 files,
but one of them is mis-spelled, can I have git just supress the errors
and add the other four?
thanks much!
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Jeff King @ 2009-12-31 21:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <4B3CD74D.7020605@kdbg.org>
On Thu, Dec 31, 2009 at 05:54:37PM +0100, Johannes Sixt wrote:
> The git version that msysgit ships (and the one that I use on
> Windows) has this sequence in pager.c:
>
> static const char *pager_argv[] = { "sh", "-c", NULL, NULL };
> ...
> pager_process.argv = &pager_argv[2];
> pager_process.in = -1;
> if (start_command(&pager_process)) {
> pager_process.argv = pager_argv;
> pager_process.in = -1;
> if (start_command(&pager_process))
> return;
> }
As a side note to what you are saying, my patch 2/6 will break this. The
"new" way to do it would be:
/* do not set pager_argv[2] specially */
pager_process.in = -1;
if (start_command(&pager_process)) {
pager_process.use_shell = 1;
pager_process.in = -1;
if (start_command(&pager_process))
return;
}
though I am happy to also just revert the pager.c changes and leave it
to handle the shell itself.
But of course if we use your trick internally in run-command, then your
pager-specific change can just go away.
> to help people set
>
> PAGER=C:\Program Files\cygwin\bin\less
>
> That is, we first try to run the program without the shell, then
> retry wrapped in sh -c.
>
> Wouldn't it be possible to do the same here, assuming that we don't
> have programs such as "editor -f" in the path?
Hmm. That is somewhat clever. And it would actually solve the
backward-compatibility problem for helpers moving to shell execution. If
you have a textconv of "/path with space/foo", it will continue to
work transparently, but now "/path_without_space/foo --option" will also
Just Work.
The two downsides I see are:
1. You want to run "foo" with "-bar" in your path but you have "foo
-bar" in your path (your "editor -f" example). This just seems
insane to me.
2. There is a little bit of an interface inconsistency. You can do
PAGER="/path with space/foo", but once you want to add an option,
PAGER="/path with space/foo -bar" does not do what you mean. You
have to understand the magic that is going on, and that you now
need to quote the first part.
I'm not sure that is not a feature, though. You are paying that
cost in the transition, but getting the DWYM magic for the common
case.
> It does assume that we are able to detect execvp failure due to
> ENOENT which is currently proposed elsewhere by Ilari Liusvaara (and
> which is already possible on Windows).
We could also simply do the path lookup ourselves, decide whether to use
the shell, and then exec. Path lookup is not that hard, and I think we
already have mingw compat routines for it anyway.
-Peff
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Johannes Sixt @ 2009-12-31 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <7v4on7x6w1.fsf@alter.siamese.dyndns.org>
On Donnerstag, 31. Dezember 2009, Junio C Hamano wrote:
> It is a cute idea that covers 70-80% of the cases, as you also have to
> assume that you don't have to specify your own pager on a path with IFS
> (e.g. "Program files" in your example) and give your parameter to the
> pager at the same time, e.g.
>
> PAGER="C:\Program Files\cygwin\bin\less -FRSX"
>
> Because it has its own LESS environment to set FRSX and you can get away
> with:
>
> PAGER="C:\Program Files\cygwin\bin\less"
> LESS=FRSX
>
> "less" is not a representative example for this issue. In real life I
> suspect that custom programs that we don't ship with git (or you don't
> ship with msysgit) would lack such a workaround, (and that is why I didn't
> say "98% of the cases").
OTOH, once you see that you would have to set
PAGER: C:\Program Files\cygwin\bin\less -FRSX
(I'm not using shell syntax here; think of a dialog that has name and value in
separate edit boxes) then it is rather obvious that this cannot work. If you
are clever (and you probably are - after all, you are modifying something
esoteric: the environment!), then you will have heard about the magic
double-quotes, and you will write this as
PAGER: "C:\Program Files\cygwin\bin\less" -FRSX
instead, and it will work as intended.
Granted, "less" is not representative.
GIT_EDITOR: "C:\Program Files\Notepad++\notepad++" -multiInst
is probably more realistic (but I didn't test it).
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Johannes Sixt @ 2009-12-31 22:16 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20091231214134.GA31399@coredump.intra.peff.net>
On Donnerstag, 31. Dezember 2009, Jeff King wrote:
> But of course if we use your trick internally in run-command, then your
> pager-specific change can just go away.
This is what I had in mind.
> > It does assume that we are able to detect execvp failure due to
> > ENOENT which is currently proposed elsewhere by Ilari Liusvaara (and
> > which is already possible on Windows).
>
> We could also simply do the path lookup ourselves, decide whether to use
> the shell, and then exec.
I tried to convince Ilari that this is the way to go, but...
-- Hannes
^ permalink raw reply
* RE: [PATCH] Provide a window icon on Windows platforms
From: Kirill @ 2009-12-31 22:42 UTC (permalink / raw)
To: 'Pat Thoyts'; +Cc: git, msysgit
In-Reply-To: <a5b261830912311312if3d71aax5bb693a907dc5c0f@mail.gmail.com>
Unfortunately, I have to insist on my patch :)
> -----Original Message-----
> From: Pat Thoyts [mailto:patthoyts@googlemail.com]
> Sent: Thursday, December 31, 2009 4:12 PM
> 2009/12/31 Kirill <kirillathome@gmail.com>:
> > Looks like 37871b73 by Giuseppe Bilotta does not work very well on
> > Windows. Instead of a former tcl/tk icon, the window has a black
> > square as an icon.
>
> I've been using versions of gitk on Windows with that patch since it
> was applied in March and it has been fine. On Windows XP and Windows
> 7. So there is more to this than you are telling. Are you using
> windows via remote desktop?
You're absolutely right about *unintentional* withdrawal of facts in my original message, but no, I'm not using Remote Desktop. However, my XP SP3 has 16-bit colors and apparently 8.5.7 can't display those photos correctly in this case either. Most probable reason why the issue was first discovered in Remote Desktop is because most of RDP sessions are limited to 16-bit colors.
> If so, this requires an updated Tk and not a patch to gitk -
> tk 8.5.8 should be ok if this is the problem.
Unfortunately, the situation is improved with 8.5.8, but definitely not resolved (tested on msysGit devel branch). The sequence image create photo && wm iconphoto on 16-bit displays in XP SP3 renders the background black, not transparent. The fact that I'm using Classic color schema may play some role too. I'd speculate that 8.5.8 on Windows 7 (admittedly, it's much harder to switch to 16-bit colors there) may have exactly the same issue, given that 8.5.7 has exactly the same symptoms.
Is there a way to replace the "simplistic"
if {$::tcl_platform(platform) eq {windows}}
with something more elaborate that takes into account 16-bit colors?
--
Kirill.
^ permalink raw reply
* Re: [PATCH] fast-import: Document author/committer/tagger name is optional
From: Junio C Hamano @ 2009-12-31 23:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Reiss, git@vger.kernel.org
In-Reply-To: <20091230150348.GF6914@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Reiss <dreiss@facebook.com> wrote:
> > >> author <somename> 1261454209 +0000
> > >> committer <somename> 1261454209 +0000
> > > a foreign system where the data might not reasonably exist.
> > But shouldn't there still be an extra space? One to separate "author"
> > from the empty name, and one to separate the empty name from the email?
> > If not, then I think this change should be made. (I couldn't find any
> > authoritative documentation on what constitutes a valid commit object.)
>
> Yes, we should do this.
Thanks.
^ permalink raw reply
* Re: [PATCH] branch: die explicitly why when calling "git branch [-a|-r] branchname".
From: Junio C Hamano @ 2009-12-31 23:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1262184331-9102-1-git-send-email-Matthieu.Moy@imag.fr>
Thanks; will apply to 'maint', together with the SubmittingPatches
addition.
Interestingly, this revealed a long-standing breakage in t5403.
^ permalink raw reply
* Re: [PATCH] Provide a window icon on Windows platforms
From: Pat Thoyts @ 2009-12-31 23:47 UTC (permalink / raw)
To: Kirill; +Cc: git, msysgit
In-Reply-To: <000701ca8a6a$7c002070$74006150$@com>
2009/12/31 Kirill <kirillathome@gmail.com>:
> Unfortunately, I have to insist on my patch :)
>
>> -----Original Message-----
>> From: Pat Thoyts [mailto:patthoyts@googlemail.com]
>> Sent: Thursday, December 31, 2009 4:12 PM
>
>> 2009/12/31 Kirill <kirillathome@gmail.com>:
>> > Looks like 37871b73 by Giuseppe Bilotta does not work very well on
>> > Windows. Instead of a former tcl/tk icon, the window has a black
>> > square as an icon.
>>
>> I've been using versions of gitk on Windows with that patch since it
>> was applied in March and it has been fine. On Windows XP and Windows
>> 7. So there is more to this than you are telling. Are you using
>> windows via remote desktop?
> You're absolutely right about *unintentional* withdrawal of facts in my original message, but no, I'm not using Remote Desktop. However, my XP SP3 has 16-bit colors and apparently 8.5.7 can't display those photos correctly in this case either. Most probable reason why the issue was first discovered in Remote Desktop is because most of RDP sessions are limited to 16-bit colors.
>
>> If so, this requires an updated Tk and not a patch to gitk -
>> tk 8.5.8 should be ok if this is the problem.
> Unfortunately, the situation is improved with 8.5.8, but definitely not resolved (tested on msysGit devel branch). The sequence image create photo && wm iconphoto on 16-bit displays in XP SP3 renders the background black, not transparent. The fact that I'm using Classic color schema may play some role too. I'd speculate that 8.5.8 on Windows 7 (admittedly, it's much harder to switch to 16-bit colors there) may have exactly the same issue, given that 8.5.7 has exactly the same symptoms.
No - it will be the use of 16bit color. Classic gets used a lot, 16
bit colour - well, you might be the only one now so such a system has
limited testing.
>
> Is there a way to replace the "simplistic"
>
> if {$::tcl_platform(platform) eq {windows}}
>
> with something more elaborate that takes into account 16-bit colors?
That is better done using 'if {[tk windowingsystem] eq "win32"}
{...}'. The windowingsystem command is preferred over platform because
they are not always equivalent (for instance, MacOSX may use either
x11 or aqua).
To test the colour-depth there is [winfo depth .] which returns 16
when using the 16bit color on XP and 32 on Win7 with full color.
Pat Thoyts
^ permalink raw reply
* Re: [PATCH] t9700-perl-git.sh: Fix a test failure on Cygwin
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Ramsay Jones, GIT Mailing-list
In-Reply-To: <7vbphfzlgt.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, could you tell us what happened to this thread?
>
> Hmph, I think we have it as 81f4026 (t9700-perl-git.sh: Fix a test failure
> on Cygwin, 2009-11-19).
Oh, my mistake. I'm very sorry for wasting your time.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git pull -s subtree doesn't work properly
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20091231193800.GB19537@cs-wsok.swansea.ac.uk>
Quoting Oliver Kullmann <O.Kullmann@swansea.ac.uk>
> it seems no reply yet (if I understand that web-email-interface
> properly); has nobody any idea here, or is it a Git bug,
> or my fault?
Because you don't specify where in your current directory hierarchy the root level of the tree you are merging goes when you run "git merge -s subtree", the merge mechanism has to find the most similar directory by itself, and if you have more than one similar directories, it can't guess correctly.
It sounds similar to
http://thread.gmane.org/gmane.comp.version-control.git/135009/focus=135033
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Client-side mirroring patches (v0)
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, git
In-Reply-To: <1259143617-26580-1-git-send-email-sam@vilain.net>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Lazily generate header dependencies
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Johannes Sixt, Git Mailing List,
Johannes Schindelin
In-Reply-To: <20091127174558.GA3461@progeny.tock>
Junio, could you tell us what happened to this thread?
Makefile improvements. No discussion.
^ 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