[PATCH] Export pcibios_bus_to_resource
tree 209aa1f61d73f84046bd8735c7b4ef306b30e3cc
parent b7561524765a30334bf31c56b523aeb3c1a04c7d
author Keith Owens [EMAIL PROTECTED] Wed, 24 Aug 2005 16:06:25 +1000
committer Linus Torvalds [EMAIL PROTECTED] Thu, 25 Aug 2005 00:22:44 -0700
[PATCH] Export pcibios_bus_to_resource
pcibios_bus_to_resource is exported on all architectures except ia64
and sparc. Add exports for the two missing architectures. Needed when
Yenta socket support is compiled as a module.
Signed-off-by: Keith Owens [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
arch/ia64/pci/pci.c |1 +
arch/sparc64/kernel/pci.c |1 +
2 files changed, 2 insertions(+)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -380,6 +380,7 @@ void pcibios_bus_to_resource(struct pci_
res-start = region-start + offset;
res-end = region-end + offset;
}
+EXPORT_SYMBOL(pcibios_bus_to_resource);
static int __devinit is_valid_resource(struct pci_dev *dev, int idx)
{
diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
--- a/arch/sparc64/kernel/pci.c
+++ b/arch/sparc64/kernel/pci.c
@@ -540,6 +540,7 @@ void pcibios_bus_to_resource(struct pci_
pbm-parent-resource_adjust(pdev, res, root);
}
+EXPORT_SYMBOL(pcibios_bus_to_resource);
char * __init pcibios_setup(char *str)
{
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cpu_exclusive sched domains build fix
tree d7db18d3d5f75fe4309ddc7aa373f3213f845b41
parent 40bb0c3ef52d872de348e1eb5432a43a147d
author Paul Jackson [EMAIL PROTECTED] Wed, 24 Aug 2005 18:15:10 -0700
committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 23:40:45 -0700
[PATCH] cpu_exclusive sched domains build fix
As reported by Paul Mackerras [EMAIL PROTECTED], the previous patch
cpu_exclusive sched domains fix broke the ppc64 build with
CONFIC_CPUSET, yielding error messages:
kernel/cpuset.c: In function 'update_cpu_domains':
kernel/cpuset.c:648: error: invalid lvalue in unary ''
kernel/cpuset.c:648: error: invalid lvalue in unary ''
On some arch's, the node_to_cpumask() is a function, returning
a cpumask_t. But the for_each_cpu_mask() requires an lvalue mask.
The following patch fixes this build failure by making a copy
of the cpumask_t on the stack.
Signed-off-by: Paul Jackson [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
kernel/cpuset.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -645,7 +645,9 @@ static void update_cpu_domains(struct cp
int i, j;
for_each_cpu_mask(i, cur-cpus_allowed) {
- for_each_cpu_mask(j, node_to_cpumask(cpu_to_node(i))) {
+ cpumask_t mask = node_to_cpumask(cpu_to_node(i));
+
+ for_each_cpu_mask(j, mask) {
if (!cpu_isset(j, cur-cpus_allowed))
return;
}
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] m68k: fix broken macros causing compile errors
tree fb0a64a7e4c53fa05a75d1ebb429a27b5c44de3b
parent 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf
author Andreas Schwab [EMAIL PROTECTED] Wed, 24 Aug 2005 17:36:21 +0200
committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 23:37:40 -0700
[PATCH] m68k: fix broken macros causing compile errors
Add parens around macro parameters.
Signed-off-by: Andreas Schwab [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
include/asm-m68k/page.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-m68k/page.h b/include/asm-m68k/page.h
--- a/include/asm-m68k/page.h
+++ b/include/asm-m68k/page.h
@@ -138,13 +138,13 @@ extern unsigned long m68k_memoffset;
#define __pa(vaddr)((unsigned long)(vaddr)+m68k_memoffset)
#define __va(paddr)((void *)((unsigned
long)(paddr)-m68k_memoffset))
#else
-#define __pa(vaddr)virt_to_phys((void *)vaddr)
-#define __va(paddr)phys_to_virt((unsigned long)paddr)
+#define __pa(vaddr)virt_to_phys((void *)(vaddr))
+#define __va(paddr)phys_to_virt((unsigned long)(paddr))
#endif
#else /* !CONFIG_SUN3 */
/* This #define is a horrible hack to suppress lots of warnings. --m */
-#define __pa(x) ___pa((unsigned long)x)
+#define __pa(x) ___pa((unsigned long)(x))
static inline unsigned long ___pa(unsigned long x)
{
if(x == 0)
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86_64: update defconfig - reenable fusion
tree e45d7e074f82778666db9d51d15dd0e66f8efdbb parent 5477d30e841e0f707fd2daddc8cb6949858476ee author Andi Kleen [EMAIL PROTECTED] Wed, 24 Aug 2005 07:37:37 +0200 committer Linus Torvalds [EMAIL PROTECTED] Thu, 25 Aug 2005 00:22:44 -0700 [PATCH] x86_64: update defconfig - reenable fusion I mistakedly disabled fusion support in an earlier update. Fusion is commonly used on many x86-64 systems, so this was a problem. This patch fixes that. Signed-off-by: And Kleen [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/x86_64/defconfig | 21 + 1 files changed, 13 insertions(+), 8 deletions(-) diff --git a/arch/x86_64/defconfig b/arch/x86_64/defconfig --- a/arch/x86_64/defconfig +++ b/arch/x86_64/defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.13-rc3 -# Fri Jul 22 16:47:31 2005 +# Linux kernel version: 2.6.13-rc6-git3 +# Fri Aug 12 16:40:34 2005 # CONFIG_X86_64=y CONFIG_64BIT=y @@ -284,10 +284,6 @@ CONFIG_IPV6=y # Network testing # # CONFIG_NET_PKTGEN is not set -CONFIG_NETPOLL=y -# CONFIG_NETPOLL_RX is not set -# CONFIG_NETPOLL_TRAP is not set -CONFIG_NET_POLL_CONTROLLER=y # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set @@ -463,6 +459,7 @@ CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set CONFIG_SCSI_SATA=y +# CONFIG_SCSI_SATA_AHCI is not set # CONFIG_SCSI_SATA_SVW is not set CONFIG_SCSI_ATA_PIIX=y # CONFIG_SCSI_SATA_NV is not set @@ -492,6 +489,7 @@ CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set +# CONFIG_SCSI_QLA24XX is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set @@ -512,9 +510,11 @@ CONFIG_BLK_DEV_DM=y # # Fusion MPT device support # -# CONFIG_FUSION is not set -# CONFIG_FUSION_SPI is not set +CONFIG_FUSION=y +CONFIG_FUSION_SPI=y # CONFIG_FUSION_FC is not set +CONFIG_FUSION_MAX_SGE=128 +# CONFIG_FUSION_CTL is not set # # IEEE 1394 (FireWire) support @@ -585,6 +585,7 @@ CONFIG_8139TOO=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=y +# CONFIG_E1000_NAPI is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set @@ -624,6 +625,10 @@ CONFIG_S2IO=m # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set CONFIG_NETCONSOLE=y +CONFIG_NETPOLL=y +# CONFIG_NETPOLL_RX is not set +# CONFIG_NETPOLL_TRAP is not set +CONFIG_NET_POLL_CONTROLLER=y # # ISDN subsystem - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
[EMAIL PROTECTED] writes: So I have another anomaly in my GIT tree. A patch to back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c in my release branch at commit 62d75f3753647656323b0365faa43fc1a8f7be97 appears to have been lost when I merged the release branch to the test branch at commit 0c3e091838f02c537ccab3b6e8180091080f7df2 : siamese; git cat-file commit 0c3e091838f02c537ccab3b6e8180091080f7df2 tree 61a407356d1e897e0badea552ce69e657cab6108 parent 7ffacc1a2527c219b834fe226a7a55dc67ca3637 parent a4cce10492358b33d33bb43f98284c80482037e8 author Tony Luck [EMAIL PROTECTED] 1124808655 -0700 committer Tony Luck [EMAIL PROTECTED] 1124808655 -0700 Pull release into test branch So I pulled 7ffacc and a4cce1 from your repository and started digging from there. 7ffacc was the head of test branch back then, and a4cce1 was the head of release branch. I checked out 7ffacc in the repository and pulled a4cce1 into it, using the GIT with the optimum merge-base patch. : siamese; git pull . aegl-release Packing 0 objects Unpacking 0 objects * committish: a4cce10492358b33d33bb43f98284c80482037e8 refs/heads/aegl-release from . Trying to find the optimum merge base. Trying to merge a4cce10492358b33d33bb43f98284c80482037e8 into 7ffacc1a2527c219b834fe226a7a55dc67ca3637 using c1ffb910f7a4e1e79d462bb359067d97ad1a8a25. Simple merge failed, trying Automatic merge Auto-merging arch/ia64/sn/kernel/io_init.c. Committed merge db376974c0aebb9e99e5cd0bce21088c6a9d927c arch/ia64/hp/sim/boot/boot_head.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) It is using c1ffb9 as the merge base. The problematic path in the three trees involved are: : siamese; git ls-tree -r aegl-test-7ffacc1a | grep arch/ia64/hp/sim/boot/bootloader.c 100644 blob a7bed60b69f9e8de9a49944e22d03fb388ae93c7 arch/ia64/hp/sim/boot/bootloader.c : siamese; git ls-tree -r aegl-release-a4cce1 | grep arch/ia64/hp/sim/boot/bootloader.c 100644 blob 51a7b7b4dd0e7c5720683a40637cdb79a31ec4c4 arch/ia64/hp/sim/boot/bootloader.c : siamese; git ls-tree -r aegl-c1ffb9 | grep arch/ia64/hp/sim/boot/bootloader.c 100644 blob 51a7b7b4dd0e7c5720683a40637cdb79a31ec4c4 arch/ia64/hp/sim/boot/bootloader.c So the file did not change between the merge base and release, and test had the change. merge-cache picked the one in the test release. Your guess in the other message hits the mark. I wonder what _other_ candidates these two commits have in common and what would have happened if they were used as the base instead? : siamese; git merge-base -a aegl-test-7ffacc1a aegl-release-a4cce1 f6fdd7d9c273bb2a20ab467cb57067494f932fa3 3a931d4cca1b6dabe1085cc04e909575df9219ae c1ffb910f7a4e1e79d462bb359067d97ad1a8a25 You can check what variant of the file each of these commits contain. What is happening is: * the problematic patch 4aec0f is one before 3a931d. Among the three merge-base candidates, only 3a931d contains teh wrongly patched version. * the problematic change 4aec0f patch introduces is part of test branch, because it was pulled via release. * the tip of release being merged into test has this patch reverted, and the file is exactly the same as before 4aec0f patch. So three-way trivial merge algorithm says, hey, the file did not change between common ancestor and release but it is different in test, so the one in the test branch must be the merge result. This does not have much to do with which common ancestor merge-base chooses. Sorry, I am not sure what is the right way to resolve this offhand. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-archimport-script - 2nd iteration
Gave the code another pass. The code should be more readable, and make a bit more sense. It now: - handles commit timestamps correctly - handles binary files correctly - uses parselog() to tell git-update-cache what's been added/deleted/modified - much faster commits on large trees - gets the commit msgs mostly ok In my immediate TODO: - handling renames - branches - incremental import A bit further off: - file modes - merge detection cheers, martin git-archimport-script Description: Binary data
Tool renames? was Re: First stab at glossary
So when this gets all settled, will we see a lot of tool renaming? While it would cause me and my team some personal effort (we have a special-purpose porcelain), it would be welcome to have a lexicon that is sane and consistent, and in tune with all the documentation. Others may feel differently, I understand. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
On Wed, 24 Aug 2005, Junio C Hamano wrote: [EMAIL PROTECTED] writes: So I have another anomaly in my GIT tree. A patch to back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c in my release branch at commit 62d75f3753647656323b0365faa43fc1a8f7be97 appears to have been lost when I merged the release branch to the test branch at commit 0c3e091838f02c537ccab3b6e8180091080f7df2 : siamese; git cat-file commit 0c3e091838f02c537ccab3b6e8180091080f7df2 tree 61a407356d1e897e0badea552ce69e657cab6108 parent 7ffacc1a2527c219b834fe226a7a55dc67ca3637 parent a4cce10492358b33d33bb43f98284c80482037e8 author Tony Luck [EMAIL PROTECTED] 1124808655 -0700 committer Tony Luck [EMAIL PROTECTED] 1124808655 -0700 Pull release into test branch So I pulled 7ffacc and a4cce1 from your repository and started digging from there. 7ffacc was the head of test branch back then, and a4cce1 was the head of release branch. I checked out 7ffacc in the repository and pulled a4cce1 into it, using the GIT with the optimum merge-base patch. : siamese; git pull . aegl-release Packing 0 objects Unpacking 0 objects * committish: a4cce10492358b33d33bb43f98284c80482037e8 refs/heads/aegl-release from . Trying to find the optimum merge base. Trying to merge a4cce10492358b33d33bb43f98284c80482037e8 into 7ffacc1a2527c219b834fe226a7a55dc67ca3637 using c1ffb910f7a4e1e79d462bb359067d97ad1a8a25. Simple merge failed, trying Automatic merge Auto-merging arch/ia64/sn/kernel/io_init.c. Committed merge db376974c0aebb9e99e5cd0bce21088c6a9d927c arch/ia64/hp/sim/boot/boot_head.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) It is using c1ffb9 as the merge base. The problematic path in the three trees involved are: : siamese; git ls-tree -r aegl-test-7ffacc1a | grep arch/ia64/hp/sim/boot/bootloader.c 100644 blob a7bed60b69f9e8de9a49944e22d03fb388ae93c7 arch/ia64/hp/sim/boot/bootloader.c : siamese; git ls-tree -r aegl-release-a4cce1 | grep arch/ia64/hp/sim/boot/bootloader.c 100644 blob 51a7b7b4dd0e7c5720683a40637cdb79a31ec4c4 arch/ia64/hp/sim/boot/bootloader.c : siamese; git ls-tree -r aegl-c1ffb9 | grep arch/ia64/hp/sim/boot/bootloader.c 100644 blob 51a7b7b4dd0e7c5720683a40637cdb79a31ec4c4 arch/ia64/hp/sim/boot/bootloader.c So the file did not change between the merge base and release, and test had the change. merge-cache picked the one in the test release. Your guess in the other message hits the mark. I wonder what _other_ candidates these two commits have in common and what would have happened if they were used as the base instead? : siamese; git merge-base -a aegl-test-7ffacc1a aegl-release-a4cce1 f6fdd7d9c273bb2a20ab467cb57067494f932fa3 3a931d4cca1b6dabe1085cc04e909575df9219ae c1ffb910f7a4e1e79d462bb359067d97ad1a8a25 You can check what variant of the file each of these commits contain. What is happening is: * the problematic patch 4aec0f is one before 3a931d. Among the three merge-base candidates, only 3a931d contains teh wrongly patched version. * the problematic change 4aec0f patch introduces is part of test branch, because it was pulled via release. * the tip of release being merged into test has this patch reverted, and the file is exactly the same as before 4aec0f patch. So three-way trivial merge algorithm says, hey, the file did not change between common ancestor and release but it is different in test, so the one in the test branch must be the merge result. This does not have much to do with which common ancestor merge-base chooses. Sorry, I am not sure what is the right way to resolve this offhand. If it picks 3a931d4cca1b6dabe1085cc04e909575df9219ae, it will determine that the file didn't change between that and test, and is different in release, so the one in release must be right. I believe that the hint that something is going on is that different common ancestors give different trivial merges (as opposed to some giving failure and some giving the same result), and resolving it probably involves identifying that that paths from f6f... and c1f... to release don't keep the same blob through the middle, despite having the same ends. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Query about status of http-pull
Hi, Recently cogito again say that the rsync method will be deprecated in future (due to http-pull now supporting pack objects I suppose), but it seems to me that it still have other issues: - lycan linux-2.6 # git pull origin Fetching HEAD using http Getting pack list error: Couldn't get 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf: not separate or in any pack error: Tried http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/05/72e3da3ff5c3744b2f606ecf296d5f89a4bbdf Cannot obtain needed object 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf while processing commit . lycan linux-2.6 # cg-update 17:50:02 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master [41/41] - refs/heads/.origin-pulling [1] FINISHED --17:50:09-- Downloaded: 11,949 bytes in 5 files Missing object of tag v2.6.13-rc7... unable to retrieve Up to date. Applying changes... Branch already fully merged. lycan linux-2.6 # - If you switch it however to rsync again, it works just fine. Other branches like that of KLIBC and one or two others do not even pull via http-pull. So basically the question is if this is known issues (had mail issues, so missed the last week or so's mail) ? Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Query about status of http-pull
On Wed, 24 Aug 2005, Martin Schlemmer wrote: Hi, Recently cogito again say that the rsync method will be deprecated in future (due to http-pull now supporting pack objects I suppose), but it seems to me that it still have other issues: - lycan linux-2.6 # git pull origin Fetching HEAD using http Getting pack list error: Couldn't get 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf: not separate or in any pack error: Tried http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/05/72e3da3ff5c3744b2f606ecf296d5f89a4bbdf Cannot obtain needed object 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf while processing commit . It looks like pack-c24bb5025e835a3d8733931ce7cc440f7bfbaaed isn't in the pack list. I suspect that updating this file should really be done by anything that creates pack files, because people forget to run the program that does it otherwise and then http has problems. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
Oops. I forgot to actually exit from the script if git-diff-files is
non-empty.
Also, looking at it now, I don't think keeping undo information in a
stack is the right thing. But keeping more than just one would be good.
Oh well, my first shot is never perfect. ;-)
Carl
On Wed, Aug 24, 2005 at 11:23:39AM -0600, Carl Baldwin wrote:
Hello,
So, one thing that I liked about GNU Arch when I tried it out was the
ability to undo and redo changes in the local working copy. I decided
to try to do this with git. What I have is preliminary. I'm sure it
could use some work.
So, I started with the assumption that all changes in the working copy
have been updated to the cache. My scripts check this (with
git-diff-files) and abort if this is not the case.
Undo calls git-write-tree to write the changes to the object store. It
stores that tree's hash and the current HEAD's tree's hash in a file.
Then it reverts the working copy to HEAD.
Redo grabs these two trees from the file, does git-write-tree to produce
a third tree and merges the three using the old HEAD's tree as the base
of the merge. This way, new commits can happen and the local copy can
be modified since the undo and it should still work assuming no
conflicts emerge.
Attached are the two scripts. Comments and criticism are welcome.
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAIL PROTECTED]
Fort Collins, CO 80525 home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/sh
. git-sh-setup-script || die Not a git archive
if [ -n $(git-diff-files) ]; then
echo The following files should be updated!
echo
git-diff-files | awk '{print $6}'
fi
undostack=$GIT_DIR/undostack
if [ ! -s $undostack ]; then
echo No undo information in $undostack
else
# Read the top of the stack
basetree=$(cat $undostack | tail -n 2 | head -n 1)
redotree=$(cat $undostack | tail -n 1)
# Pop the stack
cat $undostack | head -n -2 $undostack.tmp
mv $undostack{.tmp,}
currenttree=$(git-write-tree)
git-read-tree -u -m $basetree $currenttree $redotree
git-merge-cache git-merge-one-file-script -a
fi
#!/bin/sh
. git-sh-setup-script || die Not a git archive
if [ -n $(git-diff-files) ]; then
echo The following files should be updated!
echo
git-diff-files | awk '{print $6}'
fi
undostack=$GIT_DIR/undostack
headtree=$(git-cat-file commit $(cat $GIT_DIR/HEAD) | head -n 1 | sed -e
's/tree //')
undotree=$(git-write-tree)
if [ $headtree == $undotree ]; then
echo There are no changes to undo.
else
{
echo $headtree
echo $undotree
} $undostack
echo Saved current state as tree $undotree.
echo Reverting to HEAD, $headtree...
git-checkout-script -f
fi
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAIL PROTECTED]
Fort Collins, CO 80525 home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query about status of http-pull
Daniel Barkalow [EMAIL PROTECTED] writes: It looks like pack-c24bb5025e835a3d8733931ce7cc440f7bfbaaed isn't in the pack list. I suspect that updating this file should really be done by anything that creates pack files, because people forget to run the program that does it otherwise and then http has problems. True. Added at the end of git-repack-script (Linus can disable it by giving an '-n' flag when packing his private repositories). - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
Carl Baldwin [EMAIL PROTECTED] writes:
Attached are the two scripts. Comments and criticism are welcome.
An obligatory non-technical comment. I would have liked to see
this not in a MIME multipart format, which made commenting on it
a bit harder than necessary.
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=git-undo-script
#!/bin/sh
. git-sh-setup-script || die Not a git archive
if [ -n $(git-diff-files) ]; then
echo The following files should be updated!
echo
git-diff-files | awk '{print $6}'
fi
There is nothing wrong with the above, but I would have written
it like this (I think you forgot to exit after showing the list
of files):
git-update-cache --refresh || exit
Also nice to learn here is git-diff-files --name-only.
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=git-redo-script
#!/bin/sh
. git-sh-setup-script || die Not a git archive
if [ -n $(git-diff-files) ]; then
echo The following files should be updated!
echo
git-diff-files | awk '{print $6}'
fi
Same here.
currenttree=$(git-write-tree)
git-read-tree -u -m $basetree $currenttree $redotree
git-merge-cache git-merge-one-file-script -a
Interesting. Very interesting.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query about status of http-pull
On Wed, 24 Aug 2005, Junio C Hamano wrote: Added at the end of git-repack-script (Linus can disable it by giving an '-n' flag when packing his private repositories). No, I just haven't updated my git on master.kernel.org in a while. So nothing to disable. I ran git-update-server-info manually, so it should work now. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
On Wed, 24 Aug 2005, Linus Torvalds wrote: Basically, he had two branches, A and B, and both contained the same patch (but _not_ the same commit). One undid it, the other did not. There's no real way to say which one is correct, and both cases clearly merge perfectly, so both outcomes patch applied and patch reverted are really equally valid. In fact, the case that git selected (patch applied), is not only the one that is very fundamentally the one git will always select in this kind of situation - in some respects is actually the nicer choice of the two. While it may cause problems (ie the revert was the right thing to do), it's at least the state that is less likely to be lost. Having a revert disappear is likely better than having a real change disappear. The reaction to the reverted code showing up again is likely damn, won't that bug ever go away, I fixed it once already - but at least people will see that it's fair: it was applied twice, so let's revert it twice. In contrast, the reaction to a patch going away is likely just very confusing: you have two people applying it, but only one reverting it will revert both, while the first person who applied it may never have realized it got reverted. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
On Wed, 24 Aug 2005, Carl Baldwin wrote: Oops. I forgot to actually exit from the script if git-diff-files is non-empty. Also, looking at it now, I don't think keeping undo information in a stack is the right thing. But keeping more than just one would be good. Oh well, my first shot is never perfect. ;-) I would actually argue that git checkout -b newbranch undo-point is the perfect undo. It leaves the old state in the old branch, and creates a new branch (and checks it out) with the state you want to revert to. The advantage is exactly that there is no stack of undo's: you can have multiple independent undo's pending, and you can continue development at any of them. And merge the results together. Of course, right now we don't have a delete branch command, but it's really as simple as rm .git/refs/heads/branchname (and eventually you may want to do a git prune to get rid of stale objects, but that's a separate issue). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix git-rev-parse breakage
On Wed, 24 Aug 2005, Junio C Hamano wrote: that is not a right thing so get rid of that assumption (which I agree is a good change, and the last sentense says opposite... Well, the patch makes it an _explicit_ assumption, instead of a very subtly hidden one from the code-flow. It was the non-obvious hidden assumption that caused the bug. Here is my thinking, requesting for a sanity check. * git-whatchanged wants to use it to tell rev-list arguments from rev-tree arguments. You _do_ want to pick --max-count=10 or --merge-order in this case, and --revs-only implying --no-flags would make this impossible. Fair enough. However, there are two kinds of flags: the revision flags, and the -p kind of flags. And the problem was that git-whatchanged -p didn't work any more, because we passed -p along to git-rev-list. Gaah. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
On Wed, 24 Aug 2005, Linus Torvalds wrote: Now, if the shared patch hadn't been a patch, but a shared _commit_, then the thing would have been unambiguous - the shared commit would have been the merge point, and the revert would have clearly undone that shared commit. Actually, it was a shared commit (4aec0fb12267718c750475f3404337ad13caa8f5), which was (an ancestor of) a candidate merge point, but wasn't the one selected. Since a different one was chosen, it looked to the 3-way merge like a shared patch (since it ignores the untaken parent in the merges in the history). This should be fixable, but it'll require more cleverness in read-tree. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
On Wed, Aug 24, 2005 at 11:51:32AM -0700, Linus Torvalds wrote: On Wed, 24 Aug 2005, Carl Baldwin wrote: Oops. I forgot to actually exit from the script if git-diff-files is non-empty. Also, looking at it now, I don't think keeping undo information in a stack is the right thing. But keeping more than just one would be good. Oh well, my first shot is never perfect. ;-) I would actually argue that git checkout -b newbranch undo-point is the perfect undo. Yes, this does the job nicely. I've used it like this effectively. I meant for undo/redo to be a lighter weight way of moving (uncommitted) changes out of the way briefly and then replaying them onto the working directory later. It leaves the old state in the old branch, and creates a new branch (and checks it out) with the state you want to revert to. The advantage is exactly that there is no stack of undo's: you can have multiple independent undo's pending, and you can continue development at any of them. And merge the results together. The stack was the wrong thing to do. I think I would have undo pick a name like undo-1, undo-2 etc. Or something like that. redo would pick the most recent unless told to do otherwise. A possible advantage of undo is having the freedom to stay on the current branch or switch to another. Of course, right now we don't have a delete branch command, but it's really as simple as rm .git/refs/heads/branchname (and eventually you may want to do a git prune to get rid of stale objects, but that's a separate issue). Linus This brings up a good point (indirectly). git prune would destroy the undo objects. I had thought of this but decided to ignore it for the time being. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
On Wed, Aug 24, 2005 at 11:18:42AM -0700, Junio C Hamano wrote:
Carl Baldwin [EMAIL PROTECTED] writes:
Attached are the two scripts. Comments and criticism are welcome.
An obligatory non-technical comment. I would have liked to see
this not in a MIME multipart format, which made commenting on it
a bit harder than necessary.
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=git-undo-script
#!/bin/sh
. git-sh-setup-script || die Not a git archive
if [ -n $(git-diff-files) ]; then
echo The following files should be updated!
echo
git-diff-files | awk '{print $6}'
fi
There is nothing wrong with the above, but I would have written
it like this (I think you forgot to exit after showing the list
of files):
git-update-cache --refresh || exit
I'll take this. This is what I was going for but being new to git I
didn't know all that was available. A good reason to request comments
:-)
Also nice to learn here is git-diff-files --name-only.
Also good to know, thanks.
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAIL PROTECTED]
Fort Collins, CO 80525 home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: baffled again
I think git did the right thing, it just happened to be the thing that Tony didn't want. Which makes it the wrong thing, of course, but from a purely technical standpoint, I don't think there's anything really wrong with the merge. On the plus side ... at least it wasn't a dumb user error this time [unless you count merging the incorrect patch in the first place, and then having to revert it :-) ]. Could GIT be smarter here? Perhaps it could pick a few likely ancestors and run the merge with each ... and then give some warnings if there are files that come out differently? -Tony - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
On Wed, 24 Aug 2005, Carl Baldwin wrote: This brings up a good point (indirectly). git prune would destroy the undo objects. I had thought of this but decided to ignore it for the time being. If you made undo store the tree under refs somewhere, git prune would preserve it. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Rationalize output selection in rev-parse.
Earlier rounds broke 'whatchanged -p'. In attempting to fix this,
make two axis of output selection in rev-parse orthogonal:
--revs-only tells it not to output things that are not revisions nor
flags that rev-list would take.
--no-revs tells it not to output things that are revisions or
flags that rev-list would take.
--flags tells it not to output parameters that do not start with
a '-'.
--no-flagstells it not to output parameters that starts with a '-'.
So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386',
while 'rev-parse --no-revs --flags -p arch/i386' would give just '-p'.
Also the meaning of --verify has been made stronger. It now rejects
anything but a single valid rev argument. Earlier it passed some flags
through without complaining.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
Linus Torvalds [EMAIL PROTECTED] writes:
Fair enough. However, there are two kinds of flags: the
revision flags, and the -p kind of flags.
And the problem was that git-whatchanged -p didn't work any more,
because we passed -p along to git-rev-list. Gaah.
Thanks for noticing.
rev-parse.c | 121 ++-
1 files changed, 54 insertions(+), 67 deletions(-)
4866ccf0f434db118c4dcdeeab840eb4844d50a4
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -7,20 +7,21 @@
#include commit.h
#include refs.h
+#define DO_REVS1
+#define DO_NOREV 2
+#define DO_FLAGS 4
+#define DO_NONFLAGS8
+static int filter = ~0;
+
static char *def = NULL;
-static int no_revs = 0;
-static int single_rev = 0;
-static int revs_only = 0;
-static int do_rev_argument = 1;
-static int output_revs = 0;
-static int flags_only = 0;
-static int no_flags = 0;
-static int output_sq = 0;
-static int symbolic = 0;
#define NORMAL 0
#define REVERSED 1
static int show_type = NORMAL;
+static int symbolic = 0;
+static int output_sq = 0;
+
+static int revs_count = 0;
/*
* Some arguments are relevant revision arguments,
@@ -30,13 +31,19 @@ static int show_type = NORMAL;
static int is_rev_argument(const char *arg)
{
static const char *rev_args[] = {
- --max-count=,
+ --bisect,
+ --header,
--max-age=,
- --min-age=,
+ --max-count=,
--merge-order,
- --topo-order,
- --bisect,
+ --min-age=,
--no-merges,
+ --objects,
+ --parents,
+ --pretty,
+ --show-breaks,
+ --topo-order,
+ --unpacked,
NULL
};
const char **p = rev_args;
@@ -47,11 +54,13 @@ static int is_rev_argument(const char *a
if (!str)
return 0;
len = strlen(str);
- if (!strncmp(arg, str, len))
+ if (!strcmp(arg, str) ||
+ (str[len-1] == '=' !strncmp(arg, str, len)))
return 1;
}
}
+/* Output argument as a string, either SQ or normal */
static void show(const char *arg)
{
if (output_sq) {
@@ -70,11 +79,13 @@ static void show(const char *arg)
puts(arg);
}
+/* Output a revision, only if filter allows it */
static void show_rev(int type, const unsigned char *sha1, const char *name)
{
- if (no_revs)
+ if (!(filter DO_REVS))
return;
- output_revs++;
+ def = NULL;
+ revs_count++;
if (type != show_type)
putchar('^');
@@ -84,29 +95,12 @@ static void show_rev(int type, const uns
show(sha1_to_hex(sha1));
}
-static void show_rev_arg(char *rev)
+/* Output a flag, only if filter allows it. */
+static void show_flag(char *arg)
{
- if (no_revs)
+ if (!(filter DO_FLAGS))
return;
- show(rev);
-}
-
-static void show_norev(char *norev)
-{
- if (flags_only)
- return;
- if (revs_only)
- return;
- show(norev);
-}
-
-static void show_arg(char *arg)
-{
- if (no_flags)
- return;
- if (do_rev_argument is_rev_argument(arg))
- show_rev_arg(arg);
- else
+ if (filter (is_rev_argument(arg) ? DO_REVS : DO_NOREV))
show(arg);
}
@@ -122,7 +116,6 @@ static void show_default(void)
show_rev(NORMAL, sha1, s);
return;
}
- show_norev(s);
}
}
@@ -134,7 +127,7 @@ static int show_reference(const char *re
int main(int argc, char **argv)
{
- int i, as_is = 0;
+ int i, as_is = 0, verify = 0;
unsigned char sha1[20];
const char *prefix = setup_git_directory();
@@ -143,15 +136,13 @@ int main(int argc, char
[PATCH] Gitk tree view (correction)
I'm sorry for sending a non-working patch. Apparently I got lost in /tmp.
So here is the patch for gitk that allows you to browse the entire tree for
every revision.
The patched gitk script and some screenshots can be found at:
http://public.efil.de/gitk/
For my personal use it's rather sufficient.
If anybody is interested in using it, I would clean it up.
- Ingo
Add tree view.
This allows you to browse the entire tree for every revision.
You may switch back an forward betweem the two modes at any time.
Keybindings: v - toggle view mode (tree/commit)
l - toggle line numbers
---
commit dbbfcc0cabb8eaaff998dc95957d73867f0e2f35
tree 53d7597f0f42ca1c3f7f01c7ca60d14541077a89
parent ccf1ee327f9a7d51704578fa41ba255abfd3a730
author [EMAIL PROTECTED](none) Thu, 25 Aug 2005 00:13:22 +0200
committer [EMAIL PROTECTED](none) Thu, 25 Aug 2005 00:13:22 +0200
gitk | 192 --
1 files changed, 187 insertions(+), 5 deletions(-)
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -329,12 +329,13 @@ proc makewindow {} {
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
global maincursor textcursor curtextcursor
-global rowctxmenu gaudydiff mergemax
+global rowctxmenu gaudydiff mergemax viewmodebutton
menu .bar
.bar add cascade -label File -menu .bar.file
menu .bar.file
.bar.file add command -label Reread references -command rereadrefs
+.bar.file add command -label Toggle line numbers -command togglelinenum
.bar.file add command -label Quit -command doquit
menu .bar.help
.bar add cascade -label Help -menu .bar.help
@@ -381,6 +382,9 @@ proc makewindow {} {
.ctop.top.clist add $canv3
bind .ctop.top.clist Configure {resizeclistpanes %W %w}
+set viewmodebutton Tree
+button .ctop.top.bar.viewmodebutton -textvariable viewmodebutton -command
toggleviewmode
+pack .ctop.top.bar.viewmodebutton -side left
set sha1entry .ctop.top.bar.sha1
set entries $sha1entry
set sha1but .ctop.top.bar.sha1label
@@ -493,9 +497,11 @@ proc makewindow {} {
bindkey Key-space $ctext yview scroll 1 pages
bindkey p selnextline -1
bindkey n selnextline 1
+bindkey l togglelinenum
bindkey b $ctext yview scroll -1 pages
bindkey d $ctext yview scroll 18 units
bindkey u $ctext yview scroll -18 units
+bindkey v toggleviewmode
bindkey / {findnext 1}
bindkey Key-Return {findnext 0}
bindkey ? findprev
@@ -2815,10 +2821,178 @@ proc gettreediffline {gdtf ids} {
lappend treediff $file
}
+proc toggleviewmode {} {
+global treemode viewmodebutton selectedline cflist viewpath ctext
+if { $treemode } {
+set viewmodebutton Tree
+set treemode false
+} else {
+set viewmodebutton Commit
+set treemode true
+}
+# redraw
+if {![info exists selectedline]} return
+set l [expr $selectedline]
+selectline $l 1
+# select current file
+if {! $treemode } {
+set commitfiles [ $cflist get 0 end ]
+set index [ lsearch $commitfiles $viewpath ]
+if { $index 0 } {
+catch { after 500 $ctext yview fmark.$index }
+}
+}
+}
+
+proc togglelinenum {} {
+global showlinenum selectedline
+if { $showlinenum } { set showlinenum false } else { set showlinenum true }
+if {![info exists selectedline]} return
+set l [expr $selectedline]
+selectline $l 1
+}
+
+proc viewfull { path } {
+global ctext currentid viewpath
+$ctext conf -state normal
+$ctext delete 0.0 end
+
+if { $path != } { set viewpath $path }
+if { $viewpath == Comments || $viewpath == / || $viewpath == } {
+set path
+set viewpath /
+set kind root
+set sha $currentid
+} else {
+if [catch {set stream [open |git-ls-tree $currentid $viewpath r]}] {
+$ctext insert end ERROR: viewfull: git-ls-tree $currentid
$viewpath
+return
+}
+gets $stream line
+fconfigure $stream -blocking 0
+close $stream
+if { $line == } {
+set kind NOT FOUND !!!
+} else {
+set kind [lindex $line 1]
+}
+set sha [lindex $line 2]
+}
+
+viewheader $viewpath $kind
+
+if { $kind == blob} {
+ viewblob $sha
+} elseif { $kind == tree || $kind == root} {
+ viewtree $sha
+}
+}
+
+proc viewheader { path kind } {
+global ctext
+$ctext insert end type: $kind\n
+$ctext insert end path:
+
+set splitpath [ linsert [ split [ string trim $path / ] / ] 0 ROOT ]
+set name [ lindex $splitpath end ]
+set splitpath [ lrange $splitpath 0 end-1 ]
+set buildpath /
+foreach next $splitpath {
+if { $next != ROOT } {
+append buildpath $next/
+}
+
Re: [RFC] undo and redo
Daniel Barkalow [EMAIL PROTECTED] writes: Generally, each subdirectory of refs/ has refs to objects of the same type, and heads/ is commits, but other directories are other things. tags/ is all tag objects, and you could have undo/ be trees. That's OK from the prune front, but I am not sure what the ramifications of this for pulling, pushing, and resolving. I would not recommend it without really thinking it through. Also note that tags/ is not all tag objects. I think git tag by default creates a lightweight tag, not an annotated kind. I think you could do either one of two things. As usual, totally untested. Just thinking aloud. (1) A hack. - Have a single undo-redo branch, which was forked from somewhere on the master branch. - When doing undo, make a commit that has the current top of undo-redo branch as the first parent and the current HEAD commit as the second parent, using the tree that represents your snapshot, to grow undo-redo branch. No, this commit does *not* represent a merge, but I am abusing the capability to record more than one parent commits. - When running redo, you would want a handy way to name what to redo. You can say undo-redo~N to mean Nth from the top of undo-redo branch. Your implementation of redo can either be (patch way): git-diff-tree -p undo-redo~N^ undo-redo~N | git apply --index or (merge way): git-read-tree -m undo-redo~N^2 undo-redo~N HEAD git-merge-cache -o git-merge-one-file-script -a (2) Try StGIT. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Tim Ottinger [EMAIL PROTECTED] writes: So when this gets all settled, will we see a lot of tool renaming? I personally do not see it coming. Any particular one you have in mind? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] GIT 0.99.5
I've pushed out all of what has been in the proposed updates branch, along with documentation updates. Many changes all over: - pulling from packed repository. - cvsimport. - documentation coverage. - usability. - terminology clarification. - hooks for updates and commits. - updated gitk. - multi-head push, fetch, pull, octopus merge. - faster merge-base. - git from subdirectories. - build procedure cleanups. Have fun. What to expect after 0.99.5 === This is written in a form of to-do list for me, so if I say accept patch, it means I do not currently plan to do that myself. People interested in seeing it materialize please take a hint. Documentation - * Accept patches from people who actually have done CVS migration and update the cvs-migration documentation. Link the documentation from the main git.txt page. * Update the SubmittingPatches document to add MUA specific hints on how to disable unwanted MIME and flowed-text by collecting past list postings. Accept patches from people who was hit by shiny blue bat to update the same. * Talk about using rsync just once at the beginning when initializing a remote repository so that local packs do not need to be expanded. I personally do not think we need tool support for this. * Update tutorial to cover shared repository style a bit more, maybe with a toy project that involves two or three repositories. * Update tutorial to cover setting up repository hooks to do common tasks. * Get help to properly use asciidoc in tutorial. * Maybe justify and demonstrate an Octopus in the tutorial. Add it to the glossary. Technical (heavier) --- * Tony Luck reported an unfortunate glitch in the 3-way merge. Encourage discussions to come up with a not-so-expensive way to catch the kind of ambiguities that led to his misery. Technical (milder) -- * When the branch head pointed by $GIT_DIR/HEAD changes while the index file and working tree are looking the other way (e.g. somebody pushed into your repository, or you ran git fetch to update the ref your working tree is on), git checkout without -f gets confused. Figure out a good way to handle this. * git commit -m should work for initial commits and perhaps merge commits as well. Warning about merge is still a good thing to do, while -m is useful in scripted non-interactive use, so we need to be careful. * Encourage concrete proposals to commit log message templates we discussed some time ago. * Bug Ryan and work with him to update send-email easier to use. * Look at portability fixes from Jason Riedy http://www.cs.berkeley.edu/~ejr/gits/git.git#portable * Accept patches to cause read-tree -u delete a directory when it makes it empty. * Perhaps accept patches to introduce the concept of patch flow expressed as ref mappings Josef has been advocating about. * MIMEified applymbox to grok B and Q encodings in headers and turn them into UTF-8; unwrap QP; explode multipart. * git cherry-pick that applies the patch an existing commit introduces in its ancestry chain, possibly using the 3-way merge machinery; update rebase using the cherry-pick command. Carl's redo/undo might fall out naturally from this. * A tool to detect, show and prune already merged topic branches. * Perhaps git branch -d to delete a branch. * Enhance git repack to not always use --all; this would be handy if the repository contains wagging heads like pu in git.git repository. * Remove git clone-dumb-http. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Looking at multiple ancestors in merge
Daniel Barkalow wrote: I'm starting to work on letting the merging process see multiple ancestors, and I think it's messy enough that I should actually discuss it. Review of the issue: It is possible to lost reverts in cases when merging two commits with multiple ancestors, in the following pattern: (letters representing blobs at some filename, children to the right) a-b-b-a-? \ X / a-b-b [Lots of stuff deleted] There seems to be a lot of effort being put into auto-magically choosing the right merge in the presence of multiple possible merge bases. Unfortunately, most (all?) of the proposals are attempting to divine intent, and so, are guaranteed to be 100% wrong at least some of the time. Wouldn't it be better, instead, to detect that current merge being attempted is ambiguous and require the user to specify the correct merge base? The alternative is a tool that appears to work all of the time but does the wrong thing some of the time. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
So, I've tried cloning, pulling to|from, pushing to|from and resolving merges in a repository with undo information stored under .git/refs/undo. None of these operations seem to notice the existence of this directory. I think this is good. What I meant was that, when undo/bar is a tree object, things may work in a funny way: $ git pull ../repo-with-undo/.git refs/undo/bar $ git push ../other-repo/.git undo/bar:refs/heads/foo $ cd ../other-repo git resolve master foo 'Attempt to merge undo' I think this undo/redo first needs to be thought about how best it is used. My guess is that the workflow you have in mind is something like this: $ git checkout master $ hack hack hack # Hmph, it almost works, and but my boss says work on # some other feature that is more urgent $ git undo Saved current state as 2005-08-24T20:32:22 $ work work work $ git commit -m 'Boring but urgent fix' # Ok, now let's back to the thing I wanted to do. $ git redo # I happen to know it is the last undo, so I did not name # it, but I could have said 2005-08-24T20:32:22 $ hack more $ git commit -m 'Finally fix frotz.' I see some problems in this. One is minor. As you mentioned about giving undo a symbolic name, after you accumulate a handful undo, you would need them to have descriptive names, and a way to list them before using git redo. But as Linus suggested in another reply, you could as well have done this without inventing these two commands. $ git checkout master $ hack hack hack # Hmph, it almost works, and but my boss says work on # some other feature that is more urgent $ git commit -m 'WIP - fix frotz' $ git branch anchor-frotz $ git reset --hard master^ $ work work work $ git commit -m 'Boring but urgent fix' # Ok, now let's go back to the thing I wanted to do. $ git pull . anchor-frotz $ rm .git/heads/anchor-frotz $ git reset --soft master^ $ hack more $ git commit -m 'Finally fix frotz.' The above flow would be something somebody not so organized (like myself) would do. A perfect person would have done this: $ git checkout -b frotz master $ hack hack hack # Hmph, it almost works, and but my boss says work on # some other feature that is more urgent $ git commit -m 'WIP - fix frotz' $ git checkout master $ work work work $ git commit -m 'Boring but urgent fix' # Ok, now let's go back to the thing I wanted to do. $ git checkout frotz $ git reset --soft HEAD^ $ hack more $ git commit -m 'Finally fix frotz.' $ git checkout master $ git pull . frotz $ rm .git/refs/heads/frotz The perfect person approach has an added benefit that you could have made intermediate commits while doing hacking, because your hackery is always done in the frotz branch. Of course, the scenarios your undo/redo is useful for may not be limited to this handling interrupt use case. If that is the only thing it solves, then I do not see much point having them as new commands. I think the undo/redo has potential beyond that. So let's first clarify what kind of workflow these new commands would help, how well that workflow is applicable in general, and then how well these new commands would help that workflow. I would be glad to write up documentation and provide a patch. Sure. I think a set of patches for new commands, and new options to existing commands should ideally include the following: - Justification, such as: - The problems new commands/options address. - The expected workflow the new commands/options fit in. - How useful that workflow is. - How impossible or cumbersome to achieve that workflow using existing tools. Some of these should go to the commit log message, and the documentation to describe the best practice workflow using the new feature should go to Documentation/howto/ directory. - Documentation. Files Documentation/git-*.txt to describe new commands or updates to existing pages, new entry in Documentation/Makefile as necessary, and a new link from Documentation/git.txt to reach that page. - Implementation. - Test scripts in t/ directory, either a new test script or updates to existing ones, if the patch is to fix existing implementation. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Looking at multiple ancestors in merge
On Wed, 24 Aug 2005, A Large Angry SCM wrote: Daniel Barkalow wrote: I'm starting to work on letting the merging process see multiple ancestors, and I think it's messy enough that I should actually discuss it. Review of the issue: It is possible to lost reverts in cases when merging two commits with multiple ancestors, in the following pattern: (letters representing blobs at some filename, children to the right) a-b-b-a-? \ X / a-b-b [Lots of stuff deleted] There seems to be a lot of effort being put into auto-magically choosing the right merge in the presence of multiple possible merge bases. Unfortunately, most (all?) of the proposals are attempting to divine intent, and so, are guaranteed to be 100% wrong at least some of the time. Wouldn't it be better, instead, to detect that current merge being attempted is ambiguous and require the user to specify the correct merge base? The alternative is a tool that appears to work all of the time but does the wrong thing some of the time. My proposal is actually to detect when a merge is ambiguous. In order to determine that, however, you have to evaluate multiple potential outcomes and see if they are actually different. I'm working on an efficient way to do that. Then further work could look into eliminating possibilities when information about the history excludes them. There were two issues in the case that Tony hit: it ignored a potential correct outcome for the merge, and it didn't ignore an outcome which could be demonstrated to be incorrect. The priority is to resolve the first, but things which improve the second or help with solutions to the second are worth understanding. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
* Even if it does always choose the nicer choice of the two, Tony was lucky (no pun intended). Rather, we were lucky that Tony was observant. A careless merger may well have easily missed this mismerge (from the human point of view). Actually I can't take credit here. This was a case of the many-eyes of open source working at its finest ... someone e-mailed me and told me that I should have backed out the old patch before applying the new one. While typing the e-mail to say that I already had in the release branch, I found the problem that it had been lost in the merge into the test branch. But this is a good reminder that merging is not a precise science, and there is more than one plausible merge in many situations ... and while GIT will pick the one that you want far more often than not, there is the possibility that it will surprise you. Maybe there should be a note to this effect in the tutorial. Git is not magic, nor is it imbued with DWIM technology. -Tony - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
