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 2>&1) 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 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 2>&1) > >> On Sat, Nov 2, 2013 at 12:03 PM, Philip Oakley wrote: >> > From: "John Keeping" >> > Sent: Saturday, November 02, 2013 2:06 PM >> > >> >> On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: >> >>> >> >>> From: "John Keeping" >> >>> 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 Sat, Nov 2, 2013 at 9:40 PM, 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. So maybe it's a good point now to also change the MINGW prerequisite name to MSYS as part of your patch, and then name the functions more appropriately? -- 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: [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: 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 2>&1) > On Sat, Nov 2, 2013 at 12:03 PM, Philip Oakley wrote: > > From: "John Keeping" > > Sent: Saturday, November 02, 2013 2:06 PM > > > >> On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: > >>> > >>> From: "John Keeping" > >>> 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: 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 wrote: > From: "John Keeping" > Sent: Saturday, November 02, 2013 2:06 PM > >> On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: >>> >>> From: "John Keeping" >>> 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!
From: "John Keeping" Sent: Saturday, November 02, 2013 2:06 PM On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote: From: "John Keeping" 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
[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 []. 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
Signed-off-by: Thomas Rast
---
Trần Ngọc Quân 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 ] [-m ] [-f] [--tags|--no-tags] "
+ "[--mirror=] ");
+static const char builtin_remote_rename_usage_str[] =
+ N_("git remote rename ");
+static const char builtin_remote_rm_usage_str[] =
+ N_("git remote remove ");
+static const char builtin_remote_sethead_usage_str[] =
+ N_("git remote set-head (-a | --auto | -d | --delete |
)");
+static const char builtin_remote_setbranches_usage_str[] =
+ N_("git remote set-branches [--add] ...");
+static const char builtin_remote_show_usage_str[] =
+ N_("git remote [-v | --verbose] show [-n] ");
+static const char builtin_remote_prune_usage_str[] =
+ N_("git remote prune [-n | --dry-run] ");
+static const char builtin_remote_update_usage_str[] =
+ N_("git remote [-v | --verbose] update [-p | --prune] "
+ "[( | )...]");
+static const char builtin_remote_seturl_usage_str[] =
+ N_("git remote set-url [--push] []");
+static const char builtin_remote_seturl_add_usage_str[] =
+ N_("git remote set-url --add ");
+static const char builtin_remote_seturl_delete_usage_str[] =
+ N_("git remote set-url --delete ");
+
static const char * const builtin_remote_usage[] = {
N_("git remote [-v | --verbose]"),
- N_("git remote add [-t ] [-m ] [-f] [--tags|--no-tags]
[--mirror=] "),
- N_("git remote rename "),
- N_("git remote remove "),
- N_("git remote set-head (-a | --auto | -d | --delete
|)"),
- N_("git remote [-v | --verbose] show [-n] "),
- N_("git remote prune [-n | --dry-run] "),
- N_("git remote [-v | --verbose] update [-p | --prune] [( |
)...]"),
- N_("git remote set-branches [--add] ..."),
- N_("git remote set-url [--push] []"),
- N_("git remote set-url --add "),
- N_("git remote set-url --delete "),
+ 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 [] "),
+ builtin_remote_add_usage_str,
NULL
};
static const char * const builtin_remote_rename_usage[] = {
- N_("git remote rename "),
+ builtin_remote_rename_usage_str,
NULL
};
static const char * const builtin_remote_rm_usage[] = {
- N_("git remote remove "),
+ builtin_remote_rm_usage_str,
NULL
};
static const char * const builtin_remote_sethead_usage[] = {
- N_("git remote set-head (-a | --auto | -d | --delete |
)"),
+ builtin_remote_sethead_usage_str,
NULL
};
static const char * const builtin_remote_setbranches_usage[] = {
- N_("git remote set-branches ..."),
- N_("git remote set-branches --add ..."),
+ builtin_remote_setbranches_usage_str,
NULL
};
static const char * const builtin_remote_show_usage[] = {
- N_("git remote show [] "),
+ builtin_remote_show_usage_str,
NULL
};
static const char * const builtin_remote_prune_usage[] = {
-
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" > 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
Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
From: "John Keeping" 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: [PATCH] commit: Add -f, --fixes option to add Fixes: line
On Wed, Oct 30, 2013 at 8:07 PM, Johan Herland wrote: > On Tue, Oct 29, 2013 at 7:23 AM, Christian Couder > 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 ". > > 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: >> >> -- >> <<>> >> >> Fixes: 1234beef56 (Commit message summmary) >> Reported-by: >> Suggested-by: >> Improved-by: >> Acked-by: Jeff King >> Reviewed-by: >> Tested-by: >> Signed-off-by: Myself >> -- >> >> 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: >> >> -- >> <<>> >> >> Fixes: 1234beef56 (Commit message summmary) >> Acked-by: Jeff King >> Reviewed-by: Johan Herland >> Signed-off-by: Myself >> -- >> >> 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: [ANNOUNCE] git reintegrate 0.1; manager of integration branches
On Sat, Nov 2, 2013 at 5:00 AM, John Keeping 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: [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: 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: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
Ville Walveranta 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: [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 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
