* git clone / SHA1 mismatch
From: Mika Muukkonen @ 2006-07-21 4:55 UTC (permalink / raw)
To: git
Greetings,
when attempting to clone repositories (Linus's kernel, stable 2.6.16, OMAP kernel) I seem to come across the following more or less constantly:
mmu@spud1:/var/git$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git linux-2.6.16
Generating pack...
Done counting 195441 objects.
Deltifying 195441 objects.
100% (195441/195441) done
fatal: unexpected EOF)
fatal: packfile '/var/git/linux-2.6.16/.git/objects/pack/tmp-QeO4uB' SHA1 mismatch
error: git-fetch-pack: unable to read from git-index-pack
error: git-index-pack died with error code 128
fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git' failed.
and
mmu@spud1:/var/git$ cg-clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git linux-2.6.16
defaulting to local storage area
Fetching pack (head and objects)...
Generating pack...
Done counting 190732 objects.
Deltifying 190732 objects.
100% (190732/190732) done
fatal: unexpected EOF)
fatal: packfile '.git/objects/pack/tmp-4BiKAb' SHA1 mismatch
error: git-fetch-pack: unable to read from git-index-pack
error: git-index-pack died with error code 128
cg-fetch: fetching pack failed
and... and...
I compiled a rather recent version of git:
mmu@spud1:/var/git$ git --version
git version 1.4.2.rc1.ge7a0
and the all other libs required are up-to-date as well.
So; am I missing something or should cloning of current trees at kernel.org go down smoothly. Any advice apprecieated.
Mika Muukkonen
^ permalink raw reply
* Re: Easy way to empty working tree?
From: Alex Riesen @ 2006-07-21 7:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Robin Luckey, git
In-Reply-To: <Pine.LNX.4.64.0607201944460.29649@g5.osdl.org>
On 7/21/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > After mothballing the repository with git-repack -a -d and git clean
> > -d -x, is there a convenient one-liner to empty the files out the
> > working directory?
>
> Well, you can do
>
> git ls-files -z | xargs -0 rm -f --
>
That'd be not enough for kernel after it was compiled.
Maybe this:
find . -maxdepth 1 -not -name .git -not -name . -print0 | xargs -0 rm -rf --
^ permalink raw reply
* Re: Unanticipated test error
From: Alex Riesen @ 2006-07-21 7:22 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060720194013.GC24793@bohr.gbar.dtu.dk>
On 7/20/06, Peter Eriksen <s022018@student.dtu.dk> wrote:
> The patch really should not change any semantics at all, since
> it converts instances of
>
> memcpy(to, from, len);
> to[len] = 0;
>
> into
>
> strlcpy(to, from, len);
>
> I need a bit of help troubleshooting this one. I have tried
> running t0000-basic.sh using "bash -x", but that did not help
> me this time.
>
Well, there are differences. Correct translation from memcpy
to strlcpy (aside the fact with \0 inside the string) would be
something like:
strlcpy(to, from, len + 1);
assuming your example with memcpy. strlcpy expects size of
storage, and will never write more bytes that it was allowed to.
That'll cut off last character of the source string, unless it is
\0-terminated before the size of storage.
^ permalink raw reply
* Re: Unanticipated test error
From: Peter Eriksen @ 2006-07-21 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0607210022o562ac326wd149c73cc529f239@mail.gmail.com>
On Fri, Jul 21, 2006 at 09:22:44AM +0200, Alex Riesen wrote:
...
> Well, there are differences. Correct translation from memcpy
> to strlcpy (aside the fact with \0 inside the string) would be
> something like:
>
> strlcpy(to, from, len + 1);
>
> assuming your example with memcpy. strlcpy expects size of
> storage, and will never write more bytes that it was allowed to.
> That'll cut off last character of the source string, unless it is
> \0-terminated before the size of storage.
I see it now. What I did was wrong. Appending " + 1" to every
one of my calls makes the patch survive "make test". However,
since strlcpy() calls strlen(from), it would have to be checked,
that 'from' is always NUL terminated. The benefits of this patch
seem to shrink.
Thank you for your comment!
Peter
^ permalink raw reply
* Re: git clone / SHA1 mismatch
From: Johannes Schindelin @ 2006-07-21 8:37 UTC (permalink / raw)
To: Mika Muukkonen; +Cc: git
In-Reply-To: <007e01c6ac81$d523a700$76401f0a@almare2.tre>
Hi,
On Fri, 21 Jul 2006, Mika Muukkonen wrote:
> when attempting to clone repositories (Linus's kernel, stable 2.6.16, OMAP kernel) I seem to come across the following more or less constantly:
>
> mmu@spud1:/var/git$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git linux-2.6.16
> Generating pack...
> Done counting 195441 objects.
> Deltifying 195441 objects.
> 100% (195441/195441) done
> fatal: unexpected EOF)
This sounds like you had a timeout before the complete pack was
transmitted (the Deltifying takes place on the other side).
Hth,
Dscho
^ permalink raw reply
* The ingredients in Fatblaster assist in the thermogenic processes allowing you to naturally and safely burn fat and loose unwanted weight.
From: Sumner @ 2006-07-21 10:05 UTC (permalink / raw)
To: godard
Dear valued customer.
The ingredients in Fatblaster assist in the thermogenic processes allowing you to naturally and safely burn fat and loose unwanted weight. One way to reduce energy intake and absorption is through thermogenic formulas such as the ingredients found in Fatblaster. Supplement your life today! Join thousands of satisfied customers and experience for yourself the proven benefits of Fatblaster. Check up here: http://yeltren.com/gal/fb/
The best doctors are Dr Diet, Dr Quiet and Dr Merryman Good broth may be made in an old pot Men are from earth Women are from earth Deal with it
For the commandment is a lamp; and the law is light; and reproofs of instruction are the way of life. Wisdom crieth without; she uttereth her voice in the streets. Imagination is the highest kite you can fly Age before beauty
^ permalink raw reply
* Re: [PATCH] Display "gitweb/test/file with spaces" in gitk
From: Paul Mackerras @ 2006-07-21 13:01 UTC (permalink / raw)
To: Thomas Kolejka; +Cc: git, Junio C Hamano
In-Reply-To: <20060720101223.116320@gmx.net>
Thomas Kolejka writes:
> with this patch files with spaces in their names are displayed
> in the treeview of gitk.
>
> I use git to make a "backup"/"dump" of a DOS-FS .. and there are
> those filenames ;-).
Hmmm, certainly my code is incorrect. However with your code, tabs in
the filename will get changed to spaces. Treating the line read from
git-ls-tree or git-diff-tree was a shortcut hack that isn't really
optimal. I'll think about the best way to fix it.
Paul.
^ permalink raw reply
* Re: Git BOF notes
From: J. Bruce Fields @ 2006-07-21 13:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060719230155.GJ13776@pasky.or.cz>
On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:
> (i) We should somehow separate the lowlevel Git commands from the
> highlevel ones meant for user consumption. There's too many of them
> and it is confusing for the users. Similarity with BitKeeper was pointed
> out (and I refrained from mentioning GNU Arch).
The man page already attempts to make this distinction in its command
list, though arguably the order is wrong (it lists the low-level
commands first) and you could argue about some of the choices (git
init-db may be "low level", but it's something everyone probably wants
to see).
"git help" already has an abbreviated list. What else could we do?
--b.
^ permalink raw reply
* Re: Git BOF notes
From: J. Bruce Fields @ 2006-07-21 13:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060719230155.GJ13776@pasky.or.cz>
On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:
> * Support for distributing and following the mutated history.
> I'm actually not sure about the level of Git support for
> this, Cogito supports cg-updating to a mutated history
> if you have no local changes.
A fetch that doesn't fast-forward fails with a warning unless you
explicitly ask it (--force) to blow away your old history.
I don't see what more you could do.
--b.
^ permalink raw reply
* Re: Git BOF notes
From: Petr Baudis @ 2006-07-21 14:31 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060721132111.GD32585@fieldses.org>
Dear diary, on Fri, Jul 21, 2006 at 03:21:11PM CEST, I got a letter
where "J. Bruce Fields" <bfields@fieldses.org> said that...
> On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:
> > * Support for distributing and following the mutated history.
> > I'm actually not sure about the level of Git support for
> > this, Cogito supports cg-updating to a mutated history
> > if you have no local changes.
>
> A fetch that doesn't fast-forward fails with a warning unless you
> explicitly ask it (--force) to blow away your old history.
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?
Just make sure you print the original commit ID and perhaps a warning.
> I don't see what more you could do.
I guess a huge majority of Git users is an - almost inherently - silent
mass of those who just use Git for tracking the development of others,
and we gotta make it easy for them - and it's not easy if when the
remote side rebases it doesn't just move them to the new commit but
helpfully offers a nonsensical three-way merge.
--
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-21 14:42 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060721131824.GC32585@fieldses.org>
Dear diary, on Fri, Jul 21, 2006 at 03:18:24PM CEST, I got a letter
where "J. Bruce Fields" <bfields@fieldses.org> said that...
> On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:
> > (i) We should somehow separate the lowlevel Git commands from the
> > highlevel ones meant for user consumption. There's too many of them
> > and it is confusing for the users. Similarity with BitKeeper was pointed
> > out (and I refrained from mentioning GNU Arch).
>
> The man page already attempts to make this distinction in its command
> list, though arguably the order is wrong (it lists the low-level
> commands first) and you could argue about some of the choices (git
> init-db may be "low level", but it's something everyone probably wants
> to see).
>
> "git help" already has an abbreviated list. What else could we do?
Perhaps (while coordinating with the porcelains, of course) we should
start moving the lowlevel tools to the libexec directory and keep only
the end-user tools around.
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 ;). I think we still tell users to use
git-update-index to mark resolved conflicts, but all the Git people at
OLS were too afraid to even _mention_ the index to the users at all;
shouldn't we have git-resolved instead?
Oh well, except that people are gonna run git-resolve instead all the
time. Why do we still _have_ that one?
--
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
* [RFC/PATCH] Per branch properties for pull
From: Santi Béjar @ 2006-07-21 14:51 UTC (permalink / raw)
To: Git Mailing List
It extracts all the information for pull from the config file.
If you have a config file as:
[branch "master"]
remote=origin
merge=next #the remote name
octopus=octopus
twohead=recursive
When doing a "git pull" without extra parameters in the master branch
it will fetch the origin remote repository and will merge the next
branch (the remote name).
And you can also put the equivalent of the pull.{octopus,twohead}
options for each branch.
This only changes the behavour when these keys exist and when
git-pull is used without extra parameters.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Hi *,
Now that we have the arbitrary keys in the config file...
It does not affect the integrator that pulls from different
places. I don't know exactly what is needed but just for discuss it
could be something as:
[branch "master"]
remote=net
remote=ata
merge=for-linus from ata
merge=upstream from net
diff --git a/git-pull.sh b/git-pull.sh
index f380437..e7630b1 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,6 +44,14 @@ do
shift
done
+if [ $# -eq 0 ] ; then
+ default=yes
+ curr_branch=$(git-symbolic-ref HEAD)
+ curr_branch=${curr_branch##refs/heads/}
+ remote=$(git-repo-config --get "branch.$curr_branch.remote")
+ test "$remote" && set x "$remote" && shift
+fi
+
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
@@ -70,9 +78,19 @@ to recover.'
fi
+if [ "$default" == yes ] ; then
+ merge_head=$(git repo-config --get-all "branch.$curr_branch.merge")
+ for ref in $merge_head ; do
+ refspec=$(git-repo-config --get "remote.$remote.fetch" "^$ref:")
+ [ -z "$refspec" ] && die "Branch $ref does not exist in the repository: $remote."
+ locref="$locref ${refspec##$ref:}"
+ done
+ merge_head=$locref
+else
merge_head=$(sed -e '/ not-for-merge /d' \
-e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \
tr '\012' ' ')
+fi
case "$merge_head" in
'')
@@ -85,6 +103,11 @@ case "$merge_head" in
then
strategy_default_args="-s $var"
fi
+ var=`git-repo-config --get branch.$curr_branch.octopus`
+ if test -n "$var"
+ then
+ strategy_default_args="-s $var"
+ fi
;;
*)
var=`git-repo-config --get pull.twohead`
@@ -92,6 +115,11 @@ case "$merge_head" in
then
strategy_default_args="-s $var"
fi
+ var=`git-repo-config --get branch.$curr_branch.twohead`
+ if test -n "$var"
+ then
+ strategy_default_args="-s $var"
+ fi
;;
esac
^ permalink raw reply related
* Re: Unanticipated test error
From: Alex Riesen @ 2006-07-21 14:54 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060721081954.GA29645@bohr.gbar.dtu.dk>
On 7/21/06, Peter Eriksen <s022018@student.dtu.dk> wrote:
> ...
> > Well, there are differences. Correct translation from memcpy
> > to strlcpy (aside the fact with \0 inside the string) would be
> > something like:
> >
> > strlcpy(to, from, len + 1);
> >
> > assuming your example with memcpy. strlcpy expects size of
> > storage, and will never write more bytes that it was allowed to.
> > That'll cut off last character of the source string, unless it is
> > \0-terminated before the size of storage.
>
> I see it now. What I did was wrong. Appending " + 1" to every
> one of my calls makes the patch survive "make test". However,
> since strlcpy() calls strlen(from), it would have to be checked,
> that 'from' is always NUL terminated. The benefits of this patch
> seem to shrink.
Probably, but you still have room to balance benefits.
^ permalink raw reply
* Never-seen Order it on-line and impress your girlfriend with your wonderful shooting
From: Sandy @ 2006-07-21 14:55 UTC (permalink / raw)
To: godard
How are u?
Prolong your ssex. You have smalll peniis? Add 3 inches in lenght! Check up here: http://www.ollyert.com/gal/ms/
Better an open enemy, than a false friend True love never grows old Pain is so close to pleasure Murder will out
^ permalink raw reply
* 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
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