On Fri, Jul 25, 2014 at 11:12 PM, Ronnie Sahlberg wrote:
>> diff --git a/refs.c b/refs.c
>> index bec2bb1..2769f20 100644
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -1533,6 +1533,105 @@ static int handle_missing_loose_ref(const char
>> *refname,
>> }
>> }
>>
>> +int parse_ref(const char *path
David Besen wrote:
> Jonathan Nieder wrote:
>> This is how pull --rebase works. It turns your single-parent commits
>> into a sequence of patches on top of upstream and completely ignores
>> your merge commits.
>>
>> There is a --rebase=preserve option that makes a halfhearted attempt
>> to prese
Ah thanks, I'll RTFM better in the future.
- Dave
-Original Message-
From: Jonathan Nieder [mailto:jrnie...@gmail.com]
Sent: Friday, July 25, 2014 4:19 PM
To: Besen, David
Cc: git@vger.kernel.org
Subject: Re: Amending merge commits?
Besen, David wrote:
> I think one of my coworkers has
Besen, David wrote:
> I think one of my coworkers has stumbled on a git bug -- if you
> amend a merge commit, and then pull, your amends are lost.
This is how pull --rebase works. It turns your single-parent commits
into a sequence of patches on top of upstream and completely ignores
your merge
Besen, David hp.com> writes:
>
>
> Hi folks,
>
> I think one of my coworkers has stumbled on a git bug -- if you amend a
merge commit, and then pull, your amends
> are lost.
>
> Is this expected behavior?
>
> I've reproduced the problem in a script (attached). I ran it against a
couple of
Junio C Hamano writes:
> "Philip Oakley" writes:
>
>>> which still makes me feel hesitant to promote this
>>> document without updating its contents, though.
>>>
>>
>> I hadn't viewed it as a 'promotion', rather it was simply ensuring
>> access to the guide via the help system, instead of leavin
Hi folks,
I think one of my coworkers has stumbled on a git bug -- if you amend a merge
commit, and then pull, your amends are lost.
Is this expected behavior?
I've reproduced the problem in a script (attached). I ran it against a couple
of versions of git (1.7.1, 1.7.9, 1.8.4, 2.0.0) and in
Ronnie Sahlberg wrote:
> Change refs.c to use a single transaction to copy/rename both the refs and
> its reflog.
Yay!
> 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
Ronnie Sahlberg wrote:
> 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 stop anyone else from modifying these refs and kee
Ronnie Sahlberg wrote:
> --- a/refs.c
> +++ b/refs.c
> @@ -2214,7 +2214,7 @@ static struct ref_lock *lock_ref_sha1_basic(const char
> *refname,
>*/
> goto retry;
> else
> - unable_to_lock_index_die(ref_file, errno);
>
Matthieu Moy writes:
> +static const char *implicit_ident_advice() {
Style:
static const char *implicit_ident_advice(void)
{
No need to resend.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
Ronnie Sahlberg wrote:
> Add a new flag REFLOG_EMAIL_IS_COMMITTER to _update_reflog to tell it
> that what we pass in as email is already the fully baked committer string
> we can use as-is.
With and without the new flag, the 'email' argument has two different
meanings:
* with the new flag, it
Thanks; will queue the patches from this iteration.
--
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
The caller can signal that it is not interested in learning
the location of $HOME/.gitconfig by passing global=NULL, but
there is no way to decline the path to the configuration
file based on $XDG_CONFIG_HOME.
Allow the caller to pass xdg=NULL to signal that it is not
interested in the XDG locatio
When the user has no ~/.gitconfig file, git config --global --edit used
to launch an editor on an nonexistant file name.
Instead, create a file with a default content before launching the
editor. The template contains only commented-out entries, to save a few
keystrokes for the user. If the values
When the user has no user-wide configuration file, it's faster to use the
newly introduced config file template than to run two commands to set
user.name and user.email. Advise this to the user.
The old advice is kept if the user already has a configuration file since
the template feature would no
Matthieu Moy writes:
> This allows a caller to request the global config file without requesting
> the XDG one.
>
> Signed-off-by: Matthieu Moy
> ---
Will rephrase
A caller can ask only for XDG location by passing global=NULL.
Allow it to ask only for the $HOME/.gitconfig by passing
Matthieu Moy writes:
> When the user has no ~/.gitconfig file, git config --global --edit used
> to launch an editor on an nonexistant file name.
>
> Instead, create a file with a default content before launching the
> editor. The template contains only commented-out entries, to save a few
> keys
Matthieu Moy writes:
>>> I'd just replace "list" with "array" and use
>>> Documentation/technical/api-allocation-growing.txt.
>>>
>>> But I can't think of a better way.
>>
>> Presumably this array will reflect the order the source file told us
>> about the keys and their values; I wonder if the
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> This allows a caller to requst the global config file without requesting
>> the XDG one.
>>
>> Signed-off-by: Matthieu Moy
>> ---
>> This is actually not needed, but I wrote this for a previous version,
>> and it seems sensible anyway.
>
> I wa
Matthieu Moy writes:
> This allows a caller to requst the global config file without requesting
> the XDG one.
>
> Signed-off-by: Matthieu Moy
> ---
> This is actually not needed, but I wrote this for a previous version,
> and it seems sensible anyway.
I was about to say "Let's not do this unti
When the user has no ~/.gitconfig file, git config --global --edit used
to launch an editor on an nonexistant file name.
Instead, create a file with a default content before launching the
editor. The template contains only commented-out entries, to save a few
keystrokes for the user. If the values
This allows a caller to request the global config file without requesting
the XDG one.
Signed-off-by: Matthieu Moy
---
path.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/path.c b/path.c
index 3afcdb4..f68df0c 100644
--- a/path.c
+++ b/path.c
@@ -148,10 +148,12
When the user has no user-wide configuration file, it's faster to use the
newly introduced config file template than to run two commands to set
user.name and user.email. Advise this to the user.
The old advice is kept if the user already has a configuration file since
the template feature would no
Matthieu Moy writes:
> Eric Sunshine writes:
>
>>> +static char *default_user_config()
>>> +{
>>> + struct strbuf buf = STRBUF_INIT;
>>> + strbuf_addf(&buf,
>>> + _("# This is Git's user-wide configuration file.\n"
>>> + "[core]\n"
>>> +
Transactions now use packed refs when deleting multiple refs so there is no
need to do it manually from remote.c any more.
Signed-off-by: Ronnie Sahlberg
---
builtin/remote.c | 70 +++-
1 file changed, 39 insertions(+), 31 deletions(-)
diff --
We no longer need to expose the lock/add/commit/rollback functions
for packed refs anymore so make them static and remove them from the
public api.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 8
refs.h | 30 --
2 files changed, 4 insertions(+), 34 deletions(
When we are updating more than one single ref, i.e. not a commit, then
write the updated refs directly to the packed refs file instead of writing
them as loose refs.
Change clone to use a transaction instead of using the packed refs API.
This changes the behavior of clone slightly. Previously clon
This is a small patch series that continues ontop of the
ref-transactions-rename series I posted earlier today.
This series expands the use of the packed refs file to make multi-ref
updates much more atomic. Additionally it allows us to continue pushing
external caller to use transactions instead
write_ref_sha1 tries to update the reflog while updating the ref.
Move these reflog changes out into its own function so that we can do the
same thing if we write a sha1 ref differently, for example by writing a ref
to the packed refs file instead.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 62
Signed-off-by: Ronnie Sahlberg
---
refs.c | 2 +-
refs.h | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index efa4f0d..5696d18 100644
--- a/refs.c
+++ b/refs.c
@@ -2534,7 +2534,7 @@ static int curate_packed_ref_fn(struct ref_entry *entry,
void *cb_data)
/
Junio C Hamano writes:
> Probably a good idea; I do not think of any possible interactions we
> have to worry about with the configuration file init-db creates with
> possible templating.
The feature should trigger only for --global, so it shouldn't interfer
with .git/config and templates.
> Do
On Fri, Jul 25, 2014 at 12:01 PM, Matthieu Moy
wrote:
> Eric Sunshine writes:
>
>>> +static char *default_user_config()
>>> +{
>>> + struct strbuf buf = STRBUF_INIT;
>>> + strbuf_addf(&buf,
>>> + _("# This is Git's user-wide configuration file.\n"
>>> +
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Tanay Abhra writes:
>>
>>> On 7/25/2014 2:52 AM, Ramsay Jones wrote:
However, I think it you could create a list of >>> entry, string-list index> pairs in the config_set and use that to do
the iteration. A bit ugly, but it should work
Matthieu Moy writes:
> When the user has no ~/.gitconfig file, git config --global --edit used
> to launch an editor on an nonexistant file name.
>
> Instead, create a file with a default content before launching the
> editor. The template contains only commented-out entries, to save a few
> keys
Tanay Abhra writes:
> On 7/25/2014 7:33 PM, Matthieu Moy wrote:
>> Tanay Abhra writes:
>>
>>> --- a/config.c
>>> +++ b/config.c
>>> @@ -1403,11 +1403,12 @@ const struct string_list
>>> *git_configset_get_value_multi(struct config_set *cs, c
>>>
>>> int git_configset_get_string_const(struct
Matthieu Moy writes:
> Tanay Abhra writes:
>
>> On 7/25/2014 2:52 AM, Ramsay Jones wrote:
>>> However, I think it you could create a list of >> entry, string-list index> pairs in the config_set and use that to do
>>> the iteration. A bit ugly, but it should work.
>>
>> Thanks for the advice, tha
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 stop anyone else from modifying these refs and keep it locked until
we are finishe
This patch series adds support for using transactions and atomic renames.
It focuses on what needs to be done in order to support fully atomic
and rollbackable renames that may or may not involve name conflicts.
By performing the actual delete old/create new via a single operation to
the packed re
Signed-off-by: Ronnie Sahlberg
---
refs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index a5053bf..619725a 100644
--- a/refs.c
+++ b/refs.c
@@ -2570,8 +2570,10 @@ int repack_without_refs(const char **refnames, int n,
struct strbuf *err)
/* Rem
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 6c55032..2ea85a8 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
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
Nice.
On Fri, Jul 25, 2014 at 3:43 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> cache.h | 11
> refs.c | 204
> ++--
> 2 files changed, 120 insertions(+), 95 deletions(-)
>
> diff --git a/cache.
Eric Sunshine writes:
>> +static char *default_user_config()
>> +{
>> + struct strbuf buf = STRBUF_INIT;
>> + strbuf_addf(&buf,
>> + _("# This is Git's user-wide configuration file.\n"
>> + "[core]\n"
>> + "# Please, adapt and
On Fri, Jul 25, 2014 at 6:43 AM, Nguyễn Thái Ngọc Duy wrote:
> In the beginning, we had resolve_ref() that returns a buffer owned by
> this function. Then we started to move away from that direction because
> the buffer could be overwritten by the next resolve_ref() call and
> introduced two new f
On Fri, Jul 25, 2014 at 9:44 AM, Matthieu Moy wrote:
> commit: advertize config --global --edit on guessed identity
s/advertize/advertise/
> When the user has no user-wide configuration file, it's faster to use the
> newly introduced config file template than to run two commands to set
> user.na
On Fri, Jul 25, 2014 at 6:43 AM, Nguyễn Thái Ngọc Duy wrote:
> This function is used to replaced some code in the next patch that
s/replaced/replace/
> does this (i.e. keep the errno when read() fails)
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> strbuf.c | 7 +--
> 1 file changed, 5 in
On Fri, Jul 25, 2014 at 9:44 AM, Matthieu Moy wrote:
> When the user has no ~/.gitconfig file, git config --global --edit used
> to launch an editor on an nonexistant file name.
>
> Instead, create a file with a default content before launching the
> editor. The template contains only commented-ou
On 7/25/2014 7:33 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> --- a/config.c
>> +++ b/config.c
>> @@ -1403,11 +1403,12 @@ const struct string_list
>> *git_configset_get_value_multi(struct config_set *cs, c
>>
>> int git_configset_get_string_const(struct config_set *cs, const char *ke
On 7/25/2014 7:28 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> +struct config_set_element {
>> +struct hashmap_entry ent;
>> +char *key;
>> +struct string_list value_list;
>> +};
>> +
>> +struct configset_list_item {
>> +struct config_set_element *e;
>> +int value_inde
Tanay Abhra writes:
> --- a/config.c
> +++ b/config.c
> @@ -1403,11 +1403,12 @@ const struct string_list
> *git_configset_get_value_multi(struct config_set *cs, c
>
> int git_configset_get_string_const(struct config_set *cs, const char *key,
> const char **dest)
> {
> - const char *valu
Tanay Abhra writes:
> +struct config_set_element {
> + struct hashmap_entry ent;
> + char *key;
> + struct string_list value_list;
> +};
> +
> +struct configset_list_item {
> + struct config_set_element *e;
> + int value_index;
> +};
I originally wondered why you had two leve
On 7/25/2014 7:14 PM, Matthieu Moy wrote:
> This allows a caller to requst the global config file without requesting
nit s/requst/request/
--
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.kern
This allows a caller to requst the global config file without requesting
the XDG one.
Signed-off-by: Matthieu Moy
---
This is actually not needed, but I wrote this for a previous version,
and it seems sensible anyway.
path.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff
When the user has no user-wide configuration file, it's faster to use the
newly introduced config file template than to run two commands to set
user.name and user.email. Advise this to the user.
The old advice is kept if the user already has a configuration file since
the template feature would no
When the user has no ~/.gitconfig file, git config --global --edit used
to launch an editor on an nonexistant file name.
Instead, create a file with a default content before launching the
editor. The template contains only commented-out entries, to save a few
keystrokes for the user. If the values
Add `git_die_config` that dies printing the line number and the file name
of the highest priority value for the configuration variable `key`.
It has usage in non-callback based config value retrieval where we can
raise an error and die if there is a semantic error.
For example,
if (!git_c
Add tests for `git_config_get_string()`, check whether it
dies printing the line number and the file name if a NULL
value is retrieved for the given key.
Signed-off-by: Tanay Abhra
---
t/t1308-config-set.sh | 9 +
test-config.c | 10 ++
2 files changed, 19 insertions(+)
Semantic errors (for example, for alias.* variables NULL values are
not allowed) in configuration files cause a die printing the line
number and file name of the offending value.
Add a test documenting that such errors cause a die printing the
accurate line number and file name.
Signed-off-by: Ta
Of all the functions in `git_config*()` family, `git_config()` has the
most invocations in the whole code base. Each `git_config()` invocation
causes config file rereads which can be avoided using the config-set API.
Use the config-set API to rewrite `git_config()` to use the config caching
layer
Store file name and line number for each key-value pair in the cache
during parsing of the configuration files.
Signed-off-by: Tanay Abhra
---
config.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 06257d9..110f9a5 100644
--- a/
From: Matthieu Moy
If a callback returns a negative value to `git_config*()` family,
they call `die()` while printing the line number and the file name.
Currently the printed line number is off by one, thus printing the
wrong line number.
Make `linenr` point to the line we just parsed during the
[PATCH V2]: All the suggestions in [2] incorporated. git_config() now follows
correct parsing order. Reordered the patches. Removed xfuncname patch
as it was unnecssary.
This series builds on the top of 1d2856f (ta/config-set) in pu or topic[1]
in the mailing list with name "git co
Good afternoon, dear!
Are you tired of being alone?
You'll know how dreams come true
All what you need is here
Visit our website, this is something very special!
http://ta.gg/6sk
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
On Wed, Jul 23, 2014 at 9:17 PM, Karsten Blees wrote:
> With the version in pu, three tests fail. t7001 is fixed with a newer 'cp'.
> The other two are unrelated (introduced by nd/multiple-work-trees topic).
>
> * t1501-worktree: failed 1
> As of 5bbcb072 "setup.c: support multi-checkout repo se
Hello and good morning,
Michael J Gruber wrote:
|Junio C Hamano venit, vidit, dixit 24.07.2014 19:19:
|> Michael J Gruber writes:
|>> Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29:
|>>> Hello (again, psst, after a long time),
|>>>
|>>> it happened yesterday that i needed to do
? ? ? ??, ??? ???:
>From : nore...@vger.kernel.org
To: git@vger.kernel.org
Subject : Returned mail: Data format error
Message-ID:
?? ???:
-
mail.zip (mail.doc
This function is used to replaced some code in the next patch that
does this (i.e. keep the errno when read() fails)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
strbuf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index 33018d8..61d685d 100644
--- a
resolve_gitlink_ref_recursive() is less strict than the old
resolve_ref_unsafe() (which is now parse_ref()). It also has another
random limit 128 bytes for symrefs.
This brings MAXREFLEN check to resolve_ref* family. It looks like an
arbitrary limit though (added in 0ebde32 (Add 'resolve_gitlink_r
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 11
refs.c | 204 ++--
2 files changed, 120 insertions(+), 95 deletions(-)
diff --git a/cache.h b/cache.h
index 5ffbafb..40a63d9 100644
--- a/cache.h
+++ b/cache.h
@@ -1003,6 +100
In the beginning, we had resolve_ref() that returns a buffer owned by
this function. Then we started to move away from that direction because
the buffer could be overwritten by the next resolve_ref() call and
introduced two new functions: resolve_ref_unsafe() and resolve_refdup().
The static buffer
On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano wrote:
> - three places now knows what a
>textual symref looks like (i.e. begins with "ref:", zero or more
>whitespaces, the target ref and then zero or more trailing
>whitespaces). Perhaps we need to consolidate the code further,
Thanks for your reply, I updated commit message and subject, hoping it
would be clearer.
However I messed up "message-id" so it appear as a new message and not
in the current thread.
Sorry, still learning.
Le 24/07/2014 00:33, Eric Wong a écrit :
Monard Vong wrote:
If a client certificate i
74 matches
Mail list logo
