* Re: Submodules: Publishing a locally created submodule.
From: Thomas Adam @ 2008-07-25 0:05 UTC (permalink / raw)
To: Mark Levedahl; +Cc: git mailing list
In-Reply-To: <48891088.40709@gmail.com>
Hello --
2008/7/25 Mark Levedahl <mlevedahl@gmail.com>:
> git submodule add <URL where this will exist> ./mysubmoduleB
>
> will recognize that mysubmoduleB is already a valid git repo and add it as
> is at the current location to the superproject.
Ah -- now that was missing from the documentation (the syntax; not the
intention.) Thanks.
It seems my brain has turned to mush so I need to go back to square
one and verify the steps for this are accurate. If I am doing this
arse-about-face, do say. ;)
I've mentioned I am using a bare repository which is shared amongst
developers. We've been using one fine for normal development and for
various reaons I am creating a new repository to be filled with
submodules. I shall call this "SM".
Our "superproject" is a directory hierarchy with interspersed files.
On the server I did this:
server% cd /usr/src/SM
server% git init
server% cd ./superproject
server% git init
server% git add .
server% git commit -m "Initial checkin"
server% cd ..
server% git submodule add /path/to/usr/src/SM
server% git commit -a -m "Submodules..."
Then cloned a bare repo from that which I was able to clone locally
and do stuff in. I could push stuff out too for that one project.
But how from this clone do I then publish any further submodules I
might create locally? I can't very well do so directly in my checkout
-- it has no concept of where the submodules are. I could go to the
server, add another directory as a submodule (as I've done with
"superproject" above --- but then any changes under /usr/src/SM on the
server are local -- the bare repo has no knowledge of any changes made
there.
Does this even make sense? ;)
Thanks in advance.
-- Thomas Adam
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-25 0:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <200807242201.23991.jnareb@gmail.com>
Hi,
On Thu, 24 Jul 2008, Jakub Narebski wrote:
> I think teaching git to use index version of .git* files (.gitignore,
> .gitattributes, .gitmodules) would be much more work than adding
> default rule that .git* files in leading directories are by default
> checked out, just like leading directories are checked out.
"Teaching" Git that would also directly contradict Git's primary motto:
"Content is king".
Oh, by some convoluted reasoning you could argue that "content" hidden
somewhere else than the working directory is "content", but nobody in her
right mind would buy into that.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Johannes Schindelin @ 2008-07-25 0:09 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20080724182813.GA21186@sigill.intra.peff.net>
Hi,
On Thu, 24 Jul 2008, Jeff King wrote:
> On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
>
> > > As a user, I would expect "sparse clone" to also be sparse on the
> > > fetching. That is, to not even bother fetching tree objects that we
> > > are not going to check out. But that is a whole other can of worms
> > > from local sparseness, so I think it is worth saving for a different
> > > series.
> >
> > I think this is not even worth of a series. Sure, it would have
> > benefits for those who want sparse checkouts. But it comes for a high
> > price on everyone else:
>
> I agree there are a lot of issues. I am just thinking of the person who
> said they had a >100G repository. But I am also not volunteering to do
> it, so I will let somebody who really cares about it try to defend the
> idea.
I never said that there were no benefits. I argued that there are too
many _downsides_ to those who _don't_ benefit.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Johannes Schindelin @ 2008-07-25 0:12 UTC (permalink / raw)
To: sverre; +Cc: Petr Baudis, Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <bd6139dc0807241201v50cd5ef2m58ee7efc05119e20@mail.gmail.com>
Hi,
On Thu, 24 Jul 2008, Sverre Rabbelier wrote:
> On Thu, Jul 24, 2008 at 8:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> > I don't follow how these two issues arise, if the server will do the
> > pruning for you. It will just skip entering some tree objects when
> > doing object traversal; why opening the git protocol or faking
> > commits? This would be a simple extra capability in the protocol.
>
> Wouldn't that be as simple as passing a pathspec to git-rev-list? Not a
> lot of overhead there I reckon.
So the server would _not_ have to deflate the objects to inspect them? I
thought you knew more about Git's object database.
> > One question is what to do with delta chains including unwanted
> > objects, but I think that given the objects' associativity for delta
> > chains, this shouldn't be huge practical issues and it could be
> > affordable in principle to include even unwanted objects.
>
> Just keep them?
You'd still have to inspect the objects, which is way more work than the
current code has to do. Remember: in the optimal case, upload-pack does
not more than just serve the existing deltas/base objects.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach fsck and prune about the new location of temporary objects
From: Johannes Schindelin @ 2008-07-25 0:33 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <6ruv3Y98_kSSVnJFTkV0PNdiNcQ3g-a3M4BhGoT7S1PorElp5tJAkw@cipher.nrlssc.navy.mil>
Hi,
On Thu, 24 Jul 2008, Brandon Casey wrote:
> Since 5723fe7e, temporary objects are now created in their final destination
> directories, rather than in .git/objects/. Teach fsck to recognize and
> ignore the temporary objects it encounters,
It somehow feels wrong for fsck to ignore anything that could be used.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Petr Baudis @ 2008-07-25 0:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <alpine.DEB.1.00.0807250210090.4140@eeepc-johanness>
Hi,
On Fri, Jul 25, 2008 at 02:12:31AM +0200, Johannes Schindelin wrote:
> On Thu, 24 Jul 2008, Sverre Rabbelier wrote:
>
> > On Thu, Jul 24, 2008 at 8:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> > > I don't follow how these two issues arise, if the server will do the
> > > pruning for you. It will just skip entering some tree objects when
> > > doing object traversal; why opening the git protocol or faking
> > > commits? This would be a simple extra capability in the protocol.
> >
> > Wouldn't that be as simple as passing a pathspec to git-rev-list? Not a
> > lot of overhead there I reckon.
>
> So the server would _not_ have to deflate the objects to inspect them? I
> thought you knew more about Git's object database.
..snip..
> You'd still have to inspect the objects, which is way more work than the
> current code has to do. Remember: in the optimal case, upload-pack does
> not more than just serve the existing deltas/base objects.
then right now, exactly how does the server decide that the blob
7a7ff130 should be served along git.git HEAD? I still see upload-pack.c
calling traverse_commit_list() that does process_tree() on every tree,
etc. But the code is not straightforward, maybe I'm missing some
shortcut?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: James Pickens @ 2008-07-25 0:46 UTC (permalink / raw)
To: git
In-Reply-To: <20080724182813.GA21186@sigill.intra.peff.net>
Jeff King <peff <at> peff.net> writes:
> I agree there are a lot of issues. I am just thinking of the person who
> said they had a >100G repository. But I am also not volunteering to do
> it, so I will let somebody who really cares about it try to defend the
> idea.
If you're referring to me (I mentioned a 144G CVS repo), then let me
clarify a couple of things:
1. Probably more than 50% of the 144G is crud that should never have
been checked in, but I have some undisciplined coworkers who like to
blindly check in everything in their work trees. If/when we moved to
git, I would get rid of all that crud. I'm also thinking about throwing
out a lot of the history, since those same undisciplined coworkers like
to use empty and/or useless log messages, so a lot of the history isn't
very valuable anyways.
2. Git of course will store the remaining ~70G much more efficiently
than CVS. I think git will be especially better than CVS for this repo,
because it contains many instances of the same file(s) being checked in
in multiple directories.
I expect the git repo size to be less than 7G. In addition, all our
work is done on site on nfs, so we can use clone -s to avoid copying the
whole 7G.
To sum it up, sparse cloning would not be important to me.
James
^ permalink raw reply
* [StGit PATCH] Fix some remaining old-style stg id calls
From: Karl Hasselström @ 2008-07-25 0:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080713114047.18845.34899.stgit@localhost.localdomain>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
You'll want to add this (just squash it into your patch). The calls
were failing, but since both sides produced the empty string on
stdout, the test was happy anyway.
t/t1300-uncommit.sh | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t1300-uncommit.sh b/t/t1300-uncommit.sh
index a906d13..472baa4 100755
--- a/t/t1300-uncommit.sh
+++ b/t/t1300-uncommit.sh
@@ -42,7 +42,7 @@ test_expect_success \
'Uncommit the patches using names' \
'
stg uncommit bar foo &&
- [ "$(stg id foo//top)" = "$(stg id bar//bottom)" ] &&
+ [ "$(stg id foo)" = "$(stg id bar^)" ] &&
stg commit --all
'
@@ -50,7 +50,7 @@ test_expect_success \
'Uncommit the patches using prefix' \
'
stg uncommit --number=2 foobar &&
- [ "$(stg id foobar1//top)" = "$(stg id foobar2//bottom)" ] &&
+ [ "$(stg id foobar1)" = "$(stg id foobar2^)" ] &&
stg commit --all
'
@@ -58,7 +58,7 @@ test_expect_success \
'Uncommit the patches using auto names' \
'
stg uncommit --number=2 &&
- [ "$(stg id foo-patch//top)" = "$(stg id bar-patch//bottom)" ] &&
+ [ "$(stg id foo-patch)" = "$(stg id bar-patch^)" ] &&
stg commit --all
'
@@ -67,14 +67,14 @@ test_expect_success \
'
stg uncommit &&
stg uncommit &&
- [ "$(stg id foo-patch//top)" = "$(stg id bar-patch//bottom)" ] &&
+ [ "$(stg id foo-patch)" = "$(stg id bar-patch^)" ] &&
stg commit --all
'
test_expect_success \
'Uncommit the patches with --to' '
stg uncommit --to HEAD^ &&
- [ "$(stg id foo-patch//top)" = "$(stg id bar-patch//bottom)" ] &&
+ [ "$(stg id foo-patch)" = "$(stg id bar-patch^)" ] &&
stg commit --all
'
^ permalink raw reply related
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path?to do sparse clone
From: Jeff King @ 2008-07-25 0:49 UTC (permalink / raw)
To: James Pickens; +Cc: git
In-Reply-To: <loom.20080725T004541-298@post.gmane.org>
On Fri, Jul 25, 2008 at 12:46:52AM +0000, James Pickens wrote:
> If you're referring to me (I mentioned a 144G CVS repo), then let me
> clarify a couple of things:
> [...]
> To sum it up, sparse cloning would not be important to me.
I was referring to you, so thanks for the clarification.
-Peff
^ permalink raw reply
* [StGit PATCH 0/3] Fix uncommit with top != head
From: Karl Hasselström @ 2008-07-25 0:52 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Erik Sandberg
See http://gna.org/bugs/?12043
---
Karl Hasselström (3):
Make sure that stg uncommit doesn't touch the branch head
stg uncommit should never touch the branch head
Test for exit code with command_error()
stgit/commands/uncommit.py | 2 +-
stgit/lib/transaction.py | 19 ++++++++++---------
t/t1300-uncommit.sh | 13 ++++++++++++-
t/t1303-commit.sh | 20 ++++++++++++++++++++
4 files changed, 43 insertions(+), 11 deletions(-)
create mode 100755 t/t1303-commit.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH 1/3] Test for exit code with command_error()
From: Karl Hasselström @ 2008-07-25 0:52 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Erik Sandberg
In-Reply-To: <20080725005154.13006.8908.stgit@yoghurt>
The helper function was made for occasions such as this, so use it.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1300-uncommit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t1300-uncommit.sh b/t/t1300-uncommit.sh
index a906d13..a657ead 100755
--- a/t/t1300-uncommit.sh
+++ b/t/t1300-uncommit.sh
@@ -79,7 +79,7 @@ test_expect_success \
'
test_expect_success 'Uncommit a commit with not precisely one parent' '
- stg uncommit -n 5 ; [ $? = 2 ] &&
+ command_error stg uncommit -n 5 &&
[ "$(echo $(stg series))" = "" ]
'
^ permalink raw reply related
* [StGit PATCH 2/3] stg uncommit should never touch the branch head
From: Karl Hasselström @ 2008-07-25 0:53 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Erik Sandberg
In-Reply-To: <20080725005154.13006.8908.stgit@yoghurt>
However, currently, it will set head to top, potentially losing data
(which can always be recovered via the reflog, but still). See
https://gna.org/bugs/index.php?12043. Add a test to demonstrate the
bad behavior. (Bug discovered by Erik Sandberg
<mandolaerik@gmail.com>.)
stg commit, on the other hand, should refuse to run if top != head,
since the committed patches might otherwise be lost. Add a test to
demonstrate that this is the case.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1300-uncommit.sh | 11 +++++++++++
t/t1303-commit.sh | 20 ++++++++++++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
create mode 100755 t/t1303-commit.sh
diff --git a/t/t1300-uncommit.sh b/t/t1300-uncommit.sh
index a657ead..d01eaaa 100755
--- a/t/t1300-uncommit.sh
+++ b/t/t1300-uncommit.sh
@@ -83,4 +83,15 @@ test_expect_success 'Uncommit a commit with not precisely one parent' '
[ "$(echo $(stg series))" = "" ]
'
+# stg uncommit should work even when top != head, and should not touch
+# the head.
+test_expect_failure 'Uncommit when top != head' '
+ stg new -m foo &&
+ git reset --hard HEAD^ &&
+ h=$(git rev-parse HEAD)
+ stg uncommit bar &&
+ test $(git rev-parse HEAD) = $h &&
+ test "$(echo $(stg series))" = "+ bar > foo"
+'
+
test_done
diff --git a/t/t1303-commit.sh b/t/t1303-commit.sh
new file mode 100755
index 0000000..d53b9f2
--- /dev/null
+++ b/t/t1303-commit.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+test_description='Test stg commit'
+. ./test-lib.sh
+
+test_expect_success 'Initialize the StGIT repository' '
+ stg init
+'
+
+# stg commit with top != head should not succeed, since the committed
+# patches are poptentially lost.
+test_expect_success 'Commit when top != head (should fail)' '
+ stg new -m foo &&
+ git reset --hard HEAD^ &&
+ h=$(git rev-parse HEAD)
+ command_error stg commit &&
+ test $(git rev-parse HEAD) = $h &&
+ test "$(echo $(stg series))" = "> foo"
+'
+
+test_done
^ permalink raw reply related
* [StGit PATCH 3/3] Make sure that stg uncommit doesn't touch the branch head
From: Karl Hasselström @ 2008-07-25 0:53 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Erik Sandberg
In-Reply-To: <20080725005154.13006.8908.stgit@yoghurt>
Even if top != head. It used to set head to top; but with this patch,
it doesn't anymore.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/uncommit.py | 2 +-
stgit/lib/transaction.py | 19 ++++++++++---------
t/t1300-uncommit.sh | 2 +-
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
index eb39fcc..9d2dba9 100644
--- a/stgit/commands/uncommit.py
+++ b/stgit/commands/uncommit.py
@@ -136,5 +136,5 @@ def func(parser, options, args):
for commit, pn in zip(commits, patchnames):
trans.patches[pn] = commit
trans.applied = list(reversed(patchnames)) + trans.applied
- trans.run()
+ trans.run(set_head = False)
out.done()
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index e47997e..23321c7 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -138,21 +138,22 @@ class StackTransaction(object):
# The only state we need to restore is index+worktree.
if iw:
self.__checkout(self.__stack.head.data.tree, iw)
- def run(self, iw = None):
+ def run(self, iw = None, set_head = True):
"""Execute the transaction. Will either succeed, or fail (with an
exception) and do nothing."""
self.__check_consistency()
new_head = self.__head
# Set branch head.
- if iw:
- try:
- self.__checkout(new_head.data.tree, iw)
- except git.CheckoutException:
- # We have to abort the transaction.
- self.abort(iw)
- self.__abort()
- self.__stack.set_head(new_head, self.__msg)
+ if set_head:
+ if iw:
+ try:
+ self.__checkout(new_head.data.tree, iw)
+ except git.CheckoutException:
+ # We have to abort the transaction.
+ self.abort(iw)
+ self.__abort()
+ self.__stack.set_head(new_head, self.__msg)
if self.__error:
out.error(self.__error)
diff --git a/t/t1300-uncommit.sh b/t/t1300-uncommit.sh
index d01eaaa..4a955f6 100755
--- a/t/t1300-uncommit.sh
+++ b/t/t1300-uncommit.sh
@@ -85,7 +85,7 @@ test_expect_success 'Uncommit a commit with not precisely one parent' '
# stg uncommit should work even when top != head, and should not touch
# the head.
-test_expect_failure 'Uncommit when top != head' '
+test_expect_success 'Uncommit when top != head' '
stg new -m foo &&
git reset --hard HEAD^ &&
h=$(git rev-parse HEAD)
^ permalink raw reply related
* Re: git newbie - cloning / check out help
From: Donald Brady @ 2008-07-24 23:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080724231531.GS32184@machine.or.cz>
Hi Peter.
I got it working now thanks to your pointer.
Donald
On Jul 24, 2008, at 4:15 PM, Petr Baudis wrote:
> Hi,
>
> On Thu, Jul 24, 2008 at 09:24:34PM +0000, Donald Brady wrote:
>> I am just ramping up on git and have the following scenario / issue:
>>
>> I have a git repository on server A.
>>
>> I clone it onto my machine B.
>>
>> In my local copy/repository on machine B I clone a repository on
>> some
>> third party server C.
>>
>> I commit my changes into B and push them to A.
>>
>> Now if I clone my repository from Server A onto my local machine
>> in a different location I see all the source as normal but only the
>> top
>> level directory of C. Any source under that is not present.
>>
>> What is the magic git incantation to make sure that I check out
>> not only the code from my repository but any repositories that
>> are cloned into it (recursive clone?)
>
> we call this functionality "submodules" and the quickstart howto is:
>
> You have git repository on A
>
> You clone it onto your machine B
>
> git submodule add url directoryC
>
> You commit your changes into B and push them to A
>
> You do another clone of A and then within the clone
>
> git submodule update --init
>
> For further details, see git-submodule(1).
>
> --
> Petr "Pasky" Baudis
> As in certain cults it is possible to kill a process if you know
> its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* StGit: kha/{stable,safe,experimental} updated
From: Karl Hasselström @ 2008-07-25 1:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Samuel Tardieu
The big update since last time is support (in kha/experimental) for
hidden patches in the new-infrastructure commands and stack log.
Unless more problems are uncovered, I'll soon move all patches in
experimental to safe (which means I'll be recommending that Catalin
merge them).
-+-
The following changes since commit a6c4be12abcf0906a63de8a72c887c360f89ea82:
Karl Hasselström (1):
Don't allow extra diff options with "stg status"
are available in the git repository at:
git://repo.or.cz/stgit/kha.git stable
Daniel White (1):
Fixed default install location
Karl Hasselström (1):
Test that we can add a new file to a non-topmost patch with refresh -p
Miklos Vajna (2):
setup.py: don't try to import stgit.run before the python version check
setup.py: fix error message when running with python-2.3
setup.cfg | 2 +-
setup.py | 4 ++--
t/t2701-refresh-p.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+), 3 deletions(-)
create mode 100755 t/t2701-refresh-p.sh
-+-
The following changes since commit 2e37b61d886ef21200007b57f496aaf182f42705:
Karl Hasselström (1):
Test for "stg edit"
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
Daniel White (1):
Fixed default install location
Karl Hasselström (19):
Test that we can add a new file to a non-topmost patch with refresh -p
Merge branch 'stable'
Test for exit code with command_error()
stg uncommit should never touch the branch head
Make sure that stg uncommit doesn't touch the branch head
Fix uncommit status message
Discard stderr output from git apply if the caller wants
Do simple in-index merge with diff+apply instead of read-tree
Reuse the same temp index in a transaction
Library functions for tree and blob manipulation
Teach stgit.lib.transaction about hidden patches
Test operations on hidden patches
stg goto: Handle hidden patches more gracefully
Add utility function for reordering patches
Add some performance testing scripts
Log subprocess activity to a file
Show full command in subprocess profiling
Log subprocess calls during performance testing
Global performance logging
Miklos Vajna (2):
setup.py: don't try to import stgit.run before the python version check
setup.py: fix error message when running with python-2.3
perf/.gitignore | 2 +
perf/create_synthetic_repo.py | 61 +++++++++
perf/find_patchbomb.py | 31 +++++
perf/perftest.py | 96 ++++++++++++++
perf/setup.sh | 52 ++++++++
setup.cfg | 2 +-
setup.py | 4 +-
stgit/commands/edit.py | 2 +-
stgit/commands/goto.py | 2 +
stgit/commands/uncommit.py | 6 +-
stgit/lib/git.py | 274 +++++++++++++++++++++++++++++++++--------
stgit/lib/transaction.py | 61 +++++++--
stgit/main.py | 10 ++-
stgit/out.py | 11 +-
stgit/run.py | 59 +++++++--
t/t1206-push-hidden.sh | 28 ++++
t/t1300-uncommit.sh | 13 ++-
t/t1303-commit.sh | 20 +++
t/t1701-goto-hidden.sh | 23 ++++
t/t2701-refresh-p.sh | 46 +++++++
t/t2900-rename.sh | 7 +
t/t3300-edit.sh | 16 ++-
22 files changed, 731 insertions(+), 95 deletions(-)
create mode 100644 perf/.gitignore
create mode 100644 perf/create_synthetic_repo.py
create mode 100644 perf/find_patchbomb.py
create mode 100644 perf/perftest.py
create mode 100644 perf/setup.sh
create mode 100755 t/t1206-push-hidden.sh
create mode 100755 t/t1303-commit.sh
create mode 100755 t/t1701-goto-hidden.sh
create mode 100755 t/t2701-refresh-p.sh
-+-
The following changes since commit 36a06e0194e013552499677e431e528ecb2faee9:
Karl Hasselström (1):
Global performance logging
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
Karl Hasselström (16):
Write to a stack log when stack is modified
New command: stg reset
Log conflicts separately
Log conflicts separately for all commands
Add a --hard flag to stg reset
Don't write a log entry if there were no changes
Move stack reset function to a shared location
New command: stg undo
New command: stg redo
Log and undo external modifications
Make "stg log" show stack log instead of patch log
Convert "stg refresh" to the new infrastructure
New refresh tests
Remove --undo flags from stg commands and docs
Refactor stgit.commands.edit
Implement "stg refresh --edit" again
Documentation/tutorial.txt | 4 +-
TODO | 2 -
stgit/commands/branch.py | 19 +-
stgit/commands/clone.py | 2 +-
stgit/commands/coalesce.py | 2 +-
stgit/commands/common.py | 18 ++-
stgit/commands/diff.py | 6 +-
stgit/commands/edit.py | 82 +------
stgit/commands/export.py | 2 +-
stgit/commands/files.py | 6 +-
stgit/commands/float.py | 2 +-
stgit/commands/fold.py | 2 +-
stgit/commands/goto.py | 3 +-
stgit/commands/hide.py | 2 +-
stgit/commands/id.py | 2 +-
stgit/commands/imprt.py | 4 +-
stgit/commands/log.py | 169 +++++----------
stgit/commands/mail.py | 8 +-
stgit/commands/new.py | 3 +-
stgit/commands/patches.py | 2 +-
stgit/commands/pick.py | 2 +-
stgit/commands/pop.py | 4 +-
stgit/commands/pull.py | 2 +-
stgit/commands/push.py | 31 +--
stgit/commands/rebase.py | 4 +-
stgit/commands/redo.py | 52 ++++
stgit/commands/refresh.py | 338 ++++++++++++++++++---------
stgit/commands/rename.py | 2 +-
stgit/commands/repair.py | 11 +-
stgit/commands/reset.py | 57 +++++
stgit/commands/resolved.py | 2 +-
stgit/commands/show.py | 2 +-
stgit/commands/sink.py | 2 +-
stgit/commands/status.py | 3 +-
stgit/commands/sync.py | 26 +--
stgit/commands/undo.py | 49 ++++
stgit/commands/unhide.py | 2 +-
stgit/git.py | 4 -
stgit/lib/edit.py | 99 ++++++++
stgit/lib/git.py | 74 ++++++-
stgit/lib/log.py | 524 ++++++++++++++++++++++++++++++++++++++++++
stgit/lib/stack.py | 25 ++
stgit/lib/transaction.py | 125 +++++++----
stgit/main.py | 8 +
stgit/stack.py | 45 +----
stgit/utils.py | 18 +-
t/t1200-push-modified.sh | 2 +-
t/t1201-pull-trailing.sh | 2 +-
t/t1202-push-undo.sh | 8 +-
t/t1400-patch-history.sh | 103 --------
t/t2300-refresh-subdir.sh | 29 +++-
t/t2701-refresh-p.sh | 2 +-
t/t3100-reset.sh | 160 +++++++++++++
t/t3101-reset-hard.sh | 56 +++++
t/t3102-undo.sh | 86 +++++++
t/t3103-undo-hard.sh | 56 +++++
t/t3104-redo.sh | 122 ++++++++++
t/t3105-undo-external-mod.sh | 68 ++++++
t/t3300-edit.sh | 4 +-
59 files changed, 1936 insertions(+), 613 deletions(-)
create mode 100644 stgit/commands/redo.py
create mode 100644 stgit/commands/reset.py
create mode 100644 stgit/commands/undo.py
create mode 100644 stgit/lib/edit.py
create mode 100644 stgit/lib/log.py
delete mode 100755 t/t1400-patch-history.sh
create mode 100755 t/t3100-reset.sh
create mode 100755 t/t3101-reset-hard.sh
create mode 100755 t/t3102-undo.sh
create mode 100755 t/t3103-undo-hard.sh
create mode 100755 t/t3104-redo.sh
create mode 100755 t/t3105-undo-external-mod.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Linus Torvalds @ 2008-07-25 2:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20080723191647.GF5283@blimp.local>
On Wed, 23 Jul 2008, Alex Riesen wrote:
>
> It is not that it is broken. We just don't need it, because the st_mode
> is not used, and the rest of inode information is not used anyway.
That is NOT why git checks the ctime.
Git checks the ctime not because it cares about the inode state being
modified per se: since it can see that _directly_ - so why should it care
about inode state like st_mode?
No, git checks ctime because it in general tries to make it VERY VERY hard
for people to try to "fake out" git and replace files from underneath it
without git noticing.
It's much easier and much more common for tools to restore 'mtime' when
they do some operation on a file than it is for them to restore 'ctime'.
For example, if you rsync files between two hosts, the '-t' flag will make
rsync try to keep the mtimes in sync (and it's part of '-a', which is the
common form that you'd use for rsync). So if you only look at mtime and
size, you often miss the fact that the file has actually been messed with!
Looking at ctime gets around a number of those things. Of course, it can
cause git to be _too_ eager in thinking that a file is modified, and an
example of that is the insane indexing that 'beagle' does, which actually
modifies the files by adding inode extended attributes to them and thus
changes ctime due to the indexing. But in general it's a lot better to be
too careful than to miss the fact that somebody changed the file.
Linus
^ permalink raw reply
* Re: Stitching together two split segments from svn
From: Liam Healy @ 2008-07-25 2:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ljzqvo6i.fsf@localhost.localdomain>
Jakub,
Thanks for the advice -- this did exactly what I wanted.
For anyone else wanting to do this: one thing that threw me for a
while was that .git/info/grafts does not accept an abbreviated SHA,
the full 40 hex digits is needed. I would see "bad graft data" from
gitk with no other explanation. There is very little documentation
that I could find on the grafts file; the best I could find was in the
man page for git-filter branch,
http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html.
Liam
On Thu, Jul 24, 2008 at 7:48 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Liam Healy" <lnp@healy.washington.dc.us> writes:
>
>> I have a project whose history is stored in two separate svn
>> repositories. The first repository I kept privately during initial
>> development, the second started when I posted it publicly and does not
>> have the history of the first. I am trying to reunite them under git.
>> The development of the first was linear, so after using git svn, the
>> history looks like:
>>
>> a - b - ... - c - d = HEAD (old repository)
>>
>> and the second has one branch "ffa":
>>
>> (new repository)
>> T - d - e - ... - f - g - h - ... - j master
>> \
>> k - l - .... - m ffa
>>
>> Note that T is the "trunk" initial commit on the svn repo that has no
>> files. The second commit d is identical to the HEAD of old, as
>> verified by git diff.
>> However, when I remote add these two into a single repository, they
>> show up as two detached chains, with no connection between them. I
>> thought git rebase would reconnect them. However, when I do that on
>> each branch (master and ffa), I get the following:
>>
>> a - b - ... - c - d - e - ... - f - g - h - ... - j master
>> \
>> e - ... -f - g - k - l - .... - m ffa
>>
>> instead of what I would like
>>
>> a - b - ... - c - d - e - ... - f - g - h - ... - j master
>> \
>> k - l - .... - m ffa
>>
>> That is to say, those commits from the new repository that have a
>> common history for the two branches are duplicated. The commits are
>> listed separately and have different SHA IDs, but they are clearly the
>> same commits (same comments, same svn version number). Is there any
>> way to do what I want? Really, all I want to do is change the parent
>> of "e" to be the HEAD of the old repository.
>
> If this is initial import, and not published anywhere, the simplest (I
> think) solution would be to use grafts file (.git/info/grafts) to
> change parent of 'k' from 'g' in ffa to 'g' in master, by adding the
> line with:
>
> <sha1 of 'k'> <sha1 of 'g' on master>
>
> to .git/info/grafts. Then examine history if everything is now all
> right (for example using gitk), and if everything is O.K. run
> git-filter-branch.
>
> See documentation for details.
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
^ permalink raw reply
* [PATCH 1/2 resend] bisect: test merge base if good rev is not an ancestor of bad rev
From: Christian Couder @ 2008-07-25 3:34 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: Michael Haggerty, Jeff King, git
Before this patch, "git bisect", when it was given some good revs that
are not ancestor of the bad rev, didn't check if the merge bases were
good. "git bisect" just supposed that the user knew what he was doing,
and that, when he said the revs were good, he knew that it meant that
all the revs in the history leading to the good revs were also
considered good.
But in pratice, the user may not know that a good rev is not an
ancestor of the bad rev, or he may not know/remember that all revs
leading to the good rev will be considered good. So he may give a good
rev that is a sibling, instead of an ancestor, of the bad rev, when in
fact there can be one rev becoming good in the branch of the good rev
(because the bug was already fixed there for example) instead of one
rev becoming bad in the branch of the bad rev.
For example, if there is the following history:
A-B-C-D
\E-F
and we launch "git bisect start D F" then only C and D would have been
considered as possible first bad commit before this patch. This may be
wrong because A, B and E may be bad too if the bug exists everywhere
except in F that fixes it.
The purpose of this patch is to detect when "git bisect" is passed
some good revs that are not ancestor of the bad rev, and then to first
ask the user to test the merge bases between the good and bad revs.
If the merge bases are good then all is fine, we can continue
bisecting. Otherwise, if one merge base is bad, it means that the
assumption that all revs leading to the good one are good too is
wrong and we error out. In the case where one merge base is skipped we
issue a warning and then continue bisecting anyway.
These checks will also catch the case where good and bad have been
mistaken. This means that we can remove the check that was done latter
on the output of "git rev-list --bisect-vars".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 134 +++++++++++++++++++++++++++++++++++--------
t/t6030-bisect-porcelain.sh | 90 +++++++++++++++++++++++++++++
2 files changed, 199 insertions(+), 25 deletions(-)
This is a resend series with the following changes since the previous
series:
- "for ...; do" has been replaced with "for" and "do" on 2 different
lines (in patch 1/2)
- a line with "unset GIT_TRACE" has been added to "t/t6030" (in patch
2/2)
diff --git a/git-bisect.sh b/git-bisect.sh
index 3cac20d..dfe36e5 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -242,33 +242,18 @@ bisect_auto_next() {
bisect_next_check && bisect_next || :
}
-eval_rev_list() {
- _eval="$1"
-
- eval $_eval
- res=$?
-
- if [ $res -ne 0 ]; then
- echo >&2 "'git rev-list --bisect-vars' failed:"
- echo >&2 "maybe you mistake good and bad revs?"
- exit $res
- fi
-
- return $res
-}
-
filter_skipped() {
_eval="$1"
_skip="$2"
if [ -z "$_skip" ]; then
- eval_rev_list "$_eval"
+ eval "$_eval"
return
fi
# Let's parse the output of:
# "git rev-list --bisect-vars --bisect-all ..."
- eval_rev_list "$_eval" | while read hash line
+ eval "$_eval" | while read hash line
do
case "$VARS,$FOUND,$TRIED,$hash" in
# We display some vars.
@@ -331,20 +316,120 @@ exit_if_skipped_commits () {
fi
}
+checkout() {
+ _rev="$1"
+ _msg="$2"
+ echo "Bisecting: $_msg"
+ git checkout -q "$_rev" || exit
+ git show-branch "$_rev"
+}
+
+is_among() {
+ _rev="$1"
+ _list="$2"
+ case "$_list" in *$_rev*) return 0 ;; esac
+ return 1
+}
+
+is_merge_base_ok() {
+ grep "^$1 $2 ok$" "$GIT_DIR/BISECT_MERGE_BASES" >/dev/null 2>&1
+}
+
+mark_merge_base_ok() {
+ echo "$1 $2 ok" >> "$GIT_DIR/BISECT_MERGE_BASES"
+}
+
+is_testing_merge_base() {
+ grep "^testing $1$" "$GIT_DIR/BISECT_MERGE_BASES" >/dev/null 2>&1
+}
+
+mark_testing_merge_base() {
+ echo "testing $1" >> "$GIT_DIR/BISECT_MERGE_BASES"
+}
+
+handle_bad_merge_base() {
+ _badmb="$1"
+ _g="$2"
+ if is_testing_merge_base "$_badmb"; then
+ cat >&2 <<EOF
+The merge base $_badmb is bad.
+This means the bug has been fixed between $_badmb and $_g.
+EOF
+ exit 3
+ else
+ cat >&2 <<EOF
+Some good revs are not ancestor of the bad rev.
+git bisect cannot work properly in this case.
+Maybe you mistake good and bad revs?
+EOF
+ exit 1
+ fi
+}
+
+handle_skipped_merge_base() {
+ _bad="$1"
+ _g="$2"
+ _mb="$3"
+ cat >&2 <<EOF
+Warning: the merge base between $_bad and $_g must be skipped.
+So we cannot be sure the first bad commit is between $_mb and $_bad.
+We continue anyway.
+EOF
+}
+
+check_merge_bases() {
+ _bad="$1"
+ _good="$2"
+ _skip="$3"
+ for _g in $_good
+ do
+ is_merge_base_ok "$_bad" "$_g" && continue
+ for _mb in $(git merge-base --all $_g $_bad)
+ do
+ if test "$_mb" = "$_g" || is_among "$_mb" "$_good"; then
+ continue
+ elif test "$_mb" = "$_bad"; then
+ handle_bad_merge_base "$_bad" "$_g"
+ elif is_among "$_mb" "$_skip"; then
+ handle_skipped_merge_base "$_bad" "$_g" "_mb"
+ else
+ mark_testing_merge_base "$_mb"
+ checkout "$_mb" "a merge base must be tested"
+ checkout_done=1
+ return
+ fi
+ done
+ mark_merge_base_ok "$_bad" "$_g"
+ done
+}
+
+check_good_are_ancestors_of_bad() {
+ _bad="$1"
+ _good=$(echo $2 | sed -e 's/\^//g')
+ _skip="$3"
+ _side=$(git rev-list $_good ^$_bad)
+ test -n "$_side" && check_merge_bases "$_bad" "$_good" "$_skip"
+}
+
bisect_next() {
case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
+ # Get bad, good and skipped revs
+ bad=$(git rev-parse --verify refs/bisect/bad) &&
+ good=$(git for-each-ref --format='^%(objectname)' \
+ "refs/bisect/good-*" | tr '\012' ' ') &&
skip=$(git for-each-ref --format='%(objectname)' \
- "refs/bisect/skip-*" | tr '\012' ' ') || exit
+ "refs/bisect/skip-*" | tr '\012' ' ') &&
+ # Maybe some merge bases must be tested first
+ check_good_are_ancestors_of_bad "$bad" "$good" "$skip" || exit
+ test "$checkout_done" -eq "1" && checkout_done='' && return
+
+ # Get bisection information
BISECT_OPT=''
test -n "$skip" && BISECT_OPT='--bisect-all'
-
- bad=$(git rev-parse --verify refs/bisect/bad) &&
- good=$(git for-each-ref --format='^%(objectname)' \
- "refs/bisect/good-*" | tr '\012' ' ') &&
eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
eval=$(filter_skipped "$eval" "$skip") &&
@@ -365,9 +450,7 @@ bisect_next() {
# commit is also a "skip" commit (see above).
exit_if_skipped_commits "$bisect_rev"
- echo "Bisecting: $bisect_nr revisions left to test after this"
- git checkout -q "$bisect_rev" || exit
- git show-branch "$bisect_rev"
+ checkout "$bisect_rev" "$bisect_nr revisions left to test after this"
}
bisect_visualize() {
@@ -414,6 +497,7 @@ bisect_clean_state() {
do
git update-ref -d $ref $hash || exit
done
+ rm -f "$GIT_DIR/BISECT_MERGE_BASES" &&
rm -f "$GIT_DIR/BISECT_LOG" &&
rm -f "$GIT_DIR/BISECT_NAMES" &&
rm -f "$GIT_DIR/BISECT_RUN" &&
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 0626544..503229b 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -350,6 +350,96 @@ test_expect_success 'bisect does not create a "bisect" branch' '
git branch -D bisect
'
+# This creates a "side" branch to test "siblings" cases.
+#
+# H1-H2-H3-H4-H5-H6-H7 <--other
+# \
+# S5-S6-S7 <--side
+#
+test_expect_success 'side branch creation' '
+ git bisect reset &&
+ git checkout -b side $HASH4 &&
+ add_line_into_file "5(side): first line on a side branch" hello2 &&
+ SIDE_HASH5=$(git rev-parse --verify HEAD) &&
+ add_line_into_file "6(side): second line on a side branch" hello2 &&
+ SIDE_HASH6=$(git rev-parse --verify HEAD) &&
+ add_line_into_file "7(side): third line on a side branch" hello2 &&
+ SIDE_HASH7=$(git rev-parse --verify HEAD)
+'
+
+test_expect_success 'good merge base when good and bad are siblings' '
+ git bisect start "$HASH7" "$SIDE_HASH7" > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect good > my_bisect_log.txt &&
+ test_must_fail grep "merge base must be tested" my_bisect_log.txt &&
+ grep $HASH6 my_bisect_log.txt &&
+ git bisect reset
+'
+test_expect_success 'skipped merge base when good and bad are siblings' '
+ git bisect start "$SIDE_HASH7" "$HASH7" > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect skip > my_bisect_log.txt 2>&1 &&
+ grep "Warning" my_bisect_log.txt &&
+ grep $SIDE_HASH6 my_bisect_log.txt &&
+ git bisect reset
+'
+
+test_expect_success 'bad merge base when good and bad are siblings' '
+ git bisect start "$HASH7" HEAD > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ test_must_fail git bisect bad > my_bisect_log.txt 2>&1 &&
+ grep "merge base $HASH4 is bad" my_bisect_log.txt &&
+ grep "fixed between $HASH4 and $SIDE_HASH7" my_bisect_log.txt &&
+ git bisect reset
+'
+
+# This creates a few more commits (A and B) to test "siblings" cases
+# when a good and a bad rev have many merge bases.
+#
+# We should have the following:
+#
+# H1-H2-H3-H4-H5-H6-H7
+# \ \ \
+# S5-A \
+# \ \
+# S6-S7----B
+#
+# And there A and B have 2 merge bases (S5 and H5) that should be
+# reported by "git merge-base --all A B".
+#
+test_expect_success 'many merge bases creation' '
+ git checkout "$SIDE_HASH5" &&
+ git merge -m "merge HASH5 and SIDE_HASH5" "$HASH5" &&
+ A_HASH=$(git rev-parse --verify HEAD) &&
+ git checkout side &&
+ git merge -m "merge HASH7 and SIDE_HASH7" "$HASH7" &&
+ B_HASH=$(git rev-parse --verify HEAD) &&
+ git merge-base --all "$A_HASH" "$B_HASH" > merge_bases.txt &&
+ test $(wc -l < merge_bases.txt) = "2" &&
+ grep "$HASH5" merge_bases.txt &&
+ grep "$SIDE_HASH5" merge_bases.txt
+'
+
+test_expect_success 'good merge bases when good and bad are siblings' '
+ git bisect start "$B_HASH" "$A_HASH" > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ git bisect good > my_bisect_log2.txt &&
+ grep "merge base must be tested" my_bisect_log2.txt &&
+ {
+ {
+ grep "$SIDE_HASH5" my_bisect_log.txt &&
+ grep "$HASH5" my_bisect_log2.txt
+ } || {
+ grep "$SIDE_HASH5" my_bisect_log2.txt &&
+ grep "$HASH5" my_bisect_log.txt
+ }
+ } &&
+ git bisect reset
+'
+
#
#
test_done
--
1.6.0.rc0.2.gf038
^ permalink raw reply related
* [PATCH 2/2 resend] bisect: only check merge bases when needed
From: Christian Couder @ 2008-07-25 3:36 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: Michael Haggerty, Jeff King, git
When one good revision is not an ancestor of the bad revision, the
merge bases between the good and the bad revision should be checked
to make sure that they are also good revisions.
Some previous patches take care of that, but they may check the
merge bases more often than really needed. In fact the previous
patches did not try to optimize this as much as possible because
it is not so simple. So this is the purpose of this patch.
One may think that when all the merge bases have been checked then
we can save a flag, so that we don't need to check the merge bases
again during the bisect process.
The problem is that the user may choose to checkout and test
something completely different from what the bisect process
suggested. In this case we have to check the merge bases again,
because there may be new merge bases relevant to the bisect
process.
That's why, in this patch, when we detect that the user tested
something else than what the bisect process suggested, we remove
the flag that says that we don't need to check the merge bases
again.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 47 +++++++++++++++++++++++++++++++-----------
t/t6030-bisect-porcelain.sh | 24 ++++++++++++++++++++++
2 files changed, 58 insertions(+), 13 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index dfe36e5..7093dd3 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -172,6 +172,25 @@ bisect_write() {
test -n "$nolog" || echo "git bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
+is_expected_rev() {
+ test -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
+ test "$1" = $(cat "$GIT_DIR/BISECT_EXPECTED_REV")
+}
+
+mark_expected_rev() {
+ echo "$1" > "$GIT_DIR/BISECT_EXPECTED_REV"
+}
+
+check_expected_revs() {
+ for _rev in "$@"; do
+ if ! is_expected_rev "$_rev"; then
+ rm -f "$GIT_DIR/BISECT_ANCESTORS_OK"
+ rm -f "$GIT_DIR/BISECT_EXPECTED_REV"
+ return
+ fi
+ done
+}
+
bisect_state() {
bisect_autostart
state=$1
@@ -181,7 +200,8 @@ bisect_state() {
1,bad|1,good|1,skip)
rev=$(git rev-parse --verify HEAD) ||
die "Bad rev input: HEAD"
- bisect_write "$state" "$rev" ;;
+ bisect_write "$state" "$rev"
+ check_expected_revs "$rev" ;;
2,bad|*,good|*,skip)
shift
eval=''
@@ -191,7 +211,8 @@ bisect_state() {
die "Bad rev input: $rev"
eval="$eval bisect_write '$state' '$sha'; "
done
- eval "$eval" ;;
+ eval "$eval"
+ check_expected_revs "$@" ;;
*,bad)
die "'git bisect bad' can take only one argument." ;;
*)
@@ -320,6 +341,7 @@ checkout() {
_rev="$1"
_msg="$2"
echo "Bisecting: $_msg"
+ mark_expected_rev "$_rev"
git checkout -q "$_rev" || exit
git show-branch "$_rev"
}
@@ -339,18 +361,10 @@ mark_merge_base_ok() {
echo "$1 $2 ok" >> "$GIT_DIR/BISECT_MERGE_BASES"
}
-is_testing_merge_base() {
- grep "^testing $1$" "$GIT_DIR/BISECT_MERGE_BASES" >/dev/null 2>&1
-}
-
-mark_testing_merge_base() {
- echo "testing $1" >> "$GIT_DIR/BISECT_MERGE_BASES"
-}
-
handle_bad_merge_base() {
_badmb="$1"
_g="$2"
- if is_testing_merge_base "$_badmb"; then
+ if is_expected_rev "$_badmb"; then
cat >&2 <<EOF
The merge base $_badmb is bad.
This means the bug has been fixed between $_badmb and $_g.
@@ -393,7 +407,6 @@ check_merge_bases() {
elif is_among "$_mb" "$_skip"; then
handle_skipped_merge_base "$_bad" "$_g" "_mb"
else
- mark_testing_merge_base "$_mb"
checkout "$_mb" "a merge base must be tested"
checkout_done=1
return
@@ -404,11 +417,17 @@ check_merge_bases() {
}
check_good_are_ancestors_of_bad() {
+ test -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
+ return
_bad="$1"
_good=$(echo $2 | sed -e 's/\^//g')
_skip="$3"
_side=$(git rev-list $_good ^$_bad)
- test -n "$_side" && check_merge_bases "$_bad" "$_good" "$_skip"
+ if test -n "$_side"; then
+ check_merge_bases "$_bad" "$_good" "$_skip" || return
+ test "$checkout_done" -eq "1" && return
+ fi
+ : > "$GIT_DIR/BISECT_ANCESTORS_OK"
}
bisect_next() {
@@ -498,6 +517,8 @@ bisect_clean_state() {
git update-ref -d $ref $hash || exit
done
rm -f "$GIT_DIR/BISECT_MERGE_BASES" &&
+ rm -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
+ rm -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
rm -f "$GIT_DIR/BISECT_LOG" &&
rm -f "$GIT_DIR/BISECT_NAMES" &&
rm -f "$GIT_DIR/BISECT_RUN" &&
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 503229b..04963b9 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -440,6 +440,30 @@ test_expect_success 'good merge bases when good and bad are siblings' '
git bisect reset
'
+check_trace() {
+ grep "$1" "$GIT_TRACE" | grep "\^$2" | grep "$3" >/dev/null
+}
+
+test_expect_success 'optimized merge base checks' '
+ GIT_TRACE="$(pwd)/trace.log" &&
+ export GIT_TRACE &&
+ git bisect start "$HASH7" "$SIDE_HASH7" > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ grep "$HASH4" my_bisect_log.txt &&
+ check_trace "rev-list" "$HASH7" "$SIDE_HASH7" &&
+ git bisect good > my_bisect_log2.txt &&
+ test -f ".git/BISECT_ANCESTORS_OK" &&
+ test "$HASH6" = $(git rev-parse --verify HEAD) &&
+ : > "$GIT_TRACE" &&
+ git bisect bad > my_bisect_log3.txt &&
+ test_must_fail check_trace "rev-list" "$HASH6" "$SIDE_HASH7" &&
+ git bisect good "$A_HASH" > my_bisect_log4.txt &&
+ grep "merge base must be tested" my_bisect_log4.txt &&
+ test_must_fail test -f ".git/BISECT_ANCESTORS_OK" &&
+ check_trace "rev-list" "$HASH6" "$A_HASH" &&
+ unset GIT_TRACE
+'
+
#
#
test_done
--
1.6.0.rc0.2.gf038
^ permalink raw reply related
* Re: [PATCH 9/9] Windows: Do not compile git-shell
From: Steffen Prohaska @ 2008-07-25 4:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Sixt
In-Reply-To: <1216667998-8879-10-git-send-email-johannes.sixt@telecom.at>
Junio,
Do you plan to apply this patch anytime soon? Currently,
building on MSYS fails when it comes to compiling git-shell.
I am waiting for this patch to either pop up in your or
Hannes' master. I need this patch before I can push new
4msysgit branches (next, devel). Should I apply it directly
in 4msysgit?
This patch is not related to the rest of the exec-path series.
Steffen
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Junio C Hamano @ 2008-07-25 4:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <20080724172912.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting "Peter Valdemar Mrch (Lists)" <4ux6as402@sneakemail.com>:
>
>> The '-trailing-space' syntax to disable the trailing-space setting is
>> not obvious and not documented as far as I can see. I would have
>> assumed a value of '' would disable it.
>>
>> Is there a documentation bug here? If so, I suggest this patch. I
>> didn't find anywhere else where the '-setting' syntax was used to
>> disable something.
>
> Doesn't gitattributes(5) describe the overall syntax in detail?
Yes, but as Peter says in his reply to you, it only talks about [-!]name
syntax to force the variable to unset (with '-' prefix) and to revert the
variable to the unspecified state (with '!' prefix).
Various "values" given to the whitespace attribute actually act as if they
are sub-variables and obey the similar "[-]name" rule, but (1) that is
left unsaid, and (2) in that context '!' does not make sense so only '-'
has any meaning. We would certainly need to clarify that.
So I think Peter's patch is going in the right direction.
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Junio C Hamano @ 2008-07-25 4:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200807242124.14583.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Donnerstag, 24. Juli 2008, Junio C Hamano wrote:
>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>> > It also fixes 'make install' of git-gui as well (sigh!) by not exporting
>> > gitexecdir - assuming that Shawn applies the git-gui patch.
>>
>> Yeah, this seems to break the install quite badly without git-gui patch.
>
> If you squash this in, we don't need the git-gui patch.
Thanks.
I think this patch makes _more_ sense than the git-gui patch, actually.
Within the context of git.git project, we would want to force the
installation directory of git-gui portion to be consistent with the main
project.
> diff --git a/Makefile b/Makefile
> index aab23a2..904150e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1344,7 +1344,7 @@ install: all
> $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
> ifndef NO_TCLTK
> $(MAKE) -C gitk-git install
> - $(MAKE) -C git-gui install
> + $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' install
> endif
> ifneq (,$X)
> $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)),
> $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
However, I have to wonder if it is the right thing to do, like your patch
does, for "git --exec-path" to return "../libexec/git-core/" in a relative
form, without saying what it is relative to. Shouldn't we be showing the
full path after resolving that relative path to git executable?
^ permalink raw reply
* Re: [PATCH] index-pack: correctly initialize appended objects
From: Junio C Hamano @ 2008-07-25 5:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, spearce, git
In-Reply-To: <alpine.DEB.1.00.0807241821440.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> From: Björn Steinbrink <B.Steinbrink@gmx.de>
>
> When index-pack completes a thin pack it appends objects to the pack.
> Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
> resolving deltas) such an object can be pruned in case of memory
> pressure.
>
> To be able to re-read the object later, a few more fields have to be set.
>
> Noticed by Pierre Habouzit.
>
> Hopefully-signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> Hopefully-reviewed-and-signed-off-by: Nicolas Pitre <nico@cam.org>,
>
> --
> Nico could you have a quick look? (I would ask Shawn, but I know
> that he is pretty busy with real world issues.)
Reading get_data_from_pack(), it does rely on hdr_size, idx.offset and
idx.offset of the next entry to be set correctly. The function does not
seem to use type (which the patch is also setting) nor real_type (which
the patch does not set).
However, the code checks objects[nth].real_type all over the place in the
code. Doesn't the lack of real_type assignment in append_obj_to_pack()
affect them in any way?
> diff --git a/index-pack.c b/index-pack.c
> index ac20a46..33ba8ef 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -699,6 +699,9 @@ static struct object_entry *append_obj_to_pack(
> write_or_die(output_fd, header, n);
> obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
> obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
> + obj[0].hdr_size = n;
> + obj[0].type = type;
> + obj[0].size = size;
> obj[1].idx.offset = obj[0].idx.offset + n;
> obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0].idx.crc32);
^ permalink raw reply
* Re: [PATCH 2/2] git-svn: make use of svn auto-props optional
From: Eric Wong @ 2008-07-25 5:50 UTC (permalink / raw)
To: Brad King; +Cc: git
In-Reply-To: <4885024D.2070402@kitware.com>
Brad King <brad.king@kitware.com> wrote:
>
> In order to preserve existing default behavior, dcommit should use svn
> auto-props only if instructed to do so. This commit creates a config
> option 'svn.autoprops' to enable the behavior.
No need for this. auto-props is the correct and expected behavior for
users coming from the `svn' client.
There's no backwards compatibility issue, either, since this only
affects new commits that git-svn makes.
Thanks.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/2] git-svn: teach dcommit about svn auto-props
From: Eric Wong @ 2008-07-25 6:00 UTC (permalink / raw)
To: Brad King; +Cc: git
In-Reply-To: <4885024A.3050200@kitware.com>
Brad King <brad.king@kitware.com> wrote:
>
> Subversion repositories often require files to have properties such as
> svn:mime-type and svn:eol-style set when they are added. Users
> typically set these properties automatically using the SVN auto-props
> feature with 'svn add'. This commit teaches dcommit to look at the user
> SVN configuration and apply matching auto-props entries for files added
> by a diff as it is applied to the SVN remote. A later commit will make
> this feature optional.
>
> Signed-off-by: Brad King <brad.king@kitware.com>
Hi Brad,
I like this patch. Can we get an automated test of this functionality?
We can (and probably should) set $HOME for the test and ignore the
existing ~/.subversion/config of the user.
Also, some minor nitpicks on whitespace/formatting inline below.
Not sure if writing a new unit test will trigger that bug below for you.
It really shouldn't...
> ---
> This change honors the user's enable-auto-props svn config setting.
> The next patch will configure this at the git level and add the
> corresponding documentation.
>
> I've tested this by hand on an real SVN repo that checks for mime type.
> Unfortunately I'm unable to run the git-svn test suite because I get
> the error reported here:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486527
>
> (even without my changes).
I haven't had the chance to look at this. Can anybody else shed more
light on that bug? It's really strange that the tests won't run because
of it. Are you unable to run some git-svn tests or all of them?
<snip>
> +sub apply_autoprops {
> + my ($self, $file, $fbat) = @_;
> + my $conf_t = ${$self->{config}}{'config'};
> + no warnings 'once';
> + # Check [miscellany]/enable-auto-props in svn configuration.
> + if (SVN::_Core::svn_config_get_bool($conf_t,
> + $SVN::_Core::SVN_CONFIG_SECTION_MISCELLANY,
> + $SVN::_Core::SVN_CONFIG_OPTION_ENABLE_AUTO_PROPS,
Long lines here and below. I'd rather just align to the left (tabs are
assumed to be 8 characters wide on screen).
> + 0)) {
> + # Auto-props are enabled. Enumerate them to look for matches.
> + my $callback = sub {
> + $self->check_autoprop($_[0], $_[1], $file, $fbat);
> + };
> + SVN::_Core::svn_config_enumerate($conf_t,
> + $SVN::_Core::SVN_CONFIG_SECTION_AUTO_PROPS,
> + $callback);
> + }
> +}
> +
> sub A {
> my ($self, $m) = @_;
> my ($dir, $file) = split_path($m->{file_b});
> @@ -3535,6 +3581,7 @@ sub A {
> my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
> undef, -1);
> print "\tA\t$m->{file_b}\n" unless $::_q;
> + $self->apply_autoprops($file, $fbat);
Hard tabs are used for indentation.
Thanks!
--
Eric Wong
^ 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