* Re: git pull versus fetch/merge
From: Jeff King @ 2008-07-21 11:09 UTC (permalink / raw)
To: Rene Herman; +Cc: Björn Steinbrink, git, Takashi Iwai
In-Reply-To: <48846BC2.4090407@keyaccess.nl>
On Mon, Jul 21, 2008 at 12:58:10PM +0200, Rene Herman wrote:
> Thank you. Also due to a reply on the ALSA list by Mark brown I now get
> this. Yes, the remote was rebased while I had it setup as a remote here
> it seems; only recently have it under this name, so I didn't think that
> was the case. After a "git remote rm tiwai, git remote add tiwai <url>"
> things work fine again as it fetched a completely new branch.
Not that adding the remote with "git remote add" will add a fetchspec
line like this:
[remote "tiwai"]
fetch = +refs/heads/*:+refs/remotes/tiwai/*
where the '+' means to force fetching rewound branches instead of
rejecting them (this is safe, since you are just overwriting tracking
branches, not your local work). So this should not come up again;
presumably your previous remote configuration was set up differently.
-Peff
^ permalink raw reply
* Re: [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Jeff King @ 2008-07-21 11:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Fredrik Tolf, git
In-Reply-To: <alpine.DEB.1.00.0807211255010.3305@eeepc-johanness>
On Mon, Jul 21, 2008 at 12:56:14PM +0200, Johannes Schindelin wrote:
> > or syntax used in RPM spec macros
> >
> > %{?p:-P %p}
> >
> > (and there is complementing %{!?<var>:<expansion>} in RPM spec macro
> > language).
>
> Yes, this is overkill. I would even have passed the port argument
> _always_, since the port 22 for ssh is as likely to change as hell will
> not freeze over. Actually, I am not so sure about the latter.
But keep in mind that "-p 22" on the command line _overrides_ what the
user has in their ssh config, so it is not a good idea to pass it all
the time.
-Peff
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Michael J Gruber @ 2008-07-21 10:59 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90807201450w57fdb523m42bc628f2dce7f87@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
Martin Langhoff venit, vidit, dixit 20.07.2008 23:50:
> On Fri, Jul 18, 2008 at 10:39 PM, Petr Baudis <pasky@suse.cz> wrote:
>> On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
>>> http://baldwindev.com/git.or.cz/
>> I'm not sure if this is really an improvement on the current state,
>> but then again, the current state pretty much matches my idea and maybe
>> others will agree that your proposal is better. Thus, it's better to
>> show this to the Git community at large. :-)
>
> FWIW, I like it. I like both the better font and whitespace layout and
> the 3-color-spot-merge-to-white. As Petr says, we have had the
> (apologies, but to me) ugly logo for a while, so it is widely used,
> and perhaps it has even grown on people.
>
> BazaarNG managed to grab the best concept logo of the lot, IMHO, with
> the 'merge' roadsign.
>
>> If you think you have a cooler logo, that's fine too, but then it's
>> again better to present it explicitly, I believe.
>
> Can we separate the 2 things? The better fonts and layout look like a win to me.
>
> WRT the logo, the current one is not a particularly strong image, and
> we haven't spent millions in plastering it over magazines or anything.
> So a good new logo would be something to take on.
I like that new logo (plusminus G), too, it's very descriptive. I just
want to raise one question which I can't answer myself:
Are there any potential issues with the Helvetica license?
In any case it may be safer do redo it with a GPL sans serif font. If
one wants to keep the association of the shape of "G" with a circular
arrow then FreeSans and Nimbus Sans L seem to be the only options.
Alternatively, it may be easier to redo it in plain PS. I'll attach 2
KISS variants. 1.5k for the eps, 3 colors only.
Cheers,
Michael
[-- Attachment #2: gitlogo.png --]
[-- Type: image/png, Size: 2034 bytes --]
[-- Attachment #3: gitlogo2.png --]
[-- Type: image/png, Size: 2034 bytes --]
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-21 10:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20080718154959.GS10151@machine.or.cz>
> In that case you would need the "URL mappings", perhaps as a per-remote
> attribute. That is, you could configure:
>
> "When I am doing git pull fred, do git submodule update but
> apply remote.fred.subrewrite sed script on each URL before
> fetching the submodule."
>
> Still, that feels quite hackish to me, and I'm not convinced that your
> workflow cannot be adjusted so that users merge only the next-to-last
> commit of a branch instead of the last one.
>
Hm - I'm still disliking having 'special' commits to change
.gitmodules. I can hack scripts to make it work, but it would be nice
to have a UI that is generally useful.
Thinking out loud, could we have in .git/config something like
[submodule "moduleA"]
url = git://origin.com/path/to/.git # Current place of origin
fred.url = git://fredcomputer/path/to/freds/moduleA.git # where
fred declares moduleA to come from
local = git://myhost/working/copy/super/moduleA/.git # where other
people can get access to *my* moduleA repo
So if I look in the git repository of fred (as specified in my [remote
"fred"], I can see their "local" entry, and enter that as fred.url in
my config
And the ability to do (e.g)
$ git submodule init fred
$ git submodule update fred
?
^ permalink raw reply
* Re: git pull versus fetch/merge
From: Rene Herman @ 2008-07-21 10:58 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Takashi Iwai
In-Reply-To: <20080721102320.GA19776@atjola.homenet>
On 21-07-08 12:23, Björn Steinbrink wrote:
> Your fetch/merge approach was different from what your pull approach
> did. tiwai/devel did not get updated by the fetch, which means that
> you tried to merge the old state of that branch and that caused some
> conflicts. OTOH the pull did fetch the latest state from the remote
> repo and merged that cleanly.
>
> Your fetch/merge approach was more like "git pull" without any
> arguments, but with the current branch setup to track tiwai/devel. In
> that case, pull really does a "git fetch tiwai", and it should fail
> in the same way.
Thank you. Also due to a reply on the ALSA list by Mark brown I now get
this. Yes, the remote was rebased while I had it setup as a remote here
it seems; only recently have it under this name, so I didn't think that
was the case. After a "git remote rm tiwai, git remote add tiwai <url>"
things work fine again as it fetched a completely new branch.
Hurray for rebasing public trees. This specific branch should be rebased
only at every kernel release so I guess it's okay. I guess I can just do
the git pull always, or the fetch every time and let the reject warn me
that it was rebased after which I'll do the remote rm/add thing again.
Many thanks for the concrete description of what goes on. Made it obvious.
Rene.
^ permalink raw reply
* Re: [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-21 10:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Fredrik Tolf, git
In-Reply-To: <m3fxq3ws16.fsf@localhost.localdomain>
Hi,
On Mon, 21 Jul 2008, Jakub Narebski wrote:
> Fredrik Tolf <fredrik@dolda2000.com> writes:
>
> > [...] Here's some makeshift documentation:
> >
> > The string specified in core.sshcommand is first checked if it matches
> > any of the built-in templates, in which case it is expanded (I've added
> > the templates "openssh" and "plink" by default). When used, the string
> > is split into words, each of which is processed as follows:
> >
> > * If a word is %p, it is replaced by the port number, if specified.
> > If the port number is not specified, the word is deleted.
> > * If a word is %h, it is replaced by the remote host name.
> > * If a word begins with %P, it is deleted if no port number is
> > specified. This is to allow for specifying different port number
> > flags for different SSH implementations. The syntax is a bit ugly,
> > but I cannot really think of anything that would look better.
> > If a port number has been specified, the leading %P is simply deleted.
>
> There is a syntax which would look better, but perhaps it is a bit
> overkill in this situation. Namely use either shell conditional
> expansion:
>
> ${p:+-P $p}
>
> or syntax used in RPM spec macros
>
> %{?p:-P %p}
>
> (and there is complementing %{!?<var>:<expansion>} in RPM spec macro
> language).
Yes, this is overkill. I would even have passed the port argument
_always_, since the port 22 for ssh is as likely to change as hell will
not freeze over. Actually, I am not so sure about the latter.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Rename .git/rebase to .git/rebase-apply
From: Johannes Schindelin @ 2008-07-21 10:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3k5ffwsma.fsf@localhost.localdomain>
With git-am, it sounds awkward to have the patches in ".git/rebase/",
but for technical reasons, we have to keep the same directory name
for git-am and git-rebase. ".git/rebase-apply" seems to be a good
compromise.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 21 Jul 2008, Jakub Narebski wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > * The ".dotest" temporary area "git am" and "git rebase" use
> > will be moved to $GIT_DIR/rebase. We might change it to
> > $GIT_DIR/rebase-apply which would be more logical name before
> > the final, though.
>
> Very good idea. $GIT_DIR/rebase looks slightly strange with git-am.
Since I was responsible for the patch in the first place, here is
a follow-up patch to imlement the rebase-apply thing.
Documentation/SubmittingPatches | 2 +-
Documentation/git-am.txt | 4 +-
Documentation/git-rebase.txt | 4 +-
Documentation/user-manual.txt | 2 +-
contrib/completion/git-completion.bash | 10 +++---
contrib/emacs/git.el | 8 ++--
git-am.sh | 2 +-
git-quiltimport.sh | 2 +-
git-rebase.sh | 48 ++++++++++++++++---------------
t/t3401-rebase-partial.sh | 2 +-
t/t3407-rebase-abort.sh | 2 +-
t/t4150-am.sh | 22 +++++++-------
t/t9106-git-svn-commit-diff-clobber.sh | 4 ++-
13 files changed, 58 insertions(+), 54 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index fdfa536..841bead 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -301,7 +301,7 @@ If it does not apply correctly, there can be various reasons.
patch appropriately.
* Your MUA corrupted your patch; "am" would complain that
- the patch does not apply. Look at .git/rebase/ subdirectory and
+ the patch does not apply. Look at .git/rebase-apply/ subdirectory and
see what 'patch' file contains and check for the common
corruption patterns mentioned above.
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index e010a16..ee335ae 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -143,9 +143,9 @@ aborts in the middle,. You can recover from this in one of two ways:
the index file to bring it in a state that the patch should
have produced. Then run the command with '--resolved' option.
-The command refuses to process new mailboxes while `.git/rebase`
+The command refuses to process new mailboxes while `.git/rebase-apply`
directory exists, so if you decide to start over from scratch,
-run `rm -f -r .git/rebase` before running the command with mailbox
+run `rm -f -r .git/rebase-apply` before running the command with mailbox
names.
Before any patches are applied, ORIG_HEAD is set to the tip of the
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 51afc87..0764b3c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -39,8 +39,8 @@ It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
and run `git rebase --continue`. Another option is to bypass the commit
that caused the merge failure with `git rebase --skip`. To restore the
-original <branch> and remove the .git/rebase working files, use the command
-`git rebase --abort` instead.
+original <branch> and remove the .git/rebase-apply working files, use the
+command `git rebase --abort` instead.
Assume the following history exists and the current branch is "topic":
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 8761ee7..c5641af 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2431,7 +2431,7 @@ $ git rebase origin
-------------------------------------------------
This will remove each of your commits from mywork, temporarily saving
-them as patches (in a directory named ".git/rebase"), update mywork to
+them as patches (in a directory named ".git/rebase-apply"), update mywork to
point at the latest version of origin, then apply each of the saved
patches to the new mywork. The result will look like:
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 29f6cd4..2edb341 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -73,12 +73,12 @@ __git_ps1 ()
if [ -n "$g" ]; then
local r
local b
- if [ -d "$g/rebase" ]
+ if [ -d "$g/rebase-apply" ]
then
- if test -f "$g/rebase/rebasing"
+ if test -f "$g/rebase-apply/rebasing"
then
r="|REBASE"
- elif test -f "$g/rebase/applying"
+ elif test -f "$g/rebase-apply/applying"
then
r="|AM"
else
@@ -488,7 +488,7 @@ __git_whitespacelist="nowarn warn error error-all strip"
_git_am ()
{
local cur="${COMP_WORDS[COMP_CWORD]}" dir="$(__gitdir)"
- if [ -d "$dir"/rebase ]; then
+ if [ -d "$dir"/rebase-apply ]; then
__gitcomp "--skip --resolved"
return
fi
@@ -915,7 +915,7 @@ _git_push ()
_git_rebase ()
{
local cur="${COMP_WORDS[COMP_CWORD]}" dir="$(__gitdir)"
- if [ -d "$dir"/rebase ] || [ -d "$dir"/rebase-merge ]; then
+ if [ -d "$dir"/rebase-apply ] || [ -d "$dir"/rebase-merge ]; then
__gitcomp "--continue --skip --abort"
return
fi
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 43b059b..c1cf1cb 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1252,8 +1252,8 @@ Return the list of files that haven't been handled."
"\n")
(when subject (insert subject "\n\n"))
(cond (msg (insert msg "\n"))
- ((file-readable-p ".git/rebase/msg")
- (insert-file-contents ".git/rebase/msg"))
+ ((file-readable-p ".git/rebase-apply/msg")
+ (insert-file-contents ".git/rebase-apply/msg"))
((file-readable-p ".git/MERGE_MSG")
(insert-file-contents ".git/MERGE_MSG")))
; delete empty lines at end
@@ -1272,9 +1272,9 @@ Return the list of files that haven't been handled."
(coding-system (git-get-commits-coding-system))
author-name author-email subject date)
(when (eq 0 (buffer-size buffer))
- (when (file-readable-p ".git/rebase/info")
+ (when (file-readable-p ".git/rebase-apply/info")
(with-temp-buffer
- (insert-file-contents ".git/rebase/info")
+ (insert-file-contents ".git/rebase-apply/info")
(goto-char (point-min))
(when (re-search-forward "^Author: \\(.*\\)\nEmail: \\(.*\\)$" nil t)
(setq author-name (match-string 1))
diff --git a/git-am.sh b/git-am.sh
index 60aaa4a..9bf12fe 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -121,7 +121,7 @@ It does not apply to blobs recorded in its index."
}
prec=4
-dotest="$GIT_DIR/rebase"
+dotest="$GIT_DIR/rebase-apply"
sign= utf8=t keep= skip= interactive= resolved= binary= rebasing= abort=
resolvemsg= resume=
git_apply_opt=
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index c9aecfd..cebaee1 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -53,7 +53,7 @@ if ! [ -d "$QUILT_PATCHES" ] ; then
fi
# Temporary directories
-tmp_dir="$GIT_DIR"/rebase
+tmp_dir="$GIT_DIR"/rebase-apply
tmp_msg="$tmp_dir/msg"
tmp_patch="$tmp_dir/patch"
tmp_info="$tmp_dir/info"
diff --git a/git-rebase.sh b/git-rebase.sh
index 6ef5754..412e135 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -14,8 +14,8 @@ It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
and run git rebase --continue. Another option is to bypass the commit
that caused the merge failure with git rebase --skip. To restore the
-original <branch> and remove the .git/rebase working files, use the command
-git rebase --abort instead.
+original <branch> and remove the .git/rebase-apply working files, use the
+command git rebase --abort instead.
Note that if <branch> is not specified on the command line, the
currently checked out branch is used.
@@ -150,7 +150,7 @@ while test $# != 0
do
case "$1" in
--continue)
- test -d "$dotest" -o -d "$GIT_DIR"/rebase ||
+ test -d "$dotest" -o -d "$GIT_DIR"/rebase-apply ||
die "No rebase in progress?"
git diff-files --quiet --ignore-submodules || {
@@ -173,15 +173,15 @@ do
finish_rb_merge
exit
fi
- head_name=$(cat "$GIT_DIR"/rebase/head-name) &&
- onto=$(cat "$GIT_DIR"/rebase/onto) &&
- orig_head=$(cat "$GIT_DIR"/rebase/orig-head) &&
+ head_name=$(cat "$GIT_DIR"/rebase-apply/head-name) &&
+ onto=$(cat "$GIT_DIR"/rebase-apply/onto) &&
+ orig_head=$(cat "$GIT_DIR"/rebase-apply/orig-head) &&
git am --resolved --3way --resolvemsg="$RESOLVEMSG" &&
move_to_original_branch
exit
;;
--skip)
- test -d "$dotest" -o -d "$GIT_DIR"/rebase ||
+ test -d "$dotest" -o -d "$GIT_DIR"/rebase-apply ||
die "No rebase in progress?"
git reset --hard HEAD || exit $?
@@ -201,15 +201,15 @@ do
finish_rb_merge
exit
fi
- head_name=$(cat "$GIT_DIR"/rebase/head-name) &&
- onto=$(cat "$GIT_DIR"/rebase/onto) &&
- orig_head=$(cat "$GIT_DIR"/rebase/orig-head) &&
+ head_name=$(cat "$GIT_DIR"/rebase-apply/head-name) &&
+ onto=$(cat "$GIT_DIR"/rebase-apply/onto) &&
+ orig_head=$(cat "$GIT_DIR"/rebase-apply/orig-head) &&
git am -3 --skip --resolvemsg="$RESOLVEMSG" &&
move_to_original_branch
exit
;;
--abort)
- test -d "$dotest" -o -d "$GIT_DIR"/rebase ||
+ test -d "$dotest" -o -d "$GIT_DIR"/rebase-apply ||
die "No rebase in progress?"
git rerere clear
@@ -217,7 +217,7 @@ do
then
move_to_original_branch
else
- dotest="$GIT_DIR"/rebase
+ dotest="$GIT_DIR"/rebase-apply
move_to_original_branch
fi
git reset --hard $(cat "$dotest/orig-head")
@@ -265,18 +265,20 @@ do
shift
done
-# Make sure we do not have $GIT_DIR/rebase
+# Make sure we do not have $GIT_DIR/rebase-apply
if test -z "$do_merge"
then
- if mkdir "$GIT_DIR"/rebase
+ if mkdir "$GIT_DIR"/rebase-apply
then
- rmdir "$GIT_DIR"/rebase
+ rmdir "$GIT_DIR"/rebase-apply
else
echo >&2 '
-It seems that I cannot create a '"$GIT_DIR"'/rebase directory, and I wonder if you
-are in the middle of patch application or another rebase. If that is not
-the case, please rm -fr '"$GIT_DIR"'/rebase and run me again. I am stopping in case
-you still have something valuable there.'
+It seems that I cannot create a '"$GIT_DIR"'/rebase-apply directory,
+and I wonder if you are in the middle of patch application or another
+rebase. If that is not the case, please
+ rm -fr '"$GIT_DIR"'/rebase-apply
+ and run me again. I am stopping in case you still have something
+valuable there.'
exit 1
fi
else
@@ -395,10 +397,10 @@ then
git am $git_am_opt --rebasing --resolvemsg="$RESOLVEMSG" &&
move_to_original_branch
ret=$?
- test 0 != $ret -a -d "$GIT_DIR"/rebase &&
- echo $head_name > "$GIT_DIR"/rebase/head-name &&
- echo $onto > "$GIT_DIR"/rebase/onto &&
- echo $orig_head > "$GIT_DIR"/rebase/orig-head
+ test 0 != $ret -a -d "$GIT_DIR"/rebase-apply &&
+ echo $head_name > "$GIT_DIR"/rebase-apply/head-name &&
+ echo $onto > "$GIT_DIR"/rebase-apply/onto &&
+ echo $orig_head > "$GIT_DIR"/rebase-apply/orig-head
exit $ret
fi
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 36d9a2a..166ddb1 100755
--- a/t/t3401-rebase-partial.sh
+++ b/t/t3401-rebase-partial.sh
@@ -50,7 +50,7 @@ test_debug \
test_expect_success \
'rebase topic branch against new master and check git-am did not get halted' \
- 'git-rebase master && test ! -d .git/rebase'
+ 'git-rebase master && test ! -d .git/rebase-apply'
test_expect_success \
'rebase --merge topic branch that was partially merged upstream' \
diff --git a/t/t3407-rebase-abort.sh b/t/t3407-rebase-abort.sh
index 12c8804..4de550a 100755
--- a/t/t3407-rebase-abort.sh
+++ b/t/t3407-rebase-abort.sh
@@ -74,7 +74,7 @@ testrebase() {
'
}
-testrebase "" .git/rebase
+testrebase "" .git/rebase-apply
testrebase " --merge" .git/rebase-merge
test_done
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 98ba020..6e6aaf5 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -102,7 +102,7 @@ test_expect_success 'am applies patch correctly' '
git checkout first &&
test_tick &&
git am <patch1 &&
- ! test -d .git/rebase &&
+ ! test -d .git/rebase-apply &&
test -z "$(git diff second)" &&
test "$(git rev-parse second)" = "$(git rev-parse HEAD)" &&
test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)"
@@ -123,7 +123,7 @@ test_expect_success 'am changes committer and keeps author' '
test_tick &&
git checkout first &&
git am patch2 &&
- ! test -d .git/rebase &&
+ ! test -d .git/rebase-apply &&
test "$(git rev-parse master^^)" = "$(git rev-parse HEAD^^)" &&
test -z "$(git diff master..HEAD)" &&
test -z "$(git diff master^..HEAD^)" &&
@@ -163,7 +163,7 @@ test_expect_success 'am without --keep removes Re: and [PATCH] stuff' '
test_expect_success 'am --keep really keeps the subject' '
git checkout HEAD^ &&
git am --keep patch4 &&
- ! test -d .git/rebase &&
+ ! test -d .git/rebase-apply &&
git-cat-file commit HEAD |
grep -q -F "Re: Re: Re: [PATCH 1/5 v2] third"
'
@@ -176,19 +176,19 @@ test_expect_success 'am -3 falls back to 3-way merge' '
test_tick &&
git commit -m "copied stuff" &&
git am -3 lorem-move.patch &&
- ! test -d .git/rebase &&
+ ! test -d .git/rebase-apply &&
test -z "$(git diff lorem)"
'
test_expect_success 'am pauses on conflict' '
git checkout lorem2^^ &&
test_must_fail git am lorem-move.patch &&
- test -d .git/rebase
+ test -d .git/rebase-apply
'
test_expect_success 'am --skip works' '
git am --skip &&
- ! test -d .git/rebase &&
+ ! test -d .git/rebase-apply &&
test -z "$(git diff lorem2^^ -- file)" &&
test goodbye = "$(cat another)"
'
@@ -196,31 +196,31 @@ test_expect_success 'am --skip works' '
test_expect_success 'am --resolved works' '
git checkout lorem2^^ &&
test_must_fail git am lorem-move.patch &&
- test -d .git/rebase &&
+ test -d .git/rebase-apply &&
echo resolved >>file &&
git add file &&
git am --resolved &&
- ! test -d .git/rebase &&
+ ! test -d .git/rebase-apply &&
test goodbye = "$(cat another)"
'
test_expect_success 'am takes patches from a Pine mailbox' '
git checkout first &&
cat pine patch1 | git am &&
- ! test -d .git/rebase &&
+ ! test -d .git/rebase-apply &&
test -z "$(git diff master^..HEAD)"
'
test_expect_success 'am fails on mail without patch' '
test_must_fail git am <failmail &&
- rm -r .git/rebase/
+ rm -r .git/rebase-apply/
'
test_expect_success 'am fails on empty patch' '
echo "---" >>failmail &&
test_must_fail git am <failmail &&
git am --skip &&
- ! test -d .git/rebase
+ ! test -d .git/rebase-apply
'
test_expect_success 'am works from stdin in subdirectory' '
diff --git a/t/t9106-git-svn-commit-diff-clobber.sh b/t/t9106-git-svn-commit-diff-clobber.sh
index 08bf1f0..83896e9 100755
--- a/t/t9106-git-svn-commit-diff-clobber.sh
+++ b/t/t9106-git-svn-commit-diff-clobber.sh
@@ -87,7 +87,9 @@ test_expect_success 'multiple dcommit from git-svn will not clobber svn' "
"
-test_expect_success 'check that rebase really failed' 'test -d .git/rebase'
+test_expect_success 'check that rebase really failed' '
+ test -d .git/rebase-apply
+'
test_expect_success 'resolve, continue the rebase and dcommit' "
echo clobber and I really mean it > file &&
--
1.5.6.2.516.g22071
^ permalink raw reply related
* Re: problem using jgit
From: Marek Zawirski @ 2008-07-21 10:41 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git, Robin Rosenberg, Shawn O. Pearce
In-Reply-To: <p06240809c4a9d887fda4@[192.168.1.106]>
Stephen Bannasch wrote:
> I've setup a simple test class that integrates jgit to clone a git
> repository. However I'm getting a NullPointerError when
> RevWalk.parseAny ends up producing a null object id.
>
> The code and the stack trace for the error are here:
>
> http://pastie.org/237711
>
> This problem occurs using the jgit from the master branch from this repo:
>
> git://repo.or.cz/egit.git
Hello Stephen,
I think you've experienced error caused by the same bug as me, during my
latest fetch/push GUI works few days ago.
Your code looks fine, probably it's actually bug in jgit. I think it's
some regression. Thanks for reporting.
I'll try to look at this problem or jgit fetch experts (Robin and Shawn)
will have a look when they come back.
Marek
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Petr Baudis @ 2008-07-21 10:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Sam Vilain, git, Joshua Roys
In-Reply-To: <200807211223.45707.jnareb@gmail.com>
On Mon, Jul 21, 2008 at 12:23:45PM +0200, Jakub Narebski wrote:
> [*1*] "the current implementation is quite slow (requiring two calls to
> 'git-cat-file' for each object)" <-- why you don't use '--batch' or
> '--batch-check' options to git cat file: see also Git::Repo and friends
> implementation send by Lea Wiemann to git mailing list as part of
> "Gitweb caching" project? BTW. by keeping discussion off the list,
> you are off the knowledge of git community, too.
I concur. Only now I realized that this project might be an important
Git Perl API user. Can you please reconsider having a separate mailing
list for discussions etc.? The traffic seems to be very low anyway, and
I'm not sure what benefits does it actually have at all.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Jakub Narebski @ 2008-07-21 10:23 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Joshua Roys
In-Reply-To: <1216601739.6523.48.camel@maia.lan>
On Mon, 21 July 2008, Sam Vilain wrote:
> On Mon, 2008-07-21 at 00:29 +0200, Jakub Narebski wrote:
> >
> > 1. GitTorrent
> >
> > Student: Joshua Roys
> > Mentor: Sam Vilain
> >
> > I never got more response than "it is going slower than I would like,
> > [...] Other than that, it's going well, I think." from Joshua Roys.
>
> > Mailing list archives for gittorrent mailing list doesn't show anything
> > interesting, either (last post is from 2007).
> > http://lists.utsl.gen.nz/pipermail/gittorrent/
>
> That's a valid complaint. I've posted a summary of the project status
> there, and will keep as much related discussion as appropriate on-list
> from here.
You can find it on GMane, too:
http://thread.gmane.org/gmane.comp.version-control.git.gittorrent/1
It would be nice if it was send to git mailing list too, perhaps
directing replies to gittorrent mailing list only by default.
A short summary of this thread (please correct me if I am wrong):
* Tracker: representing "metainfo" files, working tracker (test)
is in progress
* Core infrastructure: "Commit Reel" sorting algorithm implemented[1]
B-tree index for fast querying.
To be done is determining minimal set of edge objects which define
reel (that can be passed to "git rev-list --objects-edge" to get thin
pack representing reel).
* Peer to Peer: handshake and two trivial messages[2] implemented.
To be done are (minimally) "References", "Blocks", "Request" and
"Play" messages.
Footnotes:
==========
[*1*] "the current implementation is quite slow (requiring two calls to
'git-cat-file' for each object)" <-- why you don't use '--batch' or
'--batch-check' options to git cat file: see also Git::Repo and friends
implementation send by Lea Wiemann to git mailing list as part of
"Gitweb caching" project? BTW. by keeping discussion off the list,
you are off the knowledge of git community, too.
[*2*] _What_ are those "two trivial messages"?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git pull versus fetch/merge
From: Björn Steinbrink @ 2008-07-21 10:23 UTC (permalink / raw)
To: Rene Herman; +Cc: git, Takashi Iwai
In-Reply-To: <488452D6.1060508@keyaccess.nl>
On 2008.07.21 11:11:50 +0200, Rene Herman wrote:
> Good day.
>
> A while ago I was here asking about "git pull" versus "git merge" for
> local branches -- now I see a difference for remote ones that I'm not
> sure should be there.
>
> I gathered before that "git pull <remote> <branch>" should basically be
> shorthand for "git fetch <remote>, git merge <remote>/<branch>". Is that
> correct?
>
> I'm seeing a problem I believe with a specific repository:
>
> rene@7ixe4:~/src/linux/7ixe4$ git remote show tiwai
> * remote tiwai
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
> Tracked remote branches
> devel dma-fix for-linus master upstream
>
> with "git pull tiwai devel" everything goes well:
>
> rene@7ixe4:~/src/linux/7ixe4$ git status
> # On branch master
> nothing to commit (working directory clean)
> rene@7ixe4:~/src/linux/7ixe4$ git branch tmp0 v2.6.26
> rene@7ixe4:~/src/linux/7ixe4$ git branch tmp1 v2.6.26
> rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp0
> Switched to branch "tmp0"
> rene@7ixe4:~/src/linux/7ixe4$ git pull tiwai devel
> Updating bce7f79..e0bf09b
> Fast forward
> Documentation/sound/alsa/ALSA-Configuration.txt | 17 +-
> [ ... ]
>
> and I get a clean merge.
"git pull remote branch" does "git fetch remote branch". That only
fetches that single branch and stores it in FETCH_HEAD. The merge part
then merges what is in FETCH_HEAD into your current branch.
> On the other hand, if I try to do this with a fetch/merge, I get:
>
> rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp1
> Switched to branch "tmp1"
> rene@7ixe4:~/src/linux/7ixe4$ git fetch tiwai
> From git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
> ! [rejected] devel -> tiwai/devel (non fast forward)
> ! [rejected] dma-fix -> tiwai/dma-fix (non fast forward)
> ! [rejected] master -> tiwai/master (non fast forward)
The rejected branches had their history rewritten since your last fetch.
Git rejects to update your remote tracking branches in that case. The
history rewriting might have been an accident, or it might have been
intentional. Only the owner of that repo is able to tell that.
You can use -f to force the updates.
> rene@7ixe4:~/src/linux/7ixe4$ git merge tiwai/devel
> Auto-merged sound/pci/ac97/ac97_patch.c
> Auto-merged sound/pci/emu10k1/emu10k1_main.c
> Auto-merged sound/pci/hda/patch_analog.c
> Auto-merged sound/pci/hda/patch_realtek.c
> CONFLICT (content): Merge conflict in sound/pci/hda/patch_realtek.c
> Auto-merged sound/pci/hda/patch_sigmatel.c
> Automatic merge failed; fix conflicts and then commit the result.
>
> and me no happy...
>
> It probably has something to do with that " ! [rejected]" but what is
> that about? Is the repo bad? (and if so, I suspect owner will want to
> know how to avoid it in the future).
>
> And if it is bad, should I be seeing something with the pull method
> also? Moreover... can I now trust my tmp0 branch?
Your fetch/merge approach was different from what your pull approach
did. tiwai/devel did not get updated by the fetch, which means that you
tried to merge the old state of that branch and that caused some
conflicts. OTOH the pull did fetch the latest state from the remote repo
and merged that cleanly.
Your fetch/merge approach was more like "git pull" without any
arguments, but with the current branch setup to track tiwai/devel. In
that case, pull really does a "git fetch tiwai", and it should fail in
the same way.
Björn
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Johannes Schindelin @ 2008-07-21 10:21 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <20080721063332.GA15596@artemis.madism.org>
Hi,
On Mon, 21 Jul 2008, Pierre Habouzit wrote:
> On Sun, Jul 20, 2008 at 09:05:30PM +0000, Junio C Hamano wrote:
> > Miklos Vajna <vmiklos@frugalware.org> writes:
> >
> > > So here is what I thought about: What about if everyone (except Junio,
> > > of course) would change the subject _and_ remove the In-Reply-To: header
> > > when replying to those mails?
> > >
> > > If those large threads just annoys a few people and most people are
> > > happy with the current situation then sorry for the noise.
> >
> > I could make "What's cooking" not a follow-up to the previous issue,
>
> That'd be great, especially since it's trivial with decent MUAs to get
> all issues with a filter (l in mutt, kmail/thunderbird has what it
> needs, and I would be surprised if GNUS or pine cannot do that).
But what you lose is the ability to tell "this cooking came directly after
that cooking".
And in the GMane interface, it is sure a nice thing to be able to go back
and forth between cookings in a thread.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Johannes Schindelin @ 2008-07-21 10:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48841E28.9050903@op5.se>
Hi,
[Cc: list trimmed]
On Mon, 21 Jul 2008, Andreas Ericsson wrote:
> Thunderbird's threading is not so advanced as mutt's, so I can't break
> threads so easily.
>
> The most annoying part is that the timebased auto-delete from thunderbird
> means I get a new thread spawning in the middle of an old partially deleted
> one. It can be very confusing.
Last time I checked, Thunderbird was Open Source...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Support copy and rename detection in fast-export.
From: Johannes Schindelin @ 2008-07-21 10:17 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200807211216.01694.angavrilov@gmail.com>
Hi,
On Mon, 21 Jul 2008, Alexander Gavrilov wrote:
> Although it does not matter for Git itself, tools that
> export to systems that explicitly track copies and
> renames can benefit from such information.
>
> This patch makes fast-export output correct action
> logs when -M or -C are enabled.
I like it.
> I'm thinking about Git->SVN conversion, like
> http://repo.or.cz/w/git2svn.git
>
> The trouble with this patch is that old versions of fast-export
> accept -M and -C, but produce garbage if they are specified.
> So the only way for the users to ensure that it is supported is
> to check the git version (or directly test it).
Unfortunately, this is so.
> As a somewhat related question, in which order does fast-export
> output the commits, beside topological? In particular, does it order
> commits on parrallel branches (i.e. not topologically dependent) by
> date?
AFAIR it obeys topological order first, and then date order, by default.
This can be changed by --topo-order.
But before you go and try to support more options with fast-export: Some
options do not make sense, such as --reverse, "a...b", --skip, etc.
I do not even think we need to bother about die()ing with such options:
the user should know what she is doing with fast-export.
Ciao,
Dscho
^ permalink raw reply
* Re: Suggestion: doc restructuring
From: Johannes Schindelin @ 2008-07-21 10:04 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <48842FA8.5070309@op5.se>
Hi,
On Mon, 21 Jul 2008, Andreas Ericsson wrote:
> Junio C Hamano wrote:
>
> > Side note, that was why I suggested us to first think about use cases
> > in our every day work that we still need to resort to the plumbing,
> > so that we can identify what that enhancement would consist of.
>
> Half a year or so ago, there were some mailings to the list along the
> lines of "what git commands do you use?", using the bash history and a
> shell oneliner to dig out some crude intel.
Actually, I did not even like that approach back then. Just because you
happen to be an old-timer and use rev-parse and rev-list frequently does
not mean that you _have_ to use it, or even _should_ use it, or that it
would be good to teach your command lines to a newbie.
Ciao,
Dscho
^ permalink raw reply
* Re: error: hook declined to update refs/heads/master
From: Johannes Schindelin @ 2008-07-21 9:54 UTC (permalink / raw)
To: Jonathan Biolaz; +Cc: git
In-Reply-To: <80F1AC38-8A10-4184-BBFB-870399DE9A3A@sikatizen.com>
Hi,
On Mon, 21 Jul 2008, Jonathan Biolaz wrote:
> $ git push origin master
>
> Counting objects: 1709, done.
> Compressing objects: 100% (1523/1523), done.
> Writing objects: 100% (1709/1709), 1.95 MiB | 3818 KiB/s, done.
> Total 1709 (delta 535), reused 0 (delta 0)
> *** Project description file hasn't been set
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> error: hooks/update exited with error code 1
> error: hook declined to update refs/heads/master
Apparently, you have a hook installed on the remote side which checks for
a valid description, and refuses even updating refs before you set the
description correctly.
Hth,
Dscho
^ permalink raw reply
* error: hook declined to update refs/heads/master
From: Jonathan Biolaz @ 2008-07-21 9:34 UTC (permalink / raw)
To: git
Hye,
I'm trying to make a remote repository on a Mac Osx Server leopard.
I tried many methods to create the remote. First one, I clone my local
repository with the --bare options, then copy this repo on the server
and add the remote to my local repository, Second one, I create an
empty bare repository on the server and then I try to push my local
repository on it.
Everything I'm doing is given my the same error when I try to push to
the server :
$ git push origin master
Counting objects: 1709, done.
Compressing objects: 100% (1523/1523), done.
Writing objects: 100% (1709/1709), 1.95 MiB | 3818 KiB/s, done.
Total 1709 (delta 535), reused 0 (delta 0)
*** Project description file hasn't been set
error: hooks/update exited with error code 1
error: hook declined to update refs/heads/master
To jbiolaz@macpro1.sikalab:/mp1_data/sikatizen/Dev/repo/calame.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'jbiolaz@macpro1.sikalab:/mp1_data/
sikatizen/Dev/repo/calame.git'
I made the same on a linux server ad it's working well (but with
another repository)
I don't know what to do to make this working.
Also, my server Leopard server is driving me crazy, I have to had for
every user a .bashrc which one contain the path to git. I don't find a
way to add this for all user !
I hope someone can help me !!
Thanks !!
Jbiolaz
^ permalink raw reply
* [PATCH] Enable threaded delta search on *BSD and Linux.
From: Pierre Habouzit @ 2008-07-21 9:23 UTC (permalink / raw)
To: git; +Cc: gitster, Pierre Habouzit
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Following the discussion we had 10 days ago, here is a proposal to enable
threaded delta search on systems that are likely to behave properly wrt
memory and CPU usage.
Makefile | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 551bde9..82f89b7 100644
--- a/Makefile
+++ b/Makefile
@@ -565,9 +565,11 @@ EXTLIBS =
ifeq ($(uname_S),Linux)
NO_STRLCPY = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),UnixWare)
CC = cc
@@ -665,6 +667,7 @@ ifeq ($(uname_S),FreeBSD)
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
@@ -672,6 +675,7 @@ ifeq ($(uname_S),OpenBSD)
NEEDS_LIBICONV = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),NetBSD)
ifeq ($(shell expr "$(uname_R)" : '[01]\.'),2)
@@ -680,6 +684,7 @@ ifeq ($(uname_S),NetBSD)
BASIC_CFLAGS += -I/usr/pkg/include
BASIC_LDFLAGS += -L/usr/pkg/lib
ALL_LDFLAGS += -Wl,-rpath,/usr/pkg/lib
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),AIX)
NO_STRCASESTR=YesPlease
--
1.6.0.rc0.137.g986dd
^ permalink raw reply related
* git pull versus fetch/merge
From: Rene Herman @ 2008-07-21 9:11 UTC (permalink / raw)
To: git; +Cc: Takashi Iwai
Good day.
A while ago I was here asking about "git pull" versus "git merge" for
local branches -- now I see a difference for remote ones that I'm not
sure should be there.
I gathered before that "git pull <remote> <branch>" should basically be
shorthand for "git fetch <remote>, git merge <remote>/<branch>". Is that
correct?
I'm seeing a problem I believe with a specific repository:
rene@7ixe4:~/src/linux/7ixe4$ git remote show tiwai
* remote tiwai
URL: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
Tracked remote branches
devel dma-fix for-linus master upstream
with "git pull tiwai devel" everything goes well:
rene@7ixe4:~/src/linux/7ixe4$ git status
# On branch master
nothing to commit (working directory clean)
rene@7ixe4:~/src/linux/7ixe4$ git branch tmp0 v2.6.26
rene@7ixe4:~/src/linux/7ixe4$ git branch tmp1 v2.6.26
rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp0
Switched to branch "tmp0"
rene@7ixe4:~/src/linux/7ixe4$ git pull tiwai devel
Updating bce7f79..e0bf09b
Fast forward
Documentation/sound/alsa/ALSA-Configuration.txt | 17 +-
[ ... ]
and I get a clean merge. On the other hand, if I try to do this with a
fetch/merge, I get:
rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp1
Switched to branch "tmp1"
rene@7ixe4:~/src/linux/7ixe4$ git fetch tiwai
From git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
! [rejected] devel -> tiwai/devel (non fast forward)
! [rejected] dma-fix -> tiwai/dma-fix (non fast forward)
! [rejected] master -> tiwai/master (non fast forward)
rene@7ixe4:~/src/linux/7ixe4$ git merge tiwai/devel
Auto-merged sound/pci/ac97/ac97_patch.c
Auto-merged sound/pci/emu10k1/emu10k1_main.c
Auto-merged sound/pci/hda/patch_analog.c
Auto-merged sound/pci/hda/patch_realtek.c
CONFLICT (content): Merge conflict in sound/pci/hda/patch_realtek.c
Auto-merged sound/pci/hda/patch_sigmatel.c
Automatic merge failed; fix conflicts and then commit the result.
and me no happy...
It probably has something to do with that " ! [rejected]" but what is
that about? Is the repo bad? (and if so, I suspect owner will want to
know how to avoid it in the future).
And if it is bad, should I be seeing something with the pull method
also? Moreover... can I now trust my tmp0 branch?
Rene.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2008-07-21 8:47 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Miklos Vajna, Junio C Hamano, Johannes Schindelin,
Nanako Shiraishi, git
In-Reply-To: <bd6139dc0807201558k6e3d85b8u30d214f16e1040bd@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>>> Whatever happened to quotes?
>>>
>>> $ git merge -s subtree -Xpath="git-gui git-gui/master"
>>
>> Read again what did you wrote. ;-)
>>
>> The current form is
>>
>> git merge -s subtree git-gui/master, so at most it could be
>>
>> $ git merge -s subtree -Xpath="git-gui" git-gui/master
>
> Meh, what I of course mean was:
> $ git merge -s subtree -X"path=git-gui" git-gui/master
>
> But that looks rather awkward, which is probably why I typed it the
> way I did? Maybe something like....
> $ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master
Or perhaps (following -Wx family of GCC options)
$ git merge -s subtree -X--path=git-gui,--foo=bar git-gui/master
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Steve Frécinaux @ 2008-07-21 8:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080721075618.14163.45309.stgit@localhost>
On Mon, Jul 21, 2008 at 9:56 AM, Petr Baudis <pasky@suse.cz> wrote:
> This was originally pointed out and described in a patch by
> Steve Frénaux <code@istique.net>, this is a shot at clearer and more
> accurate description.
There is a typo in my name ;-)
^ permalink raw reply
* Re: [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Jakub Narebski @ 2008-07-21 8:38 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: Johannes Schindelin, git
In-Reply-To: <1216604693.3673.20.camel@pc7.dolda2000.com>
Fredrik Tolf <fredrik@dolda2000.com> writes:
> [...] Here's some makeshift documentation:
>
> The string specified in core.sshcommand is first checked if it matches
> any of the built-in templates, in which case it is expanded (I've added
> the templates "openssh" and "plink" by default). When used, the string
> is split into words, each of which is processed as follows:
>
> * If a word is %p, it is replaced by the port number, if specified.
> If the port number is not specified, the word is deleted.
> * If a word is %h, it is replaced by the remote host name.
> * If a word begins with %P, it is deleted if no port number is
> specified. This is to allow for specifying different port number
> flags for different SSH implementations. The syntax is a bit ugly,
> but I cannot really think of anything that would look better.
> If a port number has been specified, the leading %P is simply deleted.
There is a syntax which would look better, but perhaps it is a bit
overkill in this situation. Namely use either shell conditional
expansion:
${p:+-P $p}
or syntax used in RPM spec macros
%{?p:-P %p}
(and there is complementing %{!?<var>:<expansion>} in RPM spec macro
language).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: 1.6.0-rc0 tagged
From: Jakub Narebski @ 2008-07-21 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4l7wyfl.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * The ".dotest" temporary area "git am" and "git rebase" use will be
> moved to $GIT_DIR/rebase. We might change it to $GIT_DIR/rebase-apply
> which would be more logical name before the final, though.
Very good idea. $GIT_DIR/rebase looks slightly strange with git-am.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability
From: Junio C Hamano @ 2008-07-21 8:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <7v7ibfvfmh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thinking about this issue a bit more, I realize that the earlier "git add -A"
> change was done in a quite inefficient way (i.e. it is as unefficient as
> "git add -u && git add ." modulo one fork/exec and read/write index). For
> that matter, the original "git add ." could probably be more efficient
> than it currently is.
> ...
> It is likely that I am too tired to do this right tonight, so I'll go to
> bed and expect to find a nicely done patch in my mailbox by somebody else
> ;-).
Well, I lied. I couldn't sleep, so here is a preview that seems to pass
all the test at least. It needs to be split into two, but I am too tired
to do that properly tonight.
The main part of the change is third hunk (preimage ll.258-) to the bottom
of builtin-add.c and follows the idea outlined in the message this is a
response to.
A private function add_files_to_cache() in builtin-add.c was borrowed by
checkout and commit re-implementors without getting properly refactored to
more library-ish place. This does the refactoring, and most of the
changes you see in the diffstat are this; it should come before the main
part of the change.
---
builtin-add.c | 78 ++++++--------------------------------------------------
cache.h | 1 +
read-cache.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 71 insertions(+), 69 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index fc3f96e..f9b25f2 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -8,10 +8,6 @@
#include "dir.h"
#include "exec_cmd.h"
#include "cache-tree.h"
-#include "diff.h"
-#include "diffcore.h"
-#include "commit.h"
-#include "revision.h"
#include "run-command.h"
#include "parse-options.h"
@@ -79,59 +75,6 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
prune_directory(dir, pathspec, baselen);
}
-struct update_callback_data
-{
- int flags;
- int add_errors;
-};
-
-static void update_callback(struct diff_queue_struct *q,
- struct diff_options *opt, void *cbdata)
-{
- int i;
- struct update_callback_data *data = cbdata;
-
- for (i = 0; i < q->nr; i++) {
- struct diff_filepair *p = q->queue[i];
- const char *path = p->one->path;
- switch (p->status) {
- default:
- die("unexpected diff status %c", p->status);
- case DIFF_STATUS_UNMERGED:
- case DIFF_STATUS_MODIFIED:
- case DIFF_STATUS_TYPE_CHANGED:
- if (add_file_to_cache(path, data->flags)) {
- if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
- die("updating files failed");
- data->add_errors++;
- }
- break;
- case DIFF_STATUS_DELETED:
- if (!(data->flags & ADD_CACHE_PRETEND))
- remove_file_from_cache(path);
- if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
- printf("remove '%s'\n", path);
- break;
- }
- }
-}
-
-int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
-{
- struct update_callback_data data;
- struct rev_info rev;
- init_revisions(&rev, prefix);
- setup_revisions(0, NULL, &rev, NULL);
- rev.prune_data = pathspec;
- rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
- rev.diffopt.format_callback = update_callback;
- data.flags = flags;
- data.add_errors = 0;
- rev.diffopt.format_callback_data = &data;
- run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
- return !!data.add_errors;
-}
-
static void refresh(int verbose, const char **pathspec)
{
char *seen;
@@ -258,7 +201,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die("-A and -u are mutually incompatible");
- if (addremove && !argc) {
+ if ((addremove || take_worktree_changes) && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
argv = here;
@@ -271,7 +214,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
flags = ((verbose ? ADD_CACHE_VERBOSE : 0) |
(show_only ? ADD_CACHE_PRETEND : 0) |
- (ignore_add_errors ? ADD_CACHE_IGNORE_ERRORS : 0));
+ (ignore_add_errors ? ADD_CACHE_IGNORE_ERRORS : 0) |
+ (!(addremove || take_worktree_changes)
+ ? ADD_CACHE_IGNORE_REMOVAL : 0));
if (require_pathspec && argc == 0) {
fprintf(stderr, "Nothing specified, nothing added.\n");
@@ -280,24 +225,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
}
pathspec = get_pathspec(prefix, argv);
- /*
- * If we are adding new files, we need to scan the working
- * tree to find the ones that match pathspecs; this needs
- * to be done before we read the index.
- */
- if (add_new_files)
- fill_directory(&dir, pathspec, ignored_too);
-
if (read_cache() < 0)
die("index file corrupt");
+ if (add_new_files)
+ /* This picks up the paths that are not tracked */
+ fill_directory(&dir, pathspec, ignored_too);
+
if (refresh_only) {
refresh(verbose, pathspec);
goto finish;
}
- if (take_worktree_changes || addremove)
- exit_status |= add_files_to_cache(prefix, pathspec, flags);
+ exit_status |= add_files_to_cache(prefix, pathspec, flags);
if (add_new_files)
exit_status |= add_files(&dir, flags);
diff --git a/cache.h b/cache.h
index 38985aa..6f374ad 100644
--- a/cache.h
+++ b/cache.h
@@ -375,6 +375,7 @@ extern int remove_file_from_index(struct index_state *, const char *path);
#define ADD_CACHE_VERBOSE 1
#define ADD_CACHE_PRETEND 2
#define ADD_CACHE_IGNORE_ERRORS 4
+#define ADD_CACHE_IGNORE_REMOVAL 8
extern int add_to_index(struct index_state *, const char *path, struct stat *, int flags);
extern int add_file_to_index(struct index_state *, const char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh);
diff --git a/read-cache.c b/read-cache.c
index a50a851..6833af6 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -8,6 +8,11 @@
#include "cache-tree.h"
#include "refs.h"
#include "dir.h"
+#include "tree.h"
+#include "commit.h"
+#include "diff.h"
+#include "diffcore.h"
+#include "revision.h"
/* Index extensions.
*
@@ -1444,3 +1449,59 @@ int read_index_unmerged(struct index_state *istate)
istate->cache_nr = dst - istate->cache;
return !!last;
}
+
+struct update_callback_data
+{
+ int flags;
+ int add_errors;
+};
+
+static void update_callback(struct diff_queue_struct *q,
+ struct diff_options *opt, void *cbdata)
+{
+ int i;
+ struct update_callback_data *data = cbdata;
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+ const char *path = p->one->path;
+ switch (p->status) {
+ default:
+ die("unexpected diff status %c", p->status);
+ case DIFF_STATUS_UNMERGED:
+ case DIFF_STATUS_MODIFIED:
+ case DIFF_STATUS_TYPE_CHANGED:
+ if (add_file_to_index(&the_index, path, data->flags)) {
+ if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
+ die("updating files failed");
+ data->add_errors++;
+ }
+ break;
+ case DIFF_STATUS_DELETED:
+ if (data->flags & ADD_CACHE_IGNORE_REMOVAL)
+ break;
+ if (!(data->flags & ADD_CACHE_PRETEND))
+ remove_file_from_index(&the_index, path);
+ if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
+ printf("remove '%s'\n", path);
+ break;
+ }
+ }
+}
+
+int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
+{
+ struct update_callback_data data;
+ struct rev_info rev;
+ init_revisions(&rev, prefix);
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.prune_data = pathspec;
+ rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = update_callback;
+ data.flags = flags;
+ data.add_errors = 0;
+ rev.diffopt.format_callback_data = &data;
+ run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
+ return !!data.add_errors;
+}
+
^ permalink raw reply related
* [RFC PATCH] Support copy and rename detection in fast-export.
From: Alexander Gavrilov @ 2008-07-21 8:16 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
Although it does not matter for Git itself, tools that
export to systems that explicitly track copies and
renames can benefit from such information.
This patch makes fast-export output correct action
logs when -M or -C are enabled.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
I'm thinking about Git->SVN conversion, like http://repo.or.cz/w/git2svn.git
The trouble with this patch is that old versions of fast-export
accept -M and -C, but produce garbage if they are specified.
So the only way for the users to ensure that it is supported is
to check the git version (or directly test it).
As a somewhat related question, in which order does fast-export
output the commits, beside topological? In particular, does it order
commits on parrallel branches (i.e. not topologically dependent) by date?
-- Alexander
builtin-fast-export.c | 28 ++++++++++++++++++++++++++--
t/t9301-fast-export.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 8bea269..3225e8f 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -118,10 +118,27 @@ static void show_filemodify(struct diff_queue_struct *q,
{
int i;
for (i = 0; i < q->nr; i++) {
+ struct diff_filespec *ospec = q->queue[i]->one;
struct diff_filespec *spec = q->queue[i]->two;
- if (is_null_sha1(spec->sha1))
+
+ switch (q->queue[i]->status) {
+ case DIFF_STATUS_DELETED:
printf("D %s\n", spec->path);
- else {
+ break;
+
+ case DIFF_STATUS_COPIED:
+ case DIFF_STATUS_RENAMED:
+ printf("%c \"%s\" \"%s\"\n", q->queue[i]->status,
+ ospec->path, spec->path);
+
+ if (!hashcmp(ospec->sha1, spec->sha1) &&
+ ospec->mode == spec->mode)
+ break;
+ /* fallthrough */
+
+ case DIFF_STATUS_TYPE_CHANGED:
+ case DIFF_STATUS_MODIFIED:
+ case DIFF_STATUS_ADDED:
/*
* Links refer to objects in another repositories;
* output the SHA-1 verbatim.
@@ -134,6 +151,13 @@ static void show_filemodify(struct diff_queue_struct *q,
printf("M %06o :%d %s\n", spec->mode,
get_object_mark(object), spec->path);
}
+ break;
+
+ default:
+ die("Unexpected comparison status '%c' for %s, %s",
+ q->queue[i]->status,
+ ospec->path ? ospec->path : "none",
+ spec->path ? spec->path : "none");
}
}
}
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index f18eec9..bb595b7 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -162,4 +162,50 @@ test_expect_success 'submodule fast-export | fast-import' '
'
+export GIT_AUTHOR_NAME='A U Thor'
+export GIT_COMMITTER_NAME='C O Mitter'
+
+test_expect_success 'setup copies' '
+
+ git config --unset i18n.commitencoding &&
+ git checkout -b copy rein &&
+ git mv file file3 &&
+ git commit -m move1 &&
+ test_tick &&
+ cp file2 file4 &&
+ git add file4 &&
+ git mv file2 file5 &&
+ git commit -m copy1 &&
+ test_tick &&
+ cp file3 file6 &&
+ git add file6 &&
+ git commit -m copy2 &&
+ test_tick &&
+ echo more text >> file6 &&
+ echo even more text >> file6 &&
+ git add file6 &&
+ git commit -m modify &&
+ test_tick &&
+ cp file6 file7 &&
+ echo test >> file7 &&
+ git add file7 &&
+ git commit -m copy_modify
+
+'
+
+test_expect_success 'fast-export -C -C | fast-import' '
+
+ ENTRY=$(git rev-parse --verify copy) &&
+ rm -rf new &&
+ mkdir new &&
+ git --git-dir=new/.git init &&
+ git fast-export -C -C --signed-tags=strip --all > output &&
+ grep "^C \"file6\" \"file7\"\$" output &&
+ cat output |
+ (cd new &&
+ git fast-import &&
+ test $ENTRY = $(git rev-parse --verify refs/heads/copy))
+
+'
+
test_done
--
1.5.6.3.18.gfe82
^ permalink raw reply related
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