Re: [PATCHv2 3/8] ident: make user_ident_explicitly_given static

Jeff King wrote: > In v1.5.6-rc0~56^2 (2008-05-04) "user_ident_explicitly_given" > was introduced as a global for communication between config, > ident, and builtin-commit. In v1.7.0-rc0~72^2 (2010-01-07) > readers switched to using the common wrapper > user_ident_sufficiently_given(). After v1.

Re: [PATCHv2 2/8] t7502: factor out autoident prerequisite

Jeff King wrote: > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -738,6 +738,12 @@ test_lazy_prereq UTF8_NFD_TO_NFC ' > esac > ' > > +test_lazy_prereq AUTOIDENT ' > + sane_unset GIT_AUTHOR_NAME && > + sane_unset GIT_AUTHOR_EMAIL && > + git var GIT_AUTHOR_IDENT > +' Lazy prer

Re: [PATCH v3 0/5] push: update remote tags only with force

Hi Junio, > I am *not* convinced that the "refs/tags/ is the only special > hierarchy whose contents should not move" is a bad limitation we > should avoid, but if it indeed is a bad limitation, the above is one > possible way to think about avoiding it. What other hierarchy besides branches and

Re: [PATCHv2 1/8] test-lib: allow negation of prerequisites

Jeff King wrote: > +test_expect_success !LAZY_TRUE 'missing lazy prereqs skip tests' ' I have a visceral nervousness when reading this code, from too much unpleasant experience of bash's csh-style !history expansion. Luckily bash does not treat ! specially in the '-o sh' mode used by tests. Doe

nike air max 95

nike air max 95 nike air max 95 nike air max 95 -- View this message in context: http://git.661346.n2.nabble.com/nike-air-max-95-tp7571318.html Sent from the git mailing list archive at Nabble.com.

Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)

On 15.11.12 02:56, Jeff King wrote: > On Wed, Nov 14, 2012 at 08:50:43PM -0500, Mark Levedahl wrote: > >> Cygwin changed the win32api implementation, and the old is not just >> no longer supported for the current release series, but virtually >> impossible to even install (several new packages are

[PATCH 1/5 v2] t/test-lib-functions.sh: allow to specify the tag name to test_commit

The part of test_commit() may not be appropriate for a tag name. So let's allow test_commit to accept a fourth argument to specify the tag name. Signed-off-by: Brandon Casey --- t/test-lib-functions.sh | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/t/test-lib-funct

Re: [PATCH 1/5] t/test-lib-functions.sh: allow to specify the tag name to test_commit

Good eye. Thanks. On Wed, Nov 14, 2012 at 7:20 PM, Matt Kraai wrote: > On Wed, Nov 14, 2012 at 05:37:50PM -0800, Brandon Casey wrote: >> -# Both and default to . >> +# Both and default to . > > I think this line would be better as > > # , , and all default to . > > since there's now more

Re: Local clones aka forks disk size optimization

On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill wrote: > On 15 November 2012 12:15, Javier Domingo wrote: >> Hi Andrew, >> >> Doing this would require I got tracked which one comes from which. So >> it would imply some logic (and db) over it. With the hardlinking way, >> it wouldn't require anythi

Re: [PATCH 1/5] t/test-lib-functions.sh: allow to specify the tag name to test_commit

On Wed, Nov 14, 2012 at 05:37:50PM -0800, Brandon Casey wrote: > -# Both and default to . > +# Both and default to . I think this line would be better as # , , and all default to . since there's now more than two arguments that default to message. -- Matt -- To unsubscribe from this lis

Re: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash

On Wed, Nov 14, 2012 at 1:11 AM, SZEDER Gábor wrote: > On Tue, Nov 13, 2012 at 07:31:45PM +0100, Felipe Contreras wrote: >> On Mon, Nov 12, 2012 at 9:07 PM, Marc Khouzam wrote: >> > + # Call _git() or _gitk() of the bash script, based on the first >> > + # element of the command-line

Re: [PATCH] send-email: add proper default sender

On Thu, Nov 15, 2012 at 2:50 AM, Jeff King wrote: > On Thu, Nov 15, 2012 at 02:41:50AM +0100, Felipe Contreras wrote: > >> But that I meant that when I introduce a regression it's like I'm >> killing all that is good and sacred about git, and when you do it's >> everything but that. > > The rhetor

Re: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident

On Thu, Nov 15, 2012 at 1:36 AM, Jeff King wrote: > diff --git a/git-send-email.perl b/git-send-email.perl > index 5a7c29d..0c49b32 100755 > --- a/git-send-email.perl > +++ b/git-send-email.perl > @@ -436,9 +436,8 @@ if (0) { > } > } > > -my ($repoauthor, $repocommitter); > -($repoauthor

Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)

On Wed, Nov 14, 2012 at 08:50:43PM -0500, Mark Levedahl wrote: > Cygwin changed the win32api implementation, and the old is not just > no longer supported for the current release series, but virtually > impossible to even install (several new packages are now installed, > the old package is in the

Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)

On 11/14/2012 07:16 PM, Jeff King wrote: On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote: b) Autodetection: (Just loud thinking), running $grep mingw /usr/include/w32api/winsock2.h * This file is part of the mingw-w64 runtime package. #include <_mingw_unicode.h> on cygw

Re: [PATCH] send-email: add proper default sender

On Thu, Nov 15, 2012 at 02:41:50AM +0100, Felipe Contreras wrote: > But that I meant that when I introduce a regression it's like I'm > killing all that is good and sacred about git, and when you do it's > everything but that. The rhetoric in this statement is a good indication that there is noth

[PATCH] usage.c: detect recursion in die routines and bail out immediately

It is theoretically possible for a die handler to get into a state of infinite recursion. For example, if a die handler called another function which itself called die(). Let's at least detect this situation, inform the user, and call exit. Signed-off-by: Brandon Casey --- usage.c | 15 +++

[PATCH 3/5] sequencer.c: handle rfc2822 continuation lines correctly

ends_rfc2822_footer() was incorrectly checking whether the current line was a continuation of the previous line. It was actually checking the next line instead of the current line. Let's fix this and mark the test as expect_success. Signed-off-by: Brandon Casey --- sequencer.c | 2

Re: [PATCH] send-email: add proper default sender

On Thu, Nov 15, 2012 at 1:07 AM, Jeff King wrote: > On Tue, Nov 13, 2012 at 09:35:18PM +0100, Felipe Contreras wrote: > >> > Yes, dying would be a regression, in that you would have to configure >> > your name via the environment and re-run rather than type it at the >> > prompt. You raise a good

[PATCH/RFC 5/5] sequencer.c: always separate "(cherry picked from" from commit body

Start treating the "(cherry picked from" line added by cherry-pick -x the same way that the s-o-b lines are treated. Namely, separate them from the main commit message body with an empty line. Also, introduce tests to test this functionality. Signed-off-by: Brandon Casey --- This seems like t

[PATCH 4/5] sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer

Currently, if the s-o-b footer of a commit message contains a "(cherry picked from ..." line that was added by a previous cherry-pick -x, it is not recognized as a s-o-b footer and will cause a newline to be inserted before an additional s-o-b is added. So, rework ends_rfc2822_footer to recognize

[PATCH 2/5] t/t3511: demonstrate breakage in cherry-pick -s

The cherry-pick -s functionality is currently broken in two ways. 1. handling of rfc2822 continuation lines has a bug, and the continuation lines are not handled correctly. 2. the "(cherry picked from ...)" lines are commonly appended to the end of the s-o-b footer and should be

[PATCH 1/5] t/test-lib-functions.sh: allow to specify the tag name to test_commit

The part of test_commit() may not be appropriate for a tag name. So let's allow test_commit to accept a fourth argument to specify the tag name. Signed-off-by: Brandon Casey --- t/test-lib-functions.sh | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/t/test-lib-funct

Re: Local clones aka forks disk size optimization

On 15 November 2012 12:15, Javier Domingo wrote: > Hi Andrew, > > Doing this would require I got tracked which one comes from which. So > it would imply some logic (and db) over it. With the hardlinking way, > it wouldn't require anything. The idea is that you don't have to do > anything else in t

Re: What's cooking in git.git (Nov 2012, #04; Wed, 14)

On Wed, Nov 14, 2012 at 11:42 PM, Junio C Hamano wrote: > * fc/completion-test-simplification (2012-10-29) 2 commits > - completion: simplify __gitcomp test helper > - completion: refactor __gitcomp related tests > > Clean up completion tests. > > There were some comments on the list. > > Ex

Re: [PATCH 2/2] pickaxe: use textconv for -S counting

