* [PATCH 1/3] git-commit-script: get commit message from an existing one.
From: Junio C Hamano @ 2005-06-23 23:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v4qbofym7.fsf_-_@assigned-by-dhcp.cox.net>
With -m flag specified, git-commit-script takes the commit
message along with author information from an existing commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Linus, I suspect that date.c mishandles the raw date; I am
*** consistently getting 7 hours off and my machine runs in
*** US/Pacific (-0700) timezone.
git-commit-script | 75 +++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -1,12 +1,37 @@
#!/bin/sh
+#
+# Copyright (c) 2005 Linus Torvalds
+#
+
+usage () {
+ echo 'git commit [-m existing-commit] [<path>...]'
+ exit 1
+}
+
: ${GIT_DIR=.git}
-if [ ! -d $GIT_DIR ]; then
+if [ ! -d "$GIT_DIR" ]; then
echo Not a git directory 1>&2
exit 1
fi
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ -m) shift
+ case "$#" in
+ 0) usage ;;
+ *) use_commit=`git-rev-parse "$1"` ||
+ exit ;;
+ esac
+ ;;
+ *) break
+ ;;
+ esac
+ shift
+done
+
git-update-cache -q --refresh -- "$@" || exit 1
PARENTS="-p HEAD"
-if [ ! -r $GIT_DIR/HEAD ]; then
+if [ ! -r "$GIT_DIR/HEAD" ]; then
if [ -z "$(git-ls-files)" ]; then
echo Nothing to commit 1>&2
exit 1
@@ -20,7 +45,7 @@ if [ ! -r $GIT_DIR/HEAD ]; then
) > .editmsg
PARENTS=""
else
- if [ -f $GIT_DIR/MERGE_HEAD ]; then
+ if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
echo "#"
echo "# It looks like your may be committing a MERGE."
echo "# If this is not correct, please remove the file"
@@ -28,8 +53,38 @@ else
echo "# and try again"
echo "#"
PARENTS="-p HEAD -p MERGE_HEAD"
- fi > .editmsg
- git-status-script >> .editmsg
+ elif test "$use_commit" != ""
+ then
+ pick_author_script='
+ /^author /{
+ h
+ s/^author \([^<]*\) <[^>]*> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_NAME='\''&'\''/p
+
+ g
+ s/^author [^<]* <\([^>]*\)> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
+
+ g
+ s/^author [^<]* <[^>]*> \(.*\)$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_DATE='\''&'\''/p
+
+ q
+ }
+ '
+ set_author_env=`git-cat-file commit "$use_commit" |
+ sed -ne "$pick_author_script"`
+ eval "$set_author_env"
+ export GIT_AUTHOR_NAME
+ export GIT_AUTHOR_EMAIL
+ export GIT_AUTHOR_DATE
+ git-cat-file commit "$use_commit" |
+ sed -e '1,/^$/d'
+ fi >.editmsg
+ git-status-script >>.editmsg
fi
if [ "$?" != "0" ]
then
@@ -37,13 +92,17 @@ then
rm .editmsg
exit 1
fi
-${VISUAL:-${EDITOR:-vi}} .editmsg
+case "$use_commit" in
+'')
+ ${VISUAL:-${EDITOR:-vi}} .editmsg
+ ;;
+esac
grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
[ -s .cmitmsg ] &&
tree=$(git-write-tree) &&
commit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS) &&
- echo $commit > $GIT_DIR/HEAD &&
- rm -f -- $GIT_DIR/MERGE_HEAD
+ echo $commit > "$GIT_DIR/HEAD" &&
+ rm -f -- "$GIT_DIR/MERGE_HEAD"
ret="$?"
rm -f .cmitmsg .editmsg
exit "$ret"
------------
^ permalink raw reply
* [PATCH 2/3] git-cherry: find commits not merged upstream.
From: Junio C Hamano @ 2005-06-23 23:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v4qbofym7.fsf_-_@assigned-by-dhcp.cox.net>
This script helps the git-rebase script by finding commits that
have not been merged upstream.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 +
git-cherry | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 91 insertions(+), 1 deletions(-)
create mode 100755 git-cherry
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -25,7 +25,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-deltafy-script git-fetch-script git-status-script git-commit-script \
git-log-script git-shortlog git-cvsimport-script git-diff-script \
git-reset-script git-add-script git-checkout-script git-clone-script \
- gitk
+ gitk git-cherry
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-cherry b/git-cherry
new file mode 100755
--- /dev/null
+++ b/git-cherry
@@ -0,0 +1,90 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano.
+#
+
+usage="usage: $0 "'<upstream> [<head>]
+
+ __*__*__*__*__> <upstream>
+ /
+ fork-point
+ \__+__+__+__+__+__+__+__> <head>
+
+Each commit between the fork-point and <head> is examined, and
+compared against the change each commit between the fork-point and
+<upstream> introduces. If the change does not seem to be in the
+upstream, it is shown on the standard output.
+
+The output is intended to be used as:
+
+ OLD_HEAD=$(git-rev-parse HEAD)
+ git-rev-parse linus >${GIT_DIR-.}/HEAD
+ git-cherry linus OLD_HEAD |
+ while read commit
+ do
+ GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p "$commit" &&
+ git-commit-script -m "$commit"
+ done
+'
+
+case "$#" in
+1) linus=`git-rev-parse "$1"` &&
+ junio=`git-rev-parse HEAD` || exit
+ ;;
+2) linus=`git-rev-parse "$1"` &&
+ junio=`git-rev-parse "$2"` || exit
+ ;;
+*) echo >&2 "$usage"; exit 1 ;;
+esac
+
+# Note that these list commits in reverse order;
+# not that the order in inup matters...
+inup=`git-rev-list ^$junio $linus` &&
+ours=`git-rev-list $junio ^$linus` || exit
+
+tmp=.cherry-tmp$$
+patch=$tmp-patch
+diff=$tmp-diff
+mkdir $patch
+trap "rm -rf $tmp-*" 0 1 2 3 15
+
+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+
+for c in $inup $ours
+do
+ git-diff-tree -p $c |
+ sed -e "/^$_x40 (from $_x40)\$/d;/^--- /d;/^+++ /d;/^@@ /d" >$patch/$c
+ git-diff-tree -r $c |
+ sed -e "/^$_x40 (from $_x40)\$/d;s/ $_x40 $_x40 / X X /" >$patch/$c.s
+done
+
+LF='
+'
+O=
+for c in $ours
+do
+ found=
+ for d in $inup
+ do
+ cmp $patch/$c.s $patch/$d.s >/dev/null ||
+ continue
+
+ diff --unified=0 $patch/$c $patch/$d >$diff
+ cmp /dev/null $diff >/dev/null && {
+ found=t
+ break
+ }
+ done
+ case "$found,$O" in
+ t,*) ;;
+ ,)
+ O="$c" ;;
+ ,*)
+ O="$c$LF$O" ;;
+ esac
+done
+case "$O" in
+'') ;;
+*) echo "$O" ;;
+esac
------------
^ permalink raw reply
* [PATCH 3/3] git-rebase-script: rebase local commits to new upstream head.
From: Junio C Hamano @ 2005-06-23 23:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v4qbofym7.fsf_-_@assigned-by-dhcp.cox.net>
Using git-cherry, forward port local commits missing from the
new upstream head. This depends on "-m" flag support in
git-commit-script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 +-
git-rebase-script | 46 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 1 deletions(-)
create mode 100755 git-rebase-script
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -25,7 +25,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-deltafy-script git-fetch-script git-status-script git-commit-script \
git-log-script git-shortlog git-cvsimport-script git-diff-script \
git-reset-script git-add-script git-checkout-script git-clone-script \
- gitk git-cherry
+ gitk git-cherry git-rebase-script
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-rebase-script b/git-rebase-script
new file mode 100755
--- /dev/null
+++ b/git-rebase-script
@@ -0,0 +1,46 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano.
+#
+
+usage="usage: $0 "'<upstream> [<head>]
+
+Uses output from git-cherry to rebase local commits to the new head of
+upstream tree.'
+
+: ${GIT_DIR=.git}
+
+case "$#" in
+1) linus=`git-rev-parse "$1"` &&
+ junio=`git-rev-parse HEAD` || exit
+ ;;
+2) linus=`git-rev-parse "$1"` &&
+ junio=`git-rev-parse "$2"` || exit
+ ;;
+*) echo >&2 "$usage"; exit 1 ;;
+esac
+
+git-read-tree -m -u $junio $linus &&
+echo "$linus" >"$GIT_DIR/HEAD" || exit
+
+tmp=.rebase-tmp$$
+fail=$tmp-fail
+trap "rm -rf $tmp-*" 0 1 2 3 15
+
+>$fail
+
+git-cherry $linus $junio |
+while read commit
+do
+ S=`cat "$GIT_DIR/HEAD"` &&
+ GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p $commit &&
+ git-commit-script -m "$commit" || {
+ echo $commit >>$fail
+ git-read-tree --reset -u $S
+ }
+done
+if test -s $fail
+then
+ echo Some commits could not be rebased, check by hand:
+ cat $fail
+fi
------------
^ permalink raw reply
* Mercurial vs Updated git HOWTO for kernel hackers
From: Matt Mackall @ 2005-06-23 23:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List, mercurial
In-Reply-To: <42B9E536.60704@pobox.com>
On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
>
> Things in git-land are moving at lightning speed, and usability has
> improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
And here's a quick comparison with the current state of Mercurial..
> 1) installing git
>
> git requires bootstrapping, since you must have git installed in order
> to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> have put together a bootstrap tarball of today's git repository.
>
> Download tarball from:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
>
> tarball build-deps: zlib, libcurl, libcrypto (openssl)
>
> install tarball: unpack && make && sudo make prefix=/usr/local install
>
> jgarzik helper scripts, not in official git distribution:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
>
> After reading the rest of this document, come back and update your copy
> of git to the latest:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
Download from: http://selenic.com/mercurial/mercurial-snapshot.tar.gz
Build-deps: Python 2.3
Install: unpack && python setup.py install [--home=/usr/local]
> 2) download a linux kernel tree for the very first time
>
> $ mkdir -p linux-2.6/.git
> $ cd linux-2.6
> $ rsync -a --delete --verbose --stats --progress \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> \ <- word-wrapped backslash; sigh
> .git/
$ mkdir linux-2.6
$ cd linux-2.6
$ hg init http://www.kernel.org/hg/ # obviously you can also browse this
This downloads about 125M of data, which include the whole kernel history
back to 2.4.0 and everything in Linus' git repo as well.
> 3) update local kernel tree to latest 2.6.x upstream ("fast-forward merge")
>
> $ cd linux-2.6
> $ git-pull-script \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ hg pull # defaults to where you originally pulled from
It takes about 4M of transfer and well under a minute to pull the
entire git history, starting from a base of 2.6.12-rc2.
> 4) check out files from the git repository into the working directory
>
> $ git checkout -f
$ hg update # or up or checkout or co, depending on your SCM habits
> 5) check in your own modifications (e.g. do some hacking, or apply a patch)
>
> # go to repo
> $ cd linux-2.6
>
> # make some modifications
> $ patch -sp1 < /tmp/my.patch
> $ diffstat -p1 < /tmp/my.patch
>
> # NOTE: add '--add' and/or '--remove' if files were added or removed
> $ git-update-cache <list of all files changed>
>
> # check in changes
> $ git commit
$ hg commit [files] # check in everything changed or just the named files
5.1) undo the last commit or pull
$ hg undo
> 6) List all changes in working dir, in diff format.
>
> $ git-diff-cache -p HEAD
$ hg status # show changed files
> 7) List all changesets (i.e. show each cset's description text) in local
> branch of local tree, that are not present in remote tree.
>
> $ cd my-kernel-tree-2.6
> $ git-changes-script -L ../linux-2.6 | less
$ hg history | less # How does git know what's not in the
# remote tree? Psychic?
> 8) List all changesets:
>
> $ git-whatchanged
$ hg history | less
> 9) apply all patches in a Berkeley mbox-format file
>
> First, download and add to your PATH Linus's git tools:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git
>
> $ cd my-kernel-tree-2.6
> $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts
hg doesn't do mboxes directly, but you can do:
$ cat patch-list | xargs hg import
> 10) don't forget to download tags from time to time.
>
> git-pull-script only downloads sha1-indexed object data, and the
> requested remote head. This misses updates to the .git/refs/tags/ and
> .git/refs/heads directories. It is advisable to update your kernel .git
> directories periodically with a full rsync command, to make sure you got
> everything:
>
> $ cd linux-2.6
> $ rsync -a --delete --verbose --stats --progress \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> \ <- word-wrapped backslash; sigh
> .git/
Tags in mercurial are properly version controlled and come along for
the ride with pulls. Also, the right thing happens with merges.
> 11) list all branches, such as those found in my netdev-2.6 or
> libata-dev trees.
>
> Download
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
> or
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
>
> $ cd netdev-2.6
> $ ls .git/refs/heads/
>
> { these are the current netdev-2.6 branches }
> >8139cp forcedeth master qeth smc91x we18
> >8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi
> >airo hdlc ns83820 register-netdev starfire
> >atmel ieee80211 orinoco remove-drivers tlan
> >chelsio iff-running orinoco-hch sis900 veth
> >dm9000 janitor ppp skge viro
$ hg heads # Has Andrew mentioned your git forest gives him a headache?
> 12) make desired branch current in working directory
>
> $ git checkout -f $branch
$ hg update -C <rev or id or tag>
> 13) create a new branch, and make it current
>
> $ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name
> $ git checkout -f my-new-branch-name
Since the hg repo is lightweight, this is usually done by just having
different directories. Thus we don't explicitly name branches.
$ mkdir new-branch
$ cd new-branch
$ hg init -u ../linux # makes hardlinks and does a checkout
> 14) examine which branch is current
>
> $ ls -l .git/HEAD
$ echo $PWD
> 15) undo all local modifications (same as checkout):
>
> $ git checkout -f
$ hg update -C
> 16) obtain a diff between current branch, and master branch
>
> In most trees WITH BRANCHES, .git/refs/heads/master contains the current
> 'vanilla' upstream tree, for easy diffing and merging. (in trees
> without branches, 'master' simply contains your latest changes)
>
> $ git-diff-tree -p master HEAD
$ hg diff -r <rev> -r <rev>
17) run a browsable, pullable repo server of the current repo on your
local machine
$ hg serve
18) push your changes to a remote server
$ hg push ssh://user@host/path/ # aliases and defaults in .hgrc
19) get per-file history
$ hg log <file> | less
20) get annotated file contents
$ hg annotate [file]
21) record that a file has been copied or renamed for the next commit
$ hg copy <source> <dest>
22) get online help
$ hg help [command]
More info at http://selenic.com/mercurial/
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: The coolest merge EVER!
From: Junio C Hamano @ 2005-06-24 0:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506221433540.2353@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Now, the advantage of this kind of merge is that Paul's original gitk
LT> repository is totally unaffected by it, yet because I now have his history
LT> (and the exact same objects), the normal kind of git merge should work
LT> fine for me to continue to import Paul's work - we have the common parent
LT> needed to resolve all differences.
This clearly shows that you are in the "project lead" integrator
mindset. Making it easy for you, the integrator, to pull
changes made in Paul's tree is what this "coolest merge ever" is
all about, but I suspect there would be a massive additional
support needed if you want to make it easy for Paul to pull
changes made to gitk in your tree.
I am not saying I do not like it, however, to make it easy for
Paul to pull changes made in your tree relevant only to gitk
part, off the top of my head:
- If a contributor to GIT wants to make a change to gitk that
adds a new file that is used by gitk (say, some common tcl
library thing to be included), we either need to feed them to
Paul and get the changes propagate to you through him, or we
need a way to mark that file somehow belonging to the
development history rooted at gitk root, not GIT root.
- Similarly, if a contributor to GIT wants to make a change to
gitk file itself, feeding the change through Paul to you
would lesson both your burden and Paul's.
- Alternatively Paul can keep track of which files are relevant
to gitk, slurp and merge commits while ignoring the files the
gitk package does not care about. This one would involve
interesting scripting somebody may want to tackle (hint,
hint).
Long time ago I had a discussion with somebody (I vaguely recall
it was with Dan Barkalow but I am not sure) about this exact
issue. He wanted to have a way to distinguish Cogito-only part
and core GIT part in a Cogito source tree, and help developers
feed core changes to you and Cogito changes to Petr.
Back then I dismissed that approach by saying that what is
broken was Cogito's source tree structure, which overlays two
projects that are theoretically separable and practically
managed separately, and it is not worth supporting such a broken
source tree structure. Now you are making GIT source tree such
an overlayed one.
^ permalink raw reply
* Re: Stacked GIT 0.1 (a.k.a. quilt for git)
From: Paul Jackson @ 2005-06-24 0:58 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxy899zzu7.fsf@arm.com>
Interesting idea. Thanks.
I am just firing it up now - noticing a couple of nits:
1) "Unknown" is misspelled as "Unkown" in a couple places.
2) I tried doing an "stg init" in the stgit subtree that I had
just unpacked and installed (python setup.py install). This
did several lines of "Adding ..." and then displayed the
number "16" and sat there. I typed some random guesses at
it, and realized I was inside my $EDITOR=/bin/ed.
Before invoking an editor, it would be a good idea to tell the
user you are doing so. If someone is on a telnet session to
a system with their $DISPLAY set wrong, they might not even
get the terse "16" clue that I got, that they are editing
something.
3) My editor 'ed' exits with non-zero status if I make even the most
trivial editing error. This resulted in this "stg init" failing
with:
stg init: Editor (ed .commitmsg) failed
I'd recommend ignoring the exit status of externally invoked
editors.
4) I tried rerunning that "stg init" without further ado, and it
failed again (due to the incomplete init above, no doubt), with:
Traceback (most recent call last):
File "/usr/bin/stg", line 25, in ?
main()
File "/usr/lib/python2.4/site-packages/stgit/main.py", line 557, in main
command.func(parser, options, args)
File "/usr/lib/python2.4/site-packages/stgit/main.py", line 91, in init
stack.init()
File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 187, in init
patch_dir = get_patch_dir()
File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 36, in get_patch_dir
return os.path.join(git.base_dir, 'patches', git.get_head_file())
File "/usr/lib/python2.4/posixpath.py", line 60, in join
if b.startswith('/'):
AttributeError: 'NoneType' object has no attribute 'startswith'
5) I tried again, doing:
rm -fr .git
stg init
# on the commit message edit - just quit 'q', to avoid any error exit
This failed again, leaving my new git tree in god only knows what bogus state.
It failed with:
stg init: Commit message not modified
I'm getting a little frustrated by now. Guess I will just nuke the .git subtree
and try again, as I have no clue what useful or bogus state this left me in.
Try generating fewer fatal errors, and try giving a tiny clue what state (ok or
not or how bad) one is left in after an apparently fatal error, and for extra
credit, a clue what to do next.
6) Ok - got through the init that time.
Since I am fond of both quilt and Python, and since I need to be using git and/or cogito,
I will poke around some more with this - it's promising.
I see something about a patch emailer on the todo list -- you're welcome to make use of
my patch emailer (I use with quilt, though it's not tightly bound to quilt) at:
http://www.speakeasy.org/~pj99/sgi/sendpatchset
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Petr Baudis @ 2005-06-24 6:41 UTC (permalink / raw)
To: Matt Mackall; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List, mercurial
In-Reply-To: <20050623235634.GC14426@waste.org>
Dear diary, on Fri, Jun 24, 2005 at 01:56:34AM CEST, I got a letter
where Matt Mackall <mpm@selenic.com> told me that...
> On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
> >
> > Things in git-land are moving at lightning speed, and usability has
> > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
>
> And here's a quick comparison with the current state of Mercurial..
And here's a quick back-comparison with Cogito. ;-)
> > 1) installing git
> >
> > git requires bootstrapping, since you must have git installed in order
> > to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> > have put together a bootstrap tarball of today's git repository.
> >
> > Download tarball from:
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
> >
> > tarball build-deps: zlib, libcurl, libcrypto (openssl)
> >
> > install tarball: unpack && make && sudo make prefix=/usr/local install
> >
> > jgarzik helper scripts, not in official git distribution:
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
> >
> > After reading the rest of this document, come back and update your copy
> > of git to the latest:
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
>
> Download from: http://selenic.com/mercurial/mercurial-snapshot.tar.gz
> Build-deps: Python 2.3
> Install: unpack && python setup.py install [--home=/usr/local]
Download from: http://www.kernel.org/pub/software/scm/cogito/
Deps: git's + bash + reasonable shell environment
Install: edit Makefile, make + make install
> > 2) download a linux kernel tree for the very first time
> >
> > $ mkdir -p linux-2.6/.git
> > $ cd linux-2.6
> > $ rsync -a --delete --verbose --stats --progress \
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> > \ <- word-wrapped backslash; sigh
> > .git/
>
> $ mkdir linux-2.6
> $ cd linux-2.6
> $ hg init http://www.kernel.org/hg/ # obviously you can also browse this
$ cg-clone \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
(that will checkout to linux-2.6/ directory; you can specify the target
directory as the optional second parameter)
> > 3) update local kernel tree to latest 2.6.x upstream ("fast-forward merge")
> >
> > $ cd linux-2.6
> > $ git-pull-script \
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> $ hg pull # defaults to where you originally pulled from
$ cg-update # defaults to where you originally pulled from
(cg-pull just gets the changes to your repository, but won't merge them
into your branch)
> > 4) check out files from the git repository into the working directory
> >
> > $ git checkout -f
>
> $ hg update # or up or checkout or co, depending on your SCM habits
In Cogito, all files are always checked out.
> > 5) check in your own modifications (e.g. do some hacking, or apply a patch)
> >
> > # go to repo
> > $ cd linux-2.6
> >
> > # make some modifications
> > $ patch -sp1 < /tmp/my.patch
> > $ diffstat -p1 < /tmp/my.patch
> >
> > # NOTE: add '--add' and/or '--remove' if files were added or removed
> > $ git-update-cache <list of all files changed>
> >
> > # check in changes
> > $ git commit
>
> $ hg commit [files] # check in everything changed or just the named files
$ cg-commit [-m"Message"...] [files] # check in everything changed or just
# the named files
If you pass multiple -m arguments, they get formatted as separate
paragraphs in the log message. It is customary for the first -m argument
to contain a short one-line summary.
Note that you must add/remove files by
$ cg-add files...
and
$ cg-rm files...
> 5.1) undo the last commit or pull
>
> $ hg undo
$ cg-admin-uncommit
Note that you should never do this if you already pushed the changes
out, or someone might get them. (That holds for regular Git too.) See
$ cg-help cg-admin-uncommit # (or cg-admin-uncommit --help)
for details. (That's another Cogito's cool feature. Handy docs! ;-)
> > 6) List all changes in working dir, in diff format.
> >
> > $ git-diff-cache -p HEAD
>
> $ hg status # show changed files
$ cg-status # show changed files
$ cg-diff [-c] [files] # show the diffs, -c colourfully
> > 7) List all changesets (i.e. show each cset's description text) in local
> > branch of local tree, that are not present in remote tree.
> >
> > $ cd my-kernel-tree-2.6
> > $ git-changes-script -L ../linux-2.6 | less
>
> $ hg history | less # How does git know what's not in the
> # remote tree? Psychic?
# -c colourfully, -s prints only summaries, one line per changeset
$ cg-log [-c] [-s] -m -r linux-2.6 # List changes only in linux-2.6
Note that | less is unnecessary (even undesirable with -c).
> > 8) List all changesets:
> >
> > $ git-whatchanged
>
> $ hg history | less
$ cg-log [-c] [-s]
8.1) List all changesets in the origin branch:
$ cg-log [-c] [-s] -r origin
8.2) List all changesets concerning files CREDITS and fs/inode.c:
$ cg-log [-c] [-s] CREDITS fs/inode.c
> > 9) apply all patches in a Berkeley mbox-format file
> >
> > First, download and add to your PATH Linus's git tools:
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git
> >
> > $ cd my-kernel-tree-2.6
> > $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts
>
> hg doesn't do mboxes directly, but you can do:
>
> $ cat patch-list | xargs hg import
Theoretically, dotest should work just fine even if you use Cogito.
Anyone tested it?
> > 10) don't forget to download tags from time to time.
> >
> > git-pull-script only downloads sha1-indexed object data, and the
> > requested remote head. This misses updates to the .git/refs/tags/ and
> > .git/refs/heads directories. It is advisable to update your kernel .git
> > directories periodically with a full rsync command, to make sure you got
> > everything:
> >
> > $ cd linux-2.6
> > $ rsync -a --delete --verbose --stats --progress \
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> > \ <- word-wrapped backslash; sigh
> > .git/
>
> Tags in mercurial are properly version controlled and come along for
> the ride with pulls. Also, the right thing happens with merges.
cg-update and cg-pull takes fetches new tags during a pull.
> > 11) list all branches, such as those found in my netdev-2.6 or
> > libata-dev trees.
> >
> > Download
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
> > or
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> >
> >
> > $ cd netdev-2.6
> > $ ls .git/refs/heads/
> >
> > { these are the current netdev-2.6 branches }
> > >8139cp forcedeth master qeth smc91x we18
> > >8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi
> > >airo hdlc ns83820 register-netdev starfire
> > >atmel ieee80211 orinoco remove-drivers tlan
> > >chelsio iff-running orinoco-hch sis900 veth
> > >dm9000 janitor ppp skge viro
>
> $ hg heads # Has Andrew mentioned your git forest gives him a headache?
$ cg-branch-ls
# Note that Cogito supports only remote branches properly now; that
# will yet evolve (in some backwards-compatible way).
> > 12) make desired branch current in working directory
> >
> > $ git checkout -f $branch
>
> $ hg update -C <rev or id or tag>
You can check the desired branch out into another directory:
$ cg-clone path/to/linux-2.6/.git#branch anotherdir
Switching branches in place will be supported soon (although I have
doubts about its usefulness).
> > 13) create a new branch, and make it current
> >
> > $ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name
> > $ git checkout -f my-new-branch-name
>
> Since the hg repo is lightweight, this is usually done by just having
> different directories. Thus we don't explicitly name branches.
>
> $ mkdir new-branch
> $ cd new-branch
> $ hg init -u ../linux # makes hardlinks and does a checkout
$ mkdir new-branch
$ cd new-branch
$ cg-clone -s ../linux-2.6
(Note that cg-clone given local path will do hardlinks too.)
We don't explicitly name branches either. You can make the branch
visible from the other tree by
$ cg-branch-add new-branch ../new-branch
and then refer to it as new-branch.
> > 14) examine which branch is current
> >
> > $ ls -l .git/HEAD
>
> $ echo $PWD
Always the "master" branch.
> > 15) undo all local modifications (same as checkout):
> >
> > $ git checkout -f
>
> $ hg update -C
$ cg-cancel
> > 16) obtain a diff between current branch, and master branch
> >
> > In most trees WITH BRANCHES, .git/refs/heads/master contains the current
> > 'vanilla' upstream tree, for easy diffing and merging. (in trees
> > without branches, 'master' simply contains your latest changes)
> >
> > $ git-diff-tree -p master HEAD
>
> $ hg diff -r <rev> -r <rev>
$ cg-diff -r <rev> -r <rev>
> 17) run a browsable, pullable repo server of the current repo on your
> local machine
>
> $ hg serve
Make it accessible over HTTP, SSH, rsync, or for the local users if you
just want them to access it.
> 18) push your changes to a remote server
>
> $ hg push ssh://user@host/path/ # aliases and defaults in .hgrc
Will be supported Real Soon (tm) (well, probably sometimes next week).
> 19) get per-file history
>
> $ hg log <file> | less
$ cg-log [-c] [-s] <file>
> 20) get annotated file contents
>
> $ hg annotate [file]
Planned.
> 22) get online help
>
> $ hg help [command]
$ cg-help [command]
Cool. Except where the concepts are just different, Cogito mostly
appears at least equally simple to use as Mercurial. Yes, some features
are missing yet. I hope to fix that soon. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* [Cogito] less verbose cg-clone/cg-update?
From: Markus Dahms @ 2005-06-24 6:46 UTC (permalink / raw)
To: git
Hi there,
as a person just following the development process of Linux/GIT/etc.
I'm normally not interested in SHA-1 sums on updating my local tree.
IMHO the default output should be less verbose (like in most VCSs),
especially in file changes the type of change (N/M/...) and the
file name may be enough.
Given an option (e.g. "-v") there could be a lot more...
If there's no time, I'd do the patch...
Markus
P.S.: I didn't really look at the source, maybe it's a git not
a cg-* change...
--
A CRAY is the only computer that runs an endless loop in just 4 hours...
^ permalink raw reply
* Re: Stacked GIT 0.1 (a.k.a. quilt for git)
From: Catalin Marinas @ 2005-06-24 9:05 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050623175848.1cf41a52.pj@sgi.com>
Hi Paul,
Thanks for trying it. As a note, for the moment you should try the
latest daily snapshot since it contains less bugs than the main
(alpha) releases.
Paul Jackson <pj@sgi.com> wrote:
> 1) "Unknown" is misspelled as "Unkown" in a couple places.
Thanks.
> Before invoking an editor, it would be a good idea to tell the
> user you are doing so. If someone is on a telnet session to
> a system with their $DISPLAY set wrong, they might not even
> get the terse "16" clue that I got, that they are editing
> something.
Done.
> I'd recommend ignoring the exit status of externally invoked
> editors.
OK, fixed.
> 4) I tried rerunning that "stg init" without further ado, and it
> failed again (due to the incomplete init above, no doubt), with:
>
[...]
> AttributeError: 'NoneType' object has no attribute
> 'startswith'
The problem here is that the .git/HEAD link is not valid if init
failed. I will fix it for the tonight's snapshot.
> 5) I tried again, doing:
>
> rm -fr .git
> stg init
> # on the commit message edit - just quit 'q', to avoid any error exit
>
> This failed again, leaving my new git tree in god only knows what bogus state.
> It failed with:
>
> stg init: Commit message not modified
I can remove this condition for init only. The problem is that if it
no longer exists on an non-zero editor exit status, it should at least
check whether the commit message was modified.
> Try generating fewer fatal errors, and try giving a tiny clue
> what state (ok or not or how bad) one is left in after an
> apparently fatal error, and for extra credit, a clue what to do
> next.
I will try to add as much as information as possible. I initially
wanted to get something working and be able to push/pop patches. I
haven't tried the init command with different editors etc.
> 6) Ok - got through the init that time.
Good.
> Since I am fond of both quilt and Python, and since I need to be
> using git and/or cogito,
> I will poke around some more with this - it's promising.
Great. Pushing/popping works fine at the moment with my kernel tree
(but with less than 10 patches on the stack). It even detected when
the patches I submitted were merged upstream.
The next thing on my plan a log command. I would like to be able to
preserve the history of a patch but this probably won't be available
in an upstream tree pulling from yours.
> I see something about a patch emailer on the todo list -- you're
> welcome to make use of my patch emailer (I use with quilt, though
> it's not tightly bound to quilt) at:
>
> http://www.speakeasy.org/~pj99/sgi/sendpatchset
Thanks. I will try to include this in a future version.
--
Catalin
^ permalink raw reply
* Finding what change broke ARM
From: Russell King @ 2005-06-24 9:19 UTC (permalink / raw)
To: Linux Kernel List, git, Linus Torvalds
When building current git for ARM, I see:
CC arch/arm/mm/consistent.o
arch/arm/mm/consistent.c: In function `dma_free_coherent':
arch/arm/mm/consistent.c:357: error: `mem_map' undeclared (first use in this function)
arch/arm/mm/consistent.c:357: error: (Each undeclared identifier is reported only once
arch/arm/mm/consistent.c:357: error: for each function it appears in.)
make[2]: *** [arch/arm/mm/consistent.o] Error 1
How can I find what change elsewhere in the kernel tree caused this
breakage?
With bk, you could ask for a per-file revision history of the likely
candidates, and then find the changeset to view the other related
changes.
With git... ? We don't have per-file revision history so...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Stacked GIT 0.1 (a.k.a. quilt for git)
From: Paul Jackson @ 2005-06-24 10:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxd5qc6s5o.fsf@arm.com>
> it should at least
> check whether the commit message was modified.
I suspect not.
Beware that quilt has tended toward the philosophy of doing just
what you said, with no more, perhaps less than, the minimum critical
consistency checking. If you tried to shoot you foot off with it,
it shot your foot off, quickly.
If I try to make a change without a meaninguful log entry, what
business of stgit is that? And it certainly should not leave the
tree in some unspecified, inconsistent state without prior warning
on account of such.
Don't add inessential sanity checks on user input. It won't sell
well to the "quilt replacement" market.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: Stacked GIT 0.1 (a.k.a. quilt for git)
From: Catalin Marinas @ 2005-06-24 11:29 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050624034743.6c3bdae4.pj@sgi.com>
Paul Jackson <pj@sgi.com> wrote:
>> it should at least
>> check whether the commit message was modified.
>
> I suspect not.
>
> Beware that quilt has tended toward the philosophy of doing just
> what you said, with no more, perhaps less than, the minimum critical
> consistency checking. If you tried to shoot you foot off with it,
> it shot your foot off, quickly.
>
> If I try to make a change without a meaninguful log entry, what
> business of stgit is that?
The way to modify a patch with stgit is via 'stg commit'. The problem
is that you can end up with a commit log you didn't want simply
because the editor crashed or $EDITOR is invalid and there is no way
to modify the log history.
With stgit you don't have files only specific to a patch (the 'quilt
add' command equivalent is missing). When you modify a file and commit
the changes, it will be included in the topmost patch. IMO, this
simplifies the command set and avoids having two different add
commands (or a single add command with different behaviours). Now,
some people might not run a 'stg status' before a commit but they find
out from the commit msg that an unrelated file was modified. You could
simply exit without saving the commit msg and the changes won't be
checked in (and the tree is left in a consistent state - the one
before the commit).
Anyway, if you don't care about the commit history for individual
patches, I can simply remove all this commit/editor/msg check and just
use a standard text, maybe a description of the patch so that people
pulling from your git tree would know what it is about.
> And it certainly should not leave the
> tree in some unspecified, inconsistent state without prior warning
> on account of such.
'commit' failing doesn't leave the tree in an unspecified state (at
least not the yesterday's snapshot). There are other commands that do
this, unfortunately, but I'm still working on this.
> Don't add inessential sanity checks on user input. It won't sell
> well to the "quilt replacement" market.
I'm not keen on keeping these sanity checks but see my reasons above
for the commit message. Anyway, I'm open to suggestions. The main
advantage of stgit over quilt is that it uses diff3 instead of patch
for pushing patches. For this to work properly, the top and bottom of
a patch have to be valid commit or tree objects containing the whole
tree even if most of the files are not modified by this patch.
--
Catalin
^ permalink raw reply
* Re: Finding what change broke ARM
From: Alecs King @ 2005-06-24 11:32 UTC (permalink / raw)
To: git; +Cc: Linux Kernel List, Linus Torvalds
In-Reply-To: <20050624101951.B23185@flint.arm.linux.org.uk>
On Fri, Jun 24, 2005 at 10:19:51AM +0100, Russell King wrote:
> When building current git for ARM, I see:
>
> CC arch/arm/mm/consistent.o
> arch/arm/mm/consistent.c: In function `dma_free_coherent':
> arch/arm/mm/consistent.c:357: error: `mem_map' undeclared (first use in this function)
> arch/arm/mm/consistent.c:357: error: (Each undeclared identifier is reported only once
> arch/arm/mm/consistent.c:357: error: for each function it appears in.)
> make[2]: *** [arch/arm/mm/consistent.o] Error 1
>
> How can I find what change elsewhere in the kernel tree caused this
> breakage?
>
> With bk, you could ask for a per-file revision history of the likely
> candidates, and then find the changeset to view the other related
> changes.
>
> With git... ? We don't have per-file revision history so...
Wouldnt a 'git-whatchanged -p <candidates>' help?
--
Alecs King
^ permalink raw reply
* Re: Stacked GIT 0.1 (a.k.a. quilt for git)
From: Paul Jackson @ 2005-06-24 11:56 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxhdfo56yd.fsf@arm.com>
> there is no way to modify the log history.
Aha. If that means what I think it does, then I suspect I will remain
with quilt. The per-patch comment is often about the last thing that
I put in the patch.
The special thing about quilt is that the patch set in every regard
is infinitely changeable - the selection and order of the patches,
the contents of the patches, and the comments and metadata associated
with the patch can all be edited trivially.
Quilt is not a change management system; it's a patch set composition
system.
That stgit is layered on git (a persistent data store), and that
it has something (the log history you mention above) that cannot
be modified, suggests that stgit is not a 'better quilt for git',
but some other sort of tool.
Good luck ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: The coolest merge EVER!
From: Matthias Urlichs @ 2005-06-24 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <7v64w4d1n6.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> I suspect there
> would be a massive additional support needed if you want to make it easy
> for Paul to pull changes made to gitk in your tree.
I don't think that's possible; after all, the trees are now merged, so any
pull would fetch all of Linus' tree.
Paul could do it as patches, or Linus could do it in a branch, or we could
write something entirely different from git that happens to support
cherrypicking. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
What's so funny 'bout peace, love, and understanding?
^ permalink raw reply
* rev-parse, unknown arguments and extended sha1's
From: Sven Verdoolaege @ 2005-06-24 12:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Is git-rev-parse supposed to echo arguments it doesn't understand ?
It currently does, but git-checkout-script seems to think it doesn't:
rev=$(git-rev-parse "$arg")
if [ -z "$rev" ]; then
echo "unknown flag $arg"
exit 1
fi
Also, is there any reason why the extended sha1 notation
is restricted to the scripts and not used in the actual
plumbing ?
skimo
^ permalink raw reply
* Re: Stacked GIT 0.1 (a.k.a. quilt for git)
From: Catalin Marinas @ 2005-06-24 12:27 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050624045627.6e9cbaff.pj@sgi.com>
Paul Jackson <pj@sgi.com> wrote:
>> there is no way to modify the log history.
>
> Aha. If that means what I think it does, then I suspect I will remain
> with quilt. The per-patch comment is often about the last thing that
> I put in the patch.
I think you got it a bit wrong.
That was the initial idea. Anyway, in a future version you will have
one commit which is trackable via HEAD and which represents the whole
patch. This commit's log should always contain the patch description
so that people pulling your HEAD know what it is about.
If this is useful, a patch can have a second commit (or chain of
commits) refering to the same tree but not trackable via .git/HEAD but
which can be useful to track the individual changes of a patch. This
would be stored under .git/patches/<head>/<name>/ and not accessible
to anyone pulling the HEAD (well, rsync might bring the object but it
can be cleaned-up). This might be useful if you have a bigger patch
and want to track its changes, only internally.
Anyway, I think I won't implement this second commit handling and the
per-patch history would be trashed. Now I think I understand why you
mean by not caring about the commit message.
> The special thing about quilt is that the patch set in every regard
> is infinitely changeable - the selection and order of the patches,
> the contents of the patches, and the comments and metadata associated
> with the patch can all be edited trivially.
Almost all of this can be done with stgit. A patch in stgit is a just
a diff between 2 snapshots of the tree. The patch is indefinitely
changeable via commit. This weekend I will implement the proper commit
handling so that every new commit represents the whole patch and not
just the last modification.
You can easily reorder patches by popping all of them and pushing in a
different order. This is done via diff3 merging.
> Quilt is not a change management system; it's a patch set composition
> system.
I think the confusion comes from the fact that I wanted to put both
patch composition and change management in the same tool without a
clear separation.
> That stgit is layered on git (a persistent data store), and that
> it has something (the log history you mention above) that cannot
> be modified, suggests that stgit is not a 'better quilt for git',
> but some other sort of tool.
Again, the log history should only be internal, if useful, and not
visible to the outside world.
> Good luck ;).
Thanks. At least it is good that you tried it and provided some ideas
about what's needed as a quilt replacement. I will release a 0.3
version this weekend with the above things and you can try it.
--
Catalin
^ permalink raw reply
* Re: Finding what change broke ARM
From: Petr Baudis @ 2005-06-24 12:39 UTC (permalink / raw)
To: Linux Kernel List, git, Linus Torvalds
In-Reply-To: <20050624101951.B23185@flint.arm.linux.org.uk>
Dear diary, on Fri, Jun 24, 2005 at 11:19:51AM CEST, I got a letter
where Russell King <rmk+lkml@arm.linux.org.uk> told me that...
> When building current git for ARM, I see:
>
> CC arch/arm/mm/consistent.o
> arch/arm/mm/consistent.c: In function `dma_free_coherent':
> arch/arm/mm/consistent.c:357: error: `mem_map' undeclared (first use in this function)
> arch/arm/mm/consistent.c:357: error: (Each undeclared identifier is reported only once
> arch/arm/mm/consistent.c:357: error: for each function it appears in.)
> make[2]: *** [arch/arm/mm/consistent.o] Error 1
>
> How can I find what change elsewhere in the kernel tree caused this
> breakage?
>
> With bk, you could ask for a per-file revision history of the likely
> candidates, and then find the changeset to view the other related
> changes.
>
> With git... ? We don't have per-file revision history so...
With Cogito, you can pass cg-log list of files, and it will show only
the history of the given files.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Andrea Arcangeli @ 2005-06-24 13:06 UTC (permalink / raw)
To: Petr Baudis
Cc: Matt Mackall, Jeff Garzik, Linux Kernel, Git Mailing List,
mercurial
In-Reply-To: <20050624064101.GB14292@pasky.ji.cz>
On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
> Cool. Except where the concepts are just different, Cogito mostly
> appears at least equally simple to use as Mercurial. Yes, some features
> are missing yet. I hope to fix that soon. :-)
The user interface and network protocol isn't the big deal, the big deal
is the more efficient on-disk storage format IMHO.
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Matthias Urlichs @ 2005-06-24 13:16 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <20050624064101.GB14292@pasky.ji.cz>
Hi, Petr Baudis wrote:
> Switching branches in place will be supported soon (although I have
> doubts about its usefulness).
Well, I don't. Main reason: It's simply a lot faster to create+switch to a
branch locally for doing independent work, than to hardlink the whole
Linux directory tree into a clone tree.
Having one tree also simpifies the "what do I have that's not merged yet"
question -- just call "gitk $(cat .git/refs/heads/*)". ;-)
The only problem I have with it is that "git-read-tree -m -u"
doesn't delete files yet. To repeat my question from last week:
>> Would it be safe to add all files for which
>> read_tree.c:merge_cache:fn() returns zero to a "delete me" list?
(files on which which then actually get deleted, of course, if g-r-t
doesn't find any problems.)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Politics -- the gentle art of getting votes from the poor and campaign
funds from the rich by promising to protect each from the other.
-- Oscar Ameringer
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Theodore Ts'o @ 2005-06-24 13:39 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Petr Baudis, mercurial, Jeff Garzik, Linux Kernel,
Git Mailing List
In-Reply-To: <20050624130604.GK17715@g5.random>
On Fri, Jun 24, 2005 at 03:06:04PM +0200, Andrea Arcangeli wrote:
> On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
> > Cool. Except where the concepts are just different, Cogito mostly
> > appears at least equally simple to use as Mercurial. Yes, some features
> > are missing yet. I hope to fix that soon. :-)
>
> The user interface and network protocol isn't the big deal, the big deal
> is the more efficient on-disk storage format IMHO.
E2fsprogs with the full revision history imported into git is 100
megs, and that's with deltas. E2fsprogs imported into Mercurial is 17
megs (and actually, the imported repository was just a tad bit smaller
than e2fsprogs' BK repository).
Which do you think is going to be faster to operate from a cold start
using 4200 rpm laptop drives? :-)
- Ted
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Catalin Marinas @ 2005-06-24 13:41 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506231245560.30848-100000@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> I think that it's important to avoid having the array of "rebased the
> patch" commits be reachable from the final series if that series is going
> to be merged into the mainline at the end.
True. I will remove that. Any commit will have the new base of the
patch as a parent.
> If you want to keep the history of a patch, you should be able to do it by
> rebasing that history as well as the latest patch, so you'd get a
> two-parent commit with two rebased parents when you rebased a two-parent
> commit.
I can have two commits, one of them accessible via HEAD and the other
stored somewhere under .git/patches. The latter is just a normal
commit where the parent is the current HEAD. This will not be
generated when the patch is re-based, but only when a patch is
modified.
--
Catalin
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Paolo Ciarrocchi @ 2005-06-24 13:46 UTC (permalink / raw)
To: Theodore Ts'o, Andrea Arcangeli, Petr Baudis, mercurial,
Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <20050624133952.GB7445@thunk.org>
2005/6/24, Theodore Ts'o <tytso@mit.edu>:
> On Fri, Jun 24, 2005 at 03:06:04PM +0200, Andrea Arcangeli wrote:
> > On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
> > > Cool. Except where the concepts are just different, Cogito mostly
> > > appears at least equally simple to use as Mercurial. Yes, some features
> > > are missing yet. I hope to fix that soon. :-)
> >
> > The user interface and network protocol isn't the big deal, the big deal
> > is the more efficient on-disk storage format IMHO.
>
> E2fsprogs with the full revision history imported into git is 100
> megs, and that's with deltas. E2fsprogs imported into Mercurial is 17
> megs (and actually, the imported repository was just a tad bit smaller
> than e2fsprogs' BK repository).
>
> Which do you think is going to be faster to operate from a cold start
> using 4200 rpm laptop drives? :-)
>
> - Ted
That's quite intersting, what the rational behind such a difference in
terms of disk occupation ?
--
Paolo
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Kevin Smith @ 2005-06-24 13:57 UTC (permalink / raw)
To: Git Mailing List, mercurial
In-Reply-To: <20050624130604.GK17715@g5.random>
Andrea Arcangeli wrote:
> On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
>
>>Cool. Except where the concepts are just different, Cogito mostly
>>appears at least equally simple to use as Mercurial. Yes, some
>>features are missing yet. I hope to fix that soon. :-)
>
>
> The user interface and network protocol isn't the big deal, the
> big deal is the more efficient on-disk storage format IMHO.
For me, efficient storage is not very important, because I mostly deal
with small projects. Likewise, speed isn't a factor for me, since both
tools are plenty fast on small repos.
For me, the big advantage of mercurial is that it is written in python,
instead of shell scripts. I know for some people that's a DISadvantage,
but I see the following benefits as a result:
- Can run on (native) MS Windows
(necessary for me because I often work on cross-platform projects)
- Python code can be more clear and expressive (IMHO)
In the long run, I think the python code base will be easier to maintain
and enhance. A rewrite of cogito in python or ruby would be cool.
One advantage that cogito has is that git viewing/browsing tools can
operate directly on cogito repos. But a psychological drawback is the
ongoing confusion between git and cogito. Questions: Would a git-based
tool that writes to the repo (such as StGIT) mess up a cogito repo? Can
you switch a repo between git and cogito or back, at any time?
Mercurial's tags use a radical approach, whereas cogito's are more
conventional. I haven't yet used mercurial's versioned-tags enough yet
to judge whether they are better, worse, or just different.
I am impressed with the vibrancy of the development communities of both
projects. Both are able to serve repos on a plain http server. Both are
easy to use and have decent basic feature sets. Both projects are
developing test suites.
Mostly, I'm thrilled with this new wave of lightweight distributed SCM
systems. Most of the established tools tended to be too heavy on
features and complexity, and have taken a long time to develop. I love
that a single developer or small team can now create a simple but usable
distributed SCM in a couple months.
Kevin
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Christopher Li @ 2005-06-24 12:19 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Theodore Ts'o, Andrea Arcangeli, Petr Baudis, mercurial,
Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <4d8e3fd3050624064620a4945e@mail.gmail.com>
On Fri, Jun 24, 2005 at 03:46:21PM +0200, Paolo Ciarrocchi wrote:
> >
> > Which do you think is going to be faster to operate from a cold start
> > using 4200 rpm laptop drives? :-)
> >
> > - Ted
>
> That's quite intersting, what the rational behind such a difference in
> terms of disk occupation ?
>
Let me see. Mercurial using delta or full storage for the repository.
It insert a full node when it detect that delta it need to reach
certain node is too big. It just like MPEG movies, most of the frame
is delta to the previous frame. Once a while you have full frame to
allow you seek to.
But git has delta as well right? Another factor is that all file has
same path in mercurial using the same storage file. So in mercurial
it has far less file to store in the repository. Each file has two repository
files, the data storage file and the index file. Remember that file system
like ext3 is using blocks, if you store very small stuff on a file, it is
still going to take at least one block on disk. So that will defeat the delta
compression if the delta is always on a new file.
Chris
^ 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