* [PATCH (update)] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 16:33 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
In-Reply-To: <1232987160-5635-1-git-send-email-ted@tedpavlic.com>
As discussed in
http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
the Mac OS X C standard library is always thread safe and always
includes the pthread library. So explicitly using -pthread causes an
'unrecognized option' compiler warning.
This patch clears PTHREAD_LIBS by default. However, if
FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
before.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This update adds the documentation comment in the Makefile to
configure.ac as well.
Makefile | 11 +++++++++++
configure.ac | 8 ++++++++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..86f0a66 100644
--- a/Makefile
+++ b/Makefile
@@ -70,6 +70,14 @@ all::
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+# Define FORCE_DARWIN_PTHREAD_LIBS if you are building on Darwin/Mac OS
+# X and want PTHREAD_LIBS to be set. On Mac OS X, all components of the
+# C standard library that are defined to be thread safe by the POSIX
+# standard already include the pthread library. Hence, the -pthread
+# option is redundant and will generate an 'unrecognized option'
+# warning. So PTHREAD_LIBS will be cleared unless
+# FORCE_DARWIN_PTHREAD_LIBS is set.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -817,6 +825,9 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+ ifndef FORCE_DARWIN_PTHREAD_LIBS
+ PTHREAD_LIBS =
+ endif
endif
ifndef CC_LD_DYNPATH
diff --git a/configure.ac b/configure.ac
index 082a03d..a53d97c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -578,6 +578,14 @@ GIT_PARSE_WITH(expat))
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+# Define FORCE_DARWIN_PTHREAD_LIBS if you are building on Darwin/Mac OS
+# X and want PTHREAD_LIBS to be set. On Mac OS X, all components of the
+# C standard library that are defined to be thread safe by the POSIX
+# standard already include the pthread library. Hence, the -pthread
+# option is redundant and will generate an 'unrecognized option'
+# warning. So PTHREAD_LIBS will be cleared unless
+# FORCE_DARWIN_PTHREAD_LIBS is set.
+#
# Define NO_MMAP if you want to avoid mmap.
#
# Define NO_ICONV if your libc does not properly support iconv.
--
1.6.1.213.g28da8
^ permalink raw reply related
* [PATCH v2] Allow format-patch to create patches for merges
From: Nathan W. Panike @ 2009-01-26 16:43 UTC (permalink / raw)
To: git; +Cc: Nathan W. Panike
In-Reply-To: <d77df1110901260827j2200fe41oe1b84c387d88aba () mail ! gmail ! com>
The behavior for git format-patch is to ignore merge commits, producing an
empty patch. The code does not allow the user to change this behavior. This
patch changes that behavior by allowing the user to specify -c or -m at the
command line to produce a patch for a merge commit.
Signed-off-by: Nathan W. Panike <nathan.panike@gmail.com>
---
Add Sign off.
This seems to solve my problem, but maybe my workflow is sufficiently different
that it is a problem no one else has. Maybe someone can point me in a direction
that solves problems more users have.
Thanks,
Nathan Panike
builtin-log.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 2ae39af..ea4729d 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -994,10 +994,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
continue;
}
- /* ignore merges */
- if (commit->parents && commit->parents->next)
- continue;
-
if (ignore_if_in_upstream &&
has_commit_patch_id(commit, &ids))
continue;
--
1.6.1.1.GIT
^ permalink raw reply related
* Re: Hosting from Windows XP.
From: Johannes Schindelin @ 2009-01-26 16:45 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0901260827ge5e4b29w871b345da2373f6b@mail.gmail.com>
Hi,
On Mon, 26 Jan 2009, Tim Visher wrote:
> I may totally be missing something here, but I don't know what. Short
> of the question is, how do I host a repo out of Windows?
Use a net share. Use the native permission system to restrict/open up the
repository for certain people to read from/write to.
Ciao,
Dscho
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Marc Branchaud @ 2009-01-26 16:10 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Stephen Haberman, spearce, Thomas Rast,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242056070.14855@racer>
Johannes Schindelin wrote:
>
> - $sha1'
>
> for merge and goto, if a $sha1 ends in a single quote, the
> rewritten commit is substituted (if there is one)
I find this notation fairly unintuitive. I'm more inclined to let users
specify their own names for important parts of the rebase.
I guess that's what Junio's 'mark' command is for, but not having seen a
proper explanation of 'mark', I suggest instead a more inline method: an
'as' keyword. Any command in a todo script can be followed (on the same
line, before the SHA1 value) with 'as <name>' allowing <name> to appear
later in the script to refer to the result of the earlier command.
So the script in the example becomes
pick as start A
pick C
pick as bottom D
goto start
pick B
merge bottom was E
I find that much easier to understand. Especially when real SHA1 values
are floating around everywhere, I think this notation will help users
get things right.
This approach also allows a commit name "A" to consistently refer to the
original commit, which I think also makes things easier for users.
M.
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Jakub Narebski @ 2009-01-26 17:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tim Visher, git
In-Reply-To: <20090126163124.GA31810@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Tim Visher <tim.visher@gmail.com> wrote:
> > I'm trying to get git set up for my company. We're stuck using
> > Windows for the foreseeable future so for now I have to host the
> > central integration repository out of a Windows box. I figured the
> > easiest way to do this, short of installing cygwin, would be to do a
> > simple msysgit install and then run git daemon with the relevant repo
> > copied over onto the server. Then devs could track that repo.
> > However, it appears that msysgit does not install git daemon.
>
> git-daemon isn't ported yet, due to its heavy reliance on POSIX
> behavior during fork+exec.
You can use instead "dumb" HTTP protocol, or network filesystem
(network share). Or SSH.
Note that for push you don't [usually] use git-daemon: you can use
SSH, filesystem (network share), HTTPS with WebDAV.
> > I may totally be missing something here, but I don't know what. Short
> > of the question is, how do I host a repo out of Windows?
>
> I think your options are limited to:
[...]
> - Use JGit and its daemon
>From what I remember currently JGit daemon generates suboptimal
packfiles, as it does not support delta compression yet...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Shawn O. Pearce @ 2009-01-26 17:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tim Visher, git
In-Reply-To: <m3bptux984.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > - Use JGit and its daemon
>
> From what I remember currently JGit daemon generates suboptimal
> packfiles, as it does not support delta compression yet...
Yes.
It does however support delta-reuse, and it only supports the
index-pack variant during receive-pack. So it saves and reuses
any deltas created by C git. Which makes it almost tolerable to
work with as a bit server.
--
Shawn.
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Tay Ray Chuan @ 2009-01-26 17:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tim Visher, git
In-Reply-To: <alpine.DEB.1.00.0901261744240.25749@intel-tinevez-2-302>
Hi,
On Tue, Jan 27, 2009 at 12:45 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Use a net share. Use the native permission system to restrict/open up the
> repository for certain people to read from/write to.
hmm, does this entail git daemon usage too?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Peter Simons @ 2009-01-26 17:46 UTC (permalink / raw)
To: git
In-Reply-To: <808woyz2k7.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
>> Other modes, such as message-mode, do support that kind of thing
>> correctly, so apparently it is possible to configure what the
>> editor considers as a paragraph. Is there some Emacs wizard out
>> there who'd be kind enough to improve git-mode accordingly?
>
> I suspect this doesn't directly relate to git-mode. What mode
> does emacs say you're in at this point? I'm guessing the buffer
> name is COMMIT_EDITMSG and the mode is fundamental-mode?
The buffer is in "log-edit" mode.
> In that case you could stick this in your .emacs if you wanted to
> use message-mode:
>
> (setq auto-mode-alist (cons '("COMMIT_EDITMSG" . message-mode) auto-mode-alist))
Unfortunately, it's not that easy. I'm not an Emacs expert, but I'd
assume that switching into a different mode would change the meaning
of C-c C-c.
Peter
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Tay Ray Chuan @ 2009-01-26 17:46 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0901260827ge5e4b29w871b345da2373f6b@mail.gmail.com>
Hi,
On Tue, Jan 27, 2009 at 12:27 AM, Tim Visher <tim.visher@gmail.com> wrote:
> Hello Everyone,
>
> I'm trying to get git set up for my company. We're stuck using
> Windows for the foreseeable future so for now I have to host the
> central integration repository out of a Windows box. I figured the
> easiest way to do this, short of installing cygwin, would be to do a
> simple msysgit install and then run git daemon with the relevant repo
> copied over onto the server. Then devs could track that repo.
> However, it appears that msysgit does not install git daemon.
you might want to look at using pushing over DAV: say, have all your
employees pulling from a DAV-enabled server.
The DAV protocol itself is platform-agnostic, so your server could be
Windows or Linux or whatever. Since DAV deals with file I/O, you might
want to look at your security options, though I think basic access
authentication would be enough if your server is only accessible
within your company's LAN.
By pushing over DAV, you can avoid running a git daemon. Looking at
how you would do this on Windows, i don't think it's advisable to do
so.
To do this, first, you would need to have cygwin, then you have to run
"cygrunsrv -I", which will install your git daemon as a Windows
service.
AFAIK, cygrunsrv pipes stuff to git-daemon. I don't know how good this
option is, reliablity or performance-wise.
I've tried this out (somewhat limitedly) using git built on cygwin,
with an Apache server, though currently you would have problems if
your Apache was running on a Windows box (my patch to fix this is on
its way).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Shawn O. Pearce @ 2009-01-26 17:46 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Johannes Schindelin, Tim Visher, git
In-Reply-To: <be6fef0d0901260944l7e128588xc560810515e5f941@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Tue, Jan 27, 2009 at 12:45 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Use a net share. Use the native permission system to restrict/open up the
> > repository for certain people to read from/write to.
>
> hmm, does this entail git daemon usage too?
No, developers would be accessing the repository directly over SMB.
Its slower than if you used git daemon. Access over SMB is
tolerable, especially if your network is fast, but there's still a
lot more data transfer then if the native git protocol could be used.
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #06; Sat, 24)
From: Junio C Hamano @ 2009-01-26 17:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Steffen Prohaska
In-Reply-To: <497D6BA7.4070409@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> * sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 7 commits
>> - Windows: Revert to default paths and convert them by
>> RUNTIME_PREFIX
>> - Compute prefix at runtime if RUNTIME_PREFIX is set
>> - Modify setup_path() to only add git_exec_path() to PATH
>> - Add calls to git_extract_argv0_path() in programs that call
>> git_config_*
>> - git_extract_argv0_path(): Move check for valid argv0 from caller
>> to callee
>> - Refactor git_set_argv0_path() to git_extract_argv0_path()
>> - Move computation of absolute paths from Makefile to runtime (in
>> preparation for RUNTIME_PREFIX)
>>
>> We should move this to 'next' soon with J6t's blessing.
>
> I've been using this series for a few days now without problems:
>
> Acked-by: Johannes Sixt <j6t@kdbg.org>
Thanks. I take that as not just "have been using this and no breakage
observed" but also "of course the patches themselves make sense to me".
^ permalink raw reply
* Re: [PATCH (update)] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Junio C Hamano @ 2009-01-26 17:47 UTC (permalink / raw)
To: Ted Pavlic; +Cc: gitster, git
In-Reply-To: <1232987609-6229-1-git-send-email-ted@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> As discussed in
>
> http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
>
> the Mac OS X C standard library is always thread safe and always
> includes the pthread library. So explicitly using -pthread causes an
> 'unrecognized option' compiler warning.
>
> This patch clears PTHREAD_LIBS by default. However, if
> FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
> before.
Why is this even configurable? You explained pretty clearly that:
- With -pthread, you get an nasty warning;
- By default, we now do not use -pthread;
- By adding FORCE_DARWIN_PTHREAD_LIBS, you can still compile with
-pthread.
But the above leaves the reader wondering in what situation it may be
useful to use FORCE_* and for what purpose other than to get the nasty
warning back (which probably is not most users want to).
^ permalink raw reply
* Re: [PATCH] Allow format-patch to create patches for merges
From: Junio C Hamano @ 2009-01-26 18:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nathan W. Panike, git, aspotashev
In-Reply-To: <alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302>
[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> - lack an explanation when this makes sense (format-patch is commonly used
> for mail-based patch queues, and only -m 1 would make sense there, and
> only if you run format-patch with --first-parent),
You do not necessarily want --first-parent.
Suppose you have this topology
B---D---E
/ /
M---A---C
where M is 'master', and E is 'mine'.
The format-patch command ignores merges by default because you can get
diff for A-M, B-A, C-A, E-D and serialize the resulting history without
it, and this is often sufficient. When D merges with a conflict, or D is
an evil merge, however, you will not be able to reproduce how D looked
like on the receiving end. Your --first-parent would instead format the
log message for A B D E with patch text of A-M, B-A, D-B and E-D.
But as a recipient of such a patch series, I'd much prefer to see the
patch text and the log message of B and C themselves. I'd either apply
them on top of A serially, or apply them on top of A to recreate the
forked history the sender had and merge, to arrive at the state the sender
had at D either way, resolving a potential conflict (either when applying
C on top of B, or when merging between B and C), and apply E on top.
Getting a first parent diff that says "I merged random stuff here at D and
here is the difference D-B", is much less useful and throws us back to
dark ages of CVS/SVN merges, especially because C could be a long
multi-patch sequence.
I am not happy about Nathan's output. I think "-m" output is a wrong
thing to use in that it just lets D-B and D-C patches in the same output
file, without marking that it is something you should not be applying as
part of the series blindly. The patch is "If you reproduced my B and C
with the patches so far, here is a hint to help you recreate the merged
state D", and care must be taken to make sure both the tool and the user
notice the situation. "git am", after you have applied B and then C, will
notice that the patches for D does not apply anyway, but the message
should tell the recipient that it is _expected_ not to apply to avoid
confusion. One possible solution might be to always show --cc patch in
such a case, which (1) won't apply with patch nor git-am, and (2) will be
clear it is not a patch by having more than two @@ signs on each hunk
header.
If you really want to generate a patch for a merge commit (e.g. D in the
above picture), what you may want is "here is a fix-up you need to apply
on top of the result of naturally merging B and C to arrive at D". It
could be empty if the merge is conflict-free and there is no evil amend.
Here is a food-for-thought sample history for interested parties to
experiment on.
[-- Attachment #2: a bundle out of a sample repo --]
[-- Type: application/octet-stream, Size: 2036 bytes --]
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Johannes Gilger @ 2009-01-26 18:35 UTC (permalink / raw)
To: git
In-Reply-To: <c115fd3c0901260827ge5e4b29w871b345da2373f6b@mail.gmail.com>
On 2009-01-26, Tim Visher <tim.visher@gmail.com> wrote:
> easiest way to do this, short of installing cygwin, would be to do a
I know you said "short of installing cygwin", but I'd like to ask you if
you have ever used CygWin. I'd suggest you give it a try first (if you
haven't already) because it would then enable you to use a wide range of
tools from the unix-world without a lot of hassle. git, for example, can
be downloaded and compiled out-of-the-box, meaning the git-daemon as
well. You even get an ssh-server with cygwin (on windows, how cool is
that ;).
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Common ancestor in merge diffs?
From: Daniel Barkalow @ 2009-01-26 18:41 UTC (permalink / raw)
To: git
I was just doing an annoying merge (I'd reorganized code while other
people made changes to it), and I kept having the problem that it was hard
to figure out what each side had done. Is there some way to ask git for
the diffs between the common ancestor (which is unique in my case, so it's
actually useful) and each of the sides of the merge? Ideally, it would
give essentially the converse of the --cc diff: first column is -stage 1
+stage 2; second column is -stage 1 +stage 3.
I think this would generally be more useful than the current diff output
for the unresolved portions (-stage 3 +working tree, -stage 2 +working
tree) because you're generally quite familiar with the working tree (since
you're trying to resolve there), and stage 1 is not obvious.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-26 18:48 UTC (permalink / raw)
To: Jay Soffian; +Cc: Johannes Schindelin, Keith Cascio, Junio C Hamano, git
In-Reply-To: <76718490901260729m21ba140dke157d1d461aed2d5@mail.gmail.com>
On Mon, Jan 26, 2009 at 10:29:17AM -0500, Jay Soffian wrote:
> Aside, AIX has commands that are run both directly or via smit (a
> curses-based interface). When smit calls the commands, it passes a
> switch to let said commands know that they are being run from smit.
> e.g.:
>
> -J
> This flag is used when the installp command is executed from the
> System Management Interface Tool (SMIT) menus.
>
> Perhaps adding such a concept to those git commands which can be used
> in both porcelain and plumbing contexts would be useful for git.
Sure, I think that is one of many possible ways that we could
differentiate between confusing plumbing and porcelain; another is
splitting functionality into two similar commands, one of which is
plumbing and one of which is porcelain.
The real problem with plans like that, though, is that there are
_already_ scripts in the wild that don't understand "-J" (or whatever).
My impression from your description above is that "-J" means "don't use
fancy features, because we're being called from the menus". And you
really want the opposite, which is that scripts opt _in_ to fancy
features, not _out_.
But then you have that problem that the _user_ is stuck specifying "OK,
turn on fancy features." And I don't relish the thought of typing "git
diff -J" every time. :)
-Peff
^ permalink raw reply
* Re: [PATCH (update)] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr62q6jtp.fsf@gitster.siamese.dyndns.org>
...
>> This patch clears PTHREAD_LIBS by default. However, if
>> FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
>> before.
>
> Why is this even configurable? You explained pretty clearly that:
...
> But the above leaves the reader wondering in what situation it may be
> useful to use FORCE_* and for what purpose other than to get the nasty
> warning back (which probably is not most users want to).
I was afraid that there would be some strange situation where someone
would have a configuration where they might want pthreads turned on. I
suppose that if someone is in that specialized situation, they will be
able to customize their build environment on their own.
I will submit a new patch without the define.
Thanks --
Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Johannes Schindelin @ 2009-01-26 18:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901261318030.19665@iabervon.org>
Hi,
On Mon, 26 Jan 2009, Daniel Barkalow wrote:
> I was just doing an annoying merge (I'd reorganized code while other
> people made changes to it), and I kept having the problem that it was hard
> to figure out what each side had done. Is there some way to ask git for
> the diffs between the common ancestor (which is unique in my case, so it's
> actually useful) and each of the sides of the merge?
How about
git diff HEAD...MERGE_HEAD
and
git diff MERGE_HEAD...HEAD
? I might have misunderstood, though.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-bundle(1): add no references required simplest case
From: jidanni @ 2009-01-26 19:02 UTC (permalink / raw)
To: mdl123, gitster; +Cc: spearce, git
In-Reply-To: <87zlirc49l.fsf@jidanni.org>
Signed-off-by: jidanni <jidanni@jidanni.org>
---
See http://article.gmane.org/gmane.comp.version-control.git/103576
Documentation/git-bundle.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..7c1e990 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -164,6 +164,13 @@ $ git pull bundle
would treat it as if it is talking with a remote side over the
network.
+If a bundle requires no references, one may simply use:
+
+------------
+$ git init
+$ git pull bundle.bdl master
+------------
+
Author
------
Written by Mark Levedahl <mdl123@verizon.net>
--
1.6.0.6
^ permalink raw reply related
* [PATCH] make: Remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 19:03 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
In-Reply-To: <497E079C.7090303@tedpavlic.com>
As discussed in
http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
the Mac OS X C standard library is always thread safe and always
includes the pthread library. So explicitly using -pthread causes an
'unrecognized option' compiler warning.
This patch clears PTHREAD_LIBS if Darwin is detected.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
Rather than simply clearing PTHREAD_LIBS, would it be better to filter
PTHREAD_LIBS to remove "-pthread" if detected?
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..9d451cf 100644
--- a/Makefile
+++ b/Makefile
@@ -817,6 +817,7 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+ PTHREAD_LIBS =
endif
ifndef CC_LD_DYNPATH
--
1.6.1.213.g28da8
^ permalink raw reply related
* Re: Common ancestor in merge diffs?
From: Linus Torvalds @ 2009-01-26 19:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901261318030.19665@iabervon.org>
On Mon, 26 Jan 2009, Daniel Barkalow wrote:
>
> I was just doing an annoying merge (I'd reorganized code while other
> people made changes to it), and I kept having the problem that it was hard
> to figure out what each side had done. Is there some way to ask git for
> the diffs between the common ancestor (which is unique in my case, so it's
> actually useful) and each of the sides of the merge? Ideally, it would
> give essentially the converse of the --cc diff: first column is -stage 1
> +stage 2; second column is -stage 1 +stage 3.
Have you tried "gitk --merge [filename]"?
That's usually even more useful - because it doesn't just give a diff, it
gives the actual commits that caused the conflict. That way you see what
both sides of a merge tried to do.. It's what I do when encountering
conflicts on the kernel (where I'm usually not the author of _either_ side
of the code that causes a conflict), and it really is very powerful.
That said, finding the diffs from the common case is pretty trivial too.
Just do
git diff MERGE_HEAD...HEAD [filename]
and you'll get the diff from the common case to the HEAD, and if you
switch them around, you'll get the diff from the common commit to the
MERGE_HEAD. Note the _three_ dots.
Linus
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Daniel Barkalow @ 2009-01-26 19:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901261958320.25749@intel-tinevez-2-302>
On Mon, 26 Jan 2009, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 26 Jan 2009, Daniel Barkalow wrote:
>
> > I was just doing an annoying merge (I'd reorganized code while other
> > people made changes to it), and I kept having the problem that it was hard
> > to figure out what each side had done. Is there some way to ask git for
> > the diffs between the common ancestor (which is unique in my case, so it's
> > actually useful) and each of the sides of the merge?
>
> How about
>
> git diff HEAD...MERGE_HEAD
>
> and
>
> git diff MERGE_HEAD...HEAD
>
> ? I might have misunderstood, though.
That's definitely helpful information (and I'd forgotten about it; I was
only thinking of the index). It would be helpful to get it in --cc form,
though, rather than as two independant diffs. And it seems somewhat
wasteful or something to not use the information in the index, although
it's hard to get worked up about with git being blindingly fast anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Bruce Stephens @ 2009-01-26 19:11 UTC (permalink / raw)
To: Peter Simons; +Cc: git
In-Reply-To: <87mydet0yg.fsf@write-only.cryp.to>
Peter Simons <simons@cryp.to> writes:
[...]
> The buffer is in "log-edit" mode.
Ah, OK. That makes sense.
> > In that case you could stick this in your .emacs if you wanted to
> > use message-mode:
> >
> > (setq auto-mode-alist (cons '("COMMIT_EDITMSG" . message-mode) auto-mode-alist))
>
> Unfortunately, it's not that easy.
True. I don't use git-mode (well, not much). I use git commit from
the command line, which runs emacsclient as its editor.
> I'm not an Emacs expert, but I'd assume that switching into a
> different mode would change the meaning of C-c C-c.
Yep. Quite likely other things, too.
OK, something like this:
(add-hook 'log-edit-mode-hook (lambda ()
(let ((regexp "--text follows this line--$\\|[ ]*$\\|-- $\\|---+$\\|^\f$\\|.*wrote:$\\|\\(\\([ ]*[-_.[:word:]]+>+\\|[ ]*[]>|}+]\\)+\\)[ ]*$\\|<#!*/?\\(multipart\\|part\\|external\\|mml\\|secure\\)"))
(setq paragraph-start regexp
paragraph-separate regexp)))
I copied the regexp from the value in message-mode. (In a junk buffer
use M-x message-mode, then C-h v paragraph-start and copy & paste.)
I imagine large parts of the regexp aren't relevant for your purposes
so you could remove them if you wanted. You might also define a
function rather than using lambda---that would make it a bit easier to
test.
^ permalink raw reply
* Re: [PATCH 2/3] Make has_commit non-static
From: Jake Goulding @ 2009-01-26 19:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901261637300.25749@intel-tinevez-2-302>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 26 Jan 2009, Jake Goulding wrote:
>
>> Moving has_commit from branch to a common location in preparation for
>> using it in tag. Renaming it to commit_has_any_in_commit_list to be more
>> unique.
>
> I feel like bike-shedding for a change, and I'd also like to prove that
> not all Germans like long names:
>
> is_ancestor_of_any()
>
> Hmm?
I assume that this means that the rest of the code/logic is fine? :-D
I'll change this (I don't have any attachment to one name or the other),
then it should be good to go!
-Jake
^ permalink raw reply
* Using the "What's cooking" scripts outside of Git
From: R. Tyler Ballance @ 2009-01-26 19:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
I was toying around with the idea of generating a "What's cooking" email
similar to Junio's for our internal development, and I'm wondering if
anybody has any experience using the scripts outside of the standard Git
repository.
Our repo is laid out slightly different, there's no "next" branch but
there are a number of "in development" branches that get folded down
into master.
Any tips would be appreciated
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox