* Re: [PATCH 3/5] git push: verify refs early
From: Clemens Buchacher @ 2012-02-14 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce
In-Reply-To: <7v4nuucrbm.fsf@alter.siamese.dyndns.org>
On Mon, Feb 13, 2012 at 02:16:13PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > I suppose with some effort, this could be done for smart HTTP as well.
> > But I am not sure if we actually want the overhead of the additional
> > ping-pong for HTTP.
>
> Hrm, I am confused.
>
> The updated protocol exchange, if I am reading your patch correctly, would
> go like this (S stands for the sender, R for the receiver):
>
> R: Here are the tips of my refs
> ----
> S: I'd like to update your refs this way
> ----
> + R: No you cannot because all updates will fail, go away
> or
> + R: You may proceed, as some updates may succeed
> ----
> S: Here is the packfile
> ----
> R: Here is how I processed your request
>
> Given that this makes the sender stall for both smart HTTP and native
> protocol, don't your worries about the additional ping-pong apply equally
> to both transports?
That is true. However, my assumption was that the overhead is greater
for HTTP, because the native protocol is full-duplex, while HTTP tears
down the connection and starts from scratch with each request. But to be
honest, I am not confident that this assumption is correct.
So, the stall might be an issue for both the native and the HTTP
protocol, or for neither. We should probably find out and then decide
whether to make this change for both protocols or not at all.
> If it is not worth doing for smart HTTP, I wonder if it is worth doing for
> native transport. After all, "all updates will fail" is hopefully the
> less likely case, and with this protocol extension, we end up penalizing
> the common case with an extra stall for everybody, regardless of the
> transport.
Indeed. I wish we could make the ref validation asynchronous. The client
would start sending object data right away, while listening for an
"abort" command on the side-band. But if I understand correctly, that is
not possible for HTTP.
^ permalink raw reply
* Re: [RFC PATCH 0/3] git-p4: move to toplevel
From: Clemens Buchacher @ 2012-02-14 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pete Wyckoff, git, Luke Diamand, Vitor Antunes
In-Reply-To: <7vhayuctwm.fsf@alter.siamese.dyndns.org>
On Mon, Feb 13, 2012 at 01:20:25PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> >> Erm,... do you really need the alias if you add git-p4 in a directory on
> >> your $PATH?
> >
> > With recent git versions, this has stopped working.
>
> Erm, I am confused.
Looks like in my case it did not work because I had a PATH entry with a
'~' in it. It probably stopped working for me because I moved some
executables around.
It's not a regression (I just tried with 1.6.0 and I get the same
result). And dash does not apply tilde expansion to PATH either. So
maybe it's not even a bug.
^ permalink raw reply
* [PATCH] filter-branch: cd to the correct directory when -d is used
From: Per Cederqvist @ 2012-02-14 9:49 UTC (permalink / raw)
To: git; +Cc: cederp, ceder
git-filter-branch changes directory to $tempdir/t, which by default is
.git-rewrite/t. Before doing the read-tree to update the working tree
it uses "cd ../.." to get back to the working tree. This breaks if
you use something like "-d /tmp/tempdir", as the read-tree will be
executed in /tmp instead of in your working tree.
Fixed by adding a variable that holds the original value of $(pwd),
and cd back to that value.
Added tests that demonstrates some issues that can happen without this
fix.
Signed-off-by: Per Cederqvist <cederp@opera.com>
---
git-filter-branch.sh | 3 ++-
t/t7003-filter-branch.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index add2c02..a58b50b 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -217,6 +217,7 @@ t)
test -d "$tempdir" &&
die "$tempdir already exists, please remove it"
esac
+oldpwd="$(pwd)"
mkdir -p "$tempdir/t" &&
tempdir="$(cd "$tempdir"; pwd)" &&
cd "$tempdir/t" &&
@@ -489,7 +490,7 @@ if [ "$filter_tag_name" ]; then
done
fi
-cd ../..
+cd "$oldpwd"
rm -rf "$tempdir"
trap - 0
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index e022773..fa464a2 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -367,4 +367,42 @@ test_expect_success 'replace submodule revision' '
test $orig_head != `git show-ref --hash --head HEAD`
'
+test_expect_success 'get a fresh tree' '
+ rm -fr ?* .git .gitmodules
+'
+
+deep_tree() {
+ test_expect_success 'setup deep tree' '
+ rm -fr drepo &&
+ mkdir drepo &&
+ ( cd drepo &&
+ git init &&
+ mkdir kom++ &&
+ test_commit authors kom++/AUTHORS "Fake authors file" &&
+ test_commit changelog kom++/ChangeLog "Fake ChangeLog file"
+ )
+ '
+
+ test_expect_success '-d tempdir with --subdirectory-filter' '
+ (cd drepo &&
+ git filter-branch -d "$TRASHDIR/tmpdir" --subdirectory-filter kom++
--tag-name-filter cat -- --all
+ )
+ '
+
+ test_expect_success 'content after -d with --subdirectory-filter' '
+ test_path_is_missing AUTHORS "AUTHORS created in tmpdir/.."
+ test_path_is_missing ChangeLog "ChangeLog created in tmpdir/.."
+ test_path_is_missing drepo/kom++ "kom++ remains"
+ test_path_is_file drepo/AUTHORS "AUTHORS not moved to top-level"
+ test_path_is_file drepo/ChangeLog "ChangeLog not moved to top-level"
+ '
+
+ test_expect_success 'Clean workdir' '
+ cd drepo&&git diff --quiet
+ '
+}
+
+deep_tree
+deep_tree # In Git 1.7.9 and earlier filter-branch fails the second time.
+
test_done
--
1.7.9
^ permalink raw reply related
* Re: git status: small difference between stating whole repository and small subdirectory
From: Thomas Rast @ 2012-02-14 11:34 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: Git Mailing List, Nguyen Thai Ngoc Duy
In-Reply-To: <CAA01Csp6_9fP2rg4104UWUXwOxZmUVdQNDAaBe6fRou6agBz6g@mail.gmail.com>
Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
> On Fri, Feb 10, 2012 at 10:42 AM, Piotr Krukowiecki
> <piotr.krukowiecki@gmail.com> wrote:
>> I compared stating whole tree vs one small subdirectory, and I
>> expected that for the subdirectory status will be very very fast.
>> After all, it has only few files to stat. But it's not fast. Why?
>>
>>
>> With cold cache (echo 3 | sudo tee /proc/sys/vm/drop_caches):
>>
>> $ time git status > /dev/null
>> real 0m41.670s
>> user 0m0.980s
>> sys 0m2.908s
>>
>> $ time git status -- src/.../somedir > /dev/null
>> real 0m17.380s
>> user 0m0.748s
>> sys 0m0.328s
[...]
> I can't reproduce this behavior at the moment. 'status' on the
> directory takes about 1.5s instead of 17s. status on whole repository
> takes 27s.
> This is my work repository, so it was changed today.
To me these timings smell like a combination of either a network
filesystem or a slow/busy disk, and non-packed repositories. Next time
this happens look at 'git count-objects', run 'git gc' and redo the
timings.
If you are indeed on a network filesystem, also look at the
core.preloadIndex setting.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/2] Save terminal width before setting up pager and export term_columns()
From: Nguyen Thai Ngoc Duy @ 2012-02-14 11:44 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1329055953-29632-1-git-send-email-zbyszek@in.waw.pl>
2012/2/12 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
> This replaces cb0850f (Save terminal width before setting up pager -
> 2012-02-04) from Nguyễn Thái Ngọc Duy and my previous patch to export
> term_columns().
>
> This is directly on top of v1.7.9 as requested.
>
> I removed Signed-off-by from Nguyễn and Junio because the patch is
> substantially changed.
No problems. I will rebase my series on top of this patch (its final
version, that is).
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] Save terminal width before setting up pager and export term_columns()
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-14 11:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <CACsJy8Da=JMF7B9hW+WXzRXQFiGJxh0S7HYFg9+uweZ=pMOmTQ@mail.gmail.com>
On 02/14/2012 12:44 PM, Nguyen Thai Ngoc Duy wrote:
> 2012/2/12 Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl>:
>> This replaces cb0850f (Save terminal width before setting up pager -
>> 2012-02-04) from Nguyễn Thái Ngọc Duy and my previous patch to export
>> term_columns().
>>
>> This is directly on top of v1.7.9 as requested.
>>
>> I removed Signed-off-by from Nguyễn and Junio because the patch is
>> substantially changed.
>
> No problems. I will rebase my series on top of this patch (its final
> version, that is).
Hi, I think that Junio's will be the final version. I have no objections
to it.
Zbyszek
^ permalink raw reply
* cvs2git migration
From: supadhyay @ 2012-02-14 12:01 UTC (permalink / raw)
To: git
Hi All,
I want to migrate my version control CVS to GIT. I have few links which
mentioned about how to migrate CVS repositories to GIT but there is no
description about how to migrate existing CVS users to GIT?
Can you please suggest me or forward me some links which mentioned about how
to migrate users as well.
Thanks in advance.
--
View this message in context: http://git.661346.n2.nabble.com/cvs2git-migration-tp7283631p7283631.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Support wrapping commit messages when you read them
From: Holger Hellmuth @ 2012-02-14 12:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sidney San Martín, git
In-Reply-To: <7vzkcmbcbq.fsf@alter.siamese.dyndns.org>
On 13.02.2012 23:25, Junio C Hamano wrote:
> "Computers are good at automating" is true, and that is why real editors
> give an easy way to auto-wrap long prose in a paragraph while composing.
> But "computers are good at automating" is not a convincing justification
> to let the composer leave unreasonably long lines in the commit log object
> and force the reader side to line-wrap the mess only to fix it up.
Maybe this is more convincing: Only the reader side knows the
line-length of the display or window.
^ permalink raw reply
* [PATCH v2] make lineno_width() from blame reusable for others
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-14 12:24 UTC (permalink / raw)
To: git, gitster, pclouds; +Cc: Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <7vhayub9d3.fsf@alter.siamese.dyndns.org>
builtin/blame.c has a helper function to compute how many columns we
need to show a line-number, whose implementation is reusable as a more
generic helper function to count the number of columns necessary to
show any cardinal number.
Rename it to decimal_width(), move it to pager.c and export it for use
by future callers. The argument type is changed to unsigned to underline
the fact that the function supports only non-negative numbers.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
I'll be using this in the 'diff --stat: use the full terminal width'
patch.
v2: - change arg type to unsigned
- corrected commit message
builtin/blame.c | 18 +++---------------
cache.h | 1 +
| 12 ++++++++++++
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 5a67c20..f028e8a 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1829,18 +1829,6 @@ static int read_ancestry(const char *graft_file)
}
/*
- * How many columns do we need to show line numbers in decimal?
- */
-static int lineno_width(int lines)
-{
- int i, width;
-
- for (width = 1, i = 10; i <= lines; width++)
- i *= 10;
- return width;
-}
-
-/*
* How many columns do we need to show line numbers, authors,
* and filenames?
*/
@@ -1880,9 +1868,9 @@ static void find_alignment(struct scoreboard *sb, int *option)
if (largest_score < ent_score(sb, e))
largest_score = ent_score(sb, e);
}
- max_orig_digits = lineno_width(longest_src_lines);
- max_digits = lineno_width(longest_dst_lines);
- max_score_digits = lineno_width(largest_score);
+ max_orig_digits = decimal_width(longest_src_lines);
+ max_digits = decimal_width(longest_dst_lines);
+ max_score_digits = decimal_width(largest_score);
}
/*
diff --git a/cache.h b/cache.h
index 2f30b3a..3504bcc 100644
--- a/cache.h
+++ b/cache.h
@@ -1176,6 +1176,7 @@ extern const char *pager_program;
extern int pager_in_use(void);
extern int pager_use_color;
extern int term_columns(void);
+extern int decimal_width(unsigned number);
extern const char *editor_program;
extern const char *askpass_program;
--git a/pager.c b/pager.c
index e06cfa0..2e16a9c 100644
--- a/pager.c
+++ b/pager.c
@@ -153,3 +153,15 @@ int term_columns(void)
#endif
return term_columns_at_startup;
}
+
+/*
+ * How many columns do we need to show this number in decimal?
+ */
+int decimal_width(unsigned number)
+{
+ int i, width;
+
+ for (width = 1, i = 10; i <= number; width++)
+ i *= 10;
+ return width;
+}
--
1.7.9.3.g2429d.dirty
^ permalink raw reply related
* Re: git-p4 useclientspec broken?
From: Pete Wyckoff @ 2012-02-14 12:36 UTC (permalink / raw)
To: Laurent Charrière; +Cc: git
In-Reply-To: <4F39AF04.5080607@promptu.com>
lcharriere@promptu.com wrote on Mon, 13 Feb 2012 16:47 -0800:
> Since I've upgraded to 1.7.9 (on OS X Lion, FWIW), git-p4 submit
> fails to apply any patches if I use useclientspec=true when cloning.
>
> My p4 client is as follows:
>
> Client: malibu
> (...)
> Root: /Users/lcharriere/Documents/Perforce/all
> (...)
> View:
> //sandbox/... //malibu/sandbox/...
> //depot/... //malibu/depot/...
>
> Sequence of steps to reproduce:
>
> $ git p4 clone //sandbox/lcharriere/foo --use-client-spec
> $ cd foo && find .
> ./.git
> (...)
> ./sandbox/lcharriere/foo/.gitignore
> ./sandbox/lcharriere/foo/foo.py
>
> -- This is new behavior to me, BTW. Previously, I would have seen
> ./.git
> (...)
> ./.gitignore
> ./foo.py
I did try to clean up our handling of --use-client-spec. This
behavior was done on purpose, but maybe I didn't the implications
on people who were relying on the old way. In particular the
behavior of multi-line view specs and those with + and - was
largely unpredictable.
The client spec now has absolute control over what files get put
where in the git repo, just like in p4. The argument
"//sandbox/lcharriere/foo" in your clone command limits the scope
of what is checked out, but does not affect where it is placed.
You can get the git layout you expect with this view:
//sandbox/lcharriere/foo/... //malibu/...
or simply just don't use --use-client-spec at all:
git p4 clone //sandbox/lcharriere/foo
Is this new behavior bad for you? Suggestions welcome.
> $ cat "test" >> sandbox/lcharriere/foo/.gitignore
> $ git commit -a -m "test"
> git commit -a -m "test"
> [master 7398144] test
> 1 files changed, 1 insertions(+), 0 deletions(-)
> $ git p4 submit
> Perforce checkout for depot path //sandbox/lcharriere/foo/ located
> at /Users/lcharriere/Documents/Perforce/all/sandbox/lcharriere/foo/
> Synchronizing p4 checkout...
> ... - file(s) up-to-date.
> Applying 739814457a8faa84dc0bddd830f671569576b177 test
>
> sandbox/lcharriere/foo/.gitignore - file(s) not on client.
> error: sandbox/lcharriere/foo/.gitignore: No such file or directory
> Unfortunately applying the change failed!
> What do you want to do?
> [s]kip this patch / [a]pply the patch forcibly and with .rej files /
> [w]rite the patch to a file (patch.txt)
This is definitely a bug. I reproduced a similar problem.
> I tried to follow what's going on with pdb:
> * self.depotPath is //sandbox/lcharriere/foo, so git-p4 chdir's to
> /Users/lcharriere/Documents/Perforce/all/sandbox/lcharriere/foo/
> * In P4Submit.applyCommit, line 926 is:
> p4_edit(path)
> At this point path is 'sandbox/lcharriere/foo/.gitignore'
The path should be plain old ".gitignore", as you noticed.
> I'm guessing this is why the p4 executable doesn't find it. The path
> should be .gitignore. Is it possible that the new behavior I
> mentioned above of reproducing the depot hierarchy when
> useclientspec is true is having unintended side effects, or is a
> bug?
I'll get a patch out tonight or soon. Need to do gobs of testing
on the submit path to make sure nothing else is broken.
-- Pete
^ permalink raw reply
* git-latexdiff: Git and Latexdiff working together
From: Matthieu Moy @ 2012-02-14 13:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Hi,
You may know latexdiff, a neat tool to visualize differences between
LaTeX files (it annotates your .tex file with colors for removed/added
parts, producing another compilable .tex file).
I wrote a little shell-script that allows one to use latexdiff on files
versionned by Git, with e.g.
git latexdiff HEAD^ --main foo.tex --output foo.pdf
Essentially, it does a checkout of the old and new revisions, and calls
latexdiff + pdflatex for you.
The result is attached in case anyone is interested.
It may be relevant to add this to contrib/ in git.git. If anyone's
interested, let me know, and I'll resend the code in the form of a
patch doing that.
Regards,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
[-- Attachment #2: git-latexdiff --]
[-- Type: application/octet-stream, Size: 4613 bytes --]
#! /bin/sh
usage () {
cat << EOF
Usage: $(basename $0) [options] OLD [NEW]
Call latexdiff on two Git revisions of a file.
OLD and NEW are Git revision identifiers. NEW defaults to HEAD.
Options:
--help This help message
--main FILE.tex Name of the main LaTeX file
--no-view Don't display the resulting PDF file
--view View the resulting PDF file
(default if -o is not used)
--no-cleanup Don't cleanup temp dir after running
-o FILE, --output FILE
Copy resulting PDF into FILE
(usually ending with .pdf)
EOF
}
die () {
echo "fatal: $@"
exit 1
}
verbose () {
if [ "$verbose" = 1 ]; then
printf "%s ..." "$@"
fi
}
verbose_progress () {
if [ "$verbose" = 1 ]; then
printf "." "$@"
fi
}
verbose_done () {
if [ "$verbose" = 1 ]; then
echo " done."
fi
}
old=
new=
main=
view=maybe
cleanup=1
verbose=0
output=
initial_dir=$PWD
while test $# -ne 0; do
case "$1" in
"--help"|"-h")
usage
exit 0
;;
"--main")
shift
main=$1
;;
"--no-view")
view=0
;;
"--view")
view=1
;;
"--no-cleanup")
cleanup=0
;;
"-o"|"--output")
shift
output=$1
;;
"--verbose"|"-v")
verbose=1
;;
*)
if [ "$1" = "" ]; then
echo "Empty string not allowed as argument"
usage
exit 1
elif [ "$old" = "" ]; then
old=$1
elif [ "$new" = "" ]; then
new=$1
else
echo "Bad argument $1"
usage
exit 1
fi
;;
esac
shift
done
if [ "$new" = "" ]; then
new=HEAD
fi
if [ "$old" = "" ]; then
echo "fatal: Please, provide at least one revision to diff with."
usage
exit 1
fi
if [ "$main" = "" ]; then
printf "%s" "No --main provided, trying to guess ... "
main=$(git grep -l '^[ \t]*\\documentclass')
# May return multiple results, but if so the result won't be a file.
if [ -r "$main" ]; then
echo "Using $main as the main file."
else
if [ "$main" = "" ]; then
echo "No candidate for main file."
else
echo "Multiple candidates for main file:"
printf "%s\n" "$main" | sed 's/^/\t/'
fi
die "Please, provide a main file with --main FILE.tex."
fi
fi
if [ ! -r "$main" ]; then
die "Cannot read $main."
fi
verbose "Creating temporary directories"
git_prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-cdup)" || die "Can't cd back to repository root"
git_dir="$(git rev-parse --git-dir)" || die "Not a git repository?"
git_dir=$(cd "$git_dir"; pwd)
main=$git_prefix/$main
tmpdir=$initial_dir/git-latexdiff.$$
mkdir "$tmpdir" || die "Cannot create temporary directory."
cd "$tmpdir" || die "Cannot cd to $tmpdir"
mkdir old new diff || die "Cannot create old, new and diff directories."
verbose_done
verbose "Checking out old and new version"
cd old || die "Cannot cd to old/"
git --git-dir="$git_dir" --work-tree=. checkout "$old" -- . || die "checkout failed for old/"
verbose_progress
cd ../new || die "Cannot cd to new/"
git --git-dir="$git_dir" --work-tree=. checkout "$new" -- . || die "checkout failed for new/"
verbose_progress
cd ../diff || die "Cannot cd to diff/"
git --git-dir="$git_dir" --work-tree=. checkout "$new" -- . || die "checkout failed for diff/"
verbose_progress
cd .. || die "Cannot cd back to toplevel"
verbose_done
verbose "Running latexdiff --flatten old/$main new/$main > diff/$main"
latexdiff --flatten old/$main new/$main > diff/$main || die "latexdiff failed"
verbose_done
mainbase=$(basename "$main" .tex)
maindir=$(dirname "$main")
verbose "Compiling result"
compile_error=0
cd diff/"$maindir" || die "Can't cd to diff/$maindir"
if [ -f Makefile ]; then
make || compile_error=1
else
pdflatex --interaction errorstopmode "$mainbase" || compile_error=1
fi
verbose_done
pdffile="$mainbase".pdf
if [ ! -r "$pdffile" ]; then
echo "No PDF file generated."
compile_error=1
fi
if [ ! -s "$pdffile" ]; then
echo "PDF file generated is empty."
compile_error=1
fi
if [ "$compile_error" = "1" ]; then
echo "Error during compilation. Please examine and cleanup if needed:"
echo "Directory: $tmpdir/diff/$maindir/"
echo " File: $mainbase.tex"
# Don't clean up to let the user diagnose.
exit 1
fi
if [ "$output" != "" ]; then
abs_pdffile="$PWD/$pdffile"
(cd "$initial_dir" && cp "$abs_pdffile" "$output")
echo "Output written on $output"
fi
if [ "$view" = 1 ] || [ "$view" = maybe ] && [ "$output" = "" ]; then
xpdf "$pdffile"
fi
if [ "$cleanup" = 1 ]; then
verbose "Cleaning-up result"
rm -fr "$tmpdir"
verbose_done
fi
^ permalink raw reply
* Git submodules with usernames in the URL
From: Tillmann.Crueger @ 2012-02-14 13:26 UTC (permalink / raw)
To: git
Hi,
I already had a look at the mailinglist archive, but I could not find any mention of this problem. There is a posting on Stackoverflow.com about this (http://stackoverflow.com/questions/7714326/git-submodule-url-not-including-username) with a workaround, but it would nice to have an official position.
Here is the problem:
When I am using git-submodule over an authorized https it is convenient to be able to specify the username directly in the url in the form https://user@domain.com/path/to/repo. So I am able to do a
> git submodule add https://user@domain.com/path/to/repo
Howver if I do this, the username becomes baked into the URL of the submodule, so other people working with the repository will not be able to use the submodule and have to change the URL first.
Is there an actual rationale for including the username in the URL in this case, or is this just because it is simpler than removing it?
One thing I noticed, is that automatically removing it would basically eliminate the convinience for the person who has been using that URL in the first place. If the username was removed every update would have to query the username again. Also having a username in the repo could be correct, in case this isn't a real user, but a role for using that repository.
Still I feel that having a username within a repository is hardly ever what someone wants and most often a mistake. For now I will try to educate everybody about this and fix all repositories where this goes wrong, but a better solution would be nice to have.
Thanks for your time,
Till
^ permalink raw reply
* Re: Git submodules with usernames in the URL
From: Michael Schubert @ 2012-02-14 14:55 UTC (permalink / raw)
To: Tillmann.Crueger; +Cc: git
In-Reply-To: <E76DF6102FDBC04BA291EAE9A3BAECB50137C2AC6530@HE111540.emea1.cds.t-internal.com>
On 02/14/2012 02:26 PM, Tillmann.Crueger@telekom.de wrote:
> I already had a look at the mailinglist archive, but I could not find
> any mention of this problem. There is a posting on Stackoverflow.com
> about this
> (http://stackoverflow.com/questions/7714326/git-submodule-url-not-including-username)
> with a workaround, but it would nice to have an official position.
>
> Here is the problem:
>
> When I am using git-submodule over an authorized https it is
> convenient to be able to specify the username directly in the url in
> the form https://user@domain.com/path/to/repo. So I am able to do a
>
>> git submodule add https://user@domain.com/path/to/repo
>
> Howver if I do this, the username becomes baked into the URL of the
> submodule, so other people working with the repository will not be
> able to use the submodule and have to change the URL first.
>
> Is there an actual rationale for including the username in the URL in
> this case, or is this just because it is simpler than removing it?
>
> One thing I noticed, is that automatically removing it would
> basically eliminate the convinience for the person who has been using
> that URL in the first place. If the username was removed every update
> would have to query the username again. Also having a username in the
> repo could be correct, in case this isn't a real user, but a role for
> using that repository.
* If the submodule repository is accessible without authentication, no
user specific URL should go into the repository.
* If the submodule repository is not accessible without authentication,
the user specific URL should not go into the repository either,
because of the problem you just described. (Sure, you could add a
"git submodule user", but..)
> Still I feel that having a username within a repository is hardly
> ever what someone wants and most often a mistake. For now I will try
> to educate everybody about this and fix all repositories where this
> goes wrong, but a better solution would be nice to have.
Git >= v1.7.9 comes with a credentials API and some helpers; see
commit abca927dbef2c310056b8a1a8be5561212b3243a
and following or the available documentation for credentials, e.g.:
https://raw.github.com/gitster/git/master/Documentation/git-credential-store.txt
In contrib, there's a helper for the OS X keychain:
https://github.com/gitster/git/tree/master/contrib/credential
If that's no option, you would have to go with netrc / url config
approach.
HTH.
^ permalink raw reply
* [PATCH 0/2] t: add blame -e tests for mailmap
From: Felipe Contreras @ 2012-02-14 16:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
I sent both the fix and the tests. Another fix was applied, but we are still
missing the tests.
These are good before, and after the fix.
Felipe Contreras (2):
t: mailmap: add 'git blame -e' tests
t: mailmap: add simple name translation test
t/t4203-mailmap.sh | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
--
1.7.9.1.g97f7d
^ permalink raw reply
* [PATCH 1/2] t: mailmap: add 'git blame -e' tests
From: Felipe Contreras @ 2012-02-14 16:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Jonathan Nieder, Marius Storm-Olsen
In-Reply-To: <1329235894-20581-1-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t4203-mailmap.sh | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 1f182f6..db12265 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -255,4 +255,22 @@ test_expect_success 'Blame output (complex mapping)' '
test_cmp expect actual.fuzz
'
+# git blame -e
+cat >expect <<\EOF
+^OBJI (<author@example.com> DATE 1) one
+OBJID (<some@dude.xx> DATE 2) two
+OBJID (<other@author.xx> DATE 3) three
+OBJID (<other@author.xx> DATE 4) four
+OBJID (<santa.claus@northpole.xx> DATE 5) five
+OBJID (<santa.claus@northpole.xx> DATE 6) six
+OBJID (<cto@company.xx> DATE 7) seven
+EOF
+test_expect_success 'Blame output (complex mapping)' '
+ git blame -e one >actual &&
+ cp actual /tmp &&
+ cp internal_mailmap/.mailmap /tmp &&
+ fuzz_blame actual >actual.fuzz &&
+ test_cmp expect actual.fuzz
+'
+
test_done
--
1.7.9.1.g97f7d
^ permalink raw reply related
* [PATCH 2/2] t: mailmap: add simple name translation test
From: Felipe Contreras @ 2012-02-14 16:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Marius Storm-Olsen, Jim Meyering,
Jonathan Nieder
In-Reply-To: <1329235894-20581-1-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t4203-mailmap.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index db12265..fc3855a 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -157,6 +157,9 @@ A U Thor <author@example.com> (1):
CTO <cto@company.xx> (1):
seventh
+Mr. Right <right@company.xx> (1):
+ eight
+
Other Author <other@author.xx> (2):
third
fourth
@@ -196,6 +199,11 @@ test_expect_success 'Shortlog output (complex mapping)' '
test_tick &&
git commit --author "CTO <cto@coompany.xx>" -m seventh &&
+ echo eight >>one &&
+ git add one &&
+ test_tick &&
+ git commit --author "Wrong <right@company.xx>" -m eight &&
+
mkdir -p internal_mailmap &&
echo "Committed <committer@example.com>" > internal_mailmap/.mailmap &&
echo "<cto@company.xx> <cto@coompany.xx>" >> internal_mailmap/.mailmap &&
@@ -204,6 +212,7 @@ test_expect_success 'Shortlog output (complex mapping)' '
echo "Other Author <other@author.xx> <nick2@company.xx>" >> internal_mailmap/.mailmap &&
echo "Santa Claus <santa.claus@northpole.xx> <me@company.xx>" >> internal_mailmap/.mailmap &&
echo "Santa Claus <santa.claus@northpole.xx> <me@company.xx>" >> internal_mailmap/.mailmap &&
+ echo "Mr. Right <right@company.xx>" >> internal_mailmap/.mailmap &&
git shortlog -e HEAD >actual &&
test_cmp expect actual
@@ -212,6 +221,9 @@ test_expect_success 'Shortlog output (complex mapping)' '
# git log with --pretty format which uses the name and email mailmap placemarkers
cat >expect <<\EOF
+Author Wrong <right@company.xx> maps to Mr. Right <right@company.xx>
+Committer C O Mitter <committer@example.com> maps to Committed <committer@example.com>
+
Author CTO <cto@coompany.xx> maps to CTO <cto@company.xx>
Committer C O Mitter <committer@example.com> maps to Committed <committer@example.com>
@@ -248,6 +260,7 @@ OBJID (Other Author DATE 4) four
OBJID (Santa Claus DATE 5) five
OBJID (Santa Claus DATE 6) six
OBJID (CTO DATE 7) seven
+OBJID (Mr. Right DATE 8) eight
EOF
test_expect_success 'Blame output (complex mapping)' '
git blame one >actual &&
@@ -264,6 +277,7 @@ OBJID (<other@author.xx> DATE 4) four
OBJID (<santa.claus@northpole.xx> DATE 5) five
OBJID (<santa.claus@northpole.xx> DATE 6) six
OBJID (<cto@company.xx> DATE 7) seven
+OBJID (<right@company.xx> DATE 8) eight
EOF
test_expect_success 'Blame output (complex mapping)' '
git blame -e one >actual &&
--
1.7.9.1.g97f7d
^ permalink raw reply related
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jakub Narebski @ 2012-02-14 17:31 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <20120213220917.4cf14eb1@gmail.com>
A few issues I have just noticed about this series.
First, about naming. "Highlighting interesting parts of diff" is
acceptable name, but "syntax highlighting for diff" is not: gitweb
already use syntax highlighting in diff views. Call it "diff refinement
highlighting", "highlighting changes / changed sections", "intraline
highlighting".
Second, I think (but I am not sure) that there is a bug in code that
finds common suffix and prefix.
If I understand correctly the idea is to highlight changed part if
there is at least one of common non-whitespace suffix or prefix.
So syntax highlighting should look like this:
1. Both prefix and suffix are non empty and non whitespace only
-foo -{bar} baz
+foo +{quux} baz
2. Non empty and non whitespace only prefix
-foo -{bar}
+foo +{quux}
2. Non empty and non whitespace only suffix
--{bar} baz
++{quux} baz
But in your code $prefix is not the length of common prefix, but
the position of end of prefix in the original line of diff. So
you start with $prefix = 1... even though the prefix is empty.
How is that supposed to work?
On Mon, 13 Feb 2012, Michał Kiedrowicz wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > On Mon, 13 Feb 2012, Michal Kiedrowicz wrote:
> > > I haven't found *examples* on GitHub and Trac sites, but what about
> > > these ones:
> > >
> > > https://github.com/gitster/git/commit/8cad4744ee37ebec1d9491a1381ec1771a1ba795
> > > http://trac.edgewall.org/changeset/10973
[...]
> > BTW GitHub is closed source, but we can check what algorithm does Trac
> > use for diff refinement highlighting (highlighting changed portions of
> > diff).
> >
>
> I think it's
> http://trac.edgewall.org/browser/trunk/trac/versioncontrol/diff.py
> (see markup intraline_changes()).
It is get_change_extent() that finds extent of changes, as a pair
containing the offset at which the changes start, and the negative offset
at which the changes end. So it is the same solution you use, only
without ignoring whitespace-only prefixes and suffixes... This code can
be easily ported to Perl, BTW.
The markup_intraline_changes() function compares lines from preimage and
from postimage pairwise, requiring that number of lines matches, the same
like in your algorithm.
[...]
> > I wonder if we can use --diff-words for diff refinement highlighting,
> > i.e. LCS on words.
>
> I think we can try it, but I worry about performance of running `git
> diff` on every diff chunk.
I was thinking about one single additional run of git-diff-tree with
`--diff-words`, not one per chunk.
Or perhaps even put it together in one git-diff-tree invocation, just like
'commitdiff' action / git_commitdiff() subroutine uses single git-diff-tree
invocation, with the option "--patch-with-raw", to generate both raw diff
for difftree and patchset.
> > Anyway Jeff's approach is a bit limited, in that it would work only for
> > change that does not involve adding newlines, for example splitting
> > overly long line when changing something.
> >
> > See for example line 1786 (in pre-image) in http://trac.edgewall.org/changeset/10973
>
> Yes, I'm aware of that. I was thinking about improving it later ("Let's
> start with a simple refinment highlightning and maybe later add more
> sophisticated algorithms").
Right.
[...]
> > BTW. is it "at least one of prefix or suffix are non-empty" or "both prefix
> > and suffix are non-empty"?
> >
>
> At least one. See:
>
> -a = 42;
> +b = 42;
>
> Here prefix is empty but suffix is not.
Nb. prefix is empty but $prefix == 1, and is boolean true.
> > > I would also consider ignoring prefixes/suffixes with punctuation, like:
> > >
> > > - * I like you.
> > > + * Alice had a little lamb.
> >
> > But this patch doesn't implement this feature yet, isn't it?
>
> No, but is a matter of adding
>
> -$prefix_is_space = 0 if ($r[$prefix] !~ /\s/);
> +$prefix_is_space = 0 if ($r[$prefix] !~ /\s|[[:punct:]]/);
>
> (and the same for suffix)
All right. But it is better added as separate patch. Perhaps even
requiring that not only there is at least one of common prefix or common
suffix, but at least one of them is not whitespace only could be put
in a separate commit...
> > > > > +sub format_rem_add_line {
> > > > > + my ($rem, $add) = @_;
> > > > > + my @r = split(//, $rem);
> > > > > + my @a = split(//, $add);
> >
> > BTW the name of variable can be just @add and @rem.
> >
>
> I know they are different scopes but I don't like it. It makes the code
> more confusing IMO. But I won't insist.
In my opinion if the variable refers to the same entity in different
forms, using @foo and %foo (used in gitweb), or $foo and @foo (could be
used here) is all right, and even better than trying to come up with
different name for the same thing because of sigil.
> > > > Shouldn't
> > > > $prefix / $prefix_len start from 0, not from 1?
> > >
> > > It starts from 1 because it skips first +/-. It should become obvious
> > > after reading the comment from last patch :).
This means that $prefix is true even if prefix is empty ($prefix == 1).
Wouldn't it be better for $prefix_len to count length of true prefix,
without diff adornment? Or make @r / @rem skip initial characters...
> > > + # In combined diff we must ignore two +/- characters.
> > > + $prefix = 2 if ($is_combined);
> >
> > Anyway comment about that fact would be nice.
>
> Will do.
BTW. it is not "2" but "scalar @{$co{'parents'}}".
> > > The splitting and comparing by characters is taken from diff-highlight.
> > > I don't think it's worth changing here.
> >
> > You are right.
> >
> > I'll try to come with hacky algorithm using string bitwise xor and regexp,
> > and benchmark it comparing to your C-like solution, but it can be left for
> > later (simple is better than clever, usually).
>
> If you have time :).
Anyway it would be separate commit. Better to just copy tested code
from contrib/diff-highlight
BTW. would "git blame -C -C -C -w" detect this correctly as code
movement^W copying?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/RFC v4] grep: Add the option '--exclude'
From: Junio C Hamano @ 2012-02-14 17:35 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Albert Yale, git
In-Reply-To: <CACsJy8DhtjG6AhPkb0SEm4g6zhtmuRb5x+4+P3A6eS0+_7OQNw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> It makes me wonder, why not add match_pathspec_with_exclusion(const
> struct pathspec *include_ps, const struct pathspec *exclude_ps,...),
> use the new function in grep.c and revert struct pathspec back to
> original? The same can be applied to tree_entry_interesting() (i.e.
> add a new one that takes two pathspec sets, which supports exclusion)
Sorry, but I am the one to blame for this in:
http://thread.gmane.org/gmane.comp.version-control.git/189455/focus=189486
> I think you may make less changes that way.
The arrangement to use two pathspecs certainly is simpler in the short
term, but I think it is a short-sighted hack that is wrong for two
reasons.
- Doing it that way will not give you a solution where you only have to
update the command line parsing of an existing command to stuff
negative patterns to the pathspec structure you have been passing down
to the existing codepath, and the command starts to understand negative
patterns without any other change. You introduce a new pathspec that
holds negative patterns, and pass that along with the positive one you
have been passing down in the existing codepath for all commands that
need to understand pathspec (otherwise we will be back to a similar
situation we were in before you started looking at pathspec where we
had three different implementations giving different semantics---some
command knows how to handle this kind of pathspec but some others do
not).
- Look at the fields in 'struct pathspec' and think about what those
outside "items" list mean. The recursive and max_depth fields are about
how the namespace is traversed [*1*], so if a codepath that used to
know only about positive patterns learns to also care about negative
ones, using different settings for these two fields in two separate
'struct pathspec' does not make sense. It is conceptually much cleaner
to make 'struct pathspec' the data structure used by the updated logic
to match paths to pathspec that can have positive and negative patterns.
[Footnote]
*1* The has_wildcard field is about optimizing the matching during the
traversal so it is a bit different. Also it is our longer term goal to
get rid of the "raw" field (which does not work well to substring match
against the path when pathspec "magic" is involved), so we won't worry
about it in this discussion.
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-14 18:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202141831.59699.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> A few issues I have just noticed about this series.
>
>
> First, about naming. "Highlighting interesting parts of diff" is
> acceptable name, but "syntax highlighting for diff" is not: gitweb
> already use syntax highlighting in diff views. Call it "diff refinement
> highlighting", "highlighting changes / changed sections", "intraline
> highlighting".
OK, I'll make sure the naming is correct and consistent.
>
>
> Second, I think (but I am not sure) that there is a bug in code that
> finds common suffix and prefix.
>
> If I understand correctly the idea is to highlight changed part if
> there is at least one of common non-whitespace suffix or prefix.
> So syntax highlighting should look like this:
>
> 1. Both prefix and suffix are non empty and non whitespace only
>
> -foo -{bar} baz
> +foo +{quux} baz
>
> 2. Non empty and non whitespace only prefix
>
> -foo -{bar}
> +foo +{quux}
>
> 2. Non empty and non whitespace only suffix
>
> --{bar} baz
> ++{quux} baz
>
> But in your code $prefix is not the length of common prefix, but
> the position of end of prefix in the original line of diff. So
> you start with $prefix = 1... even though the prefix is empty.
>
> How is that supposed to work?
But see the check:
+ # Mark lines that are different from each other, but have some common
+ # part that isn't whitespace. If lines are completely different, don't
+ # mark them because that would make output unreadable, especially if
+ # diff consists of multiple lines.
+ if (($prefix == 1 && $suffix_rem == $#r && $suffix_add == $#a)
^
|
This part.
+ || ($prefix_is_space && $suffix_is_space)) {
+ $esc_rem = esc_html($rem);
+ $esc_add = esc_html($add);
+ } else {
+ $esc_rem = esc_html_mark_range(\@r, $prefix, $suffix_rem);
+ $esc_add = esc_html_mark_range(\@a, $prefix, $suffix_add);
+ }
I guess it's still not correct because it should be equal to number of
parents or $prefix_length should start from 0 like you wrote later.
>
>
> On Mon, 13 Feb 2012, Michał Kiedrowicz wrote:
> > Jakub Narebski <jnareb@gmail.com> wrote:
> > > On Mon, 13 Feb 2012, Michal Kiedrowicz wrote:
>
> > > > I haven't found *examples* on GitHub and Trac sites, but what about
> > > > these ones:
> > > >
> > > > https://github.com/gitster/git/commit/8cad4744ee37ebec1d9491a1381ec1771a1ba795
> > > > http://trac.edgewall.org/changeset/10973
> [...]
> > > BTW GitHub is closed source, but we can check what algorithm does Trac
> > > use for diff refinement highlighting (highlighting changed portions of
> > > diff).
> > >
> >
> > I think it's
> > http://trac.edgewall.org/browser/trunk/trac/versioncontrol/diff.py
> > (see markup intraline_changes()).
>
> It is get_change_extent() that finds extent of changes, as a pair
> containing the offset at which the changes start, and the negative offset
> at which the changes end. So it is the same solution you use, only
> without ignoring whitespace-only prefixes and suffixes... This code can
> be easily ported to Perl, BTW.
>
> The markup_intraline_changes() function compares lines from preimage and
> from postimage pairwise, requiring that number of lines matches, the same
> like in your algorithm.
>
So using Jeff's diff-highlight we remain quite consistent with Trac
output. There's nothing we can "steal" from it.
> > > > I would also consider ignoring prefixes/suffixes with punctuation, like:
> > > >
> > > > - * I like you.
> > > > + * Alice had a little lamb.
> > >
> > > But this patch doesn't implement this feature yet, isn't it?
> >
> > No, but is a matter of adding
> >
> > -$prefix_is_space = 0 if ($r[$prefix] !~ /\s/);
> > +$prefix_is_space = 0 if ($r[$prefix] !~ /\s|[[:punct:]]/);
> >
> > (and the same for suffix)
>
> All right. But it is better added as separate patch.
Sure
> Perhaps even
> requiring that not only there is at least one of common prefix or common
> suffix, but at least one of them is not whitespace only could be put
> in a separate commit...
>
> > > > > > +sub format_rem_add_line {
> > > > > > + my ($rem, $add) = @_;
> > > > > > + my @r = split(//, $rem);
> > > > > > + my @a = split(//, $add);
> > >
> > > BTW the name of variable can be just @add and @rem.
> > >
> >
> > I know they are different scopes but I don't like it. It makes the code
> > more confusing IMO. But I won't insist.
>
> In my opinion if the variable refers to the same entity in different
> forms, using @foo and %foo (used in gitweb), or $foo and @foo (could be
> used here) is all right, and even better than trying to come up with
> different name for the same thing because of sigil.
OK. I'll follow that convention then.
>
> > > > > Shouldn't
> > > > > $prefix / $prefix_len start from 0, not from 1?
> > > >
> > > > It starts from 1 because it skips first +/-. It should become obvious
> > > > after reading the comment from last patch :).
>
> This means that $prefix is true even if prefix is empty ($prefix == 1).
> Wouldn't it be better for $prefix_len to count length of true prefix,
> without diff adornment? Or make @r / @rem skip initial characters...
>
> > > > + # In combined diff we must ignore two +/- characters.
> > > > + $prefix = 2 if ($is_combined);
> > >
> > > Anyway comment about that fact would be nice.
> >
> > Will do.
>
> BTW. it is not "2" but "scalar @{$co{'parents'}}".
>
OK.
>
> > > > The splitting and comparing by characters is taken from diff-highlight.
> > > > I don't think it's worth changing here.
> > >
> > > You are right.
> > >
> > > I'll try to come with hacky algorithm using string bitwise xor and regexp,
> > > and benchmark it comparing to your C-like solution, but it can be left for
> > > later (simple is better than clever, usually).
> >
> > If you have time :).
>
> Anyway it would be separate commit. Better to just copy tested code
> from contrib/diff-highlight
>
> BTW. would "git blame -C -C -C -w" detect this correctly as code
> movement^W copying?
>
Cannot say. Have you considered what I wrote in a separate e-mail,
about using diff-highlight output directly / as a library?
^ permalink raw reply
* Re: [PATCH] column: Fix an incorrect parse of the 'nodense' option token
From: Ramsay Jones @ 2012-02-14 18:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <CACsJy8B7=6OYBV-HVK3Cq4_cTdPvm_1MvVv=U2R=4yQw9t5X9Q@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> It's about overriding config. If you set "dense" by default in
> column.ui but do not want it in this particular run, you can say
> --column=nodense.
Ah, OK, I missed that (obvious in retrospect!). Thanks.
> The [no]color is for plumbing only. If a command produces colored
> output, "color" is required to calculate text length correctly.
> Overriding it with "nocolor" would break the layout badly so it's no
> use there. It does not make sense (to me) for users to put "color" in
> column.ui. Which is why it's not mentioned in document.
Er... but 'color' is documented with column.ui in config.txt.
I'm obviously (still) being dense! :-D
ATB,
Ramsay Jones
^ permalink raw reply
* Re: cvs2git migration
From: supadhyay @ 2012-02-14 18:33 UTC (permalink / raw)
To: git
In-Reply-To: <1329220866066-7283631.post@n2.nabble.com>
Hi All,
Can any one please update me what would be the method/steps to migrate
existing CVS users to GIT in CVS2GIT migration? User migration is possible
or not?
Thanks in advance...
--
View this message in context: http://git.661346.n2.nabble.com/cvs2git-migration-tp7283631p7285021.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC PATCH 0/3] git-p4: move to toplevel
From: Junio C Hamano @ 2012-02-14 18:40 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Pete Wyckoff, git, Luke Diamand, Vitor Antunes
In-Reply-To: <20120214092048.GC1762@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> On Mon, Feb 13, 2012 at 01:20:25PM -0800, Junio C Hamano wrote:
>> Clemens Buchacher <drizzd@aon.at> writes:
>>
>> >> Erm,... do you really need the alias if you add git-p4 in a directory on
>> >> your $PATH?
>> >
>> > With recent git versions, this has stopped working.
>>
>> Erm, I am confused.
>
> Looks like in my case it did not work because I had a PATH entry with a
> '~' in it. It probably stopped working for me because I moved some
> executables around.
>
> It's not a regression (I just tried with 1.6.0 and I get the same
> result). And dash does not apply tilde expansion to PATH either.
I do not think tilde in $PATH is expanded by exec*p family to begin with,
so it is not "dash" but POSIX, I would think. It is bash that is harming
other programs, by trying to be more helpful, encouraging this user
mistake to add ~ literally on the PATH.
You can see it in action below.
$ cd /var/tmp
$ cat >execlptest.c <<\EOF
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <stdio.h>
int main(int ac, const char **av)
{
int status = execlp("xyzzy", "xyzzy", NULL);
printf("execlp returned %d (errno = %d, %s)\n",
status, errno, strerror(errno));
return 0;
}
EOF
$ gcc -o execlptest execlptest.c
$ cat >/home/junio/junk/xyzzy <<\EOF
#!/bin/sh
exec lp test
EOF
$ chmod +x /home/junio/junk/xyzzy
$ PATH=/usr/bin:/bin
$ export PATH
$ /var/tmp/execlptest
execlp returned -1 (errno = 2, No such file or directory)
: notice the sq pair around the value on the next line
$ PATH='/usr/bin:/bin:~/junk'; export PATH; echo "$PATH"
/usr/bin:/bin:~/junk
$ /var/tmp/execlptest
execlp returned -1 (errno = 2, No such file or directory)
$ xyzzy
exec lp test
$ echo $BASH_VERSION
4.1.5(1)-release
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jeff King @ 2012-02-14 18:52 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: Jakub Narebski, git
In-Reply-To: <20120214192340.2d473866@gmail.com>
On Tue, Feb 14, 2012 at 07:23:40PM +0100, Michał Kiedrowicz wrote:
> > > > BTW GitHub is closed source, but we can check what algorithm does Trac
> > > > use for diff refinement highlighting (highlighting changed portions of
> > > > diff).
> > > >
> > > I think it's
> > > http://trac.edgewall.org/browser/trunk/trac/versioncontrol/diff.py
> > > (see markup intraline_changes()).
> [...]
> [...]
> > The markup_intraline_changes() function compares lines from preimage and
> > from postimage pairwise, requiring that number of lines matches, the same
> > like in your algorithm.
>
> So using Jeff's diff-highlight we remain quite consistent with Trac
> output. There's nothing we can "steal" from it.
Neat. When I originally wrote diff-highlight, I was inspired by seeing
what Trac and GitHub did, but came up with the algorithm on my own.
Learning that Trac does the multiline thing (as we started doing with
recent patches) makes me feel even better that it's a good strategy.
As an aside, I looked at what GitHub does. It turns on highlighting only
for the single-line case, and does the same prefix/suffix thing.
It's really not very complex code; most of the hassle in diff-highlight
is ignoring (but preserving) embedded colors, so that we build on top of
existing colorization. A web tool will be doing the line coloring itself
anyway, so it can be much simpler. Elsewhere, I suggested lib-ifying
diff-highlight for gitweb to use. But once you remove the embedded color
handling, there really is not that much code, and it's probably simpler
to just rewrite it.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/3] git-p4: move to toplevel
From: Jeff King @ 2012-02-14 19:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Clemens Buchacher, Pete Wyckoff, git, Luke Diamand, Vitor Antunes
In-Reply-To: <7vaa4l8diz.fsf@alter.siamese.dyndns.org>
On Tue, Feb 14, 2012 at 10:40:04AM -0800, Junio C Hamano wrote:
> I do not think tilde in $PATH is expanded by exec*p family to begin with,
> so it is not "dash" but POSIX, I would think. It is bash that is harming
> other programs, by trying to be more helpful, encouraging this user
> mistake to add ~ literally on the PATH.
Hmm. There is an interesting ramification for run-command's "use_shell"
optimization. Typically, git runs all of the user-provided commands
given to it via the shell. But if the command contains no
meta-characters, we skip the shell invocation as an optimization, since
the shell should simply be word-splitting and calling exec, and the
behavior will be identical.
But if your shell handles PATH entries differently, then there is a
difference. I.e., doing this:
mkdir junk
ln -s /usr/bin/vi junk/my-editor
export PATH=~/junk:$PATH
export GIT_EDITOR=my-editor
git commit
might work without the optimization, but not with.
We could check PATH and disable the optimization in that case, but I
suspect it is not worth it, as:
1. People who put a literal "~" in their PATH get what they deserve
anyway. :)
2. We explicitly run "sh" in such situations, not SHELL_PATH. Even if
"sh" is bash, I believe it should look at its own argv[0] and put
itself into a more POSIX-y mode (but I didn't test).
-Peff
^ permalink raw reply
* Re: [PATCH 2/5] do not override receive-pack errors
From: Junio C Hamano @ 2012-02-14 19:06 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20120214083324.GA1762@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Yes, it really is. For example, in t5504 rev-list --verify-objects (it
> was turned on for me if called from there) detects the corrupt object.
> But the error string is later overwritten with the return value of
> update, which is NULL in this case.
> ...
> Actually, check_alias_update searches for aliases of cmd in ref_list,
> which is a list of refs from all commands, irrespective of their error
> status. So this change is correct.
Ok, thanks for clarificatin on both counts.
^ 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