clone URL missing in gitweb
Hi, I setup gitweb and it is working. When you click any project in gitweb following information will be displayed cloning git clone http://.domain.com/git/Android/Abalone.git description email client - web hybrid owner ciebv245a daemon last change Thu, 10 May 2012 15:44:36 + But in my setup i coould not find cloaning option How do i get http url as you see blow http://git.kernel.org/?p=bluetooth/bluez-gnome.git;a=summary description Bluetooth applications for GNOME owner Marcel Holtmann URL git://git.kernel.org/pub/scm/bluetooth/bluez-gnome.git http://git.kernel.org/pub/scm/bluetooth/bluez-gnome.git https://git.kernel.org/pub/scm/bluetooth/bluez-gnome.git -- View this message in context: http://git.661346.n2.nabble.com/clone-URL-missing-in-gitweb-tp7563176.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 4/4] git-rebase: add keep_empty flag
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman nhor...@tuxdriver.com wrote:
pick_one () {
ff=--ff
+
case $1 in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
case $force_rebase in '') ;; ?*) ff= ;; esac
output git rev-parse --verify $sha1 || die Invalid commit name:
$sha1
+
+ if is_empty_commit $sha1
+ then
+ empty_args=--allow-empty
+ fi
+
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $ff $@
+ output git cherry-pick $empty_args $ff $@
The is_empty_commit check seems to mean that if $sha1 is an empty
commit, we pass the --allow-empty option to cherry-pick. If it's not
empty, we don't. The word allow in allow-empty suggests that even
if the commit is not empty, cherry-pick would not mind. So, can we
always pass allow-empty to cherry-pick (i.e. even if the commit to
pick is not empty)?
Sorry I'm commenting so late; I didn't have time to look at your
patches when you sent them, but I'm currently working on the code
touched by this patch.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: respect --no-ext-diff with typechange
On Tue, Jul 17, 2012 at 10:08:59PM -0700, Junio C Hamano wrote: The impression I got from Peff's review was that the problem description in the proposed commit log message did not describe the reality at all, and the added three lines did not do what the message implied they do. So I do not see how it can be acceptable by anybody. It also needs a test to protect this fix from being broken by other people in the future. Yeah, exactly. -- 8 -- Subject: diff: correctly disable external_diff with --no-ext-diff Upon seeing a type-change filepair, diff --no-ext-diff does not show the usual deletion followed by addition split patch and does not run the external diff driver either. This is because the logic to disable external diff was placed at a wrong level in the callchain. run_diff_cmd() decides to show the split patch only when external diff driver is not configured or specified via GIT_EXTERNAL_DIFF environment, but this is done before checking if --no-ext-diff was given. To make things worse, run_diff_cmd() checks --no-ext-diff and disables the output for such a filepair completely, as the callchain below it (e.g. builtin_diff) does not want to handle typechange filepairs. Signed-off-by: Junio C Hamano gits...@pobox.com Your patch looks good to me. --- * The use of userdiff_find_by_path() in run_diff_cmd() may be iffy; it is probably OK to override diff.external with a more specific per-path configuration, but I think an external diff specified by the GIT_EXTERNAL_DIFF environment may want to trump the configured per-path one, as an environment is a stronger one-shot request. I think this date all the way back to f1af60b (Support 'diff=pgm' attribute, 2007-04-22). There's a tradeoff here; usually environment variables trump config, but you end up using a large hammer (here is how to diff _all_ files externally) to hit a small nail (here is how to diff _just_ this file). I suspect it isn't that big a problem in practice because people tend to use either one mechanism or the other. The most sensible thing to me is probably $GIT_EXTERNAL_DIFF, followed by attributes, followed by diff.external. That uses the more specific diff pulled from the on-disk config, but allows you to do one-shot overrides with the environment as long as you are careful to restrict your command (e.g., GIT_EXTERNAL_DIFF=foo-differ git diff -- file.foo). But this patch is not about changing that semantics, so I left it as-is. Sounds sensible. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: respect --no-ext-diff with typechange
On Wed, Jul 18, 2012 at 02:23:29AM -0400, Jeff King wrote:
* The use of userdiff_find_by_path() in run_diff_cmd() may be iffy;
it is probably OK to override diff.external with a more specific
per-path configuration, but I think an external diff specified by
the GIT_EXTERNAL_DIFF environment may want to trump the
configured per-path one, as an environment is a stronger one-shot
request.
I think this date all the way back to f1af60b (Support 'diff=pgm'
attribute, 2007-04-22). There's a tradeoff here; usually environment
variables trump config, but you end up using a large hammer (here is how
to diff _all_ files externally) to hit a small nail (here is how to diff
_just_ this file). I suspect it isn't that big a problem in practice
because people tend to use either one mechanism or the other.
The most sensible thing to me is probably $GIT_EXTERNAL_DIFF, followed
by attributes, followed by diff.external. That uses the more specific
diff pulled from the on-disk config, but allows you to do one-shot overrides
with the environment as long as you are careful to restrict your command
(e.g., GIT_EXTERNAL_DIFF=foo-differ git diff -- file.foo).
Here's a patch implementing that. This is definitely how I would have
done it if I were starting from scratch. My only hesitation now is that
I don't care too deeply either way, and it is technically a behavior
change. So there is a chance of regression for something that nobody has
actually complained about. To be honest, I doubt many people are using
external diff at all these days; textconv is closer to what most people
want, and is much easier to use.
-- 8 --
Subject: [PATCH] diff: fix precedence of external diff options
There are three ways to specify an external diff command:
GIT_EXTERNAL_DIFF in the environment, diff.external in the
config, or a diff gitattribute. The current order of
precedence is:
1. gitattribute
2. GIT_EXTERNAL_DIFF
3. diff.external
But usually our rule is that environment variables should
take precedence over on-disk config (i.e., option 2 should
come before option 1). This situation is trickier than some,
because option 1 is more specific to the individual file
than option 2 (which affects all files), so it might be
preferable. So the current behavior can be seen as
implementing do the specific thing if we can, but fall back
to this general thing.
However, since you can already implement that behavior (by
combining attributes with a diff.external setting), and
because environment variables can be useful for one-shot
overrides (e.g., GIT_EXTERNAL_DIFF=foo git diff -- bar to
override bar's gitattribute setting), let's switch the
precedence of options 1 and 2 above.
While we're adding tests to t4020 for the precedence, let's
also make sure that diff.external works at all by running it
through the same tests as GIT_EXTERNAL_DIFF.
Signed-off-by: Jeff King p...@peff.net
---
diff.c | 35 +++
t/t4020-diff-external.sh | 41 +
2 files changed, 56 insertions(+), 20 deletions(-)
diff --git a/diff.c b/diff.c
index 62cbe14..ed2de96 100644
--- a/diff.c
+++ b/diff.c
@@ -238,18 +238,20 @@ static char *quote_two(const char *one, const char *two)
return strbuf_detach(res, NULL);
}
-static const char *external_diff(void)
+static const char *external_diff(const char *path)
{
- static const char *external_diff_cmd = NULL;
- static int done_preparing = 0;
+ const char *r;
+ struct userdiff_driver *drv;
- if (done_preparing)
- return external_diff_cmd;
- external_diff_cmd = getenv(GIT_EXTERNAL_DIFF);
- if (!external_diff_cmd)
- external_diff_cmd = external_diff_cmd_cfg;
- done_preparing = 1;
- return external_diff_cmd;
+ r = getenv(GIT_EXTERNAL_DIFF);
+ if (r)
+ return r;
+
+ drv = userdiff_find_by_path(path);
+ if (drv drv-external)
+ return drv-external;
+
+ return external_diff_cmd_cfg;
}
static struct diff_tempfile {
@@ -2992,13 +2994,6 @@ static void run_diff_cmd(const char *pgm,
int complete_rewrite = (p-status == DIFF_STATUS_MODIFIED) p-score;
int must_show_header = 0;
-
- if (DIFF_OPT_TST(o, ALLOW_EXTERNAL)) {
- struct userdiff_driver *drv = userdiff_find_by_path(attr_path);
- if (drv drv-external)
- pgm = drv-external;
- }
-
if (msg) {
/*
* don't use colors when the header is intended for an
@@ -3059,7 +3054,7 @@ static void strip_prefix(int prefix_length, const char
**namep, const char **oth
static void run_diff(struct diff_filepair *p, struct diff_options *o)
{
- const char *pgm = external_diff();
+ const char *pgm = NULL;
struct strbuf msg;
struct diff_filespec *one = p-one;
struct
Re: [PATCH v8 4/4] git-rebase: add keep_empty flag
Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman nhor...@tuxdriver.com wrote:
pick_one () {
ff=--ff
+
case $1 in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
case $force_rebase in '') ;; ?*) ff= ;; esac
output git rev-parse --verify $sha1 || die Invalid commit name:
$sha1
+
+ if is_empty_commit $sha1
+ then
+ empty_args=--allow-empty
+ fi
+
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $ff $@
+ output git cherry-pick $empty_args $ff $@
The is_empty_commit check seems to mean that if $sha1 is an empty
commit, we pass the --allow-empty option to cherry-pick. If it's not
empty, we don't. The word allow in allow-empty suggests that even
if the commit is not empty, cherry-pick would not mind. So, can we
always pass allow-empty to cherry-pick (i.e. even if the commit to
pick is not empty)?
I don't think so. If the commit is not empty, but all its changes are
already in HEAD, then it will become empty when cherry-picked to HEAD.
In such a case, we usually do not want to record an empty commit, but stop
rebase to give to user a chance to deal with the situation.
-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 4/4] git-rebase: add keep_empty flag
On Wed, Jul 18, 2012 at 12:10 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman nhor...@tuxdriver.com wrote:
pick_one () {
ff=--ff
+
case $1 in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
case $force_rebase in '') ;; ?*) ff= ;; esac
output git rev-parse --verify $sha1 || die Invalid commit name:
$sha1
+
+ if is_empty_commit $sha1
+ then
+ empty_args=--allow-empty
+ fi
+
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $ff $@
+ output git cherry-pick $empty_args $ff $@
The is_empty_commit check seems to mean that if $sha1 is an empty
commit, we pass the --allow-empty option to cherry-pick. If it's not
empty, we don't. The word allow in allow-empty suggests that even
if the commit is not empty, cherry-pick would not mind. So, can we
always pass allow-empty to cherry-pick (i.e. even if the commit to
pick is not empty)?
I don't think so. If the commit is not empty, but all its changes are
already in HEAD, then it will become empty when cherry-picked to HEAD.
In such a case, we usually do not want to record an empty commit, but stop
rebase to give to user a chance to deal with the situation.
Ah, makes sense. Thanks!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Fix notes handling in rev-list
On Mon, Jul 16, 2012 at 10:42:07PM -0700, Junio C Hamano wrote: Just like log, the notes are part of the commit information to the right of the graph. But this second hunk is for when we are not using the pretty-printer at all, and the output looks like this: $ git rev-list --graph --notes -2 HEAD * f6bbb09529a4cc73446c7c115ac1468477bd0cc6 Notes: foobar * 31c79549b85c6393be4f40432f5b86ebc097fc7e which doesn't make sense I actually have quite a different feeling about this. As I said in the separate message, I think --graph, or anything that makes the output unparsable or harder to parse for machines for that matter, in rev-list are not something we have because we wanted to support them, but that which just happen to work because the large part of rev-list and log can share building blocks to do similar things. The key phrase is can share here; it does not necessarily mean they should [*1*]. Somebody went to the trouble to make rev-list --graph work[1] (that is what the call to graph_show_remainder in the else clause of the conditional is about). I agree it seems kind of useless, but it does work now, and we should at least not make it worse (and I think we both agree that the output above is just wrong). So whatever we show for a note, it should look like: * f6bbb095... | the notes thing to show * 31c79549... Because that is how graph output is formatted. Either that, or we should disallow --graph entirely with rev-list (which I'd also be OK with). I do not mind having an option to show the notes text, but I doubt it is a sane thing to do to make rev-list --notes unconditionally show the payload of the notes blob. rev-list --objects only shows the object names of trees and blobs, not the payload in these objects, and this is very much on purpuse. It allows the downstream process that reads its output from the pipe to easily parse the output and choose to do whatever it wants to do using them. I wonder if we should show the blob object names that store the notes payload if we were given --notes option in a format that is easy for readers to mechanically parse its output. So leaving aside the --graph issues, we would need to decide what to show in the non-graph case. And I think your suggestion is good; there is no real need to dereference the blob (if you want that, you can turn on the pretty-printer). I'm just not sure what the output should be. I guess: commit_sha1 notes sha1s is probably the most sensible (it's sort of like --parents). And that solves the --graph issue, too, since it continues to take only a single line. -Peff [1] Looking at the code, I do think somebody wanted rev-list --graph to work, and it is not an accident. But I think they did not do a very thorough job, as things like git rev-list --objects --graph produce nonsensical output. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: clone URL missing in gitweb
Quoting baluchen murugan.b...@gmail.com: Hi, hi, But in my setup i coould not find cloaning option cloneurl is a per repository option, which is set as config option in your repository. see man gitweb for details. what you're probably searching for is the global option git_base_url_list, which is used by gitweb to generate the clone URLs. hth, tom. -- Thomas Duke Hager d...@sigsegv.at GPG: 2048R/791C5EB1http://www.sigsegv.at/gpg/duke.gpg = Never Underestimate the Power of Stupid People in Large Groups. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] git-rebase--interactive: group all $preserve_merges code
The code in git-rebase--interactive that creates the todo file
contains if-blocks that depend on whether $preserve_merges is
active. There is only a very small amount of code in between that is
shared with non-merge-preserving code path, so remove the repeated
conditions and duplicate the small amount of shared code instead.
---
git-rebase--interactive.sh | 69 ++
1 file changed, 33 insertions(+), 36 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index fa722b6..4bb8e3f 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -793,28 +793,6 @@ mkdir $state_dir || die Could not create temporary
$state_dir
: $state_dir/interactive || die Could not mark as interactive
write_basic_state
-if test t = $preserve_merges
-then
- if test -z $rebase_root
- then
- mkdir $rewritten
- for c in $(git merge-base --all $orig_head $upstream)
- do
- echo $onto $rewritten/$c ||
- die Could not init rewritten commits
- done
- else
- mkdir $rewritten
- echo $onto $rewritten/root ||
- die Could not init rewritten commits
- fi
- # No cherry-pick because our first pass is to determine
- # parents to rewrite and skipping dropped commits would
- # prematurely end our probe
- merges_option=
-else
- merges_option=--no-merges --cherry-pick
-fi
shorthead=$(git rev-parse --short $orig_head)
shortonto=$(git rev-parse --short $onto)
@@ -839,16 +817,30 @@ add_pick_line () {
printf '%s\n' ${comment_out}pick $1 $2 $todo
}
-git rev-list $merges_option --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --topo-order \
- $revisions | \
- sed -n s/^//p |
-while read -r shortsha1 rest
-do
- if test t != $preserve_merges
+if test t = $preserve_merges
+then
+ if test -z $rebase_root
then
- add_pick_line $shortsha1 $rest
+ mkdir $rewritten
+ for c in $(git merge-base --all $orig_head $upstream)
+ do
+ echo $onto $rewritten/$c ||
+ die Could not init rewritten commits
+ done
else
+ mkdir $rewritten
+ echo $onto $rewritten/root ||
+ die Could not init rewritten commits
+ fi
+ # No cherry-pick because our first pass is to determine
+ # parents to rewrite and skipping dropped commits would
+ # prematurely end our probe
+ git rev-list --pretty=oneline --abbrev-commit \
+ --abbrev=7 --reverse --left-right --topo-order \
+ $revisions |
+ sed -n s/^//p |
+ while read -r shortsha1 rest
+ do
sha1=$(git rev-parse $shortsha1)
if test -z $rebase_root
then
@@ -868,12 +860,8 @@ do
touch $rewritten/$sha1
add_pick_line $shortsha1 $rest
fi
- fi
-done
-
-# Watch for commits that been dropped by --cherry-pick
-if test t = $preserve_merges
-then
+ done
+ # Watch for commits that been dropped by --cherry-pick
mkdir $dropped
# Save all non-cherry-picked changes
git rev-list $revisions --left-right --cherry-pick | \
@@ -895,6 +883,15 @@ then
rm $rewritten/$rev
fi
done
+else
+ git rev-list --no-merges --cherry-pick --pretty=oneline --abbrev-commit
\
+ --abbrev=7 --reverse --left-right --topo-order \
+ $revisions |
+ sed -n s/^//p |
+ while read -r shortsha1 rest
+ do
+ add_pick_line $shortsha1 $rest
+ done
fi
test -s $todo || echo noop $todo
--
1.7.11.1.104.ge7b44f1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] git-rebase--interactive.sh: extract function for adding pick line
Extract the code that adds a possibly commented-out pick line to the
todo file. This lets us reuse it more easily later.
---
git-rebase--interactive.sh | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bef7bc0..fa722b6 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -828,23 +828,26 @@ else
revisions=$onto...$orig_head
shortrevisions=$shorthead
fi
-git rev-list $merges_option --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --topo-order \
- $revisions | \
- sed -n s/^//p |
-while read -r shortsha1 rest
-do
- if test -z $keep_empty is_empty_commit $shortsha1
+add_pick_line () {
+ if test -z $keep_empty is_empty_commit $1
then
comment_out=#
else
comment_out=
fi
+ printf '%s\n' ${comment_out}pick $1 $2 $todo
+}
+git rev-list $merges_option --pretty=oneline --abbrev-commit \
+ --abbrev=7 --reverse --left-right --topo-order \
+ $revisions | \
+ sed -n s/^//p |
+while read -r shortsha1 rest
+do
if test t != $preserve_merges
then
- printf '%s\n' ${comment_out}pick $shortsha1 $rest $todo
+ add_pick_line $shortsha1 $rest
else
sha1=$(git rev-parse $shortsha1)
if test -z $rebase_root
@@ -863,7 +866,7 @@ do
if test f = $preserve
then
touch $rewritten/$sha1
- printf '%s\n' ${comment_out}pick $shortsha1 $rest
$todo
+ add_pick_line $shortsha1 $rest
fi
fi
done
--
1.7.11.1.104.ge7b44f1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] rebase -p: use --cherry-mark for todo file
While building the todo file, 'rebase -p' needs to find the cherry-picked commits in the branch that is about to be rebased. For this, it calculates the set difference between the full set of commits and the non-cherry-picked ones (as reported by 'git rev-list --left-right --cherry-pick'). Now that have the 'git rev-list --cherry-mark' option (since adbbb31 (revision.c: introduce --cherry-mark, 2011-03-07)), we can instead use that option to get the set of cherry-picked commits. --- git-rebase--interactive.sh | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 9715830..47beb58 100644 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -859,17 +859,12 @@ then add_pick_line $sha1 fi done - # Watch for commits that been dropped by --cherry-pick + # Now drop cherry-picked commits mkdir $dropped - # Save all non-cherry-picked changes - git rev-list $revisions --left-right --cherry-pick | \ - sed -n s/^//p $state_dir/not-cherry-picks - # Now all commits and note which ones are missing in - # not-cherry-picks and hence being dropped - git rev-list $revisions | + git rev-list $revisions --cherry-mark --right-only | sed -ne s/^=//p | while read rev do - if test -f $rewritten/$rev -a $(sane_grep $rev $state_dir/not-cherry-picks) = + if test -f $rewritten/$rev then # Use -f2 because if rev-list is telling us this commit is # not worthwhile, we don't want to track its multiple heads, -- 1.7.11.1.104.ge7b44f1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] rebase -p: don't request --left-right only to ignore left side
While generating the todo file, rebase -p calls 'git rev-list --left-right a...b' (with 'a' equal to $upstream or $onto and 'b' equal to $orig_head) and its output is piped through 'sed -n s/^//p', making it equivalent to 'git rev-list --right-only a...b'. Change the invocation to exactly that. (One could alternatively change it to 'git rev-list a..b', which would be even simpler, if it wasn't for the fact that we already have the revision range expression in a variable.) --- git-rebase--interactive.sh | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 47beb58..cd5a2cc 100644 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -836,8 +836,7 @@ then # No cherry-pick because our first pass is to determine # parents to rewrite and skipping dropped commits would # prematurely end our probe - git rev-list $revisions --reverse --left-right --topo-order | - sed -n s/^//p | + git rev-list $revisions --reverse --right-only --topo-order | while read -r sha1 do if test -z $rebase_root -- 1.7.11.1.104.ge7b44f1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] git-rebase--interactive.sh: look up subject in add_pick_line
The todo file is generated using (more-or-less) 'git rev-list
$revisions --pretty=oneline --abbrev-commit --abbrev=7', i.e. by
letting 'git rev-list' output both the abbreviated sha1 and the
subject line. To allow us to more easily generate the list of commits
to rebase by using commands that don't support outputting the subject
line, move this logic into add_pick_line.
---
git-rebase--interactive.sh | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 4bb8e3f..9715830 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -814,7 +814,8 @@ add_pick_line () {
else
comment_out=
fi
- printf '%s\n' ${comment_out}pick $1 $2 $todo
+ line=$(git rev-list -1 --pretty=oneline --abbrev-commit --abbrev=7 $1)
+ printf '%s\n' ${comment_out}pick $line $todo
}
if test t = $preserve_merges
@@ -835,13 +836,10 @@ then
# No cherry-pick because our first pass is to determine
# parents to rewrite and skipping dropped commits would
# prematurely end our probe
- git rev-list --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --topo-order \
- $revisions |
+ git rev-list $revisions --reverse --left-right --topo-order |
sed -n s/^//p |
- while read -r shortsha1 rest
+ while read -r sha1
do
- sha1=$(git rev-parse $shortsha1)
if test -z $rebase_root
then
preserve=t
@@ -858,7 +856,7 @@ then
if test f = $preserve
then
touch $rewritten/$sha1
- add_pick_line $shortsha1 $rest
+ add_pick_line $sha1
fi
done
# Watch for commits that been dropped by --cherry-pick
@@ -884,13 +882,12 @@ then
fi
done
else
- git rev-list --no-merges --cherry-pick --pretty=oneline --abbrev-commit
\
- --abbrev=7 --reverse --left-right --topo-order \
- $revisions |
+ git rev-list $revisions --reverse --left-right --topo-order \
+ --no-merges --cherry-pick |
sed -n s/^//p |
- while read -r shortsha1 rest
+ while read -r sha1
do
- add_pick_line $shortsha1 $rest
+ add_pick_line $sha1
done
fi
--
1.7.11.1.104.ge7b44f1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] correctly calculate patches to rebase
These seven patches replace the broken one I sent in http://thread.gmane.org/gmane.comp.version-control.git/200644/focus=200648. I hope I got the handling of empty commits right this time. Martin von Zweigbergk (7): git-rebase--am.sh: avoid special-casing --keep-empty git-rebase--interactive.sh: extract function for adding pick line git-rebase--interactive: group all $preserve_merges code git-rebase--interactive.sh: look up subject in add_pick_line rebase -p: use --cherry-mark for todo file rebase -p: don't request --left-right only to ignore left side rebase (without -p): correctly calculate patches to rebase git-am.sh | 10 +- git-rebase--am.sh | 20 +++ git-rebase--interactive.sh | 87 -- git-rebase--merge.sh | 2 +- git-rebase.sh | 11 +++--- t/t3401-rebase-partial.sh | 17 + t/t3406-rebase-message.sh | 14 7 files changed, 81 insertions(+), 80 deletions(-) -- 1.7.11.1.104.ge7b44f1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] rebase (without -p): correctly calculate patches to rebase
The different types of rebase use different ways of calculating the
patches to rebase.
'git rebase' (without -m/-i/-p) uses
git format-patch --ignore-if-in-upstream $upstream..$orig_head
'git rebase -m' uses
git rev-list $upstream..$orig_head
'git rebase -i' (without -p) uses
git rev-list $upstream...$orig_head --left-right --no-merges \
--cherry-pick | sed -n s/^//p
, which could also have been written
git rev-list $upstream...$orig_head --right-only --no-merges \
--cherry-pick
'git rebase -p' uses
git rev-list $upstream...$orig_head --right-only
followed by cherry-picked commits found by
git rev-list $upstream...$orig_head --cherry-mark --right-only |
| sed -ne s/^=//p
As Knut Franke reported in [1], the fact that there is no
--ignore-if-in-upstream or equivalent when using merge-based rebase
means that unnecessary conflicts can arise due to commits
cherry-picked between $orig_head and $upstream.
With all the other types, there is a different problem with the method
of calculating the commits to rebase. Copying the example history from
[1]:
.-c
/
a---b---d---e---f
\
.-g---E
Commit E is here a cherry-pick of e. If we now run 'git rebase [-i|-p]
--onto c f E', the commits to rebase will be those on E that are not
equivalent to any of those in f, which in this case would be only
'g'. Commit 'E' would thus be lost.
To solve both of the above problems, we want to find the commits in
$upstream..$orig_head that are not cherry-picked in
$orig_head..$onto. There is unfortunately no direct way of finding
these commits using 'git rev-list', so we will have to resort to using
'git cherry' and filter for lines starting with '+'. This works for
all but 'rebase -p', since 'git cherry' ignores merges.
As a side-effect, we also avoid the cost of formatting patches.
Test case updates for 'rebase -m' by Knut, the rest by Martin.
[1] http://thread.gmane.org/gmane.comp.version-control.git/161917
Helped-by: Knut Franke knut.fra...@gmx.de
Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
---
git-rebase--am.sh | 6 ++
git-rebase--interactive.sh | 8 +++-
git-rebase--merge.sh | 2 +-
git-rebase.sh | 11 ---
t/t3401-rebase-partial.sh | 17 +
t/t3406-rebase-message.sh | 14 +++---
6 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index 37c1b23..fe3fdd1 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -16,11 +16,9 @@ skip)
;;
esac
-test -n $rebase_root root_flag=--root
test -n $keep_empty git_am_opt=$git_am_opt --keep-empty
-git format-patch -k --stdout --full-index --ignore-if-in-upstream \
- --src-prefix=a/ --dst-prefix=b/ \
- --no-renames $root_flag $revisions |
+generate_revisions |
+sed -e 's/\([0-9a-f]\{40\}\)/From \1 Mon Sep 17 00:00:00 2001/' |
git am $git_am_opt --rebasing --resolvemsg=$resolvemsg
move_to_original_branch
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index cd5a2cc..da32ca7 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -800,10 +800,8 @@ if test -z $rebase_root
# this is now equivalent to ! -z $upstream
then
shortupstream=$(git rev-parse --short $upstream)
- revisions=$upstream...$orig_head
shortrevisions=$shortupstream..$shorthead
else
- revisions=$onto...$orig_head
shortrevisions=$shorthead
fi
@@ -822,6 +820,7 @@ if test t = $preserve_merges
then
if test -z $rebase_root
then
+ revisions=$upstream...$orig_head
mkdir $rewritten
for c in $(git merge-base --all $orig_head $upstream)
do
@@ -829,6 +828,7 @@ then
die Could not init rewritten commits
done
else
+ revisions=$onto...$orig_head
mkdir $rewritten
echo $onto $rewritten/root ||
die Could not init rewritten commits
@@ -876,9 +876,7 @@ then
fi
done
else
- git rev-list $revisions --reverse --left-right --topo-order \
- --no-merges --cherry-pick |
- sed -n s/^//p |
+ generate_revisions |
while read -r sha1
do
add_pick_line $sha1
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
index b10f2cf..bf4ec4b 100644
--- a/git-rebase--merge.sh
+++ b/git-rebase--merge.sh
@@ -131,7 +131,7 @@ echo $onto_name $state_dir/onto_name
write_basic_state
msgnum=0
-for cmt in `git rev-list --reverse --no-merges $revisions`
+for cmt in $(generate_revisions)
do
msgnum=$(($msgnum + 1))
echo $cmt $state_dir/cmt.$msgnum
diff --git a/git-rebase.sh b/git-rebase.sh
index 1cd0633..0fdff87 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -530,6 +530,10 @@ then
GIT_PAGER='' git diff --stat
Re: [PATCH 0/7] correctly calculate patches to rebase
Argh! Sorry about the sendemail.chainreplyto=true. I must have read that warning message incorrectly :-(. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] git-rebase--am.sh: avoid special-casing --keep-empty
Since 0fbb95d (am: don't call mailinfo if $rebasing, 2012-06-26), the
patch body to apply when running 'git am --rebasing' is not taken from
the mbox, but directly from the commit. If such a commit is empty,
'git am --rebasing' still happily applies it and commits. However,
since the input to 'git am --rebasing' only ever comes from 'git
format-patch', which completely leaves the commit out from its output
if it's empty, no empty commits are ever created by 'git am
--rebasing'. By teaching 'git am --rebasing' a --keep-empty option and
letting the caller decide whether or not to keep empty commits, we can
unify the two different mechanisms that git-rebase--am.sh uses for
rebasing.
---
git-am.sh | 10 +-
git-rebase--am.sh | 20 ++--
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b6a5300..37641b7 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -37,7 +37,8 @@ abort restore the original branch and abort the
patching operation.
committer-date-is-author-datelie about committer date
ignore-date use current timestamp for author date
rerere-autoupdate update the index with reused conflict resolution if possible
-rebasing* (internal use for git-rebase)
+rebasing* (internal use for git-rebase)
+keep-empty* (internal use for git-rebase)
. git-sh-setup
. git-sh-i18n
@@ -375,6 +376,7 @@ git_apply_opt=
committer_date_is_author_date=
ignore_date=
allow_rerere_autoupdate=
+keep_empty=
if test $(git config --bool --get am.keepcr) = true
then
@@ -414,6 +416,8 @@ do
abort=t ;;
--rebasing)
rebasing=t threeway=t ;;
+ --keep-empty)
+ keep_empty=t ;;
-d|--dotest)
die $(gettext -d option is no longer supported. Do not
use.)
;;
@@ -669,6 +673,10 @@ do
echo $commit $dotest/original-commit
get_author_ident_from_commit $commit
$dotest/author-script
git diff-tree --root --binary $commit $dotest/patch
+ test -s $dotest/patch || test -n $keep_empty || {
+ go_next
+ continue
+ }
else
git mailinfo $keep $no_inbody_headers $scissors $utf8
$dotest/msg $dotest/patch \
$dotest/$msgnum $dotest/info ||
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index 392ebc9..37c1b23 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -17,20 +17,12 @@ skip)
esac
test -n $rebase_root root_flag=--root
-
-if test -n $keep_empty
-then
- # we have to do this the hard way. git format-patch completely squashes
- # empty commits and even if it didn't the format doesn't really lend
- # itself well to recording empty patches. fortunately, cherry-pick
- # makes this easy
- git cherry-pick --allow-empty $revisions
-else
- git format-patch -k --stdout --full-index --ignore-if-in-upstream \
- --src-prefix=a/ --dst-prefix=b/ \
- --no-renames $root_flag $revisions |
- git am $git_am_opt --rebasing --resolvemsg=$resolvemsg
-fi move_to_original_branch
+test -n $keep_empty git_am_opt=$git_am_opt --keep-empty
+git format-patch -k --stdout --full-index --ignore-if-in-upstream \
+ --src-prefix=a/ --dst-prefix=b/ \
+ --no-renames $root_flag $revisions |
+git am $git_am_opt --rebasing --resolvemsg=$resolvemsg
+move_to_original_branch
ret=$?
test 0 != $ret -a -d $state_dir write_basic_state
--
1.7.11.1.104.ge7b44f1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Add a new email notification script to contrib
mhag...@alum.mit.edu writes:
* One email per commit [1]. For each reference change, the script
first emits one email summarizing the reference change (including
one-line summaries of the new commits), then emits a separate email
for each new commit that was introduced, including patches.
I have a dirty hack to do that on my private repositories (instead of
sending mail on receive, the script runs as a cron job, does a git
fetch on each repo on my machine, and sends me patches for new commits
with git send-email). I had several problems with it:
* Binary content was sometimes embedded in the patch. It's cool that
git send-email can base64-encode content when I send a patch to
someone, but it's counter-productive when used for code review. So, I
used git format-patch --no-binary.
* Even with that, I sometimes had overly long lines (e.g. non-text files
that were shown as a one long line, I don't remember exactly the
use-case, probably postscript files or so) that were confusing my
mailer. So, I added
# Truncate long lines
perl -pi -e 's/^(.{500}).*/$1 [...]/' $patches
to my script to truncate them.
You probably want to test these cases, and allow (configurably) the user
to do some cleanup on patches before they are sent.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] git-svn: don't create master if another head exists
Thanks for the review!
On Wed, Jul 11, 2012 at 03:56:43PM -0700, Junio C Hamano wrote:
Marcin Owsiany mar...@owsiany.pl writes:
Date: Sun, 24 Jun 2012 22:40:05 +0100
Subject: [PATCH] git-svn: don't create master if another head exists
git-svn insists on creating the master head (unless it exists) on every
fetch. It is useful that it gets created initially, when no head exists
- users expect this git convention of having a master branch on initial
clone.
However creating it when there already is another head does not provide any
value - the ref is never updated, so it just gets stale after a while.
Also,
some users find it annoying that it gets recreated, especially when they
would
like the git branch names to follow SVN repository branch names. More
background in http://thread.gmane.org/gmane.comp.version-control.git/115030
Make git-svn skip the master creation if HEAD points at a valid head. This
means master does get created on initial clone but does not get
recreated
once a user deletes it.
The above description makes sense to me, but the code updated with
this patch doesn't quite make sense to me.
This is your patch with a bit wider context.
diff --git a/git-svn.perl b/git-svn.perl
index 0b074c4..2379a71 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1599,35 +1599,35 @@ sub rebase_cmd {
sub post_fetch_checkout {
return if $_no_checkout;
my $gs = $Git::SVN::_head or return;
return if verify_ref('refs/heads/master^0');
Does master matter here?
I am wondering why this is not
return if verify_ref(HEAD^0);
Moreover, since the code will check verify_ref(HEAD^0) anyway in
the place you updated, is this early return still necessary?
Hm, good point, nothing between these two returns seems to modify
on-disk state.
# look for trunk ref if it exists
my $remote = Git::SVN::read_all_remotes()-{$gs-{repo_id}};
my $fetch = $remote-{fetch};
if ($fetch) {
foreach my $p (keys %$fetch) {
basename($fetch-{$p}) eq 'trunk' or next;
$gs = Git::SVN-new($fetch-{$p}, $gs-{repo_id},
$p);
last;
}
}
- my $valid_head = verify_ref('HEAD^0');
+ return if verify_ref('HEAD^0');
This one matches the description. When post_fetch_checkout() is
called, if HEAD is already pointing at a valid commit, we do not
want to run checkout (or create a ref).
command_noisy(qw(update-ref refs/heads/master), $gs-refname);
- return if ($valid_head || !verify_ref('HEAD^0'));
+ return unless verify_ref('HEAD^0');
I do not understand these three lines. Why aren't they like this?
command_noisy(qw(update-ref HEAD), $gs-refname) || return;
That is, in a fresh repository whose HEAD points at an unborn
'master', nothing changes from the current behaviour. If a fresh
repository whose HEAD points at some other unborn branch, should the
code still want to update 'master'? Wouldn't we rather want to
update that branch?
I don't know if there can ever be some other unborn branch other than
master, but I guess your proposal makes it more robust.
If the caller does not handle errors, it could be even clearer to
write it like
command_noisy(qw(update-ref HEAD), $gs-refname) ||
die Cannot update HEAD!!!;
Turns out that command_noisy()
- has a meaningless return value
- throws an exception on command failure
so the || bit does not work.
Also, for some reason command_noisy does not check for the command being
killed by a signal, so I'd prefer to leave the verify_ref there.
PTAL:
From: Marcin Owsiany mar...@owsiany.pl
Date: Sun, 24 Jun 2012 22:40:05 +0100
Subject: [PATCH] git-svn: don't create master if another head exists
git-svn insists on creating the master head (unless it exists) on every
fetch. It is useful that it gets created initially, when no head exists
- users expect this git convention of having a master branch on initial
clone.
However creating it when there already is another head does not provide any
value - the ref is never updated, so it just gets stale after a while. Also,
some users find it annoying that it gets recreated, especially when they would
like the git branch names to follow SVN repository branch names. More
background in http://thread.gmane.org/gmane.comp.version-control.git/115030
Make git-svn skip the master creation if HEAD already points at a valid head.
This means master does get created on initial clone but does not get
recreated once a user deletes it.
Also, make post_fetch_checkout work with any head that is pointed to by HEAD,
not just master.
Also, use fatal error handling consistent with the rest of the program for
post_fetch_checkout.
Signed-off-by: Marcin Owsiany mar...@owsiany.pl
---
git-svn.perl |9 -
1 files changed, 4 insertions(+), 5
Re: clone URL missing in gitweb
Thanks tom.
I verified and i have following line in my gitweb.cgi. But still i caould
not get cloan
our @git_base_url_list = grep { $_ ne '' } ();
@url_list = map { $_/$project } @git_base_url_list unless
@url_list;
# use per project git URL list in $projectroot/$project/cloneurl
# or make project git URL from git base URL and project name
my $url_tag = URL;
my @url_list = git_get_project_url_list($project);
@url_list = map { $_/$project } @git_base_url_list unless
@url_list;
foreach my $git_url (@url_list) {
next unless $git_url;
print format_repo_url($url_tag, $git_url);
$url_tag = ;
}
Thanks
Bala
--
View this message in context:
http://git.661346.n2.nabble.com/clone-URL-missing-in-gitweb-tp7563176p7563196.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: clone URL missing in gitweb
Quoting baluchen murugan.b...@gmail.com: I verified and i have following line in my gitweb.cgi. But still i caould not get cloan and what does your configuration of gitweb look like? and what do mean with But still i caould not get cloan? are you trying to clone via gitweb? bye, tom. -- Thomas Duke Hager d...@sigsegv.at GPG: 2048R/791C5EB1http://www.sigsegv.at/gpg/duke.gpg = Never Underestimate the Power of Stupid People in Large Groups. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: clone URL missing in gitweb
Tom, I verified the entries and they seems to be correct. But the clone and its URL is still now showing when browsing project summary page via gitweb Thanks Bala -- View this message in context: http://git.661346.n2.nabble.com/clone-URL-missing-in-gitweb-tp7563176p7563199.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Extract Git classes from git-svn (2/10) (was Re: Fix git-svn tests for SVN 1.7.5.)
Michael G Schwern schw...@pobox.com wrote: Hi Michael, thanks for taking your time to help with this. I agree with everything Jonathan said (and thank him for taking the time to point you in the right direction). I too (very strongly) prefer email for code review. I doubt I would've ever gotten involved if git were run differently. I'm actually disappointed the mailing list culture that built git hasn't rubbed off to other projects that adopt git. +++ b/t/Git-SVN/00compile.t +use Test::More tests = 2; I prefer not declaring test counts and using done_testing() instead. done_testing() is favorable to me in at least 2 ways: * done_testing() closely matches the behavior of the existing sh-based test suite in git (which calls test_done) * maintaining test counts leads to unnecessary merge conflicts Skipping the tests on old versions of Test::More ( 0.88) is acceptable to me (especially since integration tests provide the real coverage already). +++ b/t/Git-SVN/Utils/can_compress.t +use Test::More 'no_plan'; no_plan is the worst way to use Test::More, I think. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] mw-to-git: check blank credential attributes via length
When writing a credential to git-credential, we omit fields
that do not have a true value. This will skip empty or
undefined fields (which we want), but will also accidentally
skip usernames or passwords which happen to have a non-true
value (e.g., 0). Be more careful by checking for non-zero
length.
Signed-off-by: Jeff King p...@peff.net
---
contrib/mw-to-git/git-remote-mediawiki | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki
b/contrib/mw-to-git/git-remote-mediawiki
index accd70a..b06f27b 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -207,7 +207,7 @@ sub credential_write {
my $credential = shift;
my $writer = shift;
while (my ($key, $value) = each(%$credential) ) {
- if ($value) {
+ if (length $value) {
print $writer $key=$value\n;
}
}
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] credential: convert url attribute into its parsed subparts
The git-credential command requires that you feed it a
broken-down credential, which means that the client needs to
parse a URL itself. Since we have our own URL-parsing
routines, we can easily allow the caller to just give us the
URL as-is, saving them some code.
Signed-off-by: Jeff King p...@peff.net
---
The implementation turned out to be delightfully simple. I stopped short
of adding an ident command to git-credential where you could do
something like:
$ echo https://u...@example.com | git credential ident
protocol=https
host=example.com
username=user
since I had no use for it, but it would obviously be an easy one-liner
to write (it's just fill without the actual fill call).
Documentation/git-credential.txt | 12
credential.c | 2 ++
2 files changed, 14 insertions(+)
diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt
index afd5365..53adee3 100644
--- a/Documentation/git-credential.txt
+++ b/Documentation/git-credential.txt
@@ -140,3 +140,15 @@ Git understands the following attributes:
`password`::
The credential's password, if we are asking it to be stored.
+
+`url`::
+
+ When this special attribute is read by `git credential`, the
+ value is parsed as a URL and treated as if its constituent parts
+ were read (e.g., `url=https://example.com` would behave as if
+ `protocol=https` and `host=example.com` had been provided). This
+ can help callers avoid parsing URLs themselves. Note that any
+ components which are missing from the URL (e.g., there is no
+ username in the example above) will be set to empty; if you want
+ to provide a URL and override some attributes, provide the URL
+ attribute first, followed by any overrides.
diff --git a/credential.c b/credential.c
index 2c40007..e54753c 100644
--- a/credential.c
+++ b/credential.c
@@ -172,6 +172,8 @@ int credential_read(struct credential *c, FILE *fp)
} else if (!strcmp(key, path)) {
free(c-path);
c-path = xstrdup(value);
+ } else if (!strcmp(key, url)) {
+ credential_from_url(c, value);
}
/*
* Ignore other lines; we don't know what they mean, but
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] mw-to-git: use git-credential's URL parser
We can just feed our URL straight to git-credential and it
will parse it for us, saving us some code.
Signed-off-by: Jeff King p...@peff.net
---
contrib/mw-to-git/git-remote-mediawiki | 32
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki
b/contrib/mw-to-git/git-remote-mediawiki
index b06f27b..c9ac416 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -163,32 +163,6 @@ while (STDIN) {
## credential API management (generic functions)
-sub credential_from_url {
- my $url = shift;
- my $parsed = URI-new($url);
- my %credential;
-
- if ($parsed-scheme) {
- $credential{protocol} = $parsed-scheme;
- }
- if ($parsed-host) {
- $credential{host} = $parsed-host;
- }
- if ($parsed-path) {
- $credential{path} = $parsed-path;
- }
- if ($parsed-userinfo) {
- if ($parsed-userinfo =~ /([^:]*):(.*)/) {
- $credential{username} = $1;
- $credential{password} = $2;
- } else {
- $credential{username} = $parsed-userinfo;
- }
- }
-
- return %credential;
-}
-
sub credential_read {
my %credential;
my $reader = shift;
@@ -216,7 +190,9 @@ sub credential_write {
sub credential_run {
my $op = shift;
my $credential = shift;
+ my $url = shift;
my $pid = open2(my $reader, my $writer, git credential $op);
+ print $writer url=$url\n if defined $url;
credential_write($credential, $writer);
print $writer \n;
close($writer);
@@ -246,10 +222,10 @@ sub mw_connect_maybe {
$mediawiki = MediaWiki::API-new;
$mediawiki-{config}-{api_url} = $url/api.php;
if ($wiki_login) {
- my %credential = credential_from_url($url);
+ my %credential;
$credential{username} = $wiki_login;
$credential{password} = $wiki_passwd;
- credential_run(fill, \%credential);
+ credential_run(fill, \%credential, $url);
my $request = {lgname = $credential{username},
lgpassword = $credential{password},
lgdomain = $wiki_domain};
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 4/4] git-rebase: add keep_empty flag
On Wed, Jul 18, 2012 at 09:10:06AM +0200, Johannes Sixt wrote:
Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman nhor...@tuxdriver.com wrote:
pick_one () {
ff=--ff
+
case $1 in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
case $force_rebase in '') ;; ?*) ff= ;; esac
output git rev-parse --verify $sha1 || die Invalid commit name:
$sha1
+
+ if is_empty_commit $sha1
+ then
+ empty_args=--allow-empty
+ fi
+
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $ff $@
+ output git cherry-pick $empty_args $ff $@
The is_empty_commit check seems to mean that if $sha1 is an empty
commit, we pass the --allow-empty option to cherry-pick. If it's not
empty, we don't. The word allow in allow-empty suggests that even
if the commit is not empty, cherry-pick would not mind. So, can we
always pass allow-empty to cherry-pick (i.e. even if the commit to
pick is not empty)?
I don't think so. If the commit is not empty, but all its changes are
already in HEAD, then it will become empty when cherry-picked to HEAD.
In such a case, we usually do not want to record an empty commit, but stop
rebase to give to user a chance to deal with the situation.
-- Hannes
Yes, this is the meaning. Allow was used in the sense of a filter, in that we
are allowing an empty commit to make it into the history, whereas a rebase or
cherry-pick would normally exclude it.
Neil
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] credential: convert url attribute into its parsed subparts
Jeff King p...@peff.net writes: $ echo https://u...@example.com | git credential ident protocol=https host=example.com username=user since I had no use for it, but it would obviously be an easy one-liner to write (it's just fill without the actual fill call). I was thinking the same, except I would have spelled it git credential parse (but ident is fine too). On the perl side, that would allow getting a credential hash very simply (but it was already simple in perl, and made useless by your code). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mw-to-git: use git-credential's URL parser
Jeff King p...@peff.net writes:
@@ -216,7 +190,9 @@ sub credential_write {
sub credential_run {
my $op = shift;
my $credential = shift;
+ my $url = shift;
my $pid = open2(my $reader, my $writer, git credential $op);
+ print $writer url=$url\n if defined $url;
credential_write($credential, $writer);
print $writer \n;
close($writer);
@@ -246,10 +222,10 @@ sub mw_connect_maybe {
$mediawiki = MediaWiki::API-new;
$mediawiki-{config}-{api_url} = $url/api.php;
if ($wiki_login) {
- my %credential = credential_from_url($url);
+ my %credential;
$credential{username} = $wiki_login;
$credential{password} = $wiki_passwd;
- credential_run(fill, \%credential);
+ credential_run(fill, \%credential, $url);
my $request = {lgname = $credential{username},
lgpassword = $credential{password},
lgdomain = $wiki_domain};
I would find it more elegant not to special-case the URL field, and just
my %credential = ('url' = $url);
but I'm fine with your version too.
Other than that, and for the 4 patches of the serie:
Reviewed-by: Matthieu Moy matthieu@imag.fr
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] credential: convert url attribute into its parsed subparts
On Wed, Jul 18, 2012 at 02:24:01PM +0200, Matthieu Moy wrote: Jeff King p...@peff.net writes: $ echo https://u...@example.com | git credential ident protocol=https host=example.com username=user since I had no use for it, but it would obviously be an easy one-liner to write (it's just fill without the actual fill call). I was thinking the same, except I would have spelled it git credential parse (but ident is fine too). On the perl side, that would allow getting a credential hash very simply (but it was already simple in perl, and made useless by your code). I wanted to give it some name that meant pass-through rather than just parse, in case we add more magic attributes later. I meant ident to be like mathematical identity, but in the context of a credential tool, it is probably somewhat ambiguous. :) Anyway, the fact that we can just do the parsing as part of the fill means we don't need it for now, so I'll leave it until somebody really cares. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mw-to-git: use git-credential's URL parser
On Wed, Jul 18, 2012 at 02:24:13PM +0200, Matthieu Moy wrote:
Jeff King p...@peff.net writes:
@@ -216,7 +190,9 @@ sub credential_write {
sub credential_run {
my $op = shift;
my $credential = shift;
+ my $url = shift;
my $pid = open2(my $reader, my $writer, git credential $op);
+ print $writer url=$url\n if defined $url;
credential_write($credential, $writer);
print $writer \n;
close($writer);
@@ -246,10 +222,10 @@ sub mw_connect_maybe {
$mediawiki = MediaWiki::API-new;
$mediawiki-{config}-{api_url} = $url/api.php;
if ($wiki_login) {
- my %credential = credential_from_url($url);
+ my %credential;
$credential{username} = $wiki_login;
$credential{password} = $wiki_passwd;
- credential_run(fill, \%credential);
+ credential_run(fill, \%credential, $url);
my $request = {lgname = $credential{username},
lgpassword = $credential{password},
lgdomain = $wiki_domain};
I would find it more elegant not to special-case the URL field, and just
my %credential = ('url' = $url);
but I'm fine with your version too.
I started with a version that did that, but there are two complications:
1. credential_write needs to know that the 'url' field must come
first, as it overwrites the other fields. So we end up
special-casing it either way.
2. Git hands us back the broken-down version, which we add to the
credential. So it is superfluous to keep sending 'url' for the
other, non-fill interactions. I don't think it's technically wrong,
but it also seemed inelegant. Having credential_write delete the
'url' field seemed even more inelegant.
Other than that, and for the 4 patches of the serie:
Reviewed-by: Matthieu Moy matthieu@imag.fr
Thanks.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mw-to-git: use git-credential's URL parser
Jeff King p...@peff.net writes: I started with a version that did that, but there are two complications: 1. credential_write needs to know that the 'url' field must come first, as it overwrites the other fields. So we end up special-casing it either way. Right, I didn't think of that. But you'd have to special-case it only within credential_run, and not for the caller. 2. Git hands us back the broken-down version, which we add to the credential. We don't add it, but already replace the whole structure. This is somehow needed because git credential fill can remove fields from the structure (the path attribute is removed with credential.useHttpPath=false). So, this point doesn't seem problematic. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] git-svn: don't create master if another head exists
On Wed, Jul 18, 2012 at 11:27:22AM +, Eric Wong wrote: Marcin Owsiany mar...@owsiany.pl wrote: On Wed, Jul 11, 2012 at 03:56:43PM -0700, Junio C Hamano wrote: If the caller does not handle errors, it could be even clearer to write it like command_noisy(qw(update-ref HEAD), $gs-refname) || die Cannot update HEAD!!!; Turns out that command_noisy() - has a meaningless return value - throws an exception on command failure so the || bit does not work. Also, for some reason command_noisy does not check for the command being killed by a signal, so I'd prefer to leave the verify_ref there. Ugh, I always forget the Git.pm API, too. Perhaps command_noisy should be made to respect signals in exit codes (the rest of git-svn is compromised by this behavior in command_noisy, too, it turns out... :x) I'm not sure what else would break if command_noisy were changed, git-svn appears to be the only user in git.git. Other command flavours should probably also be changed to match? -- Marcin Owsiany mar...@owsiany.pl http://marcin.owsiany.pl/ GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC Every program in development at MIT expands until it can read mail. -- Unknown -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] git-rebase--interactive.sh: extract function for adding pick line
On Wed, Jul 18, 2012 at 12:27:30AM -0700, Martin von Zweigbergk wrote:
Extract the code that adds a possibly commented-out pick line to the
todo file. This lets us reuse it more easily later.
---
git-rebase--interactive.sh | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bef7bc0..fa722b6 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -828,23 +828,26 @@ else
revisions=$onto...$orig_head
shortrevisions=$shorthead
fi
-git rev-list $merges_option --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --topo-order \
- $revisions | \
- sed -n s/^//p |
-while read -r shortsha1 rest
-do
- if test -z $keep_empty is_empty_commit $shortsha1
+add_pick_line () {
+ if test -z $keep_empty is_empty_commit $1
then
comment_out=#
else
comment_out=
fi
+ printf '%s\n' ${comment_out}pick $1 $2 $todo
+}
+git rev-list $merges_option --pretty=oneline --abbrev-commit \
+ --abbrev=7 --reverse --left-right --topo-order \
+ $revisions | \
+ sed -n s/^//p |
+while read -r shortsha1 rest
+do
if test t != $preserve_merges
then
- printf '%s\n' ${comment_out}pick $shortsha1 $rest $todo
+ add_pick_line $shortsha1 $rest
else
sha1=$(git rev-parse $shortsha1)
if test -z $rebase_root
@@ -863,7 +866,7 @@ do
if test f = $preserve
then
touch $rewritten/$sha1
- printf '%s\n' ${comment_out}pick $shortsha1 $rest
$todo
+ add_pick_line $shortsha1 $rest
fi
fi
done
--
1.7.11.1.104.ge7b44f1
Thanks!
Acked-by: Neil Horman nhor...@tuxdriver.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mw-to-git: use git-credential's URL parser
On Wed, Jul 18, 2012 at 02:37:27PM +0200, Matthieu Moy wrote:
Jeff King p...@peff.net writes:
I started with a version that did that, but there are two complications:
1. credential_write needs to know that the 'url' field must come
first, as it overwrites the other fields. So we end up
special-casing it either way.
Right, I didn't think of that. But you'd have to special-case it only
within credential_run, and not for the caller.
Yeah. It would look like this:
diff --git a/contrib/mw-to-git/git-remote-mediawiki
b/contrib/mw-to-git/git-remote-mediawiki
index c9ac416..e1392b0 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -190,9 +190,11 @@ sub credential_write {
sub credential_run {
my $op = shift;
my $credential = shift;
- my $url = shift;
my $pid = open2(my $reader, my $writer, git credential $op);
- print $writer url=$url\n if defined $url;
+ if (exists $credential-{url}) {
+ print $writer url=$credential-{url}\n;
+ delete $credential-{url};
+ }
credential_write($credential, $writer);
print $writer \n;
close($writer);
which is still kind of ugly. We could also push it down into
credential_write, like:
diff --git a/contrib/mw-to-git/git-remote-mediawiki
b/contrib/mw-to-git/git-remote-mediawiki
index c9ac416..0a821fd 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -180,8 +180,9 @@ sub credential_read {
sub credential_write {
my $credential = shift;
my $writer = shift;
+ print $writer url=$credential-{url}\n if exists $credential-{url};
while (my ($key, $value) = each(%$credential) ) {
- if (length $value) {
+ if (length $value $key ne 'url') {
print $writer $key=$value\n;
}
}
@@ -190,9 +191,7 @@ sub credential_write {
sub credential_run {
my $op = shift;
my $credential = shift;
- my $url = shift;
my $pid = open2(my $reader, my $writer, git credential $op);
- print $writer url=$url\n if defined $url;
credential_write($credential, $writer);
print $writer \n;
close($writer);
which is probably the least gross. I was originally hesitant because the
issue (2) I brought up, but...
2. Git hands us back the broken-down version, which we add to the
credential.
We don't add it, but already replace the whole structure. This is
somehow needed because git credential fill can remove fields from the
structure (the path attribute is removed with
credential.useHttpPath=false). So, this point doesn't seem problematic.
Hmph. I considered that we might do it and even checked, but I somehow
read the code wrong (I think I was thrown off by the pass-by-reference
to credential_run, but of course it overwrites it inside that function).
So since that is a non-issue, I think the second diff I provided above
is a bit nicer.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/4] mw-to-git: use git-credential's URL parser
On Wed, Jul 18, 2012 at 08:57:41AM -0400, Jeff King wrote:
So since that is a non-issue, I think the second diff I provided above
is a bit nicer.
And here is a replacement patch 4/4.
-- 8 --
Subject: mw-to-git: use git-credential's URL parser
We can just feed our URL straight to git-credential and it
will parse it for us, saving us some code.
Signed-off-by: Jeff King p...@peff.net
---
contrib/mw-to-git/git-remote-mediawiki | 32
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki
b/contrib/mw-to-git/git-remote-mediawiki
index b06f27b..38afa76 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -163,32 +163,6 @@ while (STDIN) {
## credential API management (generic functions)
-sub credential_from_url {
- my $url = shift;
- my $parsed = URI-new($url);
- my %credential;
-
- if ($parsed-scheme) {
- $credential{protocol} = $parsed-scheme;
- }
- if ($parsed-host) {
- $credential{host} = $parsed-host;
- }
- if ($parsed-path) {
- $credential{path} = $parsed-path;
- }
- if ($parsed-userinfo) {
- if ($parsed-userinfo =~ /([^:]*):(.*)/) {
- $credential{username} = $1;
- $credential{password} = $2;
- } else {
- $credential{username} = $parsed-userinfo;
- }
- }
-
- return %credential;
-}
-
sub credential_read {
my %credential;
my $reader = shift;
@@ -206,8 +180,10 @@ sub credential_read {
sub credential_write {
my $credential = shift;
my $writer = shift;
+ # url overwrites other fields, so it must come first
+ print $writer url=$credential-{url}\n if exists $credential-{url};
while (my ($key, $value) = each(%$credential) ) {
- if (length $value) {
+ if (length $value $key ne 'url') {
print $writer $key=$value\n;
}
}
@@ -246,7 +222,7 @@ sub mw_connect_maybe {
$mediawiki = MediaWiki::API-new;
$mediawiki-{config}-{api_url} = $url/api.php;
if ($wiki_login) {
- my %credential = credential_from_url($url);
+ my %credential = (url = $url);
$credential{username} = $wiki_login;
$credential{password} = $wiki_passwd;
credential_run(fill, \%credential);
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mw-to-git: use git-credential's URL parser
Jeff King p...@peff.net writes: So since that is a non-issue, I think the second diff I provided above is a bit nicer. I like this one best too. It just lacks a comment saying why it should be displayed first ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 4/4] mw-to-git: use git-credential's URL parser
Jeff King p...@peff.net writes: On Wed, Jul 18, 2012 at 08:57:41AM -0400, Jeff King wrote: So since that is a non-issue, I think the second diff I provided above is a bit nicer. And here is a replacement patch 4/4. -- 8 -- Subject: mw-to-git: use git-credential's URL parser Perfect, thanks. (and you've been faster than me about the comment ;-) ) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git_getpass regression?
On Wed, Jul 18, 2012 at 7:53 AM, Junio C Hamano gits...@pobox.com wrote: Ping on seemingly stalled discussion. Just to recap quickly from my point of view: 1. There's no regression. 2. There's room for improvement of the prompting on Windows. 3. I'm not entirely confident that I've found a safe way of improving the Windows prompt yet. 4. I've been busy with other stuff, but I'll get back to hacking soon :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: clone URL missing in gitweb
Quoting baluchen murugan.b...@gmail.com:
I verified the entries and they seems to be correct. But the clone and its
URL is still now showing when browsing project summary page via gitweb
well, unless you at least post the most relevant options of your
gitweb config, i'm afraid i cannot help you. maybe a snippet of mine
gives you a hint:
##
## gitweb.config.pl -- gitweb Perl configuration
##
our $projectroot = /var/lib/git/repositories;
our $projects_list = /var/lib/git/projects.list;
our $site_name = Git Home;
our @git_base_url_list = grep { $_ ne '' } (https://git.company.org/git;);
[...]
with this config, gitweb displays the clone url of a repository
dummy.git located in /var/lib/git/repositories as
https://git.company.org/git/dummy.git
bye,
tom.
--
Thomas Duke Hager d...@sigsegv.at
GPG: 2048R/791C5EB1http://www.sigsegv.at/gpg/duke.gpg
=
Never Underestimate the Power of Stupid People in Large Groups.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] branch: make --set-upstream saner without an explicit starting point
On Tue, 2012-07-17 at 22:56 -0700, Junio C Hamano wrote: Ping on a seemingly stalled discussion (no need to rush but just checking). I've implemented the feedback, but been slacking on writing the tests which is what's stopped me from re-sending the series. cmn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] git-svn: don't create master if another head exists
Marcin Owsiany mar...@owsiany.pl writes:
PTAL:
From: Marcin Owsiany mar...@owsiany.pl
Date: Sun, 24 Jun 2012 22:40:05 +0100
Subject: [PATCH] git-svn: don't create master if another head exists
git-svn insists on creating the master head (unless it exists) on every
fetch. It is useful that it gets created initially, when no head exists
- users expect this git convention of having a master branch on initial
clone.
However creating it when there already is another head does not provide any
value - the ref is never updated, so it just gets stale after a while. Also,
some users find it annoying that it gets recreated, especially when they would
like the git branch names to follow SVN repository branch names. More
background in http://thread.gmane.org/gmane.comp.version-control.git/115030
Make git-svn skip the master creation if HEAD already points at a valid
head.
This means master does get created on initial clone but does not get
recreated once a user deletes it.
Also, make post_fetch_checkout work with any head that is pointed to by HEAD,
not just master.
Also, use fatal error handling consistent with the rest of the program for
post_fetch_checkout.
Signed-off-by: Marcin Owsiany mar...@owsiany.pl
---
git-svn.perl |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0b074c4..6673d21 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -367,9 +367,9 @@ Git::SVN::init_vars();
eval {
Git::SVN::verify_remotes_sanity();
$cmd{$cmd}-[0]-(@ARGV);
+ post_fetch_checkout();
};
fatal $@ if $@;
-post_fetch_checkout();
exit 0;
### primary functions ##
@@ -1598,8 +1598,8 @@ sub rebase_cmd {
sub post_fetch_checkout {
return if $_no_checkout;
+ return if verify_ref('HEAD^0');
my $gs = $Git::SVN::_head or return;
- return if verify_ref('refs/heads/master^0');
# look for trunk ref if it exists
my $remote = Git::SVN::read_all_remotes()-{$gs-{repo_id}};
@@ -1612,9 +1612,8 @@ sub post_fetch_checkout {
}
}
- my $valid_head = verify_ref('HEAD^0');
- command_noisy(qw(update-ref refs/heads/master), $gs-refname);
- return if ($valid_head || !verify_ref('HEAD^0'));
+ command_noisy(qw(update-ref HEAD), $gs-refname);
+ return unless verify_ref('HEAD^0');
return if $ENV{GIT_DIR} !~ m#^(?:.*/)?\.git$#;
my $index = $ENV{GIT_INDEX_FILE} || $ENV{GIT_DIR}/index;
I am happy with this version, as long as Eric is happy ;-)
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] build system: support automatic reconfiguration for autotools user
This series aims at improving the user experience for those people who (like me) use that Autotools-based interface to the build system of Git. The two actual improvements (equipped with proper explanations and rationales) are implemented in the last two patches. The other five patches are just preparatory changes. The series as general or as clean as it could actually be, but it's enough to scratch the itch that motivated me to write it. Thanks, Stefano Stefano Lattarini (7): autoconf: GIT_CONF_APPEND_LINE: change signature autoconf: GIT_CONF_APPEND_LINE - GIT_CONF_SUBST autoconf: remove some redundant shell indirections autoconf: remove few redundant semicolons autoconf: use AC_CONFIG_COMMANDS instead of ad-hoc 'config.mak.append' build: make clean should not remove configure-generated files build: reconfigure automatically if configure.ac changes Makefile | 17 +++-- configure.ac | 53 ++--- 2 files changed, 45 insertions(+), 25 deletions(-) -- 1.7.10.2.1067.g553d16e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] autoconf: GIT_CONF_APPEND_LINE: change signature
From:
GIT_CONF_APPEND_LINE([VAR=VAL])
to:
GIT_CONF_APPEND_LINE([VAR], [VAL])
This is only a preparatory change in view of future refactorings.
No semantic change is intended. In fact, the generated configure
file doesn't change at all.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4e9012f..14c7960 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7,7 +7,7 @@
# --
# Append LINE to file ${config_append}
AC_DEFUN([GIT_CONF_APPEND_LINE],
- [echo $1 ${config_append}])
+ [echo $1=$2 ${config_append}])
# GIT_ARG_SET_PATH(PROGRAM)
# -
@@ -34,8 +34,8 @@ AC_DEFUN([GIT_CONF_APPEND_PATH],
if test -n $2; then
GIT_UC_PROGRAM[]_PATH=$withval
AC_MSG_NOTICE([Disabling use of ${PROGRAM}])
- GIT_CONF_APPEND_LINE(NO_${PROGRAM}=YesPlease)
- GIT_CONF_APPEND_LINE(${PROGRAM}_PATH=)
+ GIT_CONF_APPEND_LINE([NO_${PROGRAM}], [YesPlease])
+ GIT_CONF_APPEND_LINE([${PROGRAM}_PATH], [])
else
AC_MSG_ERROR([You cannot use git without $1])
fi
@@ -45,7 +45,7 @@ AC_DEFUN([GIT_CONF_APPEND_PATH],
else
GIT_UC_PROGRAM[]_PATH=$withval
AC_MSG_NOTICE([Setting GIT_UC_PROGRAM[]_PATH to $withval])
- GIT_CONF_APPEND_LINE(${PROGRAM}_PATH=$withval)
+ GIT_CONF_APPEND_LINE([${PROGRAM}_PATH], [$withval])
fi
fi
m4_popdef([GIT_UC_PROGRAM])])
@@ -67,7 +67,7 @@ AC_DEFUN([GIT_PARSE_WITH],
NO_[]GIT_UC_PACKAGE=
GIT_UC_PACKAGE[]DIR=$withval
AC_MSG_NOTICE([Setting GIT_UC_PACKAGE[]DIR to $withval])
- GIT_CONF_APPEND_LINE(${PACKAGE}DIR=$withval)
+ GIT_CONF_APPEND_LINE([${PACKAGE}DIR], [$withval])
fi
m4_popdef([GIT_UC_PACKAGE])])
@@ -87,7 +87,7 @@ AC_DEFUN([GIT_PARSE_WITH_SET_MAKE_VAR],
[a value for $1 ($2). Maybe you do...?])
fi
AC_MSG_NOTICE([Setting $2 to $withval])
- GIT_CONF_APPEND_LINE($2=$withval)
+ GIT_CONF_APPEND_LINE([$2], [$withval])
fi)])# GIT_PARSE_WITH_SET_MAKE_VAR
#
@@ -150,7 +150,7 @@ AC_ARG_WITH([sane-tool-path],
else
AC_MSG_NOTICE([Setting SANE_TOOL_PATH to '$withval'])
fi
- GIT_CONF_APPEND_LINE([SANE_TOOL_PATH=$withval])],
+ GIT_CONF_APPEND_LINE([SANE_TOOL_PATH], [$withval])],
[# If the --with-sane-tool-path option was not given, don't touch
# SANE_TOOL_PATH here, but let defaults in Makefile take care of it.
# This should minimize spurious differences in the behaviour of the
@@ -169,7 +169,7 @@ AC_ARG_WITH([lib],
else
lib=$withval
AC_MSG_NOTICE([Setting lib to '$lib'])
- GIT_CONF_APPEND_LINE(lib=$withval)
+ GIT_CONF_APPEND_LINE([lib], [$withval])
fi])
if test -z $lib; then
@@ -205,7 +205,7 @@ AC_ARG_ENABLE([jsmin],
[
JSMIN=$enableval;
AC_MSG_NOTICE([Setting JSMIN to '$JSMIN' to enable JavaScript minifying])
- GIT_CONF_APPEND_LINE(JSMIN=$enableval);
+ GIT_CONF_APPEND_LINE([JSMIN], [$enableval]);
])
# Define option to enable CSS minification
@@ -215,7 +215,7 @@ AC_ARG_ENABLE([cssmin],
[
CSSMIN=$enableval;
AC_MSG_NOTICE([Setting CSSMIN to '$CSSMIN' to enable CSS minifying])
- GIT_CONF_APPEND_LINE(CSSMIN=$enableval);
+ GIT_CONF_APPEND_LINE([CSSMIN], [$enableval]);
])
## Site configuration (override autodetection)
@@ -256,7 +256,7 @@ AS_HELP_STRING([], [ARG can be also prefix for
libpcre library and hea
USE_LIBPCRE=YesPlease
LIBPCREDIR=$withval
AC_MSG_NOTICE([Setting LIBPCREDIR to $withval])
- GIT_CONF_APPEND_LINE(LIBPCREDIR=$withval)
+ GIT_CONF_APPEND_LINE([LIBPCREDIR], [$withval])
fi)
#
# Define NO_CURL if you do not have curl installed. git-http-pull and
--
1.7.10.2.1067.g553d16e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] autoconf: remove few redundant semicolons
They are merely useless now, but would get in the way of future changes. No semantic change is intended. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 9472f6b..5fb9734 100644 --- a/configure.ac +++ b/configure.ac @@ -203,7 +203,7 @@ AC_ARG_ENABLE([jsmin], [ JSMIN=$enableval; AC_MSG_NOTICE([Setting JSMIN to '$JSMIN' to enable JavaScript minifying]) - GIT_CONF_SUBST([JSMIN], [$enableval]); + GIT_CONF_SUBST([JSMIN], [$enableval]) ]) # Define option to enable CSS minification @@ -213,7 +213,7 @@ AC_ARG_ENABLE([cssmin], [ CSSMIN=$enableval; AC_MSG_NOTICE([Setting CSSMIN to '$CSSMIN' to enable CSS minifying]) - GIT_CONF_SUBST([CSSMIN], [$enableval]); + GIT_CONF_SUBST([CSSMIN], [$enableval]) ]) ## Site configuration (override autodetection) -- 1.7.10.2.1067.g553d16e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] build: reconfigure automatically if configure.ac changes
This provides a reduced but still useful sibling of the Automake's automatic Makefile rebuild feature. It's important to note that we take care to enable the new rules only if the tree that has already be configured with './configure', so that users relying on manual configuration won't be negatively impacted. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- Makefile | 12 configure.ac | 2 ++ 2 files changed, 14 insertions(+) diff --git a/Makefile b/Makefile index 88a76a3..f4e8fac 100644 --- a/Makefile +++ b/Makefile @@ -2158,6 +2158,18 @@ configure: configure.ac GIT-VERSION-FILE autoconf -o $@ $+ \ $(RM) $+ +ifdef AUTOCONFIGURED +config.status: configure + $(QUIET_GEN)if test -f config.status; then \ + ./config.status --recheck; \ + else \ + ./configure; \ + fi +reconfigure config.mak.autogen: config.status + $(QUIET_GEN)./config.status +.PHONY: reconfigure # This is a convenience target. +endif + XDIFF_OBJS += xdiff/xdiffi.o XDIFF_OBJS += xdiff/xprepare.o XDIFF_OBJS += xdiff/xutils.o diff --git a/configure.ac b/configure.ac index 64eecbc..8949935 100644 --- a/configure.ac +++ b/configure.ac @@ -149,6 +149,8 @@ AC_CONFIG_SRCDIR([git.c]) config_file=config.mak.autogen config_in=config.mak.in +GIT_CONF_SUBST([AUTOCONFIGURED], [YesPlease]) + # Directories holding saner versions of common or POSIX binaries. AC_ARG_WITH([sane-tool-path], [AS_HELP_STRING( -- 1.7.10.2.1067.g553d16e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] build: make clean should not remove configure-generated files
Those filed hold variables, settings and information set by the configuration process run by './configure'; in Autotools-based build system that kind of stuff should only be removed by make distclean. Having it removed by make clean is not only inconsistent, but causes real confusion for that part of the Git audience that is used to the Autotools semantics; for example, an autotools old-timer that has run: ./configure --prefix /opt/git in the past, without running make distclean afterwards, would expect a make install issued after a make clean to rebuild and install git in '/opt/git'; but with the current behaviour, the make clean invocation removes (among the other things) the file 'config.mak.autogen', so that the make install falls back to the default prefix of '$HOME', thus installing git in the user's home directory -- definitely unexpected. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 285c660..88a76a3 100644 --- a/Makefile +++ b/Makefile @@ -2742,6 +2742,9 @@ dist-doc: distclean: clean $(RM) configure + $(RM) config.log config.status config.cache + $(RM) config.mak.autogen config.mak.append + $(RM) -r autom4te.cache profile-clean: $(RM) $(addsuffix *.gcda,$(addprefix $(PROFILE_DIR)/, $(object_dirs))) @@ -2756,8 +2759,6 @@ clean: profile-clean $(RM) -r $(dep_dirs) $(RM) -r po/build/ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h $(ETAGS_TARGET) tags cscope* - $(RM) -r autom4te.cache - $(RM) config.log config.mak.autogen config.mak.append config.status config.cache $(RM) -r $(GIT_TARNAME) .doc-tmp-dir $(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz $(RM) $(htmldocs).tar.gz $(manpages).tar.gz -- 1.7.10.2.1067.g553d16e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Fix notes handling in rev-list
Jeff King p...@peff.net writes: So leaving aside the --graph issues, we would need to decide what to show in the non-graph case. And I think your suggestion is good; there is no real need to dereference the blob (if you want that, you can turn on the pretty-printer). I'm just not sure what the output should be. I guess: commit_sha1 notes sha1s is probably the most sensible (it's sort of like --parents). And that solves the --graph issue, too, since it continues to take only a single line. Surely. rev-list --parents --notes would still be usable that way, as a reader that requests such a combination is prepared to tell commits (i.e. parents) and blobs (i.e. notes) apart. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: respect --no-ext-diff with typechange
Jeff King p...@peff.net writes: I don't care too deeply either way, and it is technically a behavior change. So there is a chance of regression for something that nobody has actually complained about. Thanks. I share the same feeling, but the code after the patch looks much nicer, which is somewhat sad. To be honest, I doubt many people are using external diff at all these days; textconv is closer to what most people want, and is much easier to use. It depends on the payload and the output you want. I wouldn't think it is fair to challenge anybody to come up with a solution based on the textconv machinery to replicate what the compare-cooking.perl in the 'todo' branch (used as an external diff driver for whats-cooking.txt) does. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Extract Git classes from git-svn (2/10) (was Re: Fix git-svn tests for SVN 1.7.5.)
On 2012.7.18 3:58 AM, Eric Wong wrote: I agree with everything Jonathan said (and thank him for taking the time to point you in the right direction). Thanks, you guys have been very nice to my flailing and failing. I'm going to back off and send out a sort of overview email so we can figure out how best to chunk this up. +++ b/t/Git-SVN/00compile.t +use Test::More tests = 2; I prefer not declaring test counts and using done_testing() instead. done_testing() is favorable to me in at least 2 ways: * done_testing() closely matches the behavior of the existing sh-based test suite in git (which calls test_done) * maintaining test counts leads to unnecessary merge conflicts Yes, I concur 100%. So much that I went back in my time machine and added done_testing() to Test::More! Also I killed Hitler, so now WWII ends in 1945. Things seem to have turned out for the better. I love it when people advocate my features back to me. :) I didn't use done_testing because I didn't know your stance on using non-5.8 core versions of modules. Skipping the tests on old versions of Test::More ( 0.88) is acceptable to me (especially since integration tests provide the real coverage already). It is very easy to bundle an uninstalled copy of Test::More, probably easier than putting in the code necessary to check for it and skip it. A lot of Perl modules do it. The usual thing is to put it into t/lib/ and add use lib 't/lib' to the tests. I don't see any reason why that basic technique wouldn't work here, with some minor changes to match the Git test suite. I can help you with that, but I'd like to get through this SVN 1.7 fix first. -- Being faith-based doesn't trump reality. -- Bruce Sterling -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] autoconf: GIT_CONF_APPEND_LINE - GIT_CONF_SUBST
Stefano Lattarini stefano.lattar...@gmail.com writes:
The new name fits better with the macro signature, and underlines the
similarities with the autoconf-provided macro AC_SUBST (which will be
made even more pronounced in planned future commits).
Once again, no semantic change is intended, and indeed no change to the
generated configure script is expected.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/configure.ac b/configure.ac
index 14c7960..789926f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,10 +3,10 @@
## Definitions of private macros.
-# GIT_CONF_APPEND_LINE(LINE)
+# GIT_CONF_SUBST(LINE)
I see that [PATCH 1/7] needs to be updated so that it describes the
new two-argument form of GIT_CONF_APPEND_LINE(VAR, VAL), and this
patch needs to be updated for GIT_CONF_SUBST() with the same.
# --
# Append LINE to file ${config_append}
Also the description definitely wants to be updated; it is no longer
LINEness that matters.
Other than that, 1 2 looked very nice and sensible.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] autoconf: remove some redundant shell indirections
Stefano Lattarini stefano.lattar...@gmail.com writes: diff --git a/configure.ac b/configure.ac index 789926f..9472f6b 100644 --- a/configure.ac +++ b/configure.ac @@ -29,13 +29,12 @@ AC_DEFUN([GIT_ARG_SET_PATH], # --without-PROGRAM is used. AC_DEFUN([GIT_CONF_APPEND_PATH], [m4_pushdef([GIT_UC_PROGRAM], m4_toupper([$1]))dnl if test $withval = no; then if test -n $2; then GIT_UC_PROGRAM[]_PATH=$withval + AC_MSG_NOTICE([Disabling use of GIT_UC_PROGRAM]) + GIT_CONF_SUBST([NO_]GIT_UC_PROGRAM, [YesPlease]) + GIT_CONF_SUBST(GIT_UC_PROGRAM[_PATH], []) Nice. The inconsistency between the existing one that does not quote the string that is not substituted, i.e. GIT_UC_PROGRAM[]_PATH=$withval and the new one that quotes _PATH, i.e. GIT_CONF_SUBST(GIT_UC_PROGRAM[_PATH], []) looks somewhat strange, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] build system: support automatic reconfiguration for autotools user
Except for miniscule nits in the the bottom two, I didn't find anything objectionable---nicely done. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Extract Git classes from git-svn (1/10)
On Wed, Jul 18, 2012 at 2:49 AM, Junio C Hamano gits...@pobox.com wrote: There may be a hosting site with better code review features, but all the code review of Git happens on this mailing list, and that is not likely to change in the near future. For me, you know, it's codereview, aka rietveld. [1] [1] code.google.com/p/rietveld/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
