* Re: History messup
From: Thomas Gleixner @ 2005-05-09 18:05 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, David Woodhouse, Linus Torvalds
In-Reply-To: <20050509170611.GJ24216@cip.informatik.uni-erlangen.de>
On Mon, 2005-05-09 at 19:06 +0200, Thomas Glanzmann wrote:
> If two repositories pull alternating from each other one has never the
> exact state the other has. They would play ping-pong and this is a bad
> thing. That was AFAIK the reason there is no COMMIT object introduced on
> 'head forward' merges.
That makes totaly sense, but for history tracking it is a horror
scenario, unless you dont have head history lists per repository or an
unique repository identifier in the commit blob itself.
tglx
^ permalink raw reply
* Darcs-git: a few notes for Git hackers
From: Juliusz Chroboczek @ 2005-05-09 18:01 UTC (permalink / raw)
To: Git Mailing List; +Cc: darcs-devel
Hi,
Here are a few notes about Git that should probably be taken into
account by people working on Git itself or on Git wrappers. The notes
apply to Linus' Git-0.6, which is the code I'm using in Darcs-git;
some of them might no longer be applicable to Darcs.
1. Darcs-git uses the fact that Git updates are atomic when reading
from a Git repository. Darcs-git almost writes to Git repositories
atomically, with one exception: it performs a non-atomic
read/update/write cycle on .git/HEAD.
For that reason, I'm taking a high-level lock on .git repositories
whenever I write them. The lockfile is ``.git/lock''. I haven't
thought about whether Darcs can be easily coerced into accessing Git
repos atomically; have people writing Git wrappers found the need for
a global lock?
2. The files git.h and git.c in Darcs-git are a simple ``libgit'' that
contains just enough functionality for Darcs-git; they use the
functionality of sha1_file.c and read_cache.c from Git-0.6.
I've found a few problems with the interfaces in these files:
- the global variables sha1_file_directory, active_cache, active_nr
and active_alloc are not marked ``extern'' in cache.h. This breaks
linkers that don't grok common symbols, such as the one in GHCi
(silly GHCi).
- the function write_sha1_file takes the metadata and the data in a
contiguous buffer, which is a problem when the data has been
allocated by a higher layer. I'm currently working around the
problem by memcpy-ing everything into a temp buffer, but that's
obviously not a good thing. I don't care whether write_sha1_file
is changed to use a writev-like interface, or to take the metadata
explicitly (as in char *type, unsigned long length).
- there is no (usable) function to write a tree; there's the code in
write_tree.c, but it's not generally useful. See the function
``git_write_tree_done'' in git.c for the type of interface I'm
thinking of.
- there's no way to have multiple simultaneous caches, short of
hacking at the values of Git's global variables by hand.
As I'd rather not maintain my own version of Git, I'd be mighty
grateful if some friendly Git hacker could fix the above.
Juliusz
^ permalink raw reply
* Re: Git-aware Darcs: a tutorial
From: H. Peter Anvin @ 2005-05-09 17:55 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: darcs-devel, darcs-users, Git Mailing List
In-Reply-To: <7i4qdc8isd.fsf@lanthane.pps.jussieu.fr>
Juliusz Chroboczek wrote:
> 0. What is Darcs-git
>
> Darcs-git is a branch of Darcs that can work with Git repositories.
>
> Darcs-git is deliberately Darcs, not Git. All commands either work in
> the same way on Git repositories as on Darcs repositories, or they
> fail. If you're a Darcs user, you'll like darcs-git. If you're a Git
> user, you'll probably find it infuriating.
>
> On the other hand, Darcs-git uses stock Git repositories; a Darcs
> command either works as-is on a Git repository, or fails.
>
How is it, performance-wise?
-hpa
^ permalink raw reply
* Howto get repository up2date after pull with touching as less as possible files in the working directory
From: Thomas Glanzmann @ 2005-05-09 17:49 UTC (permalink / raw)
To: GIT
Hello alltogether,
at the moment I ensrure that there are no dirty files before the pull
and do a
git-read-tree HEAD
git-checkout -a -f
git-update-cache --refresh
this is suboptimal because all the files in my working directory get a
new timestamp and if I call make everything is recompiled (ccache helps,
but is not the solution to this problem).
So what is the right way to touch *only* the files which are dirty. Are
there any shortcuts? Or should I call 'git dirty' pipe that to
git-checkout -f?
Thomas
^ permalink raw reply
* Re: History messup
From: Thomas Gleixner @ 2005-05-09 17:48 UTC (permalink / raw)
To: David Woodhouse; +Cc: git, Linus Torvalds
In-Reply-To: <1115659677.16187.393.camel@hades.cambridge.redhat.com>
On Mon, 2005-05-09 at 18:27 +0100, David Woodhouse wrote:
> On Mon, 2005-05-09 at 16:59 +0000, Thomas Gleixner wrote:
> It's normal practice, and it _has_ to be the case. Otherwise the trees
> would never stabilise -- every time Linus pulled from my tree he would
> create a merge-commit which I don't yet have, and vice versa.
Sure
> Unless a commit also carries a unique repo-id identifying the repository
> in which it originally occurred, you'll only ever be able to track
> history in the way people want by means of heuristics.
That would be really great. A line after "parents" like
repoid "username/reponame"
would be sufficient
tglx
^ permalink raw reply
* Re: kernel.org upgraded to cogito-0.10
From: Kay Sievers @ 2005-05-09 17:45 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Jan-Benedict Glaw, Git Mailing List
In-Reply-To: <427F7FEF.7040406@zytor.com>
On Mon, 2005-05-09 at 08:21 -0700, H. Peter Anvin wrote:
> Jan-Benedict Glaw wrote:
> > On Mon, 2005-05-09 07:17:24 -0700, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> >>I have installed cogito-0.10 on the kernel.org machines.
Very nice!
> > ...and you'd probably revert or fix the bug(s) that make all project's
> > logs look quite empty at http://www.kernel.org/git ...
> >
>
> Kay has a new version of the git web client which is needed for the new
> version... Kay?
The new version of gitweb is installed now.
Kay
^ permalink raw reply
* Re: History messup
From: David Woodhouse @ 2005-05-09 17:27 UTC (permalink / raw)
To: tglx; +Cc: git, Linus Torvalds
In-Reply-To: <1115657971.19236.33.camel@tglx>
On Mon, 2005-05-09 at 16:59 +0000, Thomas Gleixner wrote:
> David merged from Linus repository . Linus synced later with David.
> Linus did not create a new commit for this update and just pointed his
> "HEAD" to Davids "HEAD", which means he forked Davids repository at
> this point.
>
> Due to that the parent->parent history is not longer unique. This
> makes it impossible to do file revision graphs over the various
> repositories in the correct order.
>
> Is this a unique problem or is the omission of a commit in cases like
> that usual practice ? In the latter case proper history tracking is
> almost impossible.
It's normal practice, and it _has_ to be the case. Otherwise the trees
would never stabilise -- every time Linus pulled from my tree he would
create a merge-commit which I don't yet have, and vice versa.
Unless a commit also carries a unique repo-id identifying the repository
in which it originally occurred, you'll only ever be able to track
history in the way people want by means of heuristics.
--
dwmw2
^ permalink raw reply
* Re: History messup
From: Thomas Glanzmann @ 2005-05-09 17:06 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: git, David Woodhouse, Linus Torvalds
In-Reply-To: <1115657971.19236.33.camel@tglx>
Hello,
if merging with a repository just means to bring the head forward (e.g.
no local development since the fork) there is no seperate commit object,
just an update of the HEAD. Linus did explain this behaviour and the
thoughts behind this decission on the ML:
If two repositories pull alternating from each other one has never the
exact state the other has. They would play ping-pong and this is a bad
thing. That was AFAIK the reason there is no COMMIT object introduced on
'head forward' merges.
Thomas
^ permalink raw reply
* History messup
From: Thomas Gleixner @ 2005-05-09 16:59 UTC (permalink / raw)
To: git; +Cc: David Woodhouse, Linus Torvalds
Hi,
I wrote a git repository tracker, which can track and coordinate
multiple git repositories. Before it goes public, I want to clarify a
problem which I encountered
The commit bfd4bda097f8758d28e632ff2035e25577f6b060
by David Woodhouse (Thu May 5 12:59:37 2005 +100)
Merge with
master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
breaks the history.
David merged from Linus repository . Linus synced later with David.
Linus did not create a new commit for this update and just pointed his
"HEAD" to Davids "HEAD", which means he forked Davids repository at this
point.
Due to that the parent->parent history is not longer unique. This makes
it impossible to do file revision graphs over the various repositories
in the correct order.
Is this a unique problem or is the omission of a commit in cases like
that usual practice ? In the latter case proper history tracking is
almost impossible.
tglx
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Sean @ 2005-05-09 16:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, Linus Torvalds, git
In-Reply-To: <7vll6oz755.fsf@assigned-by-dhcp.cox.net>
On Mon, May 9, 2005 12:38 pm, Junio C Hamano said:
>>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:
>
> HPA> Naming the environment variables SHA1_FILE_<anything> is almost
> HPA> certainly wrong; a much more logical name would be
> HPA> GIT_<something>. It'd also be much less likely to cause conflicts.
>
> Exactly my feeling from the beginning.
>
> But you have to realize that you are suggesting to change the
> SHA1_FILE_DIRECTORY that was there from almost the beginning as
> well. I know the code change required for the rename is
> minimum, but there are users involved. My feeling is that we
> should contain the damage by changing the definition of
> DB_ENVIRONMENT in cache.h sooner rather than later, but I do not
> think this is the week to do it.
>
>
What about creating a transition plan that uses the GIT_ name if it exists
and the SHA1_ name if it doesn't. And mark the SHA1_ name as depreciated.
That should be okay to do this week, no?
Sean
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Junio C Hamano @ 2005-05-09 16:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Sean, Linus Torvalds, git
In-Reply-To: <427F6693.2080707@zytor.com>
>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:
HPA> Naming the environment variables SHA1_FILE_<anything> is almost
HPA> certainly wrong; a much more logical name would be
HPA> GIT_<something>. It'd also be much less likely to cause conflicts.
Exactly my feeling from the beginning.
But you have to realize that you are suggesting to change the
SHA1_FILE_DIRECTORY that was there from almost the beginning as
well. I know the code change required for the rename is
minimum, but there are users involved. My feeling is that we
should contain the damage by changing the definition of
DB_ENVIRONMENT in cache.h sooner rather than later, but I do not
think this is the week to do it.
^ permalink raw reply
* Git-aware Darcs: a tutorial
From: Juliusz Chroboczek @ 2005-05-09 16:29 UTC (permalink / raw)
To: darcs-devel; +Cc: darcs-users, Git Mailing List
0. What is Darcs-git
Darcs-git is a branch of Darcs that can work with Git repositories.
Darcs-git is deliberately Darcs, not Git. All commands either work in
the same way on Git repositories as on Darcs repositories, or they
fail. If you're a Darcs user, you'll like darcs-git. If you're a Git
user, you'll probably find it infuriating.
On the other hand, Darcs-git uses stock Git repositories; a Darcs
command either works as-is on a Git repository, or fails.
1. What you can expect
The following should work reasonably well on Git repositories:
darcs changes
darcs whatsnew
darcs pull
darcs send
darcs record
The following commands work, but have serious performance problems:
darcs diff
darcs changes with a file argument
The following commands should in principle work but haven't been tested:
darcs add
darcs remove
darcs dist
darcs trackdown
The following commands don't work because I'm lazy::
darcs push
darcs unrecord
darcs unpull
darcs amend-record
darcs annotate
darcs rollback
The following commands only work on native Darcs repositories, either
because they don't make sense on Git repositories, or because there
are perfectly good native Git tools to perform their function:
darcs initialize
darcs get/put
darcs check
darcs repair
darcs optimize
darcs mv
darcs replace
darcs resolve
darcs tag
darcs setpref
Remote Git repositories are not supported.
2. A tutorial
(0) Build darcs-git
$ darcs get --partial http://www.pps.jussieu.fr/~jch/software/repos/darcs-git
$ cd darcs-git
$ make darcs
$ make Context.hs
$ make darcs
$ cp darcs ~/bin/
(1) Get a copy of the Linux Git repository:
$ cd /usr/local/src
$ mkdir linux-2.6
$ cd linux-2.6
$ rsync -r rsync://rsync.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git .git
$ curl http://rsync.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git/HEAD > .git/HEAD
We still need to bring the cache and working directory into a state
that Darcs will be happy with. While this could in principle be done
with Darcs itself, it will be faster to do it with Git:
$ read-tree `cat .git/HEAD`
$ checkout-cache -a
$ update-cache --refresh
(2) Check what the friendly Linux hackers have been up to:
$ darcs changes | more
$ darcs changes -s | more
(3) Create a local clone of the Linux repository:
$ cd ..
$ mkdir linux-2.6-local
$ mkdir linux-2.6-local/.git
$ ln -s `pwd`/linux-2.6/.git/objects linux-2.6-local/.git
$ cp linux-2.6/.git/HEAD linux-2.6-local/.git
$ cd linux-2.6-local
$ read-tree `cat .git/HEAD`
$ checkout-cache -a
$ update-cache --refresh
(4) Commit some work
First, check that Darcs is happy with the new repository.
$ darcs whatsnew
This should take a few seconds at most; if it takes minutes instead,
try running ``update-cache --refresh''.
Okay, let's add myself to the list of Linux maintainers.
$ echo 'P: Juliusz Chroboczek' >> MAINTAINERS
Let's see if Darcs agrees.
$ darcs whatsnew -s
$ darcs whatsnew
Everything looks fine, let's record (commit) this patch.
$ darcs record -a
$ darcs changes | more
$ darcs changes -s | more
(5) Send it upstream
If Linus were using Darcs, we could just send him a Darcs patch, which
is a patch-like data structure that contains just enough context
information to allow Darcs to perform a history-sensitive merge:
$ darcs send ../linux-2.6
However, until Linus switches to Darcs, we're stuck with old-fashioned
patches.
$ darcs diff -u --patch='.' | mail bill@microsoft.com
Unfortunately, until I've spent some time optimising ``darcs diff'',
the above won't terminate on a repository the size of Linux'.
3. Caveats
There is little input validation. In particular, if you enter an
e-mail address that doesn't end in ``>'', Darcs will write a commit
that neither Git nor Darcs itself will be able to parse.
Darcs never updates the Git cache. If you perform many commits using
Darcs, you'll need to manually run ``update-cache --refresh''.
Darcs treats Git merges by reverse-engineering a Darcs merge (thanks
to David Roundy for outlining how that can be done). In practice,
this means that Darcs will collapse as soon as it sees a nontrivial
Git merge.
^ permalink raw reply
* Re: kernel.org upgraded to cogito-0.10
From: Dave Kleikamp @ 2005-05-09 16:01 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Steven Cole, Git Mailing List, Kay Sievers, Steve French
In-Reply-To: <427F8803.7030004@zytor.com>
On Mon, 2005-05-09 at 08:55 -0700, H. Peter Anvin wrote:
> > Unrelated, but the repo at .../sfrench/cifs-2.6.git gives a
> > 403 Forbidden - Invalid project directory from the web interface.
>
> That's because he has a .git directory inside another .git directory.
I was working with Steve Friday afternoon to set up this repo. We quit
for the weekend before we realized we didn't initialize the repository
correctly. We'll fix it.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: kernel.org upgraded to cogito-0.10
From: H. Peter Anvin @ 2005-05-09 15:55 UTC (permalink / raw)
To: Steven Cole; +Cc: Git Mailing List, Kay Sievers
In-Reply-To: <427F828C.8070406@mesatop.com>
Steven Cole wrote:
> H. Peter Anvin wrote:
>
>> I have installed cogito-0.10 on the kernel.org machines.
>>
>> -hpa
>> -
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Something seems to have broken recently with gitweb.cgi at
> http://www.kernel.org/git/. No results from any repos.
Known issue.
> Unrelated, but the repo at .../sfrench/cifs-2.6.git gives a
> 403 Forbidden - Invalid project directory from the web interface.
That's because he has a .git directory inside another .git directory.
-hpa
^ permalink raw reply
* Re: kernel.org upgraded to cogito-0.10
From: Steven Cole @ 2005-05-09 15:32 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, Kay Sievers
In-Reply-To: <427F70F4.4030409@zytor.com>
H. Peter Anvin wrote:
> I have installed cogito-0.10 on the kernel.org machines.
>
> -hpa
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Something seems to have broken recently with gitweb.cgi at
http://www.kernel.org/git/. No results from any repos.
Unrelated, but the repo at .../sfrench/cifs-2.6.git gives a
403 Forbidden - Invalid project directory from the web interface.
Steven
^ permalink raw reply
* Re: [RFC] allow file list editing during cg-commit
From: Jonas Fonseca @ 2005-05-09 15:24 UTC (permalink / raw)
To: git
In-Reply-To: <20050509041459.GA13475@gate.ebshome.net>
Eugene Surovegin <ebs@ebshome.net> wrote Sun, May 08, 2005:
> I just started playing with cogito and failed to find _easy_ way to
> select which files will be committed and which won't. cg-commit seems
> to support specifying file list in command line, but this isn't very
> convenient when the list is big.
The commit message is already very self documenting so it would be great
if this feature was also documented there. Something like the following,
but clearer:
CG: -----------------------------------------------------------------
CG: Lines beginning with the CG: prefix are removed automatically.
CG: By deleting lines beginning with `CG:F' the associated file will
CG: be removed from the commit list.
CG: ...
--
Jonas Fonseca
^ permalink raw reply
* Re: kernel.org upgraded to cogito-0.10
From: H. Peter Anvin @ 2005-05-09 15:21 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Git Mailing List, Kay Sievers
In-Reply-To: <20050509145943.GJ24187@lug-owl.de>
Jan-Benedict Glaw wrote:
> On Mon, 2005-05-09 07:17:24 -0700, H. Peter Anvin <hpa@zytor.com> wrote:
>
>>I have installed cogito-0.10 on the kernel.org machines.
>
>
> ...and you'd probably revert or fix the bug(s) that make all project's
> logs look quite empty at http://www.kernel.org/git ...
>
Kay has a new version of the git web client which is needed for the new
version... Kay?
-hpa
^ permalink raw reply
* Re: kernel.org upgraded to cogito-0.10
From: Jan-Benedict Glaw @ 2005-05-09 14:59 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, Kay Sievers
In-Reply-To: <427F70F4.4030409@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
On Mon, 2005-05-09 07:17:24 -0700, H. Peter Anvin <hpa@zytor.com> wrote:
> I have installed cogito-0.10 on the kernel.org machines.
...and you'd probably revert or fix the bug(s) that make all project's
logs look quite empty at http://www.kernel.org/git ...
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: H. Peter Anvin @ 2005-05-09 14:47 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050507231539.GB2497@cip.informatik.uni-erlangen.de>
Thomas Glanzmann wrote:
> Hello Coworker,
>
>
>>huh? which broken shell does not understand $()?
>
>
> /bin/sh under Solaris 9 for example. That is where I hit it initial.
>
Shoot Sun.
$(...) is in POSIX and has been for oh, what, 15 years now?
-hpa
^ permalink raw reply
* Re: [PATCH Cogito] .spec file update
From: H. Peter Anvin @ 2005-05-09 14:37 UTC (permalink / raw)
To: Mads Martin Joergensen; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <20050509141940.GP87309@mmj.dk>
[-- Attachment #1: Type: text/plain, Size: 275 bytes --]
Mads Martin Joergensen wrote:
> * H. Peter Anvin <hpa@orionmulti.com> [May 09. 2005 16:14]:
>
>>+Provides: cogito = %{version}
>
> This provides is not necessary, rpm will figure this out by itself.
>
Eh, right. That shouldn't have been there.
Update included.
-hpa
[-- Attachment #2: cogito.spec.patch --]
[-- Type: text/x-patch, Size: 4354 bytes --]
Index: Makefile
===================================================================
--- 3974261da777f55a7a11aff6e02f584bbfe2b475/Makefile (mode:100644)
+++ d486ada2c4c7abf6bc32bed730e18f46f9dc6cd2/Makefile (mode:100644)
@@ -125,7 +125,7 @@
@chmod +x $@
endif
-git.spec: git.spec.in $(VERSION)
+cogito.spec: cogito.spec.in $(VERSION)
sed -e 's/@@VERSION@@/$(shell cat $(VERSION) | cut -d"-" -f2)/g' < $< > $@
@@ -155,5 +155,8 @@
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
+distclean: clean
+ find . -name \*~ -print0 | xargs -0rt rm -f
+
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
Index: cogito.spec.in
===================================================================
--- /dev/null (tree:3974261da777f55a7a11aff6e02f584bbfe2b475)
+++ d486ada2c4c7abf6bc32bed730e18f46f9dc6cd2/cogito.spec.in (mode:100644)
@@ -0,0 +1,60 @@
+Name: cogito
+Version: @@VERSION@@
+Release: 1
+Vendor: Petr Baudis <pasky@ucw.cz>
+Summary: Git core and tools
+License: GPL
+Group: Development/Tools
+URL: http://kernel.org/pub/software/scm/cogito/
+Source: http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.bz2
+Obsoletes: git
+BuildRequires: zlib-devel, openssl-devel, curl-devel
+BuildRoot: %{_tmppath}/%{name}-%{version}-root
+Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
+
+%description
+GIT comes in two layers. The bottom layer is merely an extremely fast
+and flexible filesystem-based database designed to store directory trees
+with regard to their history. The top layer is a SCM-like tool which
+enables human beings to work with the database in a manner to a degree
+similar to other SCM tools (like CVS, BitKeeper or Monotone).
+
+%prep
+%setup -q
+
+%build
+
+make
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} install
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root)
+/usr/bin/*
+/usr/lib/cogito
+%doc README COPYING Documentation/*
+
+%changelog
+* Mon May 9 2005 H. Peter Anvin <hpa@zytor.com> 0.10-1
+- New upstream revision
+- Rename spec file to cogito.spec
+
+* Wed Apr 27 2005 Terje Rosten <terje.rosten@ntnu.no> 0.8-2
+- Doc files
+- Use %%{_prefix} macro
+- Rename spec file
+- Drop -n option to %%setup macro
+
+* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.8-1
+- Update to cogito, rename package, move to /usr/bin, update prereqs
+
+* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.7-1
+- Update to 0.7
+
+* Thu Apr 21 2005 Chris Wright <chrisw@osdl.org> 0.6.3-1
+- Initial rpm build
Index: git.spec.in
===================================================================
--- 3974261da777f55a7a11aff6e02f584bbfe2b475/git.spec.in (mode:100644)
+++ /dev/null (tree:d486ada2c4c7abf6bc32bed730e18f46f9dc6cd2)
@@ -1,55 +0,0 @@
-Name: cogito
-Version: @@VERSION@@
-Release: 2
-Vendor: Petr Baudis <pasky@ucw.cz>
-Summary: Git core and tools
-License: GPL
-Group: Development/Tools
-URL: http://kernel.org/pub/software/scm/cogito/
-Source: http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.bz2
-Provides: cogito = %{version}
-Obsoletes: git
-BuildRequires: zlib-devel, openssl-devel, curl-devel
-BuildRoot: %{_tmppath}/%{name}-%{version}-root
-Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
-
-%description
-GIT comes in two layers. The bottom layer is merely an extremely fast
-and flexible filesystem-based database designed to store directory trees
-with regard to their history. The top layer is a SCM-like tool which
-enables human beings to work with the database in a manner to a degree
-similar to other SCM tools (like CVS, BitKeeper or Monotone).
-
-%prep
-%setup -q
-
-%build
-
-make
-
-%install
-rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} install
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-%files
-%defattr(-,root,root)
-/usr/bin/*
-%doc README README.reference COPYING Changelog
-
-%changelog
-* Wed Apr 27 2005 Terje Rosten <terje.rosten@ntnu.no> 0.8-2
-- Doc files
-- Use %%{_prefix} macro
-- Drop -n option to %%setup macro
-
-* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.8-1
-- Update to cogito, rename package, move to /usr/bin, update prereqs
-
-* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.7-1
-- Update to 0.7
-
-* Thu Apr 21 2005 Chris Wright <chrisw@osdl.org> 0.6.3-1
-- Initial rpm build
^ permalink raw reply
* kernel.org upgraded to cogito-0.10
From: H. Peter Anvin @ 2005-05-09 14:17 UTC (permalink / raw)
To: Git Mailing List, Kay Sievers
I have installed cogito-0.10 on the kernel.org machines.
-hpa
^ permalink raw reply
* [PATCH Cogito] .spec file update
From: H. Peter Anvin @ 2005-05-09 14:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, chrisw
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
This patch updates the spec file to match Cogito 0.10, and changes its
name to cogito.spec.
It would be *really* appreciated if "make cogito.spec" could be made
part of the release procedure so it's included in the tarballs.
[ChrisW: we need this, so I'm going to take the liberty of uploading the
corresponding RPM.]
-hpa
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: cogito.spec.patch --]
[-- Type: text/x-patch, Size: 4386 bytes --]
Index: Makefile
===================================================================
--- 3974261da777f55a7a11aff6e02f584bbfe2b475/Makefile (mode:100644)
+++ 23305c6f40abf5723f28f7ec79a8cdf3ada78f6e/Makefile (mode:100644)
@@ -125,7 +125,7 @@
@chmod +x $@
endif
-git.spec: git.spec.in $(VERSION)
+cogito.spec: cogito.spec.in $(VERSION)
sed -e 's/@@VERSION@@/$(shell cat $(VERSION) | cut -d"-" -f2)/g' < $< > $@
@@ -155,5 +155,8 @@
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
+distclean: clean
+ find . -name \*~ -print0 | xargs -0rt rm -f
+
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
Index: cogito.spec.in
===================================================================
--- /dev/null (tree:3974261da777f55a7a11aff6e02f584bbfe2b475)
+++ 23305c6f40abf5723f28f7ec79a8cdf3ada78f6e/cogito.spec.in (mode:100644)
@@ -0,0 +1,61 @@
+Name: cogito
+Version: @@VERSION@@
+Release: 1
+Vendor: Petr Baudis <pasky@ucw.cz>
+Summary: Git core and tools
+License: GPL
+Group: Development/Tools
+URL: http://kernel.org/pub/software/scm/cogito/
+Source: http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.bz2
+Provides: cogito = %{version}
+Obsoletes: git
+BuildRequires: zlib-devel, openssl-devel, curl-devel
+BuildRoot: %{_tmppath}/%{name}-%{version}-root
+Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
+
+%description
+GIT comes in two layers. The bottom layer is merely an extremely fast
+and flexible filesystem-based database designed to store directory trees
+with regard to their history. The top layer is a SCM-like tool which
+enables human beings to work with the database in a manner to a degree
+similar to other SCM tools (like CVS, BitKeeper or Monotone).
+
+%prep
+%setup -q
+
+%build
+
+make
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} install
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root)
+/usr/bin/*
+/usr/lib/cogito
+%doc README COPYING Documentation/*
+
+%changelog
+* Mon May 9 2005 H. Peter Anvin <hpa@zytor.com> 0.10-1
+- New upstream revision
+- Rename spec file to cogito.spec
+
+* Wed Apr 27 2005 Terje Rosten <terje.rosten@ntnu.no> 0.8-2
+- Doc files
+- Use %%{_prefix} macro
+- Rename spec file
+- Drop -n option to %%setup macro
+
+* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.8-1
+- Update to cogito, rename package, move to /usr/bin, update prereqs
+
+* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.7-1
+- Update to 0.7
+
+* Thu Apr 21 2005 Chris Wright <chrisw@osdl.org> 0.6.3-1
+- Initial rpm build
Index: git.spec.in
===================================================================
--- 3974261da777f55a7a11aff6e02f584bbfe2b475/git.spec.in (mode:100644)
+++ /dev/null (tree:23305c6f40abf5723f28f7ec79a8cdf3ada78f6e)
@@ -1,55 +0,0 @@
-Name: cogito
-Version: @@VERSION@@
-Release: 2
-Vendor: Petr Baudis <pasky@ucw.cz>
-Summary: Git core and tools
-License: GPL
-Group: Development/Tools
-URL: http://kernel.org/pub/software/scm/cogito/
-Source: http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.bz2
-Provides: cogito = %{version}
-Obsoletes: git
-BuildRequires: zlib-devel, openssl-devel, curl-devel
-BuildRoot: %{_tmppath}/%{name}-%{version}-root
-Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
-
-%description
-GIT comes in two layers. The bottom layer is merely an extremely fast
-and flexible filesystem-based database designed to store directory trees
-with regard to their history. The top layer is a SCM-like tool which
-enables human beings to work with the database in a manner to a degree
-similar to other SCM tools (like CVS, BitKeeper or Monotone).
-
-%prep
-%setup -q
-
-%build
-
-make
-
-%install
-rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} install
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-%files
-%defattr(-,root,root)
-/usr/bin/*
-%doc README README.reference COPYING Changelog
-
-%changelog
-* Wed Apr 27 2005 Terje Rosten <terje.rosten@ntnu.no> 0.8-2
-- Doc files
-- Use %%{_prefix} macro
-- Drop -n option to %%setup macro
-
-* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.8-1
-- Update to cogito, rename package, move to /usr/bin, update prereqs
-
-* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.7-1
-- Update to 0.7
-
-* Thu Apr 21 2005 Chris Wright <chrisw@osdl.org> 0.6.3-1
-- Initial rpm build
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: H. Peter Anvin @ 2005-05-09 13:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, Linus Torvalds, git
In-Reply-To: <7vacn6ak7r.fsf@assigned-by-dhcp.cox.net>
Naming the environment variables SHA1_FILE_<anything> is almost
certainly wrong; a much more logical name would be GIT_<something>.
It'd also be much less likely to cause conflicts.
-hpa
^ permalink raw reply
* Re: [PATCH] Add cg-printenv command.
From: Steven Cole @ 2005-05-09 13:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sean, Junio C Hamano, Marcel Holtmann, git
In-Reply-To: <20050509072438.GB3599@pasky.ji.cz>
Petr Baudis wrote:
> Dear diary, on Mon, May 09, 2005 at 05:59:59AM CEST, I got a letter
> where Steven Cole <elenstev@mesatop.com> told me that...
>
>>On Sunday 08 May 2005 09:40 pm, Sean wrote:
>>
>>>On Sun, May 8, 2005 11:25 pm, Steven Cole said:
>>>
>>>
>>>>I had intended it only as a quick check by an end-user before doing
>>>>a commit that the values had been set as desired.
>>>
>>>Hey Steven,
>>>
>>>Rather than creating a separate command, perhaps the values could
>>>automatically be added to the initial commit message in a few "CG:" lines?
>
>
> I was already thinking about this and I think Sean's way makes more
> sense. Also, I actually believe you should add this functionality to
> commit-tree instead (commit-tree -n (dry-run), perhaps?) - so that the
> user can actually check the default values commit-tree is going to use
> too. *That* would be useful.
I agree that having a --dry-run option here would be useful. I frequently
use the 't' option when untarring an unfamiliar tarball.
>
>
>>A secondary reason for adding the cg-printenv capability was that a user would
>>see this command in the cg-help list, and cg-help printenv would give:
>
>
> No, I think this sucks. You should just list the variables in cg-commit
> documentation if anything. That's where they matter anyway and where the
> user could possibly look for them anyway.
OK. David has done a good job of documenting this in the git-commit-tree
section of Documentation/core-git.txt, and here is the information again in
the comment header for cg-commit.
That's the way of open source. Post an idea, and any number of superior
implementations come rolling in.
--------
Add comments to cg-commit to point out usage of git environment variables.
Signed-off-by: Steven Cole <elenstev@mesatop.com>
===================================================================
--- 3974261da777f55a7a11aff6e02f584bbfe2b475/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -13,6 +13,16 @@
# appended to a single commit message, each as separate paragraph.
# -e forces the editor to be brought up even when -m parameters were
# passed to cg-commit.
+#
+#These git environment variables are used in case
+#values other than that returned by getpwuid(getuid())
+#are desired when performing a commit.
+#
+#AUTHOR_NAME Author's name
+#AUTHOR_EMAIL Author's e-mail address
+#AUTHOR_DATE Date, perhaps from a patch e-mail
+#COMMIT_AUTHOR_NAME Committer's name
+#COMMIT_AUTHOR_EMAIL Committer's e-mail address
. ${COGITO_LIB}cg-Xlib
^ permalink raw reply
* Re: Pointers to CVS 2 GIT imports and gateways
From: H. Peter Anvin @ 2005-05-09 13:30 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f905050822413ece89b9@mail.gmail.com>
Martin Langhoff wrote:
>
> Ease of transition for other automated tasks, perhaps? I don't know
> what bits and pieces of infrastructure hang from the old BK-CVS
> changeset distribution infrastructure.
>
None. That was all owned by Bitmover.
-hpa
^ 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