On 06/19/2014 04:59 AM, Yue Lin Ho wrote:
Hi:
^_^
I did some test on the EOL behavior between official git and libgit2-based
software(TortoiseGit).
Then, I got that they have different EOL behavior.
The blob stored in repository is a text file with mixed EOLs.
Even set core.autocrlf = true, of
Hi,
I was about to send a patch like this series today, I am attaching it below.
-- >8 --
Subject: [PATCH] imap-send: use skip_prefix instead of using magic numbers
Signed-off-by: Tanay Abhra
---
imap-send.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/imap-send.c b
The to-do list command `squash` and its close relative `fixup` replay
the changes of a commit like `pick` but do not recreate the commit.
Instead they replace the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without c
Since `do_pick` might be executed in a sub-shell (a modified author
environment for instance), calling `die` in `do_pick` has no effect but
exiting the sub-shell with a failure exit status. Moreover, if `do_pick`
is called while a squash or fixup is happening, `die_with_patch` will
discard `$squash
Rewrite `squash` and `fixup` handling in `do_next` using the atomic
sequence
pick_one
commit
in order to test the correctness of a single `do_squash` or parametrized
`do_pick` and make the subsequent patch reimplementing `squash` in terms
of such a single function more readable.
Might be
The options passed to `do_pick` determine whether the picked commit will
be rewritten or not. If the commit gets rewritten, because the user
requested to edit the commit message for instance, let `pick_one` merely
apply the changes introduced by the commit and do not commit the
resulting tree yet.
`pick_one` and `pick_one_preserving_merges` are wrappers around
`cherry-pick` in `rebase --interactive`. They take the hash of a commit
and build a `cherry-pick` command line that
- respects the user-supplied merge options
- disables complaints about empty commits
- tries to fast-forward the re
When `rebase` is executed with `--root` but no `--onto` is specified,
`rebase` creates a sentinel commit which is replaced with the root
commit in three steps. This combination of options results never in a
fast-forward.
1. The sentinel commit is forced into the authorship of the root
commit.
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If one thinks of `pick`
entries as scheduled `cherry-pick` command lines, then `reword` becomes
an alias for the command line `cherry-pick --edit`. The porcelain
`rebase--interactive`
Hi,
This patch series is part of the undertaking to add command line options
to to-do list commands. The goal is to be able to write something
similar to
pick --reset-author --signoff a Some changes
pick b Some more changes
squash --no-edit c Ack
Hi:
^_^
I did some test on the EOL behavior between official git and libgit2-based
software(TortoiseGit).
Then, I got that they have different EOL behavior.
The blob stored in repository is a text file with mixed EOLs.
Even set core.autocrlf = true, official git checkout the file as it is(means
On Mon, Jun 16, 2014 at 11:17:46AM -0700, Junio C Hamano wrote:
> David Aguilar writes:
>
> > Hmm.. I guess what I could do is keep the old behavior (having gitk ignore
> > TMPDIR)
> > on Windows and only use the new code path on non-Windows.
>
> Or perhaps attempt to create, catch error and th
105b5d3fbb1c00bb0aeaf9d3e0fbe26a7b1993fc introduced a dependency
on mkdtemp, which is not available on Windows.
Use the original temporary directory behavior when mkdtemp fails.
This makes the code use mkdtemp when available and gracefully
fallback to the existing behavior when it is not available
Here is the fsck which is ok. Remember that if I do the clone to another file
server it works fine.
"c:\Program Files (x86)\Git\bin\git.exe" fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (774/774), done.
Checking connectivity: 5128, done.
One thing I noti
On Thu, Jun 19, 2014 at 12:11:43AM +, Dodge, Warren L wrote:
> Hi Brian
Hi. Please do keep the list in CC. Someone else may be able to help
you better than I.
> c:\Program Files (x86)\Git\bin\git.exe" --version
> git version 1.9.4.msysgit.0
>
> I also had 1.8.?? and it did the same thing s
On Wed, Jun 18, 2014 at 04:03:40PM -0700, warren.l.do...@tektronix.com wrote:
> git.exe clone --progress -v L:\GIT_REPOSITORY L:\warrend\fail
>
> Cloning into L:\warrend\fail
> Done.
> Fatal: unable to read "Long hash key"
> Warning: clone succeeded, but checkout failed.
> You can inspect wh
I'm still working on the struct object_id patches, and I had a style
question. In several places throughout the code, we do something like
this:
unsigned char a[20], b[20];
/* do some stuff with b */
hashcpy(a, b);
I could implement an oidcpy that does the same thing.
struct object_id
I have looked for an answer to the Error 128 Clone succeeded, but checkout
failed message we are getting on a clone command.
And there does not seem to be any that relates to our situation.
The repository is on a local file server system that is mounted to the pc as L:
If we clone the repositor
On 06/19/2014 12:27 AM, Ronnie Sahlberg wrote:
> It looks like we need to reorder two of the patches.
> This patch needs to be moved to later in the series and happen after
> the delete_ref conversion :
>
> refs.c: make delete_ref use a transaction
> refs.c: add an err argument to delete_ref_loose
Jeff King writes:
> You can use a strbuf to build up a string from parts, and
> then detach it. In the general case, you might use multiple
> strbuf_add* functions to do the building. However, in many
> cases, a single strbuf_addf is sufficient, and we end up
> with:
>
> struct strbuf buf = STR
On 18/06/14 21:08, Jeff King wrote:
> On Wed, Jun 18, 2014 at 08:52:46PM +0100, Ramsay Jones wrote:
>
[snip]
> Yeah, I noticed it while writing the patch but decided it wasn't worth
> the trouble to deal with (since after all, it's not advertised to any
> callers, the very thing that sparse is com
It looks like we need to reorder two of the patches.
This patch needs to be moved to later in the series and happen after
the delete_ref conversion :
refs.c: make delete_ref use a transaction
refs.c: add an err argument to delete_ref_loose
I will respin a v19 with these patches reordered.
Thank
fixed
Thanks
On Wed, Jun 18, 2014 at 2:00 PM, Michael Haggerty wrote:
> There is a typo in the commit log subject line:
>
> s/alwasy/always/
>
> Michael
>
> On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
>> Making errno when returning from remove_empty_directories() more
>> obviously meaningful
fixed in 19
On Wed, Jun 18, 2014 at 1:38 PM, Michael Haggerty wrote:
> On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
>> Making errno when returning from verify_lock() meaningful, which
>> should almost but not completely fix
>>
>> * a bug in "git fetch"'s s_update_ref, which trusts the result o
On Wed, Jun 18, 2014 at 2:08 PM, Michael Haggerty wrote:
> On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
>> Making errno from write_ref_sha1() meaningful, which should fix
>>
>> * a bug in "git checkout -b" where it prints strerror(errno)
>> despite errno possibly being zero or clobbered
>>
>>
Am 18.06.2014 19:33, schrieb Junio C Hamano:
> In the meantime, are Windows folks happy with the four topics queued
> on 'pu' so far? I would like to start moving them down to 'next'
> and to 'master' soonish.
>
> They consist of these individual patches:
>
> $ git shortlog ^master \
>
Junio C Hamano writes:
> Ronnie Sahlberg writes:
>
>> Add a field that describes what type of update this refers to. For now
>> the only type is UPDATE_SHA1 but we will soon add more types.
>>
>> Signed-off-by: Ronnie Sahlberg
>> ---
>> refs.c | 25 +
>> 1 file changed,
On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
> Making errno from write_ref_sha1() meaningful, which should fix
>
> * a bug in "git checkout -b" where it prints strerror(errno)
> despite errno possibly being zero or clobbered
>
> * a bug in "git fetch"'s s_update_ref, which trusts the result o
There is a typo in the commit log subject line:
s/alwasy/always/
Michael
On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
> Making errno when returning from remove_empty_directories() more
> obviously meaningful, which should provide some peace of mind for
> people auditing lock_ref_sha1_basic.
>
On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
> Add an err argument to delete_loose_ref so that we can pass a descriptive
> error string back to the caller. Pass the err argument from transaction
> commit to this function so that transaction users will have a nice error
> string if the transaction
On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
> Making errno when returning from verify_lock() meaningful, which
> should almost but not completely fix
>
> * a bug in "git fetch"'s s_update_ref, which trusts the result of an
>errno == ENOTDIR check to detect D/F conflicts
>
> ENOTDIR makes
Ronnie Sahlberg writes:
> Add a field that describes what type of update this refers to. For now
> the only type is UPDATE_SHA1 but we will soon add more types.
>
> Signed-off-by: Ronnie Sahlberg
> ---
> refs.c | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
When we get the author name and email either from an
existing commit or from the "--author" option, we create a
copy of the strings. We cannot just free() these copies,
since the same pointers may also be pointing to getenv()
storage which we do not own.
Instead, let's treat these the same way as
On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
> Making errno when returning from lock_file() meaningful, which should
> fix
>
> * an existing almost-bug in lock_ref_sha1_basic where it assumes
>errno==ENOENT is meaningful and could waste some work on retries
>
> * an existing bug in repack
Rather than parsing the header manually to find the "author"
field, and then parsing its sub-parts, let's use
find_commit_header and split_ident_line. This is shorter and
easier to read, and should do a more careful parsing job.
For example, the current parser could find the end-of-email
right-bra
Ronnie Sahlberg writes:
> Signed-off-by: Ronnie Sahlberg
> ---
> refs.c | 13 ++---
> refs.h | 7 ---
> 2 files changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index dfbf003..a9f91ab 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -3487,23 +3487,14 @@ int ref
Many of the date functions write into fixed-size buffers.
This is a minor pain, as we have to take special
precautions, and frequently end up copying the result into a
strbuf or heap-allocated buffer anyway (for which we
sometimes use strcpy!).
Let's instead teach parse_date, datestamp, etc to wri
When we parse an ident line, we end up with several fields,
each with a begin/end pointer into the buffer, like:
const char *name_begin;
const char *name_end;
There is nothing except the field names to indicate that
they are paired. This makes it annoying to write helper
functions for dealing
There's a typo in the subject line of this commit.
Michael
On 06/17/2014 05:53 PM, Ronnie Sahlberg wrote:
> Making errno when returning from lock_file() meaningful, which should
> fix
>
> * an existing almost-bug in lock_ref_sha1_basic where it assumes
>errno==ENOENT is meaningful and could
This saves us some manual parsing and makes the code more
readable.
Signed-off-by: Jeff King
---
I suspect there are other sites which could use this helper, too; I
didn't do an exhaustive search.
commit.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --gi
If we hit the end-of-header without finding an "author"
line, we just return from the function. We should jump to
the fail_exit path to clean up the buffer that we may have
allocated.
Signed-off-by: Jeff King
---
commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/commit
Usually when we parse a commit, we read it line by line and
handle each header in a single pass (e.g., in parse_commit
and parse_commit_header). Sometimes, however, we only care
about extracting a single header. Code in this situation is
stuck doing an ad-hoc parse of the commit buffer.
Let's pro
This is another function I ran across in today's cleanups. The memory
leak in it has bugged me for a while (even though it's really not a big
deal in practice). So this is mostly minor cleanups, but I did find a
bug in the commit parser.
[1/7]: commit: provide a function to find a header in a bu
The only way I have found so far to do this is to merge the branch on to a tmp
branch and then back!
The only other way I found seems real bad:
http://stackoverflow.com/questions/16473363/tell-git-blame-to-use-imported-histo
ry
And the way below does not work if there are edits already on master
On Wed, Jun 18, 2014 at 08:52:46PM +0100, Ramsay Jones wrote:
> In order to encapsulate the setting of the unique commit index, commit
> 969eba63 ("commit: push commit_index update into alloc_commit_node",
> 10-06-2014) introduced a (logically private) intermediary allocator
> function. However, t
You can use a strbuf to build up a string from parts, and
then detach it. In the general case, you might use multiple
strbuf_add* functions to do the building. However, in many
cases, a single strbuf_addf is sufficient, and we end up
with:
struct strbuf buf = STRBUF_INIT;
...
strbuf_addf(&bu
In many parts of the code, we do an ugly and error-prone
malloc like:
const char *fmt = "something %s";
buf = xmalloc(strlen(foo) + 10 + 1);
sprintf(buf, fmt, foo);
This makes the code brittle, and if we ever get the
allocation wrong, is a potential heap overflow. Let's
instead favor xstrdu
While working on the skip_prefix series, I ended up grepping for:
+ strlen("
to find spots in need of skip_prefix. Of course, it turns up many other
nasty ad-hoc calculations. Here's a short series that addresses a few.
There are many more, but hopefully the first patch provides a tool that
can
In some cases, we use starts_with to check for a prefix, and
then use an already-calculated prefix length to advance a
pointer past the prefix. There are no magic numbers or
duplicated strings here, but we can still make the code
simpler and more obvious by using skip_prefix.
Signed-off-by: Jeff K
After handling options, any leftover arguments should be
commands. However, we pass through "--help" and "--version",
so that we convert them into "git help" and "git version"
respectively.
This is a straightforward use of skip_prefix to avoid a
magic number, but while we are there, it is worth ad
There are several uses of the magic number "line+45" when
parsing ACK lines from the server, and it's rather unclear
why 45 is the correct number. We can make this more clear by
keeping a running pointer as we parse, using skip_prefix to
jump past the first "ACK ", then adding 40 to jump past
get_s
In order to encapsulate the setting of the unique commit index, commit
969eba63 ("commit: push commit_index update into alloc_commit_node",
10-06-2014) introduced a (logically private) intermediary allocator
function. However, this function (alloc_raw_commit_node()) was declared
as a public functio
When we see a file change in a commit, we expect one of:
1. A mark.
2. An "inline" keyword.
3. An object sha1.
The handling of spaces is inconsistent between the three
options. Option 1 calls a sub-function which checks for the
space, but doesn't parse past it. Option 2 parses the space,
As in earlier commits, the diff option parser uses
starts_with to find that an argument starts with "--stat-",
and then adds strlen("stat-") to find the rest of the
option.
However, in this case the starts_with and the strlen are
separated across functions, making it easy to call the
latter withou
Like earlier cases, we can use skip_prefix to avoid magic
numbers that must match the length of starts_with prefixes.
However, the numbers are a little more complicated here, as
we keep parsing past the prefix. We can solve it by keeping
a running pointer as we parse; its final value is the
locatio
Fast-import does a lot of parsing of commands and
dispatching to sub-functions. For example, given "option
foo", we might recognize "option " using starts_with, and
then hand it off to parse_option() to do the rest.
However, we do not let parse_option know that we have parsed
the first part alread
It's a common idiom to match a prefix and then skip past it
with strlen, like:
if (starts_with(foo, "bar"))
foo += strlen("bar");
This avoids magic numbers, but means we have to repeat the
string (and there is no compiler check that we didn't make a
typo in one of the strings).
We ca
It's a common idiom to match a prefix and then skip past it
with a magic number, like:
if (starts_with(foo, "bar"))
foo += 3;
This is easy to get wrong, since you have to count the
prefix string yourself, and there's no compiler check if the
string changes. We can use skip_prefix to
We detect the "import-marks" capability by looking for that
string, but _without_ a trailing space. Then we skip past it
using strlen("import-marks "), with a space. So if a remote
helper gives us exactly "import-marks", we will read past
the end-of-string by one character.
This is unlikely to be
Fast-import shares code between its command-line parser and
the "option" command. To do so, it strips the "--" from any
command-line options and passes them to the option parser.
However, it does not confirm that the option even begins
with "--" before blindly passing "arg + 2".
It does confirm th
A submodule diff generally has content like:
-Subproject commit [0-9a-f]{40}
+Subproject commit [0-9a-f]{40}
When we are using "git apply --index" with a submodule, we
first apply the textual diff, and then parse that result to
figure out the new sha1.
If the diff has bogus input like:
-S
The skip_prefix function returns a pointer to the content
past the prefix, or NULL if the prefix was not found. While
this is nice and simple, in practice it makes it hard to use
for two reasons:
1. When you want to conditionally skip or keep the string
as-is, you have to introduce a second
There's no point in using:
if (skip_prefix(buf, "foo"))
over
if (starts_with(buf, "foo"))
as the point of skip_prefix is to return a pointer to the
data after the prefix. Using starts_with is more readable,
and will make refactoring skip_prefix easier.
Signed-off-by: Jeff King
---
builti
This function originally took a whole config variable name
("var") and an offset ("ofs"). It checked "var+ofs" against
each color slot, but reported errors using the whole "var".
However, since 8b8e862 (ignore unknown color configuration,
2009-12-12), it returns -1 rather than printing its own
err
None of these strings is modified; marking them as const
will help later refactoring.
Signed-off-by: Jeff King
---
daemon.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/daemon.c b/daemon.c
index f9c63e9..18818c3 100644
--- a/daemon.c
+++ b/daemon.c
@@ -39,8
A while ago[1] we discussed refactoring skip_prefix (or adding something
like it) to make it more natural to call. This morning I decided to take
a look at doing this, and went down a rabbit hole of cleanups. This is
part one of the result.
The short of it is that skip_prefix can now be used like
Jeremiah Mahler wrote:
> Jeremiah Mahler (5):
> cache: rename cache_name_compare() to name_compare()
> tree-walk.c: remove name_compare() function
> unpack-trees.c: remove name_compare() function
> dir.c: rename to name_compare()
> name-hash.c: rename to name_compare()
>
> cache.h
Jeremiah Mahler wrote:
> The cache_name_compare() function is not specific to a cache.
> Make its name more general by renaming it to name_compare().
Sounds reasonable.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More maj
Jeremiah Mahler wrote:
> name-hash.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Same thoughts as patch 4/5.
--
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/majordom
Jeremiah Mahler wrote:
> This is a case where cache_name_compare() was used even though it had
> nothing to do with a cache. The new name makes it clear that no cache
> is involved.
That's a perfect sort of thing to put in the commit message. ;-)
Unlike patches 2 and 3, this could m
Jeremiah Mahler wrote:
> unpack-trees.c | 11 ---
> 1 file changed, 11 deletions(-)
Same thoughts as patch 2/5. :)
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 http://vger
Jeremiah Mahler wrote:
> Remove the duplicate name_compare() function and use the one provided by
> read-cache.c.
I'd squash this into patch 1/5.
> ---
> Notes:
> There is one small difference between the old function and the new one.
> The old one returned -N and +N whereas the new one
Rename the call to cache_name_compare() to name_compare().
Signed-off-by: Jeremiah Mahler
---
Notes:
This is a case where cache_name_compare() was used even though it had
nothing to do with a cache. The new name makes it clear that no cache
is involved.
dir.c | 3 +--
1 file chang
Remove the duplicate name_compare() function and use the one provided by
read-cache.c.
Signed-off-by: Jeremiah Mahler
---
Notes:
There is one small difference between the old function and the new one.
The old one returned -N and +N whereas the new one returns -1 and +1.
However, ther
Remove the duplicate name_compare() function and use the one provided by
read-cache.c.
Signed-off-by: Jeremiah Mahler
---
Notes:
There is one small difference between the old function and the new one.
The old one returned -N and +N whereas the new one returns -1 and +1.
However, ther
Rename the call to cache_name_compare() to name_compare().
Signed-off-by: Jeremiah Mahler
---
name-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/name-hash.c b/name-hash.c
index be7c4ae..e2bea88 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -179,7 +179,7 @@ static int
The cache_name_compare() function is not specific to a cache.
Make its name more general by renaming it to name_compare().
Simplify cache_name_stage_compare() via name_compare().
Where lengths are involved, change int to size_t.
Signed-off-by: Jeremiah Mahler
---
cache.h | 2 +-
read-cach
Version 3 of the patch series to cleanup duplicate name_compare()
functions (previously was 'add strnncmp() function' [1]).
This version goes in a slightly different direction than the previous
version. Before I was trying to add a strnncmp() function so I could
remove duplicate copies of the n
On Wed, Jun 18, 2014 at 10:51:04AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin wrote:
> >>
> >> OK, after looking into this for a while, I realize
> >> this is a special property of the Signed-off-by footer.
> >> For now I think
guangai@travelzen.com writes:
> I delete a file and push to master branch, after code reviewing
> in gerrit, then click 'Cherry Pick To' button to cherry-pick to
> release/1.1 branch, and then code review and merge...
Gerrit folks, for which this list may not be the best place to get
in
Junio C Hamano writes:
> On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin wrote:
>>
>> OK, after looking into this for a while, I realize
>> this is a special property of the Signed-off-by footer.
>> For now I think it's reasonable to just avoid de-duplicating
>> other footers if any. Agree?
Signed-off-by: Ronnie Sahlberg
---
refs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 89e5bc0..582591b 100644
--- a/refs.c
+++ b/refs.c
@@ -2548,8 +2548,10 @@ int repack_without_refs(const char **refnames, int n,
struct strbuf *err)
/* Rem
Karsten Blees writes:
> Right, it makes no sense for trace_performance(), and for
> trace_performance_since() only if followed by another 'measured' code
> section. In that special case, I think it wouldn't hurt if you had to
> write:
>
> uint64_t start = getnanotime();
> /* first code sectio
Stepan Kasal writes:
> Hello Karsten,
>
> On Tue, Jun 17, 2014 at 11:06:52AM +0200, Karsten Blees wrote:
>> Am 11.06.2014 11:37, schrieb Stepan Kasal:
>> > This is the second part of the time-proven unicode suport branch from
>> > msysgit.
>> > This batch is a collection of small independent cha
Followup on this, it looks like the local repository actually didn't contain
branch-2. So this doesn't appear to be an issue.
--
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/major
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Many topics that have been cooking in 'next' during the previous
cycle, totalling close to 300 individual patches, are in 'master'
now. We have
In many places in the code we do not have access to the individual fields
in the committer data. Instead we might only have access to prebaked data
such as what is returned by git_committer_info() containing a string
that consists of email, timestamp, zone etc.
This makes it inconvenient to use tr
Make the deletion of refs during a transaction more atomic.
Start by first copying all loose refs we will be deleting to the packed
refs file and then commit the packed refs file. Then re-lock the packed refs
file to avoid anyone else from modifying the refs we are to delete during
this transaction
These patches can also be found at:
https://github.com/rsahlberg/git/tree/ref-transactions-rename
This series is based on, and applies ontop of, the previous
ref-transactions-reflog series, also found at my githup repo.
This series updates the reflog handling and converts rename_ref to use a
singl
Change lock_ref_sha1_basic to return an error instead of dying when
we fail to lock a file during a transaction.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 11dcb07..a644e7c 100644
--- a/refs.c
+++ b/refs.c
@
Change refs.c to use a single transaction to copy/rename both the refs and
its reflog. Since we are no longer using rename() to move the reflog file
we no longer need to disallow rename_ref for refs with a symlink for its
reflog so we can remove that test from the testsuite.
Change the function to
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333
Update hold_lock_file_for_append and copy_fd to return a meaningful errno
on failure.
Signed-off-by: Ronnie Sahlberg
---
copy.c | 20 +---
lockfile.c | 7 ++-
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/copy.c b/copy.c
index a7f58fd..5cb8679 100644
--
Define a new transaction update type, UPDATE_LOG, and a new function
transaction_update_reflog. This function will lock the reflog and append
an entry to it during transaction commit.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 101
log_ref_setup is used to do several semi-related things :
* sometimes it will create a new reflog including missing parent directories
and cleaning up any conflicting stale directories in the path.
* fill in a filename buffer for the full path to the reflog.
* unconditionally re-adjust the permis
Allow to make multiple reflog updates to the same ref during a transaction.
This means we only need to lock the reflog once, during the first update
that touches the reflog, and that all further updates can just write the
reflog entry since the reflog is already locked.
This allows us to write cod
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.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 5 +++--
refs.h | 1 +
2 files changed, 4 insertions(
Rename the transaction functions. Remove the leading ref_ from the
names and append _sha1 to the names for functions that create/delete/
update sha1 refs.
Signed-off-by: Ronnie Sahlberg
---
branch.c | 11 ---
builtin/commit.c | 14 -
builtin/fetch.c| 12 ++
unlock|close|commit_ref can be made static since there are no more external
callers.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 24
refs.h | 9 -
2 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/refs.c b/refs.c
index 9653a01..ff98682 100644
---
Add a field that describes what type of update this refers to. For now
the only type is UPDATE_SHA1 but we will soon add more types.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 4e3d
1 - 100 of 125 matches
Mail list logo
