* [PATCH] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-12-03 5:27 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <7vtz9vk6uj.fsf@gitster.siamese.dyndns.org>
* Before interpretting an upward path (../) in cd_to_toplevel,
cd to a path without symlinks given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus constrasting
scenarios that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
I hope this patch will address concerns both about changes
to existing APIs and speed of the new behavior.
A few notes on implementation choices:
I used /bin/pwd because of this precedent for choosing it over
"cd -P" for compatibility.
http://article.gmane.org/gmane.comp.version-control.git/46918
If cd_to_toplevel had concatenated $(/bin/pwd) with $cdup to
avoid the separate "cd", it would require checking for $cdup
being an absolute path. I wasn't sure how to check that in
a way that is both portable and clearly faster than "cd",
so cd_to_toplevel runs "cd" twice. I'm assuming that
running an external command like expr or grep is slower than
just doing the "cd".
cd_to_toplevel doesn't check $PWD to see whether to do the
first cd, because some shells allegedly don't update it
reliably.
Since cd_to_toplevel doesn't know whether it's at a
symlinked PWD or not, I wrote it to treat the
"cd $(/bin/pwd)" as mandatory, even when it might not
actually be. So on systems without /bin/pwd, it will fail
even when there are no symlinks. I thought that was better
than inconsistent behavior depending on whether /bin/pwd is
available.
The extra "cd" will be skipped when the script is already at
the top of the working tree.
git-sh-setup.sh | 11 +++++++
t/t2300-cd-to-toplevel.sh | 37 +++++++++++++++++++++++++
t/t5521-pull-symlink.sh | 67 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 115 insertions(+), 0 deletions(-)
create mode 100755 t/t2300-cd-to-toplevel.sh
create mode 100755 t/t5521-pull-symlink.sh
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbdf209..377700b 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -85,6 +85,17 @@ cd_to_toplevel () {
cdup=$(git rev-parse --show-cdup)
if test ! -z "$cdup"
then
+ # Interpret $cdup relative to the physical, not logical, cwd.
+ # Probably /bin/pwd is more portable than passing -P to cd or pwd.
+ phys="$(/bin/pwd)" || {
+ echo >&2 "Cannot determine the physical path to the current dir"
+ exit 1
+ }
+ cd "$phys" || {
+ echo >&2 "Cannot chdir to the physical path to current dir: $phys"
+ exit 1
+ }
+
cd "$cdup" || {
echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
exit 1
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
new file mode 100755
index 0000000..293dc35
--- /dev/null
+++ b/t/t2300-cd-to-toplevel.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='cd_to_toplevel'
+
+. ./test-lib.sh
+
+test_cd_to_toplevel () {
+ test_expect_success "$2" '
+ (
+ cd '"'$1'"' &&
+ . git-sh-setup &&
+ cd_to_toplevel &&
+ [ "$(pwd -P)" = "$TOPLEVEL" ]
+ )
+ '
+}
+
+TOPLEVEL="$(pwd -P)/repo"
+mkdir -p repo/sub/dir
+mv .git repo/
+SUBDIRECTORY_OK=1
+
+test_cd_to_toplevel repo 'at physical root'
+
+test_cd_to_toplevel repo/sub/dir 'at physical subdir'
+
+ln -s repo symrepo
+test_cd_to_toplevel symrepo 'at symbolic root'
+
+ln -s repo/sub/dir subdir-link
+test_cd_to_toplevel subdir-link 'at symbolic subdir'
+
+cd repo
+ln -s sub/dir internal-link
+test_cd_to_toplevel internal-link 'at internal symbolic subdir'
+
+test_done
diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh
new file mode 100755
index 0000000..f18fec7
--- /dev/null
+++ b/t/t5521-pull-symlink.sh
@@ -0,0 +1,67 @@
+#!/bin/sh
+
+test_description='pulling from symlinked subdir'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+# The scenario we are building:
+#
+# trash\ directory/
+# clone-repo/
+# subdir/
+# bar
+# subdir-link -> clone-repo/subdir/
+#
+# The working directory is subdir-link.
+#
+test_expect_success setup '
+
+ mkdir subdir &&
+ touch subdir/bar &&
+ git add subdir/bar &&
+ git commit -m empty &&
+ git clone . clone-repo &&
+ # demonstrate that things work without the symlink
+ test_debug "cd clone-repo/subdir/ && git pull; cd ../.." &&
+ ln -s clone-repo/subdir/ subdir-link &&
+ cd subdir-link/ &&
+ test_debug "set +x"
+'
+
+# From subdir-link, pulling should work as it does from
+# clone-repo/subdir/.
+#
+# Instead, the error pull gave was:
+#
+# fatal: 'origin': unable to chdir or not a git archive
+# fatal: The remote end hung up unexpectedly
+#
+# because git would find the .git/config for the "trash directory"
+# repo, not for the clone-repo repo. The "trash directory" repo
+# had no entry for origin. Git found the wrong .git because
+# git rev-parse --show-cdup printed a path relative to
+# clone-repo/subdir/, not subdir-link/. Git rev-parse --show-cdup
+# used the correct .git, but when the git pull shell script did
+# "cd `git rev-parse --show-cdup`", it ended up in the wrong
+# directory. Shell "cd" works a little different from chdir() in C.
+# Bash's "cd -P" works like chdir() in C.
+#
+test_expect_success 'pulling from symlinked subdir' '
+
+ git pull
+'
+
+# Prove that the remote end really is a repo, and other commands
+# work fine in this context.
+#
+test_debug "
+ test_expect_success 'pushing from symlinked subdir' '
+
+ git push
+ '
+"
+cd "$D"
+
+test_done
--
1.6.0.3
^ permalink raw reply related
* Re: git-p4 submit, Can't clobber writable file
From: Gary Yang @ 2008-12-03 6:04 UTC (permalink / raw)
To: Jing Xue; +Cc: git
In-Reply-To: <20081203030729.GB5624@jabba.hq.digizenstudio.com>
So, I have to keep two copies of source tree at my home directory. One is for Perforce build_scripts workspace, another is for Git build_scripts.git. I normally work at build_scripts.git. But, when I need to submit changes to Perforce, I have to copy changed code from build_scripts.git to build_scripts. Then, p4 submit code into Perforce. Is this the only way of using git-p4?
Note: I cannot use git-p4 submit at build_scripts. It claims "Cannot clobber writable file". Is it a bug of git-p4 or the instruction is not correct?
--- On Tue, 12/2/08, Jing Xue <jingxue@digizenstudio.com> wrote:
> From: Jing Xue <jingxue@digizenstudio.com>
> Subject: Re: git-p4 submit, Can't clobber writable file
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: git@vger.kernel.org
> Date: Tuesday, December 2, 2008, 7:07 PM
> On Tue, Dec 02, 2008 at 02:30:51PM -0800, Gary Yang wrote:
> >
> > I followed the instructions at
> http://modular.math.washington.edu/home/mhansen/git-1.5.5.1/contrib/fast-import/git-p4.txt
> >
> > But, I am not able to git-p4 submit. Any idea?
> >
> > git-p4 clone //build/scripts build_scripts
> > cd build_scripts
> > vi foo.h
> > git commit foo.h
> > git-p4 rebase
> > git-p4 submit
> >
> > from sets import Set;
> > Perforce checkout for depot path //build/scripts/
> located at /home/gyang/workspace/build_scripts/
> > Syncronizing p4 checkout...
> > //build/scripts/foo.h#1 - added as
> /home/gyang/workspace/build_scripts/foo.h
> > Can't clobber writable file
> /home/gyang/workspace/build_scripts/foo.h
> > //build/scripts/foo.c#1 - added as
> /home/gyang/workspace/build_scripts/foo.c
> > Can't clobber writable file
> /user/home/gyang/workspace/build_scripts/foo.c
> > ......
> > command failed: p4 sync ...
>
> You might want to clone to a git working dir different than
> the p4
> working dir.
>
> For instance, if your p4 workspace has the working dir set
> to
> build_scripts/, try 'git p4 clone //build/scripts
> build_scripts.git'.
>
> You would then normally work under build_scripts.git/.
> build_scripts/
> would only be used by git-p4 at submission time.
>
> Cheers.
> --
> Jing Xue
^ permalink raw reply
* What's in git.git (Dec 2008, #01; Tue, 02)
From: Junio C Hamano @ 2008-12-03 6:23 UTC (permalink / raw)
To: git
We'll probably have 1.6.0.5 by the end of this week.
The tip of the 'master' branch is at 1.6.1-rc1 with a few more fixes.
Hopefully we will have the final 1.6.1 by the end of the year.
* The 'maint' branch has these fixes since the last announcement.
Joey Hess (1):
sha1_file: avoid bogus "file exists" error message
Johannes Schindelin (1):
fast-export: use an unsorted string list for extra_refs
Junio C Hamano (1):
Update draft release notes to 1.6.0.5
Martin Koegler (1):
git push: Interpret $GIT_DIR/branches in a Cogito compatible way
Matt McCutchen (1):
git checkout: don't warn about unborn branch if -f is already passed
Miklos Vajna (2):
Add new testcase to show fast-export does not always exports all tags
User's Manual: remove duplicated url at the end of Appendix B
Nguyễn Thái Ngọc Duy (1):
generate-cmdlist.sh: avoid selecting synopsis at wrong place
Pete Wyckoff (1):
git-p4: fix keyword-expansion regex
Ralf Wildenhues (1):
Fix typos in the documentation.
SZEDER Gábor (2):
bash: remove dashed command leftovers
bash: offer refs instead of filenames for 'git revert'
Sam Vilain (1):
sha1_file.c: resolve confusion EACCES vs EPERM
Samuel Tardieu (2):
tag: Check that options are only allowed in the appropriate mode
tag: Add more tests about mixing incompatible modes and options
* The 'master' branch has these since the last announcement
in addition to the above.
Alexander Gavrilov (3):
gitk: Avoid handling the Return key twice in Add Branch
gitk: Make line origin search update the busy status
gitk: Add a menu option to start git gui
Cheng Renquan (1):
git-remote: add verbose mode to git remote update
Christian Couder (4):
git-gui: french translation update
bisect: teach "skip" to accept special arguments like "A..B"
bisect: fix "git bisect skip <commit>" and add tests cases
Documentation: describe how to "bisect skip" a range of commits
Christian Stimming (1):
gitk: Update German translation
Giuseppe Bilotta (2):
gitweb: make gitweb_check_feature a boolean wrapper
Update comment on gitweb_check/get_feature
Johannes Schindelin (1):
Document levenshtein.c
Johannes Sixt (2):
compat/mingw.c: Teach mingw_rename() to replace read-only files
t4030-diff-textconv: Make octal escape sequence more portable
Junio C Hamano (6):
gitweb: fix 'ctags' feature check and others
gitweb: rename gitweb_check_feature to gitweb_get_feature
send-email: do not reverse the command line arguments
Include git-gui--askpass in git-gui RPM package
GIT 1.6.1-rc1
Makefile: introduce NO_PTHREADS
Linus Torvalds (3):
Add cache preload facility
Fix index preloading for racy dirty case
Add backslash to list of 'crud' characters in real name
Mark Burton (1):
git-gui: Teach start_push_anywhere_action{} to notice when remote is a
mirror.
Michele Ballabio (1):
git gui: update Italian translation
Miklos Vajna (5):
Update Hungarian translation. 100% completed.
builtin-clone: use strbuf in guess_dir_name()
builtin-clone: use strbuf in clone_local() and copy_or_link_directory()
builtin_clone: use strbuf in cmd_clone()
git-stash: use git rev-parse -q
Nanako Shiraishi (1):
git-gui: update Japanese translation
Paul Mackerras (6):
gitk: Index line[hnd]tag arrays by id rather than row number
gitk: Fix switch statement in parseviewargs
gitk: Show local changes properly when we have a path limit
gitk: Fix context menu items for generating diffs when in tree mode
gitk: Highlight only when search type is "containing:".
gitk: Fix bug in accessing undefined "notflag" variable
Peter Krefting (1):
Updated Swedish translation (514t0f0u).
Pierre Habouzit (4):
git send-email: make the message file name more specific.
git send-email: interpret unknown files as revision lists
git send-email: add --annotate option
git send-email: ask less questions when --compose is used.
Ralf Wildenhues (1):
Fix typos in the documentation.
René Scharfe (6):
add strbuf_expand_dict_cb(), a helper for simple cases
merge-recursive: use strbuf_expand() instead of interpolate()
daemon: use strbuf_expand() instead of interpolate()
daemon: inline fill_in_extra_table_entries()
daemon: deglobalize variable 'directory'
remove the unused files interpolate.c and interpolate.h
SZEDER Gábor (1):
bash: complete full refs
Samuel Tardieu (1):
Fix deletion of last character in levenshtein distance
Scott Chacon (1):
Add a built-in alias for 'stage' to the 'add' command
Tuncer Ayaz (2):
Teach/Fix pull/fetch -q/-v options
Retain multiple -q/-v occurrences in git pull
^ permalink raw reply
* What's cooking in git.git (Dec 2008, #01; Tue, 02)
From: Junio C Hamano @ 2008-12-03 6:59 UTC (permalink / raw)
To: git
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 merged to the maintenance series have "maint-" in their names.
As we have already passed -rc1, things queued in 'next' let alone 'pu' are
unlikely to be merged to 'master' by the end of year unless otherwise
noted.
----------------------------------------------------------------
[New Topics]
* gb/gitweb-patch (Sat Nov 29 14:41:11 2008 +0100) 2 commits
- [DONTMERGE: wait for signoff] gitweb: links to patch action in
commitdiff and shortlog view
- gitweb: add patch view
* lt/reset-merge (Mon Dec 1 09:30:31 2008 -0800) 1 commit
+ Add 'merge' mode to 'git reset'
Unfortunately, I cannot write down a good use case in what circumstances
this is needed, even though I do recall that I occasionally (perhaps once
every two months) needed to do "read-tree -m -u" myself in the past, and
this patch brings that feature close to Porcelain. On the other hand, the
existing "reset --mixed" is very easily explained ("after starting to add
changes to the staging area, you realized that you screwed up, and you
want to redo it from scratch"). Therefore, I cannot justify what the log
message of this change claims myself.
* jc/rm-i-t-a (Fri Nov 28 19:56:34 2008 -0800) 5 commits
+ git add --intent-to-add: do not let an empty blob be committed by
accident
+ git add --intent-to-add: fix removal of cached emptiness
+ builtin-rm.c: explain and clarify the "local change" logic
+ Merge branch 'nd/narrow' (early part) into jc/add-i-t-a
+ Extend index to save more flags
As intent-to-add index entry is a new feature for 1.6.1, it probably is a
good idea to merge this to 'master'. Nitpicks and bugfixes are very much
appreciated.
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
- In add --patch, Handle K,k,J,j slightly more gracefully.
- Add / command in add --patch
- git-add -i/-p: Change prompt separater from slash to comma
There are some other useful bits and pieces around this area exchanged on
the list with the author of these patches. I think it would become a
useful series after reassembling their pieces. Waiting for v2.
* jn/gitweb-utf8 (Mon Dec 1 19:01:42 2008 +0100) 1 commit
- gitweb: Fix handling of non-ASCII characters in inserted HTML
files.
Possibly a bugfix worthy to have in 1.6.1.
* jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits
- clone: test the new HEAD detection logic
- Merge commit 'HEAD@{2}' into HEAD
- upload-pack: send the HEAD information
- clone: find the current branch more explicitly
- connect.c::read_extra_info(): find where HEAD points at
- connect.c::read_extra_info(): prepare to receive more than server
capabilities
- get_remote_heads(): refactor code to read "server capabilities"
This is no way meant for 1.6.1, let alone next, yet.
----------------------------------------------------------------
[Graduated to "master"]
* cr/remote-update-v (Tue Nov 18 19:04:02 2008 +0800) 1 commit
+ git-remote: add verbose mode to git remote update
* rs/strbuf-expand (Sun Nov 23 00:16:59 2008 +0100) 6 commits
+ remove the unused files interpolate.c and interpolate.h
+ daemon: deglobalize variable 'directory'
+ daemon: inline fill_in_extra_table_entries()
+ daemon: use strbuf_expand() instead of interpolate()
+ merge-recursive: use strbuf_expand() instead of interpolate()
+ add strbuf_expand_dict_cb(), a helper for simple cases
* mv/fast-export (Sun Nov 23 12:55:54 2008 +0100) 2 commits
+ fast-export: use an unsorted string list for extra_refs
+ Add new testcase to show fast-export does not always exports all
tags
* st/levenshtein (Thu Nov 20 14:27:27 2008 +0100) 2 commits
+ Document levenshtein.c
+ Fix deletion of last character in levenshtein distance
* js/mingw-rename-fix (Wed Nov 19 17:25:27 2008 +0100) 1 commit
+ compat/mingw.c: Teach mingw_rename() to replace read-only files
* mv/clone-strbuf (Fri Nov 21 01:45:01 2008 +0100) 3 commits
+ builtin_clone: use strbuf in cmd_clone()
+ builtin-clone: use strbuf in clone_local() and
copy_or_link_directory()
+ builtin-clone: use strbuf in guess_dir_name()
* pw/maint-p4 (Wed Nov 26 13:52:15 2008 -0500) 1 commit
- git-p4: fix keyword-expansion regex
* cc/bisect-skip (Sun Nov 23 22:02:49 2008 +0100) 1 commit
- bisect: teach "skip" to accept special arguments like "A..B"
Should be in 1.6.1-rc1.
* lt/preload-lstat (Mon Nov 17 09:01:20 2008 -0800) 2 commits
+ Fix index preloading for racy dirty case
+ Add cache preload facility
* ta/quiet-pull (Mon Nov 17 23:09:30 2008 +0100) 2 commits
+ Retain multiple -q/-v occurrences in git pull
+ Teach/Fix pull/fetch -q/-v options
* ph/send-email (Tue Nov 11 00:54:02 2008 +0100) 4 commits
+ git send-email: ask less questions when --compose is used.
+ git send-email: add --annotate option
+ git send-email: interpret unknown files as revision lists
+ git send-email: make the message file name more specific.
After merging these to 'master' I found a breakage which I hopefully
fixed.
----------------------------------------------------------------
[Will merge to "master" soon]
What are you looking for? We are in -rc ;-)
----------------------------------------------------------------
[On Hold]
* cb/mergetool (Thu Nov 13 12:41:15 2008 +0000) 3 commits
- [DONTMERGE] Add -k/--keep-going option to mergetool
- Add -y/--no-prompt option to mergetool
- Fix some tab/space inconsistencies in git-mergetool.sh
Jeff had good comments on the last one; the discussion needs concluded,
and also waiting for comments from the original author (Ted).
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
Rebased to 'master', that introduced NO_PTHREADS.
* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
- bisect: add "--no-replace" option to bisect without using replace
refs
- rev-list: make it possible to disable replacing using "--no-
bisect-replace"
- bisect: use "--bisect-replace" options when checking merge bases
- merge-base: add "--bisect-replace" option to use fixed up revs
- commit: add "bisect_replace_all" prototype to "commit.h"
- rev-list: add "--bisect-replace" to list revisions with fixed up
history
- Documentation: add "git bisect replace" documentation
- bisect: add test cases for "git bisect replace"
- bisect: add "git bisect replace" subcommand
I really hate the idea of introducing a potentially much more useful
replacement of the existing graft mechanism and tie it very tightly to
bisect, making it unusable from outside.
(1) I do not think "bisect replace" workflow is a practical and usable
one;
(2) The underlying mechanism to express "this object replaces that other
object" is much easier to work with than what the graft does which is
"the parents of this commit are these", and idea to use the normal
ref to point at them means this can potentially be used for
transferring the graft information across repositories, which the
current graft mechanism cannot do.
(3) Because I like the aspect (2) of this series so much, it deeply
disappoints and troubles me that this is implemented minimally near
the surface, and that it is controlled by the "bisect" Porcelain
alone, by explicitly passing command line arguments.
I think a mechanism like this should be added to replace grafts, but it
should always be enabled for normal revision traversal operation, while
always disabled for object enumeration and transfer operation (iow, fsck,
fetch and push should use the real ancestry information recorded in the
underlying objects, while rev-list, log, etc. should always use the
replaced objects). I have a suspicion that even cat-file could honor it.
* nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 18 commits
- wt-status: show sparse checkout info
- Introduce default sparse patterns (core.defaultsparse)
- checkout: add new options to support sparse checkout
- clone: support sparse checkout with --sparse-checkout option
- unpack_trees(): add support for sparse checkout
- unpack_trees(): keep track of unmerged entries
- Introduce "sparse patterns"
- Merge branch 'master' into nd/narrow
+ t2104: touch portability fix
+ grep: skip files outside sparse checkout area
+ checkout_entry(): CE_NO_CHECKOUT on checked out entries.
+ Prevent diff machinery from examining worktree outside sparse
checkout
+ ls-files: Add tests for --sparse and friends
+ update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
+ update-index: refactor mark_valid() in preparation for new options
+ ls-files: add options to support sparse checkout
+ Introduce CE_NO_CHECKOUT bit
+ Extend index to save more flags
Kicked back to 'on hold' until 1.6.1 final by popular(?) demand.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* 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.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply
* Re: [PATCH] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Junio C Hamano @ 2008-12-03 7:20 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: git, jnareb, ae, j.sixt
In-Reply-To: <1228282020-2294-1-git-send-email-marcel@oak.homeunix.org>
"Marcel M. Cary" <marcel@oak.homeunix.org> writes:
> If cd_to_toplevel had concatenated $(/bin/pwd) with $cdup to
> avoid the separate "cd", it would require checking for $cdup
> being an absolute path. I wasn't sure how to check that in
> a way that is both portable and clearly faster than "cd",
case "$v" in
/*) : handle absolute path ;;
*) : everything else ;;
esac
In all shells that support "case..esac", it is built-in.
Having said that, I think it would probably be better to bite the bullet
and start using "cd -P" soon after 1.6.1 goes final, and at the same time
existing places that use "cd `pwd`" as a workaround if there are some.
^ permalink raw reply
* "git help stage" doesn't display git-stage man page
From: Teemu Likonen @ 2008-12-03 7:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Scott Chacon
In-Reply-To: <7vvdu1hj41.fsf@gitster.siamese.dyndns.org>
Junio C Hamano (2008-12-02 22:23 -0800) wrote:
> * The 'master' branch has these since the last announcement
> in addition to the above.
> Scott Chacon (1):
> Add a built-in alias for 'stage' to the 'add' command
I think there's a minor user-interface defect:
$ git help stage
No manual entry for gitstage
"git stage" is only a built-in alias but at some point it may become the
primary staging command for new Git users and hence a kind of real Git
command. I think "git help stage" should show the git-stage manual page
(even though it only points to git-add(1)).
^ permalink raw reply
* Re: [man bug?] git rebase --preserve-merges
From: Andreas Ericsson @ 2008-12-03 7:43 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812020845g7de701bbye4a43a4e992a264b@mail.gmail.com>
Constantine Plotnikov wrote:
> The man page for git rebase mentions "--preserve-merges" command line
> option but this option does not seems to be available.
>
> Also if this option is specified, the following usage statement is printed:
>
> Usage: git rebase [--interactive | -i] [-v] [--onto <newbase>]
> <upstream> [<branch>]
>
> And this usage statement does not mention -m and -s options that seems
> to be available. I assume that the problem is the obsolete
> documentation.
>
You're probably using an old git where merge-preserving rebase is only
available for interactive mode. Check the man-page again, and thoroughly
this time ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Junio C Hamano @ 2008-12-03 7:54 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <1228277212-5917-1-git-send-email-tuncer.ayaz@gmail.com>
Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
> This is needed on top of the fetch/pull -q/-v changes
> to make
> $ git pull --rebase -q
> as quiet as expected.
I am not sure if this is worth it, in the sense that it is not really
quiet enough (iow, it is not what I expect even though you claim "as
expected" here), and in another sense that making it really quiet may not
be what we want anyway.
How are you dealing with messages from the actual replaying of each local
commit on top of what is fetched? In order to be able to tell where you
are when one of them fail in conflicts, you cannot stay silent while doing
so.
^ permalink raw reply
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Tuncer Ayaz @ 2008-12-03 8:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej0pheww.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 3, 2008 at 8:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
>
>> This is needed on top of the fetch/pull -q/-v changes
>> to make
>> $ git pull --rebase -q
>> as quiet as expected.
>
> I am not sure if this is worth it, in the sense that it is not really
> quiet enough (iow, it is not what I expect even though you claim "as
Junio, sorry for using 'expected'.
I thought about the wording while writing and had a feeling that 'expected'
may be too strong as it's my opinion only. I should have listened to myself :).
> expected" here), and in another sense that making it really quiet may not
> be what we want anyway.
I mainly use -q in automation where I only want output if something
goes wrong. Just like good old cp or mv do.
Do you think this is the wrong way to go?
> How are you dealing with messages from the actual replaying of each local
> commit on top of what is fetched? In order to be able to tell where you
> are when one of them fail in conflicts, you cannot stay silent while doing
> so.
Fair point.
Log messages that are of importance to a failure should ideally be sent to
stderr but I think caching log messages for the failure case would
over-complicate
much of the code and is not worth it. Also you may not always know which part
of stdout messages are useful for the failure case and not getting the
same messages
on a rerun for many commands makes this hard to trace back, yeah.
As we've quietened pull/fetch/clone in a major already I am OK with leaving this
change out.
I'm definitely not advocating adding/changing anything when it's not clear we
want the changed behavior. It's easier to keep out than to remove it
later on :).
^ permalink raw reply
* Re: "git help stage" doesn't display git-stage man page
From: Junio C Hamano @ 2008-12-03 8:14 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git, Scott Chacon
In-Reply-To: <87myfdn2ga.fsf@iki.fi>
Teemu Likonen <tlikonen@iki.fi> writes:
> Junio C Hamano (2008-12-02 22:23 -0800) wrote:
>
>> * The 'master' branch has these since the last announcement
>> in addition to the above.
>
>> Scott Chacon (1):
>> Add a built-in alias for 'stage' to the 'add' command
>
> I think there's a minor user-interface defect:
>
> $ git help stage
> No manual entry for gitstage
The patch also breaks the promise made at 1.6.0 that prepending exec path
to $PATH allows you to use the dashed form.
$ PATH=$(git --exec-path):$PATH
$ git-stage -p
xash: git-stage: cmd not found
> "git stage" is only a built-in alias but at some point it may become the
> primary staging command for new Git users and hence a kind of real Git
> command. I think "git help stage" should show the git-stage manual page
> (even though it only points to git-add(1)).
I do not think it would ever be _the_ primary command to add the contents
to the index; we are adding it as a training wheel.
When we had the "staging area" discussion, somehow people ended up with
this notion that you somehow *need to* use the same verb and noun.
I.e. "the index is now explained as the _staging area_. Why isn't the
command to add contents to the staging area called git-stage?" was the
primary argument that lead to this thinking.
I do not think it adds much value to the system to be dogmatic and insist
that you _have to_ use the same verb and noun. "You add your changes to
the staging area" is a perfectly natural way to explain what you are doing
and where the "add" in git-add command comes from. It however is Ok to
allow people to use different spelling (i.e. the verb "stage").
In that sense, I think the intention of the patch to add "stage" as an
additional verb, while clearly marking it as a synonym to the primary
command "add", is aimed at the right place and strikes the right balance.
By the way, I think this should fix it, although it is very late and I
have no time to test it tonight myself.
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git i/Makefile w/Makefile
index 9577d6f..5158197 100644
--- i/Makefile
+++ w/Makefile
@@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
BUILT_INS += git-peek-remote$X
BUILT_INS += git-repo-config$X
BUILT_INS += git-show$X
+BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
^ permalink raw reply related
* fast-import problem importing dos format files under cygwin
From: Jan Hudec @ 2008-12-03 7:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
Hello folks,
I have been playing with fast-import in cygwin and I have problems
importing files with CR/LF line-endings. The size in data command is
calculated including the CRs and than the file is copied binary to the
fast-import input stream. However fast-import skips the CRs when reading,
overreads by that number of bytes and fails when it tries to read the next
command from the middle.
Attached is a test input stream and crash report generated by fast-import
when reading it. In case mail system damages it along the way despite
being attached to prevent that, the file should be in unix format -- that
is what my cygwin perl outputs by default -- and has CRs only on lines 15
and 16. The unix.txt and dos.txt should only differ that the '.'s in
former are replaced by '^M's in the later (so the data commands are
otherwise same).
Note, that when I convert the file to dos format, it is read as intended.
However, that is inconsistent with rest of the cygwin environment which
generated and expects files in unix format. I use binary mounts (not
converting) and CYGWIN environment variable is empty. My git version is
1.6.0.4 from official Cygwin package.
Is this behaviour intentional workaround for something or a bug?
--
- Jan Hudec <bulb@ucw.cz>
[-- Attachment #2: test1.gfi --]
[-- Type: /, Size: 495 bytes --]
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287890 +0100
data 19
unix-formatted-file
M 100644 inline unix.txt
data 13
some.
lines.
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287892 +0100
data 18
dos-formatted-file
M 100644 inline dos.txt
data 13
some
lines
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287894 +0100
data 23
one more commit for fun
M 100644 inline other.txt
data 22
we need more commands
checkpoint
[-- Attachment #3: fast_import_crash_5212 --]
[-- Type: /, Size: 1034 bytes --]
fast-import crash report:
fast-import process: 5212
parent process : 1696
at Wed Dec 3 08:29:42 2008
fatal: Unsupported command: mmit refs/heads/master
Most Recent Commands Before Crash
---------------------------------
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287890 +0100
data 19
M 100644 inline unix.txt
data 13
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287892 +0100
data 18
M 100644 inline dos.txt
data 13
* mmit refs/heads/master
Active Branch LRU
-----------------
active_branches = 1 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 2 refs/heads/master
Inactive Branches
-----------------
refs/heads/master:
status : active loaded
tip commit : 2a11b753d155443462523e0f3cef72e4f02817b2
old tree : 5bcdcdcafba5303797865311a7fa06e2ce3ddc65
cur tree : 5bcdcdcafba5303797865311a7fa06e2ce3ddc65
commit clock: 2
last pack : 0
Marks
-----
-------------------
END OF CRASH REPORT
^ permalink raw reply
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Junio C Hamano @ 2008-12-03 8:26 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <4ac8254d0812030007w3217f6eei3d364ce2272930c3@mail.gmail.com>
"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
> I mainly use -q in automation where I only want output if something
> goes wrong. Just like good old cp or mv do.
> Do you think this is the wrong way to go?
>
>> How are you dealing with messages from the actual replaying of each local
>> commit on top of what is fetched? In order to be able to tell where you
>> are when one of them fail in conflicts, you cannot stay silent while doing
>> so.
>
> Fair point.
Ahh, ok, if this is for cron jobs, then it is understandable that:
(1) You may want a successful "git pull" or "git pull --rebase" to be
absolutely silent about what it did; and
(2) A failed "git pull" and "git pull --rebase" that produces information
other than the fact it failed would not help you, the receiver of a
cron job report, very much. You would go to the repository when it
fails, reset the mess away, and then do the pull or pull-rebase
yourself manually anyway.
If that is the motivation behind the series, I think you would really want
to squelch output from "format-patch | am -3" pipeline.
Another thing to consider is that, unlike simple single-operation commands
such as "mv" or "cp" you mentioned, what "git pull" does is much more
involved and has many different failure modes, so you cannot compare them
fairly. Simple commands can have a single "quiet" level, but I have a
feeling that there is a difference between "quiet mode" I expect when I am
running "git pull" interactively and "quiet mode" I would want when I
would be driving "git pull" from a cron job. IOW, you probably would want
something like "--really-quiet" mode.
I would write such a cron-job script to capture the log and send it only
upon failure from the underlying command if I were doing this myself,
though.
^ permalink raw reply
* Re: "git help stage" doesn't display git-stage man page
From: Teemu Likonen @ 2008-12-03 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Scott Chacon
In-Reply-To: <7vwsehfzf7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano (2008-12-03 00:14 -0800) wrote:
> By the way, I think this should fix it, although it is very late and I
> have no time to test it tonight myself.
It does fix it for me. Thanks.
> diff --git i/Makefile w/Makefile
> index 9577d6f..5158197 100644
> --- i/Makefile
> +++ w/Makefile
> @@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
> BUILT_INS += git-peek-remote$X
> BUILT_INS += git-repo-config$X
> BUILT_INS += git-show$X
> +BUILT_INS += git-stage$X
> BUILT_INS += git-status$X
> BUILT_INS += git-whatchanged$X
^ permalink raw reply
* Re: "git help stage" doesn't display git-stage man page
From: Junio C Hamano @ 2008-12-03 8:34 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git, Scott Chacon
In-Reply-To: <7vwsehfzf7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Teemu Likonen <tlikonen@iki.fi> writes:
>
>>> Scott Chacon (1):
>>> Add a built-in alias for 'stage' to the 'add' command
>>
>> I think there's a minor user-interface defect:
>>
>> $ git help stage
>> No manual entry for gitstage
>
> ...
> In that sense, I think the intention of the patch to add "stage" as an
> additional verb, while clearly marking it as a synonym to the primary
> command "add", is aimed at the right place and strikes the right balance.
>
> By the way, I think this should fix it, although it is very late and I
> have no time to test it tonight myself.
Ok, I lied. I'll go to bed after committing this.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 3 Dec 2008 00:30:34 -0800
Subject: [PATCH] Install git-stage in exec-path
Earlier the plan was to eventually eradicate git-foo executables from the
filesystem for all the built-in commands, but when we released 1.6.0 we
decided not to do so. Instead, it has been promised that by prepending
the output from $(git --exec-path) to your $PATH, you can keep using the
dashed form of commands.
This also allows "git stage" to appear in the autogenerated command list,
which is used to offer man pages by "git help" command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 9577d6f..5158197 100644
--- a/Makefile
+++ b/Makefile
@@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
BUILT_INS += git-peek-remote$X
BUILT_INS += git-repo-config$X
BUILT_INS += git-show$X
+BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
--
1.6.1.rc1.44.g06a3
^ permalink raw reply related
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Tuncer Ayaz @ 2008-12-03 8:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr64pfyvg.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> I mainly use -q in automation where I only want output if something
>> goes wrong. Just like good old cp or mv do.
>> Do you think this is the wrong way to go?
>>
>>> How are you dealing with messages from the actual replaying of each local
>>> commit on top of what is fetched? In order to be able to tell where you
>>> are when one of them fail in conflicts, you cannot stay silent while doing
>>> so.
>>
>> Fair point.
>
> Ahh, ok, if this is for cron jobs, then it is understandable that:
>
> (1) You may want a successful "git pull" or "git pull --rebase" to be
> absolutely silent about what it did; and
>
> (2) A failed "git pull" and "git pull --rebase" that produces information
> other than the fact it failed would not help you, the receiver of a
> cron job report, very much. You would go to the repository when it
> fails, reset the mess away, and then do the pull or pull-rebase
> yourself manually anyway.
>
> If that is the motivation behind the series, I think you would really want
> to squelch output from "format-patch | am -3" pipeline.
You mean I should follow this path and produce a patch series instead?
> Another thing to consider is that, unlike simple single-operation commands
> such as "mv" or "cp" you mentioned, what "git pull" does is much more
> involved and has many different failure modes, so you cannot compare them
> fairly. Simple commands can have a single "quiet" level, but I have a
> feeling that there is a difference between "quiet mode" I expect when I am
> running "git pull" interactively and "quiet mode" I would want when I
We have the same expectation here and IDE writers also seem to expect that.
> would be driving "git pull" from a cron job. IOW, you probably would want
> something like "--really-quiet" mode.
Yeah, it gets messy and in the current codebase. I am also not sure whether
the effort/benefit ratio is good enough.
> I would write such a cron-job script to capture the log and send it only
> upon failure from the underlying command if I were doing this myself,
> though.
This is the way I do it now and I'm surprised I found no other simple way
than writing a wrapper script for it. At least not with vixie-cron.
^ permalink raw reply
* Re: git-svn with multiple remote repositories?
From: Michael J Gruber @ 2008-12-03 8:45 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20081202213930.GD12716@raven.wolf.lan>
Josef Wolf venit, vidit, dixit 02.12.2008 22:39:
> Hello,
>
> I am trying to create a git repository with two remote svn repositories
> so that I can merge/move patch-sets back and forth between the svn
> repositories.
>
> This is what I have tried so far:
>
> mkdir -p project
> cd project
> git-svn init -R private -s https://foo.bar/repos/private
>
> Then I go and edit .git/config too look like this:
>
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [svn-remote "private"]
> url = https://foo.bar/repos/private
> fetch = trunk:refs/remotes/private/trunk
> branches = branches/*:refs/remotes/private/*
> tags = tags/*:refs/remotes/private/tags/*
> [svn-remote "public"]
> url = https://foo.bar/repos/public
> fetch = trunk:refs/remotes/public/trunk
> branches = branches/*:refs/remotes/public/*
> tags = tags/*:refs/remotes/public/tags/*
>
> And finally, I do
>
> git-svn fetch -R private
> git-svn fetch -R public
>
> Both commands seem to fetch the contents from their origins. But
> git-branch shows me only the local master branch with contents from
> the "private" svn repository. When I do
>
> git checkout public/trunk
>
> the contents actually change to reflect the "public" svn repository,
> but git-branch says I am on "(no branch)" at all.
You want "git branch -a" if you want to see all branches including
remotes. "master" happens to reflect "remotes/private/trunk" because the
first fetch set it up like that. Further fetches will not change master.
Remote branches are your local copy, but different from local branches:
you're not supposed to check them out, and if you do anyways, you get a
"detached HEAD". Well, your repo gets a detached HEAD...
If you want to work with remote branches, create a tracking branch: a
local branch that is based on a remote one and that is set up to rebase
(or merge) new commits from the remote:
git checkout -b mypublic/trunk remotes/public/trunk
You can name the local branch any way you want, even "public/trunk", but
that may lead to confusion when you look at the output of "git branch
-a" which suppresses the "remote/" part.
Michael
^ permalink raw reply
* Ad: fast-import problem importing dos format files under cygwin
From: Jan Hudec @ 2008-12-03 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <43827.194.138.12.144.1228290700.squirrel@artax.karlin.mff.cuni.cz>
On 3 December 2008, 08:51, Jan Hudec wrote:
> Hello folks,
>
> I have been playing with fast-import in cygwin and I have problems
> importing files with CR/LF line-endings. The size in data command is
> calculated including the CRs and than the file is copied binary to the
> fast-import input stream. However fast-import skips the CRs when reading,
> overreads by that number of bytes and fails when it tries to read the
> next command from the middle.
One addition:
I have tried with MSYS version 1.5.6.1.1071.g76fb and it imported the
test, as it was, except it didn't like 'refs/heads/master' as branchname
(and accepted bare 'master', but that created '.git/master').
--
- Jan Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH 0/2] gitweb: patch view
From: Giuseppe Bilotta @ 2008-12-03 9:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200812011202.41300.jnareb@gmail.com>
On Mon, Dec 1, 2008 at 12:02 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 1 December 2008, Giuseppe Bilotta wrote:
>> On Mon, Dec 1, 2008 at 1:45 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Sun, 30 Nov 2008, Giuseppe Bilotta wrote:
>>>> On Sun, Nov 30, 2008 at 2:06 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>> On Sat, 29 Nov 2008, Giuseppe Bilotta wrote:
>>>>
>>>>> By the way, we still might want to add somehow X-Git-Url and X-Git-Tag
>>>>> headers later to 'patch' ('patchset') output format.
>>>>
>>>> Yeah, I've been thinking about it, but I couldn't find an easy and
>>>> robust way to do it. Plus, should we add them for each patch, or just
>>>> once for the whole patchset?
>>>
>>> True, that is a complication. Perhaps they should be added only for
>>> single patch?
>>
>> Although that's rather easy to implement technically, it also creates
>> some kind of inconsistency.
>
> Well, it is problem also from technical point of view. Currently we can
> just stream (dump) git-format-patch output to browser (not forgetting
> adding '--encoding=utf8' if it is not used already), and do not need
> to have markers between commits. It is very simple code, which is its
> own advantage.
>
> From theoretical point of view corrected X-Git-Tag functioning as
> a kind of ref marker but for the raw (text/plain) output could be added
> for each end every patch, so there would be no inconsistency for _this_
> extra header.
>
> I don't know what can be done about X-Git-URL.
I'm thinking that the best way to achieve these results would be to
have some way to specify extra headers to git format-patch from the
command line and not just from a config file. Plus, we want to make
them 'dynamic' in the sense that we want to be able to put hash or ref
names etc in them. For the moment I'll mark this 'TODO' in the file.
>>>> Considering I think commitdiff is ugly and long, you can guess my
>>>> opinion on format_patch 8-P. 'patchset' might be a good candidate,
>>>> considering it's what it does when both hash_parent and hash are
>>>> given.
>>>
>>> True, 'patchset' might be even better, especially that it hints
>>> what it does for a range a..b (not diff of endpoints, but series
>>> of patches).
>>
>> Good, I'll rename it.
>
> I just don't know if it would be best name. Perhaps 'patches' would
> be better?
The only thing I don't like about 'patches' is that if you ask for a
single commit you get a single patch. I'd rather stick to 'patch'
then, maybe make 'patches' a synonym?
>>>> * diff(_plain): do what commitdiff(_plain) currently does for
>>>> parent..hash views, modulo something to be discussed for commit
>>>> messages (a shortlog rather maybe?)
>>>
>>> Equivalent of "git diff" (or "git diff-tree").
>>>
>>> Diffstat, or dirstat might be a good idea. Shortlog... I am not sure.
>>> Diff is about endpoints, and they can be in reverse, too.
>>>
>>> There is a problem how to denote endpoints.
>>
>> Hm? Doesn't parent..hash work? Or are you talking about something else?
>
> Errr... I meant here for the user, not for gitweb. To somehow denote
> before patch itself the endpoints. Just like for diff _for_ a commit
> we have commit message denoting :-).
Ah, in the sense that you have to specify parent..hash manually in the
URL presently? I've seen some patches to non-main gitweb doing this
kind of thing. If it got merged with upstream we could use that as
well.
>>>> * patch[set?][_plain?]: format-patch style output (maybe with option
>>>> for HTML stuff too)
>>>
>>> Equivalent of "git format-patch".
>>>
>>> Actually the HTML format would be more like "git log -p", so perhaps
>>> that could be handled simply as a version of 'log' view (perhaps via
>>> @extra_options aka 'opt' parameter).
>>
>> This is starting to get complicated ... I'm not sure how far in this I
>> can go with this patchset, so for the time being I'll probably just
>> stick to refining the (plain) patchset feature.
>
> What I meant here is that it would be IMHO enough to have 'patch' view
> (or whatever it ends up named) be raw format / plain/text format only,
> and leave HTML equivalent for extra options/extra format to 'log' view.
Ah, ok. I'll resubmit a cleaned up version of these two patches for
the time being then.
>>>>>> The second patch exposes it from commitdiff view (obviosly), but also
>>>>>> from shortlog view, when less than 16 patches are begin shown.
>>>>>
>>>>> Why this nonconfigurable limit?
>>>>
>>>> Because the patch was actually a quick hack for the proof of concept
>>>> 8-) I wasn't even sure the patch idea would have been worth it (as
>>>> opposed to email-izing commitdiff_plain).
>>>
>>> Ah.
>>>
>>> Well, we might want to impose some limit to avoid generating and sending
>>> patchset for a whole history. Perhaps to page size (100), or some similar
>>> number?
>>
>> The reason why I chose 16 is that (1) it's a rather commonly used
>> 'small' number across gitweb and (2) it's a rather acceptable
>> 'universal' upper limit for patchsets. There _are_ a few patchbombs
>> that considerably overtake that limit, but observe that this limit is
>> not an arbitrary limit on patchsets generated by the 'patchset' view,
>> but only a condition for which a link is generated from shortlog view.
>
> I see.
>
>> We may want to have TWO limits here: one is the absolute maximum limit
>> to the number of patches dumped in a patchset (to prevent DoS attacks
>> by repeated requests of the whole history), and the other one is the
>> limit for autogenerated patchset links.
>
> A pageful (100 commits) as hard limit against DoS attacks?
I suspect 100 is too hight already, but I guess we can tune it later.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] Make t9128-git-svn-cmd-branch pass with svn 1.4
From: Michael J Gruber @ 2008-12-03 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <7vbpvtj4kl.fsf@gitster.siamese.dyndns.org>
The copy command in svn 1.4 allows only one source (svn copy A D), whereas
the copy command in svn 1.5 allows multiple sources (svn copy A B C D).
This patch rewrites t9128 to use the backwards compatible form.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t9128-git-svn-cmd-branch.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/t/t9128-git-svn-cmd-branch.sh b/t/t9128-git-svn-cmd-branch.sh
index e2b6696..252daa7 100755
--- a/t/t9128-git-svn-cmd-branch.sh
+++ b/t/t9128-git-svn-cmd-branch.sh
@@ -61,7 +61,9 @@ test_expect_success 'branch uses correct svn-remote' '
cd svn &&
mkdir mirror &&
svn add mirror &&
- svn copy trunk tags branches mirror/ &&
+ svn copy trunk mirror/ &&
+ svn copy tags mirror/ &&
+ svn copy branches mirror/ &&
svn ci -m "made mirror" ) &&
rm -rf svn &&
git svn init -s -R mirror --prefix=mirror/ "$svnrepo"/mirror &&
--
1.6.1.rc1
^ permalink raw reply related
* Re: [PATCH] git-svn: Make branch use correct svn-remote
From: Michael J Gruber @ 2008-12-03 9:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Eric Wong, Deskin Miller
In-Reply-To: <7vbpvtj4kl.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 03.12.2008 04:55:
> Eric Wong <normalperson@yhbt.net> writes:
>
>> Deskin Miller <deskinm@umich.edu> wrote:
>>> The 'branch' subcommand incorrectly had the svn-remote to use hardcoded
>>> as 'svn', the default remote name. This meant that branches derived
>>> from other svn-remotes would try to use the branch and tag configuration
>>> for the 'svn' remote, potentially copying would-be branches to the wrong
>>> place in SVN, into the branch namespace for another project.
>>>
>>> Fix this by using the remote name extracted from the svn info for the
>>> specified git ref. Add a testcase for this behaviour.
>>>
>>> Signed-off-by: Deskin Miller <deskinm@umich.edu>
>> Looks alright to me, thanks Deskin.
>>
>> Acked-by: Eric Wong <normalperson@yhbt.net>
>
> Does not work for me X-<.
>
> * expecting success:
> (svn co "$svnrepo" svn &&
> cd svn &&
> mkdir mirror &&
> svn add mirror &&
> svn copy trunk tags branches mirror/ &&
> svn ci -m "made mirror" ) &&
> rm -rf svn &&
> git svn init -s -R mirror --prefix=mirror/ "$svnrepo"/mirror &&
> git svn fetch -R mirror &&
> git checkout mirror/trunk &&
> base=$(git rev-parse HEAD:) &&
> git svn branch -m "branch in mirror" d &&
> test $base = $(git rev-parse remotes/mirror/d:) &&
> test_must_fail git rev-parse remotes/d
>
> A svn/trunk
> A svn/trunk/foo
> A svn/branches
> A svn/branches/a
> A svn/branches/a/foo
> A svn/branches/b
> A svn/branches/b/foo
> A svn/tags
> A svn/tags/tag4
> A svn/tags/tag4/foo
> A svn/tags/tag1
> A svn/tags/tag1/foo
> A svn/tags/tag2
> A svn/tags/tag2/foo
> A svn/tags/tag3
> A svn/tags/tag3/foo
> Checked out revision 8.
> A mirror
> svn: Client error in parsing arguments
> * FAIL 4: branch uses correct svn-remote
>
> (svn co "$svnrepo" svn &&
> cd svn &&
> mkdir mirror &&
> svn add mirror &&
> svn copy trunk tags branches mirror/ &&
With my svn (1.4.6) it fails already here: "svn copy" allows two
arguments only. That may be different in svn 1.5.
> svn ci -m "made mirror" ) &&
> rm -rf svn &&
> git svn init -s -R mirror --prefix=mirror/ "$svnrepo"/mirror &&
> git svn fetch -R mirror &&
> git checkout mirror/trunk &&
> base=$(git rev-parse HEAD:) &&
> git svn branch -m "branch in mirror" d &&
> test $base = $(git rev-parse remotes/mirror/d:) &&
> test_must_fail git rev-parse remotes/d
If I split the above copy into three lines then the test passes (svn
1.4.6, Deskin's patch applied onto 1.6.1-rc1 with the fix.
Patch coming. (Sorry I always forget the ccs with send-email.)
Michael
^ permalink raw reply
* [RFCv2 0/2] gitweb: patch view
From: Giuseppe Bilotta @ 2008-12-03 10:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Another go at the patch view feature. I'm marking this as RFC because
there are still a couple of points that need to be agreed on, esp. wrt
to the patch limiting and the insertion of extra X-Git-* email headers.
Giuseppe Bilotta (2):
gitweb: add patch view
gitweb: links to patch action in commitdiff and shortlog view
Makefile | 2 ++
gitweb/gitweb.perl | 39 +++++++++++++++++++++++++++++++++++++--
2 files changed, 39 insertions(+), 2 deletions(-)
^ permalink raw reply
* [RFCv2 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-03 10:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1228298862-28191-1-git-send-email-giuseppe.bilotta@gmail.com>
The manually-built email format in commitdiff_plain output is not
appropriate for feeding git-am, because of two limitations:
* when a range of commits is specified, commitdiff_plain publishes a
single patch with the message from the first commit, instead of a
patchset,
* in either case, the patch summary is replicated both as email subject
and as first line of the email itself, resulting in a doubled summary
if the output is fed to git-am.
We thus create a new view that can be fed to git-am directly by exposing
the output of git format-patch directly. This allows patch exchange and
submission via gitweb. A hard limit (configurable, defaults to 100) is
imposed on the number of commits which will be included in a patchset,
to prevent DoS attacks on the server.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 30 +++++++++++++++++++++++++++++-
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 5a69a41..dbf414c 100644
--- a/Makefile
+++ b/Makefile
@@ -220,6 +220,7 @@ GITWEB_LOGO = git-logo.png
GITWEB_FAVICON = git-favicon.png
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
+GITWEB_PATCH_MAX = 100
export prefix bindir sharedir htmldir sysconfdir
@@ -1210,6 +1211,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
-e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
-e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
+ -e 's|++GITWEB_PATCH_MAX++|$(GITWEB_PATCH_MAX)|g' \
$< >$@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2738643..10cbe93 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -87,6 +87,9 @@ our $projects_list = "++GITWEB_LIST++";
# the width (in characters) of the projects list "Description" column
our $projects_list_description_width = 25;
+# the maximum number of patches allowed in patch view
+our $patch_max = "++GITWEB_PATCH_MAX++";
+
# default order of projects list
# valid values are none, project, descr, owner, and age
our $default_projects_order = "project";
@@ -503,6 +506,7 @@ our %actions = (
"heads" => \&git_heads,
"history" => \&git_history,
"log" => \&git_log,
+ "patch" => \&git_patch,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5483,7 +5487,12 @@ sub git_commitdiff {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
'-p', $hash_parent_param, $hash, "--"
or die_error(500, "Open git-diff-tree failed");
-
+ } elsif ($format eq 'patch') {
+ open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
+ '--stdout', "-$patch_max",
+ $hash_parent ? ('-n', "$hash_parent..$hash") :
+ ('--root', '-1', $hash)
+ or die_error(500, "Open git-format-patch failed");
} else {
die_error(400, "Unknown commitdiff format");
}
@@ -5532,6 +5541,15 @@ sub git_commitdiff {
print to_utf8($line) . "\n";
}
print "---\n\n";
+ } elsif ($format eq 'patch') {
+ my $filename = basename($project) . "-$hash.patch";
+
+ print $cgi->header(
+ -type => 'text/plain',
+ -charset => 'utf-8',
+ -expires => $expires,
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
+ # TODO add X-Git-Tag/X-Git-Url headers in a sensible way
}
# write patch
@@ -5553,6 +5571,11 @@ sub git_commitdiff {
print <$fd>;
close $fd
or print "Reading git-diff-tree failed\n";
+ } elsif ($format eq 'patch') {
+ local $/ = undef;
+ print <$fd>;
+ close $fd
+ or print "Reading git-format-patch failed\n";
}
}
@@ -5560,6 +5583,11 @@ sub git_commitdiff_plain {
git_commitdiff('plain');
}
+# format-patch-style patches
+sub git_patch {
+ git_commitdiff('patch');
+}
+
sub git_history {
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
--
1.5.6.5
^ permalink raw reply related
* [RFCv2 2/2] gitweb: links to patch action in commitdiff and shortlog view
From: Giuseppe Bilotta @ 2008-12-03 10:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1228298862-28191-2-git-send-email-giuseppe.bilotta@gmail.com>
In shortlog view, a link to the patchset is only offered when the number
of commits shown is less than the allowed maximum number of patches.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10cbe93..aea0e07 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5403,7 +5403,9 @@ sub git_commitdiff {
if ($format eq 'html') {
$formats_nav =
$cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
- "raw");
+ "raw") . " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
if (defined $hash_parent &&
$hash_parent ne '-c' && $hash_parent ne '--cc') {
@@ -5938,6 +5940,11 @@ sub git_shortlog {
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
+ if ($#commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ $#commitlist > 1 ? "patchset" : "patch");
+ }
git_header_html();
git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
From: Jakub Narebski @ 2008-12-03 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
In-Reply-To: <7v63m1j4ke.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Use new insert_file() subroutine to insert HTML chunks from external
> > files: $site_header, $home_text (by default indextext.html),
> > $site_footer, and $projectroot/$project/REAME.html.
> >
> > All non-ASCII chars of those files will be broken by Perl IO layer
> > without decoding to utf8, so insert_file() does to_utf8() on each
> > printed line; alternate solution would be to open those files with
> > "binmode $fh, ':utf8'", or even all files with "use open qw(:std :utf8)".
> > This is more complete solution that the one provided by Tatsuki Sugiura
> > in original patch
> >
> > [PATCH] gitweb: fix encode handling for site_{header,footer}
> > Msg-Id: <87vdumbxgc.wl@vaj-k-334-sugi.local.valinux.co.jp>
> > http://thread.gmane.org/gmane.comp.version-control.git/101199
>
> It may be more complete but it is obviously untested. Please help me
> trust you better with your future patches. Because I personally do not
> run gitweb myself, I really need a trustworthy lieutenant(s) in the area.
>
> [Wed Dec 3 01:52:07 2008] gitweb.perl: Global symbol "$fd" requires explicit package name at /git.git/t/../gitweb/gitweb.perl line 4500.
> [Wed Dec 3 01:52:07 2008] gitweb.perl: Execution of /git.git/t/../gitweb/gitweb.perl aborted due to compilation errors.
>
> > but it is in principle the same solution.
> >
> > I think this one as it is a bugfix should go in git 1.6.1
>
> Trading a gitweb with a small bug with a gitweb that does not even pass
> its test script does not feel like a good change to me.
>
> I think the breakage is the "close $fd" at the end of this hunk:
[...]
> I'll queue it to 'pu', with the "close $fd" removed, for now.
I'm very sorry about that. It was a bit of time since my last patch
sent, and I forgot that nevermind how obvious and simple the change,
one should run relevant parts of test suite, or at least try to run
gitweb / changed command.
With "close $fd" removed the patch is correct (and patches t9500*).
--
Jakub Narebski
Poland
^ permalink raw reply
* Is there a way to control the number of revisions will be saved by git
From: Tzury Bar Yochay @ 2008-12-03 11:01 UTC (permalink / raw)
To: git
Hello Happy Gitters,
Say I wish to save only 100 generations back (per branch).
Is it possible to configure git so it will save only N records back.
If git cannot be configured for that, Is there a way to shrink the repository
manually so it will contain the last N generations?
- Tzury
^ 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