* Makefile checks for DarwinPorts / Fink
From: Stefan Pfetzing @ 2006-07-21 14:58 UTC (permalink / raw)
To: Git Mailing List
Hi,
while I was updating the DarwinPorts Portfile for git, I saw some
really suspicious lines in the Makefile of Git for DarwinPorts/Fink.
--- snip ---
## fink
ifeq ($(shell test -d /sw/lib && echo y),y)
ALL_CFLAGS += -I/sw/include
ALL_LDFLAGS += -L/sw/lib
endif
## darwinports
ifeq ($(shell test -d /opt/local/lib && echo y),y)
ALL_CFLAGS += -I/opt/local/include
ALL_LDFLAGS += -L/opt/local/lib
endif
--- snap ---
IMHO, Git should definetely not include /sw/include and /sw/lib, just
if it *exists*.
Think of a situation, when somebody has Fink and DarwinPorts installed
on one machine (possible). Then if you would build Git from
DarwinPorts, the git Makefile would link against Fink libraries! IMHO
the DarwinPorts / Fink build process should set LDFLAGS and CFLAGS
accordingly.
Also, maybe you want to create a DarwinPorts / Fink independent Mac OS
X pkg which contains Git and its deps.
I know this just appends to CFLAGS/LDFLAGS, but if for example
DarwinPorts has broken build-deps, then the Fink stuff would get
sucked in, and you would not notice. (on a box with both, DP and Fink
installed)
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ permalink raw reply
* Re: Git BOF notes
From: Alex Riesen @ 2006-07-21 15:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: J. Bruce Fields, git
In-Reply-To: <20060721143115.GN13776@pasky.or.cz>
On 7/21/06, Petr Baudis <pasky@suse.cz> wrote:
> I don't know if there's a point in being so paranoid - it already makes
> things more painful than necessary. In the tracking branch, you just
> want to have what the other side has anyway, and if the other side
> decided to jump around, why would you care otherwise?
But for the ones who do care, it is much harder to notice. Even if it is
a warning (it gets lost in crontab logs).
^ permalink raw reply
* [RTLWS8-CFP] Eighth Real-Time Linux Workshop 2nd CFP
From: mcguire @ 2006-07-21 21:34 UTC (permalink / raw)
To: nag, alina12004, mail, mail, market, market, sales01, sales01,
git, david, git, rsync-bugs, vas-agu, vas-agu, igor, lena, web,
anna, vlad, web, dashulya, dashulya, newavrora, newavrora,
webmaster, webmaster, newavrora, senat50, newavrora, senat50,
anneke94, anneke94, babenkot
We apologize for multiple receipts.
--------------------------------------------------------------------------------
Eighth Real-Time Linux Workshop
October 12-15, 2006
Lanzhou University - SISE
Tianshui South Road 222
Lanzhou, Gansu 730000
P.R.China
General
Following the meetings of developers and users at the previous 7
successful real-time Linux workshops held in Vienna, Orlando, Milano,
Boston, and Valencia, Singapore, Lille, the Real-Time Linux Workshop
for 2006 will come back to Asia again, to be held at the School for
Information Science and Engineering, Lanzhou University, in Lanzhou
China.
Embedded and real-time Linux is rapidly gaining traction in the Asia
Pacific region. Embedded systems in both automation/control and
entertainment moving to 32/64bit systems, opening the door for the use
of full featured OS like GNU/Linux on COTS based systems. With
real-time capabilities being a common demand for embedded systems the
soft and hard real-time variants are an important extension to the
versatile GNU/Linux GPOS.
Authors are invited to submit original work dealing with general
topics related to real-time Linux research, experiments and case
studies, as well as issues of integration of real-time and embedded
Linux. A special focus will be on industrial case studies. Topics of
interest include, but are not limited to:
* Modifications and variants of the GNU/Linux operating system
extending its real-time capabilities,
* Contributions to real-time Linux variants, drivers and extensions,
* User-mode real-time concepts, implementation and experience,
* Real-time Linux applications, in academia, research and industry,
* Work in progress reports, covering recent developments,
* Educational material on real-time Linux,
* Tools for embedding Linux or real-time Linux and embedded
real-time Linux applications,
* RTOS core concepts, RT-safe synchronization mechanisms,
* RT-safe interaction of RT and non RT components,
* IPC mechanisms in RTOS,
* Analysis and Benchmarking methods and results of
real-time GNU/Linux variants,
* Debugging techniques and tools, both for code and temporal
debugging of core RTOS components, drivers and real-time
applications,
* Real-time related extensions to development environments.
Further information:
EN: http://www.realtimelinuxfoundation.org/events/rtlws-2006/ws.html
CN: http://dslab.lzu.edu.cn/rtlws8/index.html
Awarded papers
The Programme Committee will award a best paper in the category Real-
Time Systems Theory. This best paper will be invited for publication
to the Real-Time Systems Journal, RTSJ.
The Programme Committee will award a best paper in the category Real-
Time Systems Application. This best paper will be invited for publication
to the Dr Dobbs Journal. Moreover, the publication of the other papers in
a special issue of Dr Dobbs Journal is in discussion.
Abstract submission
In order register an abstract, please go to:
http://www.realtimelinuxfoundation.org/rtlf/register-abstract.html
Venue
Lanzhou University Information Building, School of Information Science
and Engineering, Laznhou University, http://www.lzu.edu.cn/.
Registration
In order to participate to the workshop, please register on the
registration page at:
http://www.realtimelinuxfoundation.org/rtlf/register-participant.html
Accommodation
Please refer to the Lanzhou hotel page for accomodation at
http://dslab.lzu.edu.cn/rtlws8/hotels/hotels.htm
Travel information
For travel information and directions how to get to Lanzhou from an
international airport in China please refer to:
http://www.realtimelinuxfoundation.org/events/rtlws-2006/
Important dates
August 28: Abstract submission
September 15: Notification of acceptance
September 29: Final paper
Pannel Participants:
o Roberto Bucher - Scuola Universitaria Professionale della Svizzera
Italiana, Switzerland, RTAI/ADEOS/RTAI-Lab.
o Alfons Crespo Lorente - University of Valenica, Spain,Departament
d'Informtica de Sistemes i Computadors, XtratuM.
o Herman Haertig - Technical University Dresden, Germany,Institute for
System Architecture, L4/Fiasco/L4Linux.
o Nicholas Mc Guire - Lanzhou University, P.R. China, Distributed and
Embedded Systems Lab, RTLinux/GPL.
o Douglas Niehaus - University of Kansas, USA, Information and
Telecommunication Technology Center, RT-preempt.
Organization committee:
* Prof. Li LIAN (Co-Chair), (SISE, Lanzhou University, CHINA)
* Xiaoping ZHANG, LZU, CHINA
* Jiming WANG, PKU, CHINA
* Zhibing LI, ECNU, China
* Prof. Nicholas MCGUIRE (Co-Chair), Real Time Linux Foundation
(RTLF)
* Dr. Peter WURMSDOBLER, Real Time Linux Foundation (RTLF)
* Dr. Qingguo ZHOU, (Distributed and Embedded Systems Lab, Lanzhou
University, CHINA)
Program committee:
* Prof. Li Xing (Co-Chair), (Tsinghua University, CHINA)
* Dr. Zhang Yunquan, (Institute of Software, Chinese Academy of
Science, CHINA)
* Dr. Chen Yu, (Tsinghua University, CHINA)
* Dr. Chen Maoke, (Tsinghua University, CHINA)
* Dr. Yu Guanghui, (Dalian University of Techonolgy, CHINA)
* Prof. Dr. Paolo Mantegazza, (Dipartimento di Ingegneria
Aerospaziale, ITALY)
* Prof. Dr. Bernhard Zagar, (Johannes Kepler Universitt Linz,
AUSTRIA)
* Prof. Dr. Hermann Hrtig, (Technische Universitt Dresden,
Fakultt Informatik, GERMANY)
* Prof. Tei-Wei Kuo, (National Taiwan University, Department of
Computer Science and Information Engineering,TAIWAN)
* Anthony Skjellum, (Mississippi State University, USA)
* Ing. Pavel Pisa, (Czech Technical University, CZECH REPUBLIC)
* Prof. Alfons Crespo, (Universidad Politcnica de Valencia, SPAIN)
* Dr. Qingguo Zhou, (Lanzhou University, CHINA)
* PhD. Jaesoon Choi, (National Cancer Center, KOREA)
* Prof. Douglas Niehaus, (Kansas University, USA)
* Dr. Michael Hohmuth, (Technische Universitt Dresden, GERMANY)
* Prof. Thambipillai Srikanthan, (Nanyang Technological University,
SINGAPORE)
* Zhengting He, (University of Texas, USA)
* Martin Terbuc, (Universitz of Maribor, SLOVENIA)
* Yoshinori Sato, (the H8/300 project, JAPAN)
* Yuqing Lan, (China Standard SoftwareCo.,LTD, CHINA)
* Dr. Peter Wurmsdobler, (Real Time Linux Foundation, USA)
* Prof. Nicholas Mc Guire (Co-Chair), (Lanzhou University, CHINA)
Workshop organizers:
* School for Information Science and Engineering (SISE) , Lanzhou
University , CHINA
* IBM China, Xi'an Branch , China
* Haag Embedded Systems, Austira
Peter Wurmsdobler <peter@wurmsdobler.org>
Nicholas Mc Guire <mcguire@lzu.edu.cn>
Zhou Qingguo <zhouqg@lzu.edu.cn>
^ permalink raw reply
* Order status, olive tubercle
From: Lacey Nicholas @ 2006-07-21 19:19 UTC (permalink / raw)
To: git-commits-head-owner
Genuine Swiss made RoleVx repilcas are as close to the real thing
as a repilca watch can be. Sometimes even the professional jewelers
are unable to tell the difference from the real RoleBx watch.
Why spend thousands of dollars on the real deal when
a repilca watch looks so much alike that only an expert could tell the difference...
And you only pay a fractoin of the price.
VISIT US, AND GET OUR SPECIL 370% DISSCOUNT OFER!
http://1W43PPGiy5b5joq666t1iiyni0y5ii0.madwortmj.com/
=====
meant! He stood on the sand and fell to wondering if there was a gull back
gentle way. I just got up, brushed myself off, and looked around. There were
bright as theirs. True, the same young Jonathan Seagull was there that had
is we've brought back."
"Yes. Once in a while I read the Reports. "
over at me, jaws clenched, teeth bared. motioned for him to be still. God,
they couldn't understand, but then he had some good ones that they could.
Borscht to put a drop or two of the stiff stuff into my system. I was just
^ permalink raw reply
* Better Life, well-served
From: Buford Munson @ 2006-07-21 20:12 UTC (permalink / raw)
To: git-commits-head-owner
Your cre dit doesn't matter to us! If you OWN real est ate
and want IMMEDIATEW cash to spend ANY way you like, or simply wish
to LOWER your monthly paym ents by a third or more, here are the dea ls
we have TODAY (hurry, these ofers will expre TONIGHT):
$488,000.00 at a 3.67,% fixed-rateP
$372,000.00 at a 3.90,% variable-rate3
$492,000.00 at a 3.21,% interest-onlyX
$248,000.00 at a 3.36,% fixed-rateI
$198,000.00 at a 3.55,% variable-rate6
Hurry, when these deals are gone, they are gone Simply fill out this one-min ute form...
Don't worry about approval, your cre dit will not disqualify you!
http://1GZBDT2.foorests.net
him face down into the deepest puddle and fell down next to him, reliving
fool. How could you have trusted me? You've known me for so long, you should
against Noonan's and said: "We're off, we're off." Then Noonan nodded,
He gulped the rest of the coffee, pulled out a cigarette, and as he
sores--yellow with black dots--and I said "Let me have it." And that was it.
pretty boy. And now that handsome face was a dark gray mask of baked-on
the rounded bristly peaks of the hills. Here and there between the hills
meaning. It had no meaning before, either, but before it was a person at
asking about the cottage--what kind was it, where was it, what did it
out would ooh and aah for five minutes and then go back to their own
but one doesn't necessarily rule out the other. Only I don't get to feel
^ permalink raw reply
* Re: Git BOF notes
From: Johannes Schindelin @ 2006-07-22 0:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060721144249.GO13776@pasky.or.cz>
Hi,
On Fri, 21 Jul 2006, Petr Baudis wrote:
> Yes, there is some blury stuff, but I think it's rather a sign that
> something is missing in the core Git porcelain. git-init-db is lowlevel
> and I think in 99% of the cases you are going to do an initial commit
> right after anyway, so you might as well just get git-init which does it
> for you (something akin cg-init ;).
Think "changed templates". And also think "setup a remote repository",
especially "setup a remote HTTP repository". No, clone will not work if
you are sitting behind a firewall and/or DSL router (and who does not?).
And also think "start a new repository with only a _part_ of the current
files". There are plenty reasons -- in addition to separation of concepts
-- not to commit straight after initializing a repository.
> I think we still tell users to use git-update-index to mark resolved
> conflicts, [...]
I don't know, but I had the impression we'd tell them "resolve your
conflicts, and then do git-commit -a". Which is good enough.
Ciao,
Dscho
^ permalink raw reply
* Re: Git BOF notes
From: Petr Baudis @ 2006-07-22 3:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607220212140.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Fri, 21 Jul 2006, Petr Baudis wrote:
>
> > Yes, there is some blury stuff, but I think it's rather a sign that
> > something is missing in the core Git porcelain. git-init-db is lowlevel
> > and I think in 99% of the cases you are going to do an initial commit
> > right after anyway, so you might as well just get git-init which does it
> > for you (something akin cg-init ;).
>
> Think "changed templates".
it may be that I'm just tired, but I don't see what you mean, sorry.
> And also think "setup a remote repository", especially "setup a remote
> HTTP repository".
Of course. Currently you need to tinker with environment variables,
then with hooks, possibly with permissions and stuff to make the
repository shared... Think cg-admin-setuprepo. ;-)
> And also think "start a new repository with only a _part_ of the current
> files". There are plenty reasons -- in addition to separation of concepts
> -- not to commit straight after initializing a repository.
So what _do_ you do if you don't commit straight?
Of course sometimes you don't want to add everything, and that should
still be possible to do (cg-init has a switch for that).
> > I think we still tell users to use git-update-index to mark resolved
> > conflicts, [...]
>
> I don't know, but I had the impression we'd tell them "resolve your
> conflicts, and then do git-commit -a". Which is good enough.
My comment there was based on the jdl's presentation at OLS. Sorry if
in docs we are saying other things, I don't tend to lookat Git porcelain
documentation. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Git BOF notes
From: Johannes Schindelin @ 2006-07-22 3:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060722032200.GP13776@pasky.or.cz>
Hi,
On Sat, 22 Jul 2006, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > On Fri, 21 Jul 2006, Petr Baudis wrote:
> >
> > > Yes, there is some blury stuff, but I think it's rather a sign that
> > > something is missing in the core Git porcelain. git-init-db is lowlevel
> > > and I think in 99% of the cases you are going to do an initial commit
> > > right after anyway, so you might as well just get git-init which does it
> > > for you (something akin cg-init ;).
> >
> > Think "changed templates".
>
> it may be that I'm just tired, but I don't see what you mean, sorry.
If you change a template (like add a hook or something), you can call
git-init-db in an existing repository to update that hook.
> > And also think "setup a remote repository", especially "setup a remote
> > HTTP repository".
>
> Of course. Currently you need to tinker with environment variables,
> then with hooks, possibly with permissions and stuff to make the
> repository shared... Think cg-admin-setuprepo. ;-)
git-init-db --shared
> > And also think "start a new repository with only a _part_ of the current
> > files". There are plenty reasons -- in addition to separation of concepts
> > -- not to commit straight after initializing a repository.
>
> So what _do_ you do if you don't commit straight?
Sometimes, I do "git-push just@initted.repository.com master". From
somewhere else, of course.
At other times, I do "git-add the-paper.tex && git commit initial".
And sometimes, I do "cp -R /some/where/CVS ./; git-cvsimport".
> Of course sometimes you don't want to add everything, and that should
> still be possible to do (cg-init has a switch for that).
Usually I start small projects as a single .c or .java file. Only after a
while, I think it is worth it to init a git database. So, I _always_ have
generated files lying around. And I would hate it if they were checked in
automatically. (Yeah, I could remove them, _then_ remove them from the
index, and then git-commit --amend. Ugly.)
> > > I think we still tell users to use git-update-index to mark resolved
> > > conflicts, [...]
> >
> > I don't know, but I had the impression we'd tell them "resolve your
> > conflicts, and then do git-commit -a". Which is good enough.
>
> My comment there was based on the jdl's presentation at OLS. Sorry if
> in docs we are saying other things, I don't tend to lookat Git porcelain
> documentation. ;-)
That makes two of us.
Ciao,
Dscho
^ permalink raw reply
* [OT] OLS slides
From: Junio C Hamano @ 2006-07-22 4:45 UTC (permalink / raw)
To: git
My slides (with full transcripts) are available at
http://members.cox.net/junkio/200607-ols.pdf
^ permalink raw reply
* Re: [OT] OLS slides
From: Martin Langhoff @ 2006-07-22 7:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvepqi6x6.fsf@assigned-by-dhcp.cox.net>
On 7/22/06, Junio C Hamano <junkio@cox.net> wrote:
> My slides (with full transcripts) are available at
>
> http://members.cox.net/junkio/200607-ols.pdf
Great slides! Specially 35 to 40 are excellent visualisations of what
happens when you clone, work and later merge.
Can you offer the source of the slides? I think I'll be at CONSOL'06
(Mexican FLOSS conference) in August talking about GIT and Cogito, and
wouldn't mind stealing (in the GNU sense) some bits of yours ;-)
m
^ permalink raw reply
* [PATCH 1/4] git.el: Run git-rerere on commits if the rr-cache directory exists.
From: Alexandre Julliard @ 2006-07-22 13:39 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 34c9950..7371d4b 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -584,6 +584,8 @@ (defun git-do-commit ()
(condition-case nil (delete-file ".git/MERGE_HEAD") (error nil))
(with-current-buffer buffer (erase-buffer))
(git-set-files-state files 'uptodate)
+ (when (file-directory-p ".git/rr-cache")
+ (git-run-command nil nil "rerere"))
(git-refresh-files)
(git-refresh-ewoc-hf git-status)
(message "Committed %s." commit))
--
1.4.2.rc1.ge7a0
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 2/4] git.el: Prepend a slash to the file name when adding to .gitignore.
From: Alexandre Julliard @ 2006-07-22 13:39 UTC (permalink / raw)
To: git
This way the ignore command will really only ignore the marked files
and not files with the same name in subdirectories.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 7371d4b..5837471 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -258,7 +258,7 @@ (defun git-append-to-ignore (file)
(set-buffer (find-file-noselect ignore-name))
(goto-char (point-max))
(unless (zerop (current-column)) (insert "\n"))
- (insert name "\n")
+ (insert "/" name "\n")
(sort-lines nil (point-min) (point-max))
(save-buffer))
(when created
--
1.4.2.rc1.ge7a0
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 3/4] git.el: Try to reuse an existing buffer when running git-status.
From: Alexandre Julliard @ 2006-07-22 13:39 UTC (permalink / raw)
To: git
By default, running git-status again will now reuse an existing buffer
that displays the same directory. The old behavior of always creating
a new buffer can be obtained by customizing the git-reuse-status-buffer
option.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5837471..92cb2b9 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -83,6 +83,12 @@ (defcustom git-append-signed-off-by nil
:group 'git
:type 'boolean)
+(defcustom git-reuse-status-buffer t
+ "Whether `git-status' should try to reuse an existing buffer
+if there is already one that displays the same directory."
+ :group 'git
+ :type 'boolean)
+
(defcustom git-per-dir-ignore-file ".gitignore"
"Name of the per-directory ignore file."
:group 'git
@@ -1003,12 +1009,28 @@ Commands:
(set (make-local-variable 'list-buffers-directory) default-directory)
(run-hooks 'git-status-mode-hook)))
+(defun git-find-status-buffer (dir)
+ "Find the git status buffer handling a specified directory."
+ (let ((list (buffer-list))
+ (fulldir (expand-file-name dir))
+ found)
+ (while (and list (not found))
+ (let ((buffer (car list)))
+ (with-current-buffer buffer
+ (when (and list-buffers-directory
+ (string-equal fulldir (expand-file-name list-buffers-directory))
+ (string-match "\\*git-status\\*$" (buffer-name buffer)))
+ (setq found buffer))))
+ (setq list (cdr list)))
+ found))
+
(defun git-status (dir)
"Entry point into git-status mode."
(interactive "DSelect directory: ")
(setq dir (git-get-top-dir dir))
(if (file-directory-p (concat (file-name-as-directory dir) ".git"))
- (let ((buffer (create-file-buffer (expand-file-name "*git-status*" dir))))
+ (let ((buffer (or (and git-reuse-status-buffer (git-find-status-buffer dir))
+ (create-file-buffer (expand-file-name "*git-status*" dir)))))
(switch-to-buffer buffer)
(cd dir)
(git-status-mode)
--
1.4.2.rc1.ge7a0
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 4/4] git.el: Put the git customize group in the 'tools' parent group.
From: Alexandre Julliard @ 2006-07-22 13:40 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 92cb2b9..68de9be 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -55,7 +55,8 @@ (require 'ewoc)
;;;; ------------------------------------------------------------
(defgroup git nil
- "Git user interface")
+ "A user interface for the git versioning system."
+ :group 'tools)
(defcustom git-committer-name nil
"User name to use for commits.
--
1.4.2.rc1.ge7a0
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: Makefile checks for DarwinPorts / Fink
From: Junio C Hamano @ 2006-07-22 14:43 UTC (permalink / raw)
To: Stefan Pfetzing; +Cc: git, merlyn
In-Reply-To: <f3d7535d0607210758m4410cddfw16329ce473404fd8@mail.gmail.com>
"Stefan Pfetzing" <stefan.pfetzing@gmail.com> writes:
> while I was updating the DarwinPorts Portfile for git, I saw some
> really suspicious lines in the Makefile of Git for DarwinPorts/Fink.
>
> --- snip ---
> ## fink
> ifeq ($(shell test -d /sw/lib && echo y),y)
> ALL_CFLAGS += -I/sw/include
> ALL_LDFLAGS += -L/sw/lib
> endif
> ## darwinports
> ifeq ($(shell test -d /opt/local/lib && echo y),y)
> ALL_CFLAGS += -I/opt/local/include
> ALL_LDFLAGS += -L/opt/local/lib
> endif
> --- snap ---
>
> IMHO, Git should definetely not include /sw/include and /sw/lib, just
> if it *exists*.
Could you make a concrete suggestion (I am not on Darwin)?
If I am reading you correctly, your suggestion is that
DarwinPorts and/or Fink build procedure, which drive our
Makefile from outside, should set up CFLAGS and LDFLAGS to have
the correct paths for local libraries and headers. It is not
clear to me if having these defaults there makes it hard (or
cumbersome) to override them in such a setup and you are
proposing to remove them (or commenting them out), or if you can
live with them being there.
These were made as "quick relatively sane defaults for help
people with simple configuration when people build git
themselves" initially and it may be the case that they now could
use improvements. I dunno (I am not on Darwin).
But I suspect that the "official" portfile (or whatever it is
called in the Darwin world) should be able to override whatever
is done in there --- otherwise we would need to remove them or
comment them out, but I am hoping it does not have to come to
that; I think they serve as good hint to help people who are
building from the source.
^ permalink raw reply
* Re: Makefile checks for DarwinPorts / Fink
From: Shawn Pearce @ 2006-07-22 16:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Pfetzing, git, merlyn
In-Reply-To: <7vhd19itu2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Stefan Pfetzing" <stefan.pfetzing@gmail.com> writes:
>
> > while I was updating the DarwinPorts Portfile for git, I saw some
> > really suspicious lines in the Makefile of Git for DarwinPorts/Fink.
> >
> > --- snip ---
> > ## fink
> > ifeq ($(shell test -d /sw/lib && echo y),y)
> > ALL_CFLAGS += -I/sw/include
> > ALL_LDFLAGS += -L/sw/lib
> > endif
> > ## darwinports
> > ifeq ($(shell test -d /opt/local/lib && echo y),y)
> > ALL_CFLAGS += -I/opt/local/include
> > ALL_LDFLAGS += -L/opt/local/lib
> > endif
> > --- snap ---
> >
> > IMHO, Git should definetely not include /sw/include and /sw/lib, just
> > if it *exists*.
[snip]
> But I suspect that the "official" portfile (or whatever it is
> called in the Darwin world) should be able to override whatever
> is done in there --- otherwise we would need to remove them or
> comment them out, but I am hoping it does not have to come to
> that; I think they serve as good hint to help people who are
> building from the source.
The quoted section of the Makefile was mostly my fault. GIT used
to build only against Fink but when I switched to DarwinPorts it
was first not even looking for them and second when I removed Fink
the Mac OS X linker was warning about /sw/lib not existing.
I completely agree that its incorrect to be doing this all of the
time as a higher-level build driver (e.g. Portfile) should be able
to have more direct control CFLAGS and LDFLAGS. Perhaps something
like this?
diff --git a/Makefile b/Makefile
index a1666e2..0a48c32 100644
--- a/Makefile
+++ b/Makefile
@@ -268,14 +268,18 @@ ifeq ($(uname_S),Darwin)
NEEDS_LIBICONV = YesPlease
NO_STRLCPY = YesPlease
## fink
- ifeq ($(shell test -d /sw/lib && echo y),y)
- BASIC_CFLAGS += -I/sw/include
- BASIC_LDFLAGS += -L/sw/lib
+ ifndef NO_FINK
+ ifeq ($(shell test -d /sw/lib && echo y),y)
+ BASIC_CFLAGS += -I/sw/include
+ BASIC_LDFLAGS += -L/sw/lib
+ endif
endif
+ ifndef NO_DARWIN_PORTS
## darwinports
- ifeq ($(shell test -d /opt/local/lib && echo y),y)
- BASIC_CFLAGS += -I/opt/local/include
- BASIC_LDFLAGS += -L/opt/local/lib
+ ifeq ($(shell test -d /opt/local/lib && echo y),y)
+ BASIC_CFLAGS += -I/opt/local/include
+ BASIC_LDFLAGS += -L/opt/local/lib
+ endif
endif
endif
ifeq ($(uname_S),SunOS)
--
Shawn.
^ permalink raw reply related
* Re: [OT] OLS slides
From: Petr Baudis @ 2006-07-22 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvepqi6x6.fsf@assigned-by-dhcp.cox.net>
Hi,
Dear diary, on Sat, Jul 22, 2006 at 06:45:41AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> My slides (with full transcripts) are available at
>
> http://members.cox.net/junkio/200607-ols.pdf
and my slides are at http://pasky.or.cz/ols-cogito/ (I've added
another two or three slides to cover some stuff I've only spoken about
at the tutorial).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Git BOF notes
From: Petr Baudis @ 2006-07-22 19:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607220547570.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sat, Jul 22, 2006 at 05:55:59AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sat, 22 Jul 2006, Petr Baudis wrote:
> > Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
> > where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > > Think "changed templates".
> >
> > it may be that I'm just tired, but I don't see what you mean, sorry.
>
> If you change a template (like add a hook or something), you can call
> git-init-db in an existing repository to update that hook.
ah well, I guess that's obscure enough to tell the user to directly
run git-init-db. ;-)
> > > And also think "setup a remote repository", especially "setup a remote
> > > HTTP repository".
> >
> > Of course. Currently you need to tinker with environment variables,
> > then with hooks, possibly with permissions and stuff to make the
> > repository shared... Think cg-admin-setuprepo. ;-)
>
> git-init-db --shared
And the environment variable and the chgrp and g+s. That's my point.
> > > And also think "start a new repository with only a _part_ of the current
> > > files". There are plenty reasons -- in addition to separation of concepts
> > > -- not to commit straight after initializing a repository.
> >
> > So what _do_ you do if you don't commit straight?
>
> Sometimes, I do "git-push just@initted.repository.com master". From
> somewhere else, of course.
I guess that's more common for the bare repositories.
> And sometimes, I do "cp -R /some/where/CVS ./; git-cvsimport".
git-cvsimport will create the repository for you, won't it?
> > Of course sometimes you don't want to add everything, and that should
> > still be possible to do (cg-init has a switch for that).
>
> Usually I start small projects as a single .c or .java file. Only after a
> while, I think it is worth it to init a git database. So, I _always_ have
> generated files lying around. And I would hate it if they were checked in
> automatically. (Yeah, I could remove them, _then_ remove them from the
> index, and then git-commit --amend. Ugly.)
Can't you just do make clean before git init? Or you can prepare
.gitignore before you check stuff in, so that the autogenerated files
don't pollute your git status output. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Random Git Issues/Wishlist
From: Petr Baudis @ 2006-07-22 19:55 UTC (permalink / raw)
To: git
Hi,
this is a random list of issues that come up in my mind when I was
thinking about things we could discuss at the Git BOF at OLS in case
enought Git developers gathered - which of course didn't happen but
perhaps it might be useful to mention them as well. Feel free to follow
up with *your* stuff (and comments or patches, of course).
(i) libgit - right now it has just evolved from bundling random Git
internal calls and has no defined API whatsoever; luckily, nothing
external hopefully uses it yet. If we wait much longer, people will
probably start to and we might start getting into a trouble there.
Another thing is what to do with the builtins, shall we bundle most of
the code in libgit? If not, many libgit users will probably end up just
reimplementing large chunks of their functionality. I've actually
thought about also interfacing libbuiltin.so when doing Git.pm but I
didn't yet for the sake of simplicity.
(ii) Documentation - it's currently very bad. Incomplete, out of sync,
missing tons of parameters and other things, and so on. We should be
more responsible when adding features to always document them right
away.
(iii) Lazy clone, shallow clone, whatever you call it. This has
several possible degrees of implementation:
(a) Just being able to get the latest revision (this really
shouldn't be that hard to do)
(b) Arbitrarily cut off the revisions at some point; this means
that you will get _some_ repository but with incomplete
history and we should handle that sensibly, like...
(c) ...having kind of "remote alternates", which means that if
we hit an object we don't have we will look it remotely as
well; this means moving the remote access functions much
more inside the really core Git; we want to be smart and
e.g. bundle tree requests with all the msisingblob requests
and so on; we don't want to fetch *everything* when the
user just does git log, though
(d) As an extension of (a), having some side of server-client
stuff which would also know how to do rev-lists and such
remotely; I'm not sure if the demand here is big enough
to justify that
(iv) Packing - I really feel bad about requiring users to manually
repack periodically, and also that's hurting the dumb server users
unless you take special provisions and so on
(v) Subprojects support; in a sort of long-term limbo because I guess
everyone is too lazy to finally implement something and the users aren't
loud enough ;-) (or they just moved on to another VCS)
(vi) Renames - should we follow them in logs? Will we? When? How
exactly in the interesting cases?
(vii) Private tags. refs/private or refs/tags/.hidden? Will we even?
When?
(viii) Patches versioning in StGit - many people I've told about StGit
complained that it doesn't version patches (and possibly moved to mq?).
We should have some scheme for doing meta-history (especially
interesting when/if we aim to make altering history easy).
(ix) What about the user survey? It sorta stalled, as far as I can
see.
(x) Metainformation over the Git protocol - kernel.org wants this
badly because rsyncing the repositories leads to *endless* problems;
there are some more complicated rsync schemes possible but hpa would be
happiest with making it possible to just use git to sync the
repositories out; this might be in part dependent on (iv) since the
repository maintainers basically lose control over the packing
(xi) Annotate or blame? Most people seem to be in favour of blome,
but having both is confusing; by now one of them should've already won.
(xii) Special merging - I now maintian the SuSE glibc package in git
and I'd like to use something more sensible than diff3 merger for
merging the changelogs from various branches; it's trivially solvable
conflicts all the time
(xiii) General user interface issues, like confusing error messages,
incomplete usage help, needlessly complicated (see our git init
discussion in the other thread) or inconsistent usage (git rebase,
anyone?) in general and other stuff aside of (ii).
That's probably all you'll hear from me for now, I guess. It's your
turn now.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Git BOF notes
From: Timo Hirvonen @ 2006-07-22 20:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes.Schindelin, git
In-Reply-To: <20060722191652.GR13776@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> > Usually I start small projects as a single .c or .java file. Only after a
> > while, I think it is worth it to init a git database. So, I _always_ have
> > generated files lying around. And I would hate it if they were checked in
> > automatically. (Yeah, I could remove them, _then_ remove them from the
> > index, and then git-commit --amend. Ugly.)
>
> Can't you just do make clean before git init? Or you can prepare
> .gitignore before you check stuff in, so that the autogenerated files
> don't pollute your git status output. ;-)
I like git init-db as it is now. I don't want it to automatically add
files. GIT does what you ask it to do, not what it _thinks_ you want to
do.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Git BOF notes
From: Nguyễn Thái Ngọc Duy @ 2006-07-22 20:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: Petr Baudis, J. Bruce Fields, git
In-Reply-To: <81b0412b0607210802q4d48b277yc4c45d4acbd890a6@mail.gmail.com>
On 7/21/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 7/21/06, Petr Baudis <pasky@suse.cz> wrote:
> > I don't know if there's a point in being so paranoid - it already makes
> > things more painful than necessary. In the tracking branch, you just
> > want to have what the other side has anyway, and if the other side
> > decided to jump around, why would you care otherwise?
>
> But for the ones who do care, it is much harder to notice. Even if it is
> a warning (it gets lost in crontab logs).
Then create some lost+found branches for them?
^ permalink raw reply
* Re: Random Git Issues/Wishlist
From: Paolo Ciarrocchi @ 2006-07-22 21:00 UTC (permalink / raw)
To: Petr Baudis, Martin Langhoff; +Cc: git
In-Reply-To: <20060722195502.GS13776@pasky.or.cz>
On 7/22/06, Petr Baudis <pasky@suse.cz> wrote:
[...]
> (ix) What about the user survey? It sorta stalled, as far as I can
> see.
Here it is the latest version:
About you
1. What country are you in?
2. What is your preferred language?
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
3. What helped you most in learning to use it?
4. When did you start using git?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
3. What hardware platforms do you use GIT on?
4. What OS (please include the version) do you use GIT on?
5. How many people do you collaborate with using GIT?
6. How big are the repositories that you work on? (e.g. how many
files, how much disk space, how deep is the history)
7. How many different projects do you manage using GIT?
8. Which porcelains do you use?
9. Is the git.git repository including codes produced by you?
What you think of GIT
1. Overall, how happy are you with GIT?
2. How does GIT compare to other SCM tools you have used?
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plugins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Documentation
1. Do you use the GIT wiki? If yes, do you find it useful?
2. Do you find GIT's online help useful?
3. What is your favourite user documentation for any software
projects or products you have used?
4. What could be improved on the GIT homepage?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
* If yes, did you get these problems resolved quickly and to
your liking?
2. Do you subscribe to the mailing list?
* If yes, do you find it useful, and traffic levels OK?
3. Do you use the IRC channel (#git on irc.freenode.net)?
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
Sorry for not following closely this topic but unfortunately I had
personal problems.
Martin, can you upload the survey to survey.net.nz as we privately discussed?
If not, I'll sending out it in the next following days.
Thanks.
regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Defaulting fetch to origin when set in the repo-config
From: Santi Béjar @ 2006-07-22 22:54 UTC (permalink / raw)
To: git
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
diff --git a/git-fetch.sh b/git-fetch.sh
index a393a50..c2eebee 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -70,7 +70,8 @@ case "$#" in
0)
test -f "$GIT_DIR/branches/origin" ||
test -f "$GIT_DIR/remotes/origin" ||
- die "Where do you want to fetch from today?"
+ git-repo-config --get remote.origin.url >/dev/null ||
+ die "Where do you want to fetch from today?"
set origin ;;
esac
^ permalink raw reply related
* Re: Random Git Issues/Wishlist
From: Martin Langhoff @ 2006-07-23 0:12 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Petr Baudis, git
In-Reply-To: <4d8e3fd30607221400j1839883es6c948464cdf22439@mail.gmail.com>
> Martin, can you upload the survey to survey.net.nz as we privately discussed?
Done. this is what it looks like:
http://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50
I'll send you the login details to modify it. I've changed a few
things ever so slightly so it made sense when boiled down to an array
of radio buttons and text boxes. Survey.net doesn't quite support
"section titles" so I added the section title to the first question of
the set, hoping for a "conversational" approach to introducing the
section to the user.
The best way to edit it is by downloading the text file, editing in
$EDITOR and posting it back. the format is trivial, and explained here
http://survey.net.nz/index.php?page=faq under "Upload Survey".
cheers,
martin
^ permalink raw reply
* :), mother-in-law
From: Rafael Mead @ 2006-07-23 4:00 UTC (permalink / raw)
To: git-commits-head-owner
Genuine Swiss made Role3x repilcas are as close to the real thing
as a repilca watch can be. Sometimes even the professional jewelers
are unable to tell the difference from the real RoleJx watch.
Why spend thousands of dollars on the real deal when
a repilca watch looks so much alike that only an expert could tell the difference...
And you only pay a fractoin of the price.
VISIT US, AND GET OUR SPECIL 370% DIS1COUNT OFER!
http://4PAQO3Rn3sgaotdbtbgo553a5nlsnn5.madwortmj.com/
=====
in his eye. "Me leading? What do you mean, me leading? You're the
one with acid, squash it under a press, or melt it in an oven. And then he
"No, Jonathan, there is no such place. Heaven is not a place, and it
hundred feet of clear space either on your left or your right. So, we can go
and it was time to go home.
and ordered a flying boot. I looked over his map to see what was on it. It
extended into the wind, and fell into a vertical dive.
was sick and he had gone for the doctor. Apologized for being late. Well, we
^ 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