On Tue, Nov 13, 2012 at 03:13:19PM -0800, Junio C Hamano wrote: > > static int has_changes(struct diff_filepair *p, struct diff_options *o, > >regex_t *regexp, kwset_t kws) > > { > > + struct userdiff_driver *textconv_one = get_textconv(p->one); > > + struct userdiff_driv

Re: Local clones aka forks disk size optimization

Hi Andrew, Doing this would require I got tracked which one comes from which. So it would imply some logic (and db) over it. With the hardlinking way, it wouldn't require anything. The idea is that you don't have to do anything else in the server. I understand that it would be imposible to do it

Re: Local clones aka forks disk size optimization

On 15 November 2012 11:40, Javier Domingo wrote: > Hi Andrew, > > The problem about that, is that if I want to delete the first repo, I > will loose objects... Or does that repack also hard-link the objects > in other repos? I don't want to accidentally loose data, so it would > be nice that altho

Re: Local clones aka forks disk size optimization

Hi Andrew, The problem about that, is that if I want to delete the first repo, I will loose objects... Or does that repack also hard-link the objects in other repos? I don't want to accidentally loose data, so it would be nice that althought avoided to repack things, it would also hardlink them. J

[PATCHv2 8/8] send-email: do not prompt for explicit repo ident

If git-send-email is configured with sendemail.from, we will not prompt the user for the "From" address of the emails. If it is not configured, we prompt the user, but provide the repo author or committer as a default. Even though we probably have a sensible value for the default, the prompt is a

[PATCHv2 7/8] Git.pm: teach "ident" to query explicitness

"git var" recently learned to report on whether an ident we fetch from it was configured explicitly or implicitly. Let's make that information available to callers of the ident function. Because evaluating "ident" in an array versus scalar context already has a meaning, we cannot return our extra

[PATCHv2 6/8] var: provide explicit/implicit ident information

Internally, we keep track of whether the author or committer ident information was provided by the user, or whether it was implicitly determined by the system. However, there is currently no way for external programs or scripts to get this information without re-implementing the ident logic themsel

[PATCHv2 5/8] var: accept multiple variables on the command line

Git-var currently only accepts a single value to print. This is inefficient if the caller is interested in finding multiple values, as they must invoke git-var multiple times. This patch lets callers specify multiple variables, and prints one per line. While we're in the area, let's add some basi

[PATCHv2 4/8] ident: keep separate "explicit" flags for author and committer

We keep track of whether the user ident was given to us explicitly, or if we guessed at it from system parameters like username and hostname. However, we kept only a single variable. This covers the common cases (because the author and committer will usually come from the same explicit source), but

[PATCHv2 3/8] ident: make user_ident_explicitly_given static

In v1.5.6-rc0~56^2 (2008-05-04) "user_ident_explicitly_given" was introduced as a global for communication between config, ident, and builtin-commit. In v1.7.0-rc0~72^2 (2010-01-07) readers switched to using the common wrapper user_ident_sufficiently_given(). After v1.7.11-rc1~15^2~18 (2012-05-21

[PATCHv2 2/8] t7502: factor out autoident prerequisite

t7502 checks the behavior of commit when we can and cannot determine a valid committer ident. Let's move that into test-lib as a lazy prerequisite so other scripts can use it. Signed-off-by: Jeff King --- t/t7502-commit.sh | 12 +--- t/test-lib.sh | 6 ++ 2 files changed, 7 inse

[PATCHv2 1/8] test-lib: allow negation of prerequisites

You can set and test a prerequisite like this: test_set_prereq FOO test_have_prereq FOO && echo yes You can negate the test in the shell like this: ! test_have_prereq && echo no However, when you are using the automatic prerequisite checking in test_expect_*, there is no opportunity to us

[PATCHv2 0/8] loosening "sender" prompt in send-email

On Tue, Nov 13, 2012 at 11:48:45AM -0500, Jeff King wrote: > [1/6]: ident: make user_ident_explicitly_given private > [2/6]: ident: keep separate "explicit" flags for author and committer > [3/6]: var: accept multiple variables on the command line > [4/6]: var: provide explicit/implicit id

Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)

Jeff King writes: > On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote: > >> * ml/cygwin-mingw-headers (2012-11-12) 1 commit >> - Update cygwin.c for new mingw-64 win32 api headers >> >> Make git work on newer cygwin. >> >> Will merge to 'next'.

Re: Local clones aka forks disk size optimization

On 15 November 2012 10:42, Javier Domingo wrote: > Hi, > > I have come up with this while doing some local forks for work. > Currently, when you clone a repo using a path (not file:/// protocol) > you get all the common objects linked. > > But as you work, each one will continue growing on its way

Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)

On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote: > * ml/cygwin-mingw-headers (2012-11-12) 1 commit > - Update cygwin.c for new mingw-64 win32 api headers > > Make git work on newer cygwin. > > Will merge to 'next'. I'm cc-ing Junio in case he

Re: [PATCH v3 0/5] push: update remote tags only with force

Junio C Hamano writes: Addendum. > In any case, I thought this series was about users who run "push" > voluntarily stopping themselves from pushing updates to tags that > may happen to fast-forward, so if we were to go with the > configuration route, the suggestion would be more like > > [pu

Re: [PATCH] send-email: add proper default sender

On Tue, Nov 13, 2012 at 09:35:18PM +0100, Felipe Contreras wrote: > > Yes, dying would be a regression, in that you would have to configure > > your name via the environment and re-run rather than type it at the > > prompt. You raise a good point that for people who _could_ take the > > implicit d

Re: [PATCH v3 0/5] push: update remote tags only with force

Hi Junio, > That is an independent issue of deciding to accept or reject > receiving a push from outside, no? Yes, it is. Actually I thought some means to let the owner do decide what to accept were already present (the pushNonFastForward config key), and going along this avenue I thought it coul

Re: [regression] Newer gits cannot clone any remote repos

Douglas Mencken writes: I cannot reproduce the problem (on openSUSE 12.2). >>> >>> You do need multiple CPU/multi-core machine, as I got it. >> >> Which is what I have. > > Then try to build *vanilla* git 1.8.0, Which is what I did. > not OpenSuSE's one (with a lot of patches inside srcrpm

Re: "git am" crash (builtin/apply.c:2108) + small repro

Alexey Spiridonov writes: > Thanks for looking into this, guys! > > I seem to run into this with some regularity, but my setting is > apply.whitespace=strip rather than 'fix'. 'strip' is an old synonym for 'fix'. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a

What's cooking in git.git (Nov 2012, #04; Wed, 14)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Big thanks go to Jeff who curated topics in flight while I was on vacation. I merged a couple of topics to 'next', and will start merging what

Re: creation of empty branches

Andrew Ardill writes: > Since git branch has the default behaviour to create a branch 'in the > background' it makes sense to fail when trying to create a new branch > this way from an empty branch. The error message should be improved to > handle this edge case in a nicer way. If we allow for re

Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)

On 14.11.12 20:02, Jeff King wrote: > On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote: > >> On 11/13/2012 03:45 PM, Torsten Bögershausen wrote: * ml/cygwin-mingw-headers (2012-11-12) 1 commit - Update cygwin.c for new mingw-64 win32 api headers Make git work on

Re: git init shared=group with a subdir

pete...@bigfoot.com writes: > $ ls -ld subdir > ls: cannot access subdir: No such file or directory > $ git init --bare --shared=group subdir/test.git > Initialized empty shared Git repository in /tmp/subdir/test.git/ > $ ls -ld subdir subdir/test.git > drwxr-xr-x 3 pete users 4096 201

Re: [PATCH 6/6] send-email: do not prompt for explicit repo ident

On Wed, Nov 14, 2012 at 12:05:05PM -0800, Jeff King wrote: > > When someone writes such a test, I think it could check that git > > either prompts or writes a message advising to configure the user > > email, no? Waiting until later for that seems fine to me, though. > > Yes. The problem is that

Re: Bug? Subtree merge seems to choke on trailing slashes.

"Jack O'Connor" writes: > Do I have the right list for bug reports? Apologies if not. Yes. > On Tue, Nov 6, 2012 at 5:58 PM, Jack O'Connor wrote: >> >> 2) I try to merge more upstream changes on top of that with the >> following command: >> git merge --strategy-option=subtree='test/' $upstream

git init shared=group with a subdir

I believe there may be a bug when initializing a new repository relating to the directory permissions when the --shared=group option is used and the repository is within a sub-directory. The following will create the "test.git" directory with 2775 permissions (which is as expected): $ ls -

Re: [PATCH 6/6] send-email: do not prompt for explicit repo ident

On Wed, Nov 14, 2012 at 09:18:27AM -0800, Jonathan Nieder wrote: > > The test scripts need to be adjusted to not expect a prompt > > for the sender, since they always have the author explicitly > > defined in the environment. Unfortunately, we cannot > > reliably test that prompting still happens

Re: [PATCHv3 3/4] git-status: show short sequencer state

Junio C Hamano writes: > Phil Hord writes: > >> # tokens and short-status >> $ git status --tree --short >> ## changed-files >>M foo.txt > > Hrm, how will the existing readers of the output avoid getting > confused by this overloading of "##", which has meant the current > branch inf

Re: [PATCH 5/6] Git.pm: teach "ident" to query explicitness

On Wed, Nov 14, 2012 at 09:12:13AM -0800, Jonathan Nieder wrote: > > --- a/perl/Git.pm > > +++ b/perl/Git.pm > > @@ -737,7 +737,7 @@ sub remote_refs { > > } > > > > > > -=item ident ( TYPE | IDENTSTR ) > > +=item ident ( TYPE | IDENTSTR [, options] ) > > > > =item ident_person ( TYPE | IDE

Re: [PATCH 4/6] var: provide explicit/implicit ident information

On Wed, Nov 14, 2012 at 09:06:57AM -0800, Jonathan Nieder wrote: > Jeff King wrote: > > > Internally, we keep track of whether the author or committer > > ident information was provided by the user, or whether it > > was implicitly determined by the system. However, there is > > currently no way

Re: [PATCHv3 3/4] git-status: show short sequencer state

Phil Hord writes: > # tokens and short-status > $ git status --tree --short > ## changed-files >M foo.txt Hrm, how will the existing readers of the output avoid getting confused by this overloading of "##", which has meant the current branch information? > # tokens only? > $ git

Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace

Am 13.11.2012 20:50, schrieb Linus Torvalds: On Tue, Nov 13, 2012 at 11:40 AM, Linus Torvalds wrote: I have to wonder why you care? As far as I'm concerned, the only valid space is space, TAB and CR/LF. Anything else is *noise*, not space. What's the reason for even caring? Btw, expanding t

Re: [PATCH 3/6] var: accept multiple variables on the command line

On Wed, Nov 14, 2012 at 09:01:48AM -0800, Jonathan Nieder wrote: > > DESCRIPTION > > --- > > -Prints a git logical variable. > > +Prints one or more git logical variables, separated by newlines. > > + > > +Note that some variables may contain newlines themselves > > Maybe a -z option to

Re: [PATCHv3 3/4] git-status: show short sequencer state

Junio C Hamano wrote: > Phil Hord writes: > >> Consider the usage: >> >> git status # show work-tree status >> git status --short # show short work-tree status >> git status --tokens # show work-tree status in token form > OK, your --tokens is more about *how* things are output, but it

Re: [PATCH 1/6] ident: make user_ident_explicitly_given private

On Wed, Nov 14, 2012 at 08:44:57AM -0800, Jonathan Nieder wrote: > > -#define IDENT_NAME_GIVEN 01 > > -#define IDENT_MAIL_GIVEN 02 > > -#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN) > > -extern int user_ident_explicitly_given; > > extern int user_ident_sufficiently_given(void); > >

Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)

On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote: > On 11/13/2012 03:45 PM, Torsten Bögershausen wrote: > >>* ml/cygwin-mingw-headers (2012-11-12) 1 commit > >> - Update cygwin.c for new mingw-64 win32 api headers > >> > >> Make git work on newer cygwin. > >> > >> Will merge to 'ne

Re: [PATCH] docs: move submodule section

On Wed, Nov 14, 2012 at 10:49:04AM -0800, Matt Kraai wrote: > 293ab15e ("submodule: teach rm to remove submodules unless they > contain a git directory", 2012-09-26) inserted the "Submodules" > section between a sentence describing a command and the command. Move > the "Submodules" section further

[PATCH] docs: move submodule section

293ab15e ("submodule: teach rm to remove submodules unless they contain a git directory", 2012-09-26) inserted the "Submodules" section between a sentence describing a command and the command. Move the "Submodules" section further down. Signed-off-by: Matt Kraai --- Documentation/git-rm.txt |

v1.8.0-150-gb0b00a3: Weird documentation for git-rm

The file Documentation/git-rm.txt says: ---8>< 8><--- Using ``git add -A'' When accepting a new code drop for a vendor branch, you probably want to record both the removal of paths and additions of new paths as well as modifications of existing paths. Typically you wo

Re: [regression] Newer gits cannot clone any remote repos

>>> I cannot reproduce the problem (on openSUSE 12.2). >> >> You do need multiple CPU/multi-core machine, as I got it. > > Which is what I have. Then try to build *vanilla* git 1.8.0, not OpenSuSE's one (with a lot of patches inside srcrpm). -- To unsubscribe from this list: send the line "unsubsc

Re: push branch descriptions

"Pyeron, Jason J CTR (US)" writes: >> > Imagine the project creates a branch "magic" to enhance its system >> > with magic words. The description for the "magic" branch in the >> > project may say "support magic words" or something. >> > >> > You and your friend are tasked to add a handful of ma

Re: [PATCHv3 3/4] git-status: show short sequencer state

Phil Hord writes: > Consider the usage: > > git status # show work-tree status > git status --short # show short work-tree status > git status --tokens # show work-tree status in token form OK, your --tokens is more about *how* things are output, but it is unclear how it would interact

Re: [PATCH v3 0/5] push: update remote tags only with force

Angelo Borsotti writes: > actually, I proposed to add a key in config files, e.g. > pushTagsNoChange to be set in the remote repo do disallow changes to > tags, similar to pushNonFastForward that disallows non-fastforward > changes to branches. I still have the impression that this is simple > an

RE: push branch descriptions

> -Original Message- > From: Angelo Borsotti > Sent: Wednesday, November 14, 2012 9:51 AM > > Hi Junio, > > > It would conceptually be a lot cleaner to treat updating of remote > > Ibranch description as a separate "repository management" class of > > Ioperation, similar to setting the re

Re: [PATCH 6/6] send-email: do not prompt for explicit repo ident

Jeff King wrote: > If git-send-email is configured with sendemail.from, we will > not prompt the user for the "From" address of the emails. > If it is not configured, we prompt the user, but provide the > repo author or committer as a default. Even though we > probably have a sensible value for t

Re: [PATCH 5/6] Git.pm: teach "ident" to query explicitness

Jeff King wrote: > "git var" recently learned to report on whether an ident we > fetch from it was configured explicitly or implicitly. Let's > make that information available to callers of the ident > function. Sounds sensible. Quick nits: [...] > --- a/perl/Git.pm > +++ b/perl/Git.pm > @@ -73

Re: [PATCH 4/6] var: provide explicit/implicit ident information

Jeff King wrote: > Internally, we keep track of whether the author or committer > ident information was provided by the user, or whether it > was implicitly determined by the system. However, there is > currently no way for external programs or scripts to get > this information What are the inten

Re: [PATCH 3/6] var: accept multiple variables on the command line

Jeff King wrote: > This patch lets callers specify multiple variables, and > prints one per line. Yay! [...] > --- a/Documentation/git-var.txt > +++ b/Documentation/git-var.txt > @@ -9,11 +9,16 @@ git-var - Show a git logical variable > SYNOPSIS > > [verse] > -'git var' ( -l | ) > +

Re: [PATCH 1/6] ident: make user_ident_explicitly_given private

Jeff King wrote: > There are no users of this global variable, as queriers > go through the user_ident_sufficiently_given accessor. > Let's make it private, which will enable further > refactoring. [...] > --- a/cache.h > +++ b/cache.h > @@ -1149,10 +1149,6 @@ struct config_include_data { > #defi

Re: [regression] Newer gits cannot clone any remote repos

Douglas Mencken writes: >> I cannot reproduce the problem (on openSUSE 12.2). > > You do need multiple CPU/multi-core machine, as I got it. Which is what I have. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now

Re: [regression] Newer gits cannot clone any remote repos

> I cannot reproduce the problem (on openSUSE 12.2). You do need multiple CPU/multi-core machine, as I got it. -- 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 v3 0/5] push: update remote tags only with force

