Re: [PATCH] git-svn: workaround for a bug in svn serf backend
Roman Kagan rka...@mail.ru writes:
+ # workaround for a bug in svn serf backend (v1.8.5 and below):
+ # store 3d argument to -add_file() in a local variable, to make it
+ # have the same lifetime as $fbat
+ my $upa = $self-url_path($m-{file_a});
my $fbat = $self-add_file($self-repo_path($m-{file_b}), $pbat,
- $self-url_path($m-{file_a}), $self-{r});
+ $upa, $self-{r});
Hmm, now that you put it that way, I wonder if the patch is correct.
Let me first rephrase the problem to verify that I understand the issue:
$fbat keeps a pointer to the $upa string, without maintaining a
reference to it. When $fbat is destroyed, it needs this string, so we
must ensure that the lifetime of $upa is at least as long as that of
$fbat.
However, does Perl make any guarantees as to the order in which local
variables are unreferenced and then destroyed? I can't find any such
guarantee.
In the absence of such, wouldn't we have to keep $upa in an outer,
separate scope to ensure that $fbat is destroyed first?
--
Thomas Rast
t...@thomasrast.ch
--
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/4] completion: prioritize ./git-completion.bash
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index fac5e71..6fca145 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z $script ]; then
local -a locations
local e
locations=(
+ $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
'/etc/bash_completion.d/git' # fedora, old debian
'/usr/share/bash-completion/completions/git' # arch, ubuntu,
new debian
'/usr/share/bash-completion/git' # gentoo
- $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
)
for e in $locations; do
test -f $e script=$e break
--
1.8.5.2.227.g53f3478
--
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/4] Fix branch.autosetup(merge|rebase) completion
Hi, I figured that branch.autosetupmerge, branch.autosetuprebase and remote.pushdefault are very tedious to type out in full, and started looking into fixing their completions this evening. The solution turns out to be much more complex than I initally imagined, but I'm quite happy with the solution. I hope it's an enjoyable read. Ramkumar Ramachandra (4): completion: prioritize ./git-completion.bash completion: introduce __gitcomp_2 () completion: fix branch.autosetup(merge|rebase) completion: fix remote.pushdefault contrib/completion/git-completion.bash | 43 -- contrib/completion/git-completion.zsh | 12 +- 2 files changed, 52 insertions(+), 3 deletions(-) -- 1.8.5.2.227.g53f3478 -- 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] completion: introduce __gitcomp_2 ()
There are situations where two classes of completions possible. For
example
branch.TAB
should try to complete
branch.master.
branch.autosetupmerge
branch.autosetuprebase
The first candidate has the suffix ., and the second/ third candidates
have the suffix . To facilitate completions of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10 ++
2 files changed, 40 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..64b20b8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,36 @@ __gitcomp_nl ()
__gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
+# Generates completion reply from two sets of completion words, with
+# configurable suffixes for each.
+#
+# It accepts 2 to 6 arguments:
+# 1: First set of possible completion words.
+# 2: Second set of possible completion words.
+# 3: A prefix to be added to each completion word (both $1 and $2)
+#(optional).
+# 4: Generate possible completion matches for this word (optional).
+# 5: A suffix to be appended to each completion word in the first set
+#($1) instead of the default space (optional).
+# 6: A suffix to be appended to each completion word in the second set
+#($2) instead of the default space (optional).
+__gitcomp_2 ()
+{
+ local pfx=${3-} cur_=${4-$cur} sfx=${5- } sfx2=${6- } i=0
+ local IFS=$' \t\n'
+
+ for x in $1; do
+ if [[ $x == $cur_* ]]; then
+ COMPREPLY[i++]=$pfx$x$sfx
+ fi
+ done
+ for x in $2; do
+ if [[ $x == $cur_* ]]; then
+ COMPREPLY[i++]=$pfx$x$sfx2
+ fi
+ done
+}
+
# Generates completion reply with compgen from newline-separated possible
# completion filenames.
# It accepts 1 to 3 arguments:
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 6fca145..261a7f5 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -76,6 +76,16 @@ __gitcomp_nl ()
compadd -Q -S ${4- } -p ${2-} -- ${=1} _ret=0
}
+__gitcomp_2 ()
+{
+ emulate -L zsh
+
+ local IFS=$' \t\n'
+ compset -P '*[=:]'
+ compadd -Q -S ${5- } -p ${3-} -- ${=1} _ret=0
+ compadd -Q -S ${6- } -p ${3-} -- ${=2} _ret=0
+}
+
__gitcomp_file ()
{
emulate -L zsh
--
1.8.5.2.227.g53f3478
--
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] completion: fix branch.autosetup(merge|rebase)
When attempting to complete
$ git config branch.autoTAB
'autosetupmerge' and 'autosetuprebase' don't come up. This is because
$cur is matched with branch.* and a list of branches are
completed. Add 'autosetup(merge|rebase)' to the list of branches using
__gitcomp_2 ().
Also take care to not complete
$ git config branch.autosetupmerge.TAB
$ git config branch.autosetuprebase.TAB
with the usual branch.name. candidates.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 64b20b8..0bda757 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1851,12 +1851,18 @@ _git_config ()
;;
branch.*.*)
local pfx=${cur%.*}. cur_=${cur##*.}
+ if [ $pfx == branch.autosetupmerge. ] ||
+ [ $pfx == branch.autosetuprebase. ]; then
+ return
+ fi
__gitcomp remote pushremote merge mergeoptions rebase $pfx
$cur_
return
;;
branch.*)
local pfx=${cur%.*}. cur_=${cur#*.}
- __gitcomp_nl $(__git_heads) $pfx $cur_ .
+ __gitcomp_2 $(__git_heads)
+ autosetupmerge autosetuprebase
+$pfx $cur_ .
return
;;
guitool.*.*)
--
1.8.5.2.227.g53f3478
--
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] completion: fix remote.pushdefault
When attempting to complete
$ git config remote.pushTAB
'pushdefault' doesn't come up. This is because $cur is matched with
remote.* and a list of remotes are completed. Add 'pushdefault' to the
list of remotes using __gitcomp_2 ().
Also take care to not complete
$ git config remote.pushdefault.TAB
with the usual remote.name. candidates.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0bda757..9e0213d 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1896,6 +1896,9 @@ _git_config ()
;;
remote.*.*)
local pfx=${cur%.*}. cur_=${cur##*.}
+ if [ $pfx == remote.pushdefault. ]; then
+ return
+ fi
__gitcomp
url proxy fetch push mirror skipDefaultUpdate
receivepack uploadpack tagopt pushurl
@@ -1904,7 +1907,7 @@ _git_config ()
;;
remote.*)
local pfx=${cur%.*}. cur_=${cur#*.}
- __gitcomp_nl $(__git_remotes) $pfx $cur_ .
+ __gitcomp_2 $(__git_remotes) pushdefault $pfx $cur_ .
return
;;
url.*.*)
--
1.8.5.2.227.g53f3478
--
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] git-svn: workaround for a bug in svn serf backend
2013/12/30 Thomas Rast t...@thomasrast.ch:
Roman Kagan rka...@mail.ru writes:
+ # workaround for a bug in svn serf backend (v1.8.5 and below):
+ # store 3d argument to -add_file() in a local variable, to make it
+ # have the same lifetime as $fbat
+ my $upa = $self-url_path($m-{file_a});
my $fbat = $self-add_file($self-repo_path($m-{file_b}), $pbat,
- $self-url_path($m-{file_a}), $self-{r});
+ $upa, $self-{r});
Hmm, now that you put it that way, I wonder if the patch is correct.
Let me first rephrase the problem to verify that I understand the issue:
$fbat keeps a pointer to the $upa string, without maintaining a
reference to it. When $fbat is destroyed, it needs this string, so we
must ensure that the lifetime of $upa is at least as long as that of
$fbat.
No. The string is needed in subversion's close_file(), so we want to
keep it alive until close_file() returns. Surviving till the end of
the current function scope is sufficient for that.
However, does Perl make any guarantees as to the order in which local
variables are unreferenced and then destroyed?
We don't care about the order they are destroyed WRT each other.
Roman.
--
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] for-each-ref: remove unused variable
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/for-each-ref.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 6551e7b..51798b4 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -92,7 +92,7 @@ static struct {
*/
static const char **used_atom;
static cmp_type *used_atom_type;
-static int used_atom_cnt, sort_atom_limit, need_tagged, need_symref;
+static int used_atom_cnt, need_tagged, need_symref;
static int need_color_reset_at_eol;
/*
@@ -1105,7 +1105,6 @@ int cmd_for_each_ref(int argc, const char **argv, const
char *prefix)
if (!sort)
sort = default_sort();
- sort_atom_limit = used_atom_cnt;
/* for warn_ambiguous_refs */
git_config(git_default_config, NULL);
--
1.8.5.2.227.g53f3478
--
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
aborted 'git fetch' leaves workspace unusable
I forgot to do 'ssh-add', so a 'git fetch' running under Windows Emacs tried to prompt for the ssh passphrase, could not find an ssh passphrase prompt program, and aborted. That left the workspace unusable: - .git/FETCH_HEAD is empty that causes 'git rev-parse FETCH_HEAD' to fail with a confusing error message. - 'git fetch' just hangs after outputting: remote: Counting objects: 15, done. remote: Compressing objects: 100% (8/8), done. remote: Total 9 (delta 5), reused 0 (delta 0) even with -v --progress A fresh clone allowed me to continue working, but this will happen again, so I'd like a better fix. The fetch is from stephen_le...@git.savannah.gnu.org/emacs/elpa.git I'm running git 1.7.9 from Cygwin. I have access to Debian, where I can compile git and run it under the debugger, if that helps. I have not yet tried to reproduce this bug on Debian. -- -- Stephe -- 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 9/9] trailer: add tests for git interpret-trailers
Christian Couder chrisc...@tuxfamily.org writes: +# Do not remove trailing spaces below! +cat complex_message_trailers 'EOF' +Fixes: +Acked-by: +Reviewed-by: +Signed-off-by: +EOF Just a hint. I think it is far safer and robust over time to do something like this: sed -e 's/ Z$/ /' -\EOF Fixes: Z Acked-by: Z EOF instead of a comment, which can warn human developers but does not do anything to prevent their editors' auto-fix features from kicking in. -- 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/3] t0000 cleanups
Jonathan Nieder jrnie...@gmail.com writes: Jeff King wrote: When I want to debug a failing test, I often end up doing: cd t ./t4107-tab -v -i cd tratab The test names are long, so tab-completing on the trash directory is very helpful. Lately I've noticed that there are a bunch of crufty trash directories in my t/ directory, which makes my tab-completion more annoying. Ah, and if I'd read this then I wouldn't have had to be confused at all. Would it work to replace the commit message with something like this? The third paragraph of 1/3 sufficiently covers it, no? We could add It makes it less convenient to use tab completion 'cd t/traTAB' to go to the trash directory of the failed test to inspect the situation after ... left in the t/ directory., though. Once upon a time, the test-lib library would create trash directories in the current working directory, unless we were explicitly told to put it elsewhere via --root. As a result, t created the sub-test trash directories inside its own trash directory. However, we noticed that this did not cover all cases, since we would need to respect $TEST_OUTPUT_DIRECTORY even if --root is not given (or is relative). Commit 38b074d fixed this to consistently use the full path. As a result, trash directories used by t's sub-tests are now created in git's original test output directory rather than in our trash directory. Furthermore, since some of the sub-tests simulate failures, the trash directories do not get cleaned up, and the cruft is left in the t/ directory. We could fix this by passing a new --root=$TRASH_DIRECTORY option to the sub-test. However, we do not want the sub-tests to write anything at all to git's directory (e.g., they should not be writing to t/test-results, either, although this is already handled by separate code). So the best solution is to simply reset $TEST_OUTPUT_DIRECTORY entirely in the sub-test, which covers this case, as well as any future ones. -- 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/3] t0000 cleanups
Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Jeff King wrote: When I want to debug a failing test, I often end up doing: cd t ./t4107-tab -v -i cd tratab The test names are long, so tab-completing on the trash directory is very helpful. Lately I've noticed that there are a bunch of crufty trash directories in my t/ directory, which makes my tab-completion more annoying. Ah, and if I'd read this then I wouldn't have had to be confused at all. [...] The third paragraph of 1/3 sufficiently covers it, no? We could add It makes it less convenient to use tab completion 'cd t/traTAB' to go to the trash directory of the failed test to inspect the situation after ... left in the t/ directory., though. [4 paragraphs snipped] I think it can be better, since the commit message left me scratching my head while the patch itself seems pretty simple. How about something like the following? First, describing the problem: Running t produces more trash directories than expected and does not clean up after itself: $ ./t-basic.sh [...] $ ls -d trash\ directory.* trash directory.failing-cleanup trash directory.mixed-results1 trash directory.mixed-results2 trash directory.partial-pass trash directory.test-verbose trash directory.test-verbose-only-2 Analysis and fix: These scratch areas for sub-tests should be under the t trash directory, but because the TEST_OUTPUT_DIRECTORY setting from the toplevel test leaks into the environment they are created under the toplevel output directory (typically t/) instead. Because some of the sub-tests simulate failures, their trash directories are kept around. Fix it by explicitly setting TEST_OUTPUT_DIRECTORY appropriately for sub-tests. And then, optionally, describing rejected alternatives: An alternative fix would be to pass the --root parameter that only specifies where to put the trash directories, which would also work. However, using TEST_OUTPUT_DIRECTORY is more futureproof in case tests want to write more output in addition to the test-results/ (which are already suppressed in sub-tests using the HARNESS_ACTIVE setting) and trash directories. And more analysis of why this wasn't caught in the first place: This fixes a regression introduced by 38b074d (t/test-lib.sh: fix TRASH_DIRECTORY handling, 2013-04-14). Before then, the TEST_OUTPUT_DIRECTORY setting was not respected consistently so most tests did their work in a trash subdirectory of the current directory instead of the output dir. Does that make sense? Thanks, Jonathan -- 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 1/2] merge-base: fix duplicates and not best ancestors in output
Василий Макаров einmal...@gmail.com writes:
Hi there!
First of all: I'm new to mailing-lists, sorry if I'm doing it wrong.
I've found a bug in git merge-base, causing it to show not best common
ancestors and duplicates under some circumstances (example is given in
attached test case).
Attached???
Problem cause is algorithm used in get_octopus_merge_bases(), it
iteratively concatenates merge bases, and don't care if there are
duplicates or decsendants/ancestors in result.
What I suggest as a solution is to simply reduce bases list after
get_octopus_merge_bases().
I do not offhand remember if it was deliberate that we do not dedup
the result from the underlying get_octopus_merge_bases() (the most
likely reason for not deduping is because the caller is expected to
do that if it wants to).
Whether it is an improvement to force deduping here or it is an
regression to do so, I think we should split that helper function
handle_octopus(). It does two totally unrelated things (one is only
to list independent heads without showing merge bases, the other is
to show one or more merge bases across all the heads given).
Perhaps if we split the independent codepath introduced by
a1e0ad78 (merge-base --independent to print reduced parent list in a
merge, 2010-08-17) into its own helper function, like this, it would
make it clear what is going on.
Thanks.
builtin/merge-base.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/builtin/merge-base.c b/builtin/merge-base.c
index e88eb93..a00e8f5 100644
--- a/builtin/merge-base.c
+++ b/builtin/merge-base.c
@@ -44,19 +44,36 @@ static struct commit *get_commit_reference(const char *arg)
return r;
}
-static int handle_octopus(int count, const char **args, int reduce, int
show_all)
+static int handle_independent(int count, const char **args)
{
struct commit_list *revs = NULL;
struct commit_list *result;
int i;
- if (reduce)
- show_all = 1;
+ for (i = count - 1; i = 0; i--)
+ commit_list_insert(get_commit_reference(args[i]), revs);
+
+ result = reduce_heads(revs);
+ if (!result)
+ return 1;
+
+ while (result) {
+ printf(%s\n, sha1_to_hex(result-item-object.sha1));
+ result = result-next;
+ }
+ return 0;
+}
+
+static int handle_octopus(int count, const char **args, int show_all)
+{
+ struct commit_list *revs = NULL;
+ struct commit_list *result;
+ int i;
for (i = count - 1; i = 0; i--)
commit_list_insert(get_commit_reference(args[i]), revs);
- result = reduce ? reduce_heads(revs) : get_octopus_merge_bases(revs);
+ result = get_octopus_merge_bases(revs);
if (!result)
return 1;
@@ -114,8 +131,10 @@ int cmd_merge_base(int argc, const char **argv, const char
*prefix)
if (reduce (show_all || octopus))
die(--independent cannot be used with other options);
- if (octopus || reduce)
- return handle_octopus(argc, argv, reduce, show_all);
+ if (octopus)
+ return handle_octopus(argc, argv, show_all);
+ else if (reduce)
+ return handle_independent(argc, argv);
rev = xmalloc(argc * sizeof(*rev));
while (argc-- 0)
--
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: aborted 'git fetch' leaves workspace unusable
stephen_le...@stephe-leake.org writes: That left the workspace unusable: - .git/FETCH_HEAD is empty that causes 'git rev-parse FETCH_HEAD' to fail with a confusing error message. This is not limited to your Cygwin environment. I can see that we leave an empty file there after a failed fetch with $ git fetch ssh://no.such.place/ But I would not call it leaving the workspace unusable. If you ask git rev-parse What is in FETCH_HEAD?, you would get that is not even a revision, which is what you would get. Similar operations that try to use FETCH_HEAD as if there is a valid revision, e.g. git merge FETCH_HEAD, would also not work, which is very much expected. I wouldn't think that needs something drastic as this workspace is unusable, let's start from a new clone. If it really bothers you, you can always safely do $ rm -f .git/FETCH_HEAD but of course, after that, nothing that tries to use FETCH_HEAD as if there is a valid revision, e.g. git show FETCH_HEAD, would not work until you fetch from somewhere, so there isn't that much to be gained by doing so. - 'git fetch' just hangs after outputting: remote: Counting objects: 15, done. remote: Compressing objects: 100% (8/8), done. remote: Total 9 (delta 5), reused 0 (delta 0) This looks more serious, but I suspect it is totally unrelated to your previous fetch failing and leaving FETCH_HEAD there. Is this 'git fetch' hangs reproduce in a clean clone _without_ first encountering the failure (due to the forgotton ssh-add)? -- 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] git-svn: workaround for a bug in svn serf backend
Roman Kagan rka...@mail.ru writes: 2013/12/28 Junio C Hamano gits...@pobox.com: Eric Wong normalper...@yhbt.net writes: git://git.bogomips.org/git-svn.git master for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace: git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +) Roman Kagan (1): git-svn: workaround for a bug in svn serf backend perl/Git/SVN/Editor.pm | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) Thanks. I almost missed this pull-request, though. Will pull. Thanks! That's redundant; the project should thank you for contributing, not the other way around. I'd like to note that it's IMO worth including in the 'maint' branch as it's a crasher. Especially so since the real fix has been merged in the subversion upstream and nominated for 1.8 branch, so the workaround may soon lose its relevance. I do not quite get this part, though. If they refused to fix it for real, it would make it likely that this workaround will stay relevant for a long time, in which case it would be worth cherry-picking to an older maintenance track. But if this workaround is expected to lose its relevance shortly, I see it as one less reason to cherry-pick it to an older maintenance track. Confused... -- 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: aborted 'git fetch' leaves workspace unusable
On 2013-12-30 18.07, stephen_le...@stephe-leake.org wrote: I forgot to do 'ssh-add', so a 'git fetch' running under Windows Emacs Windows native emacs or emacs under cygwin ? tried to prompt for the ssh passphrase, could not find an ssh passphrase prompt program, and aborted. That left the workspace unusable: - .git/FETCH_HEAD is empty that causes 'git rev-parse FETCH_HEAD' to fail with a confusing error message. Would you mind to post the confusion error message here? Because some people may find it useful. - 'git fetch' just hangs after outputting: remote: Counting objects: 15, done. remote: Compressing objects: 100% (8/8), done. remote: Total 9 (delta 5), reused 0 (delta 0) even with -v --progress A fresh clone allowed me to continue working, but this will happen again, so I'd like a better fix. The fetch is from stephen_le...@git.savannah.gnu.org/emacs/elpa.git I'm running git 1.7.9 from Cygwin. This feels old, we have v1.8.5.2 as the latest version. I have access to Debian, where I can compile git and run it under the debugger, if that helps. I have not yet tried to reproduce this bug on Debian. This could be helpful: a) compile git under cygwin (try 1.8.5.2), and see if the problem is still there. b) Which version of cygwin do you have? c) If the same problem exist under Debian, debugging it could be helpfull, yes. If the same problem exist here, in some version of git, it would be helpful to test the latest version of git. (Which means compile debug) HTH /Torsten -- 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 1/2] merge-base: fix duplicates and not best ancestors in output
Junio C Hamano gits...@pobox.com writes: I do not offhand remember if it was deliberate that we do not dedup the result from the underlying get_octopus_merge_bases() (the most likely reason for not deduping is because the caller is expected to do that if it wants to). Whether it is an improvement to force deduping here or it is an regression to do so, I think we should split that helper function handle_octopus(). It does two totally unrelated things (one is only to list independent heads without showing merge bases, the other is to show one or more merge bases across all the heads given). Perhaps if we split the independent codepath introduced by a1e0ad78 (merge-base --independent to print reduced parent list in a merge, 2010-08-17) into its own helper function, like this, it would make it clear what is going on. And assuming that deduping is the right thing to do here, here is a follow-up on top of the spliting patch. -- 8 -- Subject: [PATCH] merge-base --octopus: reduce the result from get_octopus_merge_bases() Scripts that use merge-base --octopus could do the reducing themselves, but most of them are expected to want to get the reduced results without having to do any work themselves. Tests are taken from a message by Василий Макаров einmal...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- We might want to vet the existing callers of the underlying get_octopus_merge_bases() and find out if _all_ of them are doing anything extra (like deduping) because the machinery can return duplicate results. And if that is the case, then we may want to move the dedupling down the callchain instead of having it here. builtin/merge-base.c | 2 +- t/t6010-merge-base.sh | 39 +++ 2 files changed, 40 insertions(+), 1 deletion(-) diff --git a/builtin/merge-base.c b/builtin/merge-base.c index daa96c7..87f4dbc 100644 --- a/builtin/merge-base.c +++ b/builtin/merge-base.c @@ -73,7 +73,7 @@ static int handle_octopus(int count, const char **args, int show_all) for (i = count - 1; i = 0; i--) commit_list_insert(get_commit_reference(args[i]), revs); - result = get_octopus_merge_bases(revs); + result = reduce_heads(get_octopus_merge_bases(revs)); if (!result) return 1; diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh index f80bba8..abb5728 100755 --- a/t/t6010-merge-base.sh +++ b/t/t6010-merge-base.sh @@ -230,4 +230,43 @@ test_expect_success 'criss-cross merge-base for octopus-step' ' test_cmp expected.sorted actual.sorted ' +test_expect_success 'merge-base --octopus --all for complex tree' ' + # Best common ancestor for JE, JAA and JDD is JC + # JE + #/ | + # / | + # / | + # JAA/| + # |\ / | + # | \ | JDD | + # | \ |/ | | + # | JC JD | + # || /| | + # ||/ | | + # JA| | | + # |\ /| | | + # X JB | X X + # \ \ | / / + #\__\|/___/ + #J + test_commit J + test_commit JB + git reset --hard J + test_commit JC + git reset --hard J + test_commit JTEMP1 + test_merge JA JB + test_merge JAA JC + git reset --hard J + test_commit JTEMP2 + test_merge JD JB + test_merge JDD JC + git reset --hard J + test_commit JTEMP3 + test_merge JE JC + git rev-parse JC expected + git merge-base --all --octopus JAA JDD JE actual + test_cmp expected actual +' + test_done -- 1.8.5.2-311-g6427a96 -- 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 9/9] trailer: add tests for git interpret-trailers
On Mon, Dec 30, 2013 at 09:19:55AM -0800, Junio C Hamano wrote: Christian Couder chrisc...@tuxfamily.org writes: +# Do not remove trailing spaces below! +cat complex_message_trailers 'EOF' +Fixes: +Acked-by: +Reviewed-by: +Signed-off-by: +EOF Just a hint. I think it is far safer and robust over time to do something like this: sed -e 's/ Z$/ /' -\EOF Fixes: Z Acked-by: Z EOF instead of a comment, which can warn human developers but does not do anything to prevent their editors' auto-fix features from kicking in. This, but for simplicity, since every line needs the trailing space, why not just use 's/$/ /' and drop the ' Z' on every line? /bikeshed - Josh Triplett -- 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] for-each-ref: remove unused variable
Ramkumar Ramachandra artag...@gmail.com writes:
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Interesting. As far as I can tell, no code ever used this symbol
since the command was introduced at 9f613ddd (Add git-for-each-ref:
helper for language bindings, 2006-09-15).
builtin/for-each-ref.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 6551e7b..51798b4 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -92,7 +92,7 @@ static struct {
*/
static const char **used_atom;
static cmp_type *used_atom_type;
-static int used_atom_cnt, sort_atom_limit, need_tagged, need_symref;
+static int used_atom_cnt, need_tagged, need_symref;
static int need_color_reset_at_eol;
/*
@@ -1105,7 +1105,6 @@ int cmd_for_each_ref(int argc, const char **argv, const
char *prefix)
if (!sort)
sort = default_sort();
- sort_atom_limit = used_atom_cnt;
/* for warn_ambiguous_refs */
git_config(git_default_config, NULL);
--
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 v4 00/10] teach replace objects to sha1_object_info_extended()
Christian Couder chrisc...@tuxfamily.org writes:
The only changes compared to version 3 are the following:
I'll queue this instead on top, as the series is already in 'next'.
Thanks.
-- 8 --
From: Christian Couder chrisc...@tuxfamily.org
Date: Sat, 28 Dec 2013 12:00:05 +0100
Subject: [PATCH] replace info: rename 'full' to 'long' and clarify in-code
symbols
Enum names SHORT/MEDIUM/FULL were too broad to be descriptive. And
they clashed with built-in symbols on platforms like Windows.
Clarify by giving them REPLACE_FORMAT_ prefix.
Rename 'full' format in git replace --format=name to 'long', to
match others (i.e. 'short' and 'medium').
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 4 ++--
builtin/replace.c | 24 ++--
t/t6050-replace.sh| 4 ++--
3 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 7a07828..0a02f70 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -72,7 +72,7 @@ OPTIONS
--format=format::
When listing, use the specified format, which can be one of
- 'short', 'medium' and 'full'. When omitted, the format
+ 'short', 'medium' and 'long'. When omitted, the format
defaults to 'short'.
FORMATS
@@ -84,7 +84,7 @@ The following format are available:
replaced sha1
* 'medium':
replaced sha1 - replacement sha1
-* 'full'
+* 'long':
replaced sha1 (replaced type) - replacement sha1 (replacement
type)
CREATING REPLACEMENT OBJECTS
diff --git a/builtin/replace.c b/builtin/replace.c
index 1672870..2336325 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -20,11 +20,15 @@ static const char * const git_replace_usage[] = {
NULL
};
-enum repl_fmt { SHORT, MEDIUM, FULL };
+enum replace_format {
+ REPLACE_FORMAT_SHORT,
+ REPLACE_FORMAT_MEDIUM,
+ REPLACE_FORMAT_LONG
+};
struct show_data {
const char *pattern;
- enum repl_fmt fmt;
+ enum replace_format format;
};
static int show_reference(const char *refname, const unsigned char *sha1,
@@ -33,11 +37,11 @@ static int show_reference(const char *refname, const
unsigned char *sha1,
struct show_data *data = cb_data;
if (!fnmatch(data-pattern, refname, 0)) {
- if (data-fmt == SHORT)
+ if (data-format == REPLACE_FORMAT_SHORT)
printf(%s\n, refname);
- else if (data-fmt == MEDIUM)
+ else if (data-format == REPLACE_FORMAT_MEDIUM)
printf(%s - %s\n, refname, sha1_to_hex(sha1));
- else { /* data-fmt == FULL */
+ else { /* data-format == REPLACE_FORMAT_LONG */
unsigned char object[20];
enum object_type obj_type, repl_type;
@@ -64,14 +68,14 @@ static int list_replace_refs(const char *pattern, const
char *format)
data.pattern = pattern;
if (format == NULL || *format == '\0' || !strcmp(format, short))
- data.fmt = SHORT;
+ data.format = REPLACE_FORMAT_SHORT;
else if (!strcmp(format, medium))
- data.fmt = MEDIUM;
- else if (!strcmp(format, full))
- data.fmt = FULL;
+ data.format = REPLACE_FORMAT_MEDIUM;
+ else if (!strcmp(format, long))
+ data.format = REPLACE_FORMAT_LONG;
else
die(invalid replace format '%s'\n
- valid formats are 'short', 'medium' and 'full'\n,
+ valid formats are 'short', 'medium' and 'long'\n,
format);
for_each_replace_ref(show_reference, (void *) data);
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index d0c62f7..719a116 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -306,7 +306,7 @@ test_expect_success 'test --format medium' '
test_cmp expected actual
'
-test_expect_success 'test --format full' '
+test_expect_success 'test --format long' '
{
echo $H1 (commit) - $BLOB (blob)
echo $BLOB (blob) - $REPLACED (blob)
@@ -314,7 +314,7 @@ test_expect_success 'test --format full' '
echo $PARA3 (commit) - $S (commit)
echo $MYTAG (tag) - $HASH1 (commit)
} | sort expected
- git replace --format=full | sort actual
+ git replace --format=long | sort actual
test_cmp expected actual
'
--
1.8.5.2-311-g6427a96
--
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 9/9] trailer: add tests for git interpret-trailers
Josh Triplett j...@joshtriplett.org writes: On Mon, Dec 30, 2013 at 09:19:55AM -0800, Junio C Hamano wrote: Christian Couder chrisc...@tuxfamily.org writes: +# Do not remove trailing spaces below! +cat complex_message_trailers 'EOF' +Fixes: +Acked-by: +Reviewed-by: +Signed-off-by: +EOF Just a hint. I think it is far safer and robust over time to do something like this: sed -e 's/ Z$/ /' -\EOF Fixes: Z Acked-by: Z EOF instead of a comment, which can warn human developers but does not do anything to prevent their editors' auto-fix features from kicking in. This, but for simplicity, since every line needs the trailing space, why not just use 's/$/ /' and drop the ' Z' on every line? /bikeshed - Josh Triplett A few reasons: - The everybody will have a single SP at the end may or may not last forever; - With your scheme, if you already had _one_ trailing SPs in the input, it would be hard to spot in the source; - It makes it visually very clear that we expect a SP after these colons. This is especially true if you replace 'Z' with something more readable (e.g. '|'). -- 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 9/9] trailer: add tests for git interpret-trailers
On Mon, Dec 30, 2013 at 12:46:33PM -0800, Junio C Hamano wrote: Josh Triplett j...@joshtriplett.org writes: On Mon, Dec 30, 2013 at 09:19:55AM -0800, Junio C Hamano wrote: Christian Couder chrisc...@tuxfamily.org writes: +# Do not remove trailing spaces below! +cat complex_message_trailers 'EOF' +Fixes: +Acked-by: +Reviewed-by: +Signed-off-by: +EOF Just a hint. I think it is far safer and robust over time to do something like this: sed -e 's/ Z$/ /' -\EOF Fixes: Z Acked-by: Z EOF instead of a comment, which can warn human developers but does not do anything to prevent their editors' auto-fix features from kicking in. This, but for simplicity, since every line needs the trailing space, why not just use 's/$/ /' and drop the ' Z' on every line? /bikeshed - Josh Triplett A few reasons: - The everybody will have a single SP at the end may or may not last forever; Trivially fixed if that ever changes, but given the nature of all of these, that seems unlikely. - With your scheme, if you already had _one_ trailing SPs in the input, it would be hard to spot in the source; Git makes them quite difficult to miss. :) - Josh Triplett -- 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 9/9] trailer: add tests for git interpret-trailers
Josh Triplett j...@joshtriplett.org writes: - The everybody will have a single SP at the end may or may not last forever; Trivially fixed if that ever changes, but given the nature of all of these, that seems unlikely. Why? Because we encourage to write tests that are expected to find breakages, some of these test vector lines may have to show a broken line that lacks SP after label + colon. - With your scheme, if you already had _one_ trailing SPs in the input, it would be hard to spot in the source; Git makes them quite difficult to miss. :) That is irrelevant, isn't it? This is about protecting the source in the editor, before you run git show --whitespace=trailing-space, git diff --check, etc. -- 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/2] Call load_command_list() only when it is needed
This avoids list_commands_in_dir() being called when not needed which is
quite slow due to file I/O in order to list matching files in a directory.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
builtin/help.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/help.c b/builtin/help.c
index cc17e67..b6fc15e 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -288,6 +288,7 @@ static struct cmdnames main_cmds, other_cmds;
static int is_git_command(const char *s)
{
+ load_command_list(git-, main_cmds, other_cmds);
return is_in_cmdlist(main_cmds, s) ||
is_in_cmdlist(other_cmds, s);
}
@@ -449,7 +450,6 @@ int cmd_help(int argc, const char **argv, const char
*prefix)
int nongit;
const char *alias;
enum help_format parsed_help_format;
- load_command_list(git-, main_cmds, other_cmds);
argc = parse_options(argc, argv, prefix, builtin_help_options,
builtin_help_usage, 0);
@@ -458,6 +458,7 @@ int cmd_help(int argc, const char **argv, const char
*prefix)
if (show_all) {
git_config(git_help_config, NULL);
printf(_(usage: %s%s), _(git_usage_string), \n\n);
+ load_command_list(git-, main_cmds, other_cmds);
list_commands(colopts, main_cmds, other_cmds);
}
--
1.8.4.msysgit.0
--
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/2] Speed up is_git_command() by checking early for internal commands
Since 2dce956 is_git_command() was a bit slow as it does file I/O in the
call to list_commands_in_dir(). Avoid the file I/O by adding an early
check for internal commands.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
builtin/help.c | 5 ++
git.c | 242 ++---
2 files changed, 132 insertions(+), 115 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index b6fc15e..1f0261e 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -284,10 +284,15 @@ static int git_help_config(const char *var, const char
*value, void *cb)
return git_default_config(var, value, cb);
}
+extern int is_internal_command(const char *s);
+
static struct cmdnames main_cmds, other_cmds;
static int is_git_command(const char *s)
{
+ if (is_internal_command(s))
+ return 1;
+
load_command_list(git-, main_cmds, other_cmds);
return is_in_cmdlist(main_cmds, s) ||
is_in_cmdlist(other_cmds, s);
diff --git a/git.c b/git.c
index 3799514..cc81138 100644
--- a/git.c
+++ b/git.c
@@ -332,124 +332,136 @@ static int run_builtin(struct cmd_struct *p, int argc,
const char **argv)
return 0;
}
+static struct cmd_struct commands[] = {
+ { add, cmd_add, RUN_SETUP | NEED_WORK_TREE },
+ { annotate, cmd_annotate, RUN_SETUP },
+ { apply, cmd_apply, RUN_SETUP_GENTLY },
+ { archive, cmd_archive },
+ { bisect--helper, cmd_bisect__helper, RUN_SETUP },
+ { blame, cmd_blame, RUN_SETUP },
+ { branch, cmd_branch, RUN_SETUP },
+ { bundle, cmd_bundle, RUN_SETUP_GENTLY },
+ { cat-file, cmd_cat_file, RUN_SETUP },
+ { check-attr, cmd_check_attr, RUN_SETUP },
+ { check-ignore, cmd_check_ignore, RUN_SETUP | NEED_WORK_TREE },
+ { check-mailmap, cmd_check_mailmap, RUN_SETUP },
+ { check-ref-format, cmd_check_ref_format },
+ { checkout, cmd_checkout, RUN_SETUP | NEED_WORK_TREE },
+ { checkout-index, cmd_checkout_index,
+ RUN_SETUP | NEED_WORK_TREE},
+ { cherry, cmd_cherry, RUN_SETUP },
+ { cherry-pick, cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
+ { clean, cmd_clean, RUN_SETUP | NEED_WORK_TREE },
+ { clone, cmd_clone },
+ { column, cmd_column, RUN_SETUP_GENTLY },
+ { commit, cmd_commit, RUN_SETUP | NEED_WORK_TREE },
+ { commit-tree, cmd_commit_tree, RUN_SETUP },
+ { config, cmd_config, RUN_SETUP_GENTLY },
+ { count-objects, cmd_count_objects, RUN_SETUP },
+ { credential, cmd_credential, RUN_SETUP_GENTLY },
+ { describe, cmd_describe, RUN_SETUP },
+ { diff, cmd_diff },
+ { diff-files, cmd_diff_files, RUN_SETUP | NEED_WORK_TREE },
+ { diff-index, cmd_diff_index, RUN_SETUP },
+ { diff-tree, cmd_diff_tree, RUN_SETUP },
+ { fast-export, cmd_fast_export, RUN_SETUP },
+ { fetch, cmd_fetch, RUN_SETUP },
+ { fetch-pack, cmd_fetch_pack, RUN_SETUP },
+ { fmt-merge-msg, cmd_fmt_merge_msg, RUN_SETUP },
+ { for-each-ref, cmd_for_each_ref, RUN_SETUP },
+ { format-patch, cmd_format_patch, RUN_SETUP },
+ { fsck, cmd_fsck, RUN_SETUP },
+ { fsck-objects, cmd_fsck, RUN_SETUP },
+ { gc, cmd_gc, RUN_SETUP },
+ { get-tar-commit-id, cmd_get_tar_commit_id },
+ { grep, cmd_grep, RUN_SETUP_GENTLY },
+ { hash-object, cmd_hash_object },
+ { help, cmd_help },
+ { index-pack, cmd_index_pack, RUN_SETUP_GENTLY },
+ { init, cmd_init_db },
+ { init-db, cmd_init_db },
+ { log, cmd_log, RUN_SETUP },
+ { ls-files, cmd_ls_files, RUN_SETUP },
+ { ls-remote, cmd_ls_remote, RUN_SETUP_GENTLY },
+ { ls-tree, cmd_ls_tree, RUN_SETUP },
+ { mailinfo, cmd_mailinfo },
+ { mailsplit, cmd_mailsplit },
+ { merge, cmd_merge, RUN_SETUP | NEED_WORK_TREE },
+ { merge-base, cmd_merge_base, RUN_SETUP },
+ { merge-file, cmd_merge_file, RUN_SETUP_GENTLY },
+ { merge-index, cmd_merge_index, RUN_SETUP },
+ { merge-ours, cmd_merge_ours, RUN_SETUP },
+ { merge-recursive, cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
+ { merge-recursive-ours, cmd_merge_recursive, RUN_SETUP |
NEED_WORK_TREE },
+ { merge-recursive-theirs, cmd_merge_recursive, RUN_SETUP |
NEED_WORK_TREE },
+ { merge-subtree, cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
+ { merge-tree, cmd_merge_tree, RUN_SETUP },
+ { mktag, cmd_mktag, RUN_SETUP },
+ { mktree, cmd_mktree, RUN_SETUP },
+ { mv, cmd_mv, RUN_SETUP | NEED_WORK_TREE },
+ { name-rev, cmd_name_rev, RUN_SETUP },
+ { notes, cmd_notes, RUN_SETUP },
+ { pack-objects, cmd_pack_objects, RUN_SETUP },
+ { pack-redundant, cmd_pack_redundant, RUN_SETUP },
+ { pack-refs, cmd_pack_refs, RUN_SETUP },
+ { patch-id, cmd_patch_id },
+ { pickaxe, cmd_blame, RUN_SETUP },
+ { prune, cmd_prune, RUN_SETUP },
+ {
Re: [PATCH] remote-hg: do not fail on invalid bookmarks
On Mon, Dec 30, 2013 at 08:41:13AM +0100, Antoine Pelisse wrote: On Sun, Dec 29, 2013 at 11:24 PM, Mike Hommey m...@glandium.org wrote: On Sun, Dec 29, 2013 at 12:30:02PM +0100, Antoine Pelisse wrote: Mercurial can have bookmarks pointing to nullid (the empty root revision), while Git can not have references to it. When cloning or fetching from a Mercurial repository that has such a bookmark, the import will fail because git-remote-hg will not be able to create the corresponding reference. Warn the user about the invalid reference, and continue the import, instead of stopping right away. It's not invalid, it's used to indicate deleted bookmarks. (Tags have the same property) Hey Mike, Indeed, I don't know how I ended-up with such a bookmark, but it prevented me from git-cloning the repository (and the backtrace was not very helpful at first). But I'm still not sure what you mean by deleted bookmarks ? I guess it's not hg bookmark --delete, as it would not be listed at all. Is it hg strip some_changeset that end-up deleting the bookmarked changeset ? I think I've tested this use-case and it moved the bookmark to a parent changeset. Mmmm after looking at the mercurial code, it looks like i was wrong and bookmarks are not handled like tags. You can actually create such a bookmark on purpose with: $ hg bookmark -r null foo Then, if you do, say: $ hg up -r foo $ echo a a $ hg add a $ hg commit -m a Then you end up with a completely new head with no ancestors in common with the others. In git terms, $ hg bookmark -r null foo $ hg up -r foo is equivalent to $ git checkout --orphan foo But git never creates an actual ref in that case. Mike -- 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
Git for Windows 1.8.5.2 (preview)
Dear fans of Git, this mail brings to you the good news that Git for Windows is available in a new version: 1.8.5.2-preview20131230 Many, many thanks go to the tireless developers working on this particularly hard port of Git. Changes since Git-1.8.4-preview20130916 New Features - Comes with Git 1.8.5.2 plus Windows-specific patches. - Windows-specific patches are now grouped into pseudo-branches which should make future development more robust despite the fact that we have had less than stellar success getting the Windows-specific patches accepted by upstream git.git. - Works around more path length limitations (pull request #86) - Has an optional stat() cache toggled via core.fscache (pull request #107) Bugfixes - Lots of installer fixes - git-cmd: Handle home directory on a different drive correctly (pull request #146) - git-cmd: add a helper to work with the ssh agent (pull request #135) - Git-Cheetah: prevent duplicate menu entries (pull request #7) - No longer replaces dos2unix with hd2u (a more powerful, but slightly incompatible version of dos2unix) In keeping with the fine tradition of making a release on the eve of a holiday, and immediately going on vacation, it is my pleasure to wish you all a happy new year, Johannes -- 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 v4 00/10] teach replace objects to sha1_object_info_extended()
From: Junio C Hamano gits...@pobox.com Christian Couder chrisc...@tuxfamily.org writes: The only changes compared to version 3 are the following: I'll queue this instead on top, as the series is already in 'next'. Great! Thanks, Christian. -- 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] git-svn: workaround for a bug in svn serf backend
2013/12/30 Junio C Hamano gits...@pobox.com: Roman Kagan rka...@mail.ru writes: I'd like to note that it's IMO worth including in the 'maint' branch as it's a crasher. Especially so since the real fix has been merged in the subversion upstream and nominated for 1.8 branch, so the workaround may soon lose its relevance. I do not quite get this part, though. If they refused to fix it for real, it would make it likely that this workaround will stay relevant for a long time, in which case it would be worth cherry-picking to an older maintenance track. But if this workaround is expected to lose its relevance shortly, I see it as one less reason to cherry-pick it to an older maintenance track. Confused... I thought it was exactly the other way around. By the time the next feature release reaches users, chances are they'd already have subversion with the fix. OTOH the workaround would benefit those who get their maintenance release of git (e.g. through their Linux distro update) before they get their maintenance release of subversion. Documentation/SubmittingPatches also suggests to submit bugfixes against 'maint'. But I might have got it wrong... Roman. -- 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
