* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-08 2:46 UTC (permalink / raw)
To: git
In-Reply-To: <7vlk0ffhw3.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be applied to the maintenance series have "maint-" in their
names.
It already is beginning to become clear what 1.6.0 will look like. What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements. Bigger changes will be:
* Port for MinGW.
* With the default Makefile settings, most of the programs will be
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH will still be supported in
1.6.0, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
* git-merge will be rewritten in C.
* default pack and idx versions will be updated as scheduled for some
time ago.
* GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
not different from GIT_CONFIG in a useful way, is removed.
----------------------------------------------------------------
[New Topics]
* jc/rebase-orig-head (Mon Jul 7 00:16:38 2008 -0700) 1 commit
+ Teach "am" and "rebase" to mark the original position with
ORIG_HEAD
* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
. Migrate git-am to use git-sequencer
. Add git-sequencer test suite (t3350)
. Add git-sequencer prototype documentation
. Add git-sequencer shell prototype
* js/pick-root (Fri Jul 4 16:19:52 2008 +0100) 1 commit
+ Allow cherry-picking root commits
* ab/bundle (Sat Jul 5 17:26:40 2008 -0400) 1 commit
+ Teach git-bundle to read revision arguments from stdin like git-
rev-list.
----------------------------------------------------------------
[Will merge to master soon]
* js/apply-root (Sun Jul 6 18:36:01 2008 -0700) 3 commits
+ git-apply --directory: make --root more similar to GNU diff
+ apply --root: thinkofix.
+ Teach "git apply" to prepend a prefix with "--root=<root>"
* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
+ Make default expiration period of reflog used for stash infinite
+ Per-ref reflog expiry configuration
As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.
* jk/pager-config (Thu Jul 3 07:46:57 2008 -0400) 1 commit
+ Allow per-command pager config
----------------------------------------------------------------
[Actively Cooking]
* sg/stash-k-i (Fri Jun 27 16:37:15 2008 +0200) 1 commit
+ stash: introduce 'stash save --keep-index' option
One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree. This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.
* am/stash-branch (Mon Jul 7 02:50:10 2008 +0530) 2 commits
+ Add a test for "git stash branch"
+ Implement "git stash branch <newbranch> <stash>"
Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.
* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
+ git-add--interactive: manual hunk editing mode
+ git-add--interactive: remove hunk coalescing
+ git-add--interactive: replace hunk recounting with apply --recount
Adds 'e/dit' action to interactive add command.
* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
+ branch -r -v: do not spit out garbage
+ stat_tracking_info(): clear object flags used during counting
+ git-branch -v: show the remote tracking statistics
+ git-status: show the remote tracking statistics
+ Refactor "tracking statistics" code used by "git checkout"
Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.
* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged. It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are. The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.
The -X<option> part may change, Dscho mentions that a single-letter -X
that take stuck option is against syntax rules, and I think he's right.
This is more "because we can", not "because we need to".
* mv/merge-in-c (Mon Jul 7 19:24:20 2008 +0200) 15 commits
- Build in merge
+ Fix t7601-merge-pull-config.sh on AIX
+ git-commit-tree: make it usable from other builtins
+ Add new test case to ensure git-merge prepends the custom merge
message
+ Add new test case to ensure git-merge reduces octopus parents when
possible
+ Introduce reduce_heads()
+ Introduce get_merge_bases_many()
+ Add new test to ensure git-merge handles more than 25 refs.
+ Introduce get_octopus_merge_bases() in commit.c
+ git-fmt-merge-msg: make it usable from other builtins
+ Move read_cache_unmerged() to read-cache.c
+ Add new test to ensure git-merge handles pull.twohead and
pull.octopus
+ Move parse-options's skip_prefix() to git-compat-util.h
+ Move commit_list_count() to commit.c
+ Move split_cmdline() to alias.c
----------------------------------------------------------------
[Graduated to "master"]
* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
+ Add another fast-import example, this time for .zip files
* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
+ Only use GIT_CONFIG in "git config", not other programs
* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
+ Eliminate an unnecessary chdir("..")
+ Add support for GIT_CEILING_DIRECTORIES
+ Fold test-absolute-path into test-path-utils
+ Implement normalize_absolute_path
* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
+ rerere.autoupdate
+ t4200: fix rerere test
+ rerere: remove dubious "tail_optimization"
+ git-rerere: detect unparsable conflicts
+ rerere: rerere_created_at() and has_resolution() abstraction
A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.
* js/maint-daemon-syslog (Thu Jul 3 16:27:24 2008 +0100) 1 commit
+ git daemon: avoid calling syslog() from a signal handler
Meant for 'maint' as well.
----------------------------------------------------------------
[On Hold]
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
----------------------------------------------------------------
[Stalled/Needs more work]
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
- [BROKEN wrt shallow clones] Ignore graft during object transfer
Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck. This fixes object transfer to ignore grafts.
Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.
* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
- Migrate git-blame to parse-option partially.
+ parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
+ parse-opt: fake short strings for callers to believe in.
+ parse-opt: do not print errors on unknown options, return -2
intead.
+ parse-opt: create parse_options_step.
+ parse-opt: Export a non NORETURN usage dumper.
+ parse-opt: have parse_options_{start,end}.
I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series. I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
+ git-blame --reverse
+ builtin-blame.c: allow more than 16 parents
+ builtin-blame.c: move prepare_final() into a separate function.
+ rev-list --children
+ revision traversal: --children option
The blame that finds where each line in the original lines moved to. This
may help a GSoC project that wants to gather statistical overview of the
history. The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).
The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-08 3:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vod591hlp.fsf@gitster.siamese.dyndns.org>
On Jul 7, 2008, at 5:58 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> And to answer your "git rebase --onto this from that-branch"
> question, I
> think ORIG_HEAD should record the tip of that-branch before rebase
> takes
> place, not the commit you happened to be at before running it.
> Switching
> branch to that-branch is not the drastic and unforseeable part. The
> drastic and unforseeable change is rebasing and seeing that the
> rebased
> result does not work with the new upstream `from`, and the user
> would want
> to have a way to quickly rewind the tip of the branch back to the
> state
> before the rebase. The new paragraph added by this patch should
> hopefully
> make this reasoning more clear.
I just wanted to make sure there was a clear reasoning and to see if
someone could word it clearly, as I was getting a little cross-eyed.
> -- >8 --
> Documentation: update sections on naming revisions and revision ranges
>
> Various *_HEAD pseudo refs were not documented in any central place.
> Especially since we may be teaching rebase and am to record ORIG_HEAD,
> it would be a good time to do so.
My only objection is to the "may". ;-)
Also, perhaps we should either list the commands that set ORIG_HEAD,
or add a note to that effect in their manpages. I'll see what wording
I can come up with, unless you (or someone else) gets to it first of
course.
> While at it, reword the explanation on r1..r2 notation to reduce
> confusion.
Looks good.
~~ Brian
^ permalink raw reply
* Re: [PATCH] fix "git-submodule add a/b/c/repository"
From: Mark Levedahl @ 2008-07-08 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sylvain Joyeux, Lars Hjemli, Ping Yin, git
In-Reply-To: <7v7ibxxfje.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I'd like to hear clarifications on two counts, please?
> (1) If Sylvain wanted to have that appear at dir0/dir1/init not init,
> would it have been sufficient to give that path twice (once for
> <repository> and another for <path> parameter) to make things work as
> expected?
>
git-submodule really requires two arguments:
$ git submodule add <URL> <relative-path-to-module-in-tree>
and supports two modes:
1) relative-path exists and is a valid repo: just add the module, it was
created in tree, the user is expected to eventually push this to the
given URL so other users will get this as normal. This exists to
simplify the process of creating a repo to begin with.
2) relative-path doesn't exist: clone from the URL. This is the normal use.
submodule supports adding a module in one of two ways:
So,
$ git submodule add dir0/dir1/init dir0/dir1/init
will add the repo, but also makes the repo its own origin. I don't think
this makes sense.
> (2) Is it generally considered a sane use case to specify an existing
> repository inside the working tree of a superproject as a submodule
> using "git submodule add" like Sylvain's example did?
>
> I would have understood if the command were "git add dir0/dir1/init",
> but I have this vague recolleciton that "git submodule add" is about
> telling our repository about a submodule that comes from _outside_.
>
>
>
Adding an existing in-tree repo, ala
$ git submodule add <intended-URL> <path>
is there to ease the initial creation of a submodule. It can be created
and registered in-tree, and later pushed to the server. This is sane,
but is not the normal usage (makes sense only on creation).
Mark
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Jay Soffian @ 2008-07-08 3:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Brian Gernhardt
In-Reply-To: <7vod591hlp.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 7, 2008 at 5:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> +HEAD names the commit your changes in the working tree is based on.
How about:
"HEAD names the commit your working tree is based on. This is the tip
of the checked out branch, unless HEAD is detached. (HEAD is said to
be detached if a commit is checked out which is not the tip of any
branch.)"
> +FETCH_HEAD records the branch you fetched from a remote repository
> +with your last 'git-fetch' invocation.
consistency w/above: s/records/names/
> +ORIG_HEAD is created by commands that moves your HEAD in a drastic
> +way, to record the position of the HEAD before their operation, so that
> +you can change the tip of the branch back to the state before you ran
> +them easily.
s/moves/move/; s/can change/can easily change/; s/them easily./them./;
But maybe this reads better:
ORIG_HEAD is created by commands that move HEAD in a drastic way to
record the position of HEAD before their operation, so that the branch
can easily be reset back to its prior state.
> +MERGE_HEAD records the commit(s) you are merging into your branch
> +when you run 'git-merge'.
So it's the "<remote>" arg or args mentioned in the git-merge man page?
j.
^ permalink raw reply
* [StGit PATCH 0/2] Test improvements
From: Karl Hasselström @ 2008-07-08 4:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
First, a change across all the tests to make sure that stg always
exits with the correct exit code even when it's not zero. This lets us
detect the difference between a controlled failure and a crash.
Second, a rather comprehensive test fir "stg edit" -- we didn't test
it at all. Which can be seen in the number of failures in this test.
They are available in kha/safe. The patches in kha/experimental have
been rebased on top of these, resulting in a number of new test
failures that I've had to fix.
---
Karl Hasselström (2):
Test for "stg edit"
Test for specific exit code
t/README | 6 +
t/t0001-subdir-branches.sh | 12 +--
t/t0002-status.sh | 2
t/t1000-branch-create.sh | 8 +-
t/t1001-branch-rename.sh | 2
t/t1002-branch-clone.sh | 2
t/t1200-push-modified.sh | 2
t/t1202-push-undo.sh | 4 -
t/t1203-push-conflict.sh | 4 -
t/t1205-push-subdir.sh | 4 -
t/t1301-repair.sh | 2
t/t1302-repair-interop.sh | 4 -
t/t1400-patch-history.sh | 2
t/t1501-sink.sh | 2
t/t1600-delete-one.sh | 4 -
t/t1601-delete-many.sh | 2
t/t2000-sync.sh | 4 -
t/t2101-pull-policy-pull.sh | 2
t/t2200-rebase.sh | 2
t/t2500-clean.sh | 2
t/t2900-rename.sh | 8 +-
t/t3000-dirty-merge.sh | 2
t/t3300-edit.sh | 205 +++++++++++++++++++++++++++++++++++++++++++
t/t4000-upgrade.sh | 2
t/test-lib.sh | 24 +++++
25 files changed, 271 insertions(+), 42 deletions(-)
create mode 100755 t/t3300-edit.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH 1/2] Test for specific exit code
From: Karl Hasselström @ 2008-07-08 4:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080708035750.23134.75833.stgit@yoghurt>
When a command is supposed to fail in a test, test for the exact error
code we're expecting, not just that it's non-zero. This makes sure
e.g. that a command that's supposed to fail doesn't do so with an
unhandled exception.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/README | 6 +++---
t/t0001-subdir-branches.sh | 12 ++++++------
t/t0002-status.sh | 2 +-
t/t1000-branch-create.sh | 8 ++++----
t/t1001-branch-rename.sh | 2 +-
t/t1002-branch-clone.sh | 2 +-
t/t1200-push-modified.sh | 2 +-
t/t1202-push-undo.sh | 4 ++--
t/t1203-push-conflict.sh | 4 ++--
t/t1205-push-subdir.sh | 4 ++--
t/t1301-repair.sh | 2 +-
t/t1302-repair-interop.sh | 4 ++--
t/t1400-patch-history.sh | 2 +-
t/t1501-sink.sh | 2 +-
t/t1600-delete-one.sh | 4 ++--
t/t1601-delete-many.sh | 2 +-
t/t2000-sync.sh | 4 ++--
t/t2101-pull-policy-pull.sh | 2 +-
t/t2200-rebase.sh | 2 +-
t/t2500-clean.sh | 2 +-
t/t2900-rename.sh | 8 ++++----
t/t3000-dirty-merge.sh | 2 +-
t/t4000-upgrade.sh | 2 +-
t/test-lib.sh | 24 ++++++++++++++++++++++++
24 files changed, 66 insertions(+), 42 deletions(-)
diff --git a/t/README b/t/README
index 77f0b6c..757f810 100644
--- a/t/README
+++ b/t/README
@@ -163,9 +163,9 @@ library for your script to use.
yields success, test is considered a failure.
This should _not_ be used for tests that succeed when their
- commands fail -- use test_expect_success and shell negation (!) for
- that. test_expect_failure is for cases when a test is known to be
- broken.
+ commands fail -- use test_expect_success and one of general_error,
+ command_error, and conflict for that. test_expect_failure is for
+ cases when a test is known to be broken.
- test_debug <script>
diff --git a/t/t0001-subdir-branches.sh b/t/t0001-subdir-branches.sh
index 0eed3a4..69c11a3 100755
--- a/t/t0001-subdir-branches.sh
+++ b/t/t0001-subdir-branches.sh
@@ -39,9 +39,9 @@ test_expect_success 'Try new form of id with slashy branch' \
stg id foo@x/y/z//top'
test_expect_success 'Try old id with slashy branch' '
- ! stg id foo/ &&
- ! stg id foo/top &&
- ! stg id foo@x/y/z/top
+ command_error stg id foo/ &&
+ command_error stg id foo/top &&
+ command_error stg id foo@x/y/z/top
'
test_expect_success 'Create patch in slashy branch' \
@@ -51,11 +51,11 @@ test_expect_success 'Create patch in slashy branch' \
test_expect_success 'Rename branches' \
'stg branch --rename master goo/gaa &&
- ! git show-ref --verify --quiet refs/heads/master &&
+ must_fail git show-ref --verify --quiet refs/heads/master &&
stg branch --rename goo/gaa x1/x2/x3/x4 &&
- ! git show-ref --verify --quiet refs/heads/goo/gaa &&
+ must_fail git show-ref --verify --quiet refs/heads/goo/gaa &&
stg branch --rename x1/x2/x3/x4 servant &&
- ! git show-ref --verify --quiet refs/heads/x1/x2/x3/x4
+ must_fail git show-ref --verify --quiet refs/heads/x1/x2/x3/x4
'
test_done
diff --git a/t/t0002-status.sh b/t/t0002-status.sh
index 4364709..d9cb2cc 100755
--- a/t/t0002-status.sh
+++ b/t/t0002-status.sh
@@ -114,7 +114,7 @@ A fie
C foo/bar
EOF
test_expect_success 'Status after conflicting push' '
- ! stg push &&
+ conflict_old stg push &&
stg status > output.txt &&
test_cmp expected.txt output.txt
'
diff --git a/t/t1000-branch-create.sh b/t/t1000-branch-create.sh
index 5a097a4..3fff3ee 100755
--- a/t/t1000-branch-create.sh
+++ b/t/t1000-branch-create.sh
@@ -26,7 +26,7 @@ test_expect_success \
test_expect_success \
'Try to create an stgit branch with a spurious patches/ entry' '
- ! stg branch -c foo1
+ command_error stg branch -c foo1
'
test_expect_success \
@@ -43,7 +43,7 @@ test_expect_success \
test_expect_success \
'Try to create an stgit branch with an existing git branch by that name' '
- ! stg branch -c foo2
+ command_error stg branch -c foo2
'
test_expect_success \
@@ -58,7 +58,7 @@ test_expect_success \
test_expect_success \
'Create an invalid refs/heads/ entry' '
touch .git/refs/heads/foo3 &&
- ! stg branch -c foo3
+ command_error stg branch -c foo3
'
test_expect_failure \
@@ -87,7 +87,7 @@ test_expect_success \
test_expect_success \
'Create branch down the stack, behind the conflict caused by the generated file' '
- ! stg branch --create foo4 master^
+ command_error stg branch --create foo4 master^
'
test_expect_success \
diff --git a/t/t1001-branch-rename.sh b/t/t1001-branch-rename.sh
index dd12132..d5d3aef 100755
--- a/t/t1001-branch-rename.sh
+++ b/t/t1001-branch-rename.sh
@@ -19,7 +19,7 @@ test_expect_success \
test_expect_success \
'Rename the current stgit branch' \
- '! stg branch -r foo bar
+ 'command_error stg branch -r foo bar
'
test_expect_success \
diff --git a/t/t1002-branch-clone.sh b/t/t1002-branch-clone.sh
index b0087e9..19bdc45 100755
--- a/t/t1002-branch-clone.sh
+++ b/t/t1002-branch-clone.sh
@@ -21,7 +21,7 @@ test_expect_success \
test_expect_success \
'Try to create a patch in a GIT branch' \
'
- ! stg new p0 -m "p0"
+ command_error stg new p0 -m "p0"
'
test_expect_success \
diff --git a/t/t1200-push-modified.sh b/t/t1200-push-modified.sh
index ba4f70c..6ebd0a1 100755
--- a/t/t1200-push-modified.sh
+++ b/t/t1200-push-modified.sh
@@ -49,7 +49,7 @@ test_expect_success \
test_expect_success \
'Attempt to push the first of those patches without --merged' \
- "(cd bar && ! stg push
+ "(cd bar && conflict_old stg push
)
"
diff --git a/t/t1202-push-undo.sh b/t/t1202-push-undo.sh
index b602643..544fe8d 100755
--- a/t/t1202-push-undo.sh
+++ b/t/t1202-push-undo.sh
@@ -43,7 +43,7 @@ test_expect_success \
test_expect_success \
'Push the second patch with conflict' \
'
- ! stg push bar
+ conflict_old stg push bar
'
test_expect_success \
@@ -55,7 +55,7 @@ test_expect_success \
test_expect_success \
'Check the push after undo fails as well' \
'
- ! stg push bar
+ conflict_old stg push bar
'
test_expect_success \
diff --git a/t/t1203-push-conflict.sh b/t/t1203-push-conflict.sh
index 72bd49f..96fee15 100755
--- a/t/t1203-push-conflict.sh
+++ b/t/t1203-push-conflict.sh
@@ -38,7 +38,7 @@ test_expect_success \
test_expect_success \
'Push the first patch with conflict' \
'
- ! stg push foo
+ conflict_old stg push foo
'
test_expect_success \
@@ -56,7 +56,7 @@ test_expect_success \
test_expect_success \
'Check that pop will fail while there are unmerged conflicts' \
'
- ! stg pop
+ command_error stg pop
'
test_expect_success \
diff --git a/t/t1205-push-subdir.sh b/t/t1205-push-subdir.sh
index 175d36d..945eb74 100755
--- a/t/t1205-push-subdir.sh
+++ b/t/t1205-push-subdir.sh
@@ -47,7 +47,7 @@ test_expect_success 'Conflicting push from subdir' '
[ "$(echo $(cat x.txt))" = "x0" ] &&
[ "$(echo $(cat foo/y.txt))" = "y0" ] &&
cd foo &&
- ! stg push p2 &&
+ conflict_old stg push p2 &&
cd .. &&
[ "$(echo $(stg status --conflict))" = "foo/y.txt x.txt" ]
'
@@ -62,7 +62,7 @@ test_expect_success 'Conflicting add/unknown file in subdir' '
stg pop &&
mkdir -p d &&
echo bar > d/test &&
- ! stg push foo &&
+ command_error stg push foo &&
[ $(stg top) != "foo" ]
'
diff --git a/t/t1301-repair.sh b/t/t1301-repair.sh
index b555b93..33f8f6d 100755
--- a/t/t1301-repair.sh
+++ b/t/t1301-repair.sh
@@ -5,7 +5,7 @@ test_description='Test the repair command.'
test_expect_success \
'Repair in a non-initialized repository' \
- '! stg repair'
+ 'command_error stg repair'
test_expect_success \
'Initialize the StGIT repository' \
diff --git a/t/t1302-repair-interop.sh b/t/t1302-repair-interop.sh
index 82c5ed2..3ea48e7 100755
--- a/t/t1302-repair-interop.sh
+++ b/t/t1302-repair-interop.sh
@@ -27,7 +27,7 @@ test_expect_success 'Create five patches' '
test_expect_success 'Pop two patches with git-reset' '
git reset --hard HEAD~2 &&
- ! stg refresh &&
+ command_error stg refresh &&
stg repair &&
stg refresh &&
[ "$(echo $(stg applied))" = "p0 p1 p2" ] &&
@@ -42,7 +42,7 @@ test_expect_success 'Create a new patch' '
test_expect_success 'Go to an unapplied patch with with git-reset' '
git reset --hard $(stg id p3) &&
- ! stg refresh &&
+ command_error stg refresh &&
stg repair &&
stg refresh &&
[ "$(echo $(stg applied))" = "p0 p1 p2 p3" ] &&
diff --git a/t/t1400-patch-history.sh b/t/t1400-patch-history.sh
index a693e75..13cd1e3 100755
--- a/t/t1400-patch-history.sh
+++ b/t/t1400-patch-history.sh
@@ -82,7 +82,7 @@ test_expect_success \
echo bar > test && stg refresh &&
stg pop &&
echo foo > test && stg refresh &&
- ! stg push &&
+ conflict_old stg push &&
stg log --full | grep -q -e "^push(c) "
'
diff --git a/t/t1501-sink.sh b/t/t1501-sink.sh
index 6af45fe..ac9e25d 100755
--- a/t/t1501-sink.sh
+++ b/t/t1501-sink.sh
@@ -17,7 +17,7 @@ test_expect_success 'Initialize StGit stack' '
'
test_expect_success 'sink without applied patches' '
- ! stg sink
+ command_error stg sink
'
test_expect_success 'sink a specific patch without applied patches' '
diff --git a/t/t1600-delete-one.sh b/t/t1600-delete-one.sh
index c3451d8..b526a55 100755
--- a/t/t1600-delete-one.sh
+++ b/t/t1600-delete-one.sh
@@ -20,7 +20,7 @@ test_expect_success \
'Try to delete a non-existing patch' \
'
[ $(stg applied | wc -l) -eq 1 ] &&
- ! stg delete bar &&
+ command_error stg delete bar &&
[ $(stg applied | wc -l) -eq 1 ]
'
@@ -29,7 +29,7 @@ test_expect_success \
'
echo dirty >> foo.txt &&
[ $(stg applied | wc -l) -eq 1 ] &&
- ! stg delete foo &&
+ command_error stg delete foo &&
[ $(stg applied | wc -l) -eq 1 ] &&
git reset --hard
'
diff --git a/t/t1601-delete-many.sh b/t/t1601-delete-many.sh
index 30b0a1d..bc5364f 100755
--- a/t/t1601-delete-many.sh
+++ b/t/t1601-delete-many.sh
@@ -37,7 +37,7 @@ test_expect_success \
'
[ "$(echo $(stg applied))" = "p0 p1 p2" ] &&
[ "$(echo $(stg unapplied))" = "p5 p8 p9" ] &&
- ! stg delete p7 p8 p2 p0 &&
+ command_error stg delete p7 p8 p2 p0 &&
[ "$(echo $(stg applied))" = "p0 p1 p2" ] &&
[ "$(echo $(stg unapplied))" = "p5 p8 p9" ]
'
diff --git a/t/t2000-sync.sh b/t/t2000-sync.sh
index e489603..9852eb8 100755
--- a/t/t2000-sync.sh
+++ b/t/t2000-sync.sh
@@ -109,7 +109,7 @@ test_expect_success \
test_expect_success \
'Synchronise the first two patches with the master branch (to fail)' \
'
- ! stg sync -B master -a
+ conflict_old stg sync -B master -a
'
test_expect_success \
@@ -127,7 +127,7 @@ test_expect_success \
test_expect_success \
'Synchronise the third patch with the exported series (to fail)' \
'
- ! stg sync -s patches-master/series p3
+ conflict_old stg sync -s patches-master/series p3
'
test_expect_success \
diff --git a/t/t2101-pull-policy-pull.sh b/t/t2101-pull-policy-pull.sh
index ce4b5c8..777ccb5 100755
--- a/t/t2101-pull-policy-pull.sh
+++ b/t/t2101-pull-policy-pull.sh
@@ -43,7 +43,7 @@ test_expect_success \
'Rewind/rewrite upstream commit and pull it from clone, without --merged' \
'
(cd upstream && echo b >> file2 && stg refresh) &&
- (cd clone && ! stg pull)
+ (cd clone && conflict_old stg pull)
'
test_expect_success \
diff --git a/t/t2200-rebase.sh b/t/t2200-rebase.sh
index ec2a104..a6f43bc 100755
--- a/t/t2200-rebase.sh
+++ b/t/t2200-rebase.sh
@@ -34,7 +34,7 @@ test_expect_success \
test_expect_success \
'Attempt rebase to non-existing commit' \
'
- ! stg rebase not-a-ref
+ command_error stg rebase not-a-ref
'
test_expect_success \
diff --git a/t/t2500-clean.sh b/t/t2500-clean.sh
index ad8f892..abde9cf 100755
--- a/t/t2500-clean.sh
+++ b/t/t2500-clean.sh
@@ -32,7 +32,7 @@ test_expect_success 'Create a conflict' '
stg new p2 -m p2
echo quux > foo.txt &&
stg refresh &&
- ! stg push
+ conflict_old stg push
'
test_expect_success 'Make sure conflicting patches are preserved' '
diff --git a/t/t2900-rename.sh b/t/t2900-rename.sh
index 5f47f86..0e16d6e 100755
--- a/t/t2900-rename.sh
+++ b/t/t2900-rename.sh
@@ -13,7 +13,7 @@ Tests some parts of the stg rename command.'
stg init
test_expect_success 'Rename in empty' '
- ! stg rename foo
+ command_error stg rename foo
'
test_expect_success 'Rename single top-most' '
@@ -23,7 +23,7 @@ test_expect_success 'Rename single top-most' '
# bar
test_expect_success 'Rename non-existing' '
- ! stg rename neithersuchpatch norsuchpatch
+ command_error stg rename neithersuchpatch norsuchpatch
'
test_expect_success 'Rename with two arguments' '
@@ -33,11 +33,11 @@ test_expect_success 'Rename with two arguments' '
# foo,baz
test_expect_success 'Rename to existing name' '
- ! stg rename foo baz
+ command_error stg rename foo baz
'
test_expect_success 'Rename to same name' '
- ! stg rename foo foo
+ command_error stg rename foo foo
'
test_expect_success 'Rename top-most when others exist' '
diff --git a/t/t3000-dirty-merge.sh b/t/t3000-dirty-merge.sh
index d87bba1..4dd6da3 100755
--- a/t/t3000-dirty-merge.sh
+++ b/t/t3000-dirty-merge.sh
@@ -26,7 +26,7 @@ test_expect_success 'Push with dirty worktree' '
echo 4 > a &&
[ "$(echo $(stg applied))" = "p1" ] &&
[ "$(echo $(stg unapplied))" = "p2" ] &&
- ! stg goto p2 &&
+ conflict stg goto p2 &&
[ "$(echo $(stg applied))" = "p1" ] &&
[ "$(echo $(stg unapplied))" = "p2" ] &&
[ "$(echo $(cat a))" = "4" ]
diff --git a/t/t4000-upgrade.sh b/t/t4000-upgrade.sh
index 8a308fb..ea9bf0b 100755
--- a/t/t4000-upgrade.sh
+++ b/t/t4000-upgrade.sh
@@ -31,7 +31,7 @@ for ver in 0.12 0.8; do
test_expect_success \
"v$ver: Make sure the base ref is no longer there" '
- ! git show-ref --verify --quiet refs/bases/master
+ must_fail git show-ref --verify --quiet refs/bases/master
'
cd ..
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 95e322e..ad8da68 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -285,6 +285,30 @@ test_expect_code () {
echo >&3 ""
}
+# When running an StGit command that should exit with an error, use
+# these instead of testing for any non-zero exit code with !.
+exit_code () {
+ expected=$1
+ shift
+ "$@"
+ test $? -eq $expected
+}
+general_error () { exit_code 1 "$@" ; }
+command_error () { exit_code 2 "$@" ; }
+conflict () { exit_code 3 "$@" ; }
+
+# Old-infrastructure commands don't exit with the proper value on
+# conflicts. But we don't want half the tests to fail because of that,
+# so use this instead of "conflict" for them.
+conflict_old () { command_error "$@" ; }
+
+# Same thing, but for other commands that StGit where we just want to
+# make sure that they fail instead of crashing.
+must_fail () {
+ "$@"
+ test $? -gt 0 -a $? -le 129
+}
+
# test_cmp is a helper function to compare actual and expected output.
# You can use it like:
#
^ permalink raw reply related
* [StGit PATCH 2/2] Test for "stg edit"
From: Karl Hasselström @ 2008-07-08 4:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080708035750.23134.75833.stgit@yoghurt>
We weren't testing this comaratively complicated command at all. (And
not surprisingly, some corner cases that should have worked didn't.)
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t3300-edit.sh | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 205 insertions(+), 0 deletions(-)
create mode 100755 t/t3300-edit.sh
diff --git a/t/t3300-edit.sh b/t/t3300-edit.sh
new file mode 100755
index 0000000..8304d9f
--- /dev/null
+++ b/t/t3300-edit.sh
@@ -0,0 +1,205 @@
+#!/bin/sh
+test_description='Test "stg edit"'
+
+. ./test-lib.sh
+
+test_expect_success 'Setup' '
+ printf "000\n111\n222\n" >> foo &&
+ git add foo &&
+ git commit -m "Initial commit" &&
+ sed -i "s/000/000xx/" foo &&
+ git commit -a -m "First change" &&
+ sed -i "s/111/111yy/" foo &&
+ git commit -a -m "Second change" &&
+ sed -i "s/222/222zz/" foo &&
+ git commit -a -m "Third change" &&
+ stg init &&
+ stg uncommit -n 3 p &&
+ stg pop
+'
+
+# Commit parse functions.
+msg () { git cat-file -p $1 | sed '1,/^$/d' | tr '\n' / | sed 's,/*$,,' ; }
+auth () { git log -n 1 --pretty=format:"%an, %ae" $1 ; }
+date () { git log -n 1 --pretty=format:%ai $1 ; }
+
+test_expect_success 'Edit message of top patch' '
+ test "$(msg HEAD)" = "Second change" &&
+ stg edit p2 -m "Second change 2" &&
+ test "$(msg HEAD)" = "Second change 2"
+'
+
+test_expect_success 'Edit message of non-top patch' '
+ test "$(msg HEAD^)" = "First change" &&
+ stg edit p1 -m "First change 2" &&
+ test "$(msg HEAD^)" = "First change 2"
+'
+
+test_expect_success 'Edit message of unapplied patch' '
+ test "$(msg $(stg id p3))" = "Third change" &&
+ stg edit p3 -m "Third change 2" &&
+ test "$(msg $(stg id p3))" = "Third change 2"
+'
+
+test_expect_success 'Set patch message with --file <file>' '
+ test "$(msg HEAD)" = "Second change 2" &&
+ echo "Pride or Prejudice" > commitmsg &&
+ stg edit p2 -f commitmsg &&
+ test "$(msg HEAD)" = "Pride or Prejudice"
+'
+
+test_expect_success 'Set patch message with --file -' '
+ echo "Pride and Prejudice" | stg edit p2 -f - &&
+ test "$(msg HEAD)" = "Pride and Prejudice"
+'
+
+( printf 'From: A U Thor <author@example.com>\nDate: <omitted>'
+ printf '\n\nPride and Prejudice' ) > expected-tmpl
+omit_date () { sed "s/^Date:.*$/Date: <omitted>/" ; }
+
+test_expect_success 'Save template to file' '
+ stg edit --save-template saved-tmpl p2 &&
+ omit_date < saved-tmpl > saved-tmpl-d &&
+ test_cmp expected-tmpl saved-tmpl-d
+'
+
+test_expect_success 'Save template to stdout' '
+ stg edit --save-template - p2 > saved-tmpl2 &&
+ omit_date < saved-tmpl2 > saved-tmpl2-d &&
+ test_cmp expected-tmpl saved-tmpl2-d
+'
+
+# Test the various ways of invoking the interactive editor. The
+# preference order should be
+#
+# 1. GIT_EDITOR
+# 2. stgit.editor (legacy)
+# 3. core.editor
+# 4. VISUAL
+# 5. EDITOR
+# 6. vi
+
+mkeditor ()
+{
+ cat > "$1" <<EOF
+#!/bin/sh
+printf "\n$1\n" >> "\$1"
+EOF
+ chmod a+x "$1"
+}
+
+mkeditor vi
+test_expect_failure 'Edit commit message interactively (vi)' '
+ m=$(msg HEAD) &&
+ PATH=.:$PATH stg edit p2 &&
+ test "$(msg HEAD)" = "$m/vi"
+'
+
+mkeditor e1
+test_expect_success 'Edit commit message interactively (EDITOR)' '
+ m=$(msg HEAD) &&
+ EDITOR=./e1 PATH=.:$PATH stg edit p2 &&
+ echo $m && echo $(msg HEAD) &&
+ test "$(msg HEAD)" = "$m/e1"
+'
+
+mkeditor e2
+test_expect_failure 'Edit commit message interactively (VISUAL)' '
+ m=$(msg HEAD) &&
+ VISUAL=./e2 EDITOR=./e1 PATH=.:$PATH stg edit p2 &&
+ test "$(msg HEAD)" = "$m/e2"
+'
+
+mkeditor e3
+test_expect_failure 'Edit commit message interactively (core.editor)' '
+ m=$(msg HEAD) &&
+ git config core.editor e3 &&
+ VISUAL=./e2 EDITOR=./e1 PATH=.:$PATH stg edit p2 &&
+ test "$(msg HEAD)" = "$m/e3"
+'
+
+mkeditor e4
+test_expect_success 'Edit commit message interactively (stgit.editor)' '
+ m=$(msg HEAD) &&
+ git config stgit.editor e4 &&
+ VISUAL=./e2 EDITOR=./e1 PATH=.:$PATH stg edit p2 &&
+ test "$(msg HEAD)" = "$m/e4"
+'
+
+mkeditor e5
+test_expect_failure 'Edit commit message interactively (GIT_EDITOR)' '
+ m=$(msg HEAD) &&
+ GIT_EDITOR=./e5 VISUAL=./e2 EDITOR=./e1 PATH=.:$PATH stg edit p2 &&
+ test "$(msg HEAD)" = "$m/e5"
+'
+
+rm -f vi e1 e2 e3 e4 e5
+git config --unset core.editor
+git config --unset stgit.editor
+
+mkeditor twoliner
+test_expect_failure 'Both noninterative and interactive editing' '
+ EDITOR=./twoliner stg edit -e -m "oneliner" p2 &&
+ test "$(msg HEAD)" = "oneliner/twoliner"
+'
+rm -f twoliner
+
+cat > diffedit <<EOF
+#!/bin/sh
+sed -i 's/111yy/111YY/' "\$1"
+EOF
+chmod a+x diffedit
+test_expect_success 'Edit patch diff' '
+ EDITOR=./diffedit stg edit -d p2 &&
+ test "$(grep 111 foo)" = "111YY"
+'
+rm -f diffedit
+
+test_expect_success 'Sign a patch' '
+ m=$(msg HEAD) &&
+ stg edit --sign p2 &&
+ test "$(msg HEAD)" = "$m//Signed-off-by: C O Mitter <committer@example.com>"
+'
+
+test_expect_success 'Acknowledge a patch' '
+ m=$(msg HEAD^) &&
+ stg edit --ack p1 &&
+ test "$(msg HEAD^)" = "$m//Acked-by: C O Mitter <committer@example.com>"
+'
+
+test_expect_success 'Set author' '
+ stg edit p2 --author "Jane Austin <jaustin@example.com>" &&
+ test "$(auth HEAD)" = "Jane Austin, jaustin@example.com"
+'
+
+test_expect_success 'Fail to set broken author' '
+ command_error stg edit p2 --author "No Mail Address" &&
+ test "$(auth HEAD)" = "Jane Austin, jaustin@example.com"
+'
+
+test_expect_success 'Set author name' '
+ stg edit p2 --authname "Jane Austen" &&
+ test "$(auth HEAD)" = "Jane Austen, jaustin@example.com"
+'
+
+test_expect_success 'Set author email' '
+ stg edit p2 --authemail "jausten@example.com" &&
+ test "$(auth HEAD)" = "Jane Austen, jausten@example.com"
+'
+
+test_expect_failure 'Set author date (RFC2822 format)' '
+ stg edit p2 --authdate "Wed, 10 Jul 2013 23:39:00 pm -0300" &&
+ test "$(date HEAD)" = "2013-07-10 23:39:00 -0300"
+'
+
+test_expect_failure 'Set author date (ISO 8601 format)' '
+ stg edit p2 --authdate "2013-01-28 22:30:00 -0300" &&
+ test "$(date HEAD)" = "2013-01-28 22:30:00 -0300"
+'
+
+test_expect_failure 'Fail to set invalid author date' '
+ command_error stg edit p2 --authdate "28 Jan 1813" &&
+ test "$(date HEAD)" = "2013-01-28 22:30:00 -0300"
+'
+
+test_done
^ permalink raw reply related
* Re: error: unlink(.git/refs/remotes/origin/testbranch) failed: was remote does not support deleting refs
From: Jeff King @ 2008-07-08 4:08 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, Martin, git
In-Reply-To: <37fcd2780807061134l341ac676ueb674a976ce15e6f@mail.gmail.com>
On Sun, Jul 06, 2008 at 10:34:31PM +0400, Dmitry Potapov wrote:
> On Sun, Jul 06, 2008 at 02:20:18AM +0200, Martin wrote:
> > But I get another error:
> > $ git push origin :testbranch
> > To ssh://myserver.com/my/path/to/repository
> > - [deleted] testbranch
> > error: unlink(.git/refs/remotes/origin/testbranch) failed: No such file_
> > or directory
> > error: Failed to delete
> >_
> > Any idea?
>
> It is harmless. It is just that "git push origin :refs/heads/testbranch"
> cannot remove your local reference to that branch because you already have
> removed it by running "git branch -d -r origin/testbranch"
It is harmless, but it still feels a little wrong to scare the user with
that message, especially since "Failed to delete" is ambiguous; it looks
like the main operation, deleting the remote ref, failed. But it didn't;
the operation that failed was something not even explicitly asked for.
How about this cleanup:
-- >8 --
make deleting a missing ref more quiet
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-send-pack.c | 3 +--
refs.c | 2 +-
t/t5404-tracking-branches.sh | 7 +++++++
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index d76260c..a708d0a 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -226,8 +226,7 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
if (args.verbose)
fprintf(stderr, "updating local tracking ref '%s'\n", rs.dst);
if (ref->deletion) {
- if (delete_ref(rs.dst, NULL))
- error("Failed to delete");
+ delete_ref(rs.dst, NULL);
} else
update_ref("update by push", rs.dst,
ref->new_sha1, NULL, 0, 0);
diff --git a/refs.c b/refs.c
index 6c6e9e5..39a3b23 100644
--- a/refs.c
+++ b/refs.c
@@ -925,7 +925,7 @@ int delete_ref(const char *refname, const unsigned char *sha1)
i = strlen(lock->lk->filename) - 5; /* .lock */
lock->lk->filename[i] = 0;
err = unlink(lock->lk->filename);
- if (err) {
+ if (err && errno != ENOENT) {
ret = 1;
error("unlink(%s) failed: %s",
lock->lk->filename, strerror(errno));
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
index 1493a92..64fe261 100755
--- a/t/t5404-tracking-branches.sh
+++ b/t/t5404-tracking-branches.sh
@@ -10,6 +10,7 @@ test_expect_success 'setup' '
git commit -m 1 &&
git branch b1 &&
git branch b2 &&
+ git branch b3 &&
git clone . aa &&
git checkout b1 &&
echo b1 >>file &&
@@ -50,4 +51,10 @@ test_expect_success 'deleted branches have their tracking branches removed' '
test "$(git rev-parse origin/b1)" = "origin/b1"
'
+test_expect_success 'already deleted tracking branches ignored' '
+ git branch -d -r origin/b3 &&
+ git push origin :b3 >output 2>&1 &&
+ ! grep error output
+'
+
test_done
--
1.5.6.2.381.ga86b
^ permalink raw reply related
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Lea Wiemann @ 2008-07-08 4:08 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, John Hawley, Marek Zawirski, Shawn O. Pearce,
Miklos Vajna, Johannes Schindelin, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <200807080227.43515.jnareb@gmail.com>
Jakub Narebski wrote:
> 3. Gitweb caching
I'll post a complete status update in the next few days. And three
large patches (including the mechanize test). ;-)
> Lea has chosen caching data and memcached as primary caching engine,
> and is working on object layer on top of Git.pm, namely Git::Repo and
> friends, which will be used by gitweb. If I understand correctly
> caching is to be done, or at least helped by this layer.
That's correct, except that I'm not using Git.pm anywhere; Git::Repo is
independent of Git.pm. More about that later...
^ permalink raw reply
* Re: [PATCH 1/3] git-imap-send: Allow the program to be run from subdirectories of a git tree.
From: Jeff King @ 2008-07-08 4:10 UTC (permalink / raw)
To: Rob Shearman; +Cc: git
In-Reply-To: <1096648c0807070105l49a6dc38ra1710b0aadb220d9@mail.gmail.com>
On Mon, Jul 07, 2008 at 09:05:22AM +0100, Rob Shearman wrote:
> Call setup_git_directory_gently to allow git-imap-send to be used from
> subdirectories of a git tree.
> [...]
> + setup_git_directory_gently( NULL );
I don't think this is right; now we _must_ be in a git tree to run the
command, which was not the case previously. You need to pass a non-NULL
parameter to setup_git_directory_gently, which is where it will store
the "are we in a git dir" return value (even if you don't want to look
at it, if the parameter is NULL, it will die("not a git repository")).
-Peff
^ permalink raw reply
* [PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase
From: Brian Gernhardt @ 2008-07-08 4:12 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
In-Reply-To: <35BBB0D4-B3E1-4097-AF11-E0F6223125EA@silverinsanity.com>
Merge has always set ORIG_HEAD but never mentioned it, while we
recently added it to am and rebase. These facts should be reflected
in the documentation.
git-reset also sets ORIG_HEAD, but that fact is already mentioned in
the very first example so no changes were needed there.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Documentation/git-am.txt | 6 ++++++
Documentation/git-merge.txt | 4 +++-
Documentation/git-rebase.txt | 3 ++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 3863eeb..88ca5f1 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -145,6 +145,12 @@ directory exists, so if you decide to start over from scratch,
run `rm -f -r .dotest` before running the command with mailbox
names.
+Before any patches are applied, ORIG_HEAD is set to the tip of the
+current branch. This is useful if you have problems with multiple
+commits, like running 'git am' on the wrong branch or an error in the
+commits that is more easily fixed by changing the mailbox (e.g.
+errors in the "From:" lines).
+
SEE ALSO
--------
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 62f99b5..019e4ca 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -81,7 +81,9 @@ Otherwise, merge will refuse to do any harm to your repository
(that is, it may fetch the objects from remote, and it may even
update the local branch used to keep track of the remote branch
with `git pull remote rbranch:lbranch`, but your working tree,
-`.git/HEAD` pointer and index file are left intact).
+`.git/HEAD` pointer and index file are left intact). In addition,
+merge always sets `.git/ORIG_HEAD` to the original state of HEAD so
+a problematic merge can be removed by using `git reset ORIG_HEAD`.
You may have local modifications in the working tree files. In
other words, 'git-diff' is allowed to report changes.
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index f3459c7..37382c4 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -26,7 +26,8 @@ of commits that would be shown by `git log <upstream>..HEAD`.
The current branch is reset to <upstream>, or <newbase> if the
--onto option was supplied. This has the exact same effect as
-`git reset --hard <upstream>` (or <newbase>).
+`git reset --hard <upstream>` (or <newbase>). This includes setting
+ORIG_HEAD to the pre-rebase tip of the branch.
The commits that were previously saved into the temporary area are
then reapplied to the current branch, one by one, in order. Note that
--
1.5.6.2.393.g45096
^ permalink raw reply related
* Re: Can I remove stg sync --undo ?
From: Karl Hasselström @ 2008-07-08 4:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807071347n17e2e09ai761b849d2d03bc9c@mail.gmail.com>
On 2008-07-07 21:47:13 +0100, Catalin Marinas wrote:
> 2008/7/5 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote:
> >
> > > There are two operations that can conflict for sync - pushing a
> > > patch and the actual sync'ing, i.e. a three-way merge with the
> > > patch to be synchronised with (kind of fold).
> >
> > My guess is that conflicts of the first type would work out of the
> > box (i.e. they'd get an extra log entry) while conflicts of the
> > second type would not.
>
> I don't really care as long as I can get back to the patch state
> before running the sync command if anything goes wrong. So, one undo
> level would be enough.
>
> > We need a sync undo test.
>
> Yes but not sure what how undo would behave in this situation yet.
OK, then I'll write a simple test that makes sure undo and sync
interact the way I imagine they should. ;-)
> > With just "stg undo" (or reset or redo), you get the usual
> > new-infrastructure check about dirty index and working tree (the
> > whole index must be clean, and the parts of the worktree we need
> > to touch must be clean). Which prevents you from undoing a
> > conflicting push, for example.
> >
> > With the --hard flag, any uncleanliness in index or worktree
> > simply gets zapped (just like with git reset --hard). I'm not 100%
> > happy with this -- what I'd really like is to zap only the files
> > that we need to touch. But I haven't figured out a good way to do
> > that.
>
> OK, not much to comment here, it's your implementation :-).
But you too get to live with the design decisions ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Shawn O. Pearce @ 2008-07-08 4:19 UTC (permalink / raw)
To: Jakub Narebski, Marek Zawirski
Cc: git, Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Miklos Vajna,
Johannes Schindelin, Stephan Beyer, Christian Couder,
Daniel Barkalow
In-Reply-To: <200807080227.43515.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> I'd very much like to have (or perhaps to wrote) some sort of interim
> progress report for Google Summer of Code 2008 projects on
> http://git.or.cz/gitwiki/SoC2008Projects. Therefore I'd like you to
> expand and/or correct those mini-summaries below.
>
> (It would be, I guess, good preparation for GSoC 2008 mid-term
> evaluations, which according to GSoC 2008 timeline
> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> are to take place July 7 -- July 14.)
Yes, it is that time for evaluations. The evaluations are now open
to students and mentors alike; please make sure you complete them
by the deadline of July 14th.
> 4. Eclipse plugin push support (!)
>
> Student: Marek Zawirski
> Mentor: Shawn O. Pearce
>
> I am not following egit/jgit development close enough, but if I remember
> correctly there is some code which provides very rudimentary support
> for native generation of simplified packs, and IIRC also for push over
> some protocols.
>
> And there is push support over SFTP and (encrypted) Amazon S3...
Marek is on holiday right now, so I have to answer for him here.
Otherwise I would have preferred to let him do it.
Thus far Marek has completed generation of packs, including delta
re-use from packs using either v1 or v2 index, including taking
advantage of the CRC inside the v2 index to accelerate a safe reuse.
This code permits jgit to write a valid pack.
The packing code does not (yet) search for a delta base, or create
a new delta for an undeltified object. Packing loose objects packs
them as whole objects in the pack file, resulting in little to no
reduction over their loose object size. This is not a limitation
of Java. Marek and I simply decided that protocol support was more
important than really tight network transport at this point in time.
As a result of being able to create pack files Marek was able to
implement the client side of git-push for the native pack transfer
service, aka push over SSH, push to another local repository (by
forking 'git receive-pack') and push over anonymous git://.
Using Marek's pack generation code I added support for push over
the dumb sftp:// and amazon-s3:// protocols, with the latter also
supporting transparent client side encryption.
I chose to add these features to jgit partly as an exercise to prove
that Marek's code was built well enough to be reused for this task,
partly because I wanted to backup some private personal repositories
to Amazon S3, and partly to prove that multiple dumb transports
could implement push support.
All of the above is done in the non-Eclipse, BSD licensed jgit
library, making it available to any tool built on top of the Java
platform, even if said tool does not use the Eclipse platform or
any other code from Eclipse.
At this point Marek's code is in the main egit.git tree's master
branch, and is in "production" use by myself and Robin, and maybe
a few others. I am quite happy with the work Marek has completed
to date for the project.
When Marek returns from his holiday he will be working on Eclipse
UI features to expose this jgit push functionality to the end-user
within the Eclipse workbench.
--
Shawn.
^ permalink raw reply
* Re: [StGit PATCH] Remove --undo flags from stg commands and docs
From: Karl Hasselström @ 2008-07-08 4:21 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807071354j50dca83aya90317f97f559b19@mail.gmail.com>
On 2008-07-07 21:54:01 +0100, Catalin Marinas wrote:
> 2008/7/4 Karl Hasselström <kha@treskal.com>:
>
> > In this one, I've just removed the --undo flag from sync without
> > adding anything back. Still undetermined if that's OK.
>
> I think it should be ok (see the other thread). Anyway, have you
> heard of anyone else using sync apart from me?
No, I haven't.
I've tried to understand what it does, and as far as I can tell it
doesn't do quite what I want. (What I want is the ability to 3-way
merge StGit patch stacks, so that I can modify the same patch stack in
several places and merge back and forth. From what I recall, the sync
command is more like a 2-way merge -- that is, it doesn't take the
last common ancestor into account. But it's been a while since I
studied it.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Jeff King @ 2008-07-08 4:26 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <F0AD23BC-FA9A-4593-8942-228C428B661E@silverinsanity.com>
On Mon, Jul 07, 2008 at 11:03:46AM -0400, Brian Gernhardt wrote:
> I personally expected @{1} to be identical to HEAD@{1}. Since omitting a
> ref usually refers to HEAD, why shouldn't omitting it when referring to
> the reflogs mean the HEAD log? The definition of @{1} is useful since
> there's no other easy way to get "current branch's reflog", but I think
> it's non-obvious. (Since HEAD@{1} is something completely different, I
> think the only other way to refer to @{1} is $(git symbolic-ref)@{1}.)
FYI, there was much discussion about this exact point:
http://thread.gmane.org/gmane.comp.version-control.git/38379
(I don't know that it has that much bearing on the current discussion,
but since I went to the trouble of digging it up, I thought you might
find it useful).
-Peff
^ permalink raw reply
* Re: [StGit PATCH 0/2] push optimizations
From: Karl Hasselström @ 2008-07-08 4:36 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807071412j71780300p87d00cccea6cd8f4@mail.gmail.com>
On 2008-07-07 22:12:26 +0100, Catalin Marinas wrote:
> 2008/7/2 Karl Hasselström <kha@treskal.com>:
>
> > Here's the git-apply call you asked for. You were right: it was a
> > huge speed-up.
>
> I know, I've been through this couple of years ago :-)
:-P
> > I set up a benchmark to test it:
> >
> > * 32 directories, each containing 32 subdirectories, each
> > containing 32 small (and different) files.
>
> Can you try with a Linux kernel like the -mm tree? You get normally
> sized patches which might show a difference with the patch log. You
> can clone the for-akpm branch on git://linux-arm.org/linux-2.6 and
> just uncommit ~300 patches.
Sure, I'll do that. (But one of the reasons I chose a fully synthetic
benchmark is that I wanted to start a performance suite similar to our
test suite, and we want such a thing to be repeatable but not too
large. (That said, operating on points of the kernel history that are
fixed should do the trick as well. I'll try to find such points -- a
long string of -mm patches somewhere in the history maybe?))
> > * I set all this up with a python script feeding fast-import. A
> > huge time-saver!
>
> What is fast-import?
man git-fast-import
I'll try to clean up and publish the script I used.
> > * Pop patches, git-reset to upstream, then goto top patch. This
> > makes sure that we use the new infrastructure to push, and that
> > we get one file-level conflict in each patch.
> >
> > Before the first patch, the "goto" command took 4:27 minutes,
> > wall-clock time. After the first patch, it took 1:31. After the
> > second, 0:48; one second or so slower than the stable branch
> > (which does not have a patch stack log).
>
> One second is just noise and depends on how warm the caches are. You
> could run a few times consecutively and discard the first result but
> we don't need to be that accurate.
I did run a few times, and it did indeed fluctuate some -- but I'm
pretty sure there was a measurable slowdown. Though I agree that it's
close enough that it doesn't really make a difference.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] avoid null SHA1 in oldest reflog
From: Jeff King @ 2008-07-08 4:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".
However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.
While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest ref
would return the null sha1, it instead returns the first
value the ref ever had.
We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
---
This patch was generally well-received in the first posting, but didn't
get applied. I think it was because the previous thread ended with me
voicing one concern: should we do this magic other places? I think the
answer is no, we don't need to. And even if I am wrong, then this is
probably still the right fix for _this_ bit, and we can fix the other if
and when a bug report comes in.
refs.c | 4 ++++
t/t1400-update-ref.sh | 9 ++++++++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 9e8e858..6c6e9e5 100644
--- a/refs.c
+++ b/refs.c
@@ -1412,6 +1412,10 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
tz = strtoul(tz_c, NULL, 10);
if (get_sha1_hex(logdata, sha1))
die("Log %s is corrupt.", logfile);
+ if (is_null_sha1(sha1)) {
+ if (get_sha1_hex(logdata + 41, sha1))
+ die("Log %s is corrupt.", logfile);
+ }
if (msg)
*msg = ref_msg(logdata, logend);
munmap(log_mapped, mapsz);
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index f387d46..ca99d37 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -155,7 +155,8 @@ rm -f .git/$m .git/logs/$m expect
git update-ref $m $D
cat >.git/logs/$m <<EOF
-$C $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150320 -0500
+0000000000000000000000000000000000000000 $C $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150320 -0500
+$C $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150350 -0500
$A $B $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150380 -0500
$F $Z $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150680 -0500
$Z $E $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150980 -0500
@@ -186,6 +187,12 @@ test_expect_success \
'Query "master@{May 26 2005 23:32:00}" (exactly history start)' \
'rm -f o e
git rev-parse --verify "master@{May 26 2005 23:32:00}" >o 2>e &&
+ test '"$C"' = $(cat o) &&
+ test "" = "$(cat e)"'
+test_expect_success \
+ 'Query "master@{May 26 2005 23:32:30}" (first non-creation change)' \
+ 'rm -f o e
+ git rev-parse --verify "master@{May 26 2005 23:32:30}" >o 2>e &&
test '"$A"' = $(cat o) &&
test "" = "$(cat e)"'
test_expect_success \
--
1.5.6
^ permalink raw reply related
* Re: [StGit PATCH] Discard stderr output from git apply
From: Karl Hasselström @ 2008-07-08 4:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807071349u7c35d2fcr5025b2b282f290f6@mail.gmail.com>
On 2008-07-07 21:49:31 +0100, Catalin Marinas wrote:
> 2008/7/4 Karl Hasselström <kha@treskal.com>:
>
> > It prints error messages when it fails, and we don't need to see
> > them since we don't care exactly _why_ it failed.
>
> Are you sure we don't need this? I found it useful when running
> "import" to see why a patch failed.
Aww, you're right. Apply isn't just called from the simple merge fast
path, it's also used to apply patches. Who would've guessed? ;-)
I'll add a parameter to shut it up or not depending on the caller's
preferences.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Cloning marks pack for .keep
From: Shawn O. Pearce @ 2008-07-08 4:46 UTC (permalink / raw)
To: Jean-Luc Herren, Junio C Hamano; +Cc: Git Mailing List, Daniel Barkalow
In-Reply-To: <48728A52.8080107@gmx.ch>
Jean-Luc Herren <jlh@gmx.ch> wrote:
> After cloning a local repository with "git clone file://...", the
> resulting repo had one big pack file, as expected, but also a
> matching ".keep" file. Certainly this is a bug, isn't it? The
> same happens if I clone git.git. I used git 1.5.6.1 but observed
> the same with the current master. I bisected this behavior to
> commit fa740529 by Shawn O. Pearce (CC'ing him). Since this dates
> back to 2007, I wonder if maybe only I am seeing this, but I
> cannot think of any reason for it.
This is a known issue to me; I have been seeing this behavior
myself since probably fa74 hit next. I just don't clone often
so I've never thought about it much. ;-)
I'm willing to bet its the hard-coded:
+ args.lock_pack = 1;
inside of fetch_refs_via_pack() that is causing the .keep file to
stay around after the clone. When this gets set the caller must
delete the transport->pack_lockfile (if non-null) once the refs
have all been updated to reference the objects downloaded into the
pack file. Under git-clone all refs are new and there is little to
no chance that someone issues "git gc" at the same time as the fetch
is running, so git-clone never cleaned up the pack_lockfile.
I think this would fix it.
--8<--
Remove unnecessary pack-*.keep file after successful git-clone
Once a clone is successful we no longer need to hold onto the
.keep file created by the transport. Delete the file so we
can later repack the complete repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-clone.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 7bcc664..7ee8275 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -337,6 +337,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
char branch_top[256], key[256], value[256];
struct strbuf reflog_msg;
+ struct transport *transport = NULL;
struct refspec refspec;
@@ -458,8 +459,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
refs = clone_local(path, git_dir);
else {
struct remote *remote = remote_get(argv[0]);
- struct transport *transport =
- transport_get(remote, remote->url[0]);
+ transport = transport_get(remote, remote->url[0]);
if (!transport->get_refs_list || !transport->fetch)
die("Don't know how to clone %s", transport->url);
@@ -529,6 +529,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
option_no_checkout = 1;
}
+ if (transport)
+ transport_unlock_pack(transport);
+
if (!option_no_checkout) {
struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
struct unpack_trees_options opts;
--
1.5.6.74.g8a5e
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] completion: add branch options --contains --merged --no-merged
From: Shawn O. Pearce @ 2008-07-08 4:49 UTC (permalink / raw)
To: Eric Raible; +Cc: Git Mailing List, Junio C Hamano, szeder
In-Reply-To: <279b37b20807071341k3551e61cl10c5969600ba8218@mail.gmail.com>
Eric Raible <raible@gmail.com> wrote:
> Signed-off-by: Eric Raible <raible@gmail.com>
Trivially-Acked-by: Shawn O. Pearce <spearce@spearce.org>
;-)
More completion support that probably should go to maint, as the
functionality in git-branch is in 1.5.6 but we (again) forgot to
make sure the completion was up-to-date prior to release.
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 0eb8df0..22e109d 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -546,7 +546,7 @@ _git_branch ()
> --*)
> __gitcomp "
> --color --no-color --verbose --abbrev= --no-abbrev
> - --track --no-track
> + --track --no-track --contains --merged --no-merged
> "
> ;;
> *)
> --
> 1.5.6.1.1071.g76fb.dirty
--
Shawn.
^ permalink raw reply
* uninstalling Git
From: Christian Jaeger @ 2008-07-08 4:57 UTC (permalink / raw)
To: Git Mailing List
Hello,
There are two situations where I'm missing a way to uninstall Git:
- accidental install with prefix=/usr instead of prefix=/usr/local which
I usually choose
- removing cruft from older gits, like tools and their man/info pages
which don't exist anymore in newer Git releases
I wonder why there's no "uninstall" make target. Ok, maybe some people
would argue that installing and uninstalling software through make has
never been the best way, but usually I don't have problems with software
providing "make uninstall", and I'm left with no solution for the above
once I choose to use "make install" for Git.
[
Well, there's the "checkinstall" tool, but for some reason using
checkinstall (version 1.6.1(-7) from Debian lenny) leads to some strange
problems:
at first I always got (with a fresh tree):
...
if test -r /usr/share/info/dir; then \
install-info --info-dir=/usr/share/info git.info ;\
install-info --info-dir=/usr/share/info gitman.info ;\
else \
echo "No directory found in /usr/share/info" >&2 ; \
fi
No `START-INFO-DIR-ENTRY' and no `This file documents'.
install-info(git.info): unable to determine description for `dir' entry
- giving up
No `START-INFO-DIR-ENTRY' and no `This file documents'.
install-info(gitman.info): unable to determine description for `dir'
entry - giving up
make[1]: *** [install-info] Error 1
make[1]: Leaving directory `/usr/src/GIT/T/git.1/Documentation'
make: *** [install-info] Error 2
and now I'm consistently getting (each time with a fresh tree):
asciidoc -b docbook -d book user-manual.txt
FAILED: unexpected error:
------------------------------------------------------------
Traceback (most recent call last):
File "/usr/bin/asciidoc", line 4014, in asciidoc
config.load_all(CONF_DIR)
File "/usr/bin/asciidoc", line 3637, in load_all
for f in os.listdir(filters):
OSError: [Errno 2] No such file or directory: '/etc/asciidoc/filters'
...
and now, again with a fresh tree but without -j2:
# checkinstall make prefix=/usr install install-doc install-info
...
asciidoc -b docbook -d manpage -f asciidoc.conf \
-agit_version=1.5.6.GIT -o git-add.xml+ git-add.txt
FAILED: unexpected error:
------------------------------------------------------------
Traceback (most recent call last):
File "/usr/bin/asciidoc", line 4014, in asciidoc
config.load_all(CONF_DIR)
File "/usr/bin/asciidoc", line 3637, in load_all
for f in os.listdir(filters):
OSError: [Errno 2] No such file or directory: '/etc/asciidoc/filters'
------------------------------------------------------------
make[1]: *** [git-add.xml] Error 1
make[1]: Leaving directory `/usr/src/GIT/T/git.1/Documentation'
make: *** [install-doc] Error 2
**** Installation failed. Aborting package creation.
Cleaning up...OK
Bye.
where /etc/asciidoc/filters clearly is a non-empty directory. It seems
to behave non-deterministically. So my guess is that checkinstall is
using LD_PRELOAD tricks or some such and just doesn't work for the task
here, at least not without fixing something.
]
So,
- is there any (good?) reason there is no uninstall target? Should I
look into creating one?
- do you have better or working alternative suggestions?
Actually I'd be happy if there are more elegant solutions than make
uninstall, since there is the race/hen-and-egg problem of having to run
"make uninstall" from the tree before checking out the new version, and
checking out the new version of course needs git, meaning the "right"
approach would be to keep the working dir of the last install for the
purpose of uninstallation until after having built the new version.
Maybe it's enough to just keep the toplevel Makefile, but that would be
making assumptions. Maybe I should talk with the Debian people about how
to build debs easily for such purposes (and not using the standard
Debian packages -- I'd really like to just have an own single package
without any applied patches etc.)?
Thanks,
Christian.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Jeff King @ 2008-07-08 4:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0806281549060.9925@racer>
On Sat, Jun 28, 2008 at 03:51:12PM +0100, Johannes Schindelin wrote:
> > Here's a somewhat hackish implementation of "git stash -i" that just
> > relies on "add -i":
>
> I like it.
Thinking about this some more, it seems to me to lack one really
important feature that "git add -i" has: you must stash all in one go.
That is, I may do some of the adds as "git add <file1> <file2>" and then
pick out the rest of the changes with "git add -p". And traditionally,
stashing has been about dumping all changes, so everything happened at
once.
But I think what I would really like here is to say "now I don't want to
stage for a commit; I want to stage into some bucket, so that I can
clear my workspace for making the commit". And then proceed to use "add"
or "add -i" in the usual way, except that they go into my bucket. And at
the end, I switch back to staging for a commit, make the commit, and
then start picking things out of my bucket.
And that workflow is not too hard to imagine by just pointing
GIT_INDEX_FILE to the bucket.
But I am still thinking on this, so I'll let it percolate and then maybe
try to implement something once I have a better sense of exactly what
workflow I want. I just thought I would throw it out there for others to
ponder.
-Peff
^ permalink raw reply
* Re: Test breakage [Re: [ANNOUNCE] GIT 1.5.6.2]
From: Jeff King @ 2008-07-08 5:16 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g4t342$9m8$1@ger.gmane.org>
On Mon, Jul 07, 2008 at 02:44:49PM +0200, Michael J Gruber wrote:
> On Kubuntu 7.10 (not my choice, this is at work...), "make test" gives:
>
> *** t9600-cvsimport.sh ***
> [...]
> * FAIL 6: update git module
> cd module-git &&
> git cvsimport -a -z 0 module &&
> git merge origin &&
> cd .. &&
> test_cmp module-cvs/o_fortuna module-git/o_fortuna
>
> On the second (and subsequent) run, "make test" succeeds. I tried again
> with a fresh copy from the tarball, same effect: failure on 1, success on
> 2 and following.
I tried reproducing on my Debian box with various weaks of $LANG, but I
couldn't. Can you please try running "./t9600-cvsimport.sh -v -i" and
send us the output of a failing instance. It's not clear which step in
failing test is causing the problem, or if cvsps is giving off any
useful errors.
> This is with LANG=de_DE.UTF-8, whereas with LANG=C the tests succeed the
> first time already. Are tests supposed to be done in C locale only? Do
> they reuse data from a previous test run? I didn't notice this with
> 1.5.6.1.
They should be perfectly repeatable, but I have run into problems in the
past with cruft in my ~/.cvsps directory. However, we should be setting
$HOME properly in t9600 to avoid this, so I'm not sure what the culprit
is.
-Peff
^ permalink raw reply
* PATCH] Documentation: Tweak use case in "git stash save --keep-index"
From: Eric Raible @ 2008-07-08 5:18 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, szeder
The documentation suggests using "git stash apply" in the
--keep-index workflow even though doing so will lead to clutter
in the stash. And given that the changes are about to be
committed anyway "git stash pop" is more sensible.
Additionally the text preceeding the example claims that it
works for "two or more commits", but the example itself is
really tailored for just two. Expanding it just a little
makes it clear how the procedure generalizes to N commits.
Signed-off-by: Eric Raible <raible@gmail.com>
---
Note that this is relative to Junio's pu branch (v1.5.6.2-397-g20210bb)
Documentation/git-stash.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index df26901..bf241da 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -201,9 +201,10 @@ $ git add --patch foo
$ git stash save --keep-index
$ build && run tests
$ git commit -m 'First part'
-$ git stash apply
+$ git stash pop
+... repeat above five steps until one commit remains ...
$ build && run tests
-$ git commit -a -m 'Second part'
+$ git commit foo -m 'Remaining parts'
----------------------------------------------------------------
SEE ALSO
--
1.5.6.1.1073.g489ff.dirty
^ permalink raw reply related
* Re: [PATCH] completion: add branch options --contains --merged --no-merged
From: Junio C Hamano @ 2008-07-08 5:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Eric Raible, Git Mailing List, szeder
In-Reply-To: <20080708044922.GD2542@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Eric Raible <raible@gmail.com> wrote:
>> Signed-off-by: Eric Raible <raible@gmail.com>
>
> Trivially-Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> ;-)
>
> More completion support that probably should go to maint, as the
> functionality in git-branch is in 1.5.6 but we (again) forgot to
> make sure the completion was up-to-date prior to release.
I am actually getting more worried about completion code getting larger
and larger without its performance impact not being looked at nor
addressed adequately. In my regular working tree:
$ echo Docu<TAB>
completes "mentation/" instantly, but:
$ git log -- Docu<TAB>
takes about 1.5 to 2 seconds to complete the same.
^ 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