Hi Junio, actually, I proposed to add a key in config files, e.g. pushTagsNoChange to be set in the remote repo do disallow changes to tags, similar to pushNonFastForward that disallows non-fastforward changes to branches. I still have the impression that this is simple and clear, and allows the o

Re: push branch descriptions

Hi Junio, > It would conceptually be a lot cleaner to treat updating of remote > Ibranch description as a separate "repository management" class of > Ioperation, similar to setting the repository description stored in > I$GIT_DIR/description. I agree, it should be a distinct operation. I was thin

Re: push branch descriptions

Angelo Borsotti writes: > currently, there is no means to push a branch description to a remote > repository. It is possible to create a branch, but not to set its > description. Correct. You have to go to the remote repository and run "git branch --edit-description" there; there is currently n

Re: push branch descriptions

Ramkumar Ramachandra venit, vidit, dixit 14.11.2012 11:33: > Hi, > > Angelo Borsotti wrote: >> currently, there is no means to push a branch description to a remote >> repository. It is possible to create a branch, but not to set its >> description. >> Would not be more correct to push also branch

Re: [PATCHv3 3/4] git-status: show short sequencer state

Junio C Hamano wrote: > Phil Hord writes: > >>> Do you think '--tree-state' is an acceptable switch or do you have other >>> suggestions? >> I've been calling these 'tokens' myself. A token is a word-or-phrase I >> can parse easily with the default $IFS, for simpler script handling. > That name m

