On Thu, Aug 21, 2014 at 12:05 AM, Marc Branchaud wrote:
> On 14-08-16 12:06 PM, Christian Couder wrote:
>
>> +The trailers are recognized in the input message using the following
>> +rules:
>> +
>> +* by default only lines that contains a ':' (colon) are considered
>
> s/contains/contain/
Ok.
>>
Bert Wesarg writes:
> On Wed, Aug 20, 2014 at 12:06 AM, Junio C Hamano wrote:
>> The basic flow based on this mechanism goes like this:
>>
>> 1. You push out your work with "git push -s".
>>
>> 2. The sending side learns where the remote refs are as usual,
>> together with what protocol ex
Hi,
Ronnie Sahlberg wrote:
> List, please see here an overview and ordering of the ref transaction
> patch series.
Thanks much for this.
[...]
> rs/ref-transaction-0
[...]
> Has been merged into next.
This is even part of "master" now, so if people have review comments
then they can make them
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A few fixes for regressions have been posted since 2.1 was tagged,
which I'd like to address before moving any topic to 'master',
rewinding 'nex
Jaime Soriano Pastor writes:
> New approach for the case of finding unmerged files with merged entries
> in the index.
> After some discussion the solution tries to:
> - Avoid the problems with infinite loops in this case.
> - Provide better information to the user in the commands affected.
> - M
On 14-08-16 12:06 PM, Christian Couder wrote:
> While at it add git-interpret-trailers to "command-list.txt".
>
> Signed-off-by: Christian Couder
> Signed-off-by: Junio C Hamano
> ---
> Documentation/git-interpret-trailers.txt | 308
> +++
> command-list.txt
On Wed, Aug 20, 2014 at 1:11 PM, Michael Haggerty wrote:
> On 08/20/2014 09:45 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> I think we can get away with not including broken refnames when
>>> iterating. After all, the main goal of tolerating them is to let them
>>> be deleted, ri
Michael Haggerty writes:
> On 08/20/2014 09:45 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> I think we can get away with not including broken refnames when
>>> iterating. After all, the main goal of tolerating them is to let them
>>> be deleted, right?
>>
>> Or read from a ref
Jaime Soriano Pastor writes:
> Subject: Re: [PATCH 4/4] git update-index --cacheinfo can be used to select
> a stage when there are merged and unmerged entries
Hmph, what does it even mean? Shared with your [1/4] is that it is
unclear if you are stating an existing problem to be fixed or
descr
Jaime Soriano Pastor writes:
> Signed-off-by: Jaime Soriano Pastor
> ---
> t/t9904-unmerged-file-with-merged-entry.sh | 86
> ++
Isn't this number already used for another test? A test on the
index probably belongs to t2XXX or t3XXX family.
> 1 file changed, 86 i
Thanks.
Will queue on top of v2.0.0-rc0~146^2 (tests: add checking that
combine-diff emits only correct paths, 2014-02-03) so that we can
merge the fix down to 2.0 maintenance track later.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.
On 08/20/2014 09:45 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I think we can get away with not including broken refnames when
>> iterating. After all, the main goal of tolerating them is to let them
>> be deleted, right?
>
> Or read from a ref whose name has retroactively made i
Michael Haggerty writes:
> I think we can get away with not including broken refnames when
> iterating. After all, the main goal of tolerating them is to let them
> be deleted, right?
Or read from a ref whose name has retroactively made invalid, in
order to create a similar but validly named re
David Turner writes:
> On Wed, 2014-08-20 at 10:29 -0700, Junio C Hamano wrote:
>> On Wed, Aug 20, 2014 at 9:56 AM, David Turner
>> wrote:
>> > On Tue, 2014-08-19 at 15:06 -0700, Junio C Hamano wrote:
>> >> Reusing the GPG signature check helpers we already have, verify
>> >> the signature in r
Bernhard Reiter writes:
> Rename the imap_folder variable to folder and make it a member
> of struct imap_server_conf.
>
> Signed-off-by: Bernhard Reiter
> ---
> As discussed in
> http://www.mail-archive.com/git@vger.kernel.org/msg57019.html
>
> Bernhard
>
> imap-send.c | 10 +-
> 1 fil
On 08/20/2014 06:28 PM, Ronnie Sahlberg wrote:
> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty
> wrote:
>> I'm a little worried that abandoning *all* refname checks could open us
>> up to somehow trying to delete a "reference" with a name like
>> "../../../../etc/passwd". Either such names h
On Wed, 2014-08-20 at 10:29 -0700, Junio C Hamano wrote:
> On Wed, Aug 20, 2014 at 9:56 AM, David Turner
> wrote:
> > On Tue, 2014-08-19 at 15:06 -0700, Junio C Hamano wrote:
> >> Reusing the GPG signature check helpers we already have, verify
> >> the signature in receive-pack and give the resul
On Wed, Aug 20, 2014 at 10:49 AM, Jonathan Nieder wrote:
> Hi,
>
> Ronnie Sahlberg wrote:
>> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty
>> wrote:
>
>>> I'm a little worried that abandoning *all* refname checks could open us
>>> up to somehow trying to delete a "reference" with a name like
Jeff King writes:
> On Wed, Aug 20, 2014 at 08:55:52PM +1200, Chris Packham wrote:
>
>> I actually find the existing behaviour useful. If I want to disable a
>> hook to I can just chmod -x .git/hook/... and I then chmod +x it when
>> I want to re-enable it. I guess I could live with an extra warn
Hi,
Ronnie Sahlberg wrote:
> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty
> wrote:
>> I'm a little worried that abandoning *all* refname checks could open us
>> up to somehow trying to delete a "reference" with a name like
>> "../../../../etc/passwd". Either such names have to be prohibit
On Wed, Aug 20, 2014 at 9:56 AM, David Turner wrote:
> On Tue, 2014-08-19 at 15:06 -0700, Junio C Hamano wrote:
>> Reusing the GPG signature check helpers we already have, verify
>> the signature in receive-pack and give the results to the hooks
>> via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment
On Tue, 2014-08-19 at 15:06 -0700, Junio C Hamano wrote:
> Reusing the GPG signature check helpers we already have, verify
> the signature in receive-pack and give the results to the hooks
> via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment variables.
>
> Policy decisions, such as accepting or rej
On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty wrote:
> On 07/15/2014 10:58 PM, Ronnie Sahlberg wrote:
>> On Tue, Jul 15, 2014 at 12:34 PM, Ronnie Sahlberg
>> wrote:
>>> On Tue, Jul 15, 2014 at 11:04 AM, Jonathan Nieder
>>> wrote:
Michael Haggerty wrote:
> So...I like the idea
On 07/15/2014 10:58 PM, Ronnie Sahlberg wrote:
> On Tue, Jul 15, 2014 at 12:34 PM, Ronnie Sahlberg wrote:
>> On Tue, Jul 15, 2014 at 11:04 AM, Jonathan Nieder wrote:
>>> Michael Haggerty wrote:
>>>
So...I like the idea of enforcing refname checks at the lowest level
possible, but I thin
On Tue, Aug 19, 2014 at 3:57 PM, Heiko Voigt wrote:
> I would actually error out when specified in already cloned state.
> Because otherwise the user might expect the remote to be updated.
>
> Since we are currently busy implementing recursive fetch and checkout I have
> added that to our ideas li
Signed-off-by: Thomas Braun
---
Today I found out that both %cd and %ad pretty print format
specifications honour the --date option as shown in:
$ git log --abbrev=8 --date=short --pretty="%h (%s, %cd)" -n1
5bdb1c4e (Merge pull request #245 from
kblees/kb/master/fix-libsvn-address-conflict, 2014
Signed-off-by: Jaime Soriano Pastor
---
read-cache.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index c932b83..d549d0b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -935,6 +935,7 @@ static int add_index_entry_with_check(struct
New approach for the case of finding unmerged files with merged entries
in the index.
After some discussion the solution tries to:
- Avoid the problems with infinite loops in this case.
- Provide better information to the user in the commands affected.
- Make sure there are ways to clean the index.
Signed-off-by: Jaime Soriano Pastor
---
read-cache.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 7f5645e..c932b83 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1933,6 +1933,7 @@ int read_index_unmerged(struct inde
Signed-off-by: Jaime Soriano Pastor
---
builtin/update-index.c | 1 +
cache.h| 1 +
read-cache.c | 3 ++-
t/t9904-unmerged-file-with-merged-entry.sh | 14 +++---
4 files changed, 15 insertions(+), 4 d
Signed-off-by: Jaime Soriano Pastor
---
t/t9904-unmerged-file-with-merged-entry.sh | 86 ++
1 file changed, 86 insertions(+)
create mode 100755 t/t9904-unmerged-file-with-merged-entry.sh
diff --git a/t/t9904-unmerged-file-with-merged-entry.sh
b/t/t9904-unmerged-file
On Wed, Aug 20, 2014 at 08:55:52PM +1200, Chris Packham wrote:
> I actually find the existing behaviour useful. If I want to disable a
> hook to I can just chmod -x .git/hook/... and I then chmod +x it when
> I want to re-enable it. I guess I could live with an extra warning as
> long as the comma
Damn! I haven’t seen that missing space.
Thank you Peff!
Davide--
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
I knew that gitk is written in a scripting language, so I had high hopes of making a
little tweak to it. But, alas, it's 12000 lines of languages I don't know!
The farthest I got was finding “text $cflist \” on line 2381 and the corroborating comment
“# lower right” just above it.
What I wan
On Wed, Aug 20, 2014 at 4:52 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Tue, Aug 19, 2014 at 04:05:21PM +1000, Babak M wrote:
>>
>>> I saw that if a hook file is present in .git/hooks and it does not
>>> have execution permissions it is silently ignored.
>>>
>>> I thought it might be w
On Wed, Aug 20, 2014 at 10:16:11AM +0200, Davide Fiorentino wrote:
> I was in the need to rewrite author name and email and commit date for a
> single commit and I guess I found a bug.
> I run this git-filter script
>
> $ git filter-branch --commit-filter ‘
> if [ "$GIT_COMMIT"="9cfca27" ];
Hi,
I was in the need to rewrite author name and email and commit date for a single
commit and I guess I found a bug.
I run this git-filter script
$ git filter-branch --commit-filter ‘
if [ "$GIT_COMMIT"="9cfca27" ];
then GIT_AUTHOR_NAME=“Michelle”;
GIT_AUTHOR_EMAIL=“mi
- Ursprungligt meddelande -
> Från: "Junio C Hamano"
> Till: "Johannes Sixt"
> Kopia: "Robin Rosenberg" , git@vger.kernel.org
> Skickat: onsdag, 20 aug 2014 0:14:21
> Ämne: Re: [PATCH v3] Allow the user to change the temporary file name for
> mergetool
>
> Johannes Sixt writes:
>
>
Am 19.08.2014 um 19:15 schrieb Robin Rosenberg:
> Using the original filename suffix for the temporary input files to
> the merge tool confuses IDEs like Eclipse. This patch introduces
> a configurtion option, mergetool.tmpsuffix, which get appended to
> the temporary file name. That way the user c
39 matches
Mail list logo
