* 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
* Re: cg-log patches
From: Sean @ 2005-05-09 13:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jonas Fonseca, GIT Mailing List
In-Reply-To: <20050509121435.GB18382@pasky.ji.cz>
On Mon, May 9, 2005 8:14 am, Petr Baudis said:
> But that makes no sense, since each merge will have enormous amount of
> files listed, making no sense. E.g. each merge of Cogito with Linus will
> have all the Cogito files listed, since they aren't in the Linus branch
> - but that's wrong, since the merge _to_ the Cogito branch concerns no
> Cogito files.
>
> In git, the parents list is unordered. But this is different in Cogito,
> where the first parent _is_ special. If you are merging _from_ branch B
> _to_ branch A, the order of parents will be always
But, there are commits (even in your tree) that aren't produced by Cogito.
And the current logic gets them wrong.
Look at commit: 211232bae64bcc60bbf5d1b5e5b2344c22ed767e in your tree.
The current logic will miss the fact that one of the other parents
altered, git-apply-patch-script. Seems better to over report, than under
report changes, although I agree that some way must be found to handle the
merge case.
Sean
^ permalink raw reply
* Re: cg-log patches
From: Jonas Fonseca @ 2005-05-09 12:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sean, GIT Mailing List
In-Reply-To: <20050509121435.GB18382@pasky.ji.cz>
Petr Baudis <pasky@ucw.cz> wrote Mon, May 09, 2005:
> Dear diary, on Mon, May 09, 2005 at 01:39:07PM CEST, I got a letter
> where Jonas Fonseca <fonseca@diku.dk> told me that...
> > Fix cg-log -f option so that a complete list of files is
> > displayed when a commit has more than one parent.
> >
> > Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> But that makes no sense, since each merge will have enormous amount of
> files listed, making no sense. E.g. each merge of Cogito with Linus will
> have all the Cogito files listed, since they aren't in the Linus branch
> - but that's wrong, since the merge _to_ the Cogito branch concerns no
> Cogito files.
>
> In git, the parents list is unordered. But this is different in Cogito,
> where the first parent _is_ special. If you are merging _from_ branch B
> _to_ branch A, the order of parents will be always
>
> parent A
> parent B
Ok, forget the patch then. I was not sure how to handle the multiple parents.
> > Index: cg-log
> > ===================================================================
> > --- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log (mode:100755)
> > +++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log (mode:100755)
> > @@ -67,8 +67,16 @@
> > done
> > fi | sort -u | \
> > while read modes type sha1s file; do
> > - echo -n "$sep$file"
# Always put a trailing comma
> > + echo -n "$sep"
> > sep=", "
> > + if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
> > + line="$line$sep$file"
> > + echo -n "$file"
> > + else
> > + line="$file"
> > + echo "$coldefault"
> > + echo -n " $colfiles$file"
> > + fi
> > done
> > echo "$coldefault:"
> > }
>
> Could we have a trailing comma at the previous line?
It should already do that ..
committer Petr Baudis <xpasky@machine.sinus.cz> Sun, 08 May 2005 23:54:08 +0200
* cg-Xlib, cg-update, cg-seek, cg-pull, cg-tag-ls, cg-branch-ls, cg-merge,
cg-commit, cg-tag, cg-init, cg-branch-add, cg-admin-lsobj, cg-status,
cg-cancel, cg-admin-uncommit:
--
Jonas Fonseca
^ permalink raw reply
* Re: cg-log patches
From: Petr Baudis @ 2005-05-09 12:14 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Sean, GIT Mailing List
In-Reply-To: <20050509113907.GA22830@diku.dk>
Dear diary, on Mon, May 09, 2005 at 01:39:07PM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> Fix cg-log -f option so that a complete list of files is
> displayed when a commit has more than one parent.
>
> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
But that makes no sense, since each merge will have enormous amount of
files listed, making no sense. E.g. each merge of Cogito with Linus will
have all the Cogito files listed, since they aren't in the Linus branch
- but that's wrong, since the merge _to_ the Cogito branch concerns no
Cogito files.
In git, the parents list is unordered. But this is different in Cogito,
where the first parent _is_ special. If you are merging _from_ branch B
_to_ branch A, the order of parents will be always
parent A
parent B
In practice, it does not make too much difference, but this is one of
the cases where it makes difference. So I think the current behaviour is
right.
BTW, this also implies that merges
A --
\
B ---+--
and
A ---+--
/
B --
are considered as different ones by Cogito; in git itself, you might
model that as
A --.
>---
B --'
which is not possible in Cogito. I could imagine doing it by e.g.
passing cg-clone multiple arguments, but I'd have to first see a
compelling real-world usage for this first.
> Index: cg-log
> ===================================================================
> --- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log (mode:100755)
> +++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log (mode:100755)
> @@ -67,8 +67,16 @@
> done
> fi | sort -u | \
> while read modes type sha1s file; do
> - echo -n "$sep$file"
> + echo -n "$sep"
> sep=", "
> + if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
> + line="$line$sep$file"
> + echo -n "$file"
> + else
> + line="$file"
> + echo "$coldefault"
> + echo -n " $colfiles$file"
> + fi
> done
> echo "$coldefault:"
> }
Could we have a trailing comma at the previous line?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-log patches
From: Jonas Fonseca @ 2005-05-09 11:39 UTC (permalink / raw)
To: Sean; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <4302.10.10.10.24.1115610350.squirrel@linux1>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
Sean <seanlkml@sympatico.ca> wrote Sun, May 08, 2005:
> On Sun, May 8, 2005 7:49 pm, Jonas Fonseca said:
> Hey Jonas,
Hi Sean,
> >> Fix cg-log -f option so that a complete list of files is
> >> displayed when a commit has more than one parent.
> >
> > This sounds great.
>
> You might want to rip it out and submit it, because it's not likely to see
> the light of day otherwise.
I ripped it out and made a patch only with the fix.
Pasky, I also updated the line-wrapping patch if you want it.
> > The reason I put it at the top was to make it more similar to GNU-style
> > changelogs (if there is such a style).
>
> Yeah, I felt a bit guilty sliding that shift in, really I had no rationale
> other than it looked better _to me_.
I don't feel strong about it. I guess I have just gotten used to it that
way.
--
Jonas Fonseca
[-- Attachment #2: fix-cg-log.patch --]
[-- Type: text/plain, Size: 2218 bytes --]
Fix cg-log -f option so that a complete list of files is
displayed when a commit has more than one parent.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 06a6b40f8e52eff0e34706c7024b54df50abb6b9
tree 95bc73fd188347aa294991d1c5c7cffd60422098
parent 4ed293bc0a5ffca9683e139cad499b69a4c4d569
author jonas <fonseca@diku.dk> Mon, 09 May 2005 13:23:20 +0200
committer jonas <fonseca@diku.dk> Mon, 09 May 2005 13:23:20 +0200
cg-log | 34 +++++++++++++++-------------------
1 files changed, 15 insertions(+), 19 deletions(-)
Index: cg-log
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-log (mode:100755)
+++ 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log (mode:100755)
@@ -53,17 +53,20 @@
list_commit_files()
{
- tree1="$1"
- tree2="$2"
+ tree="$1"
sep=" * $colfiles"
- # List all files for for the initial commit
- if [ -z $tree2 ]; then
- list_cmd="git-ls-tree $tree1"
- else
- list_cmd="git-diff-tree -r $tree1 $tree2"
- fi
echo
- $list_cmd | while read modes type sha1s file; do
+ if [ -z $2 ]; then
+ # List all files for the initial commit
+ git-ls-tree $tree
+ else
+ shift
+ # List changes from each parent
+ for parent; do
+ git-diff-tree -r $tree $parent
+ done
+ fi | sort -u | \
+ while read modes type sha1s file; do
echo -n "$sep$file"
sep=", "
done
@@ -102,8 +105,7 @@
$revls | $revsort | while read time commit parents; do
trap exit SIGPIPE
- tree1=
- tree2=
+ trees=
[ "$revfmt" = "git-rev-list" ] && commit="$time"
if [ $# -ne 0 ]; then
parent=$(git-cat-file commit $commit | sed -n '2s/parent //p;2Q')
@@ -131,17 +133,11 @@
fi
;;
"tree"|"parent")
- if [ -z $tree1 ]; then
- tree1=$rest
- elif [ -z $tree2 ]; then
- tree2=$rest
- fi
+ trees="$trees $rest"
echo $colheader$key $rest $coldefault
;;
"")
- if [ -n "$list_files" ]; then
- list_commit_files "$tree1" "$tree2"
- fi
+ [ -n "$list_files" ] && list_commit_files $trees
echo; sed -re '
/ *Signed-off-by:.*/Is//'$colsignoff'&'$coldefault'/
/ *Acked-by:.*/Is//'$colsignoff'&'$coldefault'/
[-- Attachment #3: wrap-file-listing-lines.patch --]
[-- Type: text/plain, Size: 1030 bytes --]
Wrap file listing lines near the 80th column.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 9d86f44f7d1eee525ed4c45731ad07b95f62dbb6
tree ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8
parent 06a6b40f8e52eff0e34706c7024b54df50abb6b9
author jonas <fonseca@diku.dk> Mon, 09 May 2005 13:27:20 +0200
committer jonas <fonseca@diku.dk> Mon, 09 May 2005 13:27:20 +0200
cg-log | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletion(-)
Index: cg-log
===================================================================
--- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log (mode:100755)
+++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log (mode:100755)
@@ -67,8 +67,16 @@
done
fi | sort -u | \
while read modes type sha1s file; do
- echo -n "$sep$file"
+ echo -n "$sep"
sep=", "
+ if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
+ line="$line$sep$file"
+ echo -n "$file"
+ else
+ line="$file"
+ echo "$coldefault"
+ echo -n " $colfiles$file"
+ fi
done
echo "$coldefault:"
}
^ permalink raw reply
* Re: Prototype git commit viewer
From: Benjamin Herrenschmidt @ 2005-05-09 9:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Paul Mackerras, git
In-Reply-To: <20050509071341.GA3599@pasky.ji.cz>
>
> What are its advantages to git-viz?
I haven't looked at git-viz in details, but from the screen-shot, I can
say I prefer paulus one :)
But heh, since when should we limit ourselves to a single tool to do a
given job ? :)
^ permalink raw reply
* Re: [RFC] allow file list editing during cg-commit
From: Petr Baudis @ 2005-05-09 8:46 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Eugene Surovegin, git
In-Reply-To: <1115627229.8949.132.camel@pegasus>
Dear diary, on Mon, May 09, 2005 at 10:27:09AM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Eugene,
Hello,
> > 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.
>
> do you know any SCM native text interface that supports such a thing? In
> general this is done by high-level GUI based interfaces to the SCM or a
> special Emacs mode etc.
so what? I still think the idea is cool, why shouldn't support it if
noone else does?
The only thing to watch out for is that cg-commit -C produces no such
list at all; it should deal with that and tell the user he is not going
to be able to control what is going to be committed then.
Another thing is that at the moment you modify the file list, you should
set customfiles - otherwise you will commit even cg-adds and cg-rms of
files you didn't select. But do that really only when you change the
file list, since it is more expensive.
You should also place an appropriate hint near the CG: lines, saying
that removing some of them will limit the list of files to be committed.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ 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