Re: [RFC] git rm -u

2013-01-21 Thread Piotr Krukowiecki
On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano gits...@pobox.com wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Implementing git rm -u as a tree-wide command would create a discrepancy with git add -u. Implementing it as a current directory command would make the migration harder

[PATCH] mergetools: Add tortoisegitmerge helper

2013-01-21 Thread Sven Strickroth
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe (starting with 1.8.0) in order to make clear that this one has special support for git and prevent confusion with the TortoiseSVN TortoiseMerge version. - The tortoisemerge mergetool does not work with filenames which

[PATCH] mergetools: Add tortoisegitmerge helper

2013-01-21 Thread Sven Strickroth
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe (starting with 1.8.0) in order to make clear that this one has special support for git and prevent confusion with the TortoiseSVN TortoiseMerge version. - The tortoisemerge mergetool does not work with filenames which

Re: [RFC] git rm -u

2013-01-21 Thread Matthieu Moy
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Do you mean git add will be disallowed without . or :/ argument? Or will this change in future and git add without argument will me whole tree, same as :/ ? Let's talk conditional, not future, for now. If the idea is to change the

[PATCH v2 00/10] unify appending of sob

2013-01-21 Thread Brandon Casey
Here's version 2 of the unify-appending-of-sob series. Hopefully this addresses the comments made on the first series: http://thread.gmane.org/gmane.comp.version-control.git/210390 The main difference is that the detection of the (cherry picked from ...) line has been relaxed, and the

[PATCH v2 01/10] sequencer.c: remove broken support for rfc2822 continuation in footer

2013-01-21 Thread Brandon Casey
Commit c1e01b0c generalized the detection of the last paragraph signed-off-by footer and used rfc2822 as a guideline. Support for rfc2822 style continuation lines was also implemented, but not correctly, so it has never detected a line beginning with space or tab as a continuation of the previous

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

2013-01-21 Thread Brandon Casey
The message 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 bca...@nvidia.com --- t/test-lib-functions.sh | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff

[PATCH v2 03/10] t/t3511: add some tests of 'cherry-pick -s' functionality

2013-01-21 Thread Brandon Casey
Add some tests to ensure that 'cherry-pick -s' operates in the following manner: * Inserts a blank line before appending a s-o-b to a commit message that does not contain a s-o-b footer * Does not mistake first line subject: description as a s-o-b footer * Does not mistake single

Re: git interactive rebase 'consume' command

2013-01-21 Thread Stephen Kelly
Junio C Hamano wrote: Stephen Kelly steve...@gmail.com writes: One scenario is something like this: Start with a clean HEAD (always a good idea :) ) hack hack hack make multiple commits realize that a hunk you committed in an early patch belongs in a later one. use git rebase -i to

