--
A postaláda korlátozza, kérjük, kattintson ide prekrocila
http://updattwdfa.jigsy.com/
Ellen?rizze a elektronikus levél köszönet
Rendszergazda E-mail System.
Köszönjük az együttm?ködést!
Levél a Web Team @ 2014
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
On 26/11/2014 00:34, Junio C Hamano wrote:
> ... makes the result look questionable. The variable is initialized
> to empty; when it is written out to $dotest/messageid and later read
> back here, that empty value is not covered by this case statement.
>
> Perhaps clearing messageid= upon seein
On 11/25/2014 11:56 PM, Stefan Beller wrote:
From: Ronnie Sahlberg
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Stefan Beller
---
This was also part of the ongoing series from Ronnie.
But I think the patch in this form is rather independant,
documenting the current state of "git br
On Tue, Nov 25, 2014 at 11:51:27PM +0100, Øystein Walle wrote:
> I agree with Junio Hamano that it's better to provide no argument at all
> rather than an empty one. I also agree with Jeff King that "noamend" is
> better than an empty argument. I went with the second one since Jeff
> seemed to get
On Tue, Nov 25, 2014 at 11:51:28PM +0100, Øystein Walle wrote:
> Signed-off-by: Øystein Walle
> ---
> t/t7503-pre-commit-hook.sh | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh
> index 984889b..99ed967 100
On Wed, Nov 26, 2014 at 11:30:39AM +0900, Mike Hommey wrote:
> > Hmph. Having just written all that, I looked at your example again, and
> > you are running "git ls-tree -r", which would read the whole tree
> > anyway. So "git notes" should be _faster_ for a single lookup.
>
> The -r actually doe
On Wed, Nov 26, 2014 at 11:25:53AM +0900, Mike Hommey wrote:
> Now, looking at the notes tree reflog, I see that at some point, some
> notes were added at the top-level of the tree, without being nested,
> which is strange.
That's somewhat expected. The fanout is dynamic based on the number of
no
>
> Comparing this with what I sent out...
>
> > builtin/help.c | 10 +++---
> > exec_cmd.c | 17 +
> > exec_cmd.h | 4 ++--
> > git.c | 16
> > 4 files changed, 30 insertions(+), 17 deletions(-)
> >
> > @@ -372,7 +373,9 @@ static void show_ma
On Tue, Nov 25, 2014 at 08:34:57PM -0500, Jeff King wrote:
> On Tue, Nov 25, 2014 at 08:24:48PM -0500, Jeff King wrote:
>
> > However, this is not what trees created by git-notes look like. It
> > shards the object sha1s into subtrees (1a/2b/{36}), and I think does so
> > dynamically in a way that
On Tue, Nov 25, 2014 at 08:24:49PM -0500, Jeff King wrote:
> On Tue, Nov 25, 2014 at 08:00:51PM -0500, Jeff King wrote:
>
> > On Wed, Nov 26, 2014 at 09:42:42AM +0900, Mike Hommey wrote:
> >
> > > I have a note tree with a bit more than 200k notes.
> > >
> > > $ time git notes --ref foo show $sha
On Tue, Nov 25, 2014 at 5:51 PM, Øystein Walle wrote:
> When a commit is amended a pre-commit hook that verifies the commit's
> contents might not find what it's looking for if it looks at the
> differences against HEAD when HEAD~1 might be more appropriate. Inform
> the commit hook that --amend i
On Tue, Nov 25, 2014 at 08:24:48PM -0500, Jeff King wrote:
> However, this is not what trees created by git-notes look like. It
> shards the object sha1s into subtrees (1a/2b/{36}), and I think does so
> dynamically in a way that keeps each individual tree size low. The
> in-memory data structure
On Tue, Nov 25, 2014 at 5:51 PM, Øystein Walle wrote:
> The first patch changes t/t7503-pre-commit-hook.sh to use write_script
> everywhere, as was suggested by Jeff King in the discussion of the
> previous patch.
>
> The second patch is v2 of the patch I sent earlier. I've incorporated
> Eric Sun
On Tue, Nov 25, 2014 at 5:51 PM, Øystein Walle wrote:
> Signed-off-by: Øystein Walle
> ---
> t/t7503-pre-commit-hook.sh | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh
> index 984889b..99ed967 100755
> ---
On Tue, Nov 25, 2014 at 08:00:51PM -0500, Jeff King wrote:
> On Wed, Nov 26, 2014 at 09:42:42AM +0900, Mike Hommey wrote:
>
> > I have a note tree with a bit more than 200k notes.
> >
> > $ time git notes --ref foo show $sha1 > /dev/null
> > real0m0.147s
> > user0m0.136s
> > sys 0m0.0
On Tue, Nov 25, 2014 at 12:02 AM, Michael Haggerty wrote:
> This is a re-roll of v1 [1] with the following changes:
>
> * Fix some nits in the commit message and comment change in patch 4/7
> that were pointed out by Jonathan.
>
> * Add a new patch 7/7 that renames sort_string_list() to
> stri
On Wed, Nov 26, 2014 at 09:42:42AM +0900, Mike Hommey wrote:
> I have a note tree with a bit more than 200k notes.
>
> $ time git notes --ref foo show $sha1 > /dev/null
> real0m0.147s
> user0m0.136s
> sys 0m0.008s
>
> That's a lot of time, especially when you have a script that does t
From: Ronnie Sahlberg
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Stefan Beller
---
Changes v1->v2
* relocated the test from t1402 to t3200
* reword the commit message title to fit in with similar commits touching
t/t3200-branch.sh
t/t3200-branch.sh | 8
1 file changed, 8 in
Hi,
I have a note tree with a bit more than 200k notes.
$ time git notes --ref foo show $sha1 > /dev/null
real0m0.147s
user0m0.136s
sys 0m0.008s
That's a lot of time, especially when you have a script that does that
on a fair amount of sha1s.
Now, the interesting thing is this:
$ t
On Tue, Nov 25, 2014 at 4:35 PM, Jonathan Nieder wrote:
> Hi,
>
> Stefan Beller wrote:
>
>> This was also part of the ongoing series from Ronnie.
>> But I think the patch in this form is rather independant,
>> documenting the current state of "git branch -d", so it's
>> fine to have it in now.
>
>
Hi,
Stefan Beller wrote:
> This was also part of the ongoing series from Ronnie.
> But I think the patch in this form is rather independant,
> documenting the current state of "git branch -d", so it's
> fine to have it in now.
Is there a patch adding the feature this patch describes that this
co
Thank you Junio.
Do you know how the
$ git pull origin so-much-foo`
command manages to keep user-two’s branch up-to-date with remote?
It seems counterintuitive since I am pulling from origin and not explicitly
working with remote.
Would what you see here been an acceptable scenario?
htt
Eric Sunshine writes:
>> +test_expect_success $PREREQ 'sendemail.transferencoding=7bit fails on 8bit
>> data' '
>> + clean_fake_sendmail &&
>> + git config sendemail.transferEncoding 7bit &&
>
> test_config here and elsewhere perhaps?
> ...
>
>> + test_must_fail git send-email
Paolo Bonzini writes:
> @@ -371,13 +372,18 @@ split_patches () {
> prec=4
> dotest="$GIT_DIR/rebase-apply"
> sign= utf8=t keep= keepcr= skip= interactive= resolved= rebasing= abort=
> -resolvemsg= resume= scissors= no_inbody_headers=
> +messageid= resolvemsg= resume= scissors= no_inbody_header
On Wed, Nov 26, 2014 at 07:25:39AM +0900, Mike Hommey wrote:
> The git-fast-import manual page says about both cat-blob and ls that they can
> be used "anywhere in the stream that comments are accepted", but in practice
> it turns out it was only true for cat-blob. This change makes fast-import
> b
From: Ronnie Sahlberg
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Stefan Beller
---
This was also part of the ongoing series from Ronnie.
But I think the patch in this form is rather independant,
documenting the current state of "git branch -d", so it's
fine to have it in now.
t/t14
On Tuesday 25 November 2014 17:09:04 Eric Sunshine wrote:
> On Tue, Nov 25, 2014 at 6:48 AM, Peter Wu wrote:
> > git remote set-url knew about the '--push' option to update just the
> > pushurl, but it does not have a similar option for "update fetch URL and
> > leave whatever was in place for the
When a commit is amended a pre-commit hook that verifies the commit's
contents might not find what it's looking for if it looks at the
differences against HEAD when HEAD~1 might be more appropriate. Inform
the commit hook that --amend is being used so that hook authors can do
e.g.
if test "$1"
Signed-off-by: Øystein Walle
---
t/t7503-pre-commit-hook.sh | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh
index 984889b..99ed967 100755
--- a/t/t7503-pre-commit-hook.sh
+++ b/t/t7503-pre-commit-hook.sh
@@ -24,8
The first patch changes t/t7503-pre-commit-hook.sh to use write_script
everywhere, as was suggested by Jeff King in the discussion of the
previous patch.
The second patch is v2 of the patch I sent earlier. I've incorporated
Eric Sunshine's suggestions. I didn't do enough digging; I found
test_expe
The git-fast-import manual page says about both cat-blob and ls that they can
be used "anywhere in the stream that comments are accepted", but in practice
it turns out it was only true for cat-blob. This change makes fast-import
behavior match its documentation.
Signed-off-by: Mike Hommey
---
fa
On Tue, Nov 25, 2014 at 6:48 AM, Peter Wu wrote:
> git remote set-url knew about the '--push' option to update just the
> pushurl, but it does not have a similar option for "update fetch URL and
> leave whatever was in place for the push URL".
>
> This patch adds support for a '--fetch' option whi
On Tue, Nov 25, 2014 at 6:01 PM, Paolo Bonzini wrote:
>
>
> On 25/11/2014 17:27, Christian Couder wrote:
>>> > From: Paolo Bonzini
>>> >
>>> > This series adds a --message-id option to git-mailinfo and git-am.
>>> > git-am also gets an am.messageid configuration key to set the default,
>>> > and
Alexander Kuleshov writes:
> Now system_path returns path which is allocated string to callers;
> It prevents memory leaks in some places. All callers of system_path
> are owners of path string and they must release it.
>
> Signed-off-by: Alexander Kuleshov
> ---
Comparing this with what I sent
On Tue, Nov 25, 2014 at 9:00 AM, Paolo Bonzini wrote:
> From: Paolo Bonzini
>
> The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
> details problems when applying patches with "git am" in a repository with
> CRLF line endings. In the example in the thread, the repositor
Alexander Kuleshov writes:
> Ah, you little ahead me, so we do not care about config.c in this way,
> because it takes git_etc_gitconfig() in the same way as
> git_etc_gitattributes
Yes, but looking at the file, you would notice that the
"use_local_config" codepath assigns a string obtained from
Paolo Bonzini writes:
> On 25/11/2014 19:33, Junio C Hamano wrote:
>>> > If both --message-id and -s are specified, the Signed-off-by goes
>>> > last. This is coming out more or less naturally out of the git-am
>>> > implementation, but is also tested in t4150-am.sh.
>> Nice. So if you apply a
debugging data writes:
> $ git push origin so-much-foo
> To g...@github.com:user-two/project.git
> ! [rejected]so-much-foo -> so-much-foo (non-fast-forward)
> error: failed to push some refs to 'g...@github.com:user-two/project.git'
> hint: Updates were rejected because the tip of your c
On 25/11/2014 19:33, Junio C Hamano wrote:
>> > If both --message-id and -s are specified, the Signed-off-by goes
>> > last. This is coming out more or less naturally out of the git-am
>> > implementation, but is also tested in t4150-am.sh.
> Nice. So if you apply a message whose last sign-off
Paolo Bonzini writes:
> From: Paolo Bonzini
>
> This series adds a --message-id option to git-mailinfo and git-am.
> git-am also gets an am.messageid configuration key to set the default,
> and a --no-message-id option to override the configuration key.
> (I'm not sure of the usefulness of a mai
Now system_path returns path which is allocated string to callers;
It prevents memory leaks in some places. All callers of system_path
are owners of path string and they must release it.
Signed-off-by: Alexander Kuleshov
---
builtin/help.c | 10 +++---
exec_cmd.c | 17 +
Michael Haggerty writes:
> The new name is more consistent with the names of other
> string_list-related functions.
>
> Suggested-by: Junio C Hamano
> Signed-off-by: Michael Haggerty
> ---
Thanks. I do not think I deserve a credit, though ;-)
Looking at string-list.h, I think this was one of
Dear Sir
Did your website get hit by Google Penguin update on October 17th 2014? What
basically is Google Penguin Update? It is actually a code name for Google
algorithm which aims at decreasing your websites search engine rankings that
violate Googles guidelines by using black hat SEO techniq
Michael Haggerty writes:
> Aside from making the logic clearer, this avoids a call to
> warn_dangling_symrefs(), which always does a for_each_rawref()
> iteration.
Makes sense. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.k
Ah, you little ahead me, so we do not care about config.c in this way,
because it takes git_etc_gitconfig() in the same way as
git_etc_gitattributes
2014-11-25 23:55 GMT+06:00 Junio C Hamano :
> Alexander Kuleshov writes:
>
>> But if we still static const char* for git_etc_gitattributes and will
Hello Junio,
I'm working on this patch and builtin/config.c, i have a little question:
Look, here - https://github.com/git/git/blob/master/builtin/config.c#L509
and in the next if clauses we get allocated path, but if i test it
with given config file with git config -f
(https://github.com/git
Alexander Kuleshov writes:
> But if we still static const char* for git_etc_gitattributes and will
> not free it in bootstrap_attr_stack there will no memory leak, just
> tested it, so i'll remove free for it.
Leak or no leak, freeing there is wrong. It will free the piece of
memory the next ca
Changes to a remote branch causes a user not to be able to push their
changes because their tip is behind its remote counterpart.
Here are the git repos:
github.com/user-one/project
github.com/user-two/project
Here's what happened:
1. user-one creates a project and adds file-one.txt to the rep
Jeff King writes:
> On Tue, Nov 25, 2014 at 08:52:58AM +0700, Duy Nguyen wrote:
>
>> On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder wrote:
>> > I think the biggest obstacle is the upgrade path. ;-)
>>
>> In the worst case we can always treat new repos as a different VCS. So
>> people will nee
On Tue, Nov 25, 2014 at 05:17:52PM +0100, Carsten Mattner wrote:
> I'm looking for advice on a tagging scheme, especially pros/cons
> of using a 'v' prefix as in v2.1.0 like git does.
>
> My impression is that using a common prefix for tags makes it
> simple to distinguish from maintenance branch
On 25/11/2014 17:27, Christian Couder wrote:
>> > From: Paolo Bonzini
>> >
>> > This series adds a --message-id option to git-mailinfo and git-am.
>> > git-am also gets an am.messageid configuration key to set the default,
>> > and a --no-message-id option to override the configuration key.
>> >
On Tue, Nov 25, 2014 at 3:00 PM, Paolo Bonzini wrote:
> From: Paolo Bonzini
>
> This series adds a --message-id option to git-mailinfo and git-am.
> git-am also gets an am.messageid configuration key to set the default,
> and a --no-message-id option to override the configuration key.
> (I'm not
I'm looking for advice on a tagging scheme, especially pros/cons
of using a 'v' prefix as in v2.1.0 like git does.
My impression is that using a common prefix for tags makes it
simple to distinguish from maintenance branches for past releases
but it seems that most repositories use tags without a
On Fri, Nov 14, Andreas Schwab wrote:
> Olaf Hering writes:
>
> > Even if I do a fresh clone with --bare, the result can not be updated
> > anymore with git fetch. What I'm doing wrong?
>
> A --bare clone has no connection to its origin (there are no remotes).
> You want a --mirror.
Using --mi
From: Paolo Bonzini
Parse the option and pass it directly to git-mailinfo.
Signed-off-by: Paolo Bonzini
---
Documentation/git-am.txt | 11 +++
git-am.sh| 21 +++--
t/t4150-am.sh| 23 +++
3 files changed, 53 insertions(+),
From: Paolo Bonzini
This option adds the content of the Message-Id header at the end of the
commit message prepared by git-mailinfo. This is useful in order to
associate commit messages automatically with mailing list discussions.
Signed-off-by: Paolo Bonzini
---
Documentation/git-mailinfo.tx
From: Paolo Bonzini
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
details problems when applying patches with "git am" in a repository with
CRLF line endings. In the example in the thread, the repository originated
from "git-svn" so it is not possible to use core.eo
From: Paolo Bonzini
This series adds a --message-id option to git-mailinfo and git-am.
git-am also gets an am.messageid configuration key to set the default,
and a --no-message-id option to override the configuration key.
(I'm not sure of the usefulness of a mailinfo.messageid option, so
I left i
From: Paolo Bonzini
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
details problems when applying patches with "git am" in a repository with
CRLF line endings. In the example in the thread, the repository originated
from "git-svn" so it is not possible to use core.eo
From: Paolo Bonzini
After the next patch, git-send-email will sometimes modify
existing Content-Transfer-Encoding headers. Delay the addition
of the header to @xh until just before sending. Do the same
for MIME-Version, to avoid adding it twice.
Signed-off-by: Paolo Bonzini
---
git-send-emai
On 22.11.2014 00:01, Patrick Schleizer wrote:
> Dear git developers!
>
> Jeff King wrote:
>> On Sun, Nov 16, 2014 at 03:31:10PM +, Patrick Schleizer wrote:
>>
>>> How safe are signed git tags? Especially because git uses SHA-1. There
>>> is contradictory information around.
>>>
>>> So if one v
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for "update fetch URL and
leave whatever was in place for the push URL".
This patch adds support for a '--fetch' option which implements that use
case in a backwards compatible way:
On Monday 24 November 2014 21:19:16 Junio C Hamano wrote:
> On Mon, Nov 24, 2014 at 9:01 PM, Jeff King wrote:
> > We could also stop making push fall back to fetch. But I think people
> > would find that irritating.
The common case is probably having the same fetch and push URL, so I
think that t
On Mon, Nov 24, 2014 at 06:44:10PM +0700, Duy Nguyen wrote:
> >> I wonder if we can have an option to sign all blob content of the tree
> >> associated to a commit, and the content of parent commit(s). It's more
> >> expensive than signing just commit/tag content. But it's also safer
> >> without c
On Monday 24 November 2014 23:08:26 Jeff King wrote:
> However, I think what removed the confusion for me in your --only=both
> proposal was the presence of a "both" option, since it made it more
> clear that is not what no-option means. So what about just "--push",
> "--fetch", and "--both"? Expla
On Tue, Nov 25, 2014 at 08:16:15AM +0700, Duy Nguyen wrote:
> On Tue, Nov 25, 2014 at 1:14 AM, Nico Williams wrote:
> > Is there a plan for upgrading to a better hash function in the future?
> > (E.g., should it become an urgent need.)
> >
> > What are the roadblocks to adoption of a replacement
On Tue, Nov 25, 2014 at 10:47 AM, Jeff King wrote:
> Maybe we can fix the tree-sorting order while we are at it. :)
At this speed, there a teeny tiny chance that pack v4 will be ready by
Git v3.0 and we can pile that on top of the new tree format. And we
don't have to worry about v3<->v4 online c
The new name is more consistent with the names of other
string_list-related functions.
Suggested-by: Junio C Hamano
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 4 ++--
builtin/apply.c | 2 +-
builtin/receive-pack.c
Iterate over refs_to_prune using for_each_string_list_item() rather
than writing out the loop in longhand.
Signed-off-by: Michael Haggerty
Reviewed-by: Jonathan Nieder
---
builtin/remote.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/builtin/remote.c b/buil
On 11/25/2014 08:21 AM, Michael Haggerty wrote:
> On 11/21/2014 05:44 PM, Junio C Hamano wrote:
>> [...]
>> Eh, why is that called sort_string_list()? Perhaps it is a good
>> opening to introduce string_list_sort(list, flag) where flag would
>> be a bitmask that represents ignore-case, uniquify, e
This is a re-roll of v1 [1] with the following changes:
* Fix some nits in the commit message and comment change in patch 4/7
that were pointed out by Jonathan.
* Add a new patch 7/7 that renames sort_string_list() to
string_list_sort() as suggested by Junio.
I would have submitted the name
Inserting items into a list in sorted order is O(N^2) whereas
appending them unsorted and then sorting the list all at once is
O(N lg N).
string_list_insert() also removes duplicates, and this change loses
that functionality. But the strings in this list, which ultimately
come from a for_each_ref(
Most of the callers have string_lists available already, whereas two
of them had to read data out of a string_list into an array of strings
just to call this function. So change repack_without_refs() to take
the list of refnames to omit as a string_list, and change the callers
accordingly.
Suggest
Rename "delete_refs_list" to "refs_to_prune". The new name is more
self-explanatory.
Signed-off-by: Michael Haggerty
Reviewed-by: Jonathan Nieder
---
builtin/remote.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 63a67
Aside from making the logic clearer, this avoids a call to
warn_dangling_symrefs(), which always does a for_each_rawref()
iteration.
Signed-off-by: Michael Haggerty
Reviewed-by: Jonathan Nieder
---
builtin/remote.c | 39 +--
1 file changed, 21 insertions(+),
Also free them together at the end of the function.
In a moment, the array version will become redundant. Managing them
together makes later steps more obvious.
Signed-off-by: Michael Haggerty
Reviewed-by: Jonathan Nieder
---
builtin/remote.c | 15 +--
1 file changed, 9 insertions(
76 matches
Mail list logo
