* [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Ping Yin @ 2007-11-19 20:12 UTC (permalink / raw)
To: git; +Cc: Ping Yin
When the file descriptor of 'FILE *fp' is assigned to child_process.out
and then start_command or run_command is run, the standard output of the
child process is expected to be outputed to fp.
start_command will always close fp in this case. However, sometimes fp is
not expected to be closed since further IO may be still performmed on fp.
This patch disables the auto closing behavious of start_command
and corrects all codes which depend on this kind of behaviour.
Following is a case that the auto closing behaviour is not expected.
When adding submodule summary feature to builtin-commit, in wt_status_print,
I want to output the submodule summary between changed and untracked files
as the following patch shows
wt_status_print_changed(s);
+ wt_status_print_submodule_summary(s);
wt_status_print_untracked(s);
All the three calls will output to s->fp (which points to a file instead of
standard output when doing committing). So I don't want s->fp to be closed after
wt_status_print_submodule_summary(s) which calls run_command.
+static void wt_status_print_submodule_summary(struct wt_status *s)
+{
+ struct child_process sm_summary;
+ memset(&sm_summary, 0, sizeof(sm_summary));
+ ...
+ sm_summary.out = fileno(s->fp);
+ ...
+ run_command(&sm_summary);
+}
Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
bundle.c | 1 +
convert.c | 1 +
run-command.c | 4 ----
upload-pack.c | 3 ++-
4 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/bundle.c b/bundle.c
index e4d60cd..fc253fb 100644
--- a/bundle.c
+++ b/bundle.c
@@ -336,6 +336,7 @@ int unbundle(struct bundle_header *header, int bundle_fd)
memset(&ip, 0, sizeof(ip));
ip.argv = argv_index_pack;
ip.in = bundle_fd;
+ ip.close_in = 1;
ip.no_stdout = 1;
ip.git_cmd = 1;
if (run_command(&ip))
diff --git a/convert.c b/convert.c
index 4df7559..ce7bed0 100644
--- a/convert.c
+++ b/convert.c
@@ -212,6 +212,7 @@ static int filter_buffer(int fd, void *data)
child_process.argv = argv;
child_process.in = -1;
child_process.out = fd;
+ child_process.close_out = 1;
if (start_command(&child_process))
return error("cannot fork to run external filter %s", params->cmd);
diff --git a/run-command.c b/run-command.c
index 476d00c..4e5f58d 100644
--- a/run-command.c
+++ b/run-command.c
@@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
if (need_in)
close(fdin[0]);
- else if (cmd->in)
- close(cmd->in);
if (need_out)
close(fdout[1]);
- else if (cmd->out > 1)
- close(cmd->out);
if (need_err)
close(fderr[1]);
diff --git a/upload-pack.c b/upload-pack.c
index 7e04311..7aeda80 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -163,7 +163,8 @@ static void create_pack_file(void)
argv[arg++] = NULL;
memset(&pack_objects, 0, sizeof(pack_objects));
- pack_objects.in = rev_list.out; /* start_command closes it */
+ pack_objects.in = rev_list.out;
+ pack_objects.close_in = 1; /* finish_command closes rev_list.out */
pack_objects.out = -1;
pack_objects.err = -1;
pack_objects.git_cmd = 1;
--
1.5.3.5.1878.gb1da0-dirty
^ permalink raw reply related
* [PATCH] Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.
From: Matthieu Moy @ 2007-11-19 20:28 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Matthieu Moy
In-Reply-To: <7vtznim1s5.fsf@gitster.siamese.dyndns.org>
The HEAD@{...} syntax was documented in git-rev-parse manpage, which
is hard to find by someone looking for the documentation of porcelain.
git-reflog is probably the place where one expects to find this.
While I'm there, "git revlog show whatever" was also undocumented.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-reflog.txt | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 5c7316c..aeac6f0 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -19,7 +19,7 @@ depending on the subcommand:
git reflog expire [--dry-run] [--stale-fix] [--verbose]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
-git reflog [show] [log-options]
+git reflog [show] [log-options] [<ref>]
Reflog is a mechanism to record when the tip of branches are
updated. This command is to manage the information recorded in it.
@@ -32,10 +32,17 @@ directly by the end users -- instead, see gitlink:git-gc[1].
The subcommand "show" (which is also the default, in the absence of any
subcommands) will take all the normal log options, and show the log of
-`HEAD`, which will cover all recent actions, including branch switches.
+`HEAD`, or of the reference provided in the command-line, which will
+cover all recent actions, including branch switches.
It is basically an alias for 'git log -g --abbrev-commit
--pretty=oneline', see gitlink:git-log[1].
+The reflog is useful in various git commands, to specify the old value
+of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be
+two moves ago", `master@\{one.week.ago\}` means "where master used to
+point to one week ago", and so on. See gitlink:git-rev-parse[1] for
+more details.
+
OPTIONS
-------
--
1.5.3.5.724.g49d9d
^ permalink raw reply related
* Re: [PATCH] Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.
From: Matthieu Moy @ 2007-11-19 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1195504133-7823-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> -`HEAD`, which will cover all recent actions, including branch switches.
> +`HEAD`, or of the reference provided in the command-line, which will
> +cover all recent actions, including branch switches.
Ooops, appologize. I didn't commit my change, this patch isn't any
better than the previous.
The one below should be correct (the sentence was getting long, I've
splitted it):
>From d71c6c8e24a5a08600f3347b4ad014e459f9f3df Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Mon, 19 Nov 2007 19:25:11 +0100
Subject: [PATCH] Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.
The HEAD@{...} syntax was documented in git-rev-parse manpage, which
is hard to find by someone looking for the documentation of porcelain.
git-reflog is probably the place where one expects to find this.
While I'm there, "git revlog show whatever" was also undocumented.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-reflog.txt | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 5c7316c..1bd54c5 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -19,7 +19,7 @@ depending on the subcommand:
git reflog expire [--dry-run] [--stale-fix] [--verbose]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
-git reflog [show] [log-options]
+git reflog [show] [log-options] [<ref>]
Reflog is a mechanism to record when the tip of branches are
updated. This command is to manage the information recorded in it.
@@ -32,10 +32,17 @@ directly by the end users -- instead, see gitlink:git-gc[1].
The subcommand "show" (which is also the default, in the absence of any
subcommands) will take all the normal log options, and show the log of
-`HEAD`, which will cover all recent actions, including branch switches.
+the reference provided in the command-line (or `HEAD`, by default).
+The log will cover all recent actions, including branch switches.
It is basically an alias for 'git log -g --abbrev-commit
--pretty=oneline', see gitlink:git-log[1].
+The reflog is useful in various git commands, to specify the old value
+of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be
+two moves ago", `master@\{one.week.ago\}` means "where master used to
+point to one week ago", and so on. See gitlink:git-rev-parse[1] for
+more details.
+
OPTIONS
-------
--
1.5.3.5.724.g49d9d
^ permalink raw reply related
* Re: [RFH] Flush progress message buffer in display().
From: Junio C Hamano @ 2007-11-19 20:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Nicolas Pitre
In-Reply-To: <200711192048.58864.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> I need this patch on Windows because appearently progress output is buffered
> by stdio. Why doesn't Linux/glibc's stdio buffer output that goes to a pipe?
> ...
> ... What is flushing the progress
> output?
The standard error stream is not "fully buffered":
http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_05.html#tag_02_05
Not "fully buffered" means either "unbuffered" or "line
buffered". Because the progress display does not terminate its
line, it means that the additional fflush(stderr) you added are
needed if the stream is line buffered (still conforming).
^ permalink raw reply
* Re: [RFH] Flush progress message buffer in display().
From: Nicolas Pitre @ 2007-11-19 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7voddqm0l7.fsf@gitster.siamese.dyndns.org>
On Mon, 19 Nov 2007, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
> > I need this patch on Windows because appearently progress output is buffered
> > by stdio. Why doesn't Linux/glibc's stdio buffer output that goes to a pipe?
> > ...
> > ... What is flushing the progress
> > output?
>
> The standard error stream is not "fully buffered":
>
> http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_05.html#tag_02_05
>
> Not "fully buffered" means either "unbuffered" or "line
> buffered". Because the progress display does not terminate its
> line, it means that the additional fflush(stderr) you added are
> needed if the stream is line buffered (still conforming).
Maybe stdio on Linux considers \r as a line termination.
Flushing stderr should not hurt anyway.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Jakub Narebski @ 2007-11-19 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steffen Prohaska
In-Reply-To: <7vy7cum2k1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Brief recap, to check if I understand things correctly:
>>
>> 1. If you use "matching" more often, then it should be enough
>> to provide remote.<remotename>.push with refspec or wildcard
>> refspec.
>
> Eh, excuse me, what refspec would you write there? "matching"
> is defined to push the intersection of what we have and what
> they have when "git-push" is run. I do not think there is any
> way to write that in remote.$there.push and cast in stone.
[...]
>> Question: what to do if there is no remote.<remotename>.push?
>> Assume 1-1 matching?
>
> One-to-one is what 'matching' does, and the way to trigger it is
> not to have a remote.$there.push.
I'm sorry, I had to have "stupid" moment. Thanks a lot for complete
explanation of git-push, anyway.
>> ... If one wants to push only current branch, one
>> would use "git push --current" or "git push <remotename> HEAD".
>
> I think that is the proposal by Steffen (added back CC).
>
> I am wondering if an alternative approach could be simpler. If
> we teach "git-push" to notice when only the refspecs are given
> without remotename, and default to branch.$current.remote in
> such a case,
Including default remote when branch.<branchname>.remote is not set?
> IOW, make these:
>
> $ git push HEAD
> $ git push next
>
> push the obvious thing to the default remote, I _think_ we can
> achieve the same effect as --current and a bit more.
The only problem would be when there is conflict between remote name and
branch name (for example default "origin" remote, and old git
no-separate-remotes "origin" branch, or origin = origin/HEAD).
Perhaps we can reuse '--' as separator between remote(s) and refspecs
(branch names); other command use it to separate refname / commit-ish
from pathspec (file name).
So for scripts it would be "git push -- HEAD"; still shorter than
"git push --current".
BTW. what would happen for "git push branch1 branch2" if branch1 has
different remote than branch2?
> The latter could be run after I made the 'next' integration
> branch into a good shape, switched to 'pu' to merge up other
> bits but before finishing that merging yet (it would not help me
> personally as I do not work that way --- I push things out only
> after I am done with all the public branches --- but it may help
> the others).
--
Jakub Narebski
Poland
^ permalink raw reply
* git-daemon
From: Medve Emilian @ 2007-11-19 21:13 UTC (permalink / raw)
To: git
Hello,
It seems that something changed since maint/v.1.5.3.6 such that on
master and next git-daemon doesn't seem to be working anymore in inetd
mode. Can somebody please confirm this?
Thanks,
Emil.
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Benoit Sigoure @ 2007-11-19 21:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Lars Hjemli, Jonas Juselius, git
In-Reply-To: <vpqtznirtlk.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
On Nov 19, 2007, at 7:13 PM, Matthieu Moy wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>> Did you only read the man? It doesn't explain how to use the reflog
>> or I must have a very hard time understanding it. I don't know where
>> the HEAD@{N} syntax is documented, but surely not in man git-reflog.
>
> http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
>
> I'll post a patch adding a link to that in the reflog man page.
No please stop adding links from on man page to another. If you read
man git-reflog, you surely want to learn the HEAD@{N} syntax and see
practical uses cases. One of the complaints against Git (which also
came up in the Git Users' Survey) is that man pages are harder to use
because they often refer to each other and they tend to list their
numerous arguments out of order. Many arguments are clearly plumbing
and should be mentioned in a different section (I guess it would be
better to list the most useful arguments in alphabetical order first
and then list the remaining arguments in another section, still in
alphabetical order).
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Matthieu Moy @ 2007-11-19 21:33 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Lars Hjemli, Jonas Juselius, git
In-Reply-To: <60891A14-1D6E-4114-ACEF-4C981D326CFA@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> No please stop adding links from on man page to another. If you read
> man git-reflog, you surely want to learn the HEAD@{N} syntax and see
> practical uses cases.
I don't understand your point.
Yes, if I read man git-reflog, I do surely want to learn HEAD@{N}
syntax, but that is _precisely_ what my patch does.
--
Matthieu
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Benoit Sigoure @ 2007-11-19 21:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Lars Hjemli, Jonas Juselius, git
In-Reply-To: <vpq63zxq5s2.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
On Nov 19, 2007, at 10:33 PM, Matthieu Moy wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>> No please stop adding links from on man page to another. If you read
>> man git-reflog, you surely want to learn the HEAD@{N} syntax and see
>> practical uses cases.
>
> I don't understand your point.
>
> Yes, if I read man git-reflog, I do surely want to learn HEAD@{N}
> syntax, but that is _precisely_ what my patch does.
By telling you to read another man page which is annoying and a
recurring complaint.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Daniel Barkalow @ 2007-11-19 22:01 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Jonas Juselius, Git Mailing List
In-Reply-To: <3057F6F3-BEAA-447A-AB79-A0AFB7DB8826@lrde.epita.fr>
On Mon, 19 Nov 2007, Benoit Sigoure wrote:
> On Nov 19, 2007, at 5:14 PM, Jonas Juselius wrote:
> >On Mon, 2007-11-19 at 17:05 +0100, Jakub Narebski wrote:
> > >Do I understand correctly that you don't support cloning via git://
> > >protocol?
> >
> >Yes, that is correct. The machine is behind a number of firewalls, and I
> >simply cannot be bothered to go through the bureaucracy...
>
> You can create a repository on repo.or.cz then :)
>
> As it is often the case different people happen to work on similar things
> without knowing each other. I started http://repo.or.cz/w/tutorial.git which
> is meant to be a big Beamer presentation that presents Git thoroughly. I
> wrote some ideas but didn't start to write the slides. Just in case you want
> to have a look.
>
> One of the things you said in your guide is that Git is easy to learn. I
> think this is wrong. Git is way more complicated than most other SCMs,
> especially compared to SVN.
I convinced my little company to switch to git (from arch, so take this
with a grain of salt). I'd previously written a document explaining how to
use arch, and I wrote a version for git, which said practically nothing,
because everything I'd been able to do in arch is trivial to do in git.
But I used the same format, anyway, to be sure to cover everything. I also
told them to ask me if they were trying to do something and couldn't. I
believe that all of the questions I've gotten were on how to use "advanced
features" (i.e., things not included in my document because I never
figured out how to do them with arch and decided to just live without),
and people are using git successfully.
The main difference I see is that "save" and "publish" are separate
operations with git and the same with other SCMs, but the separate
concepts are obvious to anybody who's emailled a word processor document
to somebody, and the distinction just has to be mentioned.
The challenge in writing a good introduction to git is leaving out
explanations of all of the wonderful things that git can do that people
don't expect to be within the abilities of an SCM. If you limit yourself
to saying how to do things that SCMs can traditionally do, and therefore
only explain how to do what people know they want to do, it's not to hard
for people to learn. Of course, that's not enough to make good use of git,
but it's enough to declare a transition from SVN or CVS successful.
I personally think it would be worth having a pair of documents, with the
first being "everything you need to know", and the second being "things
you'll find helpful that aren't strictly necessary".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFH] Flush progress message buffer in display().
From: Junio C Hamano @ 2007-11-19 22:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.LFD.0.99999.0711191549510.19105@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 19 Nov 2007, Junio C Hamano wrote:
>
>> The standard error stream is not "fully buffered":
>>
>> http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_05.html#tag_02_05
>>
>> Not "fully buffered" means either "unbuffered" or "line
>> buffered". Because the progress display does not terminate its
>> line, it means that the additional fflush(stderr) you added are
>> needed if the stream is line buffered (still conforming).
>
> Maybe stdio on Linux considers \r as a line termination.
Or totally unbufferred. Running strace on this:
#include <stdio.h>
int
main(int ac, char **av)
{
fprintf(stderr, "foo");
fprintf(stderr, "bar");
return 0;
}
will tell you. I bet you will see two write(2) of 3 bytes
each.
> Flushing stderr should not hurt anyway.
True, especially if the rate is limited, which it is.
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Junio C Hamano @ 2007-11-19 22:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Steffen Prohaska
In-Reply-To: <200711192204.26772.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Brief recap, to check if I understand things correctly:
>>>
>>> 1. If you use "matching" more often, then it should be enough
>>> to provide remote.<remotename>.push with refspec or wildcard
>>> refspec.
>>
>> Eh, excuse me, what refspec would you write there? "matching"
>> is defined to push the intersection of what we have and what
>> they have when "git-push" is run. I do not think there is any
>> way to write that in remote.$there.push and cast in stone.
> [...]
>>> Question: what to do if there is no remote.<remotename>.push?
>>> Assume 1-1 matching?
>>
>> One-to-one is what 'matching' does, and the way to trigger it is
>> not to have a remote.$there.push.
>
> I'm sorry, I had to have "stupid" moment. Thanks a lot for complete
> explanation of git-push, anyway.
>
>
>>> ... If one wants to push only current branch, one
>>> would use "git push --current" or "git push <remotename> HEAD".
>>
>> I think that is the proposal by Steffen (added back CC).
>>
>> I am wondering if an alternative approach could be simpler. If
>> we teach "git-push" to notice when only the refspecs are given
>> without remotename, and default to branch.$current.remote in
>> such a case,
>
> Including default remote when branch.<branchname>.remote is not set?
>
>> IOW, make these:
>>
>> $ git push HEAD
>> $ git push next
>>
>> push the obvious thing to the default remote, I _think_ we can
>> achieve the same effect as --current and a bit more.
>
> The only problem would be when there is conflict between remote name and
> branch name...
Yes. *If* we were to do that fallback it has to be something
like this:
(1) does $0 look like remote and $1..$n look like a refspec? If
so do not fallback;
(2) Do we have branch.$current.remote? If not, we cannot
fallback so error out.
(3) otherwise, does $0 look like a refspec? If so, try insert
it before the params, treating $0..$n all refspecs.
> So for scripts it would be "git push -- HEAD"; still shorter than
> "git push --current".
scripts should be as explicit as they need to be.
What matters is the case when the command cannot be explicit,
just like you cannot write --matching with explicit refspecs.
> BTW. what would happen for "git push branch1 branch2" if branch1 has
> different remote than branch2?
Read my example more carefully. It says "push HEAD" and "push
next" while on 'pu' and it takes branch.pu.remote.
^ permalink raw reply
* Re: Git in a Nutshell guide
From: J. Bruce Fields @ 2007-11-19 22:23 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Matthieu Moy, Lars Hjemli, Jonas Juselius, git
In-Reply-To: <0E0AA90A-2282-4AFE-8B94-EA0E35B57D65@lrde.epita.fr>
On Mon, Nov 19, 2007 at 10:51:35PM +0100, Benoit Sigoure wrote:
> On Nov 19, 2007, at 10:33 PM, Matthieu Moy wrote:
>
>> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>>
>>> No please stop adding links from on man page to another. If you read
>>> man git-reflog, you surely want to learn the HEAD@{N} syntax and see
>>> practical uses cases.
>>
>> I don't understand your point.
>>
>> Yes, if I read man git-reflog, I do surely want to learn HEAD@{N}
>> syntax, but that is _precisely_ what my patch does.
>
> By telling you to read another man page which is annoying and a recurring
> complaint.
Are we looking at the same patch? It both gives examples of the syntax
*and* refers to another page. I thought it was the lack of the former,
rather than the presence of the latter, that was the recurring
complaint....
--b.
^ permalink raw reply
* Re: git-daemon
From: Junio C Hamano @ 2007-11-19 22:23 UTC (permalink / raw)
To: Medve Emilian; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27017BCC42@az33exm24.fsl.freescale.net>
"Medve Emilian" <Emilian.Medve@freescale.com> writes:
> It seems that something changed since maint/v.1.5.3.6 such that on
> master and next git-daemon doesn't seem to be working anymore in inetd
> mode. Can somebody please confirm this?
Sorry, I cannot quite parse. Do you mean:
master and next used to work. Recently 'maint' was
merged to them after v1.5.3.6 was cut. master and next
does not work anymore after that.
Or do you mean:
maint (specifically at v1.5.3.6) works, but master and
next contain more changes on top of them, and they do
not work.
In either case, the only change to the daemon code between
v1.5.3.5 and master is this one:
commit c67359be45be74e1056d6293c6bb09ee6d00a54a
Author: Gerrit Pape <pape@smarden.org>
Date: Mon Nov 5 09:16:22 2007 +0000
git-daemon: fix remote port number in log entry
The port number in struct sockaddr_in needs to be converted from network
byte order to host byte order (on some architectures).
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
daemon.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/daemon.c b/daemon.c
index 660e155..b8df980 100644
--- a/daemon.c
+++ b/daemon.c
@@ -540,7 +540,7 @@ static int execute(struct sockaddr *addr)
if (addr->sa_family == AF_INET) {
struct sockaddr_in *sin_addr = (void *) addr;
inet_ntop(addr->sa_family, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
- port = sin_addr->sin_port;
+ port = ntohs(sin_addr->sin_port);
#ifndef NO_IPV6
} else if (addr && addr->sa_family == AF_INET6) {
struct sockaddr_in6 *sin6_addr = (void *) addr;
@@ -550,7 +550,7 @@ static int execute(struct sockaddr *addr)
inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
strcat(buf, "]");
- port = sin6_addr->sin6_port;
+ port = ntohs(sin6_addr->sin6_port);
#endif
}
loginfo("Connection from %s:%d", addrbuf, port);
I do not see anything wrong in it. The "port" variable is very
local to this function and is used only for that loginfo() call
at the end of the context. So I am quite puzzled.
We have another irrelevant style change that is full of things
like this, but I do not think that makes any behaviour
difference either.
@@ -406,7 +406,8 @@ static struct daemon_service daemon_service[] = {
{ "receive-pack", "receivepack", receive_pack, 0, 1 },
};
-static void enable_service(const char *name, int ena) {
+static void enable_service(const char *name, int ena)
+{
int i;
for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
if (!strcmp(daemon_service[i].name, name)) {
^ permalink raw reply related
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Jakub Narebski @ 2007-11-19 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steffen Prohaska
In-Reply-To: <7vfxz1naq0.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano wrote:
>>> IOW, make these:
>>>
>>> $ git push HEAD
>>> $ git push next
>>>
>>> push the obvious thing to the default remote, I _think_ we can
>>> achieve the same effect as --current and a bit more.
>>
>> The only problem would be when there is conflict between remote name and
>> branch name...
What about idea of using "--" to separate remote from branchname?
> Yes. *If* we were to do that fallback it has to be something
> like this:
>
> (1) does $0 look like remote and $1..$n look like a refspec? If
> so do not fallback;
By "look like remote" you mean that there is [remote "$0"] section
in config (I guess that we can not support old .git/remotes/<remote>
configuration for _new_ features, especially that there exist script
converting to new way of configuring remotes, contrib/remotes2config.sh)
> (2) Do we have branch.$current.remote? If not, we cannot
> fallback so error out.
Do not fallback to "origin"?
> (3) otherwise, does $0 look like a refspec? If so, try insert
> it before the params, treating $0..$n all refspecs.
You mean $0 is existing branch, or of the form branch:<whatever>?
Or should we forbid remote names containing ':'?
>> BTW. what would happen for "git push branch1 branch2" if branch1 has
>> different remote than branch2?
>
> Read my example more carefully. It says "push HEAD" and "push
> next" while on 'pu' and it takes branch.pu.remote.
Somehow I missed that $current means _current branch_ (branch we are on,
which defines default remote).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Junio C Hamano @ 2007-11-19 22:29 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Matthieu Moy, Lars Hjemli, Jonas Juselius, git
In-Reply-To: <0E0AA90A-2282-4AFE-8B94-EA0E35B57D65@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> On Nov 19, 2007, at 10:33 PM, Matthieu Moy wrote:
>
>> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>>
>>> No please stop adding links from on man page to another. If you read
>>> man git-reflog, you surely want to learn the HEAD@{N} syntax and see
>>> practical uses cases.
>>
>> I don't understand your point.
>>
>> Yes, if I read man git-reflog, I do surely want to learn HEAD@{N}
>> syntax, but that is _precisely_ what my patch does.
>
> By telling you to read another man page which is annoying and a
> recurring complaint.
Which is a valid point. We could move that part into a separate
source file and include it from different places appropriately,
just we have done for the common diff options.
However, you need to think about what's appropriate. Any
command that potentially takes a ref as (one of) its parameter?
That means almost everybody.
I think the ref naming syntax is so commonly used and
fundamental that we could treat it as prerequiste for individual
manual pages. Maybe move the section to git(7)? That would
certainly be better than having it in git-rev-parse(1), but does
not reduce the cross referencing complaints.
^ permalink raw reply
* [ANNOUNCE] Guilt v0.28
From: Josef Sipek @ 2007-11-19 22:43 UTC (permalink / raw)
To: guilt; +Cc: git, brandon
Guilt v0.28 is available for download (once it mirrors out on kernel.org).
Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.
(kernel.org seems to be slow at mirroring things today, so please be
patient)
Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/
Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
This release took _far_ too long to make. The major changes since v0.27
include:
- fix for insecure handling of temporary files (CVE-2007-5207)
- push and pop now support -n <num> to push/pop specified number of patches
- import-commit can import any commit from any branch
- couple of other small bugfixes/tweaks
For more details about any of the commits, check the commits.
As always, patches, and other feedback is welcome.
Josef "Jeff" Sipek.
------------
Changes since v0.27:
David Chinner (1):
{push,pop}: Add -n <number of patches> option
Erez Zadok (1):
Documentation fixups
Eric Lesh (2):
guilt-help: Make guilt-cmd --help show the right man page
[GUILT PATCH] guilt-import-commit: Import commits from any branch
Josef 'Jeff' Sipek (6):
{next,prev,top}: Update usage strings & docs
guilt: Fix insecure handling of temporary files
patchbomb: Be quiet when there are no Cc lines in patch header
guilt: fixed bad interaction between push_patch() and git
guilt: Fixed regexp matching the beginning of the patch
Guilt v0.28
Peter Zijlstra (1):
guilt: allow for full path in {top,next,prev}
^ permalink raw reply
* RE: git-daemon
From: Medve Emilian @ 2007-11-19 22:49 UTC (permalink / raw)
To: git
In-Reply-To: <7vbq9pnac2.fsf@gitster.siamese.dyndns.org>
Hello Junio,
v1.5.3.6 works but the HEAD of master and next don't. I considered the
patches below but they seemed harmless. I think the problem comes form
upload-pack (and below it). Weirdly enough running git-daemon standalone
seems to work fine. Cloning over ssh or on the same file system seems to
work fine too.
I was hoping somebody can repeat the experiment (build the latest master
or maint) and invalidate my experience.
Cheers,
Emil.
> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Monday, November 19, 2007 4:24 PM
> To: Medve Emilian
> Cc: git@vger.kernel.org
> Subject: Re: git-daemon
>
> "Medve Emilian" <Emilian.Medve@freescale.com> writes:
>
> > It seems that something changed since maint/v.1.5.3.6 such that on
> > master and next git-daemon doesn't seem to be working
> anymore in inetd
> > mode. Can somebody please confirm this?
>
> Sorry, I cannot quite parse. Do you mean:
>
> master and next used to work. Recently 'maint' was
> merged to them after v1.5.3.6 was cut. master and next
> does not work anymore after that.
>
> Or do you mean:
>
> maint (specifically at v1.5.3.6) works, but master and
> next contain more changes on top of them, and they do
> not work.
>
> In either case, the only change to the daemon code between
> v1.5.3.5 and master is this one:
>
> commit c67359be45be74e1056d6293c6bb09ee6d00a54a
> Author: Gerrit Pape <pape@smarden.org>
> Date: Mon Nov 5 09:16:22 2007 +0000
>
> git-daemon: fix remote port number in log entry
>
> The port number in struct sockaddr_in needs to be
> converted from network
> byte order to host byte order (on some architectures).
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> daemon.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/daemon.c b/daemon.c
> index 660e155..b8df980 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -540,7 +540,7 @@ static int execute(struct sockaddr *addr)
> if (addr->sa_family == AF_INET) {
> struct sockaddr_in *sin_addr = (void *) addr;
> inet_ntop(addr->sa_family,
> &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
> - port = sin_addr->sin_port;
> + port = ntohs(sin_addr->sin_port);
> #ifndef NO_IPV6
> } else if (addr && addr->sa_family == AF_INET6) {
> struct sockaddr_in6 *sin6_addr = (void *) addr;
> @@ -550,7 +550,7 @@ static int execute(struct sockaddr *addr)
> inet_ntop(AF_INET6,
> &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
> strcat(buf, "]");
>
> - port = sin6_addr->sin6_port;
> + port = ntohs(sin6_addr->sin6_port);
> #endif
> }
> loginfo("Connection from %s:%d", addrbuf, port);
>
> I do not see anything wrong in it. The "port" variable is very
> local to this function and is used only for that loginfo() call
> at the end of the context. So I am quite puzzled.
>
> We have another irrelevant style change that is full of things
> like this, but I do not think that makes any behaviour
> difference either.
>
> @@ -406,7 +406,8 @@ static struct daemon_service daemon_service[] = {
> { "receive-pack", "receivepack", receive_pack, 0, 1 },
> };
>
> -static void enable_service(const char *name, int ena) {
> +static void enable_service(const char *name, int ena)
> +{
> int i;
> for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
> if (!strcmp(daemon_service[i].name, name)) {
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Jon Smirl @ 2007-11-19 22:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <tnxbq9qyvom.fsf@pc1117.cambridge.arm.com>
On 11/19/07, Catalin Marinas <catalin.marinas@arm.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> wrote:
> > On 11/18/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> "Jon Smirl" <jonsmirl@gmail.com> writes:
> >>
> >> > What's causing this? I'm using stgit on the master branch.
> [...]
> >> pushed "A" to the remote's 'master', then built this history:
> >>
> >> o---o---A
> >> /
> >> ---o---o---o---o---A'
> >>
> >> by rewinding and rebuilding, and the tip of the branch now
> >> points at A', which you tried to push to the remote.
> >
> > stgit must be doing this when I rebase. It pops all of it's patches,
> > moves to head of linus/master and then rebases them.
> [...]
> > What is the right way to share repositories using stgit? I have a set
> > of patches which I am working on for kernel inclusion. I have them
> > applied as a stgit stack on top of linus/master. I need to share this
> > patch stack with other developers. These developers may want to change
> > one of my patches. Right now they are emailing me deltas and I apply
> > them to the appropriate stgit patch. I have seventeen patches in my
> > stack currently.
>
> StGIT is meant for keeping a clean history but with the big
> disadvantage that this history is volatile.
>
> A solution is for the other developers to use StGIT or just git-rebase
> so that they always have the same base (volatile) history and keep
> their patches on top of yours.
>
> A 2nd approach is to use topic branches rather than StGIT patches but
> you might lose some flexibility.
>
> Yet another approach (which I used) is to keep a public branch (can be
> maintained by StGIT) where the history doesn't change and a devel
> volatile branch. When I modify some patches and they are ready for
> publishing, switch to the public branch and cherry-pick them (stg
> pick) from the devel branch. Because this is done with a three-way
> merge in StGIT, you will only get the new changes rather than the full
> patch. You need to change the patch message (as it is that of the
> original patch) to describe the specific changes and run 'stg refresh
> && stg commit' to store it into the immutable history (well, there is
> an 'uncommit' command as well if something goes wrong).
Is a StGit where we can transparently share patches under version
control in the works?
Something like this:
clone repo with stgit
normal stg commands work with no setup
change a patch
stg push the repo
I stg pull and the patch is updated.
I also get rebased forward if the base repo has been updated
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Matthieu Moy @ 2007-11-19 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Benoit Sigoure, Lars Hjemli, Jonas Juselius, git
In-Reply-To: <7v7ikdna24.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think the ref naming syntax is so commonly used and
> fundamental that we could treat it as prerequiste for individual
> manual pages. Maybe move the section to git(7)? That would
> certainly be better than having it in git-rev-parse(1), but does
> not reduce the cross referencing complaints.
Well, obviously, something which isn't addressed by my patch is the
fact that some of the documentation an average user needs is in the
plumbing man pages.
(Gosh, I was going to cite the manpage for git-log and git-rev-parse
as an example, but it has already been fixed :-). Good job !)
git-rev-parse(1) is full of terribly usefull information, and that
information is definitely not in the place an average user would look
at.
I have no ideal solution for that. git(7) is already really long.
Perhaps some "topic man pages" would be good. By "topic man page", I
mean "man git-something" where "something" isn't a git command, but a
crosscutting concept. For example, here, "man git-refspec" to document
reference specifiers like HEAD@{42}, master~55, d71c6c8e24a and
friends. "man git-i18n" would be another candidate.
Anyway, my patch is definitely a step forward, even if it's just the
first, small one ;-).
--
Matthieu
^ permalink raw reply
* t9106 failure, bisect weirdness
From: carbonated beverage @ 2007-11-19 23:06 UTC (permalink / raw)
To: git
Hi all,
Just checked out v1.5.3.6 from git, built it on a Debian/stable i386 box,
and got a failure in one of the test suites:
*** t9106-git-svn-dcommit-clobber-series.sh ***
* ok 1: initialize repo
* ok 2: (supposedly) non-conflicting change from SVN
* ok 3: some unrelated changes to git
* FAIL 4: change file but in unrelated area
test x"`sed -n -e 4p < file`" = x4 &&
test x"`sed -n -e 7p < file`" = x7 &&
perl -i -p -e 's/^4$/4444/' file &&
perl -i -p -e 's/^7$/7777/' file &&
test x"`sed -n -e 4p < file`" = x4444 &&
test x"`sed -n -e 7p < file`" = x7777 &&
git commit -m '4 => 4444, 7 => 7777' file &&
git svn dcommit &&
svn up tmp &&
cd tmp &&
test x"`sed -n -e 4p < file`" = x4444 &&
test x"`sed -n -e 7p < file`" = x7777 &&
test x"`sed -n -e 58p < file`" = x5588 &&
test x"`sed -n -e 61p < file`" = x6611
* ok 5: attempt to dcommit with a dirty index
* failed 1 among 5 test(s)
make[1]: *** [t9106-git-svn-dcommit-clobber-series.sh] Error 1
make[1]: Leaving directory `/home/ramune/src/git/git/t'
make: *** [test] Error 2
ramune/lycaeum:git:
Bisecting gives me:
fb159580a1628947f0a088e24cfe6fe4c81d99d0 is first bad commit
commit fb159580a1628947f0a088e24cfe6fe4c81d99d0
Author: Eric Wong <normalperson@yhbt.net>
Date: Mon Nov 5 03:21:48 2007 -0800
git-svn: t9114: verify merge commit message in test
It's possible that we end up with an incorrect commit message
in this test after making changes to fix the clobber bug
in dcommit.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:040000 040000 1c4f3776c031f9531869e736b661a0559fab5ff6 4f4c5ecd6c79f7e9732b554e2f8dd536a8a8f2a6 M t
Which seems odd -- the previous commit (marked good, because make test didn't
fail) was the one that modified t9106-git-svn-dcommit-clobber-series.sh.
I tried running the test manually and noticed something weird as well:
ramune/lycaeum:t: sh t9106-git-svn-dcommit-clobber-series.sh
* ok 1: initialize repo
* ok 2: (supposedly) non-conflicting change from SVN
* ok 3: some unrelated changes to git
* ok 4: change file but in unrelated area
* passed all 4 test(s)
ramune/lycaeum:t:
ramune/lycaeum:t: pwd
/home/ramune/src/git/git/t
ramune/lycaeum:t:
ramune/lycaeum:t: sh t9106-git-svn-dcommit-clobber-series.sh
* ok 1: initialize repo
* ok 2: (supposedly) non-conflicting change from SVN
* ok 3: some unrelated changes to git
* FAIL 4: change file but in unrelated area
test x"`sed -n -e 4p < file`" = x4 &&
test x"`sed -n -e 7p < file`" = x7 &&
perl -i -p -e 's/^4$/4444/' file &&
perl -i -p -e 's/^7$/7777/' file &&
test x"`sed -n -e 4p < file`" = x4444 &&
test x"`sed -n -e 7p < file`" = x7777 &&
git commit -m '4 => 4444, 7 => 7777' file &&
git svn dcommit &&
svn up tmp &&
cd tmp &&
test x"`sed -n -e 4p < file`" = x4444 &&
test x"`sed -n -e 7p < file`" = x7777 &&
test x"`sed -n -e 58p < file`" = x5588 &&
test x"`sed -n -e 61p < file`" = x6611
* failed 1 among 4 test(s)
So it succeeds once, then fails.
/bin/sh is dash 0.5.3-7 from Debian.
Any additional information needed?
-- DN
Daniel
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Junio C Hamano @ 2007-11-19 23:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Benoit Sigoure, Lars Hjemli, Jonas Juselius, git
In-Reply-To: <vpqd4u5zvs3.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> I have no ideal solution for that. git(7) is already really long.
> Perhaps some "topic man pages" would be good. By "topic man page", I
> mean "man git-something" where "something" isn't a git command, but a
> crosscutting concept. For example, here, "man git-refspec" to document
> reference specifiers like HEAD@{42}, master~55, d71c6c8e24a and
> friends. "man git-i18n" would be another candidate.
Yeah, gitattributes(5), gitignore(5) and gitmodules(5) can take
advantage of the fact that they define file formats and describe
the underlying concepts in their own corner while describing the
file format. But there are many other things (e.g. syntax for
refspec, ref naming) that would benefit from having their own
topic-centric documents, without defining their own file format,
so git-refspec(5) trick is not an option for them.
^ permalink raw reply
* [PATCH] git-svn: add a show-externals command.
From: Vineet Kumar @ 2007-11-19 22:56 UTC (permalink / raw)
To: git; +Cc: Vineet Kumar
show-externals can be used by scripts to provide svn:externals-like
functionality. For example, a script can list all of the externals and then
use check out the listed URLs at the appropriate paths, similar to what the svn
client does. Said script (or perhaps git-svn itself, in the future) could
simply invoke svn export on the paths, or it could go one further, using
git-svn clone and even git-submodule together to better integrate externals
checkouts.
The implementation is shamelessly copied from show-ignores. A more general
command to list user-specified properties is probably a better idea.
Signed-off-by: Vineet Kumar <vineet@doorstop.net>
---
git-svn.perl | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 5b1deea..74966ed 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -141,6 +141,9 @@ my %cmd = (
'show-ignore' => [ \&cmd_show_ignore, "Show svn:ignore listings",
{ 'revision|r=i' => \$_revision
} ],
+ 'show-externals' => [ \&cmd_show_externals, "Show svn:externals listings",
+ { 'revision|r=i' => \$_revision
+ } ],
'multi-fetch' => [ \&cmd_multi_fetch,
"Deprecated alias for $0 fetch --all",
{ 'revision|r=s' => \$_revision, %fc_opts } ],
@@ -560,6 +563,21 @@ sub cmd_show_ignore {
});
}
+sub cmd_show_externals {
+ my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
+ $gs ||= Git::SVN->new;
+ my $r = (defined $_revision ? $_revision : $gs->ra->get_latest_revnum);
+ $gs->prop_walk($gs->{path}, $r, sub {
+ my ($gs, $path, $props) = @_;
+ print STDOUT "\n# $path\n";
+ my $s = $props->{'svn:externals'} or return;
+ $s =~ s/[\r\n]+/\n/g;
+ chomp $s;
+ $s =~ s#^#$path#gm;
+ print STDOUT "$s\n";
+ });
+}
+
sub cmd_create_ignore {
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
$gs ||= Git::SVN->new;
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] Fix warning about bitfield in struct ref
From: Johannes Schindelin @ 2007-11-19 23:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071118093137.GA2196@spearce.org>
Hi,
On Sun, 18 Nov 2007, Shawn O. Pearce wrote:
> + unsigned int force:1,
Isn't this "unsigned force:1" everywhere else in git's source?
Ciao,
Dscho
^ 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