Re: [PATCHv3 3/4] git-status: show short sequencer state

Phil Hord writes: >> Do you think '--tree-state' is an acceptable switch or do you have other >> suggestions? > > I've been calling these 'tokens' myself. A token is a word-or-phrase I > can parse easily with the default $IFS, for simpler script handling. That name may be good for variables, bu

Re: bug? git format-patch -M -D then git am fails

Junio C Hamano venit, vidit, dixit 14.11.2012 00:22: > Joe Perches writes: > >> I don't believe that reversibility >> is a really useful aspect of deletion patches >> when there are known git repositories involved. > > You can read "reversibility" as "safety" if you want. We would want > to mak

Re: [PATCH v3 0/5] push: update remote tags only with force

Chris Rorvick writes: >> "Do not update, only add new" may be a good feature, but at the same >> time I have this suspicion that its usefulness may not necessarily >> be limited to refs/tags/* hierarchy. >> >> I dunno. > > Are you suggesting allowing forwards for just refs/heads/*? No, it is a n

Re: Notes in format-patch

Michael J Gruber writes: > Junio C Hamano venit, vidit, dixit 13.11.2012 19:09: >> Junio C Hamano writes: >> >>> ... and it is broken X-<. >>> >>> The blank line should be added before the diffstat, not after the >>> notes message (t3307 shows a case where we give notes without >>> diffstat, an

RE: Unable to compile Git on HP-UX B.11.31 U ia64

Hello Stefano, Thank you for your quick answer. You are right, HP-UX have a gmake executable : #gmake --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FIT

Re: Unable to compile Git on HP-UX B.11.31 U ia64

On 11/14/2012 12:18 PM, Quintin Ronan wrote: > Hello, > > I’m trying to compile git 1.7 on a HPUX server using make. > The ./configure worked well : > > [SNIP] > > But when i run make (with –d) it simply doesn’t work with a message > which isn’t really helpfull : > > [SNIP] > Make: line 313:

Unable to compile Git on HP-UX B.11.31 U ia64

Hello, I’m trying to compile git 1.7 on a HPUX server using make. The ./configure worked well : configure: Setting lib to 'lib' (the default) configure: Will try -pthread then -lpthread to enable POSIX Threads. configure: CHECKS for site configuration configure: CHECKS for programs checking for

Re: Git does not understand absolute Win'dos' path

Am 11/14/2012 10:12, schrieb Martin Lichtin: > Maven's release plugin prepares a call Git like in this example: > > cmd.exe /X /C "git commit --verbose -F > C:\cygwin\tmp\maven-scm-915771020.commit pom.xml" > > Git doesn't seem to understand the -F argument and treats it like a > relative path (r

Re: Notes in format-patch

Junio C Hamano venit, vidit, dixit 13.11.2012 19:09: > Junio C Hamano writes: > >> ... and it is broken X-<. >> >> The blank line should be added before the diffstat, not after the >> notes message (t3307 shows a case where we give notes without >> diffstat, and we shouldn't be adding an extra bl

Git does not understand absolute Win'dos' path

Hi Maven's release plugin prepares a call Git like in this example: cmd.exe /X /C "git commit --verbose -F C:\cygwin\tmp\maven-scm-915771020.commit pom.xml" Git doesn't seem to understand the -F argument and treats it like a relative path (relative to the repository root): $ cmd.exe /X /C "gi

Re: [PATCH v3 0/5] push: update remote tags only with force

On Wed, Nov 14, 2012 at 12:29:14AM -0600, Chris Rorvick wrote: > >> 2. Require force when updating tag references, even on a fast-forward. > >> push: flag updates > >> push: flag updates that require force > >> push: update remote tags only with force > >> An email thread i