* Re: Lightweight tag ?
From: Michael J Gruber @ 2009-01-12 12:55 UTC (permalink / raw)
To: Francis Moreau; +Cc: Junio C Hamano, git
In-Reply-To: <m2bpucnas2.fsf@gmail.com>
Francis Moreau venit, vidit, dixit 01/12/09 10:17:
> Hello,
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Don't use explicit --tags blindly. It says "no matter what kind of tag,
>> transfer everything under refs/tags". Otherwise you won't see a
>> difference.
>
> Well:
>
> $ git --version
> git version 1.6.0.4
> $ mkdir test-tag
> $ cd test-tag/
> $ date > A
> $ git init
> Initialized empty Git repository in
> /home/fmoreau/tmp/git/test-tag/.git/
> $ git add .
> $ git commit -a -s -m "Init"
> Created initial commit be8750e: Init
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 A
> $ cd ..
> $ git clone --bare test-tag test-tag.git
> Initialized empty Git repository in /home/fmoreau/tmp/git/test-tag.git/
> $ cd test-tag
> $ git tag light
>
> $ git tag -a -m "Annoted tag" annoted
> $ git push ../test-tag.git
> Everything up-to-date
> $ git push --tags ../test-tag.git
> Counting objects: 1, done.
> Writing objects: 100% (1/1), 166 bytes, done.
> Total 1 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (1/1), done.
> To ../test-tag.git
> * [new tag] annoted -> annoted
> * [new tag] light -> light
>
> It looks like they're no difference for git-push...
>
> That said the documentation about this is rather cryptic IMHO:
>
> ,----[ man git-push ]
> | --tags
> | All refs under $GIT_DIR/refs/tags are pushed, in
> | addition to refspecs explicitly listed on the command
> | line.
> `----
>
> From a user point of view, the word lightweight is missing here. Why
> not simply saying:
>
> ,----
> | All kind of tags are pushed with this option _otherwise_ only annoted
> | tags are pushed
> `----
Your test above confirms that the description is correct and nothing is
missing. "git push" pushes explicitly listed refspecs (or : as a
default). It pushes tags (light and heavy) when asked to.
"git pull" pulls tags if they can be reached from heads which are
pulled. It pulls all tags only when asked to.
In fact, the automatic following of tags (if they can be reached...)
depends on the transport, because typically you want to clone everything
if you clone locally but don't want all tags if you clone/pull from a
remote. There is also a config "tagopt" for overriding this. It's
mentioned but not really explained in "git tag"'s man page.
So, "non-local" tags are the ones which can be reached from heads which
you pull, and local ones are the others. I don't think lightweight tags
are more local than tag objects (please correct me if I'm wrong; I think
this needs more doc). It's just that the latter reside in the object db
store whereas the former are simple refs under refs/tags.
Michael
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Mikael Magnusson @ 2009-01-12 12:25 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <4967DB4A.2000702@lsrfire.ath.cx>
2009/1/10 René Scharfe <rene.scharfe@lsrfire.ath.cx>:
> Add the new flag "fixed" to struct grep_pat and set it if the pattern
> is doesn't contain any regex control characters in addition to if the
> flag -F/--fixed-strings was specified.
>
> diff --git a/grep.c b/grep.c
> index 394703b..a1092df 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -28,9 +28,31 @@ void append_grep_pattern(struct grep_opt *opt, const char *pat,
> p->next = NULL;
> }
>
> +static int isregexspecial(int c)
> +{
> + return isspecial(c) || c == '$' || c == '(' || c == ')' || c == '+' ||
> + c == '.' || c == '^' || c == '{' || c == '|';
> +}
Shouldn't this include '*' and '\'?
--
Mikael Magnusson
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Mike Hommey @ 2009-01-12 12:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <200901121213.45858.jnareb@gmail.com>
On Mon, Jan 12, 2009 at 12:13:44PM +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> Alex Riesen wrote:
> > 2009/1/12 Jakub Narebski <jnareb@gmail.com>:
>
> > > Do you have any suggestions to bypass this block for git? I have access
> > > to Linux shell account (no root access, though) which doesn't have
> > > problems with repo.or.cz, so I think I could set up SSH tunnel: but
> > > how? And what to do with access via git:// - move to SSH too?
> >
> > See man ssh, look for -L. It works for arbitrary ports, so you can redirect
> > git:// port to anywhere. Same for push over ssh, just give another port when
> > connecting.
>
> Currently I have the folowing in my ~/.ssh/config:
>
> # TP S.A. blocks repo.or.cz
> Host repo.or.cz
> NoHostAuthenticationForLocalhost yes
> HostName localhost
> Port 2222
>
> and I can simply use "git push repo" without any changes.
> But I have to run
>
> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>
> first. Is there any way to automate this?
Something like the following should do the trick:
Host repo.or.cz
ProxyCommand ssh jnareb@host.example.com nc %h %p
You will need nc (netcat) installed on the host.example.com server, though.
Mike
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Johannes Sixt @ 2009-01-12 12:19 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20090112120345.GA12087@coredump.intra.peff.net>
Jeff King schrieb:
> On Mon, Jan 12, 2009 at 01:00:05PM +0100, Johannes Sixt wrote:
>
>> Good question. The exit code is 0xc000013a if the signal was generated by
>> hitting Ctrl-C (tested with 'git --no-pager log'), but it is 3 if the
>> signal was "generated" by 'raise(SIGINT)'. The implementation of the
>> latter just calls _exit(3) (same for other deadly signals). Wow!
>
> Eh? So it doesn't even run the signal handlers? Or if it is SIG_DFL
> (i.e., we have already run all the handlers), then it just calls _exit?
It's silly, but not *that* silly: It calls _exit(3) only if the handler is
SIG_DFL.
-- Hannes
^ permalink raw reply
* Re: "git diff --stat" doesn't show added empty file
From: Johannes Schindelin @ 2009-01-12 12:19 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320901111936h6343e51fo94750d83e95743dc@mail.gmail.com>
Hi,
On Mon, 12 Jan 2009, Ping Yin wrote:
> $ git --version
> git version 1.6.1.9.g97c34
> $ mkdir test && cd test && git init && git commit --allow-empty -m
> "Initial commit"
> $ touch .gitignore && git add .gitignore && git commit -m "Add empty .gitignore"
> $ git diff --stat HEAD^..
> 0 files changed, 0 insertions(+), 0 deletions(-)
>
> May be the following is better?
>
> .gitignore | 0 +
> 1 files changed, 0 insertions(+), 0 deletions(-)
Have fun coding that.
Ciao,
Dscho
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Jeff King @ 2009-01-12 12:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <496B30C5.2060207@viscovery.net>
On Mon, Jan 12, 2009 at 01:00:05PM +0100, Johannes Sixt wrote:
> Good question. The exit code is 0xc000013a if the signal was generated by
> hitting Ctrl-C (tested with 'git --no-pager log'), but it is 3 if the
> signal was "generated" by 'raise(SIGINT)'. The implementation of the
> latter just calls _exit(3) (same for other deadly signals). Wow!
Eh? So it doesn't even run the signal handlers? Or if it is SIG_DFL
(i.e., we have already run all the handlers), then it just calls _exit?
> > Don't these get fed to signal()? Does Windows really not care about
> > getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
> > are we just ignoring the return code everywhere?
>
> Windows's signal() does return EINVAL; appearently, we never check the
> return code. :-P
OK. That makes sense; we don't bother checking the return code because
it's mostly just registering a cleanup function. The only sane thing to
do on an error (besides ignore it) is to abort whatever we're doing, and
I'm not sure it's worth it.
I do feel a little like this is a trap waiting to spring for future
coders to break Windows, but I think your change doesn't make anything
_worse_ in that regard.
-Peff
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Johannes Sixt @ 2009-01-12 12:00 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20090112112109.GA3825@coredump.intra.peff.net>
Jeff King schrieb:
> Hrm. How do you properly detect "killed by SIGINT" on Windows?
Good question. The exit code is 0xc000013a if the signal was generated by
hitting Ctrl-C (tested with 'git --no-pager log'), but it is 3 if the
signal was "generated" by 'raise(SIGINT)'. The implementation of the
latter just calls _exit(3) (same for other deadly signals). Wow!
>> -#define SIGKILL 0
>> -#define SIGCHLD 0
>> -#define SIGPIPE 0
>> -#define SIGHUP 0
>> -#define SIGQUIT 0
>> -#define SIGALRM 100
>> +#define SIGHUP 1
>> +#define SIGQUIT 3
>> +#define SIGKILL 9
>> +#define SIGPIPE 13
>> +#define SIGALRM 14
>> +#define SIGCHLD 17
>
> Don't these get fed to signal()? Does Windows really not care about
> getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
> are we just ignoring the return code everywhere?
Windows's signal() does return EINVAL; appearently, we never check the
return code. :-P
-- Hannes
^ permalink raw reply
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Alex Riesen @ 2009-01-12 11:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110336380.19665@iabervon.org>
2009/1/11 Daniel Barkalow <barkalow@iabervon.org>:
> diff --git a/Makefile b/Makefile
>
> +LIB_OBJS += p4client.o
> +LIB_OBJS += vcs-p4.o
> +
>
> +extern int cmd_p4(int argc, const char **argv, const char *prefix);
> +
Why is your foreign VCS importer built-in? The majority wont ever need it,
yet they have to pay the price for its text being in git executable.
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Luciano Rocha @ 2009-01-12 11:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <200901121213.45858.jnareb@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]
On Mon, Jan 12, 2009 at 12:13:44PM +0100, Jakub Narebski wrote:
> Alex Riesen wrote:
> > 2009/1/12 Jakub Narebski <jnareb@gmail.com>:
>
> > > Do you have any suggestions to bypass this block for git? I have access
> > > to Linux shell account (no root access, though) which doesn't have
> > > problems with repo.or.cz, so I think I could set up SSH tunnel: but
> > > how? And what to do with access via git:// - move to SSH too?
> >
> > See man ssh, look for -L. It works for arbitrary ports, so you can redirect
> > git:// port to anywhere. Same for push over ssh, just give another port when
> > connecting.
>
> Currently I have the folowing in my ~/.ssh/config:
>
> # TP S.A. blocks repo.or.cz
> Host repo.or.cz
> NoHostAuthenticationForLocalhost yes
> HostName localhost
> Port 2222
>
> and I can simply use "git push repo" without any changes.
> But I have to run
>
> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>
> first. Is there any way to automate this?
For those cases I use the attached script. Read the first lines, with
information on how to install.
The end result is that I can do:
ssh host1--host2--host3
Or scp, rsync, etc.
Regards,
Luciano Rocha
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #1.2: ssh_p --]
[-- Type: text/plain, Size: 2166 bytes --]
#!/bin/bash
## SSH connection chaining
##
## (C) 2007, Luciano Rocha <strange@nsk.pt>
##
## This program is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License
## as published by the Free Software Foundation; either version 2
## of the License, or (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
## Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
## MA 02110-1301, USA.
##
## Or check the webpage: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
##
## Documentation:
##
## Include in your .ssh/config:
## host *--*
## proxycommand ssh_p %h %p
##
## And then you can do:
## ssh hosta--hostb--hostc
## scp hosta--hostb--hostc:file .
##
## A user specification is also possible, but not for the last host, for
## that one, you'll have to use ssh's standard user specification (user@host
## or -luser):
## ssh usera_hosta--userb_hostb--hostc -luserc
## scp userc@usera_hosta--userb_hostb--hostc:file .
##
## Compression is disable on all proxy sshs, as traffic is already encrypted.
## Activate compression in the master ssh command, if desired.
##
## Environment variable SSH_CONFIG_FILE can point to a ssh configuration
## file for use in the proxy sshs.
## missing hops
h="${1%--*}"
## nc target
rh="${1##*--}"
p="${2:-22}"
## user for next hop
u=
n="${h##*--}"
if [ -z "${n##*_*}" ]; then
u=${n%%_*}
if [ "$h" != "$n" ]; then
h="${h%--*}--${n##*_}"
else
h="${n##*_}"
fi
fi
echo "${SSH_INDENT}+ connecting to $h for $rh" >&2
exec env SSH_INDENT="${SSH_INDENT} " ssh -o "Compression no" \
${SSH_CONFIG_FILE:+-F$SSH_CONFIG_FILE} \
${u:+$u@}$h \
"echo \"${SSH_INDENT}- connected to $h, forwarding to $rh:$p\" >&2 ; nc -w 3600 $rh $p"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Asheesh Laroia @ 2009-01-12 11:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <200901121213.45858.jnareb@gmail.com>
On Mon, 12 Jan 2009, Jakub Narebski wrote:
> But I have to run
>
> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>
> first. Is there any way to automate this?
Check out 'gstm' or 'autossh'.
-- Asheesh.
--
You will get what you deserve.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Andreas Ericsson @ 2009-01-12 11:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090107183033.GB10790@spearce.org>
Just chiming in that I can probably help mentoring whoever goes
with libgit2. I do not have enough spare time for me to promise
that I can be there as much as I think is necessary and proper,
but I'll gladly help out.
On a side-note, I think all mentors should urge the students in
the strongest possible terms to deliver their work to git@vger
as soon as possible. From previous years experience, successful
projects are those that the list sees code from within a week
or two after the project's started, while the projects that are
kept in the dark rarely (if ever?) finish successfully.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Jeff King @ 2009-01-12 11:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <496B2278.9050905@viscovery.net>
On Mon, Jan 12, 2009 at 11:59:04AM +0100, Johannes Sixt wrote:
> But we need to insert the patch below *before* 2/4. The test case needs a
> change, too,(exit code on Windows is 3, not 130) but I'll keep that in my
> repository, like with all other Windows related test suite changes.
Hrm. How do you properly detect "killed by SIGINT" on Windows? That is
the intent of that test.
> -#define SIGKILL 0
> -#define SIGCHLD 0
> -#define SIGPIPE 0
> -#define SIGHUP 0
> -#define SIGQUIT 0
> -#define SIGALRM 100
> +#define SIGHUP 1
> +#define SIGQUIT 3
> +#define SIGKILL 9
> +#define SIGPIPE 13
> +#define SIGALRM 14
> +#define SIGCHLD 17
Don't these get fed to signal()? Does Windows really not care about
getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
are we just ignoring the return code everywhere?
-Peff
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 11:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0901120117mf010317m79874a235e29a439@mail.gmail.com>
Alex Riesen wrote:
> 2009/1/12 Jakub Narebski <jnareb@gmail.com>:
> > Do you have any suggestions to bypass this block for git? I have access
> > to Linux shell account (no root access, though) which doesn't have
> > problems with repo.or.cz, so I think I could set up SSH tunnel: but
> > how? And what to do with access via git:// - move to SSH too?
>
> See man ssh, look for -L. It works for arbitrary ports, so you can redirect
> git:// port to anywhere. Same for push over ssh, just give another port when
> connecting.
Currently I have the folowing in my ~/.ssh/config:
# TP S.A. blocks repo.or.cz
Host repo.or.cz
NoHostAuthenticationForLocalhost yes
HostName localhost
Port 2222
and I can simply use "git push repo" without any changes.
But I have to run
$ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
first. Is there any way to automate this?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Lars Hjemli @ 2009-01-12 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab9wj0rs.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 12, 2009 at 11:07, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>> On Mon, Jan 12, 2009 at 04:15, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> When the user explicitly asks you to traverse into submodules and the
>>> necessary commit is not available in a submodule, the code goes on without
>>> complaining. I am not saying it is bad, but I wonder if we would want to
>>> distinguish these three cases:
>>>
>>> (1) the submodule is initialized and the necessary commit is there.
>>>
>>> (2) the submodule is initialized, but the necessary commit is missing.
>>>
>>> (3) the submodule is not even initialized (aka "the user is not
>>> interested in it"); there is only an empty directory.
>>>
>>> I think it is perfectly fine not to say anything for (3) but I am unsure
>>> about the second case.
>>
>> Do we want to impose the porcelainish rules of git-submodule
>> (.gitmodules, .git/config) in read_tree_recursive()?
>>
>> If so, I guess a new submodule.h might provide something like this
>> (disclaimer: coded in gmail):
>
> I do not see why you would need anything more than we already have to tell
> (3) from (1) and (2). And I do not see why you need to have the Porcelain
> policy in the picture for telling these three cases apart, either.
>
> For example, there is this code in read-cache.c::ce_compare_gitlink():
>
> static int ce_compare_gitlink(struct cache_entry *ce)
> {
> unsigned char sha1[20];
>
> /*
> * We don't actually require that the .git directory
> * under GITLINK directory be a valid git directory. It
> * might even be missing (in case nobody populated that
> * sub-project).
> *
> * If so, we consider it always to match.
> */
> if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
> return 0;
> return hashcmp(sha1, ce->sha1);
> }
>
> It asks resolve_gitlink_ref() to see if the directory (where the submodule
> checkout _might_ be present if the user is interested in it) has .git/HEAD
> that resolves. If so, the user has a checkout and is interested in it.
> Otherwise, there is no checkout, in other words, we have case (3) above.
Ah, yes, this makes sense. Thanks.
> Whether you force the user to link the submodule object store to the
> primary one as alternates, or do that for the user temporarily inside the
> process [*1*],
If resolve_gitlink_ref() returns 0, I think we should automatically
insert the objectdir of the submodule as a tempory alternate.
> you would then be able to tell (1) and (2) apart by asking
> has_sha1_file() if you can see the commit.
Yes (I've also got a use-case for this with bare repositories [*1*],
but in that setting I guess it's ok to force the user to link the
alternates manually).
> One thing that is unclear is to me is for whom the commit is missing (or
> present). I think the outline I gave above follows the design of your
> patch to assume that the commit may (or may not) be available to the
> superproject and traverse into the commit when that is the case. It does
> not mean the commit is available to the submodule itself (the commit may
> have found in the primary project itself, not via the alternates), but
> such an arrangement makes it somewhat useless.
I think we can ignore this issue; if someone has added the
superproject as an alternate for the submodule and then done a
checkout of a superproject commit in the submodule followed by
committing this gitlink in the superproject, we can only hope the user
really knew what he was doing...
> What's the typical direction of using alternates in a setting with
> superproject with a submodule? Do people have alternates in the submodule
> repository that borrows from the superproject repository? Or the other
> way around? What's the rationale for having such alternates for normal
> use case? I am suspecting that there is no reason (other than this
> "recursive tree traversal") to have an alternates file in either
> direction,
Likewise.
> but I also strongly suspect that I am missing some unwritten
> assumption you are making.
I'm only assuming that we want to support traversal into the
submodules from core git.
*1* This will be (ab)used by cgit to support downloading of 'complete'
tarballs, as outlined in
http://thread.gmane.org/gmane.comp.version-control.git/102827.
--
larsh
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Johannes Sixt @ 2009-01-12 10:59 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20090111112222.GA29656@coredump.intra.peff.net>
From: Johannes Sixt <j6t@kdbg.org>
Jeff King schrieb:
> On Fri, Jan 09, 2009 at 11:36:41AM +0100, Johannes Sixt wrote:
>
>> I'll test your other patch (that replaces the execvp in git.c by
>> run_command).
>
> There is something funny with it that I have not diagnosed: aliases are
> broken, and "git foobar" does not return an error. Presumably just
> checking the "we did not exec succesfully" case is not triggering
> properly. However, I think the right solution is actually to refactor
> git.c to figure out ahead of time whether we have a builtin, external,
> or alias. I can work on that, but not tonight, as my git-time is up for
> now.
>
> But other than that, did it work for you on Windows?
It passed the test suite. This should already work better on Windows,
because we already *do* look-up the program, and exit from
mingw_spawnvpe() before the equivalent of fork+exec happens.
> However, here is a 4-patch series that handles the separate signal
> delivery problem. It should fix the "^C makes funny things happen"
> problems you were seeing. Please test and let me know how it works on
> Windows.
It does help a bit. The interesting thing is that the only case where I
can now reproduces the unwanted behavior with the unpatched version is
when all output was completely read by 'less' and git already waits in
wait_for_pager(), such as in 'git show'. But Ctrl-C'ing a 'git log -p'
works as expected even without these patches. With the patches, the 'git
show' case now works as well.
> The patches are:
> 1/4: Makefile: clean up TEST_PROGRAMS definition
> 2/4: chain kill signals for cleanup functions
> 3/4: refactor signal handling for cleanup functions
> 4/4: pager: do wait_for_pager on signal death
But we need to insert the patch below *before* 2/4. The test case needs a
change, too,(exit code on Windows is 3, not 130) but I'll keep that in my
repository, like with all other Windows related test suite changes.
-- Hannes
-- 8< --
From: Johannes Sixt <j6t@kdbg.org>
Subject: Windows: Fix signal numbers
We had defined some SIG_FOO macros that appear in the code, but that are
not supported on Windows, in order to make the code compile. But a
subsequent change will assert that a signal number is non-zero. We now
use the signal numbers that are commonly used on POSIX systems.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
compat/mingw.h | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 4f275cb..a255898 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -21,12 +21,12 @@ typedef int pid_t;
#define WEXITSTATUS(x) ((x) & 0xff)
#define WIFSIGNALED(x) ((unsigned)(x) > 259)
-#define SIGKILL 0
-#define SIGCHLD 0
-#define SIGPIPE 0
-#define SIGHUP 0
-#define SIGQUIT 0
-#define SIGALRM 100
+#define SIGHUP 1
+#define SIGQUIT 3
+#define SIGKILL 9
+#define SIGPIPE 13
+#define SIGALRM 14
+#define SIGCHLD 17
#define F_GETFD 1
#define F_SETFD 2
--
1.6.1.rc4.959.gcece.dirty
^ permalink raw reply related
* Re: [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Junio C Hamano @ 2009-01-12 10:07 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580901120104u418d8d73mad4ab7d71fe8c3f8@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> On Mon, Jan 12, 2009 at 04:15, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> When the user explicitly asks you to traverse into submodules and the
>> necessary commit is not available in a submodule, the code goes on without
>> complaining. I am not saying it is bad, but I wonder if we would want to
>> distinguish these three cases:
>>
>> (1) the submodule is initialized and the necessary commit is there.
>>
>> (2) the submodule is initialized, but the necessary commit is missing.
>>
>> (3) the submodule is not even initialized (aka "the user is not
>> interested in it"); there is only an empty directory.
>>
>> I think it is perfectly fine not to say anything for (3) but I am unsure
>> about the second case.
>
> Do we want to impose the porcelainish rules of git-submodule
> (.gitmodules, .git/config) in read_tree_recursive()?
>
> If so, I guess a new submodule.h might provide something like this
> (disclaimer: coded in gmail):
I do not see why you would need anything more than we already have to tell
(3) from (1) and (2). And I do not see why you need to have the Porcelain
policy in the picture for telling these three cases apart, either.
For example, there is this code in read-cache.c::ce_compare_gitlink():
static int ce_compare_gitlink(struct cache_entry *ce)
{
unsigned char sha1[20];
/*
* We don't actually require that the .git directory
* under GITLINK directory be a valid git directory. It
* might even be missing (in case nobody populated that
* sub-project).
*
* If so, we consider it always to match.
*/
if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
return 0;
return hashcmp(sha1, ce->sha1);
}
It asks resolve_gitlink_ref() to see if the directory (where the submodule
checkout _might_ be present if the user is interested in it) has .git/HEAD
that resolves. If so, the user has a checkout and is interested in it.
Otherwise, there is no checkout, in other words, we have case (3) above.
Whether you force the user to link the submodule object store to the
primary one as alternates, or do that for the user temporarily inside the
process [*1*], you would then be able to tell (1) and (2) apart by asking
has_sha1_file() if you can see the commit.
One thing that is unclear is to me is for whom the commit is missing (or
present). I think the outline I gave above follows the design of your
patch to assume that the commit may (or may not) be available to the
superproject and traverse into the commit when that is the case. It does
not mean the commit is available to the submodule itself (the commit may
have found in the primary project itself, not via the alternates), but
such an arrangement makes it somewhat useless.
What's the typical direction of using alternates in a setting with
superproject with a submodule? Do people have alternates in the submodule
repository that borrows from the superproject repository? Or the other
way around? What's the rationale for having such alternates for normal
use case? I am suspecting that there is no reason (other than this
"recursive tree traversal") to have an alternates file in either
direction, but I also strongly suspect that I am missing some unwritten
assumption you are making.
[Footnote]
*1* If you want to recurse seemlessly, it might make sense to add (during
the course of this "recursive tree traversal") the object store of the
submodule repository to the process'es list of alternate object databases
yourself, instead of forcing the user to do so permanently by mucking with
the alternates list of the primary project repository. But that is an
independent issue.
^ permalink raw reply
* Re: patches in context format ?
From: Christian MICHON @ 2009-01-12 9:57 UTC (permalink / raw)
To: Jeff King; +Cc: git list
In-Reply-To: <20090112095250.GB3079@coredump.intra.peff.net>
On Mon, Jan 12, 2009 at 10:52 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 12, 2009 at 10:00:11AM +0100, Christian MICHON wrote:
>
>> The current solution I have is to use the original patch command,
>> stage modifications and add new files. I do not like this solution,
>> because I have to work out the commit messages out of the mbox and I
>> lose reproducibility. I'm basically maintaining a subset of shell
>> scripts, the original patches and an artificial way (ugly) to get
>> timestamps of modifications (for the commit dates).
>>
>> Instead of this complicated procedure, I'd like to use "git apply" or
>> "git am", provided I can get git to support "context output format" as
>> input for patches ?
>
> Maybe this is not the nicest solution if you are going to apply a lot of
> these patches, but you can pick up where git-am fails, run patch, and
> ask it to resume:
>
> $ git am mbox-with-context-diff
> Applying: a minor change
> error: No changes
> Patch failed at 0001.
> When you have resolved this problem run "git am --resolved".
> If you would prefer to skip this patch, instead run "git am --skip".
> To restore the original branch and stop patching run "git am --abort".
>
> $ patch <.git/rebase-apply/patch ;# or whatever
> $ git add -u
> $ git am -r
> Applying: a minor change
>
> -Peff
>
vim patches are in hundredth... so I guess this is too manual.
Thanks for the suggestion!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: patches in context format ?
From: Christian MICHON @ 2009-01-12 9:53 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git list
In-Reply-To: <871vv8rhpz.fsf@iki.fi>
On Mon, Jan 12, 2009 at 10:34 AM, Teemu Likonen <tlikonen@iki.fi> wrote:
> Christian MICHON (2009-01-12 10:00 +0100) wrote:
>
>> is there another way to translate from "context" to "unified" format ?
>
> Well, this is not exactly the best solution for a Vim user but this is
> the only way I know. Emacs can convert diffs between the formats. You
> don't even need to launch Emacs, just run it in batch mode:
>
> $ emacs --batch -Q --file input.diff \
> --eval '(diff-context->unified (point-min) (point-max))' \
> --eval '(save-buffer)'
>
you're asking a vim user to use emacs ? ;-)
thanks for the suggestion: I'll try it at least, but I think I'll
stick to interdiff.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: patches in context format ?
From: Jeff King @ 2009-01-12 9:52 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db660901120100g7f62a0c2k68c96cbfc23dab5@mail.gmail.com>
On Mon, Jan 12, 2009 at 10:00:11AM +0100, Christian MICHON wrote:
> The current solution I have is to use the original patch command,
> stage modifications and add new files. I do not like this solution,
> because I have to work out the commit messages out of the mbox and I
> lose reproducibility. I'm basically maintaining a subset of shell
> scripts, the original patches and an artificial way (ugly) to get
> timestamps of modifications (for the commit dates).
>
> Instead of this complicated procedure, I'd like to use "git apply" or
> "git am", provided I can get git to support "context output format" as
> input for patches ?
Maybe this is not the nicest solution if you are going to apply a lot of
these patches, but you can pick up where git-am fails, run patch, and
ask it to resume:
$ git am mbox-with-context-diff
Applying: a minor change
error: No changes
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
$ patch <.git/rebase-apply/patch ;# or whatever
$ git add -u
$ git am -r
Applying: a minor change
-Peff
^ permalink raw reply
* Re: patches in context format ?
From: Christian MICHON @ 2009-01-12 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vy6xgj2jq.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 12, 2009 at 10:28 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I guess the answer is no, but has anyone on the list been working on
>> this ? is there another way to translate from "context" to "unified"
>> format ?
>
> Not that I know of.
>
> If you want to add support for the copied context format patches to your
> workflow, I think the first step (and easiest one) would be to find an
> external program that lets you convert from the copied context format to
> the unified context format. Perhaps "interdiff /dev/null copied >unified"
> would suffice (but I haven't tested this).
>
interdiff is exactly what I needed (I used -p and -q switches, plus a
substitution for the path).
Thanks for this! I guess there's not really a need to add this now in
git-am, since I've seldom seen such context patches.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [RFC PATCH 1/3] Add "vcs" config option in remotes
From: Bert Wesarg @ 2009-01-12 9:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110332580.19665@iabervon.org>
On Sun, Jan 11, 2009 at 21:12, Daniel Barkalow <barkalow@iabervon.org> wrote:
> diff --git a/builtin-push.c b/builtin-push.c
> index 122fdcf..3fdedba 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -53,6 +53,9 @@ static int do_push(const char *repo, int flags)
> int i, errs;
> struct remote *remote = remote_get(repo);
>
> + if (remote->foreign_vcs)
> + die("Pushing with foreign VCSes not supported.");
> +
> if (!remote)
> die("bad repository '%s'", repo);
>
Use of remote before NULL check.
Bert
^ permalink raw reply
* Re: [RFC/PATCH 2/3] replace_object: add mechanism to replace objects found in "refs/replace/"
From: Jakub Narebski @ 2009-01-12 9:50 UTC (permalink / raw)
To: Tim Ansell; +Cc: git
In-Reply-To: <1231727868.6716.155.camel@vaio>
On Mon, 12 Jan 2009, Tim 'mithro' Ansell wrote:
> > I just had an idea: we can use this mechanism to better manage large
> > binary files in Git, by using replacements for _blobs_.
> >
> > We want to be able to have two flavours of repository: one with large
> > blobs (media files usually), and one without. We can use stubs in the
> > place of large binary files in 'no-megablobs' flavor, and add contents
> > of those files via refs/replace/* for _blobs_ in 'with-megablobs'
> > flavour. We can control which objects we want to have, and which
> > objects to transfer.
> >
> > What do you think about this (abuse of) an idea?
>
> I'm not sure I understand. I don't really care much about the
> implementation details if it's transparent to the user :)
>
> I have not really had much time to pursue my idea of getting sha1_file
> to read download blob on an as-needed basis (work has been hectic).
Actually this idea is a bit different from lazy / on demand downloading
of large blobs.
In "on demand loading" solution you have sha-1 of _full_ blob in a tree,
but git knows that not having it is not a fatal error (somehow), and you
can ask git to download it. This is as far as I understand the solution
you proposed and partially implemented.
In "replacement blobs" solution, the (ab)use of object replacement
mechanism meant originally for easier bisect, you have sha-1 of _stub_
object in a tree. If you want full (large) blob, you add replacement
in refs/replace/*, replacing stub blob object (must be unique; it can
for example contain some header + sha-1 of full object) with full
object. If you want to have large object, you need to transfer
refs/replace/*. This solution means that user needs to be aware of
this mechanism, or have some wrapper (script) around it.
Different solution, and a bit different behavior wrt getting large
object for the user.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/4] color-words: refactor to allow for 0-character word boundaries
From: Junio C Hamano @ 2009-01-12 9:36 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Schindelin, git
In-Reply-To: <200901120947.13566.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> These remarks aside (and the last one is the only one of relevance to
> the code), this patch would be a vast improvement of the code even if
> we weren't discussing it in the context of the regex feature. So FWIW
>
> Acked-by: Thomas Rast <trast@student.ethz.ch>
>
> up to here. I hope we can agree on some sane regex semantics for
> 4/4...
Ok, although I've already queued your series to 'pu' for the night, I'll
drop and replace it with the one from Dscho. After a few more iteration
hopefully we can get it into a reasonable shape.
Thanks, both.
^ permalink raw reply
* Re: grammar patches not best use of talent
From: Junio C Hamano @ 2009-01-12 9:35 UTC (permalink / raw)
To: jdelstrother; +Cc: jidanni, git
In-Reply-To: <57518fd10901120054o5fbe78f8he0a54f6d62216ad5@mail.gmail.com>
jdelstrother@gmail.com writes:
> Wait, "a handful X" is now a legitimate form of "a handful of X"? I
> assumed they were due to non-native speakers.
You assumed correctly.
Jidanni is saying that _he_ thought about doing so, and then changed his
mind. I personally do not know what the point of saying such things on
the public list like this: you either just do it, or you don't, and you do
not add noise to the traffic by saying you won't do this nor that.
If you agree with me on the above point, just ignore the message you are
responding to (I am not saying "just ignore _him_"; at least not yet), and
if you are inclined to help, please don't let the message you are
responding to discourage you.
Thanks.
^ permalink raw reply
* Re: patches in context format ?
From: Teemu Likonen @ 2009-01-12 9:34 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db660901120100g7f62a0c2k68c96cbfc23dab5@mail.gmail.com>
Christian MICHON (2009-01-12 10:00 +0100) wrote:
> is there another way to translate from "context" to "unified" format ?
Well, this is not exactly the best solution for a Vim user but this is
the only way I know. Emacs can convert diffs between the formats. You
don't even need to launch Emacs, just run it in batch mode:
$ emacs --batch -Q --file input.diff \
--eval '(diff-context->unified (point-min) (point-max))' \
--eval '(save-buffer)'
^ 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