* Re: [PATCH] Restore expected list order for --merge-order switch
From: Jon Seymour @ 2005-07-05 23:21 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
In-Reply-To: <20050705010619.13581.qmail@blackcubes.dyndns.org>
G'day Linus,
Is there some reason why this didn't get applied?
jon.
On 7/5/05, Jon Seymour <jon.seymour@gmail.com> wrote:
>
> A recent change to rev-list altered the order in which start points
> are presented to the merge-order sort algorithm. This caused
> breaks in the t/t6001 unit tests.
>
> This change restores the order in which start points are presented to the
> the merge-order sort algorithm (but leaves the order unchanged from
> the immediately preceding behaviour for non --merge-order sorts).
>
> The order in which arguments are presented to the merge-order
> sort algorithm is significant, since left-most arguments
> are expected to sort last so as to be consistent with
> how left-most parents sort.
>
> Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
^ permalink raw reply
* Re: cvsimport: rewritten in Perl
From: Wolfgang Denk @ 2005-07-05 23:02 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.03.13.44.46.995524@smurf.noris.de>
In message <pan.2005.07.03.13.44.46.995524@smurf.noris.de> you wrote:
>
> Linus: Please grab http://netz.smurf.noris.de/git/git.git/#cvs2git.
I tested this on the U-Boot CVS repository (available at
http://cvs.sourceforge.net/cvstarballs/u-boot-cvsroot.tar.bz2).
I got:
-> ~/test/git-cvsimport-script -d ~/git/u-boot-SF/u-boot -C u-boot u-boot
cvs_direct initialized to CVSROOT /home/wd/git/u-boot-SF/u-boot
cvs rlog: Logging u-boot
cvs rlog: Logging u-boot/board
...
cvs rlog: Logging u-boot/tools/scripts
cvs rlog: Logging u-boot/tools/updater
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
include/configs/svm_sc8xx.h:1.3=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 816, Tag LABEL_2003_12_08_MKR:
include/configs/rmu.h:1.4=after, CHANGELOG:1.171=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
include/configs/TQM823M.h:1.3=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
include/configs/TQM823L.h:1.9=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 816, Tag LABEL_2003_12_08_MKR:
include/configs/IceCube.h:1.16=after, CHANGELOG:1.171=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, CHANGELOG:1.165=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/RRvision/RRvision.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/atc/atc.c:1.6=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/c2mon/c2mon.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/etx094/etx094.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/evb64260/flash.c:1.5=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/rmu/rmu.c:1.3=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/tqm8260/tqm8260.c:1.4=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/tqm8xx/tqm8xx.c:1.4=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, include/version.h:1.20=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, lib_arm/board.c:1.19=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
cpu/mpc8xx/lcd.c:1.14=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 817, Tag LABEL_2003_12_08_MKR:
common/cmd_bootm.c:1.31=after, CHANGELOG:1.172=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
board/tqm8xx/tqm8xx.c:1.5=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
README:1.60=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
Makefile:1.65=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 816, Tag LABEL_2003_12_08_MKR:
include/configs/IceCube.h:1.16=after, CHANGELOG:1.171=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
include/configs/TQM823M.h:1.3=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
include/configs/svm_sc8xx.h:1.3=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 817, Tag LABEL_2003_12_08_MKR:
common/cmd_bootm.c:1.31=after, CHANGELOG:1.172=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
cpu/mpc8xx/lcd.c:1.14=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, CHANGELOG:1.165=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/RRvision/RRvision.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/atc/atc.c:1.6=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/c2mon/c2mon.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/etx094/etx094.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/evb64260/flash.c:1.5=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/rmu/rmu.c:1.3=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/tqm8260/tqm8260.c:1.4=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, board/tqm8xx/tqm8xx.c:1.4=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, include/version.h:1.20=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_12_08_MKR:
fs/fat/fat.c:1.5=after, lib_arm/board.c:1.19=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
include/configs/TQM823L.h:1.9=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
board/tqm8xx/tqm8xx.c:1.5=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
Makefile:1.65=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 816, Tag LABEL_2003_12_08_MKR:
include/configs/rmu.h:1.4=after, CHANGELOG:1.171=before. Treated as 'before'
WARNING: Invalid PatchSet 815, Tag LABEL_2003_12_08_MKR:
README:1.60=after, CHANGELOG:1.170=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, CHANGELOG:1.165=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/RRvision/RRvision.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/atc/atc.c:1.6=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/c2mon/c2mon.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/etx094/etx094.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/evb64260/flash.c:1.5=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/rmu/rmu.c:1.3=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/tqm8260/tqm8260.c:1.4=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/tqm8xx/tqm8xx.c:1.4=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, include/version.h:1.20=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, lib_arm/board.c:1.19=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, CHANGELOG:1.165=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/RRvision/RRvision.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/atc/atc.c:1.6=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/c2mon/c2mon.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/etx094/etx094.c:1.2=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/evb64260/flash.c:1.5=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/rmu/rmu.c:1.3=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/tqm8260/tqm8260.c:1.4=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, board/tqm8xx/tqm8xx.c:1.4=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, include/version.h:1.20=before. Treated as 'before'
WARNING: Invalid PatchSet 810, Tag LABEL_2003_11_26_MKR:
fs/fat/fat.c:1.5=after, lib_arm/board.c:1.19=before. Treated as 'before'
Committing initial tree 2183da96d548c02bd4f99b05e673395f81212878
Cannot create object: Too many open files
-> ulimit -n
1024
Any ideas?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"It is easier to port a shell than a shell script." - Larry Wall
^ permalink raw reply
* Re: git-update-cache:
From: Sam Ravnborg @ 2005-07-05 22:42 UTC (permalink / raw)
To: git
In-Reply-To: <20050705210256.GA28700@mars.ravnborg.org>
>
> I receive the following error:
> git-update-cache: symbol lookup error: git-update-cache: undefined
> symbol: deflateBound
>
> open("/usr/lib/libz.so.1", O_RDONLY) = 3
This is the reason.
For a strange reason when git-update-chache was compiled is was linked
dynamically towards an older libz.so version.
Latest installed is libz.1.2.2 which includes deflateBound.
libz.so.1 points at 1.1.4 which does not.
Sam
^ permalink raw reply
* git-update-cache:
From: Sam Ravnborg @ 2005-07-05 21:02 UTC (permalink / raw)
To: git
While trying to execute:
git-update-cache -- drivers/Kconfig drivers/net/Kconfig net/Kconfig
I receive the following error:
git-update-cache: symbol lookup error: git-update-cache: undefined
symbol: deflateBound
I have fetched a clean tree from kernel.org, and cloned it using
cg-clone.
Modifications are done in the cloned tree and the error is seen when
trying to do a cg-commit (that does the git-update-cache).
When this error is seen a file .git/index.lock is left and next
invocation of git-update-cache faild due to this but deletes the file.
Third invocation show the same error again.
To my best knowledge I have a working zlib installed.
Any help really appreciated!
Sam
strace appended:
sam@mars ~/linux/net-kconfig $ strace git-update-cache -- drivers/Kconfig drivers/net/Kconfig net/Kconfig > ../z
execve("/home/sam/bin/git-update-cache", ["git-update-cache", "--", "drivers/Kconfig", "drivers/net/Kconfig", "net/Kconfig"], [/* 54 vars */]) = 0
uname({sys="Linux", node="mars", ...}) = 0
brk(0) = 0x8054000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=136714, ...}) = 0
mmap2(NULL, 136714, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000
close(3) = 0
open("/usr/lib/libz.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\31\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=54416, ...}) = 0
mmap2(NULL, 56204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40038000
mmap2(0x40044000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb) = 0x40044000
close(3) = 0
open("/usr/lib/libcrypto.so.0.9.7", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \305\2"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=999412, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40046000
mmap2(NULL, 974584, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40047000
mmap2(0x40120000, 73728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd8) = 0x40120000
mmap2(0x40132000, 12024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40132000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220V\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1154496, ...}) = 0
mmap2(NULL, 1088900, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40135000
mprotect(0x40238000, 28036, PROT_NONE) = 0
mmap2(0x40239000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x103) = 0x40239000
mmap2(0x4023d000, 7556, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4023d000
close(3) = 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\v\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=10592, ...}) = 0
mmap2(NULL, 12392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4023f000
mmap2(0x40241000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x40241000
close(3) = 0
mprotect(0x40239000, 4096, PROT_READ) = 0
munmap(0x40016000, 136714) = 0
open("/dev/urandom", O_RDONLY) = 3
read(3, "1@\353)", 4) = 4
close(3) = 0
brk(0) = 0x8054000
brk(0x8075000) = 0x8075000
rt_sigaction(SIGINT, {0x804cb30, [INT], SA_RESTART}, {SIG_DFL}, 8) = 0
open(".git/index.lock", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
open(".git/index", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=1658992, ...}) = 0
mmap2(NULL, 1658992, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4, 0) = 0x40243000
close(4) = 0
lstat64("drivers/Kconfig", {st_mode=S_IFREG|0644, st_size=1030, ...}) = 0
open("drivers/Kconfig", O_RDONLY) = 4
mmap2(NULL, 1030, PROT_READ, MAP_PRIVATE, 4, 0) = 0x403d9000
close(4) = 0
stat64(".git/objects/fb/5c9b2a886518a4bfb0d2e2762fad41a08a5ba7", 0xbf85005c) = -1 ENOENT (No such file or directory)
open(".git/objects/pack", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
getdents64(4, /* 2 entries */, 4096) = 48
getdents64(4, /* 0 entries */, 4096) = 0
open(".git/objects/fb/5c9b2a886518a4bfb0d2e2762fad41a08a5ba7", O_RDONLY) = -1 ENOENT (No such file or directory)
gettimeofday({1120596694, 840021}, NULL) = 0
getpid() = 28699
open(".git/objects/obj_5s6K76", O_RDWR|O_CREAT|O_EXCL, 0600) = 5
brk(0x80a1000) = 0x80a1000
brk(0x80d1000) = 0x80d1000
writev(2, [{"git-update-cache", 16}, {": ", 2}, {"symbol lookup error", 19}, {": ", 2}, {"git-update-cache", 16}, {": ", 2}, {"undefined symbol: deflateBound", 30}, {"", 0}, {"", 0}, {"\n", 1}], 10git-update-cache: symbol lookup error: git-update-cache: undefined symbol: deflateBound
) = 88
exit_group(127) = ?
^ permalink raw reply
* [PATCH] Add script for patch submission via e-mail.
From: Junio C Hamano @ 2005-07-05 20:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <20050705093441.GD6191@pasky.ji.cz>
[PATCH] git-format-patch: Prepare patches for e-mail submission.
This is the script I use to prepare patches for e-mail submission.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** The latest incarnation. Uses --merge-order while generating
*** the list of patches to number them better.
Makefile | 3 +
git-format-patch-script | 121 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 123 insertions(+), 1 deletions(-)
create mode 100755 git-format-patch-script
1a3c4d6335860c7bfd09b997b19c850620c6fb50
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -31,7 +31,8 @@ SCRIPTS=git git-apply-patch-script git-m
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 git-rebase-script git-relink-script git-repack-script
+ gitk git-cherry git-rebase-script git-relink-script git-repack-script \
+ git-format-patch-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-format-patch-script b/git-format-patch-script
new file mode 100755
--- /dev/null
+++ b/git-format-patch-script
@@ -0,0 +1,121 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+usage () {
+ echo >&2 "usage: $0"' [-n] [-o dir] [-<diff options>...] upstream [ our-head ]
+
+Prepare each commit with its patch since our-head forked from upstream,
+one file per patch, for e-mail submission. Each output file is
+numbered sequentially from 1, and uses the first line of the commit
+message (massaged for pathname safety) as the filename.
+
+When -o is specified, output files are created in that directory; otherwise in
+the current working directory.
+
+When -n is specified, instead of "[PATCH] Subject", the first line is formatted
+as "[PATCH N/M] Subject", unless you have only one patch.
+'
+ exit 1
+}
+
+diff_opts=
+IFS='
+'
+LF='
+'
+outdir=./
+
+while case "$#" in 0) break;; esac
+do
+ case "$1" in
+ -n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
+ numbered=t ;;
+ -o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\
+ --output-d=*|--output-di=*|--output-dir=*|--output-dire=*|\
+ --output-direc=*|--output-direct=*|--output-directo=*|\
+ --output-director=*|--output-directory=*)
+ outdir=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ -o|--o|--ou|--out|--outp|--outpu|--output|--output-|--output-d|\
+ --output-di|--output-dir|--output-dire|--output-direc|--output-direct|\
+ --output-directo|--output-director|--output-directory)
+ case "$#" in 1) usage ;; esac; shift
+ outdir="$1" ;;
+ -*) diff_opts="$diff_opts$LF$1" ;;
+ *) break ;;
+ esac
+ shift
+done
+
+case "$#" in
+2) linus="$1" junio="$2" ;;
+1) linus="$1" junio=HEAD ;;
+*) usage ;;
+esac
+
+case "$outdir" in
+*/) ;;
+*) outdir="$outdir/" ;;
+esac
+test -d "$outdir" || mkdir -p "$outdir" || exit
+
+tmp=.tmp-series$$
+trap 'rm -f $tmp-*' 0 1 2 3 15
+
+series=$tmp-series
+
+titleScript='
+ 1,/^$/d
+ : loop
+ /^$/b loop
+ s/[^-a-z.A-Z_0-9]/-/g
+ s/\.\.\.*/\./g
+ s/\.*$//
+ s/--*/-/g
+ s/^-//
+ s/-$//
+ s/$/./
+ q
+'
+
+_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"
+stripCommitHead='/^'"$_x40"' (from '"$_x40"')$/d'
+
+git-rev-list --merge-order "$junio" "^$linus" >$series
+total=`wc -l <$series`
+i=$total
+while read commit
+do
+ title=`git-cat-file commit "$commit" | sed -e "$titleScript"`
+ case "$numbered" in
+ '') num= ;;
+ *)
+ case $total in
+ 1) num= ;;
+ *) num=' '`printf "%d/%d" $i $total` ;;
+ esac
+ esac
+ file=`printf '%04d-%stxt' $i "$title"`
+ i=`expr "$i" - 1`
+ echo "$file"
+ {
+ mailScript='
+ 1,/^$/d
+ : loop
+ /^$/b loop
+ s|^|[PATCH'"$num"'] |
+ : body
+ p
+ n
+ b body'
+
+ git-cat-file commit "$commit" | sed -ne "$mailScript"
+ echo '---'
+ echo
+ git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
+ echo
+ git-diff-tree -p $diff_opts "$commit" | sed -e "$stripCommitHead"
+ } >"$outdir$file"
+done <$series
^ permalink raw reply
* [PATCH] Short-cut git-fetch-pack while cloning locally.
From: Junio C Hamano @ 2005-07-05 20:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, David S. Miller
In-Reply-To: <Pine.LNX.4.58.0507041443510.3570@g5.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Well, I'm not working on it, but tested patches...
Prodded by the hint...
------------
The git-fetch-pack command used internally by git-fetch-script
which in turn is used by git-clone-script refuses to run if
there is no common head. When cloning locally, just copy/link the
objects directory to avoid its use, since we know there will not
be any common head (the target is empty). It also should be
more efficient.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** This is slightly different from the one I sent as a response
*** to David's inquiry, in that it uses cp -rl (or just cp -r)
*** instead of cpio. Also I added the copyright notices and one
*** liner description.
git-clone-script | 43 +++++++++++++++++++++++++++++++++++++++----
rev-list.c | 5 ++++-
2 files changed, 43 insertions(+), 5 deletions(-)
f33df082e175f7fc717a75e528eab3db1d294576
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -1,7 +1,42 @@
#!/bin/sh
+#
+# Copyright (c) 2005, Linus Torvalds
+# Copyright (c) 2005, Junio C Hamano
+#
+# Clone a repository into a different directory that does not yet exist.
+
repo="$1"
dir="$2"
-mkdir $dir || exit 1
-cd $dir
-git-init-db
-git fetch "$repo" && ( git-rev-parse FETCH_HEAD > .git/HEAD )
+mkdir "$dir" &&
+D=$(
+ (cd "$dir" && git-init-db && pwd)
+) || exit 1
+
+# See if repo is a local directory.
+if (
+ cd "$repo/objects" 2>/dev/null
+)
+then
+ # See if we can hardlink and drop "l" if not.
+ sample_file=$(cd "$repo" && find objects -type f -print | sed -e 1q)
+
+ # objects directory should not be empty since we are cloning!
+ test -f "$repo/$sample_file" || exit
+
+ if ln "$repo/$sample_file" "$D/.git/objects/sample" 2>/dev/null
+ then
+ l=l
+ else
+ l=
+ fi &&
+ rm -f "$D/.git/objects/sample" &&
+
+ cp -r$l "$repo/objects" "$D/.git/" || exit 1
+
+ # FETCH_HEAD is always HEAD because we do not do the
+ # extra parameter to "git fetch".
+ cat "$repo/HEAD" >"$D/.git/FETCH_HEAD"
+ cd "$D"
+else
+ cd "$D" && git fetch "$repo"
+fi && git-rev-parse FETCH_HEAD > .git/HEAD
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -482,7 +482,10 @@ int main(int argc, char **argv)
commit = get_commit_reference(arg, flags);
if (!commit)
continue;
- insert_by_date(&list, commit);
+ if (!merge_order)
+ insert_by_date(&list, commit);
+ else
+ commit_list_insert(commit, &list);
}
if (!merge_order) {
^ permalink raw reply
* Re: Tags
From: Junio C Hamano @ 2005-07-05 19:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric W. Biederman, Daniel Barkalow, H. Peter Anvin,
Git Mailing List, ftpadmin
In-Reply-To: <Pine.LNX.4.58.0507051132530.3570@g5.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Tue, 5 Jul 2005, Eric W. Biederman wrote:
>>
>> True but if you can you will get multiple tags with the
>> same suggested name. So you need so way to find the one you
>> care about.
LT> I do agree that it would make sense to have a "tagger" field with the same
LT> semantics as the "committer" in a commit (including all the same fields:
LT> real name, email, and date).
While we are talking about changing tag object format/fields,
I've wondered if we would want to be able to associate more than
one objects with a single tag (i.e. have more than one "object"
lines just like commits can have more than one "parent" lines).
I admit that it would not be a "tag" anymore, rather, it would
be a "bag".
I wanted to have something like this in the past for some reason
I do not exactly remember anymore, but basically it was to
record "here is the list of related objects."
I could fake it with a multi-parent commit with a commit message
if all I want to include are commits with a single blob, but
that is (1) abusing the commit to record something that is not
even a merge, and (2) the tree associated with that commit would
not mean anything.
^ permalink raw reply
* Re: Tags
From: Linus Torvalds @ 2005-07-05 18:33 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Daniel Barkalow, H. Peter Anvin, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m1br5hywde.fsf@ebiederm.dsl.xmission.com>
On Tue, 5 Jul 2005, Eric W. Biederman wrote:
>
> True but if you can you will get multiple tags with the
> same suggested name. So you need so way to find the one you
> care about.
I do agree that it would make sense to have a "tagger" field with the same
semantics as the "committer" in a commit (including all the same fields:
real name, email, and date).
Linus
^ permalink raw reply
* Re: Tags
From: Eric W. Biederman @ 2005-07-05 17:51 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Linus Torvalds, H. Peter Anvin, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <Pine.LNX.4.21.0507051155580.30848-100000@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Tue, 5 Jul 2005, Eric W. Biederman wrote:
>
>> Could you include the person who generated the tag and the time the
>> tag was generated in the tag object?
>>
>> For a tag like "latest" it would help quite a bit if you could actually
>> find out which was the latest version of it :)
>
> The fact that lots of tags get refs named with their contents is just due
> to tags only getting used for a small portion of their possible uses. This
> only happens when the feature you'd look something up under is a feature
> which is persistent.
True but if you can you will get multiple tags with the
same suggested name. So you need so way to find the one you
care about.
Either a date or it's position in the tree, are all you have
to go on.
I picked on latest as that is an extreme example that had already
been mentioned.
Eric
^ permalink raw reply
* Re: Tags
From: Daniel Barkalow @ 2005-07-05 16:21 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, H. Peter Anvin, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m1vf3p2yks.fsf@ebiederm.dsl.xmission.com>
On Tue, 5 Jul 2005, Eric W. Biederman wrote:
> Could you include the person who generated the tag and the time the
> tag was generated in the tag object?
>
> For a tag like "latest" it would help quite a bit if you could actually
> find out which was the latest version of it :)
Actually, what you really want here is to put in refs/tags/latest the hash
of the tag whose "tag" field is v2.6.13-rc1 (or whatever it is). Having a
tag with the "tag" field of "latest" would be a bit silly, because the
object will probably stay in circulation long after it's no longer
true. And the object itself would tell you that it was the latest version
when it was created (but isn't every version?). That's why you want the
_tag_ to say something useful about the version (maybe "v2.6.12", maybe
just "tested"), and the _ref_ to tell you it's the latest.
The fact that lots of tags get refs named with their contents is just due
to tags only getting used for a small portion of their possible uses. This
only happens when the feature you'd look something up under is a feature
which is persistent.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Add script for patch submission via e-mail.
From: Jon Seymour @ 2005-07-05 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Linus Torvalds, git
In-Reply-To: <7vekadfff6.fsf@assigned-by-dhcp.cox.net>
On 7/6/05, Junio C Hamano <junkio@cox.net> wrote:
> >>>>> "PB" == Petr Baudis <pasky@suse.cz> writes:
>
> PB> Any reason why this was not applied? It appears kind of cool.
>
> FYI, the one in <7vll4s47p3.fsf_-_@assigned-by-dhcp.cox.net> is
> newer than what you quoted.
>
> One thing _I_ am unhappy about what it does is that it does not
> try to be intelligent about merges (I haven't tried the script
> on a merged head myself).
I am not completely sure this is really a problem. I would presume
that the project lead doesn't really need to use
git-format-patch-script and the individual developer should probably
rebase on the latest head which is either done by trivially reapplying
the patches in sequence automatically or reapplying the patches in
sequence with some edits to fix any conflicts that have arisen.
So, it is not clear to me git-format-patch-script needs to worry about
merge questions. It'd be better to put such logic in a separate
rebasing script, I think. If anything, you might want to add checks to
git-format-patch script that refuse to generate a patch sequence for
any sequence of patches that spans a merge commit.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Merging and parents
From: Matthias Urlichs @ 2005-07-05 16:19 UTC (permalink / raw)
To: git
I just had this ugly merge situation:
M
|\
| \
A B
|\/|
|/\|
C D
| /
|/
E
Suppose both the EC and the ED branch add files (not with conflicting
filenames!) which then get modified somewhere between C/D and M.
No matter which node gets picked as the parent, some files will end
up as "created on different branches" because the chosen parent doesn't
have them, even though, strictly speaking, it ain't so.
So ... what to do? Generate a list of parents, and for each file pick the
one parent where it (a) exists and (b) has the smallest diff?
Or just ignore (umm... OK, document) the problem?
--
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
- -
I'm thankful I didn't believe in God, because it
would have been another thing for me to conquer.
-- Kim Goldman
^ permalink raw reply
* Re: [PATCH] Add script for patch submission via e-mail.
From: Junio C Hamano @ 2005-07-05 15:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050705093441.GD6191@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@suse.cz> writes:
PB> Any reason why this was not applied? It appears kind of cool.
FYI, the one in <7vll4s47p3.fsf_-_@assigned-by-dhcp.cox.net> is
newer than what you quoted.
One thing _I_ am unhappy about what it does is that it does not
try to be intelligent about merges (I haven't tried the script
on a merged head myself).
When you think about "project lead" vs "individual developer"
modes of operation, the latter is primarily "keep rebasing
commits in my fork and re-throwing them upstream until some of
them stick", so not supporting merges specially would not be so
big a flaw. However, at least it should use --merge-order to
get the epochs decomposed right, in order to produce anything
remotely useful when dealing with a merged head.
^ permalink raw reply
* Re: Last mile for 1.0 again
From: Marco Costalba @ 2005-07-05 13:34 UTC (permalink / raw)
To: Junio C Hamano, Daniel Barkalow; +Cc: Linus Torvalds, git
In-Reply-To: <7v3bqthiso.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>
> DB> [perl script]
>
> >> How does this work, and what do we do about merges?
>
Checking diffs of all the parents can be computational expensive.
I'am developing a different alghoritm for qgit, where I know,
before to run annotate all the revs that changed a given file.
The revs are saved in the shaHist list according to git-rev-list --merge-order.
The algoritm operates form the oldest to the newst calculating annotation for each
following rev.
This alghoritm takes advantage of the fact that mostly revs belong to 2 categories:
1) revs of the same development-sequence (e.g. connected without merges)
2) empty merges, i.e. merges where the file we are interested in
is listed in only one merging branch
If a rev in shaHist does not belong to above categories a reach analisys must be performed
in order to find the direct ancestor among all the previous revs in the list.
So starting from shaHist a ReachList rl is populated by getReachability():
void Annotate::getReachability(ReachList& rl, const QString& file, const QStringList& shaHist) {
rl.clear();
QStringList::const_iterator it = shaHist.begin();
Rev* r = revLookup(*it);
rl.append(ReachInfo(*it, r->id, INITIAL));
for (it++; it != shaHist.end(); it++) {
Rev* r = revLookup(*it);
// initial revision case
if (r->parents.count() == 0) {
rl.append(ReachInfo(*it, r->id, INITIAL));
continue;
}
// merge case
if (r->parents.count() > 1) {
// check empty merges diffing against previous in list
QString prevSha = rl.last().sha;
QString d = getFileDiff(*it, prevSha, file);
if (d.isEmpty()) {
rl.append(ReachInfo(*it, r->id, EMPTY_MERGE));
rl.last().roots.append(prevSha);
} else {
// real merge: we need reach test.
QStringList roots;
roots.clear();
for (uint i = 0; i < r->parents.count(); i++) {
// here tree walking is performed
QString root = getRoot(r->parents[i], rl);
if (!root.isEmpty())
roots.append(root);
}
rl.append(ReachInfo(*it, r->id, MERGE));
rl.last().roots = roots;
}
}
continue;
}
// normal case: a revision with a single parent
if (r->id == rl.last().id) { // same development sequence
QString prevSha = rl.last().sha;
rl.append(ReachInfo(*it, r->id, SAME_BR)); // same branch
rl.last().roots.append(prevSha);
} else { // different development sequence
QString root = getRoot(*it, rl); // <-- here tree walking is performed
if (!root.isEmpty()) {
rl.append(ReachInfo(*it, r->id, DIFF_BR));
rl.last().roots.append(root);
} else
qDebug("ASSERT getReachability: rev %s not reachable",
(*it).latin1());
}
}
}
Then ReachList rl is then used to compute correct annotations:
void Annotate::run(const QString& file, const QStringList& shaHist, AnnotateHistory& ah) {
QString d, diffTarget;
QStringList t;
int pos;
ReachList rl;
ah.clear();
getReachability(rl, file, shaHist); // <-- here ReachList rl is calculated
for (uint i = 0; i < rl.count(); i++) {
switch(rl[i].type) { // <-- here ReachList rl is used to find annotations
case SAME_BR:
case DIFF_BR:
diffTarget = rl[i].roots.first();
d = getFileDiff(rl[i].sha, diffTarget, file);
pos = shaHist.findIndex(diffTarget);
ah.append(processDiff(d, ah[pos], getAuthor(rl[i].sha, shaHist)));
break;
case INITIAL:
pos = shaHist.findIndex(rl[i].sha);
ah.append(getFirstAnnotation(file, shaHist, pos));
break;
case EMPTY_MERGE:
diffTarget = rl[i].roots.first();
pos = shaHist.findIndex(diffTarget);
t = ah[pos]; // copy annotation from previous
ah.append(t);
break;
case MERGE:
// append annotation calculated on first root
diffTarget = rl[i].roots.first();
d = getFileDiff(rl[i].sha, diffTarget, file);
pos = shaHist.findIndex(diffTarget);
ah.append(processDiff(d, ah[pos], "Merge"));
// update annotation with all the others roots
for (uint j = 1; j < rl[i].roots.count(); j++) {
diffTarget = rl[i].roots[j];
d = getFileDiff(rl[i].sha, diffTarget, file);
pos = shaHist.findIndex(diffTarget);
// create an annotation calculated between root[i] and
// the merge.
QStringList scndAnn = processDiff(d, ah[pos],
getAuthor(diffTarget, shaHist));
// finally we unify the two annotations, so we catch
// also the case of a 3-way merge
unify(ah.last(), scndAnn);
}
break;
}
}
}
Advantage of this algorithm is that reach analisys, i.e. tree walking, is
done, statistically, only for a small subset of revs.
Another side benefit is that correct annotation is calculated for each rev and
not only for newest one.
Of course there are issues:
1) A ordered list of revs (file history) must be known in advance. This is not a problem
for qgit because file history is calculated while loading revs.
2) Does not takes in account file renames.
Hope this notes can help in ongoing discussion
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Tags
From: Eric W. Biederman @ 2005-07-05 13:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <Pine.LNX.4.58.0507021501450.8247@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> (And you might also change tag contents occasionally. One reason might be
> a bug and you decide to re-tag something else. But a more common reason
> might be because you want to have tags like "latest" that don't actually
> update with development, but they update with some other event, like a
> release event or some automated test cycle completion or something like
> that. So tags aren't _immutable_ even from an expectation standpoint,
> it's just that they tend to change _less_).
Could you include the person who generated the tag and the time the
tag was generated in the tag object?
For a tag like "latest" it would help quite a bit if you could actually
find out which was the latest version of it :)
Eric
^ permalink raw reply
* Re: [PATCH] Add script for patch submission via e-mail.
From: Jon Seymour @ 2005-07-05 9:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20050705093441.GD6191@pasky.ji.cz>
On 7/5/05, Petr Baudis <pasky@suse.cz> wrote:
>
> Any reason why this was not applied? It appears kind of cool. Well, I
> will probably take it and extend cg-mkpatch with it so I don't need it
> in Git, but I'm so altruistic and want to bring at least a bit of light
> to the gloomy dark world of the poor core Git plumbing users. ;-)
As one who inhabits that dark world, I second that!
jon.
^ permalink raw reply
* Re: [PATCH] Add script for patch submission via e-mail.
From: Petr Baudis @ 2005-07-05 9:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <7vll5h7k5t.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jun 11, 2005 at 03:32:30AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> This git-format-patch-script is what I use to prepare patches
> for e-mail submission.
>
> Typical usage is:
>
> $ git-format-patch-script -B -C --find-copies-harder HEAD linus
>
> to prepare each commit with its patch since "HEAD" forked from
> "linus", one file per patch for e-mail submission. Each output
> file is numbered sequentially from 1, and uses the first line of
> the commit message (massaged for pathname safety) as the
> filename.
>
> $ git-format-patch-script -B -C --find-copies-harder HEAD linus .patch/
>
> creates output files in .patch/ directory.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> *** Linus I am submitting this one because some patches on
> *** read-tree I am going to send you will need this for
> *** formatting into a form that is easier to review. And this
> *** in turn can use diff-tree --find-copies-harder, which I
> *** indeed used to generate the patches that follow.
Any reason why this was not applied? It appears kind of cool. Well, I
will probably take it and extend cg-mkpatch with it so I don't need it
in Git, but I'm so altruistic and want to bring at least a bit of light
to the gloomy dark world of the poor core Git plumbing users. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Proposed script: cg-info
From: Petr Baudis @ 2005-07-05 9:22 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1120542372.17286.7.camel@dv>
Dear diary, on Tue, Jul 05, 2005 at 07:46:12AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Hello!
Hello,
> It would be useful to have a script to display current status of the
> repository - branches, current branch and merge status. Maybe I'm
> missing something, but I don't see such script.
>
> I wrote a script that would do that. I'm still not fully familiar with
> the concepts of cogito, so maybe wrong terms are used in the script. I
> just want to offer this scripts as a base for further work.
>
> cg-info sounds very pretentious, so maybe the script should be renamed
> to cg-heads-ls or cg-admin-status or something like that.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
thanks. I've somewhat cleaned it up and added some more information to
show, and committed it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: [PATCH] Fixlet for argument parsing in rev-list.
From: Jon Seymour @ 2005-07-05 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7vpstxg02q.fsf@assigned-by-dhcp.cox.net>
I ack the patch, though --show-breaks could use the same treatment.
jon.
On 7/5/05, Junio C Hamano <junkio@cox.net> wrote:
> The --merge-order flag does not take parameter so there is no
> point doing strncmp with the length.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> rev-list.c | 2 +-
> 1 file changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/rev-list.c b/rev-list.c
> --- a/rev-list.c
> +++ b/rev-list.c
> @@ -462,7 +462,7 @@ int main(int argc, char **argv)
> limited = 1;
> continue;
> }
> - if (!strncmp(arg, "--merge-order", 13)) {
> + if (!strcmp(arg, "--merge-order")) {
> merge_order = 1;
> continue;
> }
> ------------------------------------------------
>
>
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* [PATCH] Fixlet for argument parsing in rev-list.
From: Junio C Hamano @ 2005-07-05 7:54 UTC (permalink / raw)
To: torvalds; +Cc: jon.seymour, git
The --merge-order flag does not take parameter so there is no
point doing strncmp with the length.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
rev-list.c | 2 +-
1 file changed, 1 insertions(+), 1 deletions(-)
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -462,7 +462,7 @@ int main(int argc, char **argv)
limited = 1;
continue;
}
- if (!strncmp(arg, "--merge-order", 13)) {
+ if (!strcmp(arg, "--merge-order")) {
merge_order = 1;
continue;
}
------------------------------------------------
^ permalink raw reply
* Re: Last mile for 1.0 again
From: Junio C Hamano @ 2005-07-05 6:24 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.21.0507042137300.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> [perl script]
>> How does this work, and what do we do about merges?
DB> I've got that part, but I'm not clear on how the rename/copy and complete
DB> rewrite stuff works.
Rename/copy is simply about what files to use when comparing
between two trees. If you are tracking file F and find that a
commit created that file by renaming what was originally G, then
you compare old G and this F and assign blame for common lines
to the ancestor of that commit (that had those lines in G), and
take responsibility of the rest yourself (or assign blame for
them to other parents).
Rewrite is easier. If diff-tree -B says it is a complete
rewrite, instead of assigning blame for lines that you are the
current suspect to any of your parents, you take blame for all
of them yourself, without comparing the file with the parent to
assign blame line-by-line.
^ permalink raw reply
* Proposed script: cg-info
From: Pavel Roskin @ 2005-07-05 5:46 UTC (permalink / raw)
To: git, Petr Baudis
Hello!
It would be useful to have a script to display current status of the
repository - branches, current branch and merge status. Maybe I'm
missing something, but I don't see such script.
I wrote a script that would do that. I'm still not fully familiar with
the concepts of cogito, so maybe wrong terms are used in the script. I
just want to offer this scripts as a base for further work.
cg-info sounds very pretentious, so maybe the script should be renamed
to cg-heads-ls or cg-admin-status or something like that.
Signed-off-by: Pavel Roskin <proski@gnu.org>
#!/usr/bin/env bash
#
# Show status of the GIT repository.
# Copyright (c) Pavel Roskin 2005
#
# The output includes the list of branches and merge status.
# Current branch is marked by ">"
USAGE="cg-info"
. ${COGITO_LIB}cg-Xlib
mkdir -p $_git/refs/heads
[ "$(find $_git/refs/heads -follow -type f)" ] \
|| die "List of heads is empty."
branch=
headlink=$(readlink $_git/HEAD)
if [ "$headlink" ]; then
branch=$(basename "$headlink")
else
headsha1=$(cat $_git/HEAD)
echo "HEAD: $headsha1"
fi
echo "Heads:"
for head in $_git/refs/heads/*; do
headsha1=$(cat $head)
headbase=$(basename $head)
if [ "$headbase" = "$branch" ]; then
echo ">$headbase $headsha1"
else
echo " $headbase $headsha1"
fi
done
if [ -s "$_git/blocked" ]; then
tmp=$(cat "$_git/blocked")
echo "Blocked: $tmp"
fi
if [ -s "$_git/merging" ]; then
tmp=$(cat "$_git/merging")
echo "Merging: $tmp"
fi
if [ -s "$_git/merging-sym" ]; then
tmp=$(cat "$_git/merging-sym")
echo "Merging-sym: $tmp"
fi
if [ -s "$_git/merge-base" ]; then
tmp=$(cat "$_git/merge-base")
echo "Merge-base: $tmp"
fi
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Last mile for 1.0 again
From: Daniel Barkalow @ 2005-07-05 1:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmzp2gohc.fsf@assigned-by-dhcp.cox.net>
On Mon, 4 Jul 2005, Junio C Hamano wrote:
> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>
> DB> Junio: what's missing from annotate/blame?
>
> Which one are you talking about?
>
> What I use to generate http://members.cox.net/junkio/Summary.txt
> is an implementation of an algorithm I consider "complete" in
> that it does rename/copy and complete rewrite correctly. What
> is missing from the implementation is efficiency.
[perl script]
> How does this work, and what do we do about merges?
I've got that part, but I'm not clear on how the rename/copy and complete
rewrite stuff works.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Restore expected list order for --merge-order switch
From: Jon Seymour @ 2005-07-05 1:06 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
A recent change to rev-list altered the order in which start points
are presented to the merge-order sort algorithm. This caused
breaks in the t/t6001 unit tests.
This change restores the order in which start points are presented to the
the merge-order sort algorithm (but leaves the order unchanged from
the immediately preceding behaviour for non --merge-order sorts).
The order in which arguments are presented to the merge-order
sort algorithm is significant, since left-most arguments
are expected to sort last so as to be consistent with
how left-most parents sort.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
rev-list.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
ed4451af196ea31ec0c6c7f663290a9b325482cd
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -482,7 +482,10 @@ int main(int argc, char **argv)
commit = get_commit_reference(arg, flags);
if (!commit)
continue;
- insert_by_date(&list, commit);
+ if (!merge_order)
+ insert_by_date(&list, commit);
+ else
+ commit_list_insert(commit, &list);
}
if (!merge_order) {
------------
^ permalink raw reply
* git-fetch-pack
From: Linus Torvalds @ 2005-07-05 0:08 UTC (permalink / raw)
To: Git Mailing List
Ok,
I've written a "git-fetch-pack" along the lines I outlined a few days
ago, ie the person doing the fetching ends up listing the commits it has,
and then both ends negotiate the missing objects.
It's probably buggy in many ways, but I actually used it to fetch the last
merge with Russell King:
remote=$(git-fetch-pack $repo master)
if [ "$remote" ]; then
git resolve $(git-rev-parse HEAD) $remote "Merge $repo"
fi
ends up doing something sane.
In general, the format is to tell git-fetch-pack where to fetch things
from, and what branch to use (if you give none, or you give multiple, it
does various magic things, you shouldn't do it). It will then fetch and
unpack the pack, and return the SHA1 corresponding to the remote ref if
everything was successful.
So the above will fetch a remote ref, and resolve it (ie it's basically a
specialized "git pull").
Linus
^ 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