On Wed, Aug 27, 2014 at 12:41:57AM -0400, David Turner wrote:
> git mktree seems to allow the creation of a tree object with multiple
> objects of the same name but different SHAs.
Yeah, I don't think we do many quality checks there. Ditto for "git
hash-object".
The latter goes through index_mem
On Wed, Aug 27, 2014 at 11:41 AM, David Turner wrote:
> Summary: git mktree ought to forbid this, and possibly there ought to be
> other checks (for instance, when unpacking) to prevent this.
Does fsck detect this (because we ought to fix fsck first if it does not)?
--
Duy
--
To unsubscribe from
On Tue, Aug 26, 2014 at 02:54:11PM -0700, Junio C Hamano wrote:
> 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".
>
> We should pick one or the other and use it for both.
Yeah, I agree they should probably behave t
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
From: Ronnie Sahlberg
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 on failure instead o
From: Ronnie Sahlberg
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 is private to
refs.
From: Ronnie Sahlberg
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
stripped off be
From: Ronnie Sahlberg
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
Reviewed-by: Michael Haggerty
Signed
From: Ronnie Sahlberg
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
1 to -1 on fail
From: Ronnie Sahlberg
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
Reviewed-by: Michael Haggerty
Signed-off-by: Jonathan Nieder
---
refs.c | 7 +--
refs.h | 6 --
2 files changed,
From: Ronnie Sahlberg
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 returning from
the funct
From: Ronnie Sahlberg
Date: Mon, 28 Apr 2014 15:23:58 -0700
Signed-off-by: Ronnie Sahlberg
Reviewed-by: Michael Haggerty
Signed-off-by: Jonathan Nieder
---
fast-import.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/fast-import.c b/fast-imp
From: Ronnie Sahlberg
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 the lock file
"refs
From: Ronnie Sahlberg
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
Signed-off-by: Jonathan Nieder
---
refs.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
From: Ronnie Sahlberg
Date: Wed, 16 Apr 2014 16:21:13 -0700
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Jonathan Nieder
---
fast-import.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git
From: Ronnie Sahlberg
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 lock_any_ref_for_update/write_ref_sha1
did not protect
From: Ronnie Sahlberg
Date: Wed, 16 Apr 2014 15:37:45 -0700
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Jonathan Nieder
---
sequencer.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/seq
From: Ronnie Sahlberg
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
Signed-off-by: Jonathan Nieder
---
builtin/commit.c | 25 +++
From: Ronnie Sahlberg
Date: Wed, 16 Apr 2014 15:32:29 -0700
Update replace.c to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Jonathan Nieder
---
builtin/replace.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/repl
From: Ronnie Sahlberg
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
Signed-off-by: Jonath
From: Ronnie Sahlberg
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
Signed-off-by: Jonathan Nieder
---
builtin/tag.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/builtin/t
From: Ronnie Sahlberg
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 die() anyway, we may add
On Tue, Aug 26, 2014 at 6:24 AM, Jeff King 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 the alloc
From: Ronnie Sahlberg
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 return error but there w
From: Ronnie Sahlberg
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 return error but there w
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 shou
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
On Tue, Aug 26, 2014 at 2:38 PM, Junio C Hamano wrote:
> Ronnie Sahlberg 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,
>> +
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 st
On Tue, Aug 26, 2014 at 2:25 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> +struct ref_be {
>> + transaction_begin_fn transaction_begin;
>> + transaction_update_sha1_fn transaction_update_sha1;
>> + transaction_create_sha1_fn transaction_create_sha1;
>> + transaction_de
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:31 PM, Junio C Hamano wrote:
> Ronnie Sahlberg 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
Jeff King 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".
We sh
Ronnie Sahlberg 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,
> + files_transaction_create_s
Ronnie Sahlberg 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 back to the new re
Ronnie Sahlberg 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;
> + transaction_update
Jonathan Nieder 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
>
> 13
> Reviewed-by: Michael Haggerty
> Reviewed-by: Jonathan Niede
On Tue, Aug 26, 2014 at 10:18:48AM -0500, Robert Dailey wrote:
> On Tue, Aug 26, 2014 at 1:28 AM, Heiko Voigt 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 draft th
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 em
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 and
Jeff King 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 && *
Junio C Hamano 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)?
Nah, that wa
Jeff King writes:
> On Tue, Aug 26, 2014 at 09:54:19AM -0700, Junio C Hamano wrote:
>
>> Jeff King 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 a
Shawn Pearce writes:
> On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano wrote:
>> Shawn Pearce 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
>>>
Jeff King writes:
> On Mon, Aug 25, 2014 at 11:35:45AM -0700, Junio C Hamano wrote:
>
>> Steffen Prohaska 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 ind
Jeff King 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 "add_name_decor
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
> ---
> copy.c | 5 +
> lockfile.c | 3 +++
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/
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, &va
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 :
> Sometimes it's interesting to have a simple output that answers the question:
> Are there commits after the latest tag?
>
> One possible solution is to just print a "+"
On Mon, Aug 25, 2014 at 11:35:45AM -0700, Junio C Hamano wrote:
> Steffen Prohaska 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 non-seekable
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 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 regu
Jaime Soriano Pastor writes:
> On Tue, Aug 26, 2014 at 6:53 PM, Junio C Hamano 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
>> i
Jeff King 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 point. To do
On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano wrote:
> Shawn Pearce 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 per-repo.
>>
>> receive-pac
On Tue, Aug 26, 2014 at 10:24:35AM -0700, Junio C Hamano wrote:
> Jeff King 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" wit
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
---
This is a resend of an earlier patch [1] with an extended
recipient list.
[1]
http://article.gmane.org/gmane.comp.version-control.git/254815
po/de.
On Tue, Aug 26, 2014 at 09:54:19AM -0700, Junio C Hamano wrote:
> Jeff King 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 ??
Jeff King 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 6:53 PM, Junio C Hamano 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 pairwise merg
Steffen Prohaska 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, wait. The cal
Signed-off-by: Ralf Thielow
---
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
Members: Thomas Rast
Jan Krüger
Jeff King 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 ori
Jeff King 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 current
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 s
> 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 shou
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 ot
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 us
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 b
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.
The new function will be used to parse GIT_MMAP_LIMIT and
GIT_ALLOC_LIMIT.
Signed-off-by: Steffen Prohaska
---
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
@@ -1318,6 +1318,
The caller opened the fd, so it should be responsible for closing it.
Signed-off-by: Steffen Prohaska
---
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
+++ b/copy.c
@@ -10,7 +10,
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
---
convert.h | 5 ++---
sha1_file.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/con
On Tue, Aug 26, 2014 at 1:28 AM, Heiko Voigt 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 from y
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
> > someb
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 +
> -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
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 agre
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 optio
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
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 a
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 o
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
> > alignm
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`
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
On Mon, Aug 25, 2014 at 03:08:50PM -0700, Junio C Hamano wrote:
> Jonathan Nieder 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 Documen
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 str
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 be
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 com
On Mon, Aug 25, 2014 at 10:52 PM, Junio C Hamano wrote:
> On Mon, Aug 25, 2014 at 12:44 PM, Jeff King 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 :1:path" output?
>
> T
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 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 co
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 "b
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
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 more
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 one
On Mon, Aug 25, 2014 at 02:11:09PM -0700, Junio C Hamano wrote:
> Jeff King 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 t
> 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
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 shortcu
1 - 100 of 102 matches
Mail list logo
