On 29 April 2014 21:47:42 GMT+10:00, Felipe Contreras
wrote:
>James Denholm wrote:
>> I've no right to say this, given that I've no contributions I'm not
>> saying that you shouldn't work on the git codebase, you could very
>> easily fork it and make the innovative SCMS none of us can see, and
>>
Felipe Contreras wrote
> [PATCH v5 1/6] pull: rename pull.rename to pull.mode
s/pull.rename/pull.rebase/
--
View this message in context:
http://git.661346.n2.nabble.com/PATCH-v5-0-6-Reject-non-ff-pulls-by-default-tp7609118p7609129.html
Sent from the git mailing list archive at Nabble.com.
--
Postkassen har overskredet grænsen for opbevaring. re-validere din postkasse
ved hjælp af nedenstående link.
https://knlhymiopiojda.typeform.com/to/HDCcIw
Tak,
Webmail System Administrator
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vge
James Denholm wrote:
> I've no right to say this, given that I've no contributions I'm not
> saying that you shouldn't work on the git codebase, you could very
> easily fork it and make the innovative SCMS none of us can see, and
> kill git. Can be done, if hunting really is the best choice as you
David Kastrup wrote:
> Felipe Contreras writes:
>
> > David Kastrup wrote:
> >
> >> The default behavior of "git push".
> >
> > This is a minor change that not many people would notice, and it has not
> > actually happend. But fine, let's count it as one.
>
> Shrug. Your diatribe is to a good p
On Tue, Apr 29, 2014 at 1:05 PM, Jeremy Morton wrote:
> On 28/04/2014 17:37, Junio C Hamano wrote:
>>
>> Christian Couder writes:
>>
>>> From: Junio C Hamano
Christian Couder writes:
...
>>>
>>>
> + trailer. After some alphanumeric characters, it can contain
> +
It is very typical for Git newcomers to inadvertently create merges and
worst; inadvertently pushing them. This is one of the reasons many
experienced users prefer to avoid 'git pull', and recommend newcomers to
avoid it as well.
To avoid these problems and keep 'git pull' useful, it has been
sugg
Also, deprecate --no-rebase since there's no need for it any more.
Signed-off-by: Felipe Contreras
---
Documentation/git-pull.txt | 8 ++--
git-pull.sh| 6 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pu
Signed-off-by: Felipe Contreras
---
Documentation/git-pull.txt | 18 ++
git-pull.sh | 2 +-
t/t4013-diff-various.sh | 2 +-
t/t5500-fetch-pack.sh| 2 +-
t/t5524-pull-msg.sh | 2 +-
t/t5700-clone-reference.sh | 4 ++--
t/t6022-merge-r
It is very typical for Git newcomers to inadvertently create merges and worst:
inadvertently pushing them. This is one of the reasons many experienced users
prefer to avoid 'git pull', and recommend newcomers to avoid it as well.
To avoid these problems and keep 'git pull' useful, it has been agre
Also 'branch..rebase' to 'branch..pullmode'.
This way 'pull.mode' can be set to 'merge', and the default can be
something else.
The old configurations still work, but get deprecated.
Signed-off-by: Felipe Contreras
---
Documentation/config.txt | 34 +-
Documen
And branch.$name.pullmode.
Signed-off-by: Felipe Contreras
---
t/t5505-remote.sh | 2 +-
t/t5520-pull.sh | 54 +++---
2 files changed, 24 insertions(+), 32 deletions(-)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index ac79dd9..76376e4 1
Signed-off-by: Felipe Contreras
---
git-pull.sh | 65 -
1 file changed, 34 insertions(+), 31 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index d4e25f1..3dfd856 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -57,16 +57,11 @@ then
On 28/04/2014 17:37, Junio C Hamano wrote:
Christian Couder writes:
From: Junio C Hamano
Christian Couder writes:
...
+ trailer. After some alphanumeric characters, it can contain
+ some non alphanumeric characters like ':', '=' or '#' that will
+ be used instead of ':'
I've no right to say this, given that I've no contributions
thus far to the project, little history in open source at all,
and have only been following the list for less than a week,
but I'll say it anyway, mayhaps.
And I don't mean this to cause offence, or inspire outrage,
or any similar sort of
Previously 'git rev-parse --show-toplevel' was used to determine the
canonical work-tree only when the installed git version was detected to
be 1.7.0 or better. The fall-back logic used the core.worktree config
variable which in the case of a submodule is a relative path from the
submodule's $GIT_D
Felipe Contreras writes:
> David Kastrup wrote:
>
>> The default behavior of "git push".
>
> This is a minor change that not many people would notice, and it has not
> actually happend. But fine, let's count it as one.
Shrug. Your diatribe is to a good part about the default behavior of
"git pu
David Kastrup wrote:
> Felipe Contreras writes:
>
> > David Kastrup wrote:
> >
> >> Well, there you have it. The ones that do any kind of relevant change
> >> are the ones that need thinking about and consideration. And when you
> >> are so verbose about them that
> >>
> >> a) you are getting
From: Karsten Blees
Date: Fri, 7 Jan 2011 17:20:21 +0100
Dynamic linking is generally preferred over static linking, and MSVCRT.dll
has been integral part of Windows for a long time.
This also fixes linker warnings for _malloc and _free in zlib.lib, which
seems to be compiled for MSVCRT.dll alre
Felipe Contreras writes:
> David Kastrup wrote:
>
>> Well, there you have it. The ones that do any kind of relevant change
>> are the ones that need thinking about and consideration. And when you
>> are so verbose about them that
>>
>> a) you are getting on people's nerves
>> b) nobody else fi
David Kastrup wrote:
> Felipe Contreras writes:
>
> > David Kastrup wrote:
> >
> >> Even while the ones getting the benefits from your work will not
> >> feel an obligation to make it worth your while, there is a
> >> difference in satisfaction between getting your work trashed and
> >> getting i
Felipe Contreras writes:
> David Kastrup wrote:
>
>> Even while the ones getting the benefits from your work will not
>> feel an obligation to make it worth your while, there is a
>> difference in satisfaction between getting your work trashed and
>> getting it used.
>
> I don't know why this kee
David Kastrup wrote:
> Felipe Contreras writes:
>
> > Contributors don't have any responsibility to champion their
> > patches. It is pro bono work.
>
> No, that's just the appearance that should be upheld in the higher
> society. It's ok to get paid for work on Git as long as you don't
> ment
On 04/28/2014 09:16 PM, Ronnie Sahlberg wrote:
> On Fri, Apr 25, 2014 at 4:16 PM, Michael Haggerty
> wrote:
>> On 04/25/2014 06:14 PM, Ronnie Sahlberg wrote:
>>> Change create_branch to use a ref transaction when creating the new branch.
>>> ref_transaction_create will check that the ref does not
On 04/28/2014 07:59 PM, Ronnie Sahlberg wrote:
> On Fri, Apr 25, 2014 at 6:31 PM, Michael Haggerty
> wrote:
>> On 04/25/2014 06:14 PM, Ronnie Sahlberg wrote:
>>> Change ref_transaction_commit to take a pointer to a pointer for the
>>> transaction. This allows us to clear the transaction pointer f
We want to ignore secondary heads, otherwise we will import revisions
that won't have any ref pointing to them and might eventually be pruned,
which would cause problems with the synchronization of marks.
This can only be expressed properly as '::b - ::a', but that's not
efficient, specially in ol
Signed-off-by: Felipe Contreras
---
t/t5810-remote-hg.sh | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/t/t5810-remote-hg.sh b/t/t5810-remote-hg.sh
index 594a0a1..ba8b2d8 100755
--- a/t/t5810-remote-hg.sh
+++ b/t/t5810-remote-hg.sh
@@ -105,17 +105,18 @@ setup () {
Cleanup 51be46e (remote-hg: do not fail on invalid bookmarks).
Having a 40-characters string is not ideal, and having three tests for
basically the same relatively rare situation is overkill.
Signed-off-by: Felipe Contreras
---
git-remote-hg.py | 2 +-
t/t5810-remote-hg.sh | 56 ---
Commit 2594a79 (remote-hg: fix bad state issue) originally introduced
this code in order to avoid synchronization issues while pushing,
because `git fast-export` might end up writing the marks before a crash
in the remote helper occurs.
However, the problem is in `git fast-export`; the marks shoul
This can happen when there's a synchronization issue between marks-git
and marks-hg; a key is missing in marks-hg, and when we receive a reset
command the value of ctx basically comes from None.
Signed-off-by: Felipe Contreras
---
git-remote-hg.py | 5 +
1 file changed, 5 insertions(+)
diff
Other tools use the 'committer' extra field differently, so let's make
the parsing more reliable and don't assume it's in a certain format.
Reported-by: Kevin Cox
Signed-off-by: Felipe Contreras
---
git-remote-hg.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/git
This is what Mercurial does.
Reported-by: Nathan Palmer
Signed-off-by: Felipe Contreras
---
git-remote-hg.py | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/git-remote-hg.py b/git-remote-hg.py
index c849abb..204ceeb 100755
--- a/git-remote-hg.py
+++ b/git-remote
From: Daniel Liew
Use the hgrc configuration file in the internal mercurial repository in
addition to the other system wide hgrc files. This is done by using the
'ui' object from the 'repository' object which will have loaded the
repository hgrc file if it exists.
Signed-off-by: Dan Liew
Signed
A few trivial updates, a few important fixes.
Daniel Liew (1):
git-remote-hg: use internal clone's hgrc
Felipe Contreras (7):
remote-hg: fix parsing of custom committer
remote-hg: update to 'public' phase when pushing
remote-{hg,bzr}: store marks only on success
remote-hg: properly det
All MinGW flavors have inttypes.h, so just include it.
However, we need to pass -D__USE_MINGW_ANSI_STDIO=0 to select
MSVCRT-compatible macro definitions on MinGW-W64:
http://sourceforge.net/apps/trac/mingw-w64/wiki/gnu%20printf
As a side-effect, Git no longer builds with MSVC < 2010 due to
its la
Is it absolutely valid and possible to have cURL in generic
MinGW environment. Building Git without cURL is still possible
by passing NO_CURL=1
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 --
1 file changed, 2 deletions(-)
diff --git a/config.mak.uname b/co
HAVE_LIBCHARSET_H and NO_R_TO_GCC_LINKER are not specific to
msysGit, they're general MinGW settings.
Logic behind HAVE_LIBCHARSET_H: if user is on MinGW and has iconv,
we expect him to have libcharset.h. If user doesn't have iconv,
he has to explicitly say so via NO_ICONV=1.
Signed-off-by: Marat
On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.
Removal -DNOGDI=1 from config.mak.uname has an undesirable effect of
bringing in wingdi.h with weird #define ERROR 0 that conflicts with
internal Git enums. So, just #undef NOGDI in compat/poll/poll.c.
Signed-off-by: Marat Rad
pid_t is available in sys/types.h on both MinGW and MinGW-W64
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 1 -
compat/msvc.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 87d58ba..7e3d038 100644
---
1. Unlike MinGW, MinGW-W64 already provides _ReadWriteBarrier macro,
so don't try to redefine it.
2. MinGW-W64 has a strange definition FORCEINLINE as
extern __inline__ __attribute__((__always_inline__,__gnu_inline__))
'extern' doesn't work together with 'static', so #undef MinGW-W64
When crosscompiling, one cannot rely on `uname` from host system.
Thus, add an option to use `make MINGW=1` for building MinGW build
from non-MinGW host (Linux, for example).
Signed-off-by: Marat Radchenko
---
config.mak.uname | 5 +
1 file changed, 5 insertions(+)
diff --git a/config.mak.u
-D__USE_MINGW_ACCESS only affects MinGW and does nothing when
MSVC is used.
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.mak.uname b/config.mak.uname
index 23a8803..faddb82 100644
--- a/co
fork() is not used in MinGW builds but causes a compiler warning
on x86_64 MinGW-W64: conflicting types for built-in function 'fork'
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
in
On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
Fix `warning: passing argument 2 of 'mingw_main' from incompatible
pointer type` in http-fetch.c and remote-curl.c by dropping 'const'.
Signed-off-by: Marat Radchenko
---
http-fetch.c | 5 +++--
remote-curl.c | 2 +-
2 files chan
Differences with v1:
- Dropped "MINGW: compat/bswap.h: include stdint.h", it isn't needed after
"MINGW: git-compat-util.h: use inttypes.h for printf macros"
- Split "MINGW: config.mak.uname allow using CURL for non-msysGit builds"
into "MINGW: config.mak.uname: allow using cURL for non-msys
Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h.
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index e033e72..262b300 100644
--- a/compat/mingw.h
+++ b/compat/mi
To ease cross-compilation process, introduce a single variable
with the prefix to all compiler-related executables.
Define CROSS_COMPILE=foo- if your compiler and binary utilities
are foo-cc, foo-ar, foo-strip, etc. More specific variables
override this, so if you set CC=gcc CROSS_COMPILE=ia64-li
Felipe Contreras writes:
> Contributors don't have any responsibility to champion their patches.
> It is pro bono work.
No, that's just the appearance that should be upheld in the higher
society. It's ok to get paid for work on Git as long as you don't
mention it in public. It's also ok to get
James Denholm wrote:
> You cannot expect that anybody but yourself is willing to propose,
> debate the merits of and otherwise defend patches that you have
> authored (herein "your patches", implying authorship, not
> ownership).
This is the original comment:
> David Kastrup wrote:
> > It become
- Ursprungligt meddelande -
> Från: "Felipe Contreras"
> Till: "James Denholm" , "Felipe Contreras"
>
> Kopia: "David Kastrup" , "Jeremy Morton"
> , "Johan Herland" ,
> "Git mailing list"
> Skickat: tisdag, 29 apr 2014 5:32:29
> Ämne: Re: Recording the current branch on each commit?
Marat Radchenko wrote:
> We need to make a decision: drop nedalloc, update nedalloc to later release,
> patch nedalloc to make it work under MinGW-W64 or disable nedalloc under
> MinGW-W64 (still leaving it enabled under MinGW).
I say go for the latter (disable for mingw-264). It can be fixed lat
Jeff King wrote:
> [1] I do not know about others, but I typically cut and paste from
> another terminal, and use the following alias in my config:
>
> [alias]
> ll = "!git --no-pager log -1 --pretty='tformat:%h (%s, %ad)'
> --date=short"
I have:
[alias]
short = show --quie
On Mon, Apr 28, 2014 at 05:23:25PM +0200, Erik Faye-Lund wrote:
> On Mon, Apr 28, 2014 at 3:51 PM, Marat Radchenko
> wrote:
> > nedalloc was initially added in f0ed82 to fix slowness of standard WinXP
> > memory allocator. Since WinXP is EOLed, this point is no longer valid.
> >
> > The actual re
On 04/29/2014 05:23 AM, Jeff King wrote:
On Mon, Apr 28, 2014 at 10:49:30PM +0200, Torsten Bögershausen wrote:
OK, thanks for the description.
In theory we can make Git "composition ignoring" by changing
index_file_exists() in name-hash.c.
(Both names must be precomposed first and compared then
Le 29/04/2014 01:34, Junio C Hamano a écrit :
Jean-Noël Avila writes:
Most manuals on git state that it is bad practice to push -f a branch
after have meddled with its history, because this would risk to upset
the repositories of the coworkers. On the other hand, some workflows
use branches to
Add tests for the new feature.
Signed-off-by: Michael S. Tsirkin
---
t/t9001-send-email.sh | 45 +
1 file changed, 45 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 1ecdacb..97cc094 100755
--- a/t/t9001-send-email.sh
++
101 - 156 of 156 matches
Mail list logo
