On Mon, Aug 25, 2014 at 09:29:07AM -0500, Robert Dailey wrote:
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt hvo...@hvoigt.net wrote:
New --with--remote parameter for 'git submodule'
While having said all that about submodule settings I
Dear git community,
I encountered the following problem: When using the date formatting
option ISO (either by setting --date=iso or using format:%ci for the
committer date), the output is formatted like this:
2014-08-25 17:49:43 +0200
But according to ISO 8601, should be formatted like this
On 26 August 2014 02:44, Junio C Hamano gits...@pobox.com wrote:
Arjun Sreedharan arjun...@gmail.com writes:
Find and allocate the required amount instead of allocating extra
100 bytes
Signed-off-by: Arjun Sreedharan arjun...@gmail.com
---
Interesting. How much memory do we typically
Hi,
I'd like to add a list parameter to the `git remote` command.
We already have:
- `git remote add`
- `git remote rename`
- `git remote delete`
I often write `git remote list` before finaly using `git remote -v` but
it isn't intuitive.
I am proposing to add `git remote list` as a
I often write `git remote list` before finaly using `git remote -v` but
it isn't intuitive.
I am proposing to add `git remote list` as a shortcut for `git remote -v`
I suffer from the same problem. I think your proposal is a logical and
nice idea.
Philippe
--
To unsubscribe from this list:
On Mon, Aug 25, 2014 at 02:11:09PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Mon, Aug 25, 2014 at 11:26:39AM -0700, Junio C Hamano wrote:
Good digging, and I agree that it should use the FLEX_ARRAY for
consistency.
I can produce a patch, but I did not want to
We are already using the flex-array technique; let's
annotate it with our usual FLEX_ARRAY macro. Besides being
more readable, this is slightly more efficient on compilers
that understand flex-arrays.
Note that we need to bump the allocation in add_name_decoration,
which did not explicitly add
The log-tree code keeps a struct decoration hash to show
text decorations for each commit during log traversals. It
makes this available to other files by providing global
access to the hash. This can result in other code adding
entries that do not conform to what log-tree expects.
For example,
In the previous commit, we made add_name_decoration global
so that adders would not have to access the hash directly.
We now make the hash itself static so that callers _have_ to
add through our function, making sure that all additions go
through a single point. To do this, we have to add one
On Mon, Aug 25, 2014 at 02:36:02PM -0700, Junio C Hamano wrote:
I think you are right, and the patch is the right direction (assuming we
want to do this; I question whether there are enough elements in the
list for us to care about the size, and if there are, we are probably
better off
Hi everyone.
Normally if I am tracking a file in a Directory which satisfies one of my
.gitignore rules, I can just add them via git add foo, and I have no
issues.
For example, let me create a new repo. I create a directory lib
containing file foo.txt, and a Directory lib2 with a file bar.txt.
On 26/08/14 11:23, Jeff King wrote:
The log-tree code keeps a struct decoration hash to show
text decorations for each commit during log traversals. It
makes this available to other files by providing global
access to the hash. This can result in other code adding
entries that do not conform
On 26/08/14 12:03, Jeff King wrote:
[snip]
Yeah, reading my suggestion again, it should clearly be
alloc_flex_struct or something.
Here's a fully-converted sample spot, where I think there's a slight
benefit:
diff --git a/remote.c b/remote.c
index 3d6c86a..ba32d40 100644
---
On Mon, Aug 25, 2014 at 10:52 PM, Junio C Hamano gits...@pobox.com wrote:
On Mon, Aug 25, 2014 at 12:44 PM, Jeff King p...@peff.net wrote:
For my own curiosity, how do you get into this situation, and what does
it mean to have multiple stage#1 entries for the same path? What would
git cat-file
On Tue, Aug 26, 2014 at 12:57:21PM +0100, Ramsay Jones wrote:
+ ret = xcalloc(1, base + extra);
+ va_start(ap, fmt);
+ vsnprintf(ret + offset, extra, fmt, ap);
What is the relationship between 'base' and 'offset'?
Let me assume that base is always, depending on your compiler,
On Tue, Aug 26, 2014 at 12:48:24PM +0100, Ramsay Jones wrote:
We can fix this by making name_decoration's adding function
public. If all callers use it, then any changes to structi
s/structi/struct/
I blame vi finger-cruft.
initialization only need to happen in one place (and because
On Tue, Aug 26, 2014 at 02:08:35PM +0200, Jaime Soriano Pastor wrote:
That is how we natively (read: not with the funky virtual stuff
merge-recursive does) express a merge with multiple merge bases.
You also should be able to read this in the way how git merge invokes
merge strategies
On Mon, Aug 25, 2014 at 03:08:50PM -0700, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Wouldn't it be sufficient to start digging not from * but from
??*?
Gah, the * was supposed to be . in my examples (though it doesn't
hurt).
find ??* \( -name
On 26/08/14 13:14, Jeff King wrote:
On Tue, Aug 26, 2014 at 12:57:21PM +0100, Ramsay Jones wrote:
+ ret = xcalloc(1, base + extra);
+ va_start(ap, fmt);
+ vsnprintf(ret + offset, extra, fmt, ap);
What is the relationship between 'base' and 'offset'?
Let me assume that base is
On Tue, Aug 26, 2014 at 11:29:32AM +0200, Rémy Hubscher wrote:
I'd like to add a list parameter to the `git remote` command.
We already have:
- `git remote add`
- `git remote rename`
- `git remote delete`
I often write `git remote list` before finaly using `git remote -v` but
it
On Tue, Aug 26, 2014 at 01:37:44PM +0100, Ramsay Jones wrote:
On my 64-bit system using gcc, sizeof() returns 16; it has to pad the
whole thing to 64-bit alignment in case I put two of them in an array.
But offsetof(name) is 12, since the array of char does not need the same
alignment; it
On 26/08/14 13:43, Jeff King wrote:
On Tue, Aug 26, 2014 at 01:37:44PM +0100, Ramsay Jones wrote:
On my 64-bit system using gcc, sizeof() returns 16; it has to pad the
whole thing to 64-bit alignment in case I put two of them in an array.
But offsetof(name) is 12, since the array of char
On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:
I encountered the following problem: When using the date formatting option
ISO (either by setting --date=iso or using format:%ci for the committer
date), the output is formatted like this:
2014-08-25 17:49:43 +0200
But
Peff is right, I did not think of backwards compatibility issues. I
believe a new option like iso-strict as he suggested will do the trick
(and I'm probably not the only one to appreciate its implementation...).
Regards,
Oliver
Am 26.08.2014 um 15:06 schrieb Jeff King:
On Tue, Aug 26, 2014
PS: As far as I understand it, there is no optionality of the T as
an indicator for the start of the time part.
Am 26.08.2014 um 15:06 schrieb Jeff King:
On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:
I encountered the following problem: When using the date formatting option
On Tue, Aug 26, 2014 at 03:19:11PM +0200, Oliver Busch wrote:
PS: As far as I understand it, there is no optionality of the T as an
indicator for the start of the time part.
The standard says (and I am quoting from Wikipedia here, as I do not
have it myself):
4.3.2 NOTE: By mutual agreement
-Original Message-
From: Jeff King
Sent: Tuesday, August 26, 2014 9:33
On Tue, Aug 26, 2014 at 03:19:11PM +0200, Oliver Busch wrote:
PS: As far as I understand it, there is no optionality of
the T as an
indicator for the start of the time part.
The standard says (and I am
Fixes several problems:
* include config.mak.uname, config.mak.autogen and config.mak
in order to use settings for prefix and other such things;
* link xdiff/lib.a as it is a requirement for libgit.a;
* fix CFLAGS and EXTLIBS for Linux and Mac OS X.
---
contrib/svn-fe/Makefile | 47
On Tue, Aug 26, 2014 at 10:10:33AM -0400, Jason Pyeron wrote:
But I am not sure that omitted means can be replaced with a space.
And while you can define by mutual agreement as git defines the
format, so any consumers agree to it that is not necessarily
useful to
somebody who wants to
On Tue, Aug 26, 2014 at 1:28 AM, Heiko Voigt hvo...@hvoigt.net wrote:
Hi Heiko,
My last email response was in violation of your request to keep the
two topics separate, sorry about that. I started typing it this
weekend and completed the draft this morning, without having read this
response
The new function will be used to parse GIT_MMAP_LIMIT and
GIT_ALLOC_LIMIT.
Signed-off-by: Steffen Prohaska proha...@zib.de
---
cache.h | 1 +
config.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/cache.h b/cache.h
index fcb511d..b820b6a 100644
--- a/cache.h
+++ b/cache.h
The caller opened the fd, so it should be responsible for closing it.
Signed-off-by: Steffen Prohaska proha...@zib.de
---
copy.c | 5 +
lockfile.c | 3 +++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/copy.c b/copy.c
index a7f58fd..d0a1d82 100644
--- a/copy.c
+++
It is only the path that matters in the decision whether to filter or
not. Clarify this by making path the single argument of
would_convert_to_git().
Signed-off-by: Steffen Prohaska proha...@zib.de
---
convert.h | 5 ++---
sha1_file.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
Similar to testing expectations about malloc with GIT_ALLOC_LIMIT (see
commit d41489 and previous commit), it can be useful to test
expectations about mmap.
This introduces a new environment variable GIT_MMAP_LIMIT to limit the
largest allowed mmap length. xmmap() is modified to check the limit.
GIT_ALLOC_LIMIT limits xmalloc()'s size, which is of type size_t.
Better use git_env_ulong() to parse the environment variable, so that
the postfixes 'k', 'm', and 'g' can be used; and use size_t to store the
limit for consistency. The change to size_t has no direct practical
impact, because we
The data is streamed to the filter process anyway. Better avoid mapping
the file if possible. This is especially useful if a clean filter
reduces the size, for example if it computes a sha1 for binary data,
like git media. The file size that the previous implementation could
handle was limited
Changes since v5:
- Introduce and use git_env_ulong().
- Change copy_fd() to not close input fd, which simplified changes to convert.
- More detailed explanation why filter must be marked required in commit
message of 6/6.
- Style fixes.
Steffen Prohaska (6):
convert: drop arguments
Perhaps -v should have been the default all along. I do not use git
remote myself, so I don't know if -v is what most people use. But
changing the output of git remote now is probably a bad thing (I
expect some people may depend on parsing it to get the list of remotes;
they should probably
On Tue, Aug 26, 2014 at 06:19:20PM +0200, Philippe Vaucher wrote:
Perhaps -v should have been the default all along. I do not use git
remote myself, so I don't know if -v is what most people use. But
changing the output of git remote now is probably a bad thing (I
expect some people may
Jeff King p...@peff.net writes:
With natively do you mean some internal state that is never written
into the index? If this were the case then there wouldn't be any
problem with the restriction when reading the index file.
FWIW, that was my question on reading Junio's response, too.
The
Jeff King p...@peff.net writes:
Actually as you are not excluding CVS, RCS, etc., and using ??* as
the starting point will exclude .git, .hg, etc. at the top, I think
we can shorten it even further and say
find ??* -name Documentation -prune -o -name \*.h
or something.
I had
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/TEAMS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/po/TEAMS b/po/TEAMS
index 52c3d07..461cc14 100644
--- a/po/TEAMS
+++ b/po/TEAMS
@@ -15,6 +15,8 @@ Leader: Ralf Thielow
ralf.thie...@googlemail.com
Members:
Steffen Prohaska proha...@zib.de writes:
The caller opened the fd, so it should be responsible for closing it.
H, I am not sure what the benefit of such a dogmatism. This
function consumes all that is useful in the fd, and there is nothing
interesting that can be do further on it, no?
Ah,
On Tue, Aug 26, 2014 at 6:53 PM, Junio C Hamano gits...@pobox.com wrote:
Yes---that is what I meant by the virtual stuff. Unlike resolve
work by Daniel (around Sep 2005 $gmane/8088) that tried to use
multiple ancestors directly in a single merge, recursive limits
itself to repeated use of
Jeff King p...@peff.net writes:
... But we are left with three options:
1. Add git remote list with verbose output. This is bad because it
differs gratuitously from git remote.
2. Add git remote list with non-verbose output. This is good because
it means git remote is just a
On Tue, Aug 26, 2014 at 09:54:19AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Actually as you are not excluding CVS, RCS, etc., and using ??* as
the starting point will exclude .git, .hg, etc. at the top, I think
we can shorten it even further and say
find ??*
Translate 38 new messages came from git.pot update in fe05e19
(l10n: git.pot: v2.1.0 round 1 (38 new, 9 removed)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
This is a resend of an earlier patch [1] with an extended
recipient list.
[1]
On Tue, Aug 26, 2014 at 10:24:35AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... But we are left with three options:
1. Add git remote list with verbose output. This is bad because it
differs gratuitously from git remote.
2. Add git remote list with
On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
A stateless nonce could look like:
nonce = HMAC_SHA1( SHA1(site+path) + '.' + now, site_key )
where site_key is a private key known to the server. It doesn't have
to be
Jeff King p...@peff.net writes:
In the previous commit, we made add_name_decoration global
so that adders would not have to access the hash directly.
We now make the hash itself static so that callers _have_ to
add through our function, making sure that all additions go
through a single
Jaime Soriano Pastor jsorianopas...@gmail.com writes:
On Tue, Aug 26, 2014 at 6:53 PM, Junio C Hamano gits...@pobox.com wrote:
Yes---that is what I meant by the virtual stuff. Unlike resolve
work by Daniel (around Sep 2005 $gmane/8088) that tried to use
multiple ancestors directly in a
On Tue, Aug 26, 2014 at 10:40:10AM -0700, Junio C Hamano wrote:
I may have called it lookup_name_decoration() to match, though, if I
were doing this patch ;-)
Hmph. I called it get because that was the opposite of add to me,
and I was matching add_name_decoration. Of course, in the regular
On Mon, Aug 25, 2014 at 06:55:51PM +0200, Steffen Prohaska wrote:
It could be handled that way, but we would be back to the original problem
that 32-bit git fails for large files. The convert code path currently
assumes that all data is available in a single buffer at some point to apply
On Mon, Aug 25, 2014 at 11:35:45AM -0700, Junio C Hamano wrote:
Steffen Prohaska proha...@zib.de writes:
Couldn't we do that with an lseek (or even an mmap with offset 0)? That
obviously would not work for non-file inputs, but I think we address
that already in index_fd: we push
hi there!
just a ping here, these are my first patches to git.
any comment, feedback?
2014-08-23 14:13 GMT-03:00 Jonh Wendell jonh.wend...@gmail.com:
Sometimes it's interesting to have a simple output that answers the question:
Are there commits after the latest tag?
One possible solution is
On Tue, Aug 26, 2014 at 05:23:21PM +0200, Steffen Prohaska wrote:
+/*
+ * Use default if environment variable is unset or empty string.
+ */
+unsigned long git_env_ulong(const char *k, unsigned long val)
+{
+ const char *v = getenv(k);
+ if (v *v !git_parse_ulong(v, val))
+
On Tue, Aug 26, 2014 at 05:23:24PM +0200, Steffen Prohaska wrote:
The caller opened the fd, so it should be responsible for closing it.
Signed-off-by: Steffen Prohaska proha...@zib.de
---
copy.c | 5 +
lockfile.c | 3 +++
2 files changed, 4 insertions(+), 4 deletions(-)
diff
Jeff King p...@peff.net writes:
On Tue, Aug 26, 2014 at 10:40:10AM -0700, Junio C Hamano wrote:
I may have called it lookup_name_decoration() to match, though, if I
were doing this patch ;-)
Hmph. I called it get because that was the opposite of add to me,
and I was matching
Jeff King p...@peff.net writes:
On Mon, Aug 25, 2014 at 11:35:45AM -0700, Junio C Hamano wrote:
Steffen Prohaska proha...@zib.de writes:
Couldn't we do that with an lseek (or even an mmap with offset 0)? That
obviously would not work for non-file inputs, but I think we address
that
Shawn Pearce spea...@spearce.org writes:
On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
A stateless nonce could look like:
nonce = HMAC_SHA1( SHA1(site+path) + '.' + now, site_key )
where site_key is a private key known
Jeff King p...@peff.net writes:
On Tue, Aug 26, 2014 at 09:54:19AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Actually as you are not excluding CVS, RCS, etc., and using ??* as
the starting point will exclude .git, .hg, etc. at the top, I think
we can shorten it even
Junio C Hamano gits...@pobox.com writes:
That is unfortunate. Would it be a major surgery to update the
protocol not to do that, perhaps by moving the command list from 3
to 2 (the latter of which is not currently doing anything useful
payload-wise, other than flushing a HTTP request early)?
Jeff King p...@peff.net writes:
On Tue, Aug 26, 2014 at 05:23:21PM +0200, Steffen Prohaska wrote:
+/*
+ * Use default if environment variable is unset or empty string.
+ */
+unsigned long git_env_ulong(const char *k, unsigned long val)
+{
+const char *v = getenv(k);
+if (v *v
On 08/26/2014 02:44 PM, Maxim Bublis wrote:
Fixes several problems:
* include config.mak.uname, config.mak.autogen and config.mak
in order to use settings for prefix and other such things;
* link xdiff/lib.a as it is a requirement for libgit.a;
* fix CFLAGS and EXTLIBS for Linux
On Tue, Aug 26, 2014 at 01:20:53PM -0700, Junio C Hamano wrote:
I think different people have different confusion criteria.
To me, these two are very different operations:
$ VAR=
$ unset VAR
I think it boils down to that I see that the distance between unset
vs set to empty is
On Tue, Aug 26, 2014 at 10:18:48AM -0500, Robert Dailey wrote:
On Tue, Aug 26, 2014 at 1:28 AM, Heiko Voigt hvo...@hvoigt.net wrote:
My last email response was in violation of your request to keep the
two topics separate, sorry about that. I started typing it this
weekend and completed the
Jonathan Nieder jrnie...@gmail.com writes:
https://code-review.googlesource.com/#/q/topic:ref-transaction-1
Outcome of the experiment: patches gained some minor changes and then
1-12
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
13
Reviewed-by: Michael Haggerty
Ronnie Sahlberg sahlb...@google.com writes:
+struct ref_be {
+ transaction_begin_fn transaction_begin;
+ transaction_update_sha1_fn transaction_update_sha1;
+ transaction_create_sha1_fn transaction_create_sha1;
+ transaction_delete_sha1_fn transaction_delete_sha1;
+
Ronnie Sahlberg sahlb...@google.com writes:
Create a new erfs.c file that will be used to hold all the refs
code that is backend agnostic and will be shared across all backends.
The reason we renamed everything to refs-be-files.c in the previous patch
and now start moving the common code
Ronnie Sahlberg sahlb...@google.com writes:
diff --git a/refs-be-files.c b/refs-be-files.c
index e58a7e1..27eafd0 100644
--- a/refs-be-files.c
+++ b/refs-be-files.c
...
+struct ref_be refs_files = {
+ files_transaction_begin,
+ files_transaction_update_sha1,
+
Jeff King p...@peff.net writes:
If it is truly some people prefer it one way and some the other, I am
not sure if we should leave it as-is (that is preferring one way).
A worse position is to have git_env_bool() that says empty is
false and add a new git_env_ulong() that says empty is unset.
On Tue, Aug 26, 2014 at 2:31 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Create a new erfs.c file that will be used to hold all the refs
code that is backend agnostic and will be shared across all backends.
The reason we renamed everything to
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The 'maint' branch now is for the 2.1.x maintenance track, and a few
fixes for recent regressions have been merged to 'maint' and 'master'.
The
On Tue, Aug 26, 2014 at 2:25 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
+struct ref_be {
+ transaction_begin_fn transaction_begin;
+ transaction_update_sha1_fn transaction_update_sha1;
+ transaction_create_sha1_fn
Hi again,
Junio C Hamano wrote:
It seems that I can hold the topic in 'pu' a bit longer and expect a
reroll from this effort before merging it to 'next'?
Sorry for the delay. The following changes on top of master
(refs.c: change ref_transaction_update() to do error checking and
return
On Tue, Aug 26, 2014 at 2:38 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
diff --git a/refs-be-files.c b/refs-be-files.c
index e58a7e1..27eafd0 100644
--- a/refs-be-files.c
+++ b/refs-be-files.c
...
+struct ref_be refs_files = {
+
Use libcurl's high-level API functions to implement git-imap-send
instead of the previous low-level OpenSSL-based functions.
Since version 7.30.0, libcurl's API has been able to communicate with
IMAP servers. Using those high-level functions instead of the current
ones would reduce imap-send.c by
Jonathan Nieder wrote:
This series teaches the tag, replace, commit, cherry-pick,
fast-import, checkout -b, branch, receive-pack, and http-fetch
commands and all update_ref and delete_ref callers to use the ref
transaction API instead of lock_ref_sha1.
The main user-visible change should be
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 16 Apr 2014 15:27:45 -0700
Change ref_transaction_delete() to do basic error checking and return
non-zero of error. Update all callers to check the return for
ref_transaction_delete(). There are currently no conditions in _delete that
will
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 16 Apr 2014 15:26:44 -0700
Do basic error checking in ref_transaction_create() and make it return
non-zero on error. Update all callers to check the result of
ref_transaction_create(). There are currently no conditions in _create that
will
On Tue, Aug 26, 2014 at 6:24 AM, Jeff King p...@peff.net wrote:
We are already using the flex-array technique; let's
annotate it with our usual FLEX_ARRAY macro. Besides being
more readable, this is slightly more efficient on compilers
that understand flex-arrays.
Note that we need to bump
From: Ronnie Sahlberg sahlb...@google.com
Date: Mon, 19 May 2014 10:42:34 -0700
Add an err argument to _begin so that on non-fatal failures in future ref
backends we can report a nice error back to the caller.
While _begin can currently never fail for other reasons than OOM, in which
case we
From: Ronnie Sahlberg sahlb...@google.com
Date: Tue, 29 Apr 2014 12:06:19 -0700
Track the state of a transaction in a new state field. Check the field for
sanity, i.e. that state must be OPEN when _commit/_create/_delete or
_update is called or else die(BUG:...)
Signed-off-by: Ronnie Sahlberg
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 16 Apr 2014 15:30:41 -0700
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/tag.c | 16 ++--
1 file changed,
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 16 Apr 2014 15:32:29 -0700
Update replace.c to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/replace.c | 14 --
1 file changed, 8
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 16 Apr 2014 15:34:19 -0700
Change commit.c to use ref transactions for all ref updates.
Make sure we pass a NULL pointer to ref_transaction_update if have_old
is false.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 16 Apr 2014 15:37:45 -0700
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
sequencer.c | 26 ++
1 file
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 16 Apr 2014 16:21:53 -0700
Change create_branch to use a ref transaction when creating the new branch.
This also fixes a race condition in the old code where two concurrent
create_branch could race since the
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 16 Apr 2014 16:21:13 -0700
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
fast-import.c | 25 +++--
1
From: Ronnie Sahlberg sahlb...@google.com
Date: Thu, 24 Apr 2014 16:36:55 -0700
Change the update_ref helper function to use a ref transaction internally.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 29
From: Ronnie Sahlberg sahlb...@google.com
Date: Mon, 28 Apr 2014 14:36:15 -0700
Wrap all the ref updates inside a transaction.
In the new API there is no distinction between failure to lock and
failure to write a ref. Both can be permanent (e.g., a ref
refs/heads/topic is blocking creation of
From: Ronnie Sahlberg sahlb...@google.com
Date: Mon, 28 Apr 2014 15:23:58 -0700
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
fast-import.c | 29 +++--
1 file
From: Ronnie Sahlberg sahlb...@google.com
Date: Mon, 28 Apr 2014 15:38:47 -0700
No external callers reference lock_ref_sha1 any more so let's declare it
static.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Jonathan Nieder
From: Ronnie Sahlberg sahlb...@google.com
Date: Thu, 17 Apr 2014 11:31:06 -0700
Switch to using ref transactions in walker_fetch(). As part of the refactoring
to use ref transactions we also fix a potential memory leak where in the
original code if write_ref_sha1() would fail we would end up
From: Ronnie Sahlberg sahlb...@google.com
Date: Tue, 29 Apr 2014 13:42:07 -0700
Since we only call update_ref_write from a single place and we only call it
with onerr==QUIET_ON_ERR we can just as well get rid of it and just call
write_ref_sha1 directly. This changes the return status for _commit
From: Ronnie Sahlberg sahlb...@google.com
Date: Tue, 29 Apr 2014 12:14:47 -0700
Since we now only call update_ref_lock with onerr==QUIET_ON_ERR we no longer
need this function and can replace it with just calling lock_any_ref_for_update
directly.
Signed-off-by: Ronnie Sahlberg
From: Ronnie Sahlberg sahlb...@google.com
Date: Tue, 29 Apr 2014 15:45:52 -0700
lock_ref_sha1 was only called from one place in refs.c and only provided
a check that the refname was sane before adding back the initial refs/
part of the ref path name, the initial refs/ that this caller had already
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 30 Apr 2014 09:03:36 -0700
Change prune_ref to delete the ref using a ref transaction. To do this we also
need to add a new flag REF_ISPRUNING that will tell the transaction that we
do not want to delete this ref from the packed refs. This flag
From: Ronnie Sahlberg sahlb...@google.com
Date: Wed, 30 Apr 2014 09:22:45 -0700
Change delete_ref to use a ref transaction for the deletion. At the same time
since we no longer have any callers of repack_without_ref we can now delete
this function.
Change delete_ref to return 0 on success and 1
git mktree seems to allow the creation of a tree object with multiple
objects of the same name but different SHAs. This leads to weird
behavior later, unsurprisingly. For instance, if there are two tree
objects with the same name but different SHAs, the checked out tree will
be the union of them
1 - 100 of 102 matches
Mail list logo
