Need to update git-svn.perl to match Documentation/git-svn.txt so
--preserve-merges|p can be used in dcommit. Similar to
https://github.com/git/git/commit/b64e1f58158d1d1a8eafabbbf002a1a3c1d72929#diff-f9a64e34cbe6c3ee4f62698008a33773R571
Nate.
Documentation/git-svn.txt
626 -m::
627 --merge::
Agree, but "partial" here means... what? just a little doc?
On Wed, May 28, 2014 at 11:53 AM, Jakub Narębski wrote:
> W dniu 2014-05-27 19:16, Pasha Bolokhov pisze:
>
Add GIT_DIR to the list of excludes in setup_standard_excludes(),
while checking that GIT_DIR is not just '.git', in wh
The title pretty much says it all. Lack of this feature (or presence
of this bug [depending on your perspective]) is a major PITA.
--Jonathan
--
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
--
Kedves felhasználók e-mailben;
Túllépte 23432 box set
Web Service / Admin, és akkor nem lesz probléma a küldő és
fogadhat e-maileket, amíg újra ellenőrizni. Kérjük, frissítse kattintva
linkre, és töltse ki az adatokat, hogy ellenőrizze a számla
Kérjük, kövesse az alábbi linkre, és majd másolj
In a repository with many refs, check_refname_component can be a major
contributor to the runtime of some git commands. Provide two
optimized versions of this function: one for machines with SSE4.2, and
one for machines without. One such command is
git rev-parse HEAD
Timings for one particular
Felipe Contreras wrote:
> In mail [3] you acknowledged my wish, and you said you were going to put
> stubs for v2.0, and you didn't. You also conveniently removed this mail
> from the archives.
My bad. You actually did it. I missed it because the commit is named
'Revert "Merge branch 'jc/graduate-
On Wed, 2014-05-28 at 23:44 +0200, Michael Haggerty wrote:
> On 05/28/2014 11:04 PM, David Turner wrote:
> > In a repository with tens of thousands of refs, the command
> > ~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
> > is a bit slow. check_refname_component is a major co
Move backwards from the end of the string (more efficient for
lines which do not have trailing spaces or have just a couple).
Slightly more rare occurrences of 'text \' with a backslash
in between spaces are handled correctly.
Namely, the code in 8ba87adad6 does not reset 'last_space' when
a b
Ronnie Sahlberg wrote:
> I rely on the fact that if the transaction has failed then it is safe
> to call ref_transaction_commit since it is guaranteed to return an
> error too.
Yes, I am saying that behavior for ref_transaction_commit is weird.
Usually when ref_transaction_commit is called I can
This is the last mail I sent to you, because you ignore them anyway, and
remove them from the mailing list.
I'm am cc'ing the git-fc mailing list so there's a public track record
of this, so you can't claim it didn't happen.
Junio C Hamano wrote:
> * The "remote-hg/bzr" remote-helper interfaces
On Wed, May 28, 2014 at 3:17 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>> On Wed, May 28, 2014 at 12:47 PM, Jonathan Nieder wrote:
>
>>> --- i/fast-import.c
>>> +++ w/fast-import.c
>>> @@ -1735,21 +1735,28 @@ static void dump_tags(void)
>>> {
>>> static const char *msg = "fast-
Junio C Hamano writes:
> The tarballs are found at:
>
> https://www.kernel.org/pub/software/scm/git/testing/
Heh, I do not know how this slipped in, but the real release tarball
is not in git/testing/ but found at:
https://www.kernel.org/pub/software/scm/git/
--
To unsubscribe from th
The latest feature release Git v2.0.0 is now available at the
usual places.
We had to delay the final release by a week or so because we found a
few problems in earlier release candidates (request-pull had a
regression that stopped it from showing the "tags/" prefix in
"Please pull tags/frotz" whe
On 05/28/2014 06:58 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I think for any two backends that are stacked, you would need to break
>> down a transaction as follows (here generalized to include not only
>> deletions):
>>
>> packed->begin_transaction()
>> loose->begin_tran
Ronnie Sahlberg wrote:
> On Wed, May 28, 2014 at 12:47 PM, Jonathan Nieder wrote:
>> --- i/fast-import.c
>> +++ w/fast-import.c
>> @@ -1735,21 +1735,28 @@ static void dump_tags(void)
>> {
>> static const char *msg = "fast-import";
>> struct tag *t;
>> - char ref_name[PATH_M
On Wed, May 28, 2014 at 5:36 AM, Duy Nguyen wrote:
> On Tue, May 27, 2014 at 10:56 AM, Pasha Bolokhov
> wrote:
>> @@ -1588,6 +1588,38 @@ void setup_standard_excludes(struct dir_struct *dir)
>> {
>> const char *path;
>> char *xdg_path;
>> + const char *r_git, *gitdir = get_g
On Wed, May 28, 2014 at 12:47 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> --- a/fast-import.c
>> +++ b/fast-import.c
>> @@ -1735,15 +1735,22 @@ static void dump_tags(void)
>> {
>> static const char *msg = "fast-import";
>> struct tag *t;
>> - struct ref_lock *lock;
>>
David Turner writes:
> On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:
>> David Turner writes:
>>
>> > RFC follows:
>> >
>> > 1. On a case-insensitive server, git receive-pack ought to always reject
>> > branches which are same-but-for-case of existing branches.
>> > 2. On a case-sensi
On Wed, May 28, 2014 at 2:51 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> 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
Ronnie Sahlberg wrote:
> 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.
s/from the packed refs/from packed-refs, nor delete the ref'
On Wed, May 28, 2014 at 11:51 AM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> --- a/refs.c
>> +++ b/refs.c
> [...]
>> @@ -3385,6 +3408,9 @@ int ref_transaction_update(struct ref_transaction
>> *transaction,
>> {
>> struct ref_update *update;
>>
>> + if (transaction->state != R
On 05/28/2014 11:04 PM, David Turner wrote:
> In a repository with tens of thousands of refs, the command
> ~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
> is a bit slow. check_refname_component is a major contributor to the
> runtime. Provide two optimized versions of this
David Turner writes:
> In a repository with tens of thousands of refs, the command
> ~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
> is a bit slow. check_refname_component is a major contributor to the
> runtime. Provide two optimized versions of this function: one for
>
Done.
Thanks.
On Wed, May 28, 2014 at 12:31 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -3474,11 +3474,28 @@ int update_ref(const char *action, const char
>> *refname,
>> const unsigned char *sha1, const unsigned char *oldval,
>>
I just tested the previous patch on a Mac with clang and it needed
some tweaks.
Also, I should clarify that this represents a real use-case: we really
do have tens of thousands of branches on some repos. It would be nice
if people would clean up after themselves, but they don't.
(Also, it's prob
In a repository with tens of thousands of refs, the command
~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
is a bit slow. check_refname_component is a major contributor to the
runtime. Provide two optimized versions of this function: one for
machines with SSE4.2, and one for
On Wed, May 28, 2014 at 12:56 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> 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 w
Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> refs.c | 35 +--
> 1 file changed, 9 insertions(+), 26 deletions(-)
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord.
In a repository with tens of thousands of refs, the command
~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
is a bit slow. check_refname_component is a major contributor to the
runtime. Provide two optimized versions of this function: one for
machines with SSE4.2, and one for
Ronnie Sahlberg wrote:
> 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 function without free()ing the msg
Ronnie Sahlberg wrote:
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1735,15 +1735,22 @@ static void dump_tags(void)
> {
> static const char *msg = "fast-import";
> struct tag *t;
> - struct ref_lock *lock;
> char ref_name[PATH_MAX];
> + struct strbuf err = STRBUF_IN
Christian Couder writes:
> +trailer..key::
> + This `key` will be used instead of in the
> + trailer. After the last alphanumeric character, this variable
> + can contain some non alphanumeric characters, like for example
> + `'%'` (one percent sign), `' = '` (one space followed
Christian Couder writes:
> +The trailers are recognized in the input message using the following
> +rules:
> +
> +* only lines that contains a ':' (colon) are considered trailers,
> +
> +* the trailer lines must all be next to each other,
> +
> +* after them it's only possible to have some lines
Ronnie Sahlberg wrote:
> --- a/refs.c
> +++ b/refs.c
> @@ -3474,11 +3474,28 @@ int update_ref(const char *action, const char
> *refname,
> const unsigned char *sha1, const unsigned char *oldval,
> int flags, enum action_on_err onerr)
> {
> - struct ref_lock *lock;
>
Christian Couder writes:
> +test_expect_success 'using "where = before" for a token in the middle of the
> message' '
> + git config trailer.review.key "Reviewed-by:" &&
Don't you want to adjust this to have trailing SP, just like you
adjusted other ones like "Fixes: " in this round?
--
To
On Wed, 28 May 2014, Junio C Hamano wrote:
David Lang writes:
On Wed, 28 May 2014, Dale R. Worley wrote:
It seems that much of Git was coded under the assumption that any file
could always be held entirely in RAM. Who made that mistake? Are
people so out of touch with reality?
Git was d
On Wed, 28 May 2014, Dale R. Worley wrote:
From: David Lang
Git was designed to track source code, there are warts that show up
in the implementation when you use individual files >4GB
I'd expect that if you want to deal with files over 100k, you should
assume that it doesn't all fit in me
Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> fast-import.c | 25 +++--
> 1 file changed, 15 insertions(+), 10 deletions(-)
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...
David Lang writes:
> On Wed, 28 May 2014, Dale R. Worley wrote:
>
>> It seems that much of Git was coded under the assumption that any file
>> could always be held entirely in RAM. Who made that mistake? Are
>> people so out of touch with reality?
>
> Git was designed to track source code, ther
W dniu 2014-05-27 19:16, Pasha Bolokhov pisze:
Add GIT_DIR to the list of excludes in setup_standard_excludes(),
while checking that GIT_DIR is not just '.git', in which case it
would be ignored by default, and that GIT_DIR is inside GIT_WORK_TREE
gives git-grep.txt and git-ls-files.txt. I don'
> From: David Lang
> Git was designed to track source code, there are warts that show up
> in the implementation when you use individual files >4GB
I'd expect that if you want to deal with files over 100k, you should
assume that it doesn't all fit in memory.
Dale
--
To unsubscribe from this lis
Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> sequencer.c | 24
> 1 file changed, 16 insertions(+), 8 deletions(-)
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vge
Ronnie Sahlberg wrote:
> --- a/refs.c
> +++ b/refs.c
[...]
> @@ -3385,6 +3408,9 @@ int ref_transaction_update(struct ref_transaction
> *transaction,
> {
> struct ref_update *update;
>
> + if (transaction->state != REF_TRANSACTION_OPEN)
> + return -1;
I still think this i
Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> builtin/update-ref.c | 5 +++--
> refs.c | 16 +++-
> refs.h | 12
> 3 files changed, 22 insertions(+), 11 deletions(-)
Reviewed-by: Jonathan Nieder
[...]
> +++ b/refs.c
> @@
Hi,
Looking at 67b8fcee:
Ronnie Sahlberg wrote:
> On Tue, May 27, 2014 at 5:11 PM, Jonathan Nieder wrote:
>> Ronnie Sahlberg wrote:
>>> --- a/refs.c
>>> +++ b/refs.c
>>> @@ -2208,6 +2208,7 @@ int commit_packed_refs(void)
>>> struct packed_ref_cache *packed_ref_cache =
>>> ge
On Wed, 28 May 2014, Dale R. Worley wrote:
From: Duy Nguyen
I don't know how many commands are hit by this. If you have time and
gdb, please put a break point in die_builtin() function and send
backtraces for those that fail. You could speed up the process by
creating a smaller file and set
> From: Junio C Hamano
> You need to have enough memory (virtual is fine if you have enough
> time) to do fsck. Some part of index-pack could be refactored into
> a common helper function that could be called from fsck, but I think
> it would be a lot of work.
How much memory is "enough"? And
> From: Duy Nguyen
> I don't know how many commands are hit by this. If you have time and
> gdb, please put a break point in die_builtin() function and send
> backtraces for those that fail. You could speed up the process by
> creating a smaller file and set the environment variable
> GIT_ALLOC_L
Ronnie Sahlberg wrote:
> Can you re-review these patches for me :
>
> please review
>
> 67b8fce refs.c: add an err argument to repack_without_refs
> 738ac43 refs.c: add an err argument to delete_ref_loose
> b78b0e0 refs.c: update ref_transaction_delete to check for error and
> return status
> e558
Thanks
Can you re-review these patches for me :
please review
67b8fce refs.c: add an err argument to repack_without_refs
738ac43 refs.c: add an err argument to delete_ref_loose
b78b0e0 refs.c: update ref_transaction_delete to check for error and
return status
e558f96 refs.c: add transaction.stat
On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > RFC follows:
> >
> > 1. On a case-insensitive server, git receive-pack ought to always reject
> > branches which are same-but-for-case of existing branches.
> > 2. On a case-sensitive server, the same rule by de
David Kastrup writes:
>>> diff --git a/progress.c b/progress.c
>>> index 261314e..24df263 100644
>>> --- a/progress.c
>>> +++ b/progress.c
>>> @@ -66,8 +66,12 @@ static void set_progress_signal(void)
>>> static void clear_progress_signal(void)
>>> {
>>> struct itimerval v = {{0,},};
>>> +
Noam Postavsky writes:
> % git init
> Initialized empty Git repository in /home/npostavs/tmp/scratch/.git/
> % echo foo > x
> % git add x
> % git commit -m x
> [master (root-commit) 41be1f2] x
> 1 file changed, 1 insertion(+)
> create mode 100644 x
> % echo bar > x
> % git diff | head -3
> dif
Ronnie Sahlberg wrote:
> Please re-review.
06df8942 is
Reviewed-by: Jonathan Nieder
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, May 28, 2014 at 10:07 AM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> Updated the comment in refs.h
>
> Thanks.
>
>> +++ b/refs.h
>> @@ -215,6 +215,31 @@ enum action_on_err {
>> };
>>
>> /*
>> + * On error, transaction functions append a message about what
>> + * went wrong to t
David Turner writes:
> RFC follows:
>
> 1. On a case-insensitive server, git receive-pack ought to always reject
> branches which are same-but-for-case of existing branches.
> 2. On a case-sensitive server, the same rule by default, with an option
> to allow the old behavior.
>
> Let me know if,
Duy Nguyen writes:
>> $ git fsck --full --strict
>> notice: HEAD points to an unborn branch (master)
>> Checking object directories: 100% (256/256), done.
>> fatal: Out of memory, malloc failed (tried to allocate 21474836481 bytes)
>
> Back trace for this one
> ...
> Not easy to f
Ronnie Sahlberg wrote:
> Updated the comment in refs.h
Thanks.
> +++ b/refs.h
> @@ -215,6 +215,31 @@ enum action_on_err {
> };
>
> /*
> + * On error, transaction functions append a message about what
> + * went wrong to the 'err' argument. The message mentions what
> + * ref was being updat
Michael Haggerty writes:
> I think for any two backends that are stacked, you would need to break
> down a transaction as follows (here generalized to include not only
> deletions):
>
> packed->begin_transaction()
> loose->begin_transaction()
>
> # And this part is done within stacked
Ronnie Sahlberg wrote:
> I reworded the commit message.
Thanks much. Looks good.
--
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, May 28, 2014 at 09:40:55AM +0200, Johannes Sixt wrote:
> Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
> > From signal(2)
> >
> > The behavior of signal() varies across UNIX versions, and has also var‐
> > ied historically across different versions of Linux. Avoid its use:
> > use
Jeff King peff.net> writes:
> [..]
> Secondly, I do get the same warning about HEAD:
>
> $ git clone repo.bundle repofrombundle
> Cloning into 'repofrombundle'...
> Receiving objects: 100% (3/3), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> but that war
On Wed, May 28, 2014 at 08:07:38PM +1200, Chris Packham wrote:
> On 28/05/14 18:14, Jeremiah Mahler wrote:
> > From signal(2)
> >
> > The behavior of signal() varies across UNIX versions, and has also var‐
> > ied historically across different versions of Linux. Avoid its use:
> > use si
On Tue, May 27, 2014 at 5:11 PM, Jonathan Nieder wrote:
> Hi,
>
> Comments from http://marc.info/?l=git&m=140079653930751&w=2:
>
> Ronnie Sahlberg wrote:
>
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -559,6 +559,8 @@ struct lock_file {
>> #define LOCK_DIE_ON_ERROR 1
>> #define LOCK_NODEREF 2
>> ext
Am 27.05.2014 18:47, schrieb Dale R. Worley:
> Even doing a 'git reset' does not put the repository in a state where
> 'git fsck' will complete:
You have to remove the offending commit also from the reflog.
The following snipped creates an offending commit, big_file is 2GB which
is too large for
On Tue, May 27, 2014 at 5:42 PM, Jonathan Nieder wrote:
> Hi,
>
> Ronnie Sahlberg wrote:
>
>> --- a/refs.h
>> +++ b/refs.h
>> @@ -215,6 +215,15 @@ enum action_on_err {
>> };
>>
>> /*
>> + * Transaction functions that take an err argument will append an error
>> + * string to this buffer if there
On Tue, May 27, 2014 at 5:27 PM, Jonathan Nieder wrote:
> Hi,
>
> Comments from http://marc.info/?l=git&m=140079653930751&w=2:
>
> Ronnie Sahlberg wrote:
>
>> [Subject: update-ref.c: log transaction error from the update_ref]
>
> The above description suggests that this is going to add new logging
On Tue, May 27, 2014 at 5:25 PM, Jonathan Nieder wrote:
> Hi,
>
> Comments from http://marc.info/?l=git&m=140079653930751&w=2:
>
> Ronnie Sahlberg wrote:
>
> [...]
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -2491,17 +2491,43 @@ static int repack_without_ref(const char *refname)
>> return repack_w
On wo, 2014-05-28 at 21:16 +0700, Duy Nguyen wrote:
> On Wed, May 28, 2014 at 9:02 PM, Thomas Kieffer wrote:
> > I then clone the bare repository with --depth 1.
> >
> > git clone file:///path/to/bare.git ./clone --depth 1
> >
> > It always returns the last two commits. If I specify --depth 2 it r
On 05/27/2014 08:27 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> This suggests to me that our current structure is best modeled as two
>> independent reference back ends, with a third implementation of the same
>> reference API whose job it is to compose the first two. In pseudocode
On Wed, May 28, 2014 at 9:02 PM, Thomas Kieffer wrote:
> I then clone the bare repository with --depth 1.
>
> git clone file:///path/to/bare.git ./clone --depth 1
>
> It always returns the last two commits. If I specify --depth 2 it returns
> the last 3 commits.
>
> If I use --depth 1 on a Github
Hi there Git developers,
I'm not sure if I found a bug in the command
git clone repo.git cloned_repo --depth 1
I follow these steps:
git init
echo "First commit" >> test.txt
git add -A
git commit -am "First commit"
echo "Second commit" >> test.txt
git commit -am "Second commit"
echo "Third c
On Tue, May 27, 2014 at 11:47 PM, Dale R. Worley wrote:
> I've discovered a problem using Git. It's not clear to me what the
> "correct" behavior should be, but it seems to me that Git is failing
> in an undesirable way.
>
> The problem arises when trying to handle a very large file. For
> examp
On Tue, May 27, 2014 at 10:56 AM, Pasha Bolokhov
wrote:
> @@ -1588,6 +1588,38 @@ void setup_standard_excludes(struct dir_struct *dir)
> {
> const char *path;
> char *xdg_path;
> + const char *r_git, *gitdir = get_git_dir();
> + char *n_git, *basename;
> + int len
On Mon, May 26, 2014 at 1:33 PM, Tanay Abhra wrote:
> Subject: config: Add new query functions to the api
This sounds as if you are adding new functions to the header file.
Saying "... to the api docs" would been clearer. Better:
config: document new query functions
> Add explanations for `
On Mon, May 26, 2014 at 1:33 PM, Tanay Abhra wrote:
> Add an internal cache with the all variable value pairs read from the usual
> config files(repo specific .git/config, user wide ~/.gitconfig and the global
s/(/ (/
> /etc/gitconfig). Also, add two external functions `git_config_get_string` an
Erik Faye-Lund writes:
> On Wed, May 28, 2014 at 10:19 AM, David Kastrup wrote:
>> Chris Packham writes:
>>
>>> On 28/05/14 18:14, Jeremiah Mahler wrote:
static void clear_progress_signal(void)
{
struct itimerval v = {{0,},};
+struct sigaction sa;
+
+
Philippe Vaucher wrote:
> Sorry if I missed a thread where it was already decided not to include
> it.
>
> Felipe, please don't use this to start any non-constructive behavior
> (rant on who is right/wrong, "my patches are not accepted", etc).
I never sent those patches. I gave up on the Git proj
On Wed, May 28, 2014 at 10:19 AM, David Kastrup wrote:
> Chris Packham writes:
>
>> On 28/05/14 18:14, Jeremiah Mahler wrote:
>>> From signal(2)
>>>
>>> The behavior of signal() varies across UNIX versions, and has also var‐
>>> ied historically across different versions of Linux. Avoid it
On Wed, May 28, 2014 at 10:11 AM, Chris Packham wrote:
> On 28/05/14 19:40, Johannes Sixt wrote:
>> Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
>>> From signal(2)
>>>
>>> The behavior of signal() varies across UNIX versions, and has also var‐
>>> ied historically across different versions of L
Chris Packham writes:
> On 28/05/14 18:14, Jeremiah Mahler wrote:
>> From signal(2)
>>
>> The behavior of signal() varies across UNIX versions, and has also var‐
>> ied historically across different versions of Linux. Avoid its use:
>> use sigaction(2) instead. See Portability below.
On 28/05/14 19:40, Johannes Sixt wrote:
> Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
>> From signal(2)
>>
>> The behavior of signal() varies across UNIX versions, and has also var‐
>> ied historically across different versions of Linux. Avoid its use:
>> use sigaction(2) instead. See Po
On 28/05/14 18:14, Jeremiah Mahler wrote:
> From signal(2)
>
> The behavior of signal() varies across UNIX versions, and has also var‐
> ied historically across different versions of Linux. Avoid its use:
> use sigaction(2) instead. See Portability below.
Minor nit. The last sentence a
Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
> From signal(2)
>
> The behavior of signal() varies across UNIX versions, and has also var‐
> ied historically across different versions of Linux. Avoid its use:
> use sigaction(2) instead. See Portability below.
>
> This patch set replaces
> Felipe Contreras wrote:
>> == git update ==
>>
>> Another proposed solution is to have a new command: `git update`. This
>> command would be similar to `git pull --ff-only` by default, but it
>> could be configured to do merges instead, and when doing so in reverse.
>
> And here it is:
>
> https:
85 matches
Mail list logo
