Thanks for the detailed explanation Eric! That really helped clear my
doubts. Also tried with "0x" and it's working fine however, as
suggested by you, i will use '='
Thanks again! :)
On Tue, Aug 11, 2015 at 4:17 AM, Eric Sunshine wrote:
> On Mon, Aug 10, 2015 at 6:29 PM, Jacob Keller wrote:
>>
Using the new refs/worktree/ refs, make bisection per-worktree.
Signed-off-by: David Turner
---
Documentation/git-bisect.txt | 4 ++--
Documentation/rev-list-options.txt | 14 +++---
bisect.c | 2 +-
builtin/rev-parse.c| 6 --
revisi
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
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.
>
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 ob
On Tue, Aug 4, 2015 at 9:01 AM, Karthik Nayak 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 and helps in easier
On Tue, Aug 4, 2015 at 9:01 AM, Karthik Nayak 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: Karthik Nayak
--
On Tue, Aug 4, 2015 at 9:01 AM, Karthik Nayak 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 ref-filter APIs in further
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: bri
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Jeff King 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 me
On Mon, Aug 10, 2015 at 6:06 AM, Jan Viktorin wrote:
> On Sun, 9 Aug 2015 14:13:33 -0400
> Eric Sunshine 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 for the Perl search path to find the f
Junio C Hamano writes:
> Jeff King 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 --git a/submodule.c b/subm
Jeff King 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 majord...@vger.kernel.org
More m
On Mon, Aug 10, 2015 at 6:42 PM, David Turner wrote:
> On Mon, 2015-08-10 at 18:30 -0400, Eric Sunshine wrote:
>> On Mon, Aug 10, 2015 at 1:52 PM, David Turner
>> wrote:
>> > worktrees: add find_shared_symref
>>
>> s/worktrees/branch/ perhaps?
>
> Do you mean "this is in branch.c, so should be l
On Mon, Aug 10, 2015 at 6:29 PM, Jacob Keller wrote:
> On Mon, Aug 10, 2015 at 2:54 AM, Gaurav Chhabra
> 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
On Mon, 2015-08-10 at 18:30 -0400, Eric Sunshine wrote:
> On Mon, Aug 10, 2015 at 1:52 PM, David Turner
> 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 mostly about non
Jeff King 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 of Michael'
On Mon, Aug 10, 2015 at 1:52 PM, David Turner 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
> die_if_checked_out to use the sam
On Mon, Aug 10, 2015 at 2:54 AM, Gaurav Chhabra
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 doesn't treat hex numb
Michael Rappazzo 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, main-
'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
---
Documentation/git-worktree.txt | 6 +++-
builtin/worktree.c | 67 ++
t/t2027-work
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 |
On 2015-08-10 20.48, Junio C Hamano wrote:
> Torsten Bögershausen 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?
A
On Mon, Jun 15, 2015 at 2:48 PM, Junio C Hamano 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 differences in st
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
Adam Dinwoodie 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 things work is by a
Torsten Bögershausen 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 are changing
per...@pluto.rain.com (Perry Hutchison) writes:
>> ... we do not say "append 'refs/remotes//' for various
>> values of 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 is not fo
Torsten Bögershausen 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 called "w
Patrick Steinhardt 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 trailin
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.
Signed-off
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
---
builtin/notes.c | 6
t/t3320-notes-merge-worktrees.
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 b
On Mon, Aug 10, 2015 at 10:31:32AM -0700, Junio C Hamano wrote:
> Jeff King 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
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
---
This reroll addresses Eric Sunshine's comments on v5.
---
builtin/notes.
Jeff King 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
Jeff King 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 the callers a
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
SZEDER Gábor 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, such a parsing c
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
Cc: git@vger
On Fri, Aug 7, 2015 at 11:20 PM, Junio C Hamano wrote:
> Junio C Hamano 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", "preload-index" and
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"
> +
>
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/
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 nai
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 trail
From: Jeff King
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 some
character
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 test
From: Jeff King
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 a recen
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 name
Junio C Hamano 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 sta
Ed Avis 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" would be a p
Hello,
I've downloaded the Windows installer for Git, but can't seem to find hashes
published anywhere for verification. Since the downloaded file doesn't seem to
be signed, I'll need another way to verify it's integrity before running it on
my system.
Are hashes published somewhere that I'm m
>
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.
Jeff King peff.net> writes:
>I also wondered if the "dropped" message is
>sufficient
On Mon, Aug 10, 2015 at 01:43:07PM +, Ed Avis wrote:
> Jeff King 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.
>
> >
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
This looks like a pretty straight-forward
Jeff King 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 be
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 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 c
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
> Allocati
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
--
To unsubscri
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
>
On Mon, 10 Aug 2015 14:26:44 +0200
"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
>
On Mon, Aug 10, 2015 at 02:05:14PM +0200, Michael Haggerty wrote:
> I was wondering whether this memoization could interact badly with
> update_common_dir(). For example, if any of the memoized functions were
> called before git_common_dir is initialized, then the pre-git_common_dir
> value would
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
AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x41, St
On Mon, Aug 10, 2015 at 12:34:05PM +0200, Michael Haggerty wrote:
> How about taking this opportunity to name the parameters ("logfile" vs.
> "log_file") consistently?
Thanks, that's a good suggestion. Here's a re-roll of this patch:
-- >8 --
Subject: [PATCH] refs.c: simplify strbufs in reflog s
On 08/10/2015 11:27 AM, Jeff King wrote:
> [...] The problem is that git_path uses a static buffer that gets overwritten
> by subsequent calls. [...]
>
> [01/17]: cache.h: clarify documentation for git_path, et al
> [02/17]: cache.h: complete set of git_path_submodule helpers
> [03/17]: t570
On 08/10/2015 11:38 AM, Jeff King wrote:
> [...]
> This patch introduces a series of functions to "memoize"
> these strings, which are essentially globals for the
> lifetime of the program. We compute the value once, take
> ownership of the buffer, and return the cached value for
> subsequent calls
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 --alwa
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 origin
On Sun, 9 Aug 2015 14:13:33 -0400
Eric Sunshine wrote:
> On Wed, Aug 5, 2015 at 3:17 AM, Jan Viktorin
> 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 big deal, and
> certainly not worth a r
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
wrote:
> Apologies for the delay in reply! I tried your
Signed-off-by: Michael Haggerty
---
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 *lock_repo_for_gc(int force, pid_t*
Signed-off-by: Michael Haggerty
---
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 deletions(-)
diff --git
Signed-off-by: Michael Haggerty
---
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"
+#include "tempfile.h"
#i
Signed-off-by: Michael Haggerty
---
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 "builtin.h"
+#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
---
lockfile.c | 28
1 file changed, 12 insert
Rearrange/rewrite it somewhat to fit its new environment.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-lockfile.txt | 220 ---
lockfile.c | 53 ++
lockfile.h | 290
Signed-off-by: Michael Haggerty
---
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 @@
*/
#define NO_THE_INDEX_C
Allow an existing file to be registered with the tempfile-handling
infrastructure; in particular, arrange for it to be deleted on program
exit. This can be used if the temporary file has to be created in a
more complicated way than just open(). For example:
* If the file itself needs to be created
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
---
credential-store.c | 2 +-
lockfile.c | 14 ++
lockfile.h | 3 +++
read-cache.c | 2 +-
refs.c | 12 +++-
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 the
Use the tempfile module to ensure that the socket file gets deleted on
program exit.
Signed-off-by: Michael Haggerty
---
credential-cache--daemon.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/credential-cache--daemon.c b/credential-cache--daemo
Signed-off-by: Michael Haggerty
---
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
*/
#include "cache.h"
+#in
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 to
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 commit_l
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
---
credential-cache--daemon.c | 3 ++-
1 file changed
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 m
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 script
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 int
'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 value
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
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 sto
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 tr
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
---
refs.c | 21 +++
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 co
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 non
There are no callers of the slightly-dangerous static-buffer
git_path_submodule left. Let's drop it.
Signed-off-by: Jeff King
---
cache.h | 5 ++---
path.c | 10 --
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/cache.h b/cache.h
index 6f74f33..7a4fa90 100644
--- a/cac
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,
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
1 - 100 of 110 matches
Mail list logo
