Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Odd. https://www.gravatar.com/; also seems to work. I've put in a
technical support query to find out what the Gravatar admins prefer.
Thanks; will hold onto Andrej's patch until we hear what the story
is.
Good news: a kind
-by: Jonathan Nieder jrnie...@gmail.com
--
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
Hi,
Junio C Hamano wrote:
Wow, that's a blast from the past.
I tend to agree that deprecating and removing are quite different,
but a simple revert of the change would not be good, either. We
still would want to _discourage_ its use.
Hm, I was about to try adding a line in that vein, like
Jonathan Nieder wrote:
Is the problem that deprecated is not precise enough? For example,
would it make sense to say deprecated synonym for `upstream`. Will
be dropped in git 2.1 or something like that?
Also, if we plan to remove support soon, we should start warning when
this setting
Hi Constantine,
Constantine A. Murenin wrote:
DragonFly BSD uses git as its SCM, with one single repository and
branch for both the kernel and the whole userland.
On 2011-11-26 (1322296064), someone did a commit that somehow touched
every single file in the repository, even though most of
Junio C Hamano wrote:
That is why I tend to prefer how check-ref-format documentation
describes --print:
--normalize::
Normalize 'refname' by removing any leading slash (`/`)
characters and collapsing runs of adjacent slashes between
Junio C Hamano wrote:
For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but going in the
opposite direction), it should be unmistakingly clear that
`tracking`
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
That works because, as you mention, the usual way to look up an option
in manpages is to search for --print, including the two minus signs.
Unfortunately an analagous approach in gitconfig(5) would be seriously
broken, because
Junio C Hamano wrote:
How about doing it this way?
[...]
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1795,7 +1795,8 @@ push.default::
+
This is currently the default, but Git 2.0 will change the default
to `simple`.
-* `upstream` - push the current branch to
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but going
Jeff King wrote:
Maybe it is just me, but the fact that accessing the manpage is now:
man gitremote-helpers
feels weird to me. I know it technically follows our syntactic rules,
but having the lack of dash be significant between git and remote,
but then having a dash later makes it hard
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Yes. I have thought for years that it should be git-remote-helpers,
that git help should be tweaked to look for that, and that the
existing gitrepository-layout and friends should be replaced with
redirects.
Because
+= ...
...
?
With that change,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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
Jeff King wrote:
Let's just call everything git-*, which is simpler. This
patch renames the documentation files, updates the Makefile
to find them, and updates internal linkgit references to the
pages. It updates builtin/help.c so that users of git help
foo will not even notice the
Hi,
Thomas Ackermann wrote:
Found by Junio:
Change git-dir to $GIT_DIR and git-file to gitfile.
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/git-rev-parse.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Junio C Hamano wrote:
How about saying something like this here in the glossary:
A plain file `.git` at the root of a working tree that
points at the directory that is the real repository.
And then as a separate patch, in gitrepository-layout.txt (eek---see
the other thread),
Thomas Ackermann wrote:
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -23,7 +23,7 @@ and full access to internals.
See linkgit:gittutorial[7] to get started, then see
link:everyday.html[Everyday Git] for a useful minimum set of
-commands. The link:user-manual.html[Git
Jongman Heo wrote:
But it doesn't stimulate any prerequisites in make, which is weird.
What's in builtin/.depend/fetch.o.d?
[...]
please see below~.
$ cat builtin/.depend/fetch.o.d
fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \
That's the problem. See the
the -MQ option. Do so.
Reported-and-tested-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Reported-by: : 허종만 jongman@samsung.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 731b6a8
Hi Ram,
Ramkumar Ramachandra wrote:
8f26aa4 (Makefile: remove tracking of TCLTK_PATH, 2012-12-18) removed
/gitk-git/gitk-wish from the toplevel .gitignore, with the intent of
moving it to gitk-git/.gitignore in a later patch. This was never
realized.
Signed-off-by: Ramkumar Ramachandra
John Keeping wrote:
From: Antoine Pelisse apeli...@gmail.com
Create a GREP_HEADER_FIELD_MIN so we can check that the field value is
sane and silent the clang warning.
Thanks. Looks good to me.
[...]
--- a/grep.c
+++ b/grep.c
@@ -625,7 +625,8 @@ static struct grep_expr
Hi Anand,
Anand Kumria wrote:
I've not been able to find the canonical location of your gitk repository.
Here's how I find it:
$ git clone git://repo.or.cz/git.git
[...]
$ cd git
$ git log -1 --oneline -- gitk-git
ec3ae6ec Merge git://ozlabs.org/~paulus/gitk
Jongman Heo wrote:
Unfortunately, the patch didn't help to me.
Thanks for testing. Did you apply the patch to the older version of
git that generates builtin/.depend/fetch.o.d or the newer version that
consumes it?
Curious,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe
Junio C Hamano wrote:
The only case that worries me is when make or cc gets interrupted.
As long as make removes the ultimate target *.o in such a case, it
is fine to leave a half-written .depend/foo.o.d (or getting it
removed) behind.
gcc removes the target .o in its signal handler in such
Junio C Hamano wrote:
(some may be too minor to be worth backproting, for
example).
Yes, this is the part I was asking for help with. Backporting is easy
but convincing the release team and upgrade-averse sysadmins to like
the result generally isn't. Occasional nominations of the
Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Missing description. Stealing from the link you sent:
The typical use-case is starting a rebase, do something else, come back
the day after, run git status or make a new commit and wonder what
Hi Michael,
Michael Haggerty wrote:
I would again like to express my discomfort about this feature, which is
already listed as will merge to next. Frankly, I have the feeling
that this feature is being steamrolled in before a community consensus
has been reached and indeed before many valid
Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Hiderefs creates a dark corner of a remote git repo
[...]
Or you can think hiderefs is the first step to addressing the
initial ref advertisment problem.
Michael Haggerty wrote:
Scenario 1: Some providers junk up their users' repositories with
content that is not created by the repository's owner and that the owner
doesn't want to appear to vouch for (e.g., GitHub pull requests). These
references might sometimes be useful to fetch, singly or
Hi Ram,
Ramkumar Ramachandra wrote:
And yes, a regular `git push origin refs/for/master` is just retarded.
The usual incantation is git push gerrit HEAD:refs/for/master. Is
the code review creation push that uses a different branchname from
the branch the integrator pulls what seems backward,
Junio C Hamano wrote:
I'd actually see this as Gerrit being weird.
If it wants to quarantine a commit destined to the master branch,
couldn't it just let people push to master and then internally
update for/master instead?
It is because pushing doesn't update refs/heads/master. Instead, it
Michael J Gruber wrote:
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
Jonathan Nieder jrnie...@gmail.com writes:
Wait, why did the remote rewind?
Oh, I am very well aware of that glitch.
git push has this hack to pretend as if the pusher immediately
turned around and fetched from
Ramkumar Ramachandra wrote:
Why should I have to `git rm -rf .` after a `git checkout --orphan`?
What sort of misfeature/ incomplete feature is this?
One designed for the going open source use case, where you have
existing code that you want to put into a new branch without history.
When there
Junio C Hamano wrote:
Nick Muerdter st...@nickm.org writes:
As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home
directory can't be accessed, it results in a fatal error. In git 1.8.1
and below this same setup just resulted in warnings. Was this an
intentional change?
I think
Hi,
Michael J Gruber wrote:
reset can be easily misunderstood as resetting a bisect session to its
start without finishing it. Clarify that it actually finishes the bisect
session.
FWIW,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Addressing Andreas's original concern about
Hi Robert,
Robert Clausecker wrote:
There are two things git archive is missing that are needed in my use
case:
First, git archive in combination with tar won't remove unneeded files.
You have to run rm -rf before manually which brings me to the next
point; git archive can't really make
Robert Clausecker wrote:
That is actually a pretty interesting approach. I can use a different
index file for different deployments. How does this cooperate with bare
repositories? Aren't they supposed to have no index file at all?
It should work fine in a bare repo.
If you can think of a
Ethan Reesor wrote:
I have a git user set up on my server. It's prompt is set to
git-prompt and it's git-shell-commands is empty.
[...]
How do I make the git user work like github where, upon attempting to
get a prompt, the connection is closed?
I assume you mean that the user's login shell
W. Trevor King wrote:
On Sun, Feb 10, 2013 at 01:33:31PM -0800, Junio C Hamano wrote:
The resulting text may read like so:
…
I'm fine with this too, but if this is the suggested route, why bother
with `git config` at all? Is it just for ease of scripting?
Yes. It can also be helpful when
.
Reported-by: Ethan Reesor firelizz...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Sitaram Chamarty wrote:
Indeed! In gitolite, I borrowed that idea added to it by making it
print a list of repos you have access to, along with what permissions
(R or RW) you have :-)
I'm
Jeff King wrote:
On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
+When run interactively (with no arguments), 'git-shell' will
+automatically run `~/git-shell-commands/help` on startup, provided it
+exists. If the 'help' command fails then the interactive shell is
+aborted
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
How about this?
A patch on top could change the default git-shell-commands is not
present message if that seems worthwhile.
Hmph.
I wonder if rewording the message when git-shell-commmands directory
is not there may
Jeff King wrote:
On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
Only interactive connections. That's the existing behavior.
Ah, sorry. I misread the patch. I see now that we already run help, and
this is just making the exit value significant. In that case, yeah, I
think
Junio C Hamano wrote:
Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
--
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
of the commit message to:
Very nice. How about this version?
Jonathan Nieder (2):
shell doc: emphasize purpose and security guarantees
shell: pay attention to exit status from 'help' command
Documentation/git-shell.txt | 86 +
shell.c
also section with some relevant related reading.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
New text. Split off from patch 2 --- this is just documenting
existing behavior.
Documentation/git-shell.txt | 66 ++---
1 file changed, 51 insertions
the help script exits with nonzero status by mistake.
Hopefully those are rare enough to not cause much trouble in practice.
Reported-by: Ethan Reesor firelizz...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Improved-by: Jeff King p...@peff.net
---
Documentation/git-shell.txt | 20
Ethan Reesor wrote:
That way, there's a default setting, there can
be a system-wide message, there can be a user specific message, and
those messages can be set via `git-commit`.
That won't let me imitate gitolite's behavior without a lot of
config file churn:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
Hmph, if that is the case, wouldn't it be a better direction to give
a better help
[administrivia: please don't top-post]
Ethan Reesor wrote:
Why not have both? That way there is a way to get a customizable
response that avoids Junio's complaints and there is a way to do what
you are trying to achieve.
What was Junio's complaint?
Jonathan
--
To unsubscribe from this list:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
The trouble is that I can't imagine a canned message that everyone
will like. (For example, I quite dislike the current one.) That's
exactly the situation in which some configurability is helpful.
I am not saying we should
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
+To disable interactive logins, displaying a greeting instead:
++
+
+$ chsh -s /usr/bin/git-shell
+$ mkdir $HOME/git-shell-commands
+$ cat $HOME/git-shell-commands/help \EOF
+#!/bin/sh
+printf '%s\n' Hi
Junio C Hamano wrote:
The purpose of the directory is to keep custom commands that are
allowed. If the site administrator does not want any command, it
would be more natural to expect that the way to disable them would
be _not_ to have that directory which is a collection of allowed
# quit the bisect session
I had forgotten that git bisect run ends in a bisecting state.
Good call.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Brandon Casey wrote:
On 2/12/2013 11:13 AM, Junio C Hamano wrote:
Brandon Casey draf...@gmail.com writes:
+static int is_cherry_picked_from_line(const char *buf, int len)
+{
+ /*
+* We only care that it looks roughly like (cherry picked from ...)
+*/
+ return len
Brandon Casey wrote:
I'm not sure we should apply this though. I'm leaning towards saying that
the 'cherry-pick -s' behavior with respect to a commit with an empty message
body should be undefined. If we want it to be undefined then we probably
shouldn't introduce a test which would have
),
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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
Hi,
John Keeping wrote:
[Subject: [PATCH 1/3] Documentation/Makefile: fix spaces around assignments]
It's not so much fix spaces as use consistent spacing, no?
Aside from that nit, looks like a sensible no-op to me, so
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
--
To unsubscribe
John Keeping wrote:
Signed-off-by: John Keeping j...@keeping.me.uk
[...]
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -81,6 +81,7 @@ DOC_MAN7 = $(patsubst %.txt,%.7,$(MAN7_TXT))
prefix ?= $(HOME)
bindir ?= $(prefix)/bin
htmldir ?= $(prefix)/share/doc/git-doc
+infodir ?=
John Keeping wrote:
Documentation/Makefile: fix inherited {html,info,man}dir
This doesn't seem to have hit the list.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
John Keeping wrote:
On Tue, Feb 12, 2013 at 02:25:08PM -0800, Jonathan Nieder wrote:
John Keeping wrote:
Documentation/Makefile: fix inherited {html,info,man}dir
This doesn't seem to have hit the list.
Hmm... it made it to gmane:
http://article.gmane.org/gmane.comp.version-control.git
,info}dir variables
to have real paths whose default values begin with $(prefix), but
as a first step, stop exporting them from the top-level Makefile.
Makes sense.
Reported-by: John Keeping j...@keeping.me.uk
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send
Junio C Hamano wrote:
* jn/shell-disable-interactive (2013-02-11) 2 commits
- shell: pay attention to exit status from 'help' command
- shell doc: emphasize purpose and security model
Will merge to 'next'.
Please hold off on merging the second patch. I'd like to reroll
renaming the
Junio C Hamano wrote:
I amended the log message like so:
commit bd9df384b16077337fffe9836c9255976b0e7b91
Author: Matt Kraai matt.kr...@amo.abbott.com
Date: Wed Feb 13 07:57:48 2013 -0800
Makefile: don't run rm without any files
When COMPUTE_HEADER_DEPENDENCIES is set to auto
Hi Paul,
Paul Campbell wrote:
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -465,4 +465,34 @@ test_expect_success 'verify one file change per commit' '
[...]
+test_expect_success 'change in subtree is pushed okay' '
+cd copy0 create new_file
);
*src_buf += len;
*src_len -= len;
- packet_trace(out-buf, out-len, 0);
return len;
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
The above code has a structure of
prepare to return(buf, len);
trace(buf, len);
discard used
for a
suitable amount of time to catch bad servers, it looks like a good
idea.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
--
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
Jeff King wrote:
If the smart HTTP response from the server is truncated for
any reason, we will get an incomplete ref advertisement. If
we then feed this incomplete list to fetch-pack, one of a
few things may happen:
1. If the truncation is in a packet header, fetch-pack
will
David Aguilar wrote:
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -10,29 +10,11 @@ Testing basic diff tool invocation
[...]
-restore_test_defaults()
-{
- # Restores the test defaults used by several tests
- remove_config_vars
- unset GIT_DIFF_TOOL
- unset
David Aguilar wrote:
t7800 tests that configured commands can override builtins,
but this test was not adjusted when the defaults file was
removed because the test continued to pass.
Adjust the test to use the everlasting vimdiff
Heh. :)
Paul Campbell wrote:
Is there was a better way to verify that the push operation succeeds
then grepping for a SHA1?
IIRC then when a push fails, it will exit with nonzero status (so the
usual -chaining would propagate the error).
Alternatively, one can fetch, ls-remote, or enter the target
Paul Campbell wrote:
Here's the updated version of the tests:
Just a few more nits:
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -465,4 +465,37 @@ test_expect_success 'verify one file change per commit' '
[...]
+test_expect_success 'change in subtree
Jeff King wrote:
On Sun, Feb 17, 2013 at 02:49:39AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
--- a/remote-curl.c
[...]
+ if (read_packets_until_flush(last-buf, last-len) 0)
Style nit: this made me wonder What would it mean if
read_packets_until_flush() 0?
[...]
My
Jeff King wrote:
On Sun, Feb 17, 2013 at 03:05:34AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
+ if (verify_ref_advertisement(last-buf, last-len) 0)
+ die(ref advertisement is invalid at %s, refs_url);
Won't this error out with
protocol error: bad
Junio C Hamano wrote:
W. Trevor King wk...@tremily.us writes:
There is no need to use here documents to setup this configuration.
It is easier, less confusing, and more robust to use `git remote add`
directly.
[...]
This looks like a good 'maint' material that can be applied straight
away
() never
returns an error when !gentle.
No functional change intended.
FWIW, the patch itself is
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
Jeff King wrote:
Originally packets were used just for the line-oriented ref
advertisement and negotiation. These days, we also stuff
packfiles and sidebands into them, and they do not
necessarily represent a line. Drop the _line suffix, as it
is not informative and makes the function names
Jeff King wrote:
The packet_read function reads from a descriptor.
Ah, so this introduces a new analagous helper that reads from
a strbuf, to avoid the copy-from-async-procedure hack?
[...]
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -103,12 +103,26 @@ static int safe_read(int fd, void *buffer,
Jeff King wrote:
I don't know that this code was hurting anything, but it has always
struck me as ugly and a possible source of error. And now it's gone.
Heh. Belongs in the commit message, presumably.
I don't think the async procedure was very harmful, but it's nice to
avoid the cost of a
Jeff King wrote:
remote-curl.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
I like.
--
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
Jeff King wrote:
But is it noisy about a missing pipe? We do not get EPIPE for reading.
Ah, that makes more sense.
[...]
+ len = packet_read_from_buf(line, sizeof(line), last-buf,
last-len);
+ if (len line[len - 1] == '\n')
+ len--;
Was anything
Jeff King wrote:
On Mon, Feb 18, 2013 at 02:19:15AM -0800, Jonathan Nieder wrote:
In combination with patch 3, this changes the meaning of packet_read()
without changing its signature, which could make other patches
cherry-picked on top change behavior in unpredictable ways. :(
So I'd
-by: Jonathan Nieder jrnie...@gmail.com
Patch left unsnipped for reference.
---
contrib/completion/git-prompt.sh | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 9b2eec2
Hi,
Jeff King wrote:
I will do it again, if people feel strongly about Git being a part of
it. However, I have gotten a little soured on the GSoC experience. Not
because of anything Google has done; it's a good idea, and I think they
do a fine of administering the program. But I have noticed
Ramkumar Ramachandra wrote:
Take what I'm about to say with a pinch of salt, because I've never mentored.
Mentors often don't provide much technical assistance: students should
just post to the list with queries, or ask on #git-devel. Mentors
serve a different purpose; their primary
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
- cross-compilable git
Why, exactly? Git for embedded devices?
My personal motivation would be building Git for Windows while
spending as little time on Windows as possible. People deploying git
to 32-bit x86, 64-bit x86, and ARM (think
Jeff King wrote:
On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:
Some potential projects (unfiltered --- please take them with a grain
of salt):
[...]
- collaborative notes editing: fix the default notes refspec,
make sure the notes pull workflow works well
, 13 insertions(+), 14 deletions(-)
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks for the quick turnaround.
--
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
(not a new problem, but a downside nonetheless) is that
it means the test doesn't demonstrate what --cleanup=verbatim --status
will do.
How about something like this?
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
diff --git i/t/t7502-commit.sh w/t/t7502-commit.sh
index cbd7a459..64162fce 100755
Jonathan Nieder wrote:
+++ w/t/t7502-commit.sh
[...]
+ # Please enter the commit message for your changes. Lines
starting
+ # with '\''#'\'' will be kept; you may remove them yourself if
you want to.
+ # An empty message aborts the commit
-commit: resurrect behavior for multiple -m
options, 2007-11-11
and
v1.5.4-rc2~3^2 Allow selection of different cleanup modes for commit
messages, 2007-12-22
The patch makes sense and makes the test easier to read, so
Reviewed-by: Jonathan Nieder jrnie
. And no other code path
touches 'message', so it always consists of complete lines.
Thanks for a clear patch and explanation.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
(rest of patch kept unsnipped for reference)
}
return 0;
}
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
can be changed by the 'commit.cleanup' configuration variable
Yeah, the current text is a bit choppy. How about this?
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
--- i/Documentation/git-commit.txt
+++ w/Documentation/git-commit.txt
@@ -172,16 +172,25 @@ OPTIONS
linkgit:git-commit
Ramkumar Ramachandra wrote:
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
Hold on a second. I'm not remembering such a grim outcome with 100%
failure from prior summers of code as you're describing.
Brandon Casey wrote:
Hmm, I think the original text was more confusing than I realized. I
think we should reorder the cleanup modes, placing default last, and
then describe default in terms of either strip or whitespace depending
on whether an editor will be spawned.
Sounds good to me. :)
]).
Problems:
* There's a weird extra blank line after default
* Wrong indentation for the final paragraph.
* The linkgit isn't resolved for some reason.
The following fixes it for me.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/git-commit.txt | 7 ---
1 file changed, 4
Jeff King wrote:
The write_or_die function will always die on an error,
including EPIPE. However, it currently treats EPIPE
specially by suppressing any error message, and by exiting
with exit code 0.
Suppressing the error message makes some sense; a pipe death
may just be a sign that the
Jeff King wrote:
On Wed, Feb 20, 2013 at 01:51:11PM -0800, Jonathan Nieder wrote:
+ if (err == EPIPE) {
+ signal(SIGPIPE, SIG_DFL);
+ raise(SIGPIPE);
+ /* Should never happen, but just in case... */
+ exit(141);
How about
die(BUG
Jeff King wrote:
On Wed, Feb 20, 2013 at 02:01:14PM -0800, Jonathan Nieder wrote:
How about
die(BUG: another thread changed SIGPIPE handling behind my
back!);
to make it easier to find and fix such problems?
You mean for the should never happen bit, not the first part, right
trees, commits, and
tags.
Reported-by: Mantas Mikulėnas graw...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi Mantas,
Mantas Mikulėnas wrote:
When messing around with various repositories, I noticed that git 1.8
(currently using 1.8.2.rc0.22.gb3600c3) has problems parsing tag
801 - 900 of 2895 matches
Mail list logo
