Hi Junio,
On Mon, 1 Dec 2014, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Johannes Schindelin johannes.schinde...@gmx.de writes:
+static const char *update_worktree(unsigned char *sha1)
+{
+...
+ const char *work_tree = git_work_tree_cfg ? git_work_tree_cfg :
Hi Junio,
On Mon, 1 Dec 2014, Junio C Hamano wrote:
When receive.denyCurrentBranch is set to updateInstead, this hook
can be used to override the built-in push-to-deploy logic, which
insists that the working tree and the index must be unchanged
relative to HEAD. The hook receives the commit
On Tue, Dec 2, 2014 at 8:04 AM, Jeff King p...@peff.net wrote:
On Mon, Dec 01, 2014 at 05:17:22AM +0100, Christian Couder wrote:
On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano gits...@pobox.com wrote:
If I were redoing this today, I would probably nominate the git
potty as such a kitchen
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
I disagree that --exit-code does nothing: it indicates whether the
listed log is empty. So for example
git log -1 --exit-code a..b /dev/null
can be used to figure out whether a is a proper ancestor of b or
not.
On Tue, Dec 2, 2014 at 3:02 AM, Junio C Hamano gits...@pobox.com wrote:
Does this contain a lot of borrowed code or something? The style
violation in the patches are unusually high, even compared with your
other series.
The first one is from coreutils, but I reformatted (and trimmed) to
fit
On Tue, Dec 2, 2014 at 12:42 PM, Jeff King p...@peff.net wrote:
On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
This is something else that's been sitting in my tree for a while now.
It adds git list-files, intended to be aliased as ls with your
favourite display
On Tue, Dec 2, 2014 at 12:39 AM, Junio C Hamano gits...@pobox.com wrote:
Sorry, what is a hic?
Off topic. It's the sound (in Vietnamese) when you inhale through your
nose, e.g. like when you cry.. I know there's an equivalent in
English, just can't remember it now.
--
Duy
--
To unsubscribe from
On Tue, Dec 2, 2014 at 12:04 PM, Mark Levedahl mleved...@gmail.com wrote:
On 12/01/2014 12:39 PM, Junio C Hamano wrote:
Sorry, what is a hic? If this were an existing feature like
git-new-workdir, even though it is from contrib, making it impossible to do
something that used to be possible,
On Tue, Dec 2, 2014 at 9:50 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sunday, November 30, 2014, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
This is more user friendly version of ls-files:
* it's automatically colored and columnized
* it refreshes the index like all porcelain
On Tue, Dec 2, 2014 at 2:32 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This allows the callback to use 'base' as a temporary buffer to
quickly assemble full path without extra allocation. The callback
has to restore it afterwards of course.
Changes since v4
* Fix styles as Junio C Hamano suggested.
* Limit number of languages and length of Accept-Language header.
Yi EungJun (1):
http: Add Accept-Language header if possible
http.c | 154 +
remote-curl.c
From: Yi EungJun eungjun...@navercorp.com
Add an Accept-Language header which indicates the user's preferred
languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
Examples:
LANGUAGE= -
LANGUAGE=ko:en - Accept-Language: ko, en;q=0.9, *;q=0.1
LANGUAGE=ko LANG=en_US.UTF-8 -
From 9096652a71666920ae8d59dd4317d536ba974d5b Mon Sep 17 00:00:00 2001
From: Aarni Koskela a...@iki.fi
Date: Tue, 2 Dec 2014 13:56:15 +0200
Subject: [PATCH] git-add--interactive: allow list (un)selection by regular
expression
Teach `list_and_choose` to allow `/regexp` and `-/regexp` syntax to
On Tue, Dec 2, 2014 at 2:40 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Hmph, that's sad. Should the below say test_expect_failure
without test_must_fail, anticipating a fix later?
Not a
Good Morning,
My name is Sefath, and I was wondering when i could start using Git for Mac.
I’m completely new to coding, and I wanted to start with HTML. However, when I
tried installing git bash on my mac, it doesn’t work. Maybe it isn’t compatible
with OS X Yosmite? I would really love to
On Tue, Dec 02, 2014 at 02:30:31PM +0300, Sergey Organov wrote:
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
I disagree that --exit-code does nothing: it indicates whether the
listed log is empty. So for example
git log -1 --exit-code a..b /dev/null
Jeff King schrieb am 02.12.2014 um 06:42:
On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
This is something else that's been sitting in my tree for a while now.
It adds git list-files, intended to be aliased as ls with your
favourite display options.
When I read the
Jeff King schrieb am 28.11.2014 um 17:50:
[updated subject, as this is not specific to the v2.2.0 release at all]
On Fri, Nov 28, 2014 at 10:48:51AM +0100, Michael J Gruber wrote:
Are you running gnome_keyring_deamon by any chance? It think it runs by
default in Gnome, claims to offer
Johannes Schindelin schrieb am 02.12.2014 um 09:47:
Hi Junio,
On Mon, 1 Dec 2014, Junio C Hamano wrote:
When receive.denyCurrentBranch is set to updateInstead, this hook
can be used to override the built-in push-to-deploy logic, which
insists that the working tree and the index must be
Hi Michael,
On Tue, 2 Dec 2014, Michael J Gruber wrote:
Johannes Schindelin schrieb am 02.12.2014 um 09:47:
The only sad part is that the already huge test suite is enlarged by
yet another extensive set of test cases (and those tests might not
really need to be that extensive because
Before gnupg 2.1 (aka modern branch), gpghome would contain only files
which allowed t/lib-gpg.sh to set permissions explicitely, and we did
that since
28a1b07 (t/lib-gpg: adjust permissions for gnupg 2.1, 2014-12-02)
in order to adjust wrong permissions from a checkout on ro file systems.
gnupg
Jeff,
Thanks much for the detailed answer and analysis.
Does either of you want to try your hand at a patch? Just enabling
copies should be a one-liner. Making it configurable is more involved,
but should also be pretty straightforward.
I'll have to pass on this. I'm absolutely not familiar
Johannes Schindelin johannes.schinde...@gmx.de writes:
This is because you know receive-pack runs inside the $GIT_DIR,
whether it is a bare or non-bare repository, so either core.worktree
points at a directory that is otherwise unrelated to the $GIT_DIR
(but is the correct $GIT_WORK_TREE), or
I've finished testing this work in larger repositories.
While the approach is performant and works nicely in small repos, but
in larger repos one of the requirements for the correctness of
substitutions slows things down (1 or 2 minutes to perform checkouts
between branches with 10,000+ files).
Johannes Schindelin johannes.schinde...@gmx.de writes:
In this particular case, I think that we really, really *just* need to
verify that the presence of the hook switches off the default behavior of
updateInstead. *Nothing* else is needed to verify that this particular
functionality hasn't
Hi Junio,
On Tue, 2 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
In this particular case, I think that we really, really *just* need to
verify that the presence of the hook switches off the default behavior of
updateInstead. *Nothing* else is
Hi Junio,
On Tue, 2 Dec 2014, Junio C Hamano wrote:
This feature [...] needs to be documented with an entry in the BUGS
section, saying that it will not work in a repository that is tied to
its working tree via the gitdir: mechanism.
Fair enough. But which BUGS section? Should I add one to
Johannes Schindelin johannes.schinde...@gmx.de writes:
Not really. You need to remember that we write tests not to show
off the new shiny, but to protect essential invariants from being
broken by careless others attempting to rewrite the implementation
in the future.
Fair enough. You are
My current approach is:
1) find files common between @ @{-1}, ls-tree --full-tree
--name-only -r both branches, take the intersection
2) find current branch's commits for common files, for each file in
intersection log -1 --format=%H $current_branch -- $file
3) find common files where
Hi Junio,
On Tue, 2 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Not really. You need to remember that we write tests not to show
off the new shiny, but to protect essential invariants from being
broken by careless others attempting to rewrite
Johannes Schindelin johannes.schinde...@gmx.de writes:
... (i.e. by only lightly testing obscure code paths that will be
executed rarely, risking bugs in favor of adding tests when fixing said
bugs when – and if – they arise).
I'd like to learn a bit more about this part, not because I want
Junio C Hamano gits...@pobox.com writes:
Johannes Schindelin johannes.schinde...@gmx.de writes:
This is because you know receive-pack runs inside the $GIT_DIR,
whether it is a bare or non-bare repository, so either core.worktree
points at a directory that is otherwise unrelated to the
Jeff King p...@peff.net writes:
There is also git var, which is a catch-all for printing some deduced
environmental defaults. I'd be just as happy to see it go away, though.
Having:
git --exec-path
git --toplevel
git --author-ident
all work would make sense to me (I often get
Aarni Koskela aarni.kosk...@andersinnovations.com writes:
From 9096652a71666920ae8d59dd4317d536ba974d5b Mon Sep 17 00:00:00 2001
From: Aarni Koskela a...@iki.fi
Date: Tue, 2 Dec 2014 13:56:15 +0200
Subject: [PATCH] git-add--interactive: allow list (un)selection by regular
expression
Remove
Duy Nguyen pclo...@gmail.com writes:
FWIW git-branch usually can show the original branch of detached head
(must not always). I don't think we have a plumbing equivalent for it
though. People can tail -1 $GIT_DIR/logs/HEAD| sed .. but that seems
hacky.
@{-1}, i.e. the last branch I checked
PPS: Sounds like I need Peff's git-blame-tree from here:
https://github.com/peff/git/compare/jk/faster-blame-tree
--
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 p...@peff.net writes:
For a public repository, it might make sense to provide a config option
to loosen the is_our_ref check completely (i.e., to just has_sha1_file).
But such an option does not yet exist.
In principle, yes, but that cannot be has_sha1_file(); it has to
have a fully
On Saturday 29 November 2014 13:31:18 Philip Oakley wrote:
From: Peter Wu pe...@lekensteyn.nl
Ok, I will make a clear note about the default (without --only)
behavior
having weird behavior for historical reasons. Are you really OK with
--only=both? It sounds a bit odd (mathematically
Jeff King p...@peff.net writes:
Interestingly, the rename behavior dates all the way back to:
commit 753fd78458b6d7d0e65ce0ebe7b62e1bc55f3992
Author: Linus Torvalds torva...@ppc970.osdl.org
Date: Fri Jun 17 15:34:19 2005 -0700
Use -M instead of -C for git diff and git status
On Tue, Dec 2, 2014 at 1:21 PM, Nizamuddin Chowdhury
mchowdhur...@gmail.com wrote:
Good Morning,
My name is Sefath, and I was wondering when i could start using Git for Mac.
I’m completely new to coding, and I wanted to start with HTML. However, when
I tried installing git bash on my mac,
On Tue, Dec 02, 2014 at 09:45:06AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
For a public repository, it might make sense to provide a config option
to loosen the is_our_ref check completely (i.e., to just has_sha1_file).
But such an option does not yet exist.
In
On Mon, Mar 24, 2014 at 09:38:27PM +, Luis Henriques wrote:
Add --[no-]xmailer that allows a user to disable adding the 'X-Mailer:'
header to the email being sent.
Ping
It's been a while since I sent this patch. Is there any interest in
having this switch in git-send-email?
I honestly
On Tue, Dec 02, 2014 at 09:57:07AM -0800, Junio C Hamano wrote:
To get a rough sense of how much effort is entailed in the various
options, here are git log --raw timings for git.git (all timings are
warm cache, best-of-five, wall clock time):
The rationale of the change talks about big
On Tue, Dec 02, 2014 at 06:45:52PM +0700, Duy Nguyen wrote:
As a side note, I wonder if it would be sensible to whitelist some
commands as porcelain, and allow aliases to override them (either
entirely, or just to add-in some options).
Agreed. Maybe not all porcelain (some like
Am 01.12.2014 um 00:27 schrieb Max Kirillov:
builtin/checkout.c: use absolute path instead of given argument for
picking worktree name, it happens to be needed because for submodule
checkout the new worktree is always .
environment.c: add GIT_COMMON_DIR to local_repo_env
git-submodule.sh:
On Tue, Dec 02, 2014 at 02:40:27PM +0100, Michael J Gruber wrote:
Before gnupg 2.1 (aka modern branch), gpghome would contain only files
which allowed t/lib-gpg.sh to set permissions explicitely, and we did
that since
28a1b07 (t/lib-gpg: adjust permissions for gnupg 2.1, 2014-12-02)
in order
On Tue, Dec 02, 2014 at 01:55:31PM +0100, Michael J Gruber wrote:
That private-keys directory is from the first run of gpg2.1 on a pre-2.1
GPGHOME. It converts the old secring db to that new dir of entries and
uses that instead.
Thanks for untangling this. As I mentioned elsewhere in the
On Tue, Dec 02, 2014 at 04:21:33PM -0500, Jeff King wrote:
I'm not sure if the most expedient path is trying to convince gpg
developers that it's a bug, or if there is some workaround (like
--passphrase-file /dev/null or something).
I've been using the patch below to test, and am tempted to
On Tue, Dec 2, 2014 at 5:55 PM, Jeff King p...@peff.net wrote:
So from these timings, I'd conclude that:
1. It's probably fine to turn on copies for git status.
2. It's probably even OK to use -C -C for some projects. Even though
22s looks scary there, that's only 11ms for git.git
On Wed, Dec 03, 2014 at 08:40:47AM +1100, Bryan Turner wrote:
On Tue, Dec 2, 2014 at 5:55 PM, Jeff King p...@peff.net wrote:
So from these timings, I'd conclude that:
1. It's probably fine to turn on copies for git status.
2. It's probably even OK to use -C -C for some projects.
On Tue, Dec 02, 2014 at 09:45:24PM +0100, Jens Lehmann wrote:
But, while hacking the submodule init I became more
convinced that the modules directory should be common and
submodules in checkout should be a checkouts of the
submodule. Because this is looks like concept of
submodules, that
Peter Wu pe...@lekensteyn.nl writes:
On Saturday 29 November 2014 13:31:18 Philip Oakley wrote:
From: Peter Wu pe...@lekensteyn.nl
Ok, I will make a clear note about the default (without --only)
behavior
having weird behavior for historical reasons. Are you really OK with
--only=both?
I just downloaded the latest git, and tried to build with:
make configure
./configure
make all doc
build failed while building doc, asciidoc not found
I would have thought the configure would have detected that.
I downloaded, built, and installed asciidoc, and re-built git, things
Jeff King p...@peff.net writes:
Taking a step back, though, I am not sure I understand the reasoning
behind the original e7f224f. The rationale in the commit message is that
we want to make sure that the files are writable. But why would they not
be? They are created by cp -R,...
Wait.
At $DAYJOB, we have a Git server[0] that supports the smart HTTP
protocol. That server can return a 401 if the repository is private or
doesn't exist.
We have several scripts, some of which run interactively, some not, that
we simply want to fail if git fetch gets a non-2xx code. Unfortunately,
On Tue, Dec 02, 2014 at 03:57:50PM -0800, Junio C Hamano wrote:
Wait. After doing this,
$ mkdir -p src/a src/b 2src/a/c chmod a-w src/b src/a/c
$ cp -R src dst
$ ls -lR dst
dst/b and dst/a/c are 0440 (with umask 0027, which makes src/b and
src/a/c also 0440, which is
On Tue, Dec 02, 2014 at 04:32:56PM -0700, Mike Berry wrote:
The documentation is still causing me trouble as my firewall doesn't like
the html in Documentation/docbook.xsl, but that's probably a firewall issue.
Is there documentation method, not requiring active web access?
If you have XML
On Tue, Dec 2, 2014 at 12:26 PM, Junio C Hamano gits...@pobox.com wrote:
Aarni Koskela aarni.kosk...@andersinnovations.com writes:
From 9096652a71666920ae8d59dd4317d536ba974d5b Mon Sep 17 00:00:00 2001
From: Aarni Koskela a...@iki.fi
Date: Tue, 2 Dec 2014 13:56:15 +0200
Subject: [PATCH]
On Tue, Dec 2, 2014 at 7:11 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Dec 2, 2014 at 2:32 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This allows the callback to use 'base' as a temporary buffer to
quickly assemble full path without extra
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano gits...@pobox.com wrote:
Torsten Bögershausen tbo...@web.de writes:
On 12/01/2014 04:02 AM, Michael Blume wrote:
I have no idea whether this should concern anyone, but my mac build of git
shows
CC imap-send.o
imap-send.c:183:36: warning:
(+peff)
Hi,
brian m. carlson wrote:
We've used GIT_ASKPASS=/bin/echo, which seems to solve the problem,
although it's ugly and I'm concerned it might break in the future. Is
there a better way to do this?
That's a good question. Before falling back to the askpass based
prompt, Git tries
On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano gits...@pobox.com wrote:
Torsten Bögershausen tbo...@web.de writes:
On 12/01/2014 04:02 AM, Michael Blume wrote:
I have no idea whether this should concern anyone, but
On Tue, Dec 02, 2014 at 04:59:53PM -0800, Jonathan Nieder wrote:
brian m. carlson wrote:
We've used GIT_ASKPASS=/bin/echo, which seems to solve the problem,
although it's ugly and I'm concerned it might break in the future. Is
there a better way to do this?
That's a good question.
Jeff King wrote:
On Tue, Dec 02, 2014 at 04:59:53PM -0800, Jonathan Nieder wrote:
As long as you have no credential helpers configured, your GIT_ASKPASS
based approach should work fine.
Yeah, it's fine (as is GIT_ASKPASS=true). You could also provide a
credential helper that gives you an
On Tue, Dec 02, 2014 at 05:29:50PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
On Tue, Dec 02, 2014 at 04:59:53PM -0800, Jonathan Nieder wrote:
As long as you have no credential helpers configured, your GIT_ASKPASS
based approach should work fine.
Yeah, it's fine (as is
On Sun, Nov 30, 2014 at 6:46 PM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
It seems like a few desirable features are being talked about here, and
summarizing the discussion as centralized vs decentralized is too
simplistic. What is really
Stefan Beller wrote:
No changes since sending it 5 days ago.
branch.c | 13 +
builtin/commit.c | 10 +++
builtin/fetch.c| 12
builtin/receive-pack.c | 13 -
builtin/replace.c | 10 +++
builtin/tag.c | 10 +++
Luis Henriques hen...@camandro.org wrote:
On Mon, Mar 24, 2014 at 09:38:27PM +, Luis Henriques wrote:
Add --[no-]xmailer that allows a user to disable adding the 'X-Mailer:'
header to the email being sent.
Ping
It's been a while since I sent this patch. Is there any interest in
Stefan Beller wrote:
The updates are only holding refs not reflogs, so express it to the reader.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Makes sense.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
On Tue, Dec 2, 2014 at 8:12 PM, Michael Blume blume.m...@gmail.com wrote:
On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano gits...@pobox.com wrote:
I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
Stefan Beller wrote:
When performing a reflog transaction update, only write to the reflog iff
msg is non-NULL. This can then be combined with REFLOG_TRUNCATE to perform
an update that only truncates but does not write. This change only affects
whether or not a reflog entry should be
Stefan Beller wrote:
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
[...]
@@ -290,7 +291,7 @@ static int unreachable(struct expire_reflog_cb *cb,
struct commit *commit, unsig
static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
const char *email,
On Dec 2, 2014, at 18:34, Eric Wong wrote:
Luis Henriques hen...@camandro.org wrote:
On Mon, Mar 24, 2014 at 09:38:27PM +, Luis Henriques wrote:
Add --[no-]xmailer that allows a user to disable adding the 'X-
Mailer:'
header to the email being sent.
Ping
It's been a while since I
Stefan Beller wrote:
How are non-regulars/newcomers, who supposingly need more iterations on
a patch, supposed to handle the inter patch change log conveniently?
I think this is one of the more important issues.
I don't think there's any reason that newcomers should need more
iterations than
We have been silently tolerating errors by returning early with an
error that the caller ignores since rerere.autoupdate was introduced
in v1.6.0-rc0~120^2 (2008-06-22). So on error (for example if the
index is already locked), rerere can return success silently without
updating the index or with
Stefan Beller wrote:
On Mon, Nov 17, 2014 at 4:48 PM, Jonathan Nieder jrnie...@gmail.com wrote:
After this patch, setting errno is not part of the contract of
copy_fd, so the bug Ronnie was fixing is gone.
But it's a little more invasive. What do you think?
I really like that approach and
When preparing an error message in a strbuf, it can be convenient
to add a formatted string to the beginning:
if (transaction_commit(t, err)) {
strbuf_prefixf(err, cannot fetch '%s': , remotename);
return -1;
}
The new strbuf_prefixf is like
The objects directory is spelled as get_object_directory(), not
git_path(objects). Some other code still hard-codes the objects/
directory name, so in the long term we may want to get rid of the
pretense of support for GIT_OBJECT_DIRECTORY altogether, but this
makes the code more consistent for
This way, callers can put the message in context or even avoid
printing the message altogether.
Currently hold_lock_file_for_append tries to save errno in order to
produce a meaningful message about the failure and tries to print a
second message using errno. Unfortunately the errno it uses is
This way, the code does not need to carefully safeguard errno to allow
callers to print a reasonable error message when they choose to do
some cleanup before die()-ing.
Fixes a bug waiting to happen where copy_fd would clobber the errno
passed back via hold_lock_file_for_append from read() or
This saves us from having to be careful about preserving errno and
makes it more explicit in the die-on-error case that the caller is
exiting without a chance to clean up.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/clone.c | 6 +-
refs.c | 17 ++---
When the lockfile API was introduced, it was only used for the index
file and error messages like
fatal: Unable to create '/path/to/foo.lock': File exists.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other
The usual way to handle errors from hold_lock_file_for_update is to
get a message from unable_to_lock_message or unable_to_lock_die, which
can explain to the user how to check for other git processes running
concurrently and unlink the .lock file if safe.
fast-import didn't use the
If writing $HOME/.git-credentials.lock (or locking another file
specified with the --file option) fails due to the lock file already
existing, chances are that it is because another git process already
locked the file. Use the message from the lockfile API that says so,
to help the user to look
The message from the lockfile API includes advice about how to remove
a stale lock file after a previous git process crashed.
Pass the LOCK_OUTSIDE_REPOSITORY flag to avoid confusing error
messages that imply the lockfile is under .git. These functions (and
'git config --file') are useful for
We have been silently tolerating errors by returning early with an
error that the caller ignores since rerere.autoupdate was introduced
in v1.6.0-rc0~120^2 (2008-06-22). So on error (for example if the
index is already locked), rerere can return success silently without
updating the index or with
Today hold_locked_index takes a boolean parameter indicating whether
to die with a message or to return -1 with errno indicating the nature
of the problem on error.
Pass back an error message through an 'err' parameter instead. This
method of error reporting was introduced in the ref transaction
This makes it more obvious when callers forget to print a message on
error, while still giving callers a chance to clean up before exiting.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/technical/api-lockfile.txt | 33 +++-
builtin/apply.c
The old callers now use the message passed back by
hold_lock_file_for_update / hold_lock_file_for_append instead of
trying to interpret errno.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
lockfile.c | 8
lockfile.h | 1 -
2 files changed, 9 deletions(-)
diff --git a/lockfile.c
The old external callers now use the message passed back by
hold_lock_file_for_update / hold_lock_file_for_append instead of
trying to interpret errno.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
That's the end of the series. Thanks for reading.
Thoughts?
lockfile.c | 42
On 12/03/2014 06:14 AM, Jonathan Nieder wrote:
This way, the code does not need to carefully safeguard errno to allow
callers to print a reasonable error message when they choose to do
some cleanup before die()-ing.
Fixes a bug waiting to happen where copy_fd would clobber the errno
passed back
Torsten Bögershausen wrote:
On 12/03/2014 06:14 AM, Jonathan Nieder wrote:
--- a/lockfile.c
+++ b/lockfile.c
@@ -179,45 +179,36 @@ int hold_lock_file_for_update(struct lock_file *lk,
const char *path, int flags)
return fd;
}
-int hold_lock_file_for_append(struct lock_file *lk,
92 matches
Mail list logo
