* Re: Draft release notes for 1.5.4 as of -rc1
From: Georgi Chorbadzhiyski @ 2007-12-20 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhciers0o.fsf@gitster.siamese.dyndns.org>
On 12/20/07 04:58, Junio C Hamano wrote:
> * "git peek-remote" is deprecated, as "git ls-remote" was written in C
> and works for all transports, and will be removed in the future.
For me it is not clear from the above which command will be removed. If
I understand it correctly probably this should sound better:
* "git peek-remote" is deprecated and will be removed in the future.
The command was replaced by "git ls-remote" which works for all
transports.
--
Georgi Chorbadzhiyski
http://georgi.unixsol.org/
^ permalink raw reply
* Draft release notes for 1.5.4 as of -rc1
From: Junio C Hamano @ 2007-12-20 2:58 UTC (permalink / raw)
To: git
This one is as of v1.5.4-rc1 which I tagged tonight. It hints that a
set of big change is coming in 1.6.0 without saying if there will be
1.5.5 before that, nor committing to the schedule for 1.6.0 firmly.
Much of the text is unchanged since -rc0 as recent changes to 'master'
have mostly been fixes to regression introduced since 1.5.3. We did not
describe that we introduced regression on purpose, so it is confusing if
we described the regression fixes.
GIT v1.5.4 Release Notes
========================
Removal
-------
* "git svnimport" was removed in favor of "git svn". It is still there
in the source tree (contrib/examples) but unsupported.
* As git-commit and git-status have been rewritten, "git runstatus"
helper script lost all its users and has been removed.
Deprecation notices
-------------------
* Next feature release of git (this change is scheduled for v1.6.0)
will by default install dashed form of commands (e.g. "git-commit")
outside of users' normal $PATH, and will install only selected
commands ("git" itself, and "gitk") in $PATH. This implies:
- Using dashed form of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
dashless form (e.g. "git commit") instead.
- Using dashed from from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- Use of dashed form with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Users are strongly encouraged to adjust their habits and scripts now
to prepare for this.
* The post-receive hook was introduced in March 2007 to supersede
post-update hook, primarily to overcome the command line length
limitation of the latter. Use of post-update hook will be deprecated
in future versions of git, starting from v1.6.0.
* "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
option, and will be removed in the future.
* "git peek-remote" is deprecated, as "git ls-remote" was written in C
and works for all transports, and will be removed in the future.
* From v1.6.0, the repack.usedeltabaseoffset config option will default
to true, which will give denser packfile (i.e. more efficient storage).
The downside is that git older than version 1.4.4 will not be able
to directly use a repository packed using this setting.
* From v1.6.0, the pack.indexversion config option will default to 2,
which is slightly more efficient, and makes repacking more immune to
data corruptions. Git older than version 1.5.2 may revert to version 1
of the pack index with a manual "git index-pack" to be able to directly
access corresponding pack files.
Updates since v1.5.3
--------------------
* Comes with much improved gitk.
* Comes with "git gui" 0.9.1 with i18n.
* gitk is now merged as a subdirectory of git.git project, in
preparation for its i18n.
* progress display from many commands are a lot nicer to the eye.
Transfer commands show throughput data.
* many commands that pay attention to per-directory .gitignore now do
so lazily, which makes the usual case go much faster.
* Output processing for '--pretty=format:<user format>' has been
optimized.
* Rename detection of diff family, while detecting exact matches, has
been greatly optimized.
* Rename detection of diff family tries to make more naturally looking
pairing. Earlier if more than one identical rename sources were
found in the preimage, they were picked pretty much at random.
* Value "true" for color.diff and color.status configuration used to
mean "always" (even when the output is not going to a terminal).
This has been corrected to mean the same thing as "auto".
* "git diff" Porcelain now respects diff.external configuration, which
is another way to specify GIT_EXTERNAL_DIFF.
* HTTP proxy can be specified per remote repository using
remote.*.httpproxy configuration, or global http.proxy configuration
variable.
* Various Perforce importer updates.
* Example update and post-receive hooks have been improved.
* Any command that wants to take a commit object name can now use
":/string" syntax to name a commit.
* "git reset" is now built-in and its output can be squelched with -q.
* "git send-email" can optionally talk over ssmtp and use SMTP-AUTH.
* "git rebase" learned --whitespace option.
* In "git rebase", when you decide not to replay a particular change
after the command stopped with a conflict, you can say "git rebase
--skip" without first running "git reset --hard", as the command now
runs it for you.
* "git rebase --interactive" mode can now work on detached HEAD.
* Other minor to serious bugs in "git rebase -i" has been fixed.
* "git rebase" now detaches head during its operation, so after a
successful "git rebase" operation, the reflog entry branch@{1} for
the current branch points at the commit before the rebase was
started.
* "git rebase -i" also triggers rerere to help your repeated merges.
* "git merge" can call the "post-merge" hook.
* "git pack-objects" can optionally run deltification with multiple
threads.
* "git archive" can optionally substitute keywords in files marked with
export-subst attribute.
* "git cherry-pick" made a misguided attempt to repeat the original
command line in the generated log message, when told to cherry-pick a
commit by naming a tag that points at it. It does not anymore.
* "git for-each-ref" learned %(xxxdate:<dateformat>) syntax to show the
various date fields in different formats.
* "git gc --auto" is a low-impact way to automatically run a variant of
"git repack" that does not lose unreferenced objects (read: safer
than the usual one) after the user accumulates too many loose
objects.
* "git clean" has been rewritten in C.
* You need to explicitly set clean.requireForce to "false" to allow
"git clean" without -f to do any damage (lack of the configuration
variable used to mean "do not require -f option to lose untracked
files", but we now use the safer default).
* The kinds of whitespace errors "git diff" and "git apply" notice (and
fix) can be controlled via 'core.whitespace' configuration variable
and 'whitespace' attribute in .gitattributes file.
* "git push" learned --dry-run option to show what would happen if a
push is run.
* "git push" does not update a tracking ref on the local side when the
remote refused to update the corresponding ref.
* "git push" learned --mirror option. This is to push the local refs
one-to-one to the remote, and deletes refs from the remote that do
not exist anymore in the repository on the pushing side.
* "git push" can remove a corrupt ref at the remote site with the usual
":ref" refspec.
* "git remote" knows --mirror mode. This is to set up configuration to
push into a remote repository to store local branch heads to the same
branch on the remote side, and remove branch heads locally removed
from local repository at the same time. Suitable for pushing into a
back-up repository.
* "git remote" learned "rm" subcommand.
* "git cvsserver" can be run via "git shell".
* "git cvsserver" acts more like receive-pack by running post-receive
and post-update hooks.
* "git am" and "git rebase" are far less verbose.
* "git pull" learned to pass --[no-]ff option to underlying "git
merge".
* "git pull --rebase" is a different way to integrate what you fetched
into your current branch.
* "git fast-export" produces datastream that can be fed to fast-import
to reproduce the history recorded in a git repository.
* "git add -i" takes pathspecs to limit the set of files to work on.
* "git add -p" is a short-hand to go directly to the selective patch
subcommand in the interactive command loop and to exit when done.
* "git add -i" UI has been colorized.
* "git commit --allow-empty" allows you to create a single-parent
commit that records the same tree as its parent, overriding the usual
safety valve.
* "git commit --amend" can amend a merge that does not change the tree
from its first parent.
* "git commit" has been rewritten in C.
* "git stash random-text" does not create a new stash anymore. It was
a UI mistake. Use "git stash save random-text", or "git stash"
(without extra args) for that.
* "git prune --expire <time>" can exempt young loose objects from
getting pruned.
* "git branch --contains <commit>" can list branches that are
descendants of a given commit.
* "git log" learned --early-output option to help interactive GUI
implementations.
* "git bisect" learned "skip" action to mark untestable commits.
* "git bisect visualize" learned a shorter synonym "git bisect view".
* "git bisect visualize" runs "git log" in a non-windowed
environments. It also can be told what command to run (e.g. "git
bisect visualize tig").
* "git format-patch" learned "format.numbered" configuration variable
to automatically turn --numbered option on when more than one commits
are formatted.
* "git ls-files" learned "--exclude-standard" to use the canned set of
exclude files.
* "git tag -a -f existing" begins the editor session using the existing
annotation message.
* "git tag -m one -m bar" (multiple -m options) behaves similarly to
"git commit"; the parameters to -m options are formatted as separate
paragraphs.
* The format "git show" outputs an annotated tag has been updated to
include "Tagger: " and "Date: " lines from the tag itself. Strictly
speaking this is a backward incompatible change, but this is a
reasonable usability fix and people's script shouldn't have been
relying on the exact output from "git show" Porcelain anyway.
* "git cvsexportcommit" learned -w option to specify and switch to the
CVS working directory.
* "git checkout" from a subdirectory learned to use "../path" to allow
checking out a path outside the current directory without cd'ing up.
* "git checkout" from and to detached HEAD leaves a bit more
information in the reflog.
* "git send-email --dry-run" shows full headers for easier diagnosis.
* "git merge-ours" is now built-in.
* "git svn" learned "info" and "show-externals" subcommands.
* "git svn" run from a subdirectory failed to read settings from the
.git/config.
* "git svn" learned --use-log-author option, which picks up more
descriptive name from From: and Signed-off-by: lines in the commit
message.
* "git svn" wasted way too much disk to record revision mappings
between svn and git; a new representation that is much more compact
for this information has been introduced to correct this.
* "git svn" left temporary index files it used without cleaning them
up; this was corrected.
* "git status" from a subdirectory now shows relative paths, which
makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
traditional behaviour to show the full path relative to the top of
the work tree can be had by setting status.relativepaths
configuration variable to true.
* "git blame" kept text for each annotated revision in core needlessly;
this has been corrected.
* "git shortlog" learned to default to HEAD when the standard input is
a terminal and the user did not give any revision parameter.
* "git shortlog" learned "-e" option to show e-mail addresses as well as
authors' names.
* "git help" learned "-w" option to show documentation in browsers.
* In addition there are quite a few internal clean-ups. Notably
- many fork/exec have been replaced with run-command API,
brought from the msysgit effort.
- introduction and more use of the option parser API.
- enhancement and more use of the strbuf API.
Fixes since v1.5.3
------------------
All of the fixes in v1.5.3 maintenance series are included in
this release, unless otherwise noted.
These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance
series.
* The way "git diff --check" behaves is much more consistent with the way
"git apply --whitespace=warn" works.
* "git svn" talking with the SVN over http will correctly quote branch
and project names.
* "git config" did not work correctly on platforms that define
REG_NOMATCH to an even number.
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Wincent Colaiuta @ 2007-12-20 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Charles Bailey, Jeff King, Linus Torvalds, git
In-Reply-To: <7vy7bqrzat.fsf@gitster.siamese.dyndns.org>
El 20/12/2007, a las 1:21, Junio C Hamano escribió:
> Charles Bailey <charles@hashpling.org> writes:
>
>> On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
>> ...
>>> Somebody beat you to it. :) Can you confirm that the fix in
>>>
>>> <1198007158-27576-1-git-send-email-win@wincent.com>
>>>
>>> works for you?
>>
>> Ooh, the excitement, I've never had the opportunity to "git am"
>> before.
>
> Well, if Wincent had sent the patch as plain text without MIME
> quoted-printable, you did not have to even have the excitement of
> running "git am", but a simple "git apply" would have sufficed.
Well, I sent it using "git send-email", so I guess it didn't have MIME
quoted-printable.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Junio C Hamano @ 2007-12-20 1:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dana How, Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0712191334460.23902@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/cache.h b/cache.h
> index 39331c2..83a2c31 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -225,6 +225,7 @@ extern char *get_index_file(void);
> extern char *get_graft_file(void);
> extern int set_git_dir(const char *path);
> extern const char *get_git_work_tree(void);
> +extern const char *get_current_prefix(void);
>
> #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
>
> diff --git a/setup.c b/setup.c
> index b59dbe7..fb9b680 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -3,6 +3,12 @@
>
> static int inside_git_dir = -1;
> static int inside_work_tree = -1;
> +static const char *current_prefix;
> +
> +const char *get_current_prefix()
> +{
> + return current_prefix;
> +}
Didn't you just make libification harder?
^ permalink raw reply
* git rebase -i / git-gui bug
From: Bernt Hansen @ 2007-12-20 0:35 UTC (permalink / raw)
To: Shawn O. Pearce, Johannes Schindelin, Junio C Hamano; +Cc: git
Thanks for a great tool I use everyday!
I'm using the tip of master for my regular day job with git-gui to write
the commit messages. I've run into a little glitch with git rebase -i
and git-gui.
$ git --version
git version 1.5.4.rc0.73.gce85b
I haven't been able to automate the process of reproducing this but the
steps are fairly simple.
To show the problem you can create a test repository using the following
script:
--- t1.sh ---
#!/bin/sh
cd /tmp
mkdir t1
cd t1
git init
for F in f1 f2 f3 f4 f5 f6 f7 f8 f9 f10; do
echo $F >$F
git add $F
echo -n -e "Commit for $F\n\nThis is line one\nThis is line two" >/tmp/commitmsg.txt
git commit -F /tmp/commitmsg.txt
done
-------------
Now cd /tmp/t1 and do the following:
$ git rebase -i HEAD~9
Change all lines with 'pick' to 'edit'
For each of the 10 commits use git-gui to select 'Amend Last Commit' and
just hit the [Commit] button (you can change the text if you want but
it's not necessary to show the problem)
$ git rebase --continue
after each commit and repeat until the rebase is complete.
Now if you try to squash these commits the edit buffer commit text is a
little mangled.
$ git rebase -i HEAD~9
Change all but the first pick line to 'squash' and I get the following
text in the commit message edit window:
----[ /tmp/t1/.git/COMMIT_EDITMSG ]----
# This is a combination of 3 commits.
# The first commit's message is:
Commit for f2
This is line one
This is line two
# This is the 2nd commit message:
Commit for f3
This is line one
This is line two# This is the 3rd commit message:
Commit for f4
This is line one
This is line two# This is the 3rd commit message:
Commit for f5
This is line one
This is line two# This is the 3rd commit message:
Commit for f6
This is line one
This is line two# This is the 3rd commit message:
Commit for f7
This is line one
This is line two# This is the 3rd commit message:
Commit for f8
This is line one
This is line two# This is the 3rd commit message:
Commit for f9
This is line one
This is line two# This is the 3rd commit message:
Commit for f10
This is line one
This is line two
# Please enter the commit message for your changes.
# (Comment lines starting with '#' will not be included)
# Not currently on any branch.
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: f10
# new file: f2
# new file: f3
# new file: f4
# new file: f5
# new file: f6
# new file: f7
# new file: f8
# new file: f9
#
---------------------------------------
Notice after the 3rd commit the '# This is the 3rd commit message:' is
appended to the last line of the previous commit message and the counter
seems to be stuck on 3.
---
When I run into this during work I fix up the commit text by adding
newlines before the '# This is the 3rd commit message' and it works
fine.
This might be the lack of a newline after the last line in the commit
edit message when git-gui creates the commit -- maybe.
If I use git --amend instead of git-gui to update the commits on the
above test repository it works correctly.
I'm posting this because someone else can probably fix this faster than
me (I've never looked at the git source code). I'll post a patch when I
figure it out if nobody else beats me to it.
Regards,
Bernt
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Junio C Hamano @ 2007-12-20 0:21 UTC (permalink / raw)
To: Charles Bailey; +Cc: Wincent Colaiuta, Jeff King, Linus Torvalds, git
In-Reply-To: <20071219143712.GA3483@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
> ...
>> Somebody beat you to it. :) Can you confirm that the fix in
>>
>> <1198007158-27576-1-git-send-email-win@wincent.com>
>>
>> works for you?
>
> Ooh, the excitement, I've never had the opportunity to "git am"
> before.
Well, if Wincent had sent the patch as plain text without MIME
quoted-printable, you did not have to even have the excitement of
running "git am", but a simple "git apply" would have sufficed.
...
How about the following? This swaps in perl in place of sed, which we c=
an
hopefully rely upon to work across platforms.
Cheers,
Wincent
-------- 8< --------
=46ix tests for broken sed on Leopard
The newly-added common-tail-optimization test fails on Leopard because
the broken sed implementation bails with a spurious "unterminated
substitute pattern" error because of the length of one of the
arguments.
Just for future reference, I do not mind avoiding "top-post" style patch
using "-- >8 --" cut markers, but do not have three or more dashes in
the cut marker. "mailinfo" will split the message at that line and the
portion intended as the proposed commit log message will be taken as
part of garbage in front of the patch. Using "-- >8 --" (two dashes,
space, scissors, ...) keeps both the front matter and the log text
together so that "am -i" or "commit --amend" can work on both parts.
By the way, how does this rewrite look?
-- >8 --
t4024: fix test script to use simpler sed pattern
The earlier test stripped away expected number of 'z' but the output
would have been very hard to read once somebody broke the common tail
optimization. Instead, count the number of 'z' and show it, to help
diagnosing the problem better in the future.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4024-diff-optimize-common.sh | 158 ++++++++++++++++++++++++++++++---------
1 files changed, 123 insertions(+), 35 deletions(-)
diff --git a/t/t4024-diff-optimize-common.sh b/t/t4024-diff-optimize-common.sh
index 20fe87b..3c66102 100755
--- a/t/t4024-diff-optimize-common.sh
+++ b/t/t4024-diff-optimize-common.sh
@@ -10,58 +10,146 @@ z="$z$z$z$z$z$z$z$z" ;# 512
z="$z$z$z$z" ;# 2048
z2047=$(expr "$z" : '.\(.*\)') ; #2047
-test_expect_success setup '
-
- echo "a$z2047" >file-a &&
- echo "b" >file-b &&
- echo "$z2047" >>file-b &&
- echo "c$z2047" | tr -d "\012" >file-c &&
- echo "d" >file-d &&
- echo "$z2047" | tr -d "\012" >>file-d &&
+x=zzzzzzzzzz ;# 10
+y="$x$x$x$x$x$x$x$x$x$x" ;# 100
+z="$y$y$y$y$y$y$y$y$y$y" ;# 1000
+z1000=$z
+z100=$y
+z10=$x
- git add file-a file-b file-c file-d &&
+zs() {
+ count="$1"
+ while test "$count" -ge 1000
+ do
+ count=$(($count - 1000))
+ printf "%s" $z1000
+ done
+ while test "$count" -ge 100
+ do
+ count=$(($count - 100))
+ printf "%s" $z100
+ done
+ while test "$count" -ge 10
+ do
+ count=$(($count - 10))
+ printf "%s" $z10
+ done
+ while test "$count" -ge 1
+ do
+ count=$(($count - 1))
+ printf "z"
+ done
+}
- echo "A$z2047" >file-a &&
- echo "B" >file-b &&
- echo "$z2047" >>file-b &&
- echo "C$z2047" | tr -d "\012" >file-c &&
- echo "D" >file-d &&
- echo "$z2047" | tr -d "\012" >>file-d
-
-'
+zc () {
+ sed -e "/^index/d" \
+ -e "s/$z1000/Q/g" \
+ -e "s/QQQQQQQQQ/Z9000/g" \
+ -e "s/QQQQQQQQ/Z8000/g" \
+ -e "s/QQQQQQQ/Z7000/g" \
+ -e "s/QQQQQQ/Z6000/g" \
+ -e "s/QQQQQ/Z5000/g" \
+ -e "s/QQQQ/Z4000/g" \
+ -e "s/QQQ/Z3000/g" \
+ -e "s/QQ/Z2000/g" \
+ -e "s/Q/Z1000/g" \
+ -e "s/$z100/Q/g" \
+ -e "s/QQQQQQQQQ/Z900/g" \
+ -e "s/QQQQQQQQ/Z800/g" \
+ -e "s/QQQQQQQ/Z700/g" \
+ -e "s/QQQQQQ/Z600/g" \
+ -e "s/QQQQQ/Z500/g" \
+ -e "s/QQQQ/Z400/g" \
+ -e "s/QQQ/Z300/g" \
+ -e "s/QQ/Z200/g" \
+ -e "s/Q/Z100/g" \
+ -e "s/000Z//g" \
+ -e "s/$z10/Q/g" \
+ -e "s/QQQQQQQQQ/Z90/g" \
+ -e "s/QQQQQQQQ/Z80/g" \
+ -e "s/QQQQQQQ/Z70/g" \
+ -e "s/QQQQQQ/Z60/g" \
+ -e "s/QQQQQ/Z50/g" \
+ -e "s/QQQQ/Z40/g" \
+ -e "s/QQQ/Z30/g" \
+ -e "s/QQ/Z20/g" \
+ -e "s/Q/Z10/g" \
+ -e "s/00Z//g" \
+ -e "s/z/Q/g" \
+ -e "s/QQQQQQQQQ/Z9/g" \
+ -e "s/QQQQQQQQ/Z8/g" \
+ -e "s/QQQQQQQ/Z7/g" \
+ -e "s/QQQQQQ/Z6/g" \
+ -e "s/QQQQQ/Z5/g" \
+ -e "s/QQQQ/Z4/g" \
+ -e "s/QQQ/Z3/g" \
+ -e "s/QQ/Z2/g" \
+ -e "s/Q/Z1/g" \
+ -e "s/0Z//g" \
+ ;
+}
-cat >expect <<\EOF
-diff --git a/file-a b/file-a
---- a/file-a
-+++ b/file-a
+expect_pattern () {
+ cnt="$1"
+ cat <<EOF
+diff --git a/file-a$cnt b/file-a$cnt
+--- a/file-a$cnt
++++ b/file-a$cnt
@@ -1 +1 @@
--aZ
-+AZ
-diff --git a/file-b b/file-b
---- a/file-b
-+++ b/file-b
+-Z${cnt}a
++Z${cnt}A
+diff --git a/file-b$cnt b/file-b$cnt
+--- a/file-b$cnt
++++ b/file-b$cnt
@@ -1 +1 @@
-b
+B
-diff --git a/file-c b/file-c
---- a/file-c
-+++ b/file-c
+diff --git a/file-c$cnt b/file-c$cnt
+--- a/file-c$cnt
++++ b/file-c$cnt
@@ -1 +1 @@
--cZ
+-cZ$cnt
\ No newline at end of file
-+CZ
++CZ$cnt
\ No newline at end of file
-diff --git a/file-d b/file-d
---- a/file-d
-+++ b/file-d
+diff --git a/file-d$cnt b/file-d$cnt
+--- a/file-d$cnt
++++ b/file-d$cnt
@@ -1 +1 @@
-d
+D
EOF
+}
+
+sample='1023 1024 1025 2047 4095'
+
+test_expect_success setup '
+
+ for n in $sample
+ do
+ ( zs $n ; echo a ) >file-a$n &&
+ ( echo b; zs $n; echo ) >file-b$n &&
+ ( printf c; zs $n ) >file-c$n &&
+ ( echo d; zs $n ) >file-d$n &&
+
+ git add file-a$n file-b$n file-c$n file-d$n &&
+
+ ( zs $n ; echo A ) >file-a$n &&
+ ( echo B; zs $n; echo ) >file-b$n &&
+ ( printf C; zs $n ) >file-c$n &&
+ ( echo D; zs $n ) >file-d$n &&
+
+ expect_pattern $n || break
+
+ done >expect
+'
test_expect_success 'diff -U0' '
- git diff -U0 | sed -e "/^index/d" -e "s/$z2047/Z/g" >actual &&
+ for n in $sample
+ do
+ git diff -U0 file-?$n
+ done | zc >actual &&
diff -u expect actual
'
^ permalink raw reply related
* Re: more than 20 commands in everyday.txt
From: Junio C Hamano @ 2007-12-20 0:15 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071219225618.GA7378@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> "every day". of course it may be only me, that's why i ask. here are the
> commands i rarely use and are in everyday.txt:
>
> - git-prune and git-repack: usually i use git-gc only. maybe prune and
> repack could be removed from everyday.txt?
>
> - git-show-branch: what about mentioning gitk instead? i think it's much
> more used - compared to git-show-branch
>
> what do you think about this? maybe i'm wrong, but if i'm right, then i
> would provide a patch to update everyday.txt according to these
> suggestions.
I think you would probably get unanimous yes for the former (I don't use
gc myself but "repack -a -d" or "repack -a -d -f" regularly, though ---
I am old fashioned and do not mind being counted as an oddball).
For the latter it all depends on whether you are in windowed environment
(I usually don't).
^ permalink raw reply
* Re: Git-to-svn convert
From: Martin Langhoff @ 2007-12-19 23:54 UTC (permalink / raw)
To: Thomas Harning; +Cc: Junio C Hamano, git, Andrew McMillan
In-Reply-To: <476997C1.2080506@gmail.com>
Hi Thomas,
I think Andrew McMillan had written a few scripts to "export" a git
repo to SVN and CVS. Not sure whether the code is public. But at least
for a while, the Mahara project was using git with SVN and CVS
"readonly" exported repos, a bit like the BK->CVS of yore. He may have
been using git-svn though.
cheers,
martin
^ permalink raw reply
* Re: kha/safe updated
From: Catalin Marinas @ 2007-12-19 23:29 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, David Kågedal
In-Reply-To: <20071219232614.GA16246@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-19 23:17:42 +0000, Catalin Marinas wrote:
>
> > On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > And with that, I don't see any reason to not recommend that you
> > > pull every patch I have. Which is:
> >
> > Please rebase again when you have time since I already merged most
> > of this branch and added some patches that might conflict with
> > yours.
>
> You hadn't pushed any of it out when I last checked about two hours
> ago ...
I just pushed the changes a few minutes ago.
> Will do, but not tonight. In fact, it may be a few days, I'm afraid.
No problem. Anyway, if I don't here from you in the meantime, have a
good Christmas :-).
--
Catalin
^ permalink raw reply
* Re: kha/safe updated
From: Karl Hasselström @ 2007-12-19 23:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <b0943d9e0712191517r6154f6c2g98068c8070275cb3@mail.gmail.com>
On 2007-12-19 23:17:42 +0000, Catalin Marinas wrote:
> On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > And with that, I don't see any reason to not recommend that you
> > pull every patch I have. Which is:
>
> Please rebase again when you have time since I already merged most
> of this branch and added some patches that might conflict with
> yours.
You hadn't pushed any of it out when I last checked about two hours
ago ...
Will do, but not tonight. In fact, it may be a few days, I'm afraid.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: René Scharfe @ 2007-12-19 23:23 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alex Riesen, git
In-Reply-To: <57518fd10712191437s6f192feds50d006fdfc624444@mail.gmail.com>
Jonathan del Strother schrieb:
> On Dec 19, 2007 6:44 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
>> Could you try
>>
>> git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b
>>
>> (or any other problematic commit) and post its output here?
>
> You mean git cat-file commit ... ?
> I get the normal output, but the problematic commits don't show a
> newline character at the end of the cat-file output.
Just a shot in the dark: does this patch on top of master make a difference?
diff --git a/pretty.c b/pretty.c
index 9db75b4..5f95a59 100644
--- a/pretty.c
+++ b/pretty.c
@@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)
if (i == eol) {
state++;
/* strip empty lines */
- while (msg[eol + 1] == '\n')
+ while (msg[eol] == '\n' && msg[eol + 1] == '\n')
eol++;
} else if (!prefixcmp(msg + i, "author ")) {
context->author.off = i + 7;
^ permalink raw reply related
* Re: kha/safe updated
From: David Kågedal @ 2007-12-19 23:24 UTC (permalink / raw)
To: Catalin Marinas, Karl Hasselström; +Cc: git
In-Reply-To: <20071219224638.GB15119@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-12-19 23:24:49 +0100, Karl Hasselström wrote:
>
>> And here it is!
>
> And with that, I don't see any reason to not recommend that you pull
> every patch I have. Which is:
The conflict series of patches from me works for me, but I know that I
don't use all the merging features that other users use, so I can't
guarantee that everything works. But it seems that Catalin has been
looking over it, so I guess it's ok.
--
David Kågedal
^ permalink raw reply
* [PATCH] builtin-tag.c: allow arguments in $EDITOR
From: Luciano Rocha @ 2007-12-19 23:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
The previous sh version of git-commit evaluated the value of the defined
editor, thus allowing arguments.
Make the builtin version work the same, by adding an explicit check for
arguments in the editor command, and extract them to an additional argument.
Signed-off-by: Luciano Rocha <luciano@eurotux.com>
---
builtin-tag.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
I personally use EDITOR="gvim -f", thus this patch.
Created on top of ce85b053d827e2f7c2ee2683cc09393e4768cc22,
git-describe is now: v1.5.4-rc0-75-g5f791e5
diff --git a/builtin-tag.c b/builtin-tag.c
index 274901a..57dcfe0 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -46,7 +46,18 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
if (!editor)
editor = "vi";
- if (strcmp(editor, ":")) {
+ if (strstr(editor, " -")) {
+ char *editor_cmd = xstrdup(editor);
+ char *editor_sep = strstr(editor_cmd, " -");
+ const char *args[] = { editor_cmd, editor_sep + 1,
+ path, NULL };
+
+ *editor_sep = '\0';
+
+ if (run_command_v_opt_cd_env(args, 0, NULL, env))
+ die("There was a problem with the editor %s.",
+ editor_cmd);
+ } else if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
if (run_command_v_opt_cd_env(args, 0, NULL, env))
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: more than 20 commands in everyday.txt
From: Jakub Narebski @ 2007-12-19 23:23 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071219225618.GA7378@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> this might seem to be a bit bikesheding, but i hope it isn't. today i
> teched git to someone who never used any scm so far. i showed him the
> "everyday with git" document, as i think it's a great start for newbies.
> actually i read it once but it was in the past, now i did it again and i
> think there are some commands listed there which is not something we use
> "every day". of course it may be only me, that's why i ask. here are the
> commands i rarely use and are in everyday.txt:
>
> - git-prune and git-repack: usually i use git-gc only. maybe prune and
> repack could be removed from everyday.txt?
I agree that git-repack should be removed (there is git-gc), and
git-prune should be replaced by mentioning --prune option to git-gc.
This document is for newbies, and they shouldn't need to run anything
other than git-gc.
Besides with new enough git the number of generated loose objects
should be greatly reduced: git now produces (small) packs if
possible.
I'm not sure if mentioning git-fsck at all, or at least this early is
a good idea for introductory tutorial. Running git-fsck should be
rare, very rare.
> - git-show-branch: what about mentioning gitk instead? i think it's much
> more used - compared to git-show-branch
I would replace git-show-branch by git-show as command to see where
you are. and add gitk (which has now manpage) to view history.
git-show-branch output is a bit cryptic...
Perhaps we could add git-reflog / "git log -g" somewhere around?
> what do you think about this? maybe i'm wrong, but if i'm right, then i
> would provide a patch to update everyday.txt according to these
> suggestions.
I'd like this. At least the first one is unambiguous.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: kha/safe updated
From: Catalin Marinas @ 2007-12-19 23:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, David Kågedal
In-Reply-To: <20071219224638.GB15119@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-19 23:24:49 +0100, Karl Hasselström wrote:
>
> > And here it is!
>
> And with that, I don't see any reason to not recommend that you pull
> every patch I have. Which is:
Please rebase again when you have time since I already merged most of
this branch and added some patches that might conflict with yours.
--
Catalin
^ permalink raw reply
* Re: Git-to-svn convert
From: Miklos Vajna @ 2007-12-19 23:16 UTC (permalink / raw)
To: Thomas Harning; +Cc: Junio C Hamano, git
In-Reply-To: <476997C1.2080506@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
On Wed, Dec 19, 2007 at 05:14:25PM -0500, Thomas Harning <harningt@gmail.com> wrote:
> Example of what I mean...:
>
> a - b -
> `c'
>
>
> As to how to pull the repository into subversion.. how would I do that?
> git-svn init ?
i think you have two options:
- use some 3rd-party tool like tailor
- first you should rewrite your history by creating a linear history
then git-svn can dcommit your changes to svn
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* more than 20 commands in everyday.txt
From: Miklos Vajna @ 2007-12-19 22:56 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
hi,
this might seem to be a bit bikesheding, but i hope it isn't. today i
teched git to someone who never used any scm so far. i showed him the
"everyday with git" document, as i think it's a great start for newbies.
actually i read it once but it was in the past, now i did it again and i
think there are some commands listed there which is not something we use
"every day". of course it may be only me, that's why i ask. here are the
commands i rarely use and are in everyday.txt:
- git-prune and git-repack: usually i use git-gc only. maybe prune and
repack could be removed from everyday.txt?
- git-show-branch: what about mentioning gitk instead? i think it's much
more used - compared to git-show-branch
what do you think about this? maybe i'm wrong, but if i'm right, then i
would provide a patch to update everyday.txt according to these
suggestions.
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* kha/safe updated
From: Karl Hasselström @ 2007-12-19 22:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071219221957.29455.27315.stgit@yoghurt>
On 2007-12-19 23:24:49 +0100, Karl Hasselström wrote:
> And here it is!
And with that, I don't see any reason to not recommend that you pull
every patch I have. Which is:
The following changes since commit 5be69cd8d89bd89be31364e9c0fd9e947b6ef644:
Karl Hasselström (1):
Name the exit codes to improve legibility
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
David Kågedal (19):
Add an StGit mode for emacs
Emacs mode: Improve the output buffer state
Emacs mode: Bind n and p
Emacs mode: add stgit-repair
Emacs mode: added stgit-commit and stgit-uncommit
Emacs mode: Add stgit-edit command
Emacs mode: added fontification
Emacs mode: Added stgit-new
Check bottom and invariants
Remove the 'bottom' field
Remove the 'top' field
Split git.merge into two functions
Leave working dir and index alone after failed (conflicting) push
Added a test case to check what happens when push finds a conflict
Simplify merge_recursive
Use the output from merge-recursive to list conflicts
Ask git about unmerged files
Emacs mode: Add mark command
Emacs mode: coalesce command
Karl Hasselström (36):
Emacs mode: Show keybindings when user presses "h" or "?"
Emacs mode: Add an explanatory header
Emacs mode: Makefile for building stgit.el
Emacs mode: push/pop next patch, not patch at point
Emacs mode: Let "P" push or pop patch at point
Emacs mode: Bind "G" to "stg goto"
Emacs mode: show patches' short description
Write removed fields for backwards compatibility
Nicer conflict markers
Better error message if merge fails
Fix "stg resolved" to work with new conflict representation
Refactoring: pass more than one file to resolved()
We keep the different stages of a conflict in the index now
"stg status --reset" is not needed anymore
Remove "stg add"
Remove "stg rm"
Remove "stg cp"
Remove "stg resolved"
New StGit core infrastructure: repository operations
Write metadata files used by the old infrastructure
Upgrade older stacks to newest version
Let "stg clean" use the new infrastructure
Add "stg coalesce"
Let "stg applied" and "stg unapplied" use the new infrastructure
Teach the new infrastructure about the index and worktree
Let "stg clean" use the new transaction primitives
Let "stg goto" use the new infrastructure
Convert "stg uncommit" to the new infrastructure
New infrastructure: Make sure that the branch is initialized
Expose transaction abort function
stg coalesce: Support --file and --save-template
Set exit code to 3 on merge conflict
Convert "stg commit" to new infrastructure
Make "stg commit" fancier
Test that "stg goto" can be called from a subdirectory
Make "stg goto" subdirectory safe
Documentation/stg-cp.txt | 63 -------
Documentation/stg.txt | 2 -
Documentation/tutorial.txt | 31 ++--
contrib/Makefile | 19 ++
contrib/stgit-completion.bash | 4 +-
contrib/stgit.el | 377 +++++++++++++++++++++++++++++++++++++++
examples/gitconfig | 19 +--
setup.py | 2 +-
stgit/commands/add.py | 44 -----
stgit/commands/applied.py | 27 ++--
stgit/commands/clean.py | 49 ++----
stgit/commands/coalesce.py | 122 +++++++++++++
stgit/commands/commit.py | 111 ++++++++-----
stgit/commands/common.py | 39 ++---
stgit/commands/copy.py | 45 -----
stgit/commands/goto.py | 52 ++----
stgit/commands/pick.py | 2 +-
stgit/commands/resolved.py | 94 ----------
stgit/commands/rm.py | 48 -----
stgit/commands/status.py | 31 ++--
stgit/commands/sync.py | 1 -
stgit/commands/unapplied.py | 23 ++--
stgit/commands/uncommit.py | 81 ++++-----
stgit/config.py | 1 -
stgit/git.py | 75 +++++---
stgit/gitmergeonefile.py | 97 +----------
stgit/lib/__init__.py | 18 ++
stgit/lib/git.py | 388 +++++++++++++++++++++++++++++++++++++++++
stgit/lib/stack.py | 176 +++++++++++++++++++
stgit/lib/stackupgrade.py | 98 +++++++++++
stgit/lib/transaction.py | 209 ++++++++++++++++++++++
stgit/main.py | 14 +-
stgit/run.py | 12 +-
stgit/stack.py | 156 ++++-------------
stgit/utils.py | 25 +++
t/t0002-status.sh | 15 +-
t/t1200-push-modified.sh | 2 +-
t/t1202-push-undo.sh | 6 +-
t/t1203-push-conflict.sh | 70 ++++++++
t/t1204-pop-keep.sh | 2 +-
t/t1205-push-subdir.sh | 8 +-
t/t1300-uncommit.sh | 16 +-
t/t1301-repair.sh | 2 +-
t/t1400-patch-history.sh | 4 +-
t/t1500-float.sh | 14 +-
t/t1600-delete-one.sh | 12 +-
t/t1601-delete-many.sh | 2 +-
t/t1700-goto-top.sh | 2 +-
t/t2000-sync.sh | 12 +-
t/t2100-pull-policy-fetch.sh | 4 +-
t/t2101-pull-policy-pull.sh | 4 +-
t/t2102-pull-policy-rebase.sh | 4 +-
t/t2300-refresh-subdir.sh | 2 +-
t/t2600-coalesce.sh | 31 ++++
t/t2800-goto-subdir.sh | 59 ++++++
55 files changed, 1959 insertions(+), 867 deletions(-)
delete mode 100644 Documentation/stg-cp.txt
create mode 100644 contrib/Makefile
create mode 100644 contrib/stgit.el
delete mode 100644 stgit/commands/add.py
create mode 100644 stgit/commands/coalesce.py
delete mode 100644 stgit/commands/copy.py
delete mode 100644 stgit/commands/resolved.py
delete mode 100644 stgit/commands/rm.py
create mode 100644 stgit/lib/__init__.py
create mode 100644 stgit/lib/git.py
create mode 100644 stgit/lib/stack.py
create mode 100644 stgit/lib/stackupgrade.py
create mode 100644 stgit/lib/transaction.py
create mode 100755 t/t1203-push-conflict.sh
create mode 100755 t/t2600-coalesce.sh
create mode 100755 t/t2800-goto-subdir.sh
kha/experimental points to the same commit as kha/safe, for now.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-19 22:37 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071219184457.GC3015@steel.home>
On Dec 19, 2007 6:44 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Could you try
>
> git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b
>
> (or any other problematic commit) and post its output here?
You mean git cat-file commit ... ?
I get the normal output, but the problematic commits don't show a
newline character at the end of the cat-file output.
> Or is the repo publised somewhere?
Afraid not - it's private code.
I'll try bisecting e52a5de tomorrow, see if that gets me anywhere.
^ permalink raw reply
* Re: [StGit PATCH 0/2] Make new infrastructure subdirectory safe
From: Karl Hasselström @ 2007-12-19 22:28 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071219221848.29455.50676.stgit@yoghurt>
On 2007-12-19 23:19:23 +0100, Karl Hasselström wrote:
> Karl Hasselström (2):
> Make "stg goto" subdirectory safe
> Test that "stg goto" can be called from a subdirectory
I forgot to say, but this goes on top of kha/experimental. The test
makes use of the "return exit code 3 when there was conflicts" patch
to make sure that there was a conflict and not another error.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH 2/2] Make "stg goto" subdirectory safe
From: Karl Hasselström @ 2007-12-19 22:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071219221848.29455.50676.stgit@yoghurt>
This is not specific to "stg goto" -- it affects all commands that use
the new infrastructure. (But of those, only goto and coalesce were
subdirectory unsafe.)
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
On 2007-12-18 10:24:19 +0100, Karl Hasselström wrote:
> On 2007-12-18 09:11:00 +0000, Catalin Marinas wrote:
>
> > On 17/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > Be careful about merging past the "goto" patch -- I'm pretty
> > > sure it breaks when called from a subdirectory, and I don't have
> > > time to fix that right now. (It should be a clean fix, though --
> > > just adjust the cwd for precisely those git subprocesses that
> > > need it, which is very few. I think.)
> >
> > Why not just change the cwd when the command starts and it should
> > be safe for all the git subprocesses.
>
> It doesn't feel very clean to require the caller of some unspecified
> subset of git calls to remember to set the correct piece of global
> state.
>
> And the correct solution should really be very simple, since it's
> precisely the worktree operations (specifically, the subset thereof
> that have to operate on the whole tree) that require setting cwd.
> And those are very clearly separated out from the rest in the new
> infrastructure.
And here it is! Note that not counting the cwd support in run.py and
changing the test to expect success, I had to change just three lines
to fix this problem for _all_ "new infrastructure" commands. And no
unintended side effects, since the cwd is changed only where it's
necessary.
stgit/lib/git.py | 5 +++--
stgit/run.py | 9 ++++++---
t/t2800-goto-subdir.sh | 4 ++--
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index 6aba966..118c9b2 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -344,6 +344,7 @@ class Worktree(object):
def __init__(self, directory):
self.__directory = directory
env = property(lambda self: { 'GIT_WORK_TREE': self.__directory })
+ directory = property(lambda self: self.__directory)
class CheckoutException(exception.StgException):
pass
@@ -364,7 +365,7 @@ class IndexAndWorktree(RunWithEnv):
self.run(['git', 'read-tree', '-u', '-m',
'--exclude-per-directory=.gitignore',
old_tree.sha1, new_tree.sha1]
- ).discard_output()
+ ).cwd(self.__worktree.directory).discard_output()
except run.RunException:
raise CheckoutException('Index/workdir dirty')
def merge(self, base, ours, theirs):
@@ -377,7 +378,7 @@ class IndexAndWorktree(RunWithEnv):
env = { 'GITHEAD_%s' % base.sha1: 'ancestor',
'GITHEAD_%s' % ours.sha1: 'current',
'GITHEAD_%s' % theirs.sha1: 'patched'}
- ).discard_output()
+ ).cwd(self.__worktree.directory).discard_output()
except run.RunException, e:
raise MergeException('Index/worktree dirty')
def changed_files(self):
diff --git a/stgit/run.py b/stgit/run.py
index 78537db..77f2e65 100644
--- a/stgit/run.py
+++ b/stgit/run.py
@@ -42,7 +42,7 @@ class Run:
if type(c) != str:
raise Exception, 'Bad command: %r' % (cmd,)
self.__good_retvals = [0]
- self.__env = None
+ self.__env = self.__cwd = None
self.__indata = None
self.__discard_stderr = False
def __log_start(self):
@@ -67,7 +67,7 @@ class Run:
"""Run with captured IO."""
self.__log_start()
try:
- p = subprocess.Popen(self.__cmd, env = self.__env,
+ p = subprocess.Popen(self.__cmd, env = self.__env, cwd = self.__cwd,
stdin = subprocess.PIPE,
stdout = subprocess.PIPE,
stderr = subprocess.PIPE)
@@ -85,7 +85,7 @@ class Run:
assert self.__indata == None
self.__log_start()
try:
- p = subprocess.Popen(self.__cmd, env = self.__env)
+ p = subprocess.Popen(self.__cmd, env = self.__env, cwd = self.__cwd)
self.exitcode = p.wait()
except OSError, e:
raise self.exc('%s failed: %s' % (self.__cmd[0], e))
@@ -104,6 +104,9 @@ class Run:
self.__env = dict(os.environ)
self.__env.update(env)
return self
+ def cwd(self, cwd):
+ self.__cwd = cwd
+ return self
def raw_input(self, indata):
self.__indata = indata
return self
diff --git a/t/t2800-goto-subdir.sh b/t/t2800-goto-subdir.sh
index 9f3ab26..fcad7da 100755
--- a/t/t2800-goto-subdir.sh
+++ b/t/t2800-goto-subdir.sh
@@ -24,7 +24,7 @@ EOF
cat > expected2.txt <<EOF
bar
EOF
-test_expect_failure 'Goto in subdirectory (just pop)' '
+test_expect_success 'Goto in subdirectory (just pop)' '
(cd foo && stg goto p1) &&
cat foo/bar > actual.txt &&
diff -u expected1.txt actual.txt &&
@@ -47,7 +47,7 @@ EOF
cat > expected2.txt <<EOF
bar
EOF
-test_expect_failure 'Goto in subdirectory (conflicting push)' '
+test_expect_success 'Goto in subdirectory (conflicting push)' '
(cd foo && stg goto p3) ;
[ $? -eq 3 ] &&
cat foo/bar > actual.txt &&
^ permalink raw reply related
* [StGit PATCH 1/2] Test that "stg goto" can be called from a subdirectory
From: Karl Hasselström @ 2007-12-19 22:19 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071219221848.29455.50676.stgit@yoghurt>
It currently can't; therefore, the tests are marked as known failures.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t2800-goto-subdir.sh | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
create mode 100755 t/t2800-goto-subdir.sh
diff --git a/t/t2800-goto-subdir.sh b/t/t2800-goto-subdir.sh
new file mode 100755
index 0000000..9f3ab26
--- /dev/null
+++ b/t/t2800-goto-subdir.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+
+test_description='Run "stg goto" in a subdirectory'
+
+. ./test-lib.sh
+
+test_expect_success 'Initialize StGit stack' '
+ stg init &&
+ echo expected1.txt >> .git/info/exclude &&
+ echo expected2.txt >> .git/info/exclude &&
+ echo actual.txt >> .git/info/exclude &&
+ mkdir foo &&
+ for i in 1 2 3; do
+ echo foo$i >> foo/bar &&
+ stg new p$i -m p$i &&
+ git add foo/bar &&
+ stg refresh
+ done
+'
+
+cat > expected1.txt <<EOF
+foo1
+EOF
+cat > expected2.txt <<EOF
+bar
+EOF
+test_expect_failure 'Goto in subdirectory (just pop)' '
+ (cd foo && stg goto p1) &&
+ cat foo/bar > actual.txt &&
+ diff -u expected1.txt actual.txt &&
+ ls foo > actual.txt &&
+ diff -u expected2.txt actual.txt
+'
+
+test_expect_success 'Prepare conflicting goto' '
+ stg delete p2
+'
+
+cat > expected1.txt <<EOF
+foo1
+<<<<<<< current:foo/bar
+=======
+foo2
+foo3
+>>>>>>> patched:foo/bar
+EOF
+cat > expected2.txt <<EOF
+bar
+EOF
+test_expect_failure 'Goto in subdirectory (conflicting push)' '
+ (cd foo && stg goto p3) ;
+ [ $? -eq 3 ] &&
+ cat foo/bar > actual.txt &&
+ diff -u expected1.txt actual.txt &&
+ ls foo > actual.txt &&
+ diff -u expected2.txt actual.txt
+'
+
+test_done
^ permalink raw reply related
* [StGit PATCH 0/2] Make new infrastructure subdirectory safe
From: Karl Hasselström @ 2007-12-19 22:19 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071218092419.GA16029@diana.vm.bytemark.co.uk>
---
Karl Hasselström (2):
Make "stg goto" subdirectory safe
Test that "stg goto" can be called from a subdirectory
stgit/lib/git.py | 5 ++--
stgit/run.py | 9 +++++--
t/t2800-goto-subdir.sh | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 68 insertions(+), 5 deletions(-)
create mode 100755 t/t2800-goto-subdir.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Git-to-svn convert
From: Thomas Harning @ 2007-12-19 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Is there a reasonable way to convert a Git project to Subversion...
Yeah, I know, blasphemy :-P... but I worked on a project in Git and my
boss wants me to put it into Subversion.
git-svn looks to be the tool for this.. however I had some non-linear
dev, which doesn't look like it'd commit (In the past I think I tried
this and it failed to deal w/ a branch-and-merge...).
Example of what I mean...:
a - b -
`c'
As to how to pull the repository into subversion.. how would I do that?
git-svn init ?
^ permalink raw reply
* Re: [PATCH] Fix interactive rebase to preserve author email address
From: Haavard Skinnemoen @ 2007-12-19 22:11 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP022BE21217030117EF2156AE5C0@CEZ.ICE>
On Wed, 19 Dec 2007 16:34:27 -0500
Sean <seanlkml@sympatico.ca> wrote:
> This simple typo fix should hopefully make it work for you Haavard.
It does indeed. Thanks!
Haavard
^ 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