Using the new refs/worktree/ refs, make bisection per-worktree.
Signed-off-by: David Turner dtur...@twopensource.com
---
Documentation/git-bisect.txt | 4 ++--
Documentation/rev-list-options.txt | 14 +++---
bisect.c | 2 +-
builtin/rev-parse.c
We need a place to stick refs for bisects in progress that is not
shared between worktrees. So we use the refs/worktree/ hierarchy.
The is_per_worktree_ref function and associated docs learn that
refs/worktree/ is per-worktree, as does the git_path code in path.c
The ref-packing functions learn
This is version 5 of my patch series which aims to improve
guessed directory names in several cases.
This version now includes the patches from Jeff which were
previously a separate patch series. Besides fixing behavior when
cloning a repository with trailing '.git' suffix they also add a
new
If the URI contains authentication data and the URI's path
component is empty we fail to guess a sensible directory name.
E.g. cloning a repository 'ssh://user:passw...@example.com/' we
guess a directory name 'passw...@example.com' where we would want
the hostname only, e.g. 'example.com'.
The
If the URI contains a port number and the URI's path component is
empty we fail to guess a sensible directory name. E.g. cloning a
repository 'ssh://example.com:/' we guess a directory name
'' where we would want the hostname only, e.g. 'example.com'.
We need to take care to not drop
From: Jeff King p...@peff.net
Commit 7e837c6 (clone: simplify string handling in
guess_dir_name(), 2015-07-09) changed clone to use
strip_suffix instead of hand-rolled pointer manipulation.
However, strip_suffix will strip from the end of a
NUL-terminated string, and we may have already stripped
Due to various components of the URI being stripped off it may
happen that we fail to guess a directory name. We currently error
out with a message that it is impossible to create the working
tree '' in such cases. Instead, error out early with a sensible
error message hinting that a directory
From: Jeff King p...@peff.net
When we run git clone $url, clone guesses from the $url
what to name the local output directory. We don't have any
test coverage of this, so let's add some basic tests.
This reveals a few problems:
- cloning foo.git/ does not properly remove the .git;
this is
Junio C Hamano gitster at pobox.com writes:
Yes, my use case is that I get confused about whether the stash has been
dropped or not and whether I might have stashed something else in the
meantime. So for me plain 'git stash drop' feels a bit dangerous.
Then git stash apply followed by git
Hi Peff,
On 2015-08-10 07:23, Jeff King wrote:
diff --git a/compat/pipe-id.c b/compat/pipe-id.c
new file mode 100644
index 000..4764c5f
--- /dev/null
+++ b/compat/pipe-id.c
@@ -0,0 +1,25 @@
+#include git-compat-util.h
+#include compat/pipe-id.h
+#include strbuf.h
+
+const char
Hi Ryan,
On 2015-08-10 15:54, Kiser, Ryan Lee wrote:
I've downloaded the Windows installer for Git,
Which one.
but can't seem to find hashes published anywhere for verification. Since the
downloaded file doesn't seem to be signed,
The newest ones from https://git-for-windows.github.io/
Jeff King p...@peff.net writes:
The problem is that git_path uses a static buffer that gets overwritten
by subsequent calls.
As the rotating static buffer pattern used in get_pathname() was
modeled after sha1_to_hex(), we have the same issue there. They are
troubles waiting to happen unless
per...@pluto.rain.com (Perry Hutchison) writes:
... we do not say append 'refs/remotes/anything/' for various
values of anything and see if such a ref exists when resolving
an abbreviated refname 'master'.
checkout appears to.
You are referring to this part of the documentation:
If
Torsten Bögershausen tbo...@web.de writes:
Actually I could reproduce the following:
CRLF in repo, CRLF in working tree, core.autocrlf= true.
What should happen in such a case? Wouldn't autocrlf=true want to
strip CRLF down to LF? Shouldn't it? And if so, blame is correct
to say that you
On Mon, Aug 10, 2015 at 06:38:10PM +0200, Johannes Schindelin wrote:
+const char *pipe_id_get(int fd)
+{
+ static struct strbuf id = STRBUF_INIT;
+ struct stat st;
+
+ if (fstat(fd, st) 0 || !S_ISFIFO(st.st_mode))
+ return NULL;
Just a quick note: it seems that
On Mon, Aug 10, 2015 at 10:31:32AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
The problem is that git_path uses a static buffer that gets overwritten
by subsequent calls.
As the rotating static buffer pattern used in get_pathname() was
modeled after sha1_to_hex(), we
Torsten Bögershausen tbo...@web.de writes:
So I think that git clone can be slighty more consistant here.
Sure.
I _think_ taking notice of word:// (with doubled slashes) and
treating it specially will not introduce any new issue; while it is
still OK for users to have a local directory
On Fri, Aug 7, 2015 at 11:20 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
... if
you really want to go the thread route, the first thing to try
would be to see if a few places we already use threads for
parallelism (namely, grep, pack-objects,
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
find_shared_symref and die if we find one. This prevents simultaneous
merges to the same notes branch from different worktrees.
Signed-off-by: David Turner dtur...@twopensource.com
---
This reroll addresses Eric Sunshine's comments on
Add a new function, find_shared_symref, which contains the heart of
die_if_checked_out, but works for any symref, not just HEAD. Refactor
die_if_checked_out to use the same infrastructure as
find_shared_symref.
Soon, we will use find_shared_symref to protect notes merges in
worktrees.
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
find_shared_symref and die if we find one. This prevents simultaneous
merges to the same notes branch from different worktrees.
Signed-off-by: David Turner dtur...@twopensource.com
---
builtin/notes.c | 6
SZEDER Gábor sze...@ira.uka.de writes:
'git config' can only show values or name-value pairs, so if a shell
script needs the names of set config variables it has to run 'git config
--list' or '--get-regexp' and parse the output to separate config
variable names from their values. However,
Jeff King p...@peff.net writes:
On Fri, Aug 07, 2015 at 05:24:29PM -0700, Junio C Hamano wrote:
Since 5a688fe4 (core.sharedrepository = 0mode should set, not
loosen, 2009-03-25), we kept reminding ourselves:
NEEDSWORK: this should be renamed to finalize_temp_file() as
moving is
Sorry, that should have included the first patch as well. Will re-send
as .v7
On Mon, 2015-08-10 at 13:43 -0400, David Turner wrote:
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
find_shared_symref and die if we find one. This prevents simultaneous
merges to the same notes
Ah, perfect. Thank you. I was looking at 1.9.5 from
http://www.git-scm.com/download
Thanks for pointing me at the right place.
-Ryan
-Original Message-
From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de]
Sent: Monday, August 10, 2015 12:10 PM
To: Kiser, Ryan Lee
Patrick Steinhardt p...@pks.im writes:
This is version 5 of my patch series which aims to improve
guessed directory names in several cases.
This version now includes the patches from Jeff which were
previously a separate patch series. Besides fixing behavior when
cloning a repository with
Ed Avis e...@waniasset.com writes:
Yes, my use case is that I get confused about whether the stash has been
dropped or not and whether I might have stashed something else in the
meantime. So for me plain 'git stash drop' feels a bit dangerous.
Then git stash apply followed by git stash drop
On Mon, Jun 15, 2015 at 2:48 PM, Junio C Hamano gits...@pobox.com wrote:
Thanks. Will replace and wait for comments from others.
I have reviewed the patches carefully and they look good to me.
As Git is a large project and I was active in other parts until now,
I noticed that there are subtle
On 2015-08-10 20.48, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
Actually I could reproduce the following:
CRLF in repo, CRLF in working tree, core.autocrlf= true.
What should happen in such a case? Wouldn't autocrlf=true want to
strip CRLF down to LF? Shouldn't it?
Differences from
[v2](http://www.mail-archive.com/git@vger.kernel.org/msg75467.html)
- removed unintended whitespace changes
- cleanup based on comments from v2
Michael Rappazzo (1):
worktree: add 'list' command
Documentation/git-worktree.txt | 6 +++-
builtin/worktree.c |
Adam Dinwoodie a...@dinwoodie.org writes:
If the desired goal is that Cygwin's link(2) acts like POSIX link(2)
on network drives, I'm not convinced that's possible, at least not by
emulating `core.createObject = rename` in the Cygwin library
layer.
The way core.createObject=rename makes
Your Donation to you is ready, contact melc...@gmail.com for more details
--
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
'git worktree list' will list the main worktree followed by any linked
worktrees which were created using 'git worktree add'.
Signed-off-by: Michael Rappazzo rappa...@gmail.com
---
Documentation/git-worktree.txt | 6 +++-
builtin/worktree.c | 67
Michael Rappazzo rappa...@gmail.com writes:
+static int list(int ac, const char **av, const char *prefix)
+{
+ int main_only = 0;
+ struct option options[] = {
+ OPT_BOOL(0, main-only, main_only, N_(only list the main
worktree)),
+ OPT_END()
+ };
Hmm,
On Mon, Aug 10, 2015 at 1:52 PM, David Turner dtur...@twopensource.com wrote:
worktrees: add find_shared_symref
s/worktrees/branch/ perhaps?
Add a new function, find_shared_symref, which contains the heart of
die_if_checked_out, but works for any symref, not just HEAD. Refactor
Jeff King p...@peff.net writes:
No users of hold_lock_file_for_append remain, so remove it.
This does not seem to have anything to do with rotating static buffers
used in get_pathname(); the only effect it has is to conflict heavily
with Michael's tempfile topic X-.
Perhaps this should be part
On Mon, Aug 10, 2015 at 6:29 PM, Jacob Keller jacob.kel...@gmail.com wrote:
On Mon, Aug 10, 2015 at 2:54 AM, Gaurav Chhabra
varuag.chha...@gmail.com wrote:
Apologies for the delay in reply! I tried your suggestion and it
works. Thanks! :)
I'm curious why integer comparison is throwing error.
Jeff King p...@peff.net writes:
There are no callers of the slightly-dangerous static-buffer
git_path_submodule left. Let's drop it.
There are a few callers added on 'pu', though.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Mon, Aug 10, 2015 at 08:36:35AM +, Benkstein, Frank wrote:
You are correct that it is also wrong in git v1.7.0. However, it is correct
in
v2.4.0.
Another bisect gave me this commit which was included in v2.0.1:
commit 4d4813a52f3722854a54bab046f4abfec13ef6ae
Author: brian m.
On Mon, Aug 10, 2015 at 6:06 AM, Jan Viktorin vikto...@rehivetech.com wrote:
On Sun, 9 Aug 2015 14:13:33 -0400
Eric Sunshine sunsh...@sunshineco.com wrote:
One possibility which comes to mind is to create a fake
Authen::SASL::Perl which merely dumps its input mechanisms to a file,
and arrange
On Mon, Aug 10, 2015 at 2:54 AM, Gaurav Chhabra
varuag.chha...@gmail.com wrote:
Apologies for the delay in reply! I tried your suggestion and it
works. Thanks! :)
I'm curious why integer comparison is throwing error. Shouldn't i be
comparing numbers with numeric operator?
Yes, but shell
On Mon, 2015-08-10 at 18:30 -0400, Eric Sunshine wrote:
On Mon, Aug 10, 2015 at 1:52 PM, David Turner dtur...@twopensource.com
wrote:
worktrees: add find_shared_symref
s/worktrees/branch/ perhaps?
Do you mean this is in branch.c, so should be labeled with branch?
Because this change is
On Mon, Aug 10, 2015 at 6:42 PM, David Turner dtur...@twopensource.com wrote:
On Mon, 2015-08-10 at 18:30 -0400, Eric Sunshine wrote:
On Mon, Aug 10, 2015 at 1:52 PM, David Turner dtur...@twopensource.com
wrote:
worktrees: add find_shared_symref
s/worktrees/branch/ perhaps?
Do you mean
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
There are no callers of the slightly-dangerous static-buffer
git_path_submodule left. Let's drop it.
There are a few callers added on 'pu', though.
Actually there is only one. Here is a proposed evil merge.
diff
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
There are no callers of the slightly-dangerous static-buffer
git_path_submodule left. Let's drop it.
There are a few callers added on 'pu', though.
Actually there is only
On 08/10/2015 11:34 AM, Jeff King wrote:
The add_to_alternates_file function blindly uses
hold_lock_file_for_append to copy the existing contents, and
then adds the new line to it. This has two minor problems:
1. We might add duplicate entries, which are ugly and
inefficient.
2.
On Tue, Aug 4, 2015 at 9:01 AM, Karthik Nayak karthik@gmail.com wrote:
Remove show_detached() and make detached HEAD to be rolled into
regular ref_list by adding REF_DETACHED_HEAD as a kind of branch and
supporting the same in append_ref(). This eliminates the need for an
extra function
On Mon, 2015-08-10 at 16:53 -0400, Michael Rappazzo wrote:
+ while ((d = readdir(dir)) != NULL) {
I think it would be useful to break this loop out into a
for_each_worktree function.
While looking into per-worktree ref stuff, I have just noticed that git
prune will delete
On Tue, Aug 4, 2015 at 9:01 AM, Karthik Nayak karthik@gmail.com wrote:
Remove unnecessary variables from ref_list and ref_item which were
used for width computation. This is to make ref_item similar to
ref-filter's ref_array_item. This will ensure a smooth port of
branch.c to use
On Tue, Aug 4, 2015 at 9:01 AM, Karthik Nayak karthik@gmail.com wrote:
This is a preperatory patch for 'roll show_detached HEAD into regular
ref_list'. This patch moves get_head_descrition() to the top so that
s/descrition/description/
it can be used in print_ref_item().
Signed-off-by:
On Mon, 10 Aug 2015 14:26:44 +0200
MS-Informatique i...@ms-informatique.be wrote:
My Windows notebook got updated to Windows 10 and now my Git Bash
doesn't start and when I open an existing repository from Git Gui, I
am getting next error:
0 [main] us 0 init_cheap: VirtualAlloc pointer is
On Mon, Aug 10, 2015 at 10:42:30AM +, Ed Avis wrote:
I would find it useful to ask 'git stash pop' to always drop the stash after
applying it to the working tree, even if there were conflicts. (Only if there
was some hard error, such as an I/O error updating some of the files, should
the
An alternative would be for git stash to always print the name of the stash
it is applying. Then you can drop it afterwards by name and be sure you got
the right one. Printing the name of the stash sounds like a reasonable
bit of chatter to add anyway, do you agree?
--
Ed Avis
Hi,
On 2015-08-10 14:26, MS-Informatique wrote:
My Windows notebook got updated to Windows 10 and now my Git Bash doesn't
start and when I open an existing repository from Git Gui, I am getting next
error:
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
The git_path function has git_pathdup and
strbuf_git_path variants, but git_submodule_path only
comes in the dangerous, static-buffer variant. That makes
refactoring callers to use the safer functions hard (since
they don't exist).
Since we're already using a strbuf behind the scenes, it's
easy
The early part of this test is rather old, and does not
follow our usual style guidelines. In particular:
- the tests liberally chdir, and expect out-of-test cd
commands to return them to a sane state
- test commands aren't indented at all
- there are a lot of minor formatting nits,
The comment above these functions actually describes
sha1_file_name, and comes from the very first revision of
git. Commit 723c31f (Add git_path() and head_ref()
helper functions., 2005-07-05) added git_path, pushing the
comment away from the function it describes; later commits
added more
As with the previous commit to git_path, assigning the
result of mkpath is suspicious, since it is not clear
whether we will still depend on the value after it may have
been overwritten by subsequent calls. This patch converts
low-hanging fruit to use mkpathdup instead of mkpath (with
the downside
Because git_path uses a static buffer that is shared with
calls to git_path, mkpath, etc, it can be dangerous to
assign the result to a variable or pass it to a non-trivial
function. The value may change unexpectedly due to other
calls.
None of the cases changed here has a known bug, but they're
It's an anti-pattern to assign the result of git_path to a
variable, since other calls may reuse our buffer. In this
case, we feed the result to unlink_or_warn immediately
afterwards, so it's OK. However, it's nice to avoid
assignment entirely, which makes it more obvious that
there's no bug.
We
In iterating over the loose refs in refs/foo/, we keep a
running strbuf with refs/foo/one, refs/foo/two, etc. But
we also need to access these files in the filesystem, as
.git/refs/foo/one, etc. For this latter purpose, we make a
series of independent calls to git_path(). These are safe
(we only
From: Jim Hill gjth...@gmail.com
No users of hold_lock_file_for_append remain, so remove it.
hold_lock_file_for_append copies its target file internally.
This makes it too heavyweight for true append-only logging
and too limited for anything else (which probably wants to
process the contents).
Recenty I created a multi-line branch description with '.' and '='
characters on one of the lines, and noticed that fragments of that line
show up when completing set variable names for 'git config', e.g.:
$ git config --get branch.b.description
Branch description to fool the completion
This is a re-roll of the tempfile patch series [1]. I'm sorry for the
long delay getting v2 out. Thanks to Junio and Johannes Sixt for their
feedback about v1. I think I have addressed all of their points.
This version is very similar to v1 in spirit, though quite a few
details have changed. The
'git config' can only show values or name-value pairs, so if a shell
script needs the names of set config variables it has to run 'git config
--list' or '--get-regexp' and parse the output to separate config
variable names from their values. However, such a parsing can't cope
with multi-line
This is a reroll of 'sg/config-name-only'.
* Instead of the two new listing options of the previous round add one
new option '--names-only' to modify the output of '--list' and
'--get-regexp' options, as suggested in previous discussions.
* Reorganized the commit messages: don't go
write_pack_data() passes bundle_fd to start_command() to be used as
the stdout of pack-objects. But start_command() closes its stdout if
it is 1. This is a problem if bundle_fd is the fd of a lock_file,
because commit_lock_file() will also try to close the fd.
So the old code suppressed
main() is responsible for cleaning up the socket in the case of
errors, so it is reasonable to also make it responsible for cleaning
it up when there are no errors. This change also makes the next step
easier.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
credential-cache--daemon.c |
Hello Torsten,
Torsten Bögershausen, Sonntag, 9. August 2015 22:20:
On 2015-08-08 07.58, Torsten Bögershausen wrote:
On 2015-08-07 18.32, Benkstein, Frank wrote:
I am working working on Linux and am examining code in a git repository I do
not know much about. I am only looking at files, not
Recently Michael and I were working on a patch series (not yet
published), which did something like:
const char *path = git_path(foo);
... do stuff with path ...
for_each_ref(some_callback, NULL);
... do some other stuff ...
unlink(path);
Clever readers may have spotted the bug
The add_to_alternates_file function blindly uses
hold_lock_file_for_append to copy the existing contents, and
then adds the new line to it. This has two minor problems:
1. We might add duplicate entries, which are ugly and
inefficient.
2. We do not check that the file ends with a
The get_repo_path function calls mkpath() and then does some
non-trivial operations on it, like calling
is_git_directory() and read_gitfile(). These are actually
OK (they do not use more pathname static buffers
themselves), but it takes a fair bit of work to verify.
Let's use our own strbuf to
Assigning the result of git_path is a bad pattern, because
it's not immediately obvious how long you expect the content
to stay valid (and it may be overwritten by subsequent
calls). Let's use a function-local strbuf here instead,
which we know is safe (we just have to remember to free it
in all
Because it's not safe to store the static-buffer results of
git_path for a long time, we end up formatting the same
filename over and over. We can fix this by using a
function-local strbuf to store the formatted pathname and
avoid repeating ourselves.
Signed-off-by: Jeff King p...@peff.net
---
There are no callers of the slightly-dangerous static-buffer
git_path_submodule left. Let's drop it.
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 5 ++---
path.c | 10 --
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/cache.h b/cache.h
index 6f74f33..7a4fa90
Commit 1a83c24 (git_snpath(): retire and replace with
strbuf_git_path(), 2014-11-30) taught log_ref_setup and
log_ref_write_1 to take a strbuf parameter, rather than a
bare string. It then makes an alias to the strbuf's buf
field under the original name.
This made the original diff much shorter,
The find_hook function returns the results of git_path,
which is a static buffer shared by other path-related calls.
Returning such a buffer is slightly dangerous, because it
can be overwritten by seemingly unrelated functions.
Let's at least keep our _own_ static buffer, so you can
only get in
The first thing we do in this function is copy the input
into a strbuf. Of the 4 callers, 3 of them already have a
strbuf we could use. Let's just take the strbuf, and convert
the remaining caller to use a strbuf, rather than a raw
git_path. This is safer, anyway, as remove_dir_recursively
is a
One of the most common uses of git_path() is to pass a
constant, like git_path(MERGE_MSG). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
read-cache.c | 38 ++
1 file changed, 6 insertions(+), 32 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 96cb9a3..89be226 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -5,6 +5,7 @@
*/
This makes the next step easier.
The old code used to use path to set the initial length of
tempfile-filename. This was not helpful because path was usually
relative whereas the value stored to filename will be absolute. So
just initialize the length to 0.
Signed-off-by: Michael Haggerty
We are about to move those members, so change client code to read them
through accessor functions.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
credential-store.c | 2 +-
lockfile.c | 14 ++
lockfile.h | 3 +++
read-cache.c | 2 +-
refs.c
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/gc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 36fe333..c41354b 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -199,6 +199,7 @@ static const char
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/commit.c | 15 ---
config.c | 14 +++---
lockfile.c | 7 +++
lockfile.h | 6 ++
refs.c | 6 +++---
shallow.c| 6 +++---
6 files changed, 34 insertions(+), 20
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
shallow.c | 35 +++
1 file changed, 7 insertions(+), 28 deletions(-)
diff --git a/shallow.c b/shallow.c
index 7973e74..2ba29a5 100644
--- a/shallow.c
+++ b/shallow.c
@@ -1,4 +1,5 @@
#include cache.h
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/gc.c | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index c41354b..bfe589f 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -11,6 +11,7 @@
*/
#include
First beef up the sanity checking in get_locked_file_path() to match
that in commit_lock_file(). Then rewrite commit_lock_file() to use
get_locked_file_path() for its pathname computation.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 28
1
Add several functions for creating temporary files with
automatically-generated names, analogous to mkstemps(), but also
arranging for the files to be deleted on program exit.
The functions are named according to a pattern depending how they
operate. They will be used to replace many places in
Rearrange/rewrite it somewhat to fit its new environment.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-lockfile.txt | 220 ---
lockfile.c | 53 ++
lockfile.h | 290
A lot of work went into defining the state diagram for lockfiles and
ensuring correct, race-resistant cleanup in all circumstances.
Most of that infrastructure can be applied directly to *any* temporary
file. So extract a new tempfile module from the lockfile module.
Reimplement lockfile on top
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
diff.c | 29 +++--
1 file changed, 7 insertions(+), 22 deletions(-)
diff --git a/diff.c b/diff.c
index 7500c55..dc95247 100644
--- a/diff.c
+++ b/diff.c
@@ -2,6 +2,7 @@
* Copyright (C) 2005 Junio C Hamano
*/
Use the tempfile module to ensure that the socket file gets deleted on
program exit.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
credential-cache--daemon.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/credential-cache--daemon.c
I would find it useful to ask 'git stash pop' to always drop the stash after
applying it to the working tree, even if there were conflicts. (Only if there
was some hard error, such as an I/O error updating some of the files, should
the stash be left on the stack.)
Would a patch for such an
On Sun, 9 Aug 2015 14:13:33 -0400
Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Aug 5, 2015 at 3:17 AM, Jan Viktorin
vikto...@rehivetech.com wrote:
Do I understand well that you are complaining about too
narrow commmit message?
Yes, I'm a complainer. ;-) It's minor, though, not a
Apologies for the delay in reply! I tried your suggestion and it
works. Thanks! :)
I'm curious why integer comparison is throwing error. Shouldn't i be
comparing numbers with numeric operator?
On Mon, Aug 10, 2015 at 3:23 PM, Gaurav Chhabra
varuag.chha...@gmail.com wrote:
Apologies for the
On 08/10/2015 11:36 AM, Jeff King wrote:
Commit 1a83c24 (git_snpath(): retire and replace with
strbuf_git_path(), 2014-11-30) taught log_ref_setup and
log_ref_write_1 to take a strbuf parameter, rather than a
bare string. It then makes an alias to the strbuf's buf
field under the original
On Mon, Aug 10, 2015 at 11:46:06AM +0200, SZEDER Gábor wrote:
'git config' can only show values or name-value pairs, so if a shell
script needs the names of set config variables it has to run 'git config
--list' or '--get-regexp' and parse the output to separate config
variable names from
On Mon, Aug 10, 2015 at 11:46:07AM +0200, SZEDER Gábor wrote:
Use the new '--names-only' option added in the previous commit to list
config variable names reliably in both cases, without error-prone post
processing.
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
This looks like a pretty
On Mon, Aug 10, 2015 at 12:50:51PM +, Ed Avis wrote:
An alternative would be for git stash to always print the name of the stash
it is applying. Then you can drop it afterwards by name and be sure you got
the right one. Printing the name of the stash sounds like a reasonable
bit of
Jeff King peff at peff.net writes:
An alternative would be for git stash to always print the name of the stash
it is applying.
Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)
Yes, that's the one.
Or maybe it would be useful to actually show the stash subject,
That could
1 - 100 of 108 matches
Mail list logo