[PATCH v2 04/10] sequencer.c: recognize (cherry picked from ... as part of s-o-b footer

2013-01-21 Thread Brandon Casey
When 'cherry-pick -s' is used to append a signed-off-by line to a cherry picked commit, it does not currently detect the (cherry picked from... that may have been appended by a previous 'cherry-pick -x' as part of the s-o-b footer and it will insert a blank line before appending a new s-o-b.

[PATCH v2 05/10] sequencer.c: always separate (cherry picked from from commit body

2013-01-21 Thread Brandon Casey
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. Introduce tests to test this functionality. Signed-off-by: Brandon Casey bca...@nvidia.com ---

[PATCH v2 06/10] sequencer.c: teach append_signoff how to detect duplicate s-o-b

2013-01-21 Thread Brandon Casey
Teach append_signoff how to detect a duplicate s-o-b in the commit footer. This is in preparation to unify the append_signoff implementations in log-tree.c and sequencer.c. Fixes test in t3511. Signed-off-by: Brandon Casey bca...@nvidia.com --- builtin/commit.c | 2 +- sequencer.c

[PATCH v2 07/10] sequencer.c: teach append_signoff to avoid adding a duplicate newline

2013-01-21 Thread Brandon Casey
Teach append_signoff to detect whether a blank line exists at the position that the signed-off-by line will be added, and avoid adding an additional one if one already exists. This is necessary to allow format-patch to add a s-o-b to a patch with no commit message without adding an extra newline.

[PATCH v2 08/10] t4014: more tests about appending s-o-b lines

2013-01-21 Thread Brandon Casey
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com [bc: Squash the tests from Duy's original unify-appending-sob series. Fix test 90 signoff: some random signoff-alike and mark as failing. Correct behavior should insert a blank line after message body and signed-off-by. Add two

[PATCH v2 09/10] format-patch: update append_signoff prototype

2013-01-21 Thread Brandon Casey
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com This is a preparation step for merging with append_signoff from sequencer.c Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com Signed-off-by: Brandon Casey bca...@nvidia.com --- builtin/log.c | 13 + log-tree.c| 14 ++

Re: [RFC] git rm -u

2013-01-21 Thread Matthieu Moy
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: git add -u is one of the only exceptions (with git grep). I consider this as a bug, and think this should be changed. This has been discussed several times here, but no one took the time to actually do

Re: [RFC] git rm -u

2013-01-21 Thread Junio C Hamano
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Do you mean git add will be disallowed without . or :/ argument? Or will this change in future and git add without argument will me whole tree, same as :/ ? No. This is only about git add -uRETURN, not any other forms of git add ...with

Re: git-cvsimport-3 and incremental imports

2013-01-21 Thread John Keeping
On Sun, Jan 20, 2013 at 06:20:08PM -0500, Eric S. Raymond wrote: John Keeping j...@keeping.me.uk: I don't think there is any way to solve this without giving cvsps more information, probably the last commit time for all git branches, but perhaps I'm missing a fast-import feature that can help

Re: git-cvsimport-3 and incremental imports

2013-01-21 Thread Eric S. Raymond
John Keeping j...@keeping.me.uk: But this is nothing more than a sticking plaster that happens to do enough in this particular case I'm beginning to think that's the best outcome we ever get in this problem domain... - if the Git repository happened to be on a different

Re: git-cvsimport-3 and incremental imports

2013-01-21 Thread John Keeping
On Mon, Jan 21, 2013 at 06:28:53AM -0500, Eric S. Raymond wrote: John Keeping j...@keeping.me.uk: But this is nothing more than a sticking plaster that happens to do enough in this particular case I'm beginning to think that's the best outcome we ever get in this problem domain... I don't

Re: git-cvsimport-3 and incremental imports

2013-01-21 Thread Eric S. Raymond
John Keeping j...@keeping.me.uk: I also disagree that cvsps outputs commits *newer* than T since it will also output commits *at* T, which is what I changed with the patch in my previous message. Ah. OK, that is yet another bug inherited from 2.x - the code doesn't match the documented (and

Re: git-cvsimport-3 and incremental imports

2013-01-21 Thread John Keeping
On Mon, Jan 21, 2013 at 07:43:40AM -0500, Eric S. Raymond wrote: John Keeping j...@keeping.me.uk: I also disagree that cvsps outputs commits *newer* than T since it will also output commits *at* T, which is what I changed with the patch in my previous message. Ah. OK, that is yet another

Re: GIT get corrupted on lustre

2013-01-21 Thread Erik Faye-Lund
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland eric.chamberl...@giref.ulaval.ca wrote: Good idea! I did a strace and here is the output with the error: http://www.giref.ulaval.ca/~ericc/strace_git_error.txt Hope it will be insightful! This trace doesn't seem to contain child-processes,

[PATCH] git-for-each-ref.txt: 'raw' is a supported date format

2013-01-21 Thread John Keeping
Commit 7dff9b3 (Support 'raw' date format) added a raw date format. Update the git-for-each-ref documentation to include this. Signed-off-by: John Keeping j...@keeping.me.uk --- Documentation/git-for-each-ref.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: git-cvsimport-3 and incremental imports

2013-01-21 Thread Eric S. Raymond
John Keeping j...@keeping.me.uk: Ah. OK, that is yet another bug inherited from 2.x - the code doesn't match the documented (and correct) behavior. Please send me a patch against the cvsps repo, I'll merge it. Should now be in your inbox. Received, merged, tested, and cvsps-3.10 has

Re: [PATCH v3 0/2] Make git-svn work with gitdir links

2013-01-21 Thread Joachim Schmitz
Junio C Hamano wrote: Barry Wardell barry.ward...@gmail.com writes: These patches fix a bug which prevented git-svn from working with repositories which use gitdir links. Changes since v2: - Rebased onto latest master. - Added test case which verifies that the problem has been fixed. -

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Robin Rosenberg
- Ursprungligt meddelande - Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. The inconsistancy of 'git add

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Matthieu Moy
Robin Rosenberg robin.rosenb...@dewire.com writes: git add -u without filepattern is, I believe very common, so no noisy output there please. What are you exactly suggesting? That we keep the inconsistant semantics of git add -u or git add -A? Or another migration plan? git diff #looks good

Re: [PATCH] git-for-each-ref.txt: 'raw' is a supported date format

2013-01-21 Thread Michael Haggerty
On 01/21/2013 02:53 PM, John Keeping wrote: Commit 7dff9b3 (Support 'raw' date format) added a raw date format. Update the git-for-each-ref documentation to include this. Signed-off-by: John Keeping j...@keeping.me.uk --- Documentation/git-for-each-ref.txt | 2 +- 1 file changed, 1

Re: GIT get corrupted on lustre

2013-01-21 Thread Thomas Rast
Erik Faye-Lund kusmab...@gmail.com writes: On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland eric.chamberl...@giref.ulaval.ca wrote: Good idea! I did a strace and here is the output with the error: http://www.giref.ulaval.ca/~ericc/strace_git_error.txt Hope it will be insightful! This

Re: GIT get corrupted on lustre

2013-01-21 Thread Maxime Boissonneault
Hi Thomas, Can you tell me what is the version of the lustre servers and the lustre clients ? Thanks, Maxime Boissonneault HPC specialist @ Calcul Québec. Le 2013-01-21 11:11, Thomas Rast a écrit : Erik Faye-Lund kusmab...@gmail.com writes: On Fri, Jan 18, 2013 at 6:50 PM, Eric

Re: GIT get corrupted on lustre

2013-01-21 Thread Thomas Rast
Maxime Boissonneault maxime.boissonnea...@calculquebec.ca writes: Hi Thomas, Can you tell me what is the version of the lustre servers and the lustre clients ? $ uname -a Linux brutus4.ethz.ch 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ cat

[PATCH v2] git-for-each-ref.txt: 'raw' is a supported date format

2013-01-21 Thread John Keeping
Commit 7dff9b3 (Support 'raw' date format) added a raw date format. Update the git-for-each-ref documentation to include this. Signed-off-by: John Keeping j...@keeping.me.uk --- On Mon, Jan 21, 2013 at 05:02:52PM +0100, Michael Haggerty wrote: Shouldn't raw be preceded with a colon like the

Re: [PATCH 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)

2013-01-21 Thread Torsten Bögershausen
Sorry for completely messing up the sensitvie/insensiteve Please discard my patch from pu, I'll send v2. Sorry for the confusion /Torsten -- 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

[PATCH v2 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)

2013-01-21 Thread Torsten Bögershausen
The test case add (with different case) indicates a known breakage when run on a case insensitive file system. The test is invalid for case sensitive file system, it will always fail. Check the precondition CASE_INSENSITIVE_FS before running it. Signed-off-by: Torsten Bögershausen tbo...@web.de

[PATCH v2 3/3] t0050: Use TAB for indentation

2013-01-21 Thread Torsten Bögershausen
Use one TAB for indentation and remove empty lines Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t0050-filesystem.sh | 48 +++- 1 file changed, 15 insertions(+), 33 deletions(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh

Re: GIT get corrupted on lustre

2013-01-21 Thread Eric Chamberland
Hi, It just happened again. Now I have the strace -f output gzipped here: http://www.giref.ulaval.ca/~ericc/strace-f_git_error.txt.gz thanks, Eric On 01/21/2013 08:29 AM, Erik Faye-Lund wrote: On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland eric.chamberl...@giref.ulaval.ca wrote: Good

Re: GIT get corrupted on lustre

2013-01-21 Thread Eric Chamberland
On 01/21/2013 12:07 PM, Eric Chamberland wrote: Hi, It just happened again. Now I have the strace -f output gzipped here: http://www.giref.ulaval.ca/~ericc/strace-f_git_error.txt.gz I added the strace -f output when non error occurs...

[PATCH v2 0/6] GIT, Git, git

2013-01-21 Thread Thomas Ackermann
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the Git system. So change every occurrence of 'GIT and

[PATCH v2 1/6] Change old system name 'GIT' to 'Git'

2013-01-21 Thread Thomas Ackermann
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). So change every occurrence of 'GIT in the documention to 'Git'. Signed-off-by: Thomas Ackermann th.ac...@arcor.de ---

Aw: [PATCH v2 0/6] GIT, Git, git

2013-01-21 Thread Thomas Ackermann
Please ignore these series ... there are still problems with the size of the patches :-| - Original Nachricht Von: Thomas Ackermann th.ac...@arcor.de An: gits...@pobox.com, th.ac...@arcor.de Datum: 21.01.2013 19:36 Betreff: [PATCH v2 0/6] GIT, Git, git Git changed its

Re: GIT get corrupted on lustre

2013-01-21 Thread Brian J. Murrell
On 13-01-21 11:11 AM, Thomas Rast wrote: What's odd is that while I cannot reproduce the original problem, there seems to be another issue/bug with utime(): I wonder if this is related to http://jira.whamcloud.com/browse/LU-305. That was reported as fixed in Lustre 2.0.0 and 2.1.0 but I

Re: [RFC] git rm -u

2013-01-21 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Do you mean git add will be disallowed without . or :/ argument? Or will this change in future and git add without argument will me whole tree, same as :/ ? No. This is only about git add

[PATCH] l10n: de.po: fix some minor issues

2013-01-21 Thread Ralf Thielow
This fixes some minor issues and improves the German translation a bit. The following things were changed: - use complete sentences in option related messages - translate use consistently as verwendet - don't translate make sense as macht Sinn Signed-off-by: Ralf Thielow ralf.thie...@gmail.com

Re: git interactive rebase 'consume' command

2013-01-21 Thread Stephen Kelly
On 01/21/2013 12:05 PM, Michael Haggerty wrote: It is perverse to have to turn a well-defined and manifestly conflict-free wish into one that has a good chance of conflicting, just because of a limitation of the tool. Yes, I agree. I would prefer to be able to mark a commit as 'should be

Re: [RFC] git rm -u

2013-01-21 Thread Piotr Krukowiecki
On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano gits...@pobox.com wrote: No. This is only about git add -uRETURN, not any other forms of git add ...with or without other args git add -uRETURN historically meant, and it still means, to update the index with every change in the working

[PATCH v3 0/6] GIT, Git, git

2013-01-21 Thread Thomas Ackermann
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the Git system. So change every occurrence of 'GIT and

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Junio C Hamano
Matthieu Moy matthieu@imag.fr writes: Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. The inconsistancy of 'git

[PATCH v3 1/6] Change old system name 'GIT' to 'Git'

2013-01-21 Thread Thomas Ackermann
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). So change every occurrence of 'GIT in the documention to 'Git'. Signed-off-by: Thomas Ackermann th.ac...@arcor.de ---

Re: [PATCH] l10n: de.po: fix some minor issues

2013-01-21 Thread Thomas Rast
Ralf Thielow ralf.thie...@gmail.com writes: This fixes some minor issues and improves the German translation a bit. The following things were changed: - use complete sentences in option related messages - translate use consistently as verwendet - don't translate make sense as macht Sinn

[PATCH v3 6/6] Add rule for when to use 'git' and when to use 'Git'

2013-01-21 Thread Thomas Ackermann
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/CodingGuidelines | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 5e60daf..4f40b44 100644 --- a/Documentation/CodingGuidelines +++

Re: [PATCH 1/2] Update :/abc ambiguity check

2013-01-21 Thread Junio C Hamano
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: :/abc may mean two things: - as a revision, it means the revision that has abc in commit message. - as a pathpec, it means abc from root. Currently we see :/abc as a rev (most of the time), but never see it as a pathspec even if abc

Re: GIT get corrupted on lustre

2013-01-21 Thread Thomas Rast
Please don't drop the Cc list! Brian J. Murrell br...@interlinx.bc.ca writes: What's odd is that while I cannot reproduce the original problem, there seems to be another issue/bug with utime(): I wonder if this is related to http://jira.whamcloud.com/browse/LU-305. That was reported as

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Piotr Krukowiecki
On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano gits...@pobox.com wrote: Matthieu Moy matthieu@imag.fr writes: Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep',

Re: [PATCH v2 0/6] GIT, Git, git

2013-01-21 Thread Junio C Hamano
Thomas Ackermann th.ac...@arcor.de writes: Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Didn't I already say that we never changed the name? The same description

Re: [PATCH v2 0/6] GIT, Git, git

2013-01-21 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Thomas Ackermann th.ac...@arcor.de writes: Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Didn't I already say that we

Re: [RFC] git rm -u

2013-01-21 Thread Matthieu Moy
Junio C Hamano gits...@pobox.com writes: But v1.5.2.5~1 (git-add -u paths... now works from subdirectory, 2007-08-16) changed the semantics to limit the operation to the working tree. Not really. It fixed git add -u path, not plain git add -u. A quick test checking out and compiling

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Matthieu Moy
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Another issue is usability. Can we definitely say which is better: add all changes from current subdir, or add all changes from whole tree? I don't know. Hard to tell, depending on users, use-case, ... But the good news is: whatever

[PATCHv2] l10n: de.po: fix some minor issues

2013-01-21 Thread Ralf Thielow
This fixes some minor issues and improves the German translation a bit. The following things were changed: - use complete sentences in option related messages - translate use consistently as verwendet - don't translate make sense as macht Sinn Signed-off-by: Ralf Thielow ralf.thie...@gmail.com

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Matthieu Moy
Junio C Hamano gits...@pobox.com writes: Wouldn't we achieve the same consistency across modes of add if we made them relative to the current directory? As other people already said, it would be nice to have consistency accross most if not all commands. AFAICT, the only exceptions to tree-wide

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Robin Rosenberg
- Ursprungligt meddelande - git diff #looks good git add -u That's indeed the kind of mistake I'd like to avoid. In your example, git diff is tree-wide, and git add -u is limited to ., so in general git add -u won't stage the same thing as git diff just showed. Good point.

Re: [PATCH v3 0/2] Make git-svn work with gitdir links

2013-01-21 Thread Philip Oakley
From: Joachim Schmitz j...@schmitz-digital.de Sent: Monday, January 21, 2013 2:19 PM Junio C Hamano wrote: Barry Wardell barry.ward...@gmail.com writes: [...] Thanks for your persistence ;-) As this is a pretty old topic, I'll give two URLs for people who are interested to view the previous

Re: [PATCH v3 0/2] Make git-svn work with gitdir links

2013-01-21 Thread Junio C Hamano
Philip Oakley philipoak...@iee.org writes: From: Joachim Schmitz j...@schmitz-digital.de Sent: Monday, January 21, 2013 2:19 PM Junio C Hamano wrote: Barry Wardell barry.ward...@gmail.com writes: [...] Thanks for your persistence ;-) As this is a pretty old topic, I'll give two URLs for

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Jonathan Nieder
Hi, Matthieu Moy wrote: The inconsistancy of 'git add -u' and 'git add -A' are particularly problematic since other 'git add' subcommands (namely 'git add -p' and 'git add -e') are tree-wide by default. Flipping the default now is unacceptable, so this patch starts training users to type

[RFC] Instruct git-completion.bash that we are in test mode

2013-01-21 Thread Jean-Noël AVILA
In test mode, git completion should only propose core commands. Signed-off-by: Jean-Noel Avila jn.av...@free.fr --- I reworked the patch so that the test argument is only evaluated when sourcing the file and there is no environment clutter. At least, it works for me.

Re: [PATCH 0/2] Hiding some refs in ls-remote

2013-01-21 Thread Jeff King
On Sat, Jan 19, 2013 at 11:16:00AM -0800, Junio C Hamano wrote: For example, if you mirror-clone from either of my repositories from GitHub: git clone --mirror git://github.com/git/git/ git clone --mirror git://github.com/gitster/git/ you will see stuff that does not belong to

Re: [PATCH 0/2] Hiding some refs in ls-remote

2013-01-21 Thread Jeff King
On Sun, Jan 20, 2013 at 02:08:32PM -0800, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: [uploadPack] hiderefs = refs/changes Would you want to do the same thing on receive-pack? It could benefit from the same reduction

Re: [PATCH 0/2] Hiding some refs in ls-remote

2013-01-21 Thread Jeff King
On Sun, Jan 20, 2013 at 10:06:33AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: [uploadPack] hiderefs = refs/changes Would you want to do the same thing on receive-pack? It could benefit from the same reduction in network cost (although it tends to be

Re: [PATCH v3 08/31] parse_pathspec: add PATHSPEC_EMPTY_MATCH_ALL

2013-01-21 Thread Martin von Zweigbergk
Hi, I was tempted to ask this before, and the recent thread regarding add -u/A [1] convinced me to. On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: We have two ways of dealing with empty pathspec: 1. limit it to current prefix 2. match the entire working

Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content

2013-01-21 Thread Jeff King
On Mon, Jan 21, 2013 at 06:40:33PM +0700, Nguyen Thai Ngoc Duy wrote: + /* + * If it has the same content that we are going to overwrite, + * there's no point in complaining. We still overwrite it in + * the end though. + */ + if (ce +

Re: [RFC] git rm -u

2013-01-21 Thread Junio C Hamano
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: But v1.5.2.5~1 (git-add -u paths... now works from subdirectory, 2007-08-16) changed the semantics to limit the operation to the working tree. Not really. It fixed git add -u path, not plain git add

Re: [RFC] Instruct git-completion.bash that we are in test mode

2013-01-21 Thread Junio C Hamano
Jean-Noël AVILA jn.av...@free.fr writes: At least, it works for me. I suspect that your approach will still not fix the case in which you build a branch with a new command git-check-ignore, and then check out another branch that does not yet have that command without first running make clean.

Re: [PATCH 0/2] Hiding some refs in ls-remote

2013-01-21 Thread Junio C Hamano
Jeff King p...@peff.net writes: It may even make sense to have git push honor it, excluding them from git push --mirror (or git push --all if some of the branches are hidden); I haven't thought things through, though. That is harder, as that is something that happens on the client. How does

Re: [PATCH v6 0/8] push: update remote tags only with force

2013-01-21 Thread Junio C Hamano
Jeff King p...@peff.net writes: ... The problem there is not already exists but rather a blob is not something that can fast-forward. Using the existing REJECT_NONFASTFORWARD is insufficient (because later code will recommend pull-then-push, which is wrong). So I'd be in favor of creating a

Re: [PATCH v3 1/6] Change old system name 'GIT' to 'Git'

2013-01-21 Thread Junio C Hamano
Thomas Ackermann th.ac...@arcor.de writes: Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). So change every occurrence of 'GIT in the documention to 'Git'.

Re: [PATCH v3 2/6] Change 'git' to 'Git' whenever the whole system is referred to #1

2013-01-21 Thread Junio C Hamano
Thomas Ackermann th.ac...@arcor.de writes: Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Forgot --stat? It helps to check the integrity of patch application and also helps anticipating possible interaction with other topics in flight. Please don't omit it. -- To unsubscribe from this

Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content

2013-01-21 Thread Duy Nguyen
On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote: Can you elaborate on when this code is triggered? In the general case, shouldn't we already know the sha1 of what's on disk in the index, and be able to just compare the hashes? And if we don't, because the entry is start-dirty,

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Duy Nguyen
On Mon, Jan 21, 2013 at 7:00 PM, Matthieu Moy matthieu@imag.fr wrote: Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.

Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content

2013-01-21 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes: On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote: Can you elaborate on when this code is triggered? In the general case, shouldn't we already know the sha1 of what's on disk in the index, and be able to just compare the hashes? And if we

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes: What about 'grep' and 'clean'? I think at least 'clean' should go tree-wide default too. I don't mind grep go the same way either but I think people voiced preference in current behavior.. I think the major argument for git grep to be the way it is is

Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content

2013-01-21 Thread Duy Nguyen
On Tue, Jan 22, 2013 at 8:45 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote: Can you elaborate on when this code is triggered? In the general case, shouldn't we already know the sha1 of what's on

Re: [PATCH v3 08/31] parse_pathspec: add PATHSPEC_EMPTY_MATCH_ALL

2013-01-21 Thread Duy Nguyen
On Tue, Jan 22, 2013 at 6:12 AM, Martin von Zweigbergk martinv...@gmail.com wrote: Hi, I was tempted to ask this before, and the recent thread regarding add -u/A [1] convinced me to. On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: We have two ways of dealing

Re: [PATCH 1/2] Update :/abc ambiguity check

2013-01-21 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes: ... take :/abc as rev even it's ambiguous. This patch makes it: - ambiguous when abc exists on worktree - a rev if abc does not exist on worktree - a path if abc is not found in any commits (although better use The any commits above sounds very scary.

Re: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)

2013-01-21 Thread Drew Northup
On Sat, Jan 5, 2013 at 11:12 AM, Jeff King p...@peff.net wrote: On Mon, Dec 31, 2012 at 03:30:53AM -0700, Martin Fick wrote: The general approach is to setup a transaction and either commit or abort it. A transaction can be setup by renaming an appropriately setup directory to the ref.lock

Re: [RFC] Instruct git-completion.bash that we are in test mode

2013-01-21 Thread Junio C Hamano
Jeff King p...@peff.net writes: I really hate to suggest this, but should it be more like: if test -z $FAKE_COMMAND_LIST; then __git_cmdlist() { git help -a | egrep '^ [a-zA-Z0-9]' } else __git_cmdlist() { printf '%s'

Re: [PATCH v6 0/8] push: update remote tags only with force

2013-01-21 Thread Chris Rorvick
On Mon, Jan 21, 2013 at 5:40 PM, Jeff King p...@peff.net wrote: On Thu, Jan 17, 2013 at 09:18:50PM -0600, Chris Rorvick wrote: On Thu, Jan 17, 2013 at 7:06 PM, Jeff King p...@peff.net wrote: However, if instead of the rule being blobs on the remote side cannot be replaced, if it becomes the

[PATCH 0/3] Finishing touches to push advises

2013-01-21 Thread Junio C Hamano
This builds on Chris Rorvick's earlier effort to forbid unforced updates to refs/tags/ hierarchy and giving sensible error and advise messages for that case (we are not rejecting such a push due to fast forwardness, and suggesting to fetch and integrate before pushing again does not make sense).

[PATCH 1/3] push: further clean up fields of struct ref

2013-01-21 Thread Junio C Hamano
The nonfastforward field is only used to decide what value to assign to the status locally in a single function. Remove it from the struct ref and make it into a local variable. The requires_force field is not used to decide if the proposed update requires a --force option to succeed, or to

[PATCH 3/3] push: further reduce struct ref and simplify the logic

2013-01-21 Thread Junio C Hamano
The update field in struct ref is only used in a very narrow scope in a single function. Remove it. Also simplify the code that rejects an attempted push by first checking if the proposed update is forced (in which case we do not need any check on our end). Signed-off-by: Junio C Hamano

Re: [PATCH 2/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE

2013-01-21 Thread Junio C Hamano
This one has a logic flaw. The logic outlined in the cover letter is correct, and the one described in the log message of this one is not. We should say fetch first only when we do not have old_sha1. diff --git a/remote.c b/remote.c index 248910f..8c39ea2 100644 --- a/remote.c +++ b/remote.c

Re: [PATCH 3/3] push: further reduce struct ref and simplify the logic

2013-01-21 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: The update field in struct ref is only used in a very narrow scope in a single function. Remove it. Also simplify the code that rejects an attempted push by first checking if the proposed update is forced (in which case we do not need any check on

[PATCH 0/3] Finishing touches to push advises

2013-01-21 Thread Junio C Hamano
This builds on Chris Rorvick's earlier effort to forbid unforced updates to refs/tags/ hierarchy and giving sensible error and advise messages for that case (we are not rejecting such a push due to fast forwardness, and suggesting to fetch and integrate before pushing again does not make sense).

[PATCH v2 1/3] push: further clean up fields of struct ref

2013-01-21 Thread Junio C Hamano
The nonfastforward and update fields are only used while deciding what value to assign to the status locally in a single function. Remove them from the struct ref. The requires_force field is not used to decide if the proposed update requires a --force option to succeed, or to record such a

[PATCH v2 2/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE

2013-01-21 Thread Junio C Hamano
When we push to update an existing ref, if: * we do not have the object at the tip of the remote; or * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, there is no point suggesting to fetch, integrate and push again. If we do not have the

[PATCH v2 3/3] push: further simplify the logic to assign rejection status

2013-01-21 Thread Junio C Hamano
Instead of using deeply nested if/else statements, first decide what rejection status we would get if this push weren't forced, and then assign the rejection reason to the ref-status field and flip the ref-forced_update field when we forced a push for a ref that indeed required forcing.

Re: [PATCH v6 0/8] push: update remote tags only with force

2013-01-21 Thread Junio C Hamano
Chris Rorvick ch...@rorvick.com writes: I agree with everything above. I just don't understand why reverting the already exists behavior for non-commit-ish objects was a prerequisite to fixing this. Because it is a regression. People who did not force such a push did not get already exists,

Re: [PATCH 0/3] Finishing touches to push advises

2013-01-21 Thread Junio C Hamano
As far as I am concerned, I am pretty much done with this topic, at least for now. Of course if there are bugreports I'll try to help resolving them, but I do not expect myself adding new object-type based policy decision to this codepath. The call the updated call makes to ref_newer() no longer

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

2013-01-21 Thread Matthieu Moy
Jonathan Nieder jrnie...@gmail.com writes: Would it be possible to make this conditional on cwd not being at the toplevel (the case where git add -u :/ and git add -u . have different behavior)? E.g., static const char *here[2] = { ., NULL }; if (prefix)

[PATCH v3] Enable minimal stat checking

2013-01-21 Thread Robin Rosenberg
Specifically the fields uid, gid, ctime, ino and dev are set to zero by JGit. Other implementations, eg. Git in cygwin are allegedly also somewhat incompatible with Git For Windows and on *nix platforms the resolution of the timestamps may differ. Any stat checking by git will then need to check

mulberry taschen outlet

2013-01-21 Thread addshdaw
Die Marke [url=http://www.taschenoutlet.eu/]Mulberry taschen outlet[/url] bietet hq taschen insbesondere innerhalb der Kleinen Gemeinde Chilcompton auf Großbritannien. Die Longchamp bestimmte Marke macht Viel Bessere nutzung von Komponenten und weiblich Baio echte bei der entwicklung of this

  1   2   >