Re: Where should git-prompt.sh be installed?
Would that not give the impression of git sh-prompt being a core command? If so, that would be poor, IMHO. When I was investigating this last night, I expected to find it (git-prompt.sh) in contrib, although that doesn't make an enormous amount of sense. Ideally, the full path to wherever it's installed should be mentioned in the bash completion file (which is where I went to look when __git_ps1 stopped working), but that would mean modifying a file from upstream and I'm not sure if that's easy/the done thing. Danny. On 25 Oct 2012, at 01:51, Jonathan Nieder jrnie...@gmail.com wrote: Hi, In olden days the admin would copy contrib/completion/git-completion.sh to /etc/bash_completion.d/git and mortals could source /etc/bash_completion or /etc/bash_completion.d/git in their ~/.bashrc (possibly shared among multiple machines) so that the bash completion and __git_ps1 helpers could work. With Git 1.7.12 __git_ps1 has been split into a separate file, to help users who only want __git_ps1 to avoid the overhead of loading the entire completion script (and allow the completion script to be loaded by bash-completion magic on the fly!). Now the sysadmin should copy contrib/completion/git-completion.sh to /usr/share/bash-completion/completions/git and contrib/completion/git-prompt.sh to /usr/share/git-core/contrib/?? (somewhere?) Mortals source /etc/bash_completion in their ~/.bashrc (possibly shared among multiple machines) and expect bash completion to work. For __git_ps1, users should source that ?? path. Questions: 1) what path is appropriate for ?? above? 2) is this documented anywhere? Possible answers: 1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses /usr/share/bash-completion/git-prompt. Maybe others use some other path. 2) The scripts themselves suggest copying to ~/.git-completion.sh and ~/.git-prompt.sh. Proposal: 1) /usr/lib/git-core/git-sh-prompt 2) git-sh-prompt(1) Sensible? Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This works just fine. Go ahead, apply my patch, and run it, the second
branch gets updated.
Yes, but as you said:
That is already the case, my patch will cause this to generate the same
output:
% git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
Which is still not got, but not catastrophic by any means.
Which is exactly the reason we (Dscho and I during our little
hackathon) went with the approach we did. We considered the approach
you took (if I still had the repository I might even find something
very like your patch in my reflog), but dismissed it for that reason.
By teaching fast-export to properly re-export interesting refs, this
exporting of negated refs does not happen. Additionally, you say it is
not catastrophic, but it _is_, if you run: 'git fast-export ^master
foo', you do not expect master to suddenly show up on the remote side.
I agree that your test more accurately describes what we're testing
(and in fact, it should probably go in the tests for remote helpers).
However, this test points out a shortcoming of fast-export that
prevents us from implementing a cleaner solution to the 'fast-export
push an existing ref' problem.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 8:07 AM, Sverre Rabbelier srabbel...@gmail.com wrote:
On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This works just fine. Go ahead, apply my patch, and run it, the second
branch gets updated.
Yes, but as you said:
That is already the case, my patch will cause this to generate the same
output:
% git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
Which is still not got, but not catastrophic by any means.
Which is exactly the reason we (Dscho and I during our little
hackathon) went with the approach we did. We considered the approach
you took (if I still had the repository I might even find something
very like your patch in my reflog), but dismissed it for that reason.
By teaching fast-export to properly re-export interesting refs, this
exporting of negated refs does not happen.
Oh really? This is with your patches:
% git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
reset refs/heads/foo1
from :21
reset refs/heads/foo3
from :21
reset refs/heads/foo3
from :21
reset refs/heads/foo2
from :21
This is with mine:
% ./git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
reset refs/heads/foo3
from :21
reset refs/heads/foo2
from :21
reset refs/heads/foo1
from :21
Now tell me again. What is the benefit of your approach?
Additionally, you say it is
not catastrophic, but it _is_, if you run: 'git fast-export ^master
foo', you do not expect master to suddenly show up on the remote side.
If 'git fast-export ^master foo' is catastrophic, so is 'git
fast-export foo ^master', and that already exports master *today*.
I agree that your test more accurately describes what we're testing
(and in fact, it should probably go in the tests for remote helpers).
However, this test points out a shortcoming of fast-export that
prevents us from implementing a cleaner solution to the 'fast-export
push an existing ref' problem.
Which is something few users will notice. What they surely notice is
that there's no remote-hg they can readily use. Nobody expects all
software to be perfect or have all the features from day 1. Something
that just fetches a hg repo is already better than the current
situation: *nothing*.
And BTW, in mercurial a commit can be only on one branch anyway, so
you can't have 'foo' and 'master' both pointing to the same
commit/revision. Sure bookmarks is another story, but again, I don't
think people would prefer remote-hg to stay out because bookmarks
don't work _perfectly_.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 7:53 AM, Jonathan Nieder jrnie...@gmail.com wrote: Felipe Contreras wrote: All right, so I run this and get this: % git fast-export master..master reset refs/heads/master from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0 As an user of fast-export, what do I do with that now? You passed master.. on the command line, indicating that your repository already has commit 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0. No I didn't. Maybe I'm not interested in all the old history and I just want to create a repository from that point forward. For example 'git fast-export v1.5.0..master. I don't want no references to objects I don't have, there's no way I can do anything sensible with that SHA-1. % git fast-export master..master | git --git-dir=/tmp/git/.git fast-import fatal: Not a valid commit: 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0 fast-import: dumping crash report to /tmp/git/.git/fast_import_crash_32498 Does it make sense to you that the output of fast-export doesn't work with fast-import? Now you can update the master branch to point to that commit, as the fast-export output indicates. I don't have that commit, I don't even know what 8c7a786 means. Show me a single remote helper that manually stores SHA-1's and I might believe you, but I doubt that, marks are too convenient. Or show me a script. I doubt there will be any, because otherwise somebody would have pushed for this patch, and there doesn't seem to be too many people. But fine, lets assume it's a valid use-case and people need this... it still has absolutely nothing to do with the original intent of the patch series. The series is in fact doing two things: 1) Use SHA-1's when a mark can't be found 2) Update refs that have been already visited (through marks) These two things are orthogonal to each other, we should have two tests, and in fact, two separate patch series. One will be useful for remote helpers, the other one will be useful to nobody IMO, but that's something that can be discussed there, and I particularly don't care. My test and my patch are good for 2), and so far I haven't seen anybody saying otherwise. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Who is the 'git' vendor?
Hi, The organisation I am currently working for uses 'git'. In order to manage all the software used in the organisation we have been compiling a list of software that includes the software Vendor's name. My colleague has listed the vendor of git as being the 'Software Freedom Conservancy'. Can you please advise me if this is correct? If not, who should the vendor be identified as? Regards, Thor Thor Prohaska Test Coordinator - Desktop Anywhere Enterprise Engineering BT, 3/300 Queen St, Brisbane Desk Phone: 07 3362 1809 Mobile: 0419 344 806 This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities Suncorp. Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
On Wed, Oct 24, 2012 at 11:19 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Oh really? This is with your patches:
% git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
reset refs/heads/foo1
from :21
reset refs/heads/foo3
from :21
reset refs/heads/foo3
from :21
reset refs/heads/foo2
from :21
That's weird, we have this bit:
+ if (elem-whence != REV_CMD_REV elem-whence !=
REV_CMD_RIGHT)
+ continue;
If I understand correctly that should cause it to only output revs
(e.g. 'foo1') and the rhs side of a have..want spec.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
Felipe Contreras wrote: Show me a single remote helper that manually stores SHA-1's and I might believe you, but I doubt that, marks are too convenient. Oh dear lord. Why are you arguing? Explain how coming to a consensus on this will help accomplish something useful, and then I can explain my point of view. In the meantime, this seems like a waste of time. Let's agree to disagree. Regards, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
Sverre Rabbelier wrote:
That's weird, we have this bit:
+ if (elem-whence != REV_CMD_REV elem-whence !=
REV_CMD_RIGHT)
+ continue;
If I understand correctly that should cause it to only output revs
(e.g. 'foo1') and the rhs side of a have..want spec.
If I remember right, '^foo1' is (whence == REV_CMD_REV) with (flags ==
UNINTERESTING). That's why sequencer.c checks for unadorned revs like
this:
if (opts-revs-cmdline.nr == 1
opts-revs-cmdline.rev-whence == REV_CMD_REV
opts-revs-no_walk
!opts-revs-cmdline.rev-flags) {
Maybe
if (elem-flags UNINTERESTING)
continue;
if (elem-whence == REV_CMD_PARENTS_ONLY) /* foo^@ */
continue;
would work well here? That would handle bizarre cases like --not
next..master (and ordinary cases like master...next) better, by
focusing on the semantics instead of syntax.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 12:34 AM, Jonathan Nieder jrnie...@gmail.com wrote:
If I remember right, '^foo1' is (whence == REV_CMD_REV) with (flags ==
UNINTERESTING). That's why sequencer.c checks for unadorned revs like
this:
if (opts-revs-cmdline.nr == 1
opts-revs-cmdline.rev-whence == REV_CMD_REV
opts-revs-no_walk
!opts-revs-cmdline.rev-flags) {
Maybe
if (elem-flags UNINTERESTING)
continue;
if (elem-whence == REV_CMD_PARENTS_ONLY) /* foo^@ */
continue;
would work well here? That would handle bizarre cases like --not
next..master (and ordinary cases like master...next) better, by
focusing on the semantics instead of syntax.
I know there was a reason why using UNINTERESTING didn't work
(otherwise we could've used that to start with, instead of needing
Junio's whence solution). I think all refs ended up being marked as
UNINTERESTING or somesuch.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] __git_ps1: migrate out of contrib/completion
Different installers put the git-prompt.sh shell library at different
places on the installed system, so there is no shared location users
can count on:
Fedora - /etc/profile.d/git-prompt.sh
Gentoo - /usr/share/bash-completion/git-prompt
Arch - /usr/share/git/git-prompt.sh
The __git_ps1 helper doesn't have anything to do with bash completion
in principle, but because it was written in the context of that
project, its sources are kept in contrib/completion/git-prompt.sh.
Let's make it a first-class shell library in the toplevel and install
it to $(gitexecdir) alongside git-sh-setup and git-sh-i18n, where it
can be easily found.
Keep a symlink in contrib/completion/ to avoid breaking setups where
this library is used directly from the source tree.
Now you can put the following in your ~/.bashrc:
if test ${BASH+set} test ${PS1+set} # interactive!
then
gitexecdir=$(git --exec-path)
if test -r $gitexecdir/git-sh-prompt)
then
. $gitexecdir/git-sh-prompt
fi
if type -t __git_ps1 /dev/null
then
PS1='\w$(__git_ps1)\$ '
fi
fi
and the shell prompt will show the current branch name in git
repositories when on a machine with a new enough version of git.
Reported-by: Danny Yates mail4da...@googlemail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Danny Yates wrote:
Would that not give the impression of git sh-prompt being a core
command? If so, that would be poor, IMHO.
Not any more than $(git --exec-path)/git-sh-setup and git-sh-i18n. :)
When I was investigating this last night, I expected to find it
(git-prompt.sh) in contrib, although that doesn't make an enormous
amount of sense. Ideally, the full path to wherever it's installed
should be mentioned in the bash completion file (which is where I
went to look when __git_ps1 stopped working),
Yes, certainly.
but that would mean
modifying a file from upstream and I'm not sure if that's easy/the
done thing.
We're talking on the upstream list now, so that's not an issue.
Thanks,
Jonathan
Documentation/git-sh-prompt.txt| 79 ++
Makefile | 1 +
contrib/completion/git-completion.bash | 2 +-
contrib/completion/git-prompt.sh | 291 +
.../completion/git-prompt.sh = git-sh-prompt.sh | 0
5 files changed, 82 insertions(+), 291 deletions(-)
create mode 100644 Documentation/git-sh-prompt.txt
rewrite contrib/completion/git-prompt.sh (100%)
mode change 100644 = 12
rename contrib/completion/git-prompt.sh = git-sh-prompt.sh (100%)
diff --git a/Documentation/git-sh-prompt.txt b/Documentation/git-sh-prompt.txt
new file mode 100644
index ..2c705fef
--- /dev/null
+++ b/Documentation/git-sh-prompt.txt
@@ -0,0 +1,79 @@
+git-sh-prompt(1)
+
+
+NAME
+
+git-sh-prompt - Functions to describe repository in bash or zsh prompt
+
+SYNOPSIS
+
+[verse]
+'. $(git --exec-path)/git-sh-prompt'
+
+DESCRIPTION
+---
+This script allows you to see the current branch in your bash prompt.
+
+To enable:
+
+1. Add the following line to your .bashrc and .zshrc:
+
+ . $(git --exec-path)/git-sh-prompt
+
+2. Change your PS1 to also show the current branch:
+
+ Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
+ Zsh: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+
+The argument to __git_ps1 will only be displayed if you are currently
+in a git repository. The %s token is replaced by the name of the current
+branch.
+
+In addition, if you set GIT_PS1_SHOWDIRTYSTATE to a nonempty value,
+unstaged (`*`) and staged (`+`) changes are indicated next to the branch
+name. You can configure this per repository with the `bash.showDirtyState`
+variable, which defaults to `true` once GIT_PS1_SHOWDIRTYSTATE is enabled.
+
+You can also see if something is currently stashed, by setting
+GIT_PS1_SHOWSTASHSTATE to a nonempty value. If something is stashed,
+then a '$' is shown next to the branch name.
+
+If you would like to see if there are untracked files, set
+GIT_PS1_SHOWUNTRACKEDFILES to a nonempty value. If there are untracked
+files, a '%' is shown next to the branch name.
+
+If you would like to see the difference between HEAD and its upstream,
+set GIT_PS1_SHOWUPSTREAM=auto. A '' indicates the current branch is
+behind, '' indicates it is ahead, '' indicates it has diverged, and
+'=' indicates no difference. You can further control behavior by
+setting GIT_PS1_SHOWUPSTREAM to a space-separated list of values:
+
+verbose::
+ show number of commits ahead of/behind (+/-) upstream
+legacy::
+ don't use the '--count' option available in recent versions
+ of git-rev-list
+git::
+ always compare HEAD to `@{upstream}`
+svn::
+ always compare HEAD
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
Sverre Rabbelier wrote: I know there was a reason why using UNINTERESTING didn't work (otherwise we could've used that to start with, instead of needing Junio's whence solution). I think all refs ended up being marked as UNINTERESTING or somesuch. True. Is it be possible to check UNINTERESTING in revs-cmdline before the walk? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: signing commits with openssl/PKCS#11
On Mon, Oct 22, 2012 at 6:38 AM, Mat Arge argemat1...@gmail.com wrote: Hy! I would like to sign each commit with a X.509 certificate and a private key stored on a PKCS#11 token. I assume that that should be possible somehow using a hook which calls openssl. Does somebody know a working implementation of this? Creating signatures from an rsa key on a pkcs11 token should be possible, but gnupg doesn't support pkcs11 for philosophical reasons. You need to use gnupg-pkcs11 which is maintained outside of the gnupg tree. Once you configure gnupg-pkcs11-scd, you'll be able to use git and gpg to sign tags as usual. I configured this a while back for use with CAC cards using the following resources: http://alpha.uwb.edu.pl/map/eToken_gpg_howto.shtml (dead) http://alpha.uwb.edu.pl/amicke/eToken_gpg_howto.shtml (replacement for above?) http://gnupg-pkcs11.sourceforge.net/man.html Try those docs. If you have questions, I'll try to find my notes. -Brandon -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Where should git-prompt.sh be installed?
On 10/25/2012 02:02 AM, Danny Yates wrote: Would that not give the impression of git sh-prompt being a core command? No more than git-sh-setup, which already works like that. Unless perhaps by “core” you mean “not contrib”. (Now that I think of it, I saw a request from an Ubuntu PPA user last week to install git-subtree in a more accessible location, and there’s a similar request about gitview at https://bugs.launchpad.net/bugs/152212 . These are less critical since the Debian package puts them in /usr/share/doc/git/contrib. Is it a good idea to package those somewhere like /usr/lib/git-core or /usr/bin, or is that a dangerous slippery slope? I dunno.) Anders -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is git mktag supposed to accept git cat-file input?
Anand Kumria venit, vidit, dixit 25.10.2012 02:58: Ahh, unix time. Of course. That's the only difference *at the time being*, but this is not guaranteed. Really, as Brandon says: cat-file -p is pretty printing for human readability (which could be improved), and cat-file type is the raw format which is the content being hashed to the sha1. Thanks Brandon. On 25 October 2012 01:18, Brandon Casey draf...@gmail.com wrote: On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria akum...@acm.org wrote: Hi, I am doing some experimenting with git-mktag, and was looking into the format it expects on input. Should this sequence of commands work? Yes, with a slight tweak... kalki:[/tmp/gittest]% git tag -m tag-test tag-test kalki:[/tmp/gittest]% git cat-file -p e619 '-p' means pretty-print, i.e. produce a human-readable format. mktag supports the raw format. So you should invoke it like this: $ git cat-file tag e619 which should produce something like: object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5 type commit tag tag-test tagger Anand Kumria akum...@acm.org 1351121552 +0100 tag-test and is the format expected by mktag. -Brandon -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixes handling of --reference argument.
On Wed, Oct 24, 2012 at 09:52:52PM -0700, sza...@google.com wrote: Signed-off-by: Stefan Zager sza...@google.com --- git-submodule.sh |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh index ab6b110..dcceb43 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -270,7 +270,6 @@ cmd_add() ;; --reference=*) reference=$1 - shift ;; Is that right? We'll unconditionally do a shift at the end of the loop. If it were a two-part argument like --reference foo, the extra shift would make sense, but for --reference=*, no extra shift should be neccessary. Am I missing something? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9401 fails with OS X sed
On Thu, Oct 25, 2012 at 01:04:11AM -0400, Geert Bosch wrote: On Oct 24, 2012, at 23:54, Brian Gernhardt br...@gernhardtsoftware.com wrote: It works if I change \s to [[:space:]], but I don't know how portable that is. As \s is shorthand for the POSIX character class [:space:], I'd say the latter should be more portable: anything accepting the shorthand should also accept the full character class. If not, you probably only care about horizontal tab and space, for which you could just use a simple regular expression. Just a literal space and tab character between square brackets is probably going to be most portable, though not most readable. I agree that the POSIX character class would be more portable than \s, but we do not have any existing uses of them, and I would worry a little about older systems like Solaris. If we can simply use a literal space and tab, that seems like the safest. Brian, can you work up a patch? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Who is the 'git' vendor?
On 10/25/2012 08:43 AM, PROHASKA, Thor wrote: Hi, The organisation I am currently working for uses 'git'. In order to manage all the software used in the organisation we have been compiling a list of software that includes the software Vendor's name. My colleague has listed the vendor of git as being the 'Software Freedom Conservancy'. Can you please advise me if this is correct? If not, who should the vendor be identified as? Most likely, you'll want to put git@vger.kernel.org as vendor for git, as the whole vendor concept doesn't really fly with FOSS. There's noone to go to if it breaks your systems, and unless you purchase a support contract from somewhere there's noone to turn to except the (excellent) git community in case you have issues with it. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
On Wed, Oct 24, 2012 at 11:08:26PM +0200, Krzysztof Mazur wrote:
ok, I'm sending a version that just adds quote_subject() without
changing any logic, so now we still have in first case:
/[^[:ascii:]]/
and in the latter case:
!is_rfc2047_quoted($subject) /^[:ascii:]]/
In the next patch I will just add matching for =? in
subject_needs_rfc2047_quoting() and we will have:
/=?/ || /[^[:ascii:]]/
and in the latter case:
!is_rfc2047_quoted($subject) (/=\?/ || /^[:ascii:]]/)
This will also add quoting for any rfc2047 quoted subject or any
other rfc2047-like subject, as you suggested.
Thanks, the two-patch series you outline makes a lot of sense to me.
Krzysiek
--
From a70c5385f9b4da69a8ce00a1448f87f63bbd500d Mon Sep 17 00:00:00 2001
From: Krzysztof Mazur krzys...@podlesie.net
Date: Wed, 24 Oct 2012 22:46:00 +0200
Subject: [PATCH] git-send-email: introduce quote_subject()
When sending a patch following some cover letter material, please cut
out any non-essential headers and use the scissors symbol, like this:
-- 8 --
Subject: [PATCH] this subject overrides the whole email's subject
the regular body and diff go here...
That format is understood by git am and means I do not have to
manually munge it, which saves a little work.
+sub quote_subject {
+ local $subject = shift;
+ my $encoding = shift || 'UTF-8';
+
+ if (subject_needs_rfc2047_quoting($subject)) {
+ return quote_rfc2047($subject, $encoding);
+ }
+ return $subject;
+}
There is some funny whitespace here (space followed by tab).
- if ($broken_encoding{$t} !is_rfc2047_quoted($subject)
- ($subject =~ /[^[:ascii:]]/)) {
- $subject = quote_rfc2047($subject, $auto_8bit_encoding);
+ if ($broken_encoding{$t} !is_rfc2047_quoted($subject)) {
+ $subject = quote_subject($subject, $auto_8bit_encoding);
}
Hmm. What is this patch on top of? It looks like it is on top of your
original patch, but when I tried it on top of that, it does not apply
either, and the index lines in the patch do not mention a sha1 that I do
not have.
Do you mind re-rolling a final 2-patch series with:
1. Your original patch and this one squashed together, with an
appropriate commit message.
2. The second quote when we see '=?' patch.
Thanks.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: add rfc2047 quoting for =?
On Wed, Oct 24, 2012 at 11:28:29PM +0200, Krzysztof Mazur wrote: For raw subjects rfc2047 quoting is needed not only for non-ASCII characters, but also for any possible rfc2047 in it. [...] - return ($s =~ /[^[:ascii:]]/); + return ($s =~ /[^[:ascii:]]/) || ($s =~ /=\?/); Very nice and obvious bug-fix made easy by the previous refactoring. :) --- Oops, this ugly Subject was generated by git format-patch (both 1.8.0 and km/send-email-compose-encoding). Yeah, format-patch has the same behavior (to encode when we see =?). So we know it is working. It is perhaps overkill in this case, since there is not technically a valid encoded-word, and a smart parser would be able to see that it should leave it alone. But it is probably better to be slightly conservative in what we generate (and the =? token is unlikely to come up in day-to-day usage). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Who is the 'git' vendor?
On Thu, Oct 25, 2012 at 10:52:44AM +0200, Andreas Ericsson wrote: On 10/25/2012 08:43 AM, PROHASKA, Thor wrote: Hi, The organisation I am currently working for uses 'git'. In order to manage all the software used in the organisation we have been compiling a list of software that includes the software Vendor's name. My colleague has listed the vendor of git as being the 'Software Freedom Conservancy'. Can you please advise me if this is correct? If not, who should the vendor be identified as? Most likely, you'll want to put git@vger.kernel.org as vendor for git, as the whole vendor concept doesn't really fly with FOSS. There's noone to go to if it breaks your systems, and unless you purchase a support contract from somewhere there's noone to turn to except the (excellent) git community in case you have issues with it. Yeah. Depending on the purpose of the list, I would probably _not_ put the SFC. They help manage the legal and financial aspects of the git project, but they have nothing at all to do with the code itself. I would hate for them to get a phone call about support. :) Probably The Git Community or git@vger.kernel.org is the best thing to fill in if you need to write something in a form. If there ends up being some specific reason for a vendor to be contacted, folks on the list will be able to point an inquiry in the right direction (which might even end up being the SFC). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: signing commits with openssl/PKCS#11
On Wednesday 24. October 2012 11:46:15 Michael J Gruber wrote: Mat Arge venit, vidit, dixit 22.10.2012 15:38: Hy! I would like to sign each commit with a X.509 certificate and a private key stored on a PKCS#11 token. I assume that that should be possible somehow using a hook which calls openssl. Does somebody know a working implementation of this? cheers Mat In principle, we have an almost pluggable architecture. See for example the latter part of the 2nd post in http://article.gmane.org/gmane.comp.version-control.git/175127 Unless you want to change git itself, you're probably better off storing your non-gpg signatures in a note (or a self-created signed tag). So, there is no possibility to modify the commit itself via a hook, and add a, say, opensslsig instead of a gpgsig tag? To sign the commit rev, you could sign the output of git cat-file commit rev (or of git rev-parse rev) and store that signature in a note that commit. To verify, you verify the note against the commit. Michael But if I crete/modify a signature file while commiting, that file wouldn't be commited itself, so the signatur-file would always be one commit behind. Or am I missing something? I'm quite new to git (or DVCSs in general), so sorry if this is a dumb question. cheers Mat -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: signing commits with openssl/PKCS#11
On Thursday 25. October 2012 01:02:33 Brandon Casey wrote: On Mon, Oct 22, 2012 at 6:38 AM, Mat Arge argemat1...@gmail.com wrote: Hy! I would like to sign each commit with a X.509 certificate and a private key stored on a PKCS#11 token. I assume that that should be possible somehow using a hook which calls openssl. Does somebody know a working implementation of this? Creating signatures from an rsa key on a pkcs11 token should be possible, but gnupg doesn't support pkcs11 for philosophical reasons. You need to use gnupg-pkcs11 which is maintained outside of the gnupg tree. Once you configure gnupg-pkcs11-scd, you'll be able to use git and gpg to sign tags as usual. I configured this a while back for use with CAC cards using the following resources: http://alpha.uwb.edu.pl/map/eToken_gpg_howto.shtml (dead) http://alpha.uwb.edu.pl/amicke/eToken_gpg_howto.shtml (replacement for above?) http://gnupg-pkcs11.sourceforge.net/man.html Try those docs. If you have questions, I'll try to find my notes. -Brandon Thanks for the tip, I will try them (though the appear to be very outdated). Do you know, if gnupg-pkcs11-scd is able to cooperate with the standard pcscd from pcsc-lite, or is a one-or-the-other situation? cheers Mat -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] git-status: show short sequencer state
On Tue, Oct 23, 2012 at 04:02:54PM -0400, Phil Hord wrote:
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Introduce a common function to determine the current sequencer
state so the regular status function and this short version can
share common code.
Add a substate to wt_status_state to track more detailed
information about a state, such as conflicted or resolved.
Move the am_empty_patch flage out of wt_status_state and into
This patch ended up quite long. It might be a little easier to review
if it were broken into refactoring steps (I have not looked at it too
closely yet, but it seems like the three paragraphs above could each be
their own commit).
State token strings which may be emitted and their meanings:
merge a git-merge is in progress
am a git-am is in progress
rebase a git-rebase is in progress
rebase-interactive a git-rebase--interactive is in progress
A minor nit, but you might want to update this list from the one in the
documentation.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..9706ed9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN
+ STATUS_FORMAT_PORCELAIN,
+ STATUS_FORMAT_SEQUENCER
} status_format = STATUS_FORMAT_LONG;
Hmm. So the new format is its own distinct output format. I could not
say I would like to see short status, and by the way, show me the
sequencer state, as you can with -b. Is it possible to do this (or
even desirable; getting the sequencer state should be way cheaper, so
conflating the two may not be what some callers want).
Not complaining, just wondering about the intended use cases.
Also, does there need to be a --porcelain version of this output? It
seems like we can have multiple words (e.g., in a merge, with conflicted
entries). If there is no arbitrary data, we do not have to worry about
delimiters and quoting. But I wonder if we would ever want to expand
the information to include arbitrary strings, at which point we would
want NUL delimiters; should we start with that now?
+ // Determine main sequencer activity
Please avoid C99 comments (there are others in the patch, too).
+void wt_sequencer_print(struct wt_status *s)
+{
+ struct wt_status_state state;
+
+ wt_status_get_state(s, state);
+
+ if (state.merge_in_progress)
+ wt_print_token(s, merge);
+ if (state.am_in_progress)
+ wt_print_token(s, am);
+ if (state.rebase_in_progress)
+ wt_print_token(s, rebase);
+ if (state.rebase_interactive_in_progress)
+ wt_print_token(s, rebase-interactive);
+ if (state.cherry_pick_in_progress)
+ wt_print_token(s, cherry-pick);
+ if (state.bisect_in_progress)
+ wt_print_token(s, bisect);
+
+ switch (state.substate) {
+ case WT_SUBSTATE_NOMINAL:
+ break;
+ case WT_SUBSTATE_CONFLICTED:
+ wt_print_token(s, conflicted);
+ break;
+ case WT_SUBSTATE_RESOLVED:
+ wt_print_token(s, resolved);
+ break;
+ case WT_SUBSTATE_EDITED:
+ wt_print_token(s, edited);
+ break;
+ case WT_SUBSTATE_EDITING:
+ wt_print_token(s, editing);
+ break;
+ case WT_SUBSTATE_SPLITTING:
+ wt_print_token(s, splitting);
+ break;
+ case WT_SUBSTATE_AM_EMPTY:
+ wt_print_token(s, am-empty);
+ break;
+ }
+}
It is clear from this code that some tokens can happen together, and
some are mutually exclusive. Should the documentation talk about that,
or do we want to literally keep it as a list of tags?
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] git-pull: Avoid merge-base on detached head
On Tue, Oct 23, 2012 at 04:39:56PM -0400, Phil Hord wrote: git pull --rebase does some clever tricks to find the base for $upstream , but it forgets that we may not have any branch at all. When this happens, git merge-base reports its usage help in the middle of an otherwise successful rebase operation, because git-merge is called with one too few parameters. Since we do not need the merge-base trick in the case of a detached HEAD, detect this condition and bypass the clever trick and the usage noise. Makes sense. I notice there is no test with your patch. It sounds from the description like the operation still may succeed, but we just get cruft on stderr? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 1/1] Wire html for all files in ./technical and ./howto in Makefile
On Tue, Oct 23, 2012 at 07:58:04PM +0200, Thomas Ackermann wrote: - target html creates html for all files in Documentation/howto and Documentation/technical Thanks. +TECH_DOCS = technical/index-format +TECH_DOCS += technical/pack-format +TECH_DOCS += technical/pack-heuristics +TECH_DOCS += technical/pack-protocol +TECH_DOCS += technical/protocol-capabilities +TECH_DOCS += technical/protocol-common +TECH_DOCS += technical/racy-git +TECH_DOCS += technical/send-pack-pipeline +TECH_DOCS += technical/shallow +TECH_DOCS += technical/trivial-merge +SP_ARTICLES += $(TECH_DOCS) I wonder if these could even be part of the generated api-index.html (that is, if somebody is reading about the API, they just as well may want to see these format documents). But I do not overly care much, as I (and I suspect most other developers) just read the technical documentation in its original txt format. If somebody cares, we can easily build it on top. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
On Tue, Oct 23, 2012 at 09:24:51AM +0700, Nguyen Thai Ngoc Duy wrote: These functions are called in sequencer.c, which is part of libgit.a. This makes libgit.a potentially require builtin/merge.c for external git commands. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- I made some unrelated changes in sequencer.c and this problem shown up. merge-recursive.c is probably not the best place for these functions. I just don't want to create merge.c for them. I'm fine with this conceptually, but merge-recursive really is the wrong place. I'd much rather see a new merge.c to collect merge-related helper functions that are not strategy-specific. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: remote tracking branch - remote-tracking branch
On Tue, Oct 23, 2012 at 01:34:05PM +0200, Matthieu Moy wrote: This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2 2010, Replace remote tracking with remote-tracking), but new instances of remote tracking (without dash) were introduced in the meantime. Thanks. It seems like an obvious step forward. I'm not opposed to dropping completely the remote-tracking part in the case of merge (i.e. remote-tracking branches that the current branch is configured to use as its upstream - upstream branch) on top of that, but if we do this, merge-config.txt should be updated too). Yeah, I do not care too deeply, but I think it reads just fine without mentioning remote-tracking at all. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix 'make test' for HP NonStop
On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote:
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need ${prefix}/bin in PATH first
+ SHELL_PATH=${prefix}/bin/bash
+ SANE_TOOL_PATH=${prefix}/bin
This feels a little too specific to go in our Makefile. Do we have any
reason to think that where you are installing git is going to be the
same place you have bash and other sane tools? Wouldn't this mean that
things work when you run make but mysteriously break when you run
make prefix=/my/local/install/of/git?
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
On Thu, Oct 25, 2012 at 05:01:49AM -0400, Jeff King wrote:
- if ($broken_encoding{$t} !is_rfc2047_quoted($subject)
- ($subject =~ /[^[:ascii:]]/)) {
- $subject = quote_rfc2047($subject, $auto_8bit_encoding);
+ if ($broken_encoding{$t} !is_rfc2047_quoted($subject)) {
+ $subject = quote_subject($subject, $auto_8bit_encoding);
}
Hmm. What is this patch on top of? It looks like it is on top of your
original patch, but when I tried it on top of that, it does not apply
either, and the index lines in the patch do not mention a sha1 that I do
not have.
Do you mind re-rolling a final 2-patch series with:
Ah, never mind. I missed your earlier use compose-encoding for
Subject. I've queued it and all of the follow-ons onto the
km/send-email-compose-encoding topic.
Thanks.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fix 'make test' for HP NonStop
From: Jeff King [mailto:p...@peff.net]
Sent: Thursday, October 25, 2012 11:58 AM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [PATCH] fix 'make test' for HP NonStop
On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote:
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need ${prefix}/bin in PATH first
+ SHELL_PATH=${prefix}/bin/bash
+ SANE_TOOL_PATH=${prefix}/bin
This feels a little too specific to go in our Makefile. Do we have any
reason to think that where you are installing git is going to be the
same place you have bash and other sane tools? Wouldn't this mean that
things work when you run make but mysteriously break when you run
make prefix=/my/local/install/of/git?
Well, make won't break (I think), but make test very well might.
Well, so far all OpenSource packages ported to HP NonStop (at least the ones on
ituglib.connect-community.org) use prefix=/usr/local and there is no intention
to change that.
A few (bash, vim, coreutils, tar, gzip, bzip2) get delivered with the system
meanwhile (rather than having to be downloaded and installed by the customer)
and live in /usr/corutiles. Still more are needed (e.g. diff , make).
The next lines in my patch cater for that, it is missing though an automatic
switch.
Such a switch would be possible, using 'uname -r' and 'uname -v', but pretty
convoluted
Pseudo code:
If (`uname -r` = J06 `uname -v` = 14) || (`uname -r`= H06 `uname -v` =
25)
SHELL_PATH=/usr/coreutils/bin/bash
SANE_TOOL_PATH=/usr/coreutils/bin:${prefix}/bin
else
SHELL_PATH=${prefix}/bin/bash
SANE_TOOL_PATH=${prefix}/bin
endif
I didn't deem it worth the effort. As mentioned it'd most likely still need
stuff from /usr/local/bin
And someone wanting prefix somewhere else could still do
PATH=/usr/local/bin:$PATH make prefix=/my/local/install/of/git
And so find what's need in either the 1st or 2nd path of PATH
Bye, Jojo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Doc format-patch: clarify --notes use case
On Sun, Oct 21, 2012 at 10:34:10PM +0100, Philip Oakley wrote: The expected use case of this is to write supporting explanation for -the commit that does not belong to the commit log message proper -when (or after) you create the commit, and include it in your patch -submission. But if you can plan ahead and write it down, there may -not be a good reason not to write it in your commit message, and if -you can't, you can always edit the output of format-patch before -sending it out, so the practical value of this option is somewhat -dubious, unless your workflow is broken. +the commit, that does not belong to the commit log message proper, +and include it with the patch submission. The notes can be maintained +between versions of the patch series. You can also edit the output of +format-patch before sending. I found the you can also slightly awkward here, as it was not clear why it was mentioned. I think the intent is this is an alternative that does not involve the notes workflow, but it is not clear from the text why you would prefer the notes workflow. Here is what I queued instead, which tires to clarify that, and also mentions that this workflow needs additional setup to track rewritten commits: diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 066dc8b..750b3fa 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -196,13 +196,12 @@ The expected use case of this is to write supporting explanation for after the three-dash line. + The expected use case of this is to write supporting explanation for -the commit that does not belong to the commit log message proper -when (or after) you create the commit, and include it in your patch -submission. But if you can plan ahead and write it down, there may -not be a good reason not to write it in your commit message, and if -you can't, you can always edit the output of format-patch before -sending it out, so the practical value of this option is somewhat -dubious, unless your workflow is broken. +the commit that does not belong to the commit log message proper, +and include it with the patch submission. While one can simply write +these explanations after `format-patch` has run but before sending, +keeping them as git notes allows them to be maintained between versions +of the patch series (but see the discussion of the `notes.rewrite.*` +configuration in linkgit:git-notes[1] to use this workflow). --[no]-signature=signature:: Add a signature to each message produced. Per RFC 3676 the signature I've queued that and your other patches on top of jc/prettier-pretty-note. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Doc User-Manual: Patch cover letter, three dashes, and --notes
On Sun, Oct 21, 2012 at 10:34:08PM +0100, Philip Oakley wrote: diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 85651b5..d918c53 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1787,6 +1787,11 @@ $ git format-patch origin will produce a numbered series of files in the current directory, one for each patch in the current branch but not in origin/HEAD. +`git format-patch` can include an initial cover letter. You can insert +a commentary on individual patches using a three dash line after the +commit message, and before the patch itself. `git format-patch --notes` +(v1.8.1) will include the commit's notes in the similar manner. I'd rather not mention a version number here, as we do not yet know which version (if any) will contain the feature. Besides, we write our documentation to match the current version, so as long as this is queued on top of the new code, I do not see any reason to mention a version at all. I'll tweak it while queueing. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Doc repository-layout: Show refs/replace
On Sun, Oct 21, 2012 at 09:52:37PM +0100, Philip Oakley wrote: Signed-off-by: Philip Oakley philipoak...@iee.org Thanks, this makes sense. +refs/replace/`obj-sha1`:: + records the SHA1 of the object that replaces `obj-sha1`. + This is similar to info/grafts and is internally used and + maintained by `git replace`. Such refs can be exchanged between + repositories while grafts are not. This should probably be an actual link to the git-replace manpage. I'll convert it to a linkgit. No need to resend. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix 'make test' for HP NonStop
On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote:
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need ${prefix}/bin in PATH first
+ SHELL_PATH=${prefix}/bin/bash
+ SANE_TOOL_PATH=${prefix}/bin
This feels a little too specific to go in our Makefile. Do we have any
reason to think that where you are installing git is going to be the
same place you have bash and other sane tools? Wouldn't this mean that
things work when you run make but mysteriously break when you run
make prefix=/my/local/install/of/git?
Well, make won't break (I think), but make test very well might.
Sure.
Well, so far all OpenSource packages ported to HP NonStop (at least
the ones on ituglib.connect-community.org) use prefix=/usr/local and
there is no intention to change that.
But then I would think using /usr/local would be the sane thing to put
there, if that is the closest to standard for your platform.
If there is not a standard, then I think we are better off leaving it
blank and letting people do the right thing for their system (including
packagers who are building for other people).
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fix 'make test' for HP NonStop
From: Jeff King [mailto:p...@peff.net]
Sent: Thursday, October 25, 2012 12:49 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [PATCH] fix 'make test' for HP NonStop
On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote:
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need ${prefix}/bin in PATH first
+ SHELL_PATH=${prefix}/bin/bash
+ SANE_TOOL_PATH=${prefix}/bin
This feels a little too specific to go in our Makefile. Do we have any
reason to think that where you are installing git is going to be the
same place you have bash and other sane tools? Wouldn't this mean that
things work when you run make but mysteriously break when you run
make prefix=/my/local/install/of/git?
Well, make won't break (I think), but make test very well might.
Sure.
Well, so far all OpenSource packages ported to HP NonStop (at least
the ones on ituglib.connect-community.org) use prefix=/usr/local and
there is no intention to change that.
But then I would think using /usr/local would be the sane thing to put
there, if that is the closest to standard for your platform.
OK, yes, hardcoding /usr/local seems OK too.
Would I need to re-roll?
Bye, Jojo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix 'make test' for HP NonStop
On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote: But then I would think using /usr/local would be the sane thing to put there, if that is the closest to standard for your platform. OK, yes, hardcoding /usr/local seems OK too. Would I need to re-roll? Please do. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] fix 'make test' for HP NonStop
This fixes the vast majority of test failures on HP NonStop.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
v2: hardcode /usr/local rather than using ${prefix}
Makefile | 9 +
1 file changed, 9 insertions(+)
diff --git a/Makefile b/Makefile
index f69979e..35380dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
MKDIR_WO_TRAILING_SLASH = YesPlease
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
+
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need /usr/local/bin in PATH first
+ SHELL_PATH=/usr/local/bin/bash
+ SANE_TOOL_PATH=/usr/local/bin
+ # as of H06.25/J06.14, we might better use this
+ #SHELL_PATH=/usr/coreutils/bin/bash
+ #SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fix 'make test' for HP NonStop
From: Jeff King [mailto:p...@peff.net] Sent: Thursday, October 25, 2012 12:53 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH] fix 'make test' for HP NonStop On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote: But then I would think using /usr/local would be the sane thing to put there, if that is the closest to standard for your platform. OK, yes, hardcoding /usr/local seems OK too. Would I need to re-roll? Please do. Done. For some reason not 'chained' to this thread though Bye, Jojo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
On Thu, Oct 25, 2012 at 05:01:49AM -0400, Jeff King wrote: Hmm. What is this patch on top of? It looks like it is on top of your original patch, but when I tried it on top of that, it does not apply either, and the index lines in the patch do not mention a sha1 that I do not have. Sorry, it's against km/send-email-compose-encoding (or current next) + git-send-email: use compose-encoding for Subject. Do you mind re-rolling a final 2-patch series with: 1. Your original patch and this one squashed together, with an appropriate commit message. I think that it's better to do refactoring and fix for ASCII in separate patches. Maybe we should reverse order of first two patches. This first will do refactoring and the second will just replace quote_rfc2047() with quote_subject() in broken encoding case and add test for this problem. 2. The second quote when we see '=?' patch. Thanks. -Peff ok, I will resend the final series. I need also to fix git-send-email: use compose-encoding for Subject patch. Now it's depends both on this series and km/send-email-compose-encoding branch. Krzysiek -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
On Thu, Oct 25, 2012 at 01:19:19PM +0200, Krzysztof Mazur wrote: On Thu, Oct 25, 2012 at 06:08:54AM -0400, Jeff King wrote: Ah, never mind. I missed your earlier use compose-encoding for Subject. I've queued it and all of the follow-ons onto the km/send-email-compose-encoding topic. thanks, what about the problem with whitespaces in quote_subject patch? I fixed the whitespace problems, and just applying your patches in sequence on top of send-email-compose-encoding actually looks sensible (after looking at it, I came to the same conclusion as you that the two patches should be kept separate). I'll push out the results of tonight's work in a few minutes, if you want to eyeball what's in pu. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
On Thu, Oct 25, 2012 at 06:08:54AM -0400, Jeff King wrote: Ah, never mind. I missed your earlier use compose-encoding for Subject. I've queued it and all of the follow-ons onto the km/send-email-compose-encoding topic. thanks, what about the problem with whitespaces in quote_subject patch? Krzysiek -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixes handling of --reference argument.
On Thu, Oct 25, 2012 at 04:36:26AM -0400, Jeff King wrote: On Wed, Oct 24, 2012 at 09:52:52PM -0700, sza...@google.com wrote: diff --git a/git-submodule.sh b/git-submodule.sh index ab6b110..dcceb43 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -270,7 +270,6 @@ cmd_add() ;; --reference=*) reference=$1 - shift ;; Is that right? We'll unconditionally do a shift at the end of the loop. If it were a two-part argument like --reference foo, the extra shift would make sense, but for --reference=*, no extra shift should be neccessary. Am I missing something? Both the patch and Jeff's analysis are right. You only need an in-case shift if you consume $2, or you're on ‘--’ and you're breaking before the end-of-case shift. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
What's cooking in git.git (Oct 2012, #08; Thu, 25)
What's cooking in git.git (Oct 2012, #08; Thu, 25) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Now that 1.8.0 is out, I've graduated the first batch of topics to master. I've also picked up some topics from the list, mostly documentation fixes that went straight to next. I haven't yet moved any of the cooking topics up to next. You can find the changes described here in the integration branches of my repository at: git://github.com/peff/git.git Until Junio returns, kernel.org and the other usual places will not be updated. -- [New Topics] * gb/maint-doc-svn-log-window-size (2012-10-25) 1 commit - Document git-svn fetch --log-window-size parameter Looks good to me, but I'd like to get an ack from svn folks. * jk/config-ignore-duplicates (2012-10-24) 8 commits (merged to 'next' on 2012-10-25 at 233df08) + git-config: use git_config_with_options + git-config: do not complain about duplicate entries + git-config: collect values instead of immediately printing + git-config: fix regexp memory leaks on error conditions + git-config: remove memory leak of key regexp + t1300: test git config --get-all more thoroughly + t1300: remove redundant test + t1300: style updates Drop duplicate detection from git-config; this lets it better match the internal config callbacks, which clears up some corner cases with includes. * mm/maint-doc-remote-tracking (2012-10-25) 1 commit (merged to 'next' on 2012-10-25 at 80f1592) + Documentation: remote tracking branch - remote-tracking branch We long ago hyphenated remote-tracking branch; this catches some new instances added since then. * ph/pull-rebase-detached (2012-10-25) 1 commit (merged to 'next' on 2012-10-25 at 73d9d14) + git-pull: Avoid merge-base on detached head Avoids spewing error messages when using pull --rebase on a detached HEAD. * ph/submodule-sync-recursive (2012-10-24) 2 commits - Add tests for submodule sync --recursive - Teach --recursive to submodule sync I'd like review from submodule folks on this one. * po/maint-refs-replace-docs (2012-10-25) 1 commit (merged to 'next' on 2012-10-25 at 3874c9d) + Doc repository-layout: Show refs/replace The refs/replace hierarchy was not mentioned in the repository-layout docs. * sl/maint-configure-messages (2012-10-25) 1 commit (merged to 'next' on 2012-10-25 at e1d7ecd) + configure: fix some output message Minor message fixes for the configure script. -- [Graduated to master] * bw/config-lift-variable-name-length-limit (2012-10-01) 1 commit (merged to 'next' on 2012-10-08 at 69f54f4) + Remove the hard coded length limit on variable names in config files The configuration parser had an unnecessary hardcoded limit on variable names that was not checked consistently. Lift the limit. * da/mergetools-p4 (2012-10-11) 1 commit (merged to 'next' on 2012-10-12 at 16f5c06) + mergetools/p4merge: Handle /dev/null * fa/remote-svn (2012-10-07) 16 commits (merged to 'next' on 2012-10-07 at 7b90cf4) + Add a test script for remote-svn + remote-svn: add marks-file regeneration + Add a svnrdump-simulator replaying a dump file for testing + remote-svn: add incremental import + remote-svn: Activate import/export-marks for fast-import + Create a note for every imported commit containing svn metadata + vcs-svn: add fast_export_note to create notes + Allow reading svn dumps from files via file:// urls + remote-svn, vcs-svn: Enable fetching to private refs + When debug==1, start fast-import with --stats instead of --quiet + Add documentation for the 'bidi-import' capability of remote-helpers + Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability + Add argv_array_detach and argv_array_free_detached + Add svndump_init_fd to allow reading dumps from arbitrary FDs + Add git-remote-testsvn to Makefile + Implement a remote helper for svn in C A GSoC project. * jc/test-say-color-avoid-echo-escape (2012-10-11) 1 commit (merged to 'next' on 2012-10-11 at 639036d) + test-lib: Fix say_color () not to interpret \a\b\c in the message Recent nd/wildmatch series was the first to reveal this ancient bug in the test scaffolding. * jk/no-more-pre-exec-callback (2012-06-05) 1 commit (merged to 'next' on 2012-10-12 at 69fed45) + pager: drop wait for output to run less hack (Originally merged to 'next' on 2012-07-23) Removes a workaround for buggy version of less older than version 406. * jk/peel-ref (2012-10-04) 4 commits (merged to 'next' on 2012-10-08 at 4adfa2f) + upload-pack: use peel_ref for ref advertisements + peel_ref: check object type before loading + peel_ref: do not return a null sha1 + peel_ref: use faster deref_tag_noverify Speeds up git upload-pack (what
Re: [PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
On Thu, Oct 25, 2012 at 4:45 PM, Jeff King p...@peff.net wrote: On Tue, Oct 23, 2012 at 09:24:51AM +0700, Nguyen Thai Ngoc Duy wrote: These functions are called in sequencer.c, which is part of libgit.a. This makes libgit.a potentially require builtin/merge.c for external git commands. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- I made some unrelated changes in sequencer.c and this problem shown up. merge-recursive.c is probably not the best place for these functions. I just don't want to create merge.c for them. I'm fine with this conceptually, but merge-recursive really is the wrong place. I'd much rather see a new merge.c to collect merge-related helper functions that are not strategy-specific. OK. I checked around for similar issues and found these used by libgit.a but stay in builtin/ instead: estimate_bisect_steps: bisect.c and builtin/rev-list.c print_commit_list: bisect.c and builtin/rev-list.c - move them to bisect.c? another candidate is revision.c. fetch_pack: transport.c and builtin/fetch-pack.c send_pack: transport.c and builtin/send-pack.c - move them to transport.c? or new files fetch-pack.c and send-pack.c? I haven't check how many functions they may pull together. setup_diff_pager: diff-no-index.c and builtin/diff.c - to diff-lib.c? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9401 fails with OS X sed
On 25.10.12 10:41, Jeff King wrote:
On Thu, Oct 25, 2012 at 01:04:11AM -0400, Geert Bosch wrote:
On Oct 24, 2012, at 23:54, Brian Gernhardt br...@gernhardtsoftware.com
wrote:
It works if I change \s to [[:space:]], but I don't know how portable that
is.
As \s is shorthand for the POSIX character class [:space:], I'd say the
latter
should be more portable: anything accepting the shorthand should also accept
the full character class. If not, you probably only care about horizontal tab
and space, for which you could just use a simple regular expression. Just a
literal space and tab character between square brackets is probably going to
be
most portable, though not most readable.
I agree that the POSIX character class would be more portable than \s,
but we do not have any existing uses of them, and I would worry a little
about older systems like Solaris. If we can simply use a literal space
and tab, that seems like the safest.
Brian, can you work up a patch?
-Peff
Would this be portable:
(It works on my Mac OS X box after installing cvs)
But I don't have solaris
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index cdb8360..f2ec9d2 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -46,7 +46,7 @@ check_status_options() {
echo Error from cvs status: $1 $2 ${WORKDIR}/marked.log
return 1;
fi
-got=$(sed -n -e 's/^\s*Sticky Options:\s*//p' ${WORKDIR}/status.out)
+got=$(tr '\t' ' ' ${WORKDIR}/status.out | sed -n -e 's/^ *Sticky
Options: *//p')
expect=$3
if [ x$expect = x ] ; then
expect=(none)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t9401: Use tr to handle TAB
Not all sed versions understand \s as whitespace
Use tr to translate '\t' into ' ' before feeding the line into sed
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t9401-git-cvsserver-crlf.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index cdb8360..f2ec9d2 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -46,7 +46,7 @@ check_status_options() {
echo Error from cvs status: $1 $2 ${WORKDIR}/marked.log
return 1;
fi
-got=$(sed -n -e 's/^\s*Sticky Options:\s*//p' ${WORKDIR}/status.out)
+got=$(tr '\t' ' ' ${WORKDIR}/status.out | sed -n -e 's/^ *Sticky
Options: *//p')
expect=$3
if [ x$expect = x ] ; then
expect=(none)
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 9:50 AM, Sverre Rabbelier srabbel...@gmail.com wrote: On Thu, Oct 25, 2012 at 12:48 AM, Jonathan Nieder jrnie...@gmail.com wrote: Sverre Rabbelier wrote: I know there was a reason why using UNINTERESTING didn't work (otherwise we could've used that to start with, instead of needing Junio's whence solution). I think all refs ended up being marked as UNINTERESTING or somesuch. True. Is it be possible to check UNINTERESTING in revs-cmdline before the walk? It is possible to check in revs-pending, but '^foo master' will mark them both as UNINTERESTING, and 'master..master' as well, which again, is what we actually want, because that's how it works in the rest of git. That might work, maybe Dscho remembers why we did not go with that approach. Because you want 'master..master' to output something, but that's wrong; it's changing the semantics of commitishes, and you don't need that to solve this problem. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Where should git-prompt.sh be installed?
On Wed, Oct 24, 2012 at 05:51:06PM -0700, Jonathan Nieder wrote: Hi, In olden days the admin would copy contrib/completion/git-completion.sh to /etc/bash_completion.d/git and mortals could source /etc/bash_completion or /etc/bash_completion.d/git in their ~/.bashrc (possibly shared among multiple machines) so that the bash completion and __git_ps1 helpers could work. Ah, the good old days! I even modified 'make install' to copy the completion script to /etc/bash_completion.d/. And I was happy. With Git 1.7.12 __git_ps1 has been split into a separate file, to help users who only want __git_ps1 to avoid the overhead of loading the entire completion script (and allow the completion script to be loaded by bash-completion magic on the fly!). Now the sysadmin should copy contrib/completion/git-completion.sh to /usr/share/bash-completion/completions/git and contrib/completion/git-prompt.sh to /usr/share/git-core/contrib/?? (somewhere?) Mortals source /etc/bash_completion in their ~/.bashrc (possibly shared among multiple machines) and expect bash completion to work. For __git_ps1, users should source that ?? path. Questions: 1) what path is appropriate for ?? above? 2) is this documented anywhere? Don't know what is appropriate, and it's not documented. I for one copy it manually to ~/.git-prompt.sh every once in a while. And I'm not all that happy with that. Possible answers: 1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses /usr/share/bash-completion/git-prompt. Maybe others use some other path. 2) The scripts themselves suggest copying to ~/.git-completion.sh and ~/.git-prompt.sh. Proposal: 1) /usr/lib/git-core/git-sh-prompt 2) git-sh-prompt(1) Not sure about the sh part. The prompt function is very Bash-specific, it won't work under a plain POSIX shell. Do other VCSes have similar prompt scripts? Where do they install theirs? Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Unexpected behaviour after removing submodule
Hi, At work, we use a lot of submodules (several levels of submodules actually). As we also work with development branches, we use scripts to resync the whole checked-out tree (mainly in automated integration) We recently run across an issue where a branch (dev) contained a submodule while it had been removed in master and the files were imported in a subdirectory with the same name (probably using git-subtree). Basically: On dev: * top/refs(submodule)/file1 On master: * top/refs(dir)/file1 Outside the fact that it is quite hard to move from one branch to the other while having a perfectly clean tree checked out underneath, we manage to end up into a weird (invalid) state that was neither clearly described nor easy to cleanup (using standard git clean/checkout/reset commands). While I cannot explain how we got in this state, here is a small test-case that produce the same results: -- mkdir folder1 cd folder1 git init echo Ooops file git add file git commit -m Add file cd .. mkdir folder2 cd folder2 git init mkdir folder1 echo Ooops folder1/file git add folder1/file git commit -m Add file again git checkout -b branch cp -R ../folder1/.git ./folder1 -- The 'cp' just seems pointless but with the submodule described as above we manage to end up in a similar state. In this state, when being in folder2, git status reports nothing. Dev branch is checked out and everything looks great. However if you change dir to folder2/folder1, while still being inside folder2, git thinks (because of the .git dir) that you are actually on master branch of folder1 repository. Which mean that if you happen to commit from a subdirectory, you may easily end-up committing in another repository than the one expected. The issue is, there is no way from folder2 to see that something wrong is going on inside your tree! As we manage to reach this state using only standard git commands (I'll try to reproduce it) with submodules, and this being part of an automated flow, it is quite worrying. We may actually be committing in the wrong repo and pushing the wrong things around. Is there or should there be a way to look for such issues? And is this an expected behaviour? Thanks in advance Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] git-status: show short sequencer state
Jeff King wrote:
On Tue, Oct 23, 2012 at 04:02:54PM -0400, Phil Hord wrote:
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Introduce a common function to determine the current sequencer
state so the regular status function and this short version can
share common code.
Add a substate to wt_status_state to track more detailed
information about a state, such as conflicted or resolved.
Move the am_empty_patch flage out of wt_status_state and into
This patch ended up quite long. It might be a little easier to review
if it were broken into refactoring steps (I have not looked at it too
closely yet, but it seems like the three paragraphs above could each be
their own commit).
I can do that.
State token strings which may be emitted and their meanings:
merge a git-merge is in progress
am a git-am is in progress
rebase a git-rebase is in progress
rebase-interactive a git-rebase--interactive is in progress
A minor nit, but you might want to update this list from the one in the
documentation.
I considered it, but I also considered the audience; then I took the
easier path. I'll look again.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..9706ed9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
-STATUS_FORMAT_PORCELAIN
+STATUS_FORMAT_PORCELAIN,
+STATUS_FORMAT_SEQUENCER
} status_format = STATUS_FORMAT_LONG;
Hmm. So the new format is its own distinct output format. I could not
say I would like to see short status, and by the way, show me the
sequencer state, as you can with -b. Is it possible to do this (or
even desirable; getting the sequencer state should be way cheaper, so
conflating the two may not be what some callers want).
Not complaining, just wondering about the intended use cases.
Originally I did place this output in the short-format display. I
particularly want this info to be available for scripts. But it feels
right to include it with the short status, since the long-form is
already available with 'git status --no-short'.
Since there may be more than one line reported, I did not feel there was
a simple way to contain these details in with the short status. For
branch this is a simple decision as the reported branch will take
exactly one line.
git status -b -s
## master
M Foo
But for sequencer state, this seemed like it could be too convoluted or
might encourage too much reliance line-counting:
git status -b -s -S
## master
## merge
## conflicted
M Foo
Maybe a different line-prefix would help make this clearer:
git status -b -s -S
## master
#! merge
#! conflicted
M Foo
It seemed to me this was someone else's itch and I might not scratch it
properly. But I am willing to try if you think this is more useful than
distracting.
Also, does there need to be a --porcelain version of this output? It
seems like we can have multiple words (e.g., in a merge, with conflicted
entries). If there is no arbitrary data, we do not have to worry about
delimiters and quoting. But I wonder if we would ever want to expand
the information to include arbitrary strings, at which point we would
want NUL delimiters; should we start with that now?
This works, though I haven't tested it on v2:
git status -S -z
+// Determine main sequencer activity
Please avoid C99 comments (there are others in the patch, too).
Thanks.
+void wt_sequencer_print(struct wt_status *s)
+{
+struct wt_status_state state;
+
+wt_status_get_state(s, state);
+
+if (state.merge_in_progress)
+wt_print_token(s, merge);
+if (state.am_in_progress)
+wt_print_token(s, am);
+if (state.rebase_in_progress)
+wt_print_token(s, rebase);
+if (state.rebase_interactive_in_progress)
+wt_print_token(s, rebase-interactive);
+if (state.cherry_pick_in_progress)
+wt_print_token(s, cherry-pick);
+if (state.bisect_in_progress)
+wt_print_token(s, bisect);
+
+switch (state.substate) {
+case WT_SUBSTATE_NOMINAL:
+break;
+case WT_SUBSTATE_CONFLICTED:
+wt_print_token(s, conflicted);
+break;
+case WT_SUBSTATE_RESOLVED:
+wt_print_token(s, resolved);
+break;
+case WT_SUBSTATE_EDITED:
+wt_print_token(s, edited);
+break;
+case WT_SUBSTATE_EDITING:
+wt_print_token(s, editing);
+break;
+case WT_SUBSTATE_SPLITTING:
+wt_print_token(s, splitting);
+break;
+case WT_SUBSTATE_AM_EMPTY:
+wt_print_token(s, am-empty);
+
Re: Where should git-prompt.sh be installed?
SZEDER Gábor wrote: On Wed, Oct 24, 2012 at 05:51:06PM -0700, Jonathan Nieder wrote: Proposal: 1) /usr/lib/git-core/git-sh-prompt 2) git-sh-prompt(1) Not sure about the sh part. The prompt function is very Bash-specific, it won't work under a plain POSIX shell. That's an interesting point. Here's my logic: The prompt function was originally Bash-specific, but over time it gained support for Zsh as well. If we're lucky, some day it might gain support for mksh. Meanwhile something simple like git-prompt would sound too much like a normal git command, I fear. Shell language extensions used: * future standard: local variables * cosmetic: [[ and (( syntax in place of test and $( * cosmetic: for ((n=1; n = n_stop; n++)) instead of a more explicit while loop * cosmetic: var+=value syntax * optimization: syntax to iterate over lines in a variable instead of, for example, sed + eval * arrays: svn_remote, svn_upstream --- using plain variables would require some escaping. So nothing fundamental, but since this is only useful in shells like Bash that support command substitution in $PS1, it seems reasonable to keep using the extensions until someone wants to use it with a more limited shell. In other words, the interface is still this is a scriptlet you might source in your Bourne-style shell to get a __git_ps1 function to use in your prompt. The implementation language just happens not to be POSIX shell today. Perhaps it should return early in shells other than bash and zsh to help people keep their .shrc simple. What do you think? Do other VCSes have similar prompt scripts? Where do they install theirs? Mercurial has an hg-prompt extension that can be used by running hg prompt. http://mercurial.selenic.com/wiki/PromptExtension I haven't found one for Subversion. Bazaar has contrib/bash/bzrbashprompt.sh. It doesn't get installed. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use character class for sed expression instead of \s
On 25.10.12 18:00, Brian Gernhardt wrote: On Oct 25, 2012, at 11:58 AM, Ben Walton bdwal...@gmail.com wrote: Sed on Mac OS X doesn't handle \s in a sed expressions so use a more portable character set expression instead. Signed-off-by: Ben Walton bdwal...@gmail.com Acked-by: Brian Gernhardt br...@gernhardtsoftware.com I have an identical change sitting in my git.git, I've just been too distracted by other things to commit and send it. ~~ Brian Gernhardt Much nicer, indeed. BTW: While we are talking CVS: (I installed a fresh version) cvs --version Concurrent Versions System (CVS) 1.11.23 (client/server) And t9200 fails: git checkout t9200-git-cvsexportcommit.sh tb@birne:~/projects/git/git.pu/t ./t9200-git-cvsexportcommit.sh cvs [init aborted]: Cannot initialize repository under existing CVSROOT: `/Users/tb/projects/git/git.pu/t/trash directory.t9200-git-cvsexportcommit' FATAL: Unexpected exit with code 1 The following fixes it, but there are possibly better solutions. Any comments/suggestions ? diff t9200-git-cvsexportcommit.sh t9200-git-cvsexportcommit.tb.sh 28,29c28 mkdir $CVSROOT cvs init --- (cvs init || mkdir $CVSROOT cvs init ) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 9:18 AM, Jonathan Nieder jrnie...@gmail.com wrote: Felipe Contreras wrote: Show me a single remote helper that manually stores SHA-1's and I might believe you, but I doubt that, marks are too convenient. Oh dear lord. Why are you arguing? Explain how coming to a consensus on this will help accomplish something useful, and then I can explain my point of view. In the meantime, this seems like a waste of time. We don't need to come to a consensus because there is no problem. Nobody has requested this feature, and nobody has faced any problem with this. If you have no evidence of the contrary, that's what I'll believe. I agree it's a waste of time, so let's not talk about the :0 - SHA-1 feature, or the master..master feature in this thread; they are orthogonal. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push tags
On Thu, Oct 25, 2012 at 2:58 AM, Angelo Borsotti angelo.borso...@gmail.com wrote: Hello, git push tag updates silently the specified tag. E.g. git init --bare release.git git clone release.git integrator cd integrator git branch -avv touch f1; git add f1; git commit -m A git tag v1 git push origin tag v1 touch f2; git add f2; git commit -m B git tag -f v1 git push origin tag v1 the second git push updates the tag in the remote repository. This is somehow counterintuitive because tags normally do not move (unless forced to that), and is not documented. You specified -f (force) and it did exactly what you asked. That is fully documented (git help tag). This is also harmful because it allows to change silently something (tags) that normally must not change. Tags have many uses. Some of those uses are harmed when tags change and some aren't. That's a philosophical argument and Git is a computer program, not a philosopher. It is not the job of the machine to prevent the user from shooting himself in the foot when he clearly expressed an interest in doing so. -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] gitk: handle --full-diff corectly
Basically $SUBJECT. See details in the 2nd patch. Felipe Contreras (2): gitk: simplify file filtering gitk: handle --full-diff correctly gitk-git/gitk | 36 +--- 1 file changed, 17 insertions(+), 19 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] gitk: simplify file filtering
git diff is perfectly able to do this with '-- files', no need for
manual filtering.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
gitk-git/gitk | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..b79dfdf 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7519,9 +7519,13 @@ proc diffcmd {ids flags} {
}
proc gettreediffs {ids} {
-global treediff treepending
+global treediff treepending limitdiffs vfilelimit curview
-if {[catch {set gdtf [open [diffcmd $ids {--no-commit-id}] r]}]} return
+set cmd [diffcmd $ids {--no-commit-id}]
+if {$limitdiffs $vfilelimit($curview) ne {}} {
+ set cmd [concat $cmd -- $vfilelimit($curview)]
+}
+if {[catch {set gdtf [open $cmd r]}]} return
set treepending $ids
set treediff {}
@@ -7565,17 +7569,7 @@ proc gettreediffline {gdtf ids} {
return [expr {$nr = $max? 2: 1}]
}
close $gdtf
-if {$limitdiffs $vfilelimit($curview) ne {}} {
- set flist {}
- foreach f $treediff {
- if {[path_filter $vfilelimit($curview) $f]} {
- lappend flist $f
- }
- }
- set treediffs($ids) $flist
-} else {
- set treediffs($ids) $treediff
-}
+set treediffs($ids) $treediff
unset treepending
if {$cmitmode eq tree [llength $diffids] == 1} {
gettree $diffids
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] gitk: handle --full-diff correctly
Otherwise the files are missing from the diff, and the list of files.
We do this by creating a limitdiffs variable specific for the view which
can be turned of by using --full-diff.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
gitk-git/gitk | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index b79dfdf..4ffabdf 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -155,11 +155,12 @@ proc unmerged_files {files} {
}
proc parseviewargs {n arglist} {
-global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
-global worddiff git_version
+global vdatemode vmergeonly vlimitdiffs vflags vdflags vrevs vfiltered
vorigargs env
+global limitdiffs worddiff git_version
set vdatemode($n) 0
set vmergeonly($n) 0
+set vlimitdiffs($n) $limitdiffs
set glflags {}
set diffargs {}
set nextisval 0
@@ -187,7 +188,7 @@ proc parseviewargs {n arglist} {
--no-renames - --full-index - --binary - --abbrev=* -
--find-copies-harder - -l* - --ext-diff - --no-ext-diff -
--src-prefix=* - --dst-prefix=* - --no-prefix -
- -O* - --text - --full-diff - --ignore-space-at-eol -
+ -O* - --text - --ignore-space-at-eol -
--ignore-space-change - -U* - --unified=* {
# These request or affect diff output, which we don't want.
# Some could be used to set our defaults for diff display.
@@ -251,6 +252,9 @@ proc parseviewargs {n arglist} {
--no-replace-objects {
set env(GIT_NO_REPLACE_OBJECTS) 1
}
+ --full-diff {
+ set vlimitdiffs($n) 0
+ }
-* {
# Other flag arguments including -n
if {[string is digit -strict [string range $arg 1 end]]} {
@@ -7519,10 +7523,10 @@ proc diffcmd {ids flags} {
}
proc gettreediffs {ids} {
-global treediff treepending limitdiffs vfilelimit curview
+global treediff treepending vlimitdiffs vfilelimit curview
set cmd [diffcmd $ids {--no-commit-id}]
-if {$limitdiffs $vfilelimit($curview) ne {}} {
+if {$vlimitdiffs($curview) $vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
}
if {[catch {set gdtf [open $cmd r]}]} return
@@ -7535,7 +7539,7 @@ proc gettreediffs {ids} {
proc gettreediffline {gdtf ids} {
global treediff treediffs treepending diffids diffmergeid
-global cmitmode vfilelimit curview limitdiffs perfile_attrs
+global cmitmode vfilelimit curview perfile_attrs
set nr 0
set sublist {}
@@ -7613,7 +7617,7 @@ proc getblobdiffs {ids} {
global diffcontext
global ignorespace
global worddiff
-global limitdiffs vfilelimit curview
+global vlimitdiffs vfilelimit curview
global diffencoding targetline diffnparents
global git_version currdiffsubmod
@@ -7632,7 +7636,7 @@ proc getblobdiffs {ids} {
if {$worddiff ne [mc Line diff]} {
append cmd --word-diff=porcelain
}
-if {$limitdiffs $vfilelimit($curview) ne {}} {
+if {$vlimitdiffs($curview) $vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
}
if {[catch {set bdf [open $cmd r]} err]} {
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use character class for sed expression instead of \s
Hi Torsten, On Thu, Oct 25, 2012 at 5:28 PM, Torsten Bögershausen tbo...@web.de wrote: BTW: While we are talking CVS: (I installed a fresh version) cvs --version Concurrent Versions System (CVS) 1.11.23 (client/server) I have 1.12.13-MirDebian-8 here. And t9200 fails: git checkout t9200-git-cvsexportcommit.sh tb@birne:~/projects/git/git.pu/t ./t9200-git-cvsexportcommit.sh cvs [init aborted]: Cannot initialize repository under existing CVSROOT: `/Users/tb/projects/git/git.pu/t/trash directory.t9200-git-cvsexportcommit' FATAL: Unexpected exit with code 1 I'm not able to reproduce this manually...are you able to make it fail this way outside of the test harness? $ CVSROOT=$PWD/bw $ export CVSROOT $ mkdir $CVSROOT cvs init echo ok ok $ rm -rf $CVSROOT $ cvs init echo ok ok (cvs init || mkdir $CVSROOT cvs init ) If your version of cvs fails the checks above in manual testing, we could see if there is a flag that works in all (old and new) versions to override the failure if CVSROOT exists. Otherwise, this isn't a bad fix, I don't think. If your version does fail the manual checks, I think it's likely a regression that was introduced and later reverted. I don't see those strings inside my cvs binary at all...? HTH. Thanks -Ben -- --- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] git-pull: Avoid merge-base on detached head
Jeff King wrote: On Tue, Oct 23, 2012 at 04:39:56PM -0400, Phil Hord wrote: git pull --rebase does some clever tricks to find the base for $upstream , but it forgets that we may not have any branch at all. When this happens, git merge-base reports its usage help in the middle of an otherwise successful rebase operation, because git-merge is called with one too few parameters. Since we do not need the merge-base trick in the case of a detached HEAD, detect this condition and bypass the clever trick and the usage noise. Makes sense. I notice there is no test with your patch. It sounds from the description like the operation still may succeed, but we just get cruft on stderr? Yes, that's correct. P -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push tags
Hi Drew, You specified -f (force) and it did exactly what you asked. That is fully documented (git help tag). Yes, it is, and I used it to show that there is a need to specify explicitly the intent to change a tag, that without such an indication would not be changed. Tags have many uses. Some of those uses are harmed when tags change and some aren't. That's a philosophical argument I agree, but in this case the computer does not provide any means to implement the same strategy on tags as it does instead on local repositories. Why I must force a change on a tag in the local repository and instead I can change it without any forcing in a remote one? Are remote repositories less protected than the local ones? I think that to be consistent, the same strategy should be used on all repositories, i.e. rejecting changes on tags by default, unless they are forced. -Angelo -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixes handling of --reference argument.
On Thu, Oct 25, 2012 at 11:32:29PM +0200, Jens Lehmann wrote: @@ -270,7 +270,6 @@ cmd_add() ;; --reference=*) reference=$1 - shift ;; Is that right? We'll unconditionally do a shift at the end of the loop. If it were a two-part argument like --reference foo, the extra shift would make sense, but for --reference=*, no extra shift should be neccessary. Am I missing something? Both the patch and Jeff's analysis are right. You only need an in-case shift if you consume $2, or you're on ‘--’ and you're breaking before the end-of-case shift. Right you are. The shift there is wrong, as there is no extra argument to consume for --reference=repo (opposed to --reference repo, also see cmd_update() where this is done right). Oh, the problem is that I'm an idiot, and for some reason read it as _adding_ the bogus shift, not removing it. Patch is clearly correct. So tested and Acked-By me, but me thinks the subject should read: [PATCH] submodule add: Fix handling of the --reference=repo option and the commit message should begin with: Doing a shift there is wrong because there is no extra argument to consume when --reference=repo is used (note the '=' instead of a space). Yeah, I think it makes sense to explain why it is wrong in the commit message (I'll blame that for my lack of common sense above :) ). Peff, is it ok for you to squash that in or do you want Stefan to resend? I can squash it in. Thanks all. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git rebase -i and final newline
Sorry if I am drumming up and old issue here. I have noticed that with git rebase -i, if your final line contains a commit and no newline, git interprets that as remove this commit please. I feel that a commit should be removed only if the entire line is removed, that is the commit hash and title as well as the newline. I have noticed that the behavior is correct with git commit. Even if you omit the final newline after the commit message body, all text lines will be included. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
