Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color
Junio C Hamano wrote: This patch is about for-each-ref and your series does not seem to aim to unify it in any way with pretty-formats, so I would have expected an enhancement in line with the former, not the latter. While I might never attempt a unification again, there's no harm in getting the formats to resemble each other in part; it's likely that users of f-e-r format will be familiar with pretty-formats. -- 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] gitk: Add a horizontal scrollbar for commit history
Hi, Am 31.10.2013 10:05, schrieb Paul Mackerras: On Wed, Oct 30, 2013 at 01:47:08PM +0100, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. Here is a patch that I did some time ago but have never pushed out. Do you think it is an improvement when using gitk on a repo with lots of tags? Paul. [PATCH] gitk: Tag display improvements When a commit has many tags, the tag icons in the graph display can easily become so wide as to push the commit message off the right-hand edge of the graph display pane. This changes the display so that if there are more than 3 tags or they would take up more than a quarter of the width of the pane, we instead display a single tag icon with a legend inside it like 4 tags If the user clicks on the tag icon, gitk then displays all the tags in the diff display pane. Signed-off-by: Paul Mackerras pau...@samba.org Yes please. I have not tried it but the description sounds great. Will try to give it a testdrive next week. Cheers Heiko -- 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 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
Ville Walveranta walveranta at gmail.com writes: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e. output true) when inside a git directory, or inside a work tree, respectively. To test, I installed git 1.8.4.2 initially from https://launchpad.net/~git-core/+archive/ppa for Ubuntu 12.04.3, and then also compiled it from source, but both seem to behave the same way. The problem is not yet present in version 1.7.9.5. Thanks, Ville Walveranta Hi, I thought I'd try to bisect this but I ended up discovering that I get the exact same behaviour with both 1.7.9.5 and 1.8.4.2. 1.7.9.5 will also output 'fatal: ...' like 1.8.4.2 does. Both version will however behave as expected if you provide --git-dir and --work-tree: $ pwd /home/osse $ git --version git version 1.8.4.2 $ git --git-dir=/home/osse/git/.git \ --work-tree=/home/osse/git\ rev-parse --is-inside-work-tree false Ditto for --is-inside-git-dir. Incidentally I discovered that the new -C option does *not* behave this way: $ git --version git version 1.8.5.rc0.23.gaa27064 $ git -C /home/osse/git rev-parse --is-inside-work-tree true But given that the purpose of the -C option is to make Git behave as if you were in that directory this is perhaps expected behaviour. Regards, Øsse -- 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 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e. output true) when inside a git directory, or inside a work tree, respectively. I think that's intentional - and it looks like the behaviour has not changed since these options were added. With the current behaviour you get three possible outcomes from git rev-parse --is-inside-work-tree: if worktree=$(git rev-parse --is-inside-work-tree 2/dev/null) then if test $worktree = true then echo 'inside work tree' else echo 'in repository, but not in work tree' fi else echo 'not in repository' fi -- 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: [ANNOUNCE] git reintegrate 0.1; manager of integration branches
On Fri, Nov 01, 2013 at 06:35:39AM -0600, Felipe Contreras wrote: One feature that is missing from git-integration is the ability to parse existing integration branches. Nice - I'd never thought of doing this. It also has support for evil merges, so it should be perfectly usable for git.git maintenance. By this, do you mean that you have an ability to squash a fixup into the merge? If so, how do you handle this in the status display - I've had a WIP branch for a while but haven't come up with a satisfactory way of displaying the status of a fixup. -- 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: [ANNOUNCE] git reintegrate 0.1; manager of integration branches
On Sat, Nov 2, 2013 at 5:00 AM, John Keeping j...@keeping.me.uk wrote: On Fri, Nov 01, 2013 at 06:35:39AM -0600, Felipe Contreras wrote: One feature that is missing from git-integration is the ability to parse existing integration branches. Nice - I'd never thought of doing this. I tried to provide all the functionality of todo:Reintegrate, or at least the important one. It also has support for evil merges, so it should be perfectly usable for git.git maintenance. By this, do you mean that you have an ability to squash a fixup into the merge? If so, how do you handle this in the status display - I've had a WIP branch for a while but haven't come up with a satisfactory way of displaying the status of a fixup. Yes, I did basically what you did, however, I skipped the status part. I think it's more important to be able to do these fixups, even if they don't show on the status. And to be honest I don't care much about the status feature in general. 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] commit: Add -f, --fixes commit option to add Fixes: line
On Wed, Oct 30, 2013 at 8:07 PM, Johan Herland jo...@herland.net wrote: On Tue, Oct 29, 2013 at 7:23 AM, Christian Couder christian.cou...@gmail.com wrote: I don't agree. Git doesn't need to dictate anything to be able to do these expansions. Git only needs some hints to do these expansions properly and it could just look at the commit template, or the config, to get those hints. For example, if there is a Acked-by: line in the commit template, then Git might decide that ack means Acked-by, and then that -by means that Peff should be related to an author, and then that it is probably Jeff King p...@peff.net. I don't like putting that much Magic into core Git... Especially not into builtin/commit.c. However, if we - as you suggest further below - put it into a separate helper, and we make that helper available (and usable) from elsewhere (most importantly from hooks where people/projects can add their own more specific functionality), then I don't have a problem with it. Ok, great! I started working on git interpret-trailers and I will post an RFC patch soon. It will support both configuration as Junio suggested and reading a commit template file as you suggested. Ok, let's call the new plumbing command git interpret-trailers. And let's suppose that git commit is passed -f ack:Peff -f fix:security-bug (or --trailer ack=Peff --trailer fix=security-bug). git commit would then call something like: git interpret-trailers --file commit_message_template.txt 'ack:Peff' 'fix:security-bug' And this command would output: -- upper part of commit_message_template.txt Fixes: 1234beef56 (Commit message summmary) Reported-by: Suggested-by: Improved-by: Acked-by: Jeff King p...@peff.net Reviewed-by: Tested-by: Signed-off-by: Myself mys...@example.com -- Because it would have looked at the commit template it is passed and filled in the blanks it could fill using the arguments it is also passed. git commit would then put the above lines in the file that it passes to the prepare-commit-msg hook. Then the prepare-commit-msg could just do nothing. After the user has edited the commit message, the commit-msg hook could just call: git interpret-trailers --trim-empty --file commit_message.txt so that what the user changed is interpreted again. For example if the user changed the Reviewed-by: line to Reviewed-by: Johan, then the output would be: -- upper part of commit_message.txt Fixes: 1234beef56 (Commit message summmary) Acked-by: Jeff King p...@peff.net Reviewed-by: Johan Herland jo...@herland.net Signed-off-by: Myself mys...@example.com -- And that would be the final commit message in most cases. This approach looks OK to me, as long as we make sure that this functionality is (a) optional, (b) flexible/reusable from hooks, and (c) not bound tightly to core Git (and AFAICS, your proposal is just that). As I said above, this stuff certainly does not belong in builtin/commit.c... Ok, I think it will be very easy to do all with git interpret-trailers. Best regards, Christian. -- 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 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 10:58 AM On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e. output true) when inside a git directory, or inside a work tree, respectively. I think that's intentional - and it looks like the behaviour has not changed since these options were added. With the current behaviour you get three possible outcomes from git rev-parse --is-inside-work-tree: if worktree=$(git rev-parse --is-inside-work-tree 2/dev/null) then if test $worktree = true then echo 'inside work tree' else echo 'in repository, but not in work tree' fi else echo 'not in repository' fi -- Shouldn't this case which produces fatal:... need to be documented in the man page? https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html doesn't mention it. Philip -- 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 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 10:58 AM On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e. output true) when inside a git directory, or inside a work tree, respectively. I think that's intentional - and it looks like the behaviour has not changed since these options were added. With the current behaviour you get three possible outcomes from git rev-parse --is-inside-work-tree: if worktree=$(git rev-parse --is-inside-work-tree 2/dev/null) then if test $worktree = true then echo 'inside work tree' else echo 'in repository, but not in work tree' fi else echo 'not in repository' fi -- Shouldn't this case which produces fatal:... need to be documented in the man page? https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html doesn't mention it. I'm not sure where it should go in there. The documentation for --git-dir says: If $GIT_DIR is not defined and the current directory is not detected to lie in a Git repository or work tree print a message to stderr and exit with nonzero status. but there reality is that if you do not specify --parseopt or --sq-quote then the command expects to be run in a Git repository [1], so perhaps it would be better to say something under Operation Modes or in the description. [1] After taking account of $GIT_DIR, $GIT_WORK_TREE, and arguments to the base git driver that affect these variables. -- 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] remote: unify main and subcommand usage strings
We had separate usages for each subcommand, and for the main command,
even though the latter is essentially a concatenation of all of the
former. This leads to a lot of duplication and unnecessary
differences, e.g., in the 'set-head' case the two strings differ only
in a space.
Unify the strings in the usages by putting each of them in a variable,
and assembling the usage arrays from them.
Note that this patch changes the usage strings for the following
subcommands:
- prune and show: the individual usage only said [options]. Kept
the snippet from the main usage, which is more specific.
- set-branches: kept the main usage, which is more concise in saying
that --add is optional
Reported-by: Trần Ngọc Quân vnwild...@gmail.com
Signed-off-by: Thomas Rast t...@thomasrast.ch
---
Trần Ngọc Quân vnwild...@gmail.com wrote:
On 02/11/2013 09:23, Jiang Xin wrote:
Confirmed, there is a typo in builtin/remote.c line 15. Have you send
patch to this list for this, Trần?
This is minor error, so let Junio C Hamano do it!
Dunno, this generally isn't the nicest way to get things done, nor the
most productive use of maintainer bandwidth.
How about patching it like this instead? That should prevent similar
issues from cropping up again.
builtin/remote.c | 70 +---
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 4e14891..2f6366a 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -7,67 +7,91 @@
#include run-command.h
#include refs.h
+static const char builtin_remote_add_usage_str[] =
+ N_(git remote add [-t branch] [-m master] [-f] [--tags|--no-tags]
+ [--mirror=fetch|push] name url);
+static const char builtin_remote_rename_usage_str[] =
+ N_(git remote rename old new);
+static const char builtin_remote_rm_usage_str[] =
+ N_(git remote remove name);
+static const char builtin_remote_sethead_usage_str[] =
+ N_(git remote set-head name (-a | --auto | -d | --delete |
branch));
+static const char builtin_remote_setbranches_usage_str[] =
+ N_(git remote set-branches [--add] name branch...);
+static const char builtin_remote_show_usage_str[] =
+ N_(git remote [-v | --verbose] show [-n] name);
+static const char builtin_remote_prune_usage_str[] =
+ N_(git remote prune [-n | --dry-run] name);
+static const char builtin_remote_update_usage_str[] =
+ N_(git remote [-v | --verbose] update [-p | --prune]
+ [(group | remote)...]);
+static const char builtin_remote_seturl_usage_str[] =
+ N_(git remote set-url [--push] name newurl [oldurl]);
+static const char builtin_remote_seturl_add_usage_str[] =
+ N_(git remote set-url --add name newurl);
+static const char builtin_remote_seturl_delete_usage_str[] =
+ N_(git remote set-url --delete name url);
+
static const char * const builtin_remote_usage[] = {
N_(git remote [-v | --verbose]),
- N_(git remote add [-t branch] [-m master] [-f] [--tags|--no-tags]
[--mirror=fetch|push] name url),
- N_(git remote rename old new),
- N_(git remote remove name),
- N_(git remote set-head name (-a | --auto | -d | --delete
|branch)),
- N_(git remote [-v | --verbose] show [-n] name),
- N_(git remote prune [-n | --dry-run] name),
- N_(git remote [-v | --verbose] update [-p | --prune] [(group |
remote)...]),
- N_(git remote set-branches [--add] name branch...),
- N_(git remote set-url [--push] name newurl [oldurl]),
- N_(git remote set-url --add name newurl),
- N_(git remote set-url --delete name url),
+ builtin_remote_add_usage_str,
+ builtin_remote_rename_usage_str,
+ builtin_remote_rm_usage_str,
+ builtin_remote_sethead_usage_str,
+ builtin_remote_show_usage_str,
+ builtin_remote_prune_usage_str,
+ builtin_remote_update_usage_str,
+ builtin_remote_setbranches_usage_str,
+ builtin_remote_seturl_usage_str,
+ builtin_remote_seturl_add_usage_str,
+ builtin_remote_seturl_delete_usage_str,
NULL
};
static const char * const builtin_remote_add_usage[] = {
- N_(git remote add [options] name url),
+ builtin_remote_add_usage_str,
NULL
};
static const char * const builtin_remote_rename_usage[] = {
- N_(git remote rename old new),
+ builtin_remote_rename_usage_str,
NULL
};
static const char * const builtin_remote_rm_usage[] = {
- N_(git remote remove name),
+ builtin_remote_rm_usage_str,
NULL
};
static const char * const builtin_remote_sethead_usage[] = {
- N_(git remote set-head name (-a | --auto | -d | --delete |
branch)),
+ builtin_remote_sethead_usage_str,
NULL
};
static const char * const builtin_remote_setbranches_usage[] = {
- N_(git remote set-branches name branch...),
- N_(git remote set-branches --add name branch...),
+
Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 2:06 PM On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 10:58 AM On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e. output true) when inside a git directory, or inside a work tree, respectively. I think that's intentional - and it looks like the behaviour has not changed since these options were added. With the current behaviour you get three possible outcomes from git rev-parse --is-inside-work-tree: if worktree=$(git rev-parse --is-inside-work-tree 2/dev/null) then if test $worktree = true then echo 'inside work tree' else echo 'in repository, but not in work tree' fi else echo 'not in repository' fi -- Shouldn't this case which produces fatal:... need to be documented in the man page? https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html doesn't mention it. I'm not sure where it should go in there. The documentation for --git-dir says: If $GIT_DIR is not defined and the current directory is not detected to lie in a Git repository or work tree print a message to stderr and exit with nonzero status. but there reality is that if you do not specify --parseopt or --sq-quote then the command expects to be run in a Git repository [1], so perhaps it would be better to say something under Operation Modes or in the description. [1] After taking account of $GIT_DIR, $GIT_WORK_TREE, and arguments to the base git driver that affect these variables. Yes, but given Ville's surprise and the need for special prior knowledge of the points you raised, I still think that some short note is needed. It can/could be read that you need to invoke --git-dir as an option before the mentioned die() exit is taken, rather than it applying to all(?) the path relevant options. Either the --git-dir condition needs to say it also applies to --is-inside-git-dir and --is-inside-work-tree (and --is-bare-repository?), or add a see --git-dir preconditions. to each of those options. It's easy to be wise after the event hence my preference for a suitable note. regards Philip -- 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 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
Without the functionality such as that 1.7.9.5 still offered, it is now not possible to use git-rev-parse --is-inside-work-tree to detect whether the current location is controlled by a git repository without emitting the fatal: Not a git repository (or any of the parent directories): .git error message, when it is not. There is no functional --quiet switch, and the usual error/std redirection to /dev/null doesn't seem to work to squelch the output. If --is-inside-git-dir and --is-inside-work-tree are indeed not supposed to emit false when outside of a git repository, perhaps there is another way I can use (in a bash script) to cleanly detect whether a specific path is part of a git repo or not? Thanks for any insights on this! :-) Ville On Sat, Nov 2, 2013 at 12:03 PM, Philip Oakley philipoak...@iee.org wrote: From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 2:06 PM On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 10:58 AM On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e. output true) when inside a git directory, or inside a work tree, respectively. I think that's intentional - and it looks like the behaviour has not changed since these options were added. With the current behaviour you get three possible outcomes from git rev-parse --is-inside-work-tree: if worktree=$(git rev-parse --is-inside-work-tree 2/dev/null) then if test $worktree = true then echo 'inside work tree' else echo 'in repository, but not in work tree' fi else echo 'not in repository' fi -- Shouldn't this case which produces fatal:... need to be documented in the man page? https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html doesn't mention it. I'm not sure where it should go in there. The documentation for --git-dir says: If $GIT_DIR is not defined and the current directory is not detected to lie in a Git repository or work tree print a message to stderr and exit with nonzero status. but there reality is that if you do not specify --parseopt or --sq-quote then the command expects to be run in a Git repository [1], so perhaps it would be better to say something under Operation Modes or in the description. [1] After taking account of $GIT_DIR, $GIT_WORK_TREE, and arguments to the base git driver that affect these variables. Yes, but given Ville's surprise and the need for special prior knowledge of the points you raised, I still think that some short note is needed. It can/could be read that you need to invoke --git-dir as an option before the mentioned die() exit is taken, rather than it applying to all(?) the path relevant options. Either the --git-dir condition needs to say it also applies to --is-inside-git-dir and --is-inside-work-tree (and --is-bare-repository?), or add a see --git-dir preconditions. to each of those options. It's easy to be wise after the event hence my preference for a suitable note. regards Philip -- 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 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
On Sat, Nov 02, 2013 at 02:42:04PM -0500, Ville Walveranta wrote: Without the functionality such as that 1.7.9.5 still offered, it is now not possible to use git-rev-parse --is-inside-work-tree to detect whether the current location is controlled by a git repository without emitting the fatal: Not a git repository (or any of the parent directories): .git error message, when it is not. There is no functional --quiet switch, and the usual error/std redirection to /dev/null doesn't seem to work to squelch the output. How doesn't redirection work? The message is printed to stderr; the snippet I posted below does indeed squelch the output. If --is-inside-git-dir and --is-inside-work-tree are indeed not supposed to emit false when outside of a git repository, perhaps there is another way I can use (in a bash script) to cleanly detect whether a specific path is part of a git repo or not? Something like this, maybe? (cd $dir git rev-parse --git-dir /dev/null 21) On Sat, Nov 2, 2013 at 12:03 PM, Philip Oakley philipoak...@iee.org wrote: From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 2:06 PM On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 10:58 AM On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e. output true) when inside a git directory, or inside a work tree, respectively. I think that's intentional - and it looks like the behaviour has not changed since these options were added. With the current behaviour you get three possible outcomes from git rev-parse --is-inside-work-tree: if worktree=$(git rev-parse --is-inside-work-tree 2/dev/null) then if test $worktree = true then echo 'inside work tree' else echo 'in repository, but not in work tree' fi else echo 'not in repository' fi -- -- 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 2/3] Windows: a test_cmp that is agnostic to random LF CRLF conversions
On 26.10.2013 21:17, Johannes Sixt wrote: In a number of tests, output that was produced by a shell script is compared to expected output using test_cmp. Unfortunately, the MSYS bash-- when invoked via git, such as in hooks--converts LF to CRLF on output (as produced by echo and printf), which leads to many false positives. As you correctly point out the LF vs. CRLF issues are caused by MSYS bash. Then why are the functions called mingw_* instead of msys_*? I'd prefer to make very clear that not MinGW but MSYS is the culprit concerning the LF vs. CRLF issues (and also the path mangling issues). -- Sebastian Schuberth -- 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 2/3] Windows: a test_cmp that is agnostic to random LF CRLF conversions
Am 02.11.2013 21:33, schrieb Sebastian Schuberth: On 26.10.2013 21:17, Johannes Sixt wrote: In a number of tests, output that was produced by a shell script is compared to expected output using test_cmp. Unfortunately, the MSYS bash-- when invoked via git, such as in hooks--converts LF to CRLF on output (as produced by echo and printf), which leads to many false positives. As you correctly point out the LF vs. CRLF issues are caused by MSYS bash. Then why are the functions called mingw_* instead of msys_*? I'd prefer to make very clear that not MinGW but MSYS is the culprit concerning the LF vs. CRLF issues (and also the path mangling issues). It's a historical accident. We already have the prerequisite MINGW to work around various annoyances, most of which are caused by MSYS bash. I didn't want to invent a new prefix. -- Hannes -- 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 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
Yes, stderr redirection in a subshell seems to work ok. Since I'm creating a small git utility script I ended up doing: -- #!/bin/bash (git rev-parse --git-dir /dev/null 21) if [ $? -ne 0 ] ; then echo Not in a git repo else echo Git repo; proceeding.. # more logic.. fi -- That works! Thanks for your help! Ville On Sat, Nov 2, 2013 at 3:20 PM, John Keeping j...@keeping.me.uk wrote: On Sat, Nov 02, 2013 at 02:42:04PM -0500, Ville Walveranta wrote: Without the functionality such as that 1.7.9.5 still offered, it is now not possible to use git-rev-parse --is-inside-work-tree to detect whether the current location is controlled by a git repository without emitting the fatal: Not a git repository (or any of the parent directories): .git error message, when it is not. There is no functional --quiet switch, and the usual error/std redirection to /dev/null doesn't seem to work to squelch the output. How doesn't redirection work? The message is printed to stderr; the snippet I posted below does indeed squelch the output. If --is-inside-git-dir and --is-inside-work-tree are indeed not supposed to emit false when outside of a git repository, perhaps there is another way I can use (in a bash script) to cleanly detect whether a specific path is part of a git repo or not? Something like this, maybe? (cd $dir git rev-parse --git-dir /dev/null 21) On Sat, Nov 2, 2013 at 12:03 PM, Philip Oakley philipoak...@iee.org wrote: From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 2:06 PM On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: From: John Keeping j...@keeping.me.uk Sent: Saturday, November 02, 2013 10:58 AM On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e. output true) when inside a git directory, or inside a work tree, respectively. I think that's intentional - and it looks like the behaviour has not changed since these options were added. With the current behaviour you get three possible outcomes from git rev-parse --is-inside-work-tree: if worktree=$(git rev-parse --is-inside-work-tree 2/dev/null) then if test $worktree = true then echo 'inside work tree' else echo 'in repository, but not in work tree' fi else echo 'not in repository' fi -- -- 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
