On Wed, Nov 26, 2014 at 7:24 PM, Jonathan Nieder wrote:
> Alexander Kuleshov wrote:
> [...]
>> +++ b/builtin/cat-file.c
>> @@ -68,9 +69,14 @@ static int cat_one_file(int opt, const char
>> +buf_must_free = 1;
>> +
>> -if (!buf)
>> +if (!buf) {
>> +free(buf);
>>
From: Ronnie Sahlberg
Define a new transaction update type, UPDATE_LOG, and a new function
transaction_update_reflog. This function will lock the reflog and append
an entry to it during transaction commit. We can pass a flag to this
function, which can truncate the the reflog file before we write
From: Ronnie Sahlberg
Add a field that describes what type of update this refers to. For now
the only type is UPDATE_SHA1 but we will soon add more types.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Stefan Beller
---
refs.c | 27 +++
1 file changed, 23 insertions(+),
From: Ronnie Sahlberg
Rename the transaction functions. Remove the leading ref_ from the
names and append _ref to the names for functions that create/delete/
update sha1 refs.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Stefan Beller
---
This commit can be reproduced via
find . -name "*.[ch
From: Ronnie Sahlberg
Use a transaction for all updates during expire_reflog.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Stefan Beller
---
builtin/reflog.c | 85
1 file changed, 37 insertions(+), 48 deletions(-)
diff --git a/builtin
This is the core part of the refs-transactions-reflog series[1],
which was in discussion for a bit already.
The idea is to have the reflog being part of the transactions, which
the refs are already using, so the we're moving towards a database
like API in the long run. This makes git easier to mai
On Wed, Nov 26, 2014 at 03:09:45PM -0800, Junio C Hamano wrote:
> * jk/pack-bitmap (2014-08-04) 1 commit
> - pack-bitmap: do not use gcc packed attribute
>
> Hold, waiting for Karsten's replacement.
I got tired of waiting, so here it is, I hope good enough for inclusion.
-- >8 --
From: Karste
On November 26, 2014 7:43:06 PM PST, Jeff King wrote:
>On Wed, Nov 26, 2014 at 02:29:28PM -0800, Adam Williamson wrote:
>
>> Hi, folks. Ran into an unfortunate issue with git which helped me
>mess
>> up a Fedora package repo today :/
>>
>> The problem can be reproduced thus:
>>
>> 1. Create an e
On Wed, Nov 26, 2014 at 02:29:28PM -0800, Adam Williamson wrote:
> Hi, folks. Ran into an unfortunate issue with git which helped me mess
> up a Fedora package repo today :/
>
> The problem can be reproduced thus:
>
> 1. Create an empty repo, clone it
> 2. Push its master branch with something i
On 11/27/2014 06:50 AM, Jonathan Nieder wrote:
> Hi Hugh,
>
> Hugh Davenport wrote:
>
>> Where is the best place to report a security vulnerability in git?
>
> Current practice is to contact Junio C Hamano .
> Cc-ing Jeff King isn't a bad idea while at it.
>
> We should probably set up a maili
Thanks. Will send a report their way soon
On 27 November 2014 2:20:53 pm NZDT, Jonathan Nieder wrote:
>Hi Hugh,
>
>Hugh Davenport wrote:
>
>> Where is the best place to report a security vulnerability in git?
>
>Current practice is to contact Junio C Hamano .
>Cc-ing Jeff King isn't a bad idea w
Hi Hugh,
Hugh Davenport wrote:
> Where is the best place to report a security vulnerability in git?
Current practice is to contact Junio C Hamano .
Cc-ing Jeff King isn't a bad idea while at it.
We should probably set up a mailing list to make this more obvious,
but that's what we have today.
--
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
Hi,
Alexander Kuleshov wrote:
> [Subject: cat-file: fix a memory leak in cat_one_file]
Can you explain further? How did you run into this? Is it an
unbounded leak or a small one-time leak? What is the benefit of
applying this patch?
"By code inspection" is a fine answer to the question of ho
On Wed, Nov 26, 2014 at 10:07 AM, Paolo Bonzini wrote:
>
>
> On 25/11/2014 22:21, Christian Couder wrote:
>> On Tue, Nov 25, 2014 at 6:01 PM, Paolo Bonzini wrote:
>>>
>>> As far as I understand, all the git-am hooks are called on the commit
>>> rather than the incoming email: all headers are lost
The latest feature release Git v2.2 is now available at the usual
places. Big thanks go to 77 contributors, among which 20 are new
people, who made 550+ changes in total since Git v2.1 was released.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public
Paul Smith writes:
> This is what happens for a file:
>
> $ rm -f foo
>
> $ touch foo
>
> $ ./src/git/contrib/workdir/git-new-workdir src/git foo master
> mkdir: cannot create directory ‘foo’: Not a directory
> unable to create new workdir "foo"!
;-) That comes from mkdir || fail which is indee
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
I haven't had time to write comments (they are essentially release
notes entries to be used when/if the topic graduates to 'master')
for new top
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
I work with One Track. Are you the user email? It is important you get back to
me
--
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
This patch series adds support for a new receive.denyCurrentBranch setting
to update the working directory (which must be clean, i.e. there must not be
any uncommitted changes) when pushing into the current branch.
The scenario in which the 'updateInstead' setting became a boon in this
developer's
When synchronizing between working directories, it can be handy to update
the current branch via 'push' rather than 'pull', e.g. when pushing a fix
from inside a VM, or when pushing a fix made on a user's machine (where
the developer is not at liberty to install an ssh daemon let alone know
the use
On Wed, 2014-11-26 at 14:29 -0800, Adam Williamson wrote:
> Hi, folks. Ran into an unfortunate issue with git which helped me mess
> up a Fedora package repo today :/
>
> The problem can be reproduced thus:
Whoops, I missed step 0:
0. Ensure push.default is not configured globally
> 1. Create a
On Wed, 2014-11-26 at 13:55 -0800, Junio C Hamano wrote:
> The comment in the original is somewhat misleading, but "test -e"
> was "test -e" and not "test -d" to stop when an existing file was
> given by mistake as $new_workdir, I think. I do not know what
> happens in the new code in that case.
Hi, folks. Ran into an unfortunate issue with git which helped me mess
up a Fedora package repo today :/
The problem can be reproduced thus:
1. Create an empty repo, clone it
2. Push its master branch with something in it (just to get started)
3. git branch --track moo origin/master
4. git checko
Jonathan,
On Wed, Nov 26, 2014 at 3:55 PM, Jonathan Nieder wrote:
> Actually, 'git grep -h' tells me that git grep --name-only is already
> accepted as a synonym for --files-with-matches, ever since
You are absolutely right, it was a typo (and then not RTFM the
resulting help) on my part that ca
On Wed, Nov 26, 2014 at 03:10:33PM -0600, Woody Gilk wrote:
> git diff --name-only
> git grep --files-with-matches
>
> I think --files-with-matches should be deprecated and replaced with
> --name-only for consistency.
git grep supports both: --name-only for consistency with other git
commands, an
Hi Woody,
Woody Gilk wrote:
> git diff --name-only
> git grep --files-with-matches
>
> I think --files-with-matches should be deprecated and replaced with
> --name-only for consistency.
See the (non-git) diff(1) and grep(1) manpages.
It might make sense for 'git grep' to learn --name-only too a
Paul Smith writes:
> Allow new workdirs to be created in an empty directory (similar to "git
> clone"). Provide more error checking and clean up on failure.
>
> Signed-off-by: Paul Smith
> ---
>
> Hopefully this doesn't contain unwanted stylistic changes.
;-)
Unwanted, no, but unrelated yes.
Woody Gilk writes:
> git diff --name-only
> git grep --files-with-matches
>
> I think --files-with-matches should be deprecated and replaced with
> --name-only for consistency.
That longer name comes from "GNU grep" consistency.
Why anybody does not use a shorter and sweeter "grep -l" is beyond
Paul Smith writes:
> In our development process we always want to do rebase and only rarely
> create merge commits, and so we have a recommendation to set the
> merge.ff configuration attribute to "only".
>
> This is great, however it appears to break git merge --squash (which we
> also use const
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 at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 26, 2014 at 11:22 AM, Derek Moore wrote:
>> Now knowing the edge cases won't work, I did not get an idea about the
>> standard case of what should work with this. Would you mind to write
>> a more detailed example or a more advertising paragraph of what this can do?
>> Not getting the
On Tue, Nov 25, 2014 at 12:09:42PM -0500, Jeff King wrote:
> 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 pref
git diff --name-only
git grep --files-with-matches
I think --files-with-matches should be deprecated and replaced with
--name-only for consistency.
Thanks,
--
Woody Gilk
http://about.me/shadowhand
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord
Johannes Schindelin writes:
> +Another option is "updateInstead" which will update the working
> +directory (must be clean) if pushing into the current branch. This option is
> +intended for synchronizing working directories when one side is not easily
> +accessible via interactive ssh (e.g. a li
Weihnachten kommt,
wir halten eine gro?e Aktivit?t in dieser Woche,
der Preis für iphone 6plus ist 420euro.very amzing
ipad, Samsung s5 .
w eb : loo.
comN�Р骒r��yb�X�肚�v�^�)藓{.n�+丕��≤�}��财�z�&j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f
Allow new workdirs to be created in an empty directory (similar to "git
clone"). Provide more error checking and clean up on failure.
Signed-off-by: Paul Smith
---
Hopefully this doesn't contain unwanted stylistic changes. There's a
kind of gross thing about the behavior here: because we cd mu
This patch "series" adds support for a new receive.denyCurrentBranch setting
to update the working directory (which must be clean, i.e. there must not be
any uncommitted changes) when pushing into the current branch.
The scenario in which the 'updateInstead' setting became a boon in this
developer
Junio C Hamano writes:
> "Ulrich Windl" writes:
>
>> Another split that is not possible is a split across an empty line, like:
>>
>> +AAA
>> +
>> +BBB
>
> Likewise. An empty line is not that special. AAA may be adding one
> block of lines "if (condition) { ... }" and BBB may be another, a
When synchronizing between working directories, it can be handy to update
the current branch via 'push' rather than 'pull', e.g. when pushing a fix
from inside a VM, or when pushing a fix made on a user's machine (where
the developer is not at liberty to install an ssh daemon let alone know
the use
Jeff King writes:
> On Wed, Nov 26, 2014 at 10:12:08AM -0800, Junio C Hamano wrote:
>
>> >> +write_script "$HOOK" <> >
>> > While you are touching this line, please make it "<<\EOF". It does not
>> > matter for these simple cases, but as a style, we try to avoid
>> > interpolation unless it is ne
In our development process we always want to do rebase and only rarely
create merge commits, and so we have a recommendation to set the
merge.ff configuration attribute to "only".
This is great, however it appears to break git merge --squash (which we
also use constantly).
If I'm squash-merging f
> Now knowing the edge cases won't work, I did not get an idea about the
> standard case of what should work with this. Would you mind to write
> a more detailed example or a more advertising paragraph of what this can do?
> Not getting the big picture may be related to me having not worked with RC
On Wed, Nov 26, 2014 at 10:12:08AM -0800, Junio C Hamano wrote:
> >> +write_script "$HOOK" < >
> > While you are touching this line, please make it "<<\EOF". It does not
> > matter for these simple cases, but as a style, we try to avoid
> > interpolation unless it is necessary.
>
> Thanks. It is
"Ulrich Windl" writes:
> This is for git-1.7.12 (an older version from the SLES11 SP3 SDK). If
> the issue is solved meanwhile, I'll be happy, and I apologize for
> being too lazy to find out.
The answer is no ;-).
> Currently Git cannot split a block of changes like
>
> -AAA
> -BBB
> +CCC
> +D
On Wed, Nov 26, 2014 at 10:35:22AM -0800, Junio C Hamano wrote:
> I _think_ "give only info that is necessary" is cleaner as an
> interface in theory, but have two niggles myself:
>
> 1. the hooks must do the "argument parsing" loop (you already
> mentioned this);
>
> 2. the hooks cannot t
Mike Hommey writes:
> An example where this happens is when doing an ls-tree on a tree that
> contains a commit link. In that case, find_unique_abbrev is called
> to get a non-abbreviated hex sha1, but still, a lookup is done as
> to whether the sha1 is in the repository (which ends up looking fo
Michael Haggerty writes:
> ... On the other hand, this is kind of an "aspirational test"; I don't
> know that the tested functionality has ever worked or that anybody has
> ever claimed that it works. So my feeling is that the addition of the
> test would feel more natural in the patch series tha
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
Changes v2 -> v3
* remove space nit pointed out by M
Jeff King writes:
> 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
Jeff King writes:
> 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
On Wed, Nov 26, 2014 at 8:44 AM, Derek Moore wrote:
> Junio, et al.,
>
> I've completed my first pass at RCS Keywords in Git. I believe I've
> come up with a solution that is accurate, performant and complete (but
> I have not tested it on big repos yet, I'm doing that today...).
>
> https://githu
Stefan Beller writes:
> As this is in conflict with origin/sb/simplify-repack-without-refs
> we'd need to decide, which we'd take. I'd gladly go with this series as it
> seems
> cleaner and easier to read.
I'll drop sb/simlify-repack-without-refs and replace it with this
series (naturally calle
Alexander Kuleshov writes:
>> > + setenv("INFOPATH", git_info_path, 1);
>> > + free(git_info_path);
>> > execlp("info", "info", "gitman", page, (char *)NULL);
>> > die(_("no info viewer handled the request"));
>>
>> We are just about to exec; does this warrant the code churn?
Junio, et al.,
I've completed my first pass at RCS Keywords in Git. I believe I've
come up with a solution that is accurate, performant and complete (but
I have not tested it on big repos yet, I'm doing that today...).
https://github.com/derekm/git-keywords
This work basically takes advantage of
Hi!
This is for git-1.7.12 (an older version from the SLES11 SP3 SDK). If the issue
is solved meanwhile, I'll be happy, and I apologize for being too lazy to find
out.
Currently Git cannot split a block of changes like
-AAA
-BBB
+CCC
+DDD
Into
-AAA
+CCC
and
-BBB
+DDD
So you'll have to edit i
Sometimes we should free output buffer in cat_one_file, but not always.
It must to be freed only if it was allocated during git cat-file -t,
commit,tag and tree types handling.
Signed-off-by: Alexander Kuleshov
---
builtin/cat-file.c | 13 -
1 file changed, 12 insertions(+), 1 deleti
What do you think if we create int variable, something like
given_config_must_free = 0; and will set up it to 1 in cases where it
will be allocated, and than we can free it in the end of cmd_config?
I'm reading git source code to understanding git internals and found
little memory leak in cat-file,
On Wed, Nov 26, 2014 at 12:46:20PM +0100, Johan Herland wrote:
> (First of all, thanks to both for great investigation and analysis)
>
> On Wed, Nov 26, 2014 at 5:46 AM, Jeff King wrote:
> > On Wed, Nov 26, 2014 at 11:25:53AM +0900, Mike Hommey wrote:
> >
> >> Now, looking at the notes tree reflo
(First of all, thanks to both for great investigation and analysis)
On Wed, Nov 26, 2014 at 5:46 AM, Jeff King wrote:
> 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 t
An example where this happens is when doing an ls-tree on a tree that
contains a commit link. In that case, find_unique_abbrev is called
to get a non-abbreviated hex sha1, but still, a lookup is done as
to whether the sha1 is in the repository (which ends up looking for
a loose object in .git/objec
Maybe we will discard this patch, because i looked on it and tested
with different places, it brings more leaks than before?
2014-11-26 9:53 GMT+06:00 Alexander Kuleshov :
>>
>> Comparing this with what I sent out...
>>
>> > builtin/help.c | 10 +++---
>> > exec_cmd.c | 17 +--
On 25/11/2014 22:21, Christian Couder wrote:
> 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.messag
Aside from one tiny formatting nit (see below), the test looks good to
me. On the other hand, this is kind of an "aspirational test"; I don't
know that the tested functionality has ever worked or that anybody has
ever claimed that it works. So my feeling is that the addition of the
test would feel
65 matches
Mail list logo
