[PATCH 06/11] completion: zsh: trivial cleanups
We don't need to override IFS, zsh has a native way of splitting by new
lines: the expansion flag (f).
Also, we don't need to split files by ':' or '='; that's only for words.
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
contrib/completion/git-completion.zsh | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index e10df7d..317b8eb 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -65,26 +65,22 @@ __gitcomp_nl ()
{
emulate -L zsh
- local IFS=$'\n'
compset -P '*[=:]'
- compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
+ compadd -Q -S "${4- }" -p "${2-}" -- ${(f)1} && _ret=0
}
__gitcomp_nl_append ()
{
emulate -L zsh
- local IFS=$'\n'
- compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
+ compadd -Q -S "${4- }" -p "${2-}" -- ${(f)1} && _ret=0
}
__gitcomp_file ()
{
emulate -L zsh
- local IFS=$'\n'
- compset -P '*[=:]'
- compadd -Q -p "${2-}" -f -- ${=1} && _ret=0
+ compadd -Q -p "${2-}" -f -- ${(f)1} && _ret=0
}
__git_zsh_bash_func ()
--
2.8.0+fc1
--
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 04/11] completion: zsh: don't hide ourselves
There's no need to hide the fact that we are on zsh any more.
Signed-off-by: Felipe Contreras <felipe.contre...@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 e255413..475705a 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -39,7 +39,7 @@ if [ -z "$script" ]; then
test -f $e && script="$e" && break
done
fi
-ZSH_VERSION='' . "$script"
+. "$script"
__gitcomp ()
{
--
2.8.0+fc1
--
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 09/11] completion: zsh: fix for directories with spaces
Signed-off-by: Felipe Contreras <felipe.contre...@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 1f786cc..28eaaed 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -24,7 +24,7 @@ if [ -z "$script" ]; then
local -a locations
local e
locations=(
- $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
+ "$(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
--
2.8.0+fc1
--
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 05/11] completion: remove zsh hack
We don't want to override the 'complete()' function in zsh, which can be
used by bashcomp.
Reported-by: Mark Lodato <lod...@google.com>
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
contrib/completion/git-completion.bash | 1 +
contrib/completion/git-completion.zsh | 6 --
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 9cbae6f..6c338ae 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2684,6 +2684,7 @@ __git_func_wrap ()
# This is NOT a public function; use at your own risk.
__git_complete ()
{
+ test -n "$ZSH_VERSION" && return
local wrapper="__git_wrap${2}"
eval "$wrapper () { __git_func_wrap $2 ; }"
complete -o bashdefault -o default -o nospace -F $wrapper $1
2>/dev/null \
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 475705a..e10df7d 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -16,12 +16,6 @@
#
# fpath=(~/.zsh $fpath)
-complete ()
-{
- # do nothing
- return 0
-}
-
zstyle -T ':completion:*:*:git:*' tag-order && \
zstyle ':completion:*:*:git:*' tag-order 'common-commands'
--
2.8.0+fc1
--
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 07/11] completion: bash: cleanup cygwin check
Avoid Yoda conditions, use test, and cleaner statement. Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com> --- contrib/completion/git-completion.bash | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 6c338ae..398f3a7 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -2698,6 +2698,5 @@ __git_complete gitk __gitk_main # when the user has tab-completed the executable name and consequently # included the '.exe' suffix. # -if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then +test "$(uname -o 2>/dev/null)" = "Cygwin" && __git_complete git.exe __git_main -fi -- 2.8.0+fc1 -- 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 03/11] completion: bash: remove zsh wrapper
It has been deprecated for more than three years. It's time to move on.
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
contrib/completion/git-completion.bash | 64 --
1 file changed, 64 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 5e2e590..9cbae6f 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2672,70 +2672,6 @@ __gitk_main ()
__git_complete_revlist
}
-if [[ -n ${ZSH_VERSION-} ]]; then
- echo "WARNING: this script is deprecated, please see
git-completion.zsh" 1>&2
-
- autoload -U +X compinit && compinit
-
- __gitcomp ()
- {
- emulate -L zsh
-
- local cur_="${3-$cur}"
-
- case "$cur_" in
- --*=)
- ;;
- *)
- local c IFS=$' \t\n'
- local -a array
- for c in ${=1}; do
- c="$c${4-}"
- case $c in
- --*=*|*.) ;;
- *) c="$c " ;;
- esac
- array[${#array[@]}+1]="$c"
- done
- compset -P '*[=:]'
- compadd -Q -S '' -p "${2-}" -a -- array && _ret=0
- ;;
- esac
- }
-
- __gitcomp_nl ()
- {
- emulate -L zsh
-
- local IFS=$'\n'
- compset -P '*[=:]'
- compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
- }
-
- __gitcomp_file ()
- {
- emulate -L zsh
-
- local IFS=$'\n'
- compset -P '*[=:]'
- compadd -Q -p "${2-}" -f -- ${=1} && _ret=0
- }
-
- _git ()
- {
- local _ret=1 cur cword prev
- cur=${words[CURRENT]}
- prev=${words[CURRENT-1]}
- let cword=CURRENT-1
- emulate ksh -c __${service}_main
- let _ret && _default && _ret=0
- return _ret
- }
-
- compdef _git git gitk
- return
-fi
-
__git_func_wrap ()
{
local cur words cword prev
--
2.8.0+fc1
--
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 11/11] Revert "Update documentation occurrences of filename .sh"
The original code was correct: the example location ~/.git-completion.sh is correct, because it's not only used by Bash. And zstyle command in Zsh should use that same location; the Bash script. This reverts commit 0e5ed7cca3c51c821c2bb0465617e75d994f432f. Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com> --- contrib/completion/git-completion.bash | 4 ++-- contrib/completion/git-completion.zsh | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 398f3a7..3224ae1 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -17,9 +17,9 @@ # # To use these routines: # -#1) Copy this file to somewhere (e.g. ~/.git-completion.bash). +#1) Copy this file to somewhere (e.g. ~/.git-completion.sh). #2) Add the following line to your .bashrc/.zshrc: -#source ~/.git-completion.bash +#source ~/.git-completion.sh #3) Consider changing your PS1 to also show the current branch, # see git-prompt.sh for details. # diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh index 28eaaed..6075111 100644 --- a/contrib/completion/git-completion.zsh +++ b/contrib/completion/git-completion.zsh @@ -9,7 +9,7 @@ # # If your script is somewhere else, you can configure it on your ~/.zshrc: # -# zstyle ':completion:*:*:git:*' script ~/.git-completion.zsh +# zstyle ':completion:*:*:git:*' script ~/.git-completion.sh # # The recommended way to install this script is to copy to '~/.zsh/_git', and # then add the following to your ~/.zshrc file: -- 2.8.0+fc1 -- 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 10/11] completion: prompt: fix for Zsh
We can add colour in Zsh without the need of pcmode.
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
contrib/completion/git-prompt.sh | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 64219e6..0da14ee 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -502,9 +502,11 @@ __git_ps1 ()
local z="${GIT_PS1_STATESEPARATOR-" "}"
- # NO color option unless in PROMPT_COMMAND mode
- if [ $pcmode = yes ] && [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then
- __git_ps1_colorize_gitstring
+ # NO color option unless in PROMPT_COMMAND mode or it's Zsh
+ if [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then
+ if [ $pcmode = yes ] || [ -n "${ZSH_VERSION-}" ]; then
+ __git_ps1_colorize_gitstring
+ fi
fi
b=${b##refs/heads/}
--
2.8.0+fc1
--
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 08/11] completion: zsh: improve main function selection
Sometimes we want to use the function directly (e.g. _git_checkout), for
example when zsh has the option 'complete_aliases', this way, we can do
something like:
compdef _git gco=git_checkout
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
contrib/completion/git-completion.zsh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 317b8eb..1f786cc 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -204,8 +204,10 @@ _git ()
if (( $+functions[__${service}_zsh_main] )); then
__${service}_zsh_main
- else
+ elif (( $+functions[__${service}_main] )); then
emulate ksh -c __${service}_main
+ elif (( $+functions[_${service}] )); then
+ emulate ksh -c _${service}
fi
let _ret && _default && _ret=0
--
2.8.0+fc1
--
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 01/11] completion: add missing fetch options
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com> --- contrib/completion/git-completion.bash | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index e3918c8..ecdf742 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1225,6 +1225,8 @@ __git_fetch_recurse_submodules="yes on-demand no" __git_fetch_options=" --quiet --verbose --append --upload-pack --force --keep --depth= --tags --no-tags --all --prune --dry-run --recurse-submodules= + --no-recurse-submodules --unshallow --update-shallow --multiple + --submodule-prefix= --update-head-ok --progress " _git_fetch () -- 2.8.0+fc1 -- 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 00/11] Completion fixes and improvements
Hi, Here's a bunch of patches I've been using for a long time. I don't recall if I've sent some of these before. Here they are in case anybody is interested. Cheers. Felipe Contreras (11): completion: add missing fetch options completion: bash: remove old wrappers completion: bash: remove zsh wrapper completion: zsh: don't hide ourselves completion: remove zsh hack completion: zsh: trivial cleanups completion: bash: cleanup cygwin check completion: zsh: improve main function selection completion: zsh: fix for directories with spaces completion: prompt: fix for Zsh Revert "Update documentation occurrences of filename .sh" contrib/completion/git-completion.bash | 86 +++--- contrib/completion/git-completion.zsh | 26 -- contrib/completion/git-prompt.sh | 8 ++-- 3 files changed, 20 insertions(+), 100 deletions(-) -- 2.8.0+fc1 -- 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] fast-import: do not truncate exported marks file
On Tue, May 17, 2016 at 10:59 PM, Junio C Hamano <gits...@pobox.com> wrote: > On Tue, May 17, 2016 at 8:31 PM, Felipe Contreras > <felipe.contre...@gmail.com> wrote: >> On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano <gits...@pobox.com> wrote: >>> - Even if we did not read from any existing marks file, if we are >>>given export_marks_file that names an existing file, wouldn't we >>>want to avoid corrupting it with a dump from this aborted run? >> >> If we don't run from an existing marks file, this patch has no effect. > > Yes, that is exactly what I was wondering if we may want to improve > while at it. This doesn't make much sense. Corrupted from where? This patch is tackling the issue where the imported marks file is "corrupted". -- Felipe Contreras -- 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] fast-import: do not truncate exported marks file
On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano <gits...@pobox.com> wrote: > Felipe Contreras <felipe.contre...@gmail.com> writes: > >> Certain lines of the marks file might be corrupted (or the objects >> missing due to a garbage collection), but that's no reason to truncate >> the file and essentially destroy the rest of it. > > Hmm, so the issue is: > > - we use die_nicely() that calls dump_marks() after writing a crash >report as our die_routine(). > > - when dump_marks() is called, and export_marks_file names an >existing file, it tries to write marks in it. If we let it go >through, we would end up writing a new marks file based on an >incomplete set of marks we have only half-read in the earlier >step, which is bad, as the resulting one is incomplete, and the >original one that this replaced may have been a good one. > > Is that what this change addresses? Yes. As I said; the marks file gets truncated. > I am just wondering if a solution to preserve both files is more > desirable. > > This change looks a bit over-eager to discard the dump die_nicely() > is trying to create in one scenario, and a bit less careful at the > same time in another scenario. > > - Even if we are reading from somewhere, export_marks_file can >point at a completely new file that is different from >import_marks file, in which case, we are not really losing any >information by freshly creating a new marks file, no? Right, we are not losing any information, but we are not gaining much either: it's a truncated version of the import marks. > - Even if we did not read from any existing marks file, if we are >given export_marks_file that names an existing file, wouldn't we >want to avoid corrupting it with a dump from this aborted run? If we don't run from an existing marks file, this patch has no effect. -- Felipe Contreras -- 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] fast-import: do not truncate exported marks file
Certain lines of the marks file might be corrupted (or the objects
missing due to a garbage collection), but that's no reason to truncate
the file and essentially destroy the rest of it.
Ideally missing objects should not cause a crash, we could just skip
them, but that's another patch.
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
fast-import.c | 7 +--
t/t9300-fast-import.sh | 15 +++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 9fc7093..a975c34 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -329,6 +329,7 @@ static const char *export_marks_file;
static const char *import_marks_file;
static int import_marks_file_from_stream;
static int import_marks_file_ignore_missing;
+static int import_marks_file_done;
static int relative_marks_paths;
/* Our last blob */
@@ -1802,7 +1803,7 @@ static void dump_marks(void)
static struct lock_file mark_lock;
FILE *f;
- if (!export_marks_file)
+ if (!export_marks_file || (import_marks_file &&
!import_marks_file_done))
return;
if (hold_lock_file_for_update(_lock, export_marks_file, 0) < 0) {
@@ -1835,7 +1836,7 @@ static void read_marks(void)
if (f)
;
else if (import_marks_file_ignore_missing && errno == ENOENT)
- return; /* Marks file does not exist */
+ goto done; /* Marks file does not exist */
else
die_errno("cannot read '%s'", import_marks_file);
while (fgets(line, sizeof(line), f)) {
@@ -1865,6 +1866,8 @@ static void read_marks(void)
insert_mark(mark, e);
}
fclose(f);
+done:
+ import_marks_file_done = 1;
}
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 25bb60b..4bca35c 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -2650,6 +2650,21 @@ test_expect_success 'R: ignore non-git options' '
git fast-import expect <<-EOF &&
+ :3
+ :1 $blob
+ :2 $blob
+ EOF
+ cp expect io.marks &&
+ test_must_fail git fast-import --import-marks=io.marks
--export-marks=io.marks <<-\EOF &&
+
+ EOF
+ test_cmp expect io.marks
+'
+
##
## R: very large blobs
##
--
2.8.2.dirty
--
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: Reset by checkout?
Kevin Bracey wrote: Maybe we just need to tighten up the EXAMPLES section? Give it easy-to-locate path/--soft/--mixed/--keep subheadings, covering all those common use cases (in clean trees...), including a before/after git status views. Then normal users could skip the top technical section waffling about indexes and go straight there instead. Or maybe we need to have sane options, like --stage, --work, and --keep. -- Felipe Contreras -- 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: [ANNOUNCE] Git v2.0.0
Jeff King wrote: On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote: And frankly, if I were a list moderator and software asked me through this sort of coincidence whether a mail should be delivered or not and a glance at it shows nothing but insults, wild accusations, threats and so on for the umpteenth time, I'd consider twice clicking Accept. Whether or not I ultimately did so, this would likely contribute to the delay. I do not disagree, but please let's not rehash all of that again. FTR. I haven't insulted anybody, I on the other hand have been insulted plenty of times, included by Junio. -- Felipe Contreras -- 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: Reset by checkout?
Atsushi Nakagawa wrote: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use reset by checkout and be carefree. Doesn't 'git reset orign/master' do that? -- Felipe Contreras -- 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: Reset by checkout?
Felipe Contreras wrote: Atsushi Nakagawa wrote: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use reset by checkout and be carefree. Doesn't 'git reset orign/master' do that? Unless you want to keep the staged files, in which case adding the --stage and --work options I originally suggested[1] would help. So you could do `git reset --no-stage --no-work origin/master` Which is essentially the same as `git update-ref refs/heads/master origin/master`. [1] http://article.gmane.org/gmane.comp.version-control.git/247086 -- Felipe Contreras -- 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: [ANNOUNCE] Git v2.0.0
Jeff King wrote: On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote: This is the last mail I sent to you, because you ignore them anyway, and remove them from the mailing list. [...] [2], a mail you conveniently removed from the tracked record. [...] You also conveniently removed this mail from the archives. I see you already noticed the changes in v2.0, but I wanted to address these points, because I consider silent censorship to be a serious accusation. Yes, I also think silent censorship is a very seriours matter, and I was very dissapointed that this mailing list would engage in that. I've reported the bug to gmane.discuss (no link yet, as I'm waiting for the message to go through, but it is not a high traffic group, so it should be easy to find the thread once it is there). Thanks. At first I thought that was the reason, but then I noticed it was always my mails that seemed to get this bug, so I decided it was too much of a coincidence. Hopefully it's indeed a bug. -- Felipe Contreras -- 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: Summary of the problems with git pull
Philippe Vaucher wrote: Sorry if I missed a thread where it was already decided not to include it. Felipe, please don't use this to start any non-constructive behavior (rant on who is right/wrong, my patches are not accepted, etc). I never sent those patches. I gave up on the Git project. -- Felipe Contreras -- 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: [ANNOUNCE] Git v2.0.0
This is the last mail I sent to you, because you ignore them anyway, and
remove them from the mailing list.
I'm am cc'ing the git-fc mailing list so there's a public track record
of this, so you can't claim it didn't happen.
Junio C Hamano wrote:
* The remote-hg/bzr remote-helper interfaces (used to be in
contrib/) are no more. They are now maintained separately as
third-party plug-ins in their own repositories.
This is a lie. You are saying they don't exist any more, but they do
exist, they graduated according to your same words.
Also, in mail [1] Jeff said:
But that being said, this is Felipe's code. While we have a legal
right to distribute it in v2.0, if he would really prefer it out for
v2.0, I would respect that.
To which you agreed, however, after you fucked up v2.0 and removed an
important patch, I said I changed my wish that I didn't want to disturb
v2.0 in mail [2], a mail you conveniently removed from the tracked
record.
In mail [3] you acknowledged my wish, and you said you were going to put
stubs for v2.0, and you didn't. You also conveniently removed this mail
from the archives.
Your rhetoric to make it appear as if the code is gone, your repeated
failures to accomplish my wish, even you said you would, and your
deliberate removal of the relevant discussion gives me no choice.
I threat all this as deliberate acts of aggression, and I will respond
as I said I would, and bring as much public attention to what you are
doing as possible.
[1] 20140516084126.gb21...@sigill.intra.peff.net
[2] 537bbd6c1daf_a6f166b308b0@nysa.notmuch
[3] xmqqlhtwrufq@gitster.dls.corp.google.com
For reference, here's the full content of mail [2]:
From: Felipe Contreras felipe.contre...@gmail.com
Subject: Re: [PATCH] remote-helpers: point at their upstream repositories
To: Junio C Hamano gits...@pobox.com, Felipe Contreras
felipe.contre...@gmail.com
Cc: Jeff King p...@peff.net, git@vger.kernel.org
Date: Tue, 20 May 2014 15:39:08 -0500
--- text/plain ---
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
2. add warning that is given every time the scripts are run and
give the same instruction as in README.
3. (optional) cripple the script to make them always fail after
showing the same warning as above.
This is what I want, and I already sent the patches for; the scripts
will be stubs. At this point you would have effectively removed the
code, which what I want.
4. Keep README and retire everything else.
After you've removed the code, I don't care what you do, but I'd say you
should remove the stubs after a long period of time.
Let's try this in a different way, as I sense there is a
misunderstanding somewhere about your wish.
that does not refer to remove them at v2.0 (unconditional). It
refers to If Felipe really wants for the removal for v2.0, I would
respect that. And I saw you said you did not want to disrupt v2.0.
If the options I listed all meant removal at v2.0, then I would
understand your complaints, but that is not the case, so I am not
sure what to make of that.
It is a weird choice of semantics then. You said you would respect my
wish, but your proposals did not follow my wish.
I understand you do not want to disrupt v2.0. My assumption of that
not disrupting v2.0 has been there still are git-remote-{hg,bzr}
that work just like what they had in v1.9.x, perhaps with some
enhancements and regressions you added in the meantime, and I
understood Peff's comment If Felipe wants the removal to mean that
kind of disruption, i.e. there is no git-remote-{hg,bzr} that
work., which would be either step 3 or 4.
But your After you've removed the code comment above makes me
wonder that perhaps your definition of not disrupting was
different from ours (which is not good or bad, just different) and
you consider that step 3. is removal but not distupting v2.0?
If that is what you want in v2.0, then please say so, and I already
said I am fine with that.
No, I already said I do not want the code removed from v2.0, that's why
I sent patches that simply added a warning, and I specifically said
those were for 2.0.
However, after seeing this commit:
10e1fee (Revert Merge branch 'fc/transport-helper-sync-error-fix')
Which is:
1) Inaccurate
2) A lie (*you* broke 2.0, not me)
3) A disservice to users
I therefore change my wish for you to remove all the remote helpers code
and a replace them with stubs (the patches I originally sent for
post-2.0).
It was a mistake from me to believe you would do the sensible thing for
2.0.
So to make it clear, I now request that you do:
1) Remove all the code.
Since my patches were removed from the list, here's an updated patch
that applies on top of 'master'
https://github.com/felipec/git/commits/up/remote/remove
2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix
RE: [ANNOUNCE] Git v2.0.0
Felipe Contreras wrote: In mail [3] you acknowledged my wish, and you said you were going to put stubs for v2.0, and you didn't. You also conveniently removed this mail from the archives. My bad. You actually did it. I missed it because the commit is named 'Revert Merge branch 'jc/graduate-remote-hg-bzr' (early part)', which is not at all what it is doing. So it's just the release notes that are misleading. -- Felipe Contreras -- 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: What's cooking in git.git (May 2014, #05; Fri, 23)
Junio C Hamano wrote:
* fc/publish-vs-upstream (2014-04-21) 8 commits
. sha1_name: add support for @{publish} marks
. sha1_name: simplify track finding
. sha1_name: cleanup interpret_branch_name()
. branch: display publish branch
. push: add --set-publish option
. branch: add --set-publish-to option
. Add concept of 'publish' branch
. t5516 (fetch-push): fix test restoration
Add branch@{publish}; it seems that this is somewhat different from
Ram and Peff started working on. At least the tip needs to be
rerolled not to squat on @{p} which @{push} and possibly @{pull}
may want to share.
Ejected from 'pu' to unclutter.
Sure, to unclutter.
Either way I'm not going to pursue this anymore. I've made changes since
I sent those patches, for those who want this feature, you can find the
latest patches here:
https://github.com/felipec/git/commits/fc/publish
Or just use git-fc.
* fc/remote-hg-fixes-for-hg-3.0 (2014-05-08) 5 commits
. [DONTMERGE-not signed-off] remote-hg: work with older versions of mercurial
. remote-hg: add support for hg v3.0
. t: remote-hg: trivial cleanups and fixes
. t: remote-hg: add file operation tests
. remote-hg: add more tests
No longer relevant, as 'master' unbundles contrib/remote-helpers/.
And for the record, the branch was never properly named, as those
patches are *not* for hg 3.0.
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
. remote-hg: trivial cleanups
. remote-hg: make sure we omit multiple heads
. git-remote-hg: use internal clone's hgrc
. t: remote-hg: split into setup test
. remote-hg: properly detect missing contexts
. remote-{hg,bzr}: store marks only on success
. remote-hg: update to 'public' phase when pushing
. remote-hg: fix parsing of custom committer
(merged to 'next' on 2014-04-22 at fed170a)
+ remote-helpers: move tests out of contrib
+ remote-helpers: move out of contrib
+ remote-helpers: squelch python import exceptions
No longer relevant, as 'master' unbundles contrib/remote-helpers/.
Again a badly named branch; those changes are independent of the
graduation.
--
Felipe Contreras
--
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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Junio C Hamano wrote: I presume that the workflow can be mimicked by having another branch 'match-next' and building it on top of 'master', and then building 'jch' on top of it, and then building 'pu' on top of it. Then you should be able to play 'match-next' instruction on top of 'next' (provided that there is a way to tell it to replay on HEAD and ignore base and have merge instruction become a no-op when the branch has already been merged). Done. % git checkout next % git reintegrate --apply match-next https://github.com/felipec/git-reintegrate/commit/036395b -- Felipe Contreras -- 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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Felipe Contreras wrote: Yes, I see how xx/topic~4 would be useful in the instruction sheet, I just didn't see it would be useful to generate that from an existing integration branch. After the explanation above I see how it could be useful to some people (though not all). I'll implement that. Actually it was already supported. https://github.com/felipec/git-reintegrate/commit/f3aa558 -- Felipe Contreras -- 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: [ANNOUNCE] Git v2.0.0-rc4
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: * The remote-helper interface to fast-import/fast-export via the transport-helper has been tightened to avoid leaving the import marks file from a failed/crashed run, as such a file that is out-of- sync with reality confuses a later invocation of itself. Really? Where are the patches for that? I think it's fair to say the way the remote-helpers and transport-helper has been handled for v2.0 has been a total disaster. Thanks for noticing. The last-minute change of plans in the morning on the -rc release day did not help. Will remove. But this changed before that. Anything else I missed? Not as far as I can see. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
2. add warning that is given every time the scripts are run and
give the same instruction as in README.
3. (optional) cripple the script to make them always fail after
showing the same warning as above.
This is what I want, and I already sent the patches for; the scripts
will be stubs. At this point you would have effectively removed the
code, which what I want.
4. Keep README and retire everything else.
After you've removed the code, I don't care what you do, but I'd say you
should remove the stubs after a long period of time.
Let's try this in a different way, as I sense there is a
misunderstanding somewhere about your wish.
that does not refer to remove them at v2.0 (unconditional). It
refers to If Felipe really wants for the removal for v2.0, I would
respect that. And I saw you said you did not want to disrupt v2.0.
If the options I listed all meant removal at v2.0, then I would
understand your complaints, but that is not the case, so I am not
sure what to make of that.
It is a weird choice of semantics then. You said you would respect my
wish, but your proposals did not follow my wish.
I understand you do not want to disrupt v2.0. My assumption of that
not disrupting v2.0 has been there still are git-remote-{hg,bzr}
that work just like what they had in v1.9.x, perhaps with some
enhancements and regressions you added in the meantime, and I
understood Peff's comment If Felipe wants the removal to mean that
kind of disruption, i.e. there is no git-remote-{hg,bzr} that
work., which would be either step 3 or 4.
But your After you've removed the code comment above makes me
wonder that perhaps your definition of not disrupting was
different from ours (which is not good or bad, just different) and
you consider that step 3. is removal but not distupting v2.0?
If that is what you want in v2.0, then please say so, and I already
said I am fine with that.
No, I already said I do not want the code removed from v2.0, that's why
I sent patches that simply added a warning, and I specifically said
those were for 2.0.
However, after seeing this commit:
10e1fee (Revert Merge branch 'fc/transport-helper-sync-error-fix')
Which is:
1) Inaccurate
2) A lie (*you* broke 2.0, not me)
3) A disservice to users
I therefore change my wish for you to remove all the remote helpers code
and a replace them with stubs (the patches I originally sent for
post-2.0).
It was a mistake from me to believe you would do the sensible thing for
2.0.
So to make it clear, I now request that you do:
1) Remove all the code.
Since my patches were removed from the list, here's an updated patch
that applies on top of 'master'
https://github.com/felipec/git/commits/up/remote/remove
2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix')
Since the code in question is no longer part of v2.0, a possible
regression that you aren't even sure of cannot be the rationale to
revert this code.
Your commit 10e1fee (Revert Merge branch
'fc/transport-helper-sync-error-fix') actively hurts the
out-of-tree tools, so I'll consider a failure to re-revert a hostile
action.
3) Update the release notes to mention these tools have been removed
Additionally, you might want to:
4) Re-add the following release note:
* git push via transport-helper interface (e.g. remote-hg) has
been updated to allow forced ref updates in a way similar to the
natively supported transports
I don't know why you removed it in the first place. Clearly you pay
no attention at all to these interfaces.
I expect you to do at the very least 1) and 2).
--
Felipe Contreras
--
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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
After looking at the reverse-depends list of packages, my faith is
strengthened in that the Git ecosystem is truly maturing and useful
third-party plug-ins will be picked up by distro packagers.
Where is git-imerge packaged?
I didn't see it on the archive the said Ubuntu box slurps from, but
I did not check all the other distros.
I will help you: it's not packaged anywhere.
Do you want to bet? Nah, you don't *ever* want to accept you were wrong,
even you clearly where.
...
This is what's going to happen: there won't be an official git-hg
package for *years*, if there is ever one. That is my prediction based
on all the available evidence, I am willing to stand by it and accept I
was wrong if it proves otherwise.
Are you willing to stand by your own decisions?
If I understand correctly, you have made and you do maintain some
packages and as an insider, you do not have to wait for an
outsider to step up to make remote-{hg,bzr} packages yourself.
No, you do not understand how packaging works. ArchLinux's AUR[1] is a
community-driven repository, anybody can package anything and put it
there. That doesn't mean people can simply do `pacman -S git-remote-hg`,
far from it.
It's a placeholder for *outsiders*, not official package maintainers.
I am an outsider in ArchLinux.
You may already have done so for your own use and told other people
about them, and others may have chosen to wait for you to push them to
distros instead of championing these tools by packaging them
themselves.
You clearly haven't tried to package anything for any distro. You can't
just champion packages for a distribution. You have to go through an
arduous process before becoming an official packager.
When you have such an influence on the outcome either way of your
choice, I do not see much value in such a bet.
If I champion these packages I would be making you win the bet. Why
would I do that?
But I actually think that we package what we want to use is a good
thing for programs whose primary audience is the software developer
types. The packagers are part of their audiences [*1*]. Because of
that, even if remote-{hg,bzr} do not get packaged for a long time, I
doubt that it tells us what you are stipulating. The only thing we
can infer would be that these programs did not interest the software
developer types to motivate them enough, and we wouldn't know why
they found the programs uninteresting. It may be because those who
have history in Hg prefer to interact with remote Git repositories
by pushing into and fetching from them using Hg tools than using Git
tools. It would not indicate useful tools fall through the cracks
if it were the case, would it?
Or it might mean that the people that would otherwise do that packaging
instead simply copy the single file needed manually.
Indeed I saw bzr-git that came from the Bazaar land packaged on the
box I mentioned, and its description sounded like it is meant to
work in such a way that allows Bazaar commits to be pushed to Git
repositories using a bzr tool.
By the way, I also saw git-mediawiki packaged from contrib/ in our
tree. I found it not very credible to say contrib/ is treated as a
single ball of wax without much value by packagers, and we need to
move the helpers up to core in order for them to be used more
widely after seeing that.
You are misconstruing what I said. I said *most* distributions treat
contrib as a ball of wax. And I said there were a few *exceptions* on
this ball of wax, like completions. remote-helpers are not part of these
exceptions (with the exception of git-bzr).
*1* I saw you called them wolves at least twice recently---where
does such a distrust come from?
It's a jungle out there, and it's every out-of-tree tool by itself. Most
of the tools on the contrib/ area would not survive if you throw them to
those wolves, and you know it.
[1] https://wiki.archlinux.org/index.php/Arch_User_Repository
--
Felipe Contreras
--
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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: ... Which will generate the integration instructions for you: % git reintegrate --cat base master merge jl/submodule-mv Moving a regular file in a repository with a .gitmodules file was producing a warning 'Could not find section in .gitmodules where path=filename'. merge ap/remote-hg-unquote-cquote It also has support for evil merges, so it should be perfectly usable for git.git maintenance. Yeah, it sounds like it is almost there. I think the infrastructure to maintain What's cooking could be updated to use these comments after merge instructions if I wanted to. I build two branches on top of 'master', one is called 'jch' and has a marker line somewhere that says '### match next' that is turned into an empty commit, and 'pu' that is built on top of the tip of 'jch'. The marker line is used to apply only an earlier part of the instruction stream to build 'jch' on top of 'master' on top of 'next' (i.e. base master in the above example will not be applied to hard-reset 'next' to match master) and stop there, and is meant to be a way to sanity check 'next' (which is made by repeated incremental merges on top of 'master' without rewinding) by comparing the ### match next commit between 'master' and 'jch' (which is made afresh from 'master' by taking only the necessary topics). They must match or I caught a possible mismerge on 'next'. I presume that the workflow can be mimicked by having another branch 'match-next' and building it on top of 'master', and then building 'jch' on top of it, and then building 'pu' on top of it. Then you should be able to play 'match-next' instruction on top of 'next' (provided that there is a way to tell it to replay on HEAD and ignore base and have merge instruction become a no-op when the branch has already been merged) Or have an option to specify a dynamic instruction sheet, so you can cat the instructions of 'match-next' and replace the base. However, I don't see the point of re-applying the branches for 'next' if you already know that 'next' and 'match-next' are the same. I would have two branches: 1) 'match-next' (or 'integration-next') that has the instructions to build 'next' on top of 'master', and 2) 'pu', which has the instructions to build 'pu' on top of 'next'. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Let's try this in a different way, as I sense there is a misunderstanding somewhere about your wish. ... No, I already said I do not want the code removed from v2.0, that's why I sent patches that simply added a warning, and I specifically said those were for 2.0. Yeah, I think there are mails crossing. I sent that different way way before I read your already said happened. So to make it clear, I now request that you do: 1) Remove all the code. Since my patches were removed from the list, here's an updated patch that applies on top of 'master' https://github.com/felipec/git/commits/up/remote/remove I'll do that, but just one thing to make sure---do you want the helper to exit with status 0? It doesn't matter; if the remote helper doesn't respond to the commands transport-helper exits with 128. 4) Re-add the following release note: * git push via transport-helper interface (e.g. remote-hg) has been updated to allow forced ref updates in a way similar to the natively supported transports I am not sure if this one is consistent with 1), as remote-hg will no longer be with the release. Remove '(e.g. remote-hg)', the rest still applies. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Johan Herland wrote: On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 05/19/2014 11:31 PM, Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Where is git-imerge packaged? I didn't see it on the archive the said Ubuntu box slurps from, but I did not check all the other distros. Michael, do you know what distro folks are doing with imerge? For the purpose of this thread, I do not follow distros, and I do not know is a perfectly acceptable answer, but it would be very relevant if your answer is I suggested these distros to include it, but so far they have been uncooperative and I haven't had much success. I haven't heard of any Linux distros that have git-imerge packages. I just searched the package archives for Debian, Fedora, Gentoo, and Arch without finding it. FWIW; someone has made an AUR package (a user-contributed Arch package recipe) for git-imerge: https://aur.archlinux.org/packages/git-imerge-git/ That doesn't say much. Anybody can put packages there, and it has a single vote, which suggests not many people use it (if any). -- Felipe Contreras -- 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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Or have an option to specify a dynamic instruction sheet, so you can cat the instructions of 'match-next' and replace the base. However, I don't see the point of re-applying the branches for 'next' if you already know that 'next' and 'match-next' are the same. The output from Reintegrate script (in 'todo') only lists the names of topic branches (or something like xx/topic~4 when the topic is not fully merged yet), and a topic branch may acquire a follow-up change (or two) on top (there is a machinery to see if xx/topic~4 is still valid in such a case and update the offset as needed). Rebuilding 'jch' on top of 'master' with the same insn sheet will then merge the updated topic branch in its entirety, and the new commits on the topic branch somehow needs to go to 'next' for the match next on 'jch' and 'next' to be in sync (in addition, updated 'master' must be merged to 'next', but that goes without saying). In other words, I already know that 'next' and match next are not the same, that they must become the same, and there needs a way to make them so. And that is done by re-running the insn sheet for 'jch' up to the match next mark, merging the topic that are not fully merged to 'next' while ignoring the ones that already are fully in 'next'. There could be a new --merge-missing option that takes the instruction sheet of an integration branch (e.g. 'match-next'), ignores the 'base' applies them in 'HEAD' but only when the topic branch isn't already in 'HEAD'. I'm not sure what would be the usefulness of using things like 'xx/topic~4'. -- Felipe Contreras -- 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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
On Tue, May 20, 2014 at 5:47 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I'm not sure what would be the usefulness of using things like 'xx/topic~4'. As a notation it is not very pretty ;-). Imagine that xx/topic is about a multistep introduction of a backward incompatible feature. The beginning part of the series up to xx/topic~4 are the step to start warning (i.e. will change---do this to keep the old one or do that to live in the future), xx/topic~3..xx/topic~1 are the next step to flip the default and still keep warning (i.e. have changed---do this to keep the old one or do that to live in the present), and the final xx/topic is the endgame where everybody lives with the new default with no warning, without having to know what the old default was. While the topic is being prepared for the next release, the insn sheet for 'jch' would have xx/topic~4 before match next marker, and then an entry for xx/topic~1 somewhere after it, and finally an entry for xx/topic (i.e. the tip, final commit). When the first step cooked well enough in 'next', selected entries of 'jch' insn sheet before match next ones are used to merge them to 'master' and the part up to xx/topic~4 (but not later patches on the topic branch) will be part of the upcoming release. You could simulate that with multiple branches stacked on top of each other, but there are times when keeping things together in a single branch is more handy. In restrospect, if I found xx/topic~4 too ugly, I might have instead made branches stacked on top of each other easier to manage, but having Reintegrate support in the middle of a branch was simpler. They are both OK solutions to the same problem, and I didn't have to solve it both ways ;-) Yes, I see how xx/topic~4 would be useful in the instruction sheet, I just didn't see it would be useful to generate that from an existing integration branch. After the explanation above I see how it could be useful to some people (though not all). I'll implement that. -- Felipe Contreras -- 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: [ANNOUNCE] Git v2.0.0-rc4
Junio C Hamano wrote: * The remote-helper interface to fast-import/fast-export via the transport-helper has been tightened to avoid leaving the import marks file from a failed/crashed run, as such a file that is out-of- sync with reality confuses a later invocation of itself. Really? Where are the patches for that? I think it's fair to say the way the remote-helpers and transport-helper has been handled for v2.0 has been a total disaster. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: - The always warn does not force update at the point of use, but it still does not help them to notice well before they try to use it for the first time after update; I don't understand this sentence. They will see a big fat warning every time they run the tool, of course they'll notice. Let me ask one question first, in order to avoid miscommunication, as I really want to get the first step for v2.0-rc4 in a concrete shape tomorrow. Do you think gradual transition worth pursuing or do you think it is a waste of time? If by gradual transition you mean place the contrib/remote-helpers in another directory before removing the code, I do think it's a waste of time, but I don't really care, as long as eventually stubs are put in place. I do not think it matters that much, but since you said you do not understand... What I meant was that when they update their Git (perhaps at the beginning of the week), the won't know they will now be running stale code. The warning comes only when they first run it (perhaps at the end of the week) to do some real work with a remote hg repository, which may not be a convenient time to do their sysadmin task. And the next time when they update their Git, they may have already forgotten about the warning. The ideal transition would be to somehow let them notice when they are in sysadmin mode. You can add such change in the release notes. Other than that I don't see what we could do. - Break the build attempts to help them notice when they try to update, not when they need to use the updated one right at this moment. This cannot be done. Renaming the directory will not break at the build time for those who have already did ln -s these scripts, of course, but it will break at the build time for others (i.e. those who cp), no? How many people copy the scripts every time they update Git? Not many I'd gather. They click that URL, and the are immediately greated with this: To enable this, simply add the git-remote-hg script anywhere in your $PATH: wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg chmod +x ~/bin/git-remote-hg Perfect. I did check the page when double-checking the URL while writing the README thing, and I did skim the page, but I must have missed it. We could add these two to the warning, then, to discourage people who see please visit this URL and say Yuck, I have no time for that without actually visiting. We could. Personally I don't see the point of making the warning any more annoying. The instructiosn are just one click away, and if they have no time for that, they can just ignore the warning. So to summarize, the following timeline is a full possibility: ... 2. add warning that is given every time the scripts are run and give the same instruction as in README. 3. (optional) cripple the script to make them always fail after showing the same warning as above. This is what I want, and I already sent the patches for; the scripts will be stubs. At this point you would have effectively removed the code, which what I want. I think explained why the step 3 would not help very much compared to the there is no script, only README remains endgame (and that is why it is marked as optional). Actually, you reminded me that a very short and easy-to-follow instruction is on the page referred to from README and the warnings, which means that this step would make even less difference compared to the endgame. I don't think I saw you explain why that is not the case and why we do want this step (and I cannot quite tell if you are aiming for more gradual transition that wants this step, or an expedited one that does not). I am fine with either way. To me the endgame is that the code is removed, and only stubs remain. What you do after that is up to you. In any case, I'd ask another question to avoid wasting time on miscommunication. By This is what I want, do you mean you want this step 3 also in v2.0, or do you mean you want 2 alone in v2.0 then step 3 some time later? I meant I want 3. eventually, hopefully for v2.1. You said your wish wasn't respected in another message, when I explained that I thought you did not want to disrupt v2.0 by insisting on removing these scripts and that was why I listed options that did not involve removal of the scripts. Are you saying that you wish you want to see them removed or crippled at v2.0? Changing your mind after discussion is perfectly fine, by the way. You did not specify those were only for v2.0. No, I don't want them crippled for v2.0. A warning should suffice. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo
Re: [ANNOUNCE] git related v0.3
Ævar Arnfjörð Bjarmason wrote: On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras felipe.contre...@gmail.com wrote: This tool finds people that might be interested in a patch, by going back through the history for each single hunk modified, and finding people that reviewed, acknowledged, signed, or authored the code the patch is modifying. It does this by running `git blame` incrementally on each hunk, and finding the relevant commit message. After gathering all the relevant people, it groups them to show what exactly was their role when the participated in the development of the relevant commit, and on how many relevant commits they participated. They are only displayed if they pass a minimum threshold of participation. It is similar the the `git contacts` tool in the contrib area, which is a rewrite of this tool, except that `git contacts` does the absolute minimum; `git related` is way superior in every way. The general heuristic I use, which I've found to be much better than git-blame is: 1. Find substrings of code I'm directly removing/altering, and functions I'm removing/altering 2. Do git log --reverse -p -S'substr' (maybe with -- file) for a list of substrings Yes, that is true, but it cannot be automated. When I'm lazy I just do `git related -cfull a..b`, which will show me the full patches so I can decide if they are relevant or not. One possibility would be to add an additional --keywords option to `git related`. Another would be to add an --interactive where each supposedly relevant patch is shown for the user to decide if it truly is. -- Felipe Contreras-- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: We could. Personally I don't see the point of making the warning any more annoying If we were giving the users a choice of no thanks, I'll keep using the obsolete one, then trying to be a low key and giving them a way to squelch with an advice.* config might make sense, but if we plan to remove/stub at as early as v2.1, I think annoyance is very much what we want, actually, because it clearly is the case that we do prefer users switching instead of waiting for v2.1. How does this sound? The patch below assumes the user has ~/bin in his PATH, which might not be the case. Personally I don't see the point of creating extra annoyance with instructions that might not work. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
% git fetch
WARNING: git-remote-hg is now maintained independently.
WARNING: For more information visit
https://github.com/felipec/git-remote-hg
searching for changes
no changes found
I don't think the situation is as simple as you claim. In many cases,
the first step before the ones you are mentionning are:
cd $git/contrib/remote-helpers
cp git-remote-{hg,bzr} somewhere/in/path
In many cases, but not all cases. In other cases they are:
ln -s $git/contrib/remote-helpers/git-remote-hg \
somewhere/in/path/git-remote-hg
Which has to be done only once, and not every time Git is updated.
They produces no warning if git-remote-{hg,bzr} exist with the warning,
but no such file or directory: contrib/remote-helpers if the directory
has been renamed or removed.
So? They'll get the warning the next time they try to use it, and their
workflow won't be interrupted, and the warning will be more useful than
No such file or directory.
When git-remote-{hg,bzr} are installed with a package manager, the fact
that they are part of Git's core or not is often irrelevant. For
example, Debian splits the git.git source into many packages, so a
Debian user will not see any difference between helpers included in
git.git or outside (e.g. I have to install the package git-svn if I want
to use git-svn).
Yet there is no git-hg. And I doubt Jonathan Nieder is going to package
the out-of-tree git-bzr, which as far as I know, is the only out-of-tree
package of these remote helpers in any distro.
--
Felipe Contreras
--
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
[ANNOUNCE] git reintegrate v0.3; manager of integration branches
Hi, git reintegrate is a helper tool to manage integration branches, it has all the options of other known tools. This is a rewrite of John Keeping's git-integration in Ruby, it has essentially the same features and passes all the git-integration tests, but it has more features. One feature that is missing from git-integration is the ability to parse existing integration branches. To give a try you can do: git clone https://github.com/gitster/git/ cd git git fetch -u origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*' git checkout pu git reintegrate --generate pu master Which will generate the integration instructions for you: % git reintegrate --cat base master merge jl/submodule-mv Moving a regular file in a repository with a .gitmodules file was producing a warning 'Could not find section in .gitmodules where path=filename'. merge ap/remote-hg-unquote-cquote A fast-import stream expresses a pathname with funny characters by quoting them in C style; remote-hg remote helper forgot to unquote such a path. merge jk/for-each-ref-skip-parsing merge jk/pack-corruption-post-mortem merge jk/reset-p-current-head-fix git reset -p HEAD has codepath to special case it from resetting to contents of other commits, but recent change broke it. ... It also has support for evil merges, so it should be perfectly usable for git.git maintenance. You can edit the instructions with `git reintegrate --edit`. The simplest way to begin an integration branch is with: git reintegrate --create pu master git reintegrate --add=branch1 --add=branch2 --add=branch3 To generate the integration branch run `git reintegrate --rebuild`, if there are merge conflicts, solve them and continue with `git reintegrate --continue`. Despite having more features, the code is actually smaller thanks to Ruby awesomeness. Enjoy. https://github.com/felipec/git-reintegrate Changes since v0.1: * Add support for empty commits * Add support for pause command * Update manpage * Add bash completion Felipe Contreras (26): Add copyright and license notices Fix EDITOR support with arguments Trivial style cleanup Improve command regex Add support for empty commits test: improve check_int() Add support for 'pause' command doc: rename manpage file doc: update options doc: add description doc: add missing instruction commands doc: cleanup . command Verify branches after parsing test: fix test names Remove unused statements Update README test: cleanup instruction sheets Update copyright notices Add bash completion build: add installation stuff readme: add installation instructions Add gitignore for documentation trvis: initial configuration travis: add verbosity test: add test-lib helper travis: remove Ruby 1.8 -- Felipe Contreras -- 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
[ANNOUNCE] git related v0.3
Hi, This tool finds people that might be interested in a patch, by going back through the history for each single hunk modified, and finding people that reviewed, acknowledged, signed, or authored the code the patch is modifying. It does this by running `git blame` incrementally on each hunk, and finding the relevant commit message. After gathering all the relevant people, it groups them to show what exactly was their role when the participated in the development of the relevant commit, and on how many relevant commits they participated. They are only displayed if they pass a minimum threshold of participation. It is similar the the `git contacts` tool in the contrib area, which is a rewrite of this tool, except that `git contacts` does the absolute minimum; `git related` is way superior in every way. For example: % git related master..fc/transport/improv Junio C Hamano gits...@pobox.com (signer: 90%, author: 5%) Felipe Contreras felipe.contre...@gmail.com (author: 25%, reviewer: 2%) Sverre Rabbelier srabbel...@gmail.com (author: 17%, acker: 2%, signer: 7%) Jeff King p...@peff.net (acker: 17%, author: 10%) Shawn O. Pearce spea...@spearce.org (author: 5%, signer: 2%, cced: 2%) Elijah Newren new...@gmail.com (author: 10%) In addition, it has an option to output the list of commits, instead of the contributors, which allows you to easily find out the previous changes to the lines your patches modify. % git related -c master..fc/transport/improv 99d9ec0 Merge branch 'fc/transport-helper-no-refspec' 67c9c78 transport-helper: barf when user tries old:new 0460ed2 documentation: trivial style cleanups 126aac5 transport-helper: fix remote helper namespace regression 21610d8 transport-helper: clarify pushing without refspecs a93b4a0 transport-helper: warn when refspec is not used 664059f transport-helper: update remote helper namespace c4458ec fast-export: Allow pruned-references in mark file ... Moreover, when sending patches for review, you can configure `git send-email` to use `git related` to find relevant people that should be Cc'ed: % git send-email --cc-cmd='git related' *.patch Compared to `git related`, `git contacts` has the following limitations: 1) Doesn't show the amount of involvement 2) Doesn't show the kind of involvement (reviewer, author) nor does it group people by their email address 3) Doesn't have the option to show the commit themselves 4) Doesn't have any options at all (--since, --min-percent) Cheers. https://github.com/felipec/git-related Changes since v0.1: * Fix compatibility with older versions * Add -clong option * Add manpage * Improve performance by grouping line ranges Felipe Contreras (12): Fix compatibility with Ruby 1.9 Add support for Ruby 1.8 Fix popen workaround Refactor blame parsing Pass multiple ranges to `git blame` test: add gitingnore file Add -clong option Add manpage build: add installation stuff readme: trivial updates test: add test-lib helper travis: initial configuration -- Felipe Contreras -- 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
[ANNOUNCE] git send-series v0.1
Hi, This tool allows you to maintain a patch series more easily. You can store the cover letter, the cc list, version of the series, and other metadata. By default it will use the currently checked out branch, and show you a template like this: version: cc: Subject Content. The first part is a YAML document with all optional fields, such as 'version', 'cc', 'to'. You can store any information you want using the YAML syntax. The second part, delimited by a blank line, is the cover letter. The first like will be used as the subject of the cover letter email, and the rest as the content of the email. Then standard tools will be used to send the emails: `git format-patch` and `git send-email`, which you must have configured before using this helper. In the end a custom ref will be created to save the current state of the branch. For example, if you want to see what was the status of your series of the branch 'feature-a' in version 2, you can use 'sent/feature-a/v2', for example to create an interdiff to see what changed between one version an the other. Enjoy. https://github.com/felipec/git-send-series -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: But that being said, this is Felipe's code. While we have a legal right to distribute it in v2.0, if he would really prefer it out for v2.0, I would respect that. I am fine with that. Are you? Because in two of the three options you list below you wouldn't be doing that. that does not refer to remove them at v2.0 (unconditional). It refers to If Felipe really wants for the removal for v2.0, I would respect that. And I saw you said you did not want to disrupt v2.0. If the options I listed all meant removal at v2.0, then I would understand your complaints, but that is not the case, so I am not sure what to make of that. It is a weird choice of semantics then. You said you would respect my wish, but your proposals did not follow my wish. The fact of the matter is that users cannot depend on packages any more. Maybe they'll be packaged, maybe not. If they are it will take a long time before they do. In the meantime they'll have to manually install them all all out-of-tree tools. I have always thought that distro packagers are the biggest ally us project leaders have. They locate useful pieces of software, massage them into a shape that fit their distro well and deliver what we write to their audience. Packaging stuff that are useful to their end-users is what they do best, and not leaving useful stuff unpackaged is in their best interest. Yet I bet a lot of open-source software is not actually packaged. That's the reason there's Python's pip, and Ruby gems. *If* your software is popular enough, then yes, packagers are your biggest allys, but if not, they aren't. Your statement makes it sound like they are incompetent lazy fools who do not know what is useful for their users. This sentence proves you have no idea how packaging is done. There is no comittee that hunts down packages that are useful for their users and assigns available packagers to those projects. Exactly the same way you don't assign Git developers tasks based on what is useful for our users. Each packager decides what project they package, just like every Git developer decides on what feature they work on. An obscure package might be packaged because a prominent Debian package maintainer likes it, and a much more useful and popular project might not be packaged simply because no package maintainer is interested in it. Exactly the same happens in Git; people work on relatively obsucre features such as ref transactions, because they are interested in them, and features much more useful for our users get ignored, because there's nobody (of relevance) championing them. When a popular project that is useful for the users is neglected for too long, what usually happens is that an outsider steps up and does the packaging, which then goes through a review process, and that outsider might become an official maintainer, and maybe start to package other things too. That's how packagers join the project. But nothing gets done if no ousider steps up. Excatly the same happens in Git; when a feature has been neglected for too long, an outsider comes and tries to implement it, go through a review process, and eventually start fixing other things too. So no, there's no comittee that decides what should be packaged, just like there's no committe that decides what Git features should be developed. It's incredibly alarming that you would think packagers in open source distributions would work any other way. And it's incredibly funny that you would label people working on such model as incompetent lazy fools for not knowing what is useful for their users, when it is *EXACTLY* the same thing you do in Git; you do not know what is useful for our users; you don't actually care; you just work on whatever you like to work on. It's even worst than that, because if somebody steps up to package a popular project, the package goes in, but when somebody steps up to implement a feature that improves our user-interface in Git; they get their knees shot. I find it disturbing to see such a distrust. Or am I being too naive to have too much faith in packaging folks? There is so much wrong with your mode of thinking and the blindness that you don't see what you yourself do that I don't even know where to begin. Yes you are too naive, on many levels. I checked the list of packages that depend on git on one of my boxes (it is a bit old Ubuntu). I of course expected that many of them are what comes from our tree split into their own niche tool packages (e.g. git-svn, git-gui, gitweb...), but I was pleasantly surprised to see many that I haven't even aware of being packaged. Of course, tig is among the packages that depend on us which I am happy to see. There are things of somewhat questionable value I saw in the list, of course. It is already 2014, and I feel fairly safe to feel that I can say without offending too
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: My suggestion to rename the directory without smudging the scripts was meant to be a step that can come before that step, and I think its necessity is debatable. It depends on how gradual a transition you want to give, and being always the more cautious type, I think having such a step will give packagers who pay attention to what they package and users who pay attention to what they install without packaging an early chance to notice and prepare. Immaginary packagers. - The always warn does not force update at the point of use, but it still does not help them to notice well before they try to use it for the first time after update; I don't understand this sentence. They will see a big fat warning every time they run the tool, of course they'll notice. - Break the build attempts to help them notice when they try to update, not when they need to use the updated one right at this moment. This cannot be done. But I am fine with an expedited transition schedule without the break the build step. That was an optional first step, because warn but still work state we must have before the endgame will give the users the choice of when to adjust anyway. I also thought about adding an extra step to have even more gradual transition, by the way. A step before the endgame will ship these scripts without anything but instruct and fail (this is not warn and fail, as it is too late warn, as the scripts are crippled not to work at this point). That will still force the user to update at the point when the user needs to use it, but seeing the instruction (e.g. run this curl command to fetch from this URL and store it in a file called git-remote-xx on your $PATH) that is easy to follow immediately would be better than seeing only a failure (i.e. remote-hg not found), having to go fish the README, visiting the GitHub pages and figuring out how to fetch and install the script, which would be what the user will get with README only, no scripts endgame. I don't see what's so complicated about this: WARNING: git-remote-hg is now maintained independently. WARNING: For more information visit https://github.com/felipec/git-remote-hg They click that URL, and the are immediately greated with this: To enable this, simply add the git-remote-hg script anywhere in your $PATH: wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg chmod +x ~/bin/git-remote-hg Clearly you haven't even bothered to visit the home pages of the projects you threw to the wolves. So to summarize, the following timeline is a full possibility: 1. (optional) break the build by renaming directory and add README. Include not just the repository URL but a blob URL and instruction to download via wget/curl. That won't break the build. 2. add warning that is given every time the scripts are run and give the same instruction as in README. 3. (optional) cripple the script to make them always fail after showing the same warning as above. This is what I want, and I already sent the patches for; the scripts will be stubs. At this point you would have effectively removed the code, which what I want. 4. Keep README and retire everything else. After you've removed the code, I don't care what you do, but I'd say you should remove the stubs after a long period of time. -- Felipe Contreras -- 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: bug: autostash is lost after aborted rebase
Karen Etheridge wrote: scenario: - edit some tracked files; do not add them to the index - git config rebase.autostash true - git rebase -i HEAD~3 (an autostash will be created) - delete the entire buffer and save/exit the editor - this will abort the rebase poof, the autostash is gone (it is not reapplied) -- it must be explicitly applied again via the SHA that was printed earlier. Yeah, I noticed this issue while rewriting `git rebase` in Ruby. I also noticed many other issues and inconsistencies that happen depending on what arguments you pass to `git rebase`. I'm in the process of writing a much more improved and consistent `git rebase` in Ruby with a different interface. Sadly it's still not ready. (please cc me; I am not subscribed to the list.) No need to say that, only on mailing lists that do Reply-To munging, and Git is not one of them. Cheers. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Jeff King wrote: On Sat, May 17, 2014 at 12:25:30AM -0500, Felipe Contreras wrote: I agree with the line of reasoning you laid out in your email, especially: What a shock. Please stop with these unproductive and rude comments. I am sorry, but the fact of the matter is that you *always* agree with Junio. I hadn't thought of the rename idea, and it would address the concerns I brought up. I do think obsolete is the wrong word, as it sends the wrong message. The helpers are not obsolete; it is our _copy_ of them that is. Originally you said you would respect if I wanted the code out for v2.0, I said I would like it out at some point, not necessarily in v2.0. Junio said he was fine with that, but the proposals above don't do that. Now it seems you are changing your mind and you are OK with the code remaining in. My concerns were with people not noticing the README. Removing the code entirely is the way I thought of to address that. Junio suggested another way, which I would also be fine with. And it seems like a friendlier way than removal to handle it for v2.0, if we are going to remove the code entirely post-v2.0. I don't see what is friendlier about this: % sudo pacman -Syu % cd ~/dev/my-hg-repo % git fetch fatal: Unable to find remote helper for 'hg' The users will scratch their heads, wonder what's going on, investigate themselves, and eventually they'll have to decide how to fix the issue properly, and how to report it. On the other hand: % git fetch WARNING: git-remote-hg is now maintained independently. WARNING: For more information visit https://github.com/felipec/git-remote-hg searching for changes no changes found You think that's less friendly? If you think so, I think you are totally biased towards whatever happens to be the opinion of one person. As before, if your desire is to have the code out for v2.0, then say so. I think we should respect such a request. As I said before, I do not wish the code to be removed for v2.0, I would like to have only a warning. Either way, do whatever you want for v2.0, it's your users you are hurting. But if I do not hear *from Junio* that the code will be removed entirely post-v2.0, hopefully replaced with stubs (which is obviously the most user-friendly thing to do), I'll do what I said I'll do. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
James Denholm wrote: Felipe Contreras wrote: James Denholm wrote: On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote: (...) I would venture to say you have never made a package in your life. And you have, Felipe? Let us see the years of experience you surely have in the field. As a matter of fact, yes I've written many packages, for Debian, Fedora, ArchLinux, and others. Even Windows installers. I'd hardly say that a few PKGBUILDs count. I've written some myself, not hard to do. Not hard, but Junio clearly hasn't done so. That said, if I had realised you were going to discuss such a trivial thing - _making_ packages rather than _maintaining_ them in a repo - I'd have dismissed your statement as mere idiotic vitriol. Why would anybody write packages and not maintain them? Of course I'm talking about maintaining packages. Do you honestly think that Junio has _never made a package?_ Never, on any of the systems he's ever touched, run makepkg or debuild or whathaveyou? I didn't say _build_ a package, I said _write_ a package. And of course I mean a significant package, that other people use, and as such needs to have some maintenance. I could be wrong here, but I'm fairly sure that Junio is a *nix software developer of some kind or another. You know, given that he's the maintainer of git, kinda might be the case. And I really doubt that any *nix dev, _anywhere_, could have _any_ sort of success without looking sideways once or twice at a package builder, given that pre-release homebrewing of expected packages is only an absolutely critical part of testing. Come on, man. Don't be silly. You are the one being silly, looking at a package builder doesn't give you any insight about the way packaging is done in distributions. If Junio has or hasn't done so is totally unimportant. You are just talking about completely irrelevant stuff, so I'm going to ignore your points about the matter. But that's a red herring. Even if was the worst packager in history, that doesn't make Junio's decision any more correct. No, but it would render your bizarre, tantrum-like accusations as generally baseless. I mean, I don't think anyone actually puts weight on them anyway, but hey, never hurts to shine a spotlight on nonsense. The fact that you think packagers of git would simply package git-remote-hg/bzr as well is pretty appalling. It's not an outlandish thought, in fact, I'd suggest it as probable - provided that they find the projects to be stable and of high quality. Do you want to bet? Not a betting man. However, ignoring that for a moment, I doubt we'd be able to agree on checks and balances for the case where git-remote-hg/bzr were rejected due to the code being of poor quality or unstable. So no, I won't bet, because you hold your own work and opinions as sacrosanct and infallible. It is not poor quality or unstable, Junio said so himself when he graduated them to the core. I suppose you don't trust Junio's opinion either. You, or someone else, might have to tap them on the shoulder and play nice to _ensure_ they know about them (after all, we all know that packagers _never_ read READMEs, do they), but you're capable of that, I'm sure. In my experience packagers scratch their own itches, and if git-remote-hg/bzr are not their itch, I don't see why any amount of nice poking would make them package them. Some other packager would have to do it, not the Git packagers. If there's a demand, Felipe, and the build process is sane, I can't see why they wouldn't. Your failure of foresight doesn't change what will actually happen in the future. Moreover, your argument that follows is a straw man, I argued that the original maintainer of the git package wouldn't do the git-remote-hg package, you didn't address that at all. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: Two announcements for their version 0.2 on the list archive are not quite enough to advertise them to their users. Signed-off-by: Junio C Hamano gits...@pobox.com --- * I am inclined to queue this for 2.0, and we would also need an update to the release notes as well. I am undecided about the revert I sent earlier in $gmane/248937; with or without it, that is just a contrib/ thing that is not well maintained inside our tree anyway. contrib/remote-helpers/README | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 contrib/remote-helpers/README NAK. diff --git a/contrib/remote-helpers/README b/contrib/remote-helpers/README new file mode 100644 index 000..72a2df4 --- /dev/null +++ b/contrib/remote-helpers/README @@ -0,0 +1,11 @@ +The remote-helper bridges to access data stored in Hg and bzr will be They are called Mercurial and Bazaar. +maintained outside the git.git tree in the repositories of its +primary author at: + +https://github.com/felipec/git-remote-hg +https://github.com/felipec/git-remote-bzr If this is formatted in asciidoc the links won't appear as links. Do it as I did: * https://github.com/felipec/git-remote-hg * https://github.com/felipec/git-remote-bzr +As a convenience, copies of the last-bundled version of these two +remote-helper bridges are kept here, but they may left stale. Users +are encouraged to visit the above authoritative repositories for the +latest versions to get involved in its further developments. 1) Most users will *never* see this README 2) Most packagers will never see this README 3) The people that do read this README will wonder *why* they are now maintained separately. Thanks for wasting all my hard work and sabotaging these projects. Just as a heads-up. I *will* complain about this publicly and my blog is visited by thousands of people. I am requesting one last time: 1) Add warnings *directly* into the tools themselves ASAP You didn't have any problems adding warnings for pre-v2.0 behavior that changed, nor did you have a problem adding the warning about the new zsh completion that moved out of the bash one. Why would you have a problem with this one? 2) Replace the tools with stubs that point to the right locations at the earliest convenience I already sent patches for both, and they were ignored. A failure to do both will result in a lack of visibility of the new projects, and a decrease in the quality the users of git.git contrib area's remote-helpers receive. I will consider that a deliberate attempt to make the new projects experience unnecessary hardship. -- Felipe Contreras -- 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 01/17] contrib: remove outdated README
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: == contrib vs. core == This is the only point relevant to contrib vs. core: - We may be painted in a hard place if remote-hg or remote-bzr take us to a position where the Git as a whole is blocked while it is incompatible with the other side. It will never happen. I already argued against it[1], multiple times. Essentially making the tests optional removes any possibility of blockage (pluse many more arguments). I already said that your It will never happen is a handwaving, and I already saw you argued against it. This is a red herring. Ignore the fact that it will never happen (which it won't), the next point remains a FACT, and you conveniently ignore it. ANSWER THIS: Essentially making the tests optional removes any possibility of blockage (pluse many more arguments). If the tests are optional, it doesn't matter if such change you are worried about happens or not (it won't). That's all there is to it. You made a wrong call. The tools *can* move into the core, and you said they couldn't. You may have been interested in contrib/core in the thread, but that does not prevent others from considering other aspects of the issue and different and possibly better solutions, which was to unbundle. That is IRRELEVANT to the fact that the tools *could* move into the core. You are using arguments (refuted) to demonstrate that the tools *might be better served* by being unbundled, in order to explain why they *could not* move into the core. That's a red herring. I was very confident back in that thread that the remote Hg bridge would not merely survive but would serve its users well as a standalone project, And you were wrong. There is a greater risk for these bridges to become unmaintained if we do not have them in my tree, and that would only hurt our users. But I did not see that particular risk at all for the remote Hg bridge. You have been very interested in maintaining it, and I don't think I ever had to prod you to respond to an issue raised on the list. It is an apples-and-oranges comparison to bring up git-svn/p4. In other words; if I had done a poorer job of maintaining these tools, they would have had a higher chance of moving into the core? If that's the case I would gladly stop any maintenance on them. Just say the word. I worked extremely hard so they could become part of the core, if being part of the core means I have to maintain them less, so be it. Besides, I want to see the git-core has the best thing among competing implementations for a specific niche subtask perception changed in the longer term so that it becomes natural for users to say something like For this particular task, there is no support in what comes with core (or there is a tool that comes with core to address similar issues but in a way different from what you want), and the go-to tool these days for that kind of task is to use this third-party plugin, Where are you saying that? Nowhere, that's where. Therefore every tool you unbundle, you are throwing to the wolves. Things like git imerge are helping us to go in that direction. I was hoping that the remote Hg bridge to be capable of becoming the first demonstration to graduate out of contrib/ that shows the users that is the case, not with just talk but with a specific example. You told me you wanted them to move to the core, you even moved them to the core. Then after years of work you change your mind, AGAINST my explicit will and with clear strong arguments AGAINST your apparently newly conceived idea. And idea you didn't explain clearly, and which you didn't give any chance of being refuted. In other words; an idea which very well COULD BE WRONG, and which very well could impact negatively many Git users. But you cannot even ponder the notion that you could possibly be wrong. After seeing these discussions, it tells me that the code is not fit for the core (also [*3*]), and I think there no longer is any reason for us to still talk only about contrib vs core. As you already said, you do not want to see them in contrib/, No, I want to see them in the core, and you said you did too. More importantly the vast majority of our users would want to see them in the core, therefore the discussion of contrib vs. core is pretty much relevant, but you don't care about them, do you? As I said, I will complain about this publicly _to our users_, which you are disregarding completely with this poorly thought decision and the subsequent ones. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Paolo Ciarrocchi wrote: On Fri, May 16, 2014 at 10:41 AM, Jeff King p...@peff.net wrote: But that being said, this is Felipe's code. While we have a legal right to distribute it in v2.0, if he would really prefer it out for v2.0, I would respect that. My understanding is that Felipe would prefer to keep it _in_ the git.git repository and eventually get it included in the core. That is correct. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Jeff King wrote: On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote: Two announcements for their version 0.2 on the list archive are not quite enough to advertise them to their users. I do not think this README nor a mention in the release notes will get their attention either, and many people (and packagers) will continue to use the stale versions forever until those versions go away. I would much rather _replace_ them with a README in the long run, and people will notice that they are gone, and then use the README to update their install procedure. For 2.0, I am hesitant to do that, though I do not have a problem with a README like this as a heads-up to prepare packagers for the future. I say hesitant because people may have been test-packaging 2.0.0-rc3 in preparation for release, and it will be annoying to them to suddenly switch. I agree, that's why I sent patches that: 1) Add a warning for v2.0 (which already has problems) So everything keeps working as well as in the release candidates, except a warning is introduced each time they do a fetch, push, or clone operation (use the remote-helpers) 2) Replace the tools with stubs So when they try to fetch, push, or clone, they get an error, and nothing else happens. There's an additional README for the people that want to read more, but if you don't put stubs, users might try to do what worked before: % git clone hg::http://selenic.com/repo/hello fatal: Unable to find remote helper for 'hg' It's much better to report: git-remote-hg is now maintained independently. For more information visit https://github.com/felipec/git-remote-hg But that being said, this is Felipe's code. While we have a legal right to distribute it in v2.0, if he would really prefer it out for v2.0, I would respect that. That's right, you have the legal right to distributed it. It is not my wish to disrupt v2.0, so I think adding a warning should be sufficient. Eventually I would prefer if they were not distributed, and replaced with stubs, not just because it would help the out-of-tree projects gather more visibility, but also because users would be better served by not having poorly maintained or unsynchronized code. Hopefully for v2.1. I would prefer to instrument the code with warnings, as that is the sort of thing a packager moving from -rc3 to -final might not notice, and shipping the warnings to end users who did not package the software in the first place will not help them. It is the attention of the packagers (and source-builders) you want to get. Of course that is all just my two cents, and is mostly predicated on there _being_ packagers of the contrib/ tools. It looks like there is a Debian package in RFP status, but I don't know if that is following the new release closely. And I don't know about other systems. As far as I understand most distributions don't do anything special with contrib, they just put everything under /usr/share. It is unlikely packagers will notice any change in one of the dozens tools in contrib, so they'll make no changes to the packages. So if the user did: % ln -s /usr/share/git/remote-helpers/git-remote-hg ~/bin/git-remote-hg The expectation would be that this keeps working even if the package doesn't change (it just adds a warning). Eventually it will stop working with an error, but the package still won't change. The distributions that do something special about remote-helpers (AFAIK it's only debian's git-bzr) would need to change, and sooner or later they will if there's only stubs there. Cheers. -- Felipe Contreras -- 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 01/17] contrib: remove outdated README
William Giokas wrote: On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote: This is a red herring. Ignore the fact that it will never happen (which it won't), the next point remains a FACT, and you conveniently ignore it. It may not block git being released, but as we can see from the recent patches that were needed to enable hg 3.0 support it can break and would have to follow *both* mercurial and git upstreams, not just git's. Indeed, it *can* happen, nobody has argued otherwise. The thing is how *likely* is it that it will happen again. As I said, in my experience developing this there has never been a single instance where such a change was required for *newer* versions of Mercurial. From what I can tell this is an exceptional situation. And it makes sense that when it happened, it happened exactly in the part where I wrote custom push() method. Mercurial has unstable API, but in unstable API's are part that are more stable than others. Generally the higher level the API is, the more stable it tends to be. The Linux kernels makes an even weaker promise of API stability than Mercurial does, but even then, the higher the API you use, the less likelihood you have of breakage. I've seen this in practice many times. And it does makes sense that for practical purses Mercurial would try to avoid changes in the higher level API, which require changes in many places, and not so much in lower level APIs, which might require a few changes here and there. The problem is that in order to replace the higher level API push(), I had to use the lower level API, and that's where the breakage happened, it was not unlikely. It is unlikely that another change in this particular API will happen soon, but not extremely so. As I already explained, this can be mitigated by contacting the Mercurial developers and figure out if their high-level API can accommodate the kind of functionality git-remote-hg needs. Maybe by adding a new option, or maybe by adding another high-level helper function. Either way, I doubt Junio is qualified at all to discern between the likelihood of future Mercurial API changes that would break git-remote-hg. He has seen one, and he is wrongly assuming there are more to come. After thinking about this for a while, I would have to agree with Junio That it's better if a bridge between to actively developed applications not be coupled to one. How exactly would it be better? If you concede that the Git release wouldn't be affected, then assuming a hypothetical future where git-remote-hg is bundled, and we have a Mercurial API breakage, we would have: Git v2.5 fail, Git = 2.5 get the fix If we unbundle, we have: git-remote-hg v0.5 fail, git-remote-hg = v0.5 get the fix What is the big difference? I presume you would say that git-remote-hg v0.5 could be released earlier than Git v2.5, so the users would get the fix faster. However, that is not the case if the breakage is detected *before* the Mercurial release happened, in which case both Git v2.4 and git-remote-hg v0.4 would already contain the fix, and it doesn't matter much which was released first. The problem is that I wasn't doing the continuous integration with the development version of Mercurial, which I am now, so these kind of exceptional issues would be detected earlier. Moreover, it is likely that the distribution package for git-remote-hg would not be maintained as rigorously as the Git package. It might not even be part of the official packages (e.g. ppa or AUR). Therefore, even if the git-remote-hg v0.4 happens earlier, it might reach the users later. Furthermore, we are talking about a single script that can be installed by hand easily. The users can simply override their distribution's script and install by hand the latest version, as many have been doing already when they report errors and want the latest fix. Even more. git-remote-hg will not have maintenance releases, if an exceptional issue like this happens, it can be back-ported to Git v2.3.x, Git v2.2.x, and so on. It seems like a very feeble argument in favor of unbundling *at best*. This does not mean that I think git-remote-hg is not of a quality to be in the git.git tree, but it is simply a fact of development and stability. If git's remote-helper stuff changes but mercurial doesn't, we're fine because, having seen the speed of your fixes, we would have a fix before the next release without a doubt. However, if mercurial changes, like it just did, then git itself would need to make a release to have it actually work with the newest release. That is not true. In this particular case, because I didn't build against the development version of Mercurial, yes, but not for the future. If I had the tests I have in place now, we would have detected the change earlier, and Git v1.9.2 would *already* contain the fix, and when Mercurial v3.0 got released we wouldn't need to make a Git release in response (same goes for unbundled
Re: [PATCH v2 01/17] contrib: remove outdated README
William Giokas wrote: On Fri, May 16, 2014 at 05:21:36AM -0500, Felipe Contreras wrote: How exactly would it be better? If you concede that the Git release wouldn't be affected, then assuming a hypothetical future where git-remote-hg is bundled, and we have a Mercurial API breakage, we would have: Git v2.5 fail, Git = 2.5 get the fix If we unbundle, we have: git-remote-hg v0.5 fail, git-remote-hg = v0.5 get the fix What is the big difference? It's a matter of scope and where the releases happen, that is all. Of course the core vs. out-of-tree question is a matter of where the releases happen. The question here was: in which way is out-of-tree a better place? If it's a matter of scope, that is; should a foreign vcs interface tool be bundled in the Git core? Then that question applies not only to git-remote-hg/bzr, but also git-p4, git-cvs, git-svn, and others. The answer to the first question seems to be; it's not at all clear (in fact there doesn't seem to be any valid argument in favour of out-of-tree). The answer to the second question is; we are not asking that question right now (for the moment foreign vcs tools should remain part of the Git core). I started the graduation series by saying there doesn't seem to be any good reason not to, and Junio agreed. Now Junio doesn't agree, but it's till the case there's no good reason not to. -- Felipe Contreras -- 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] Always auto-gc after calling a fast-import transport
Stepan Kasal wrote: From: Johannes Schindelin johannes.schinde...@gmx.de Date: Mon, 9 Apr 2012 13:04:35 -0500 After importing anything with fast-import, we should always let the garbage collector do its job, since the objects are written to disk inefficiently. This brings down an initial import of http://selenic.com/hg from about 230 megabytes to about 14. In the future, we may want to make this configurable on a per-remote basis, or maybe teach fast-import about it in the first place. Actually I tested this patch and it makes no difference. Before and after the patch the repository size is exactly the same (and so is the run-time). That is because after the initial import there are no loose objects, every thing is into one big pack, so `git gc --auto` does nothing. Could anyone on the list try to reproduce the performance problem that triggered this? I'd say this patch is not doing anything in recent versions of Git. -- Felipe Contreras -- 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: [msysGit] [PATCH] transport-helper: add trailing --
Johannes Schindelin wrote: Hi, On Thu, 15 May 2014, Stepan Kasal wrote: From: Sverre Rabbelier srabbel...@gmail.com Date: Sat, 28 Aug 2010 20:49:01 -0500 [PT: ensure we add an additional element to the argv array] IIRC we had problems with refs vs file names. Actually I tried to push a file named refs/heads/master and I saw the issue. I'd say it's a very rare issue, and I don't see how it could be triggered with normal files since all the ref names have the full name. That being said I don't think it would hurt. -- Felipe Contreras -- 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] config: be strict on core.commentChar
Nguyễn Thái Ngọc Duy wrote:
We don't support comment _strings_ (at least not yet). And multi-byte
character encoding could also be misinterpreted.
The test with two commas is deleted because it violates this. It's
added with the patch that introduces core.commentChar in eff80a9
(Allow custom comment char - 2013-01-16). It's not clear to me _why_
that behavior is wanted.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
config.c | 8 ++--
t/t7508-status.sh | 6 --
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/config.c b/config.c
index a30cb5c..05d909b 100644
--- a/config.c
+++ b/config.c
@@ -826,8 +826,12 @@ static int git_default_core_config(const char *var,
const char *value)
if (!strcmp(var, core.commentchar)) {
const char *comment;
int ret = git_config_string(comment, var, value);
- if (!ret)
- comment_line_char = comment[0];
+ if (!ret) {
+ if (comment[0] !comment[1])
+ comment_line_char = comment[0];
+ else
+ return error(core.commentChar should only be
one character);
+ }
Small nit:
if (ret)
return ret;
if (comment[0] !comment[1])
comment_line_char = comment[0];
else
return error(core.commentChar should only be one character);
--
Felipe Contreras--
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] remote-helpers: point at their upstream repositories
, then report the problem to the packagers. Then they might include the obsolete directory, or they might decide not to. * The packagers that pick up from contrib/remote-helpers and arrange the scripts to be on user's PATH will find their build broken, because they are no longer where they expect them to be. They will notice obsolete(or graduated), and read README. - They can choose to pick them up from obsolete, perhaps for expediency, perhaps for their change aversion, but that will not last once we grabbed their attention, and they will switch their upstream in some later release once such a choice makes them feel dirty enough. - They can choose to switch their upstream right now in response to the breakage. That's not how packaging works. Ask your friend Jonathan Nieder, the packager of Git for Debian, if he would be interested in maintaining a new git-remote-bzr package. My guess is that he wont. Maybe he would, but he can assure you that other packages wont. The fact of the matter is that users cannot depend on packages any more. Maybe they'll be packaged, maybe not. If they are it will take a long time before they do. In the meantime they'll have to manually install them all all out-of-tree tools. I would say that the options I see are these three, and I would rank the warn every time as less helpful to end-users: - rename contrib/remote-helpers to contrib/obsolete-remote-helpers and add README to point at the upstream. I don't like this. This would only reward lazy packagers, it wouldn't be clear to the user what happened at first, and even after they use the new place, they wouldn't be disserviced by that code. - remove contrib/remote-helpers scripts and add README. Again, the user will still see an unhelpful message at first. I guess it wouldn't be as bad as the option 1, but it's not as good as the patch I proposed where they are replaced with stubs (plus a README). - warn every time the user runs the scripts. I suggested this, but only as a temporary measure. I am surprised that we are talking about the ways to proceed, and which ways would affect the users less, and what would be the repercussions. In particular, your obvious disconnection from the way packaging is done, I would venture to say you have never made a package in your life. The fact that you think packagers of git would simply package git-remote-hg/bzr as well is pretty appalling. You should have thought about all this *before* making your stupid decision. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Jeff King wrote: I agree with the line of reasoning you laid out in your email, especially: What a shock. I would say that the options I see are these three, and I would rank the warn every time as less helpful to end-users: - rename contrib/remote-helpers to contrib/obsolete-remote-helpers and add README to point at the upstream. - remove contrib/remote-helpers scripts and add README. - warn every time the user runs the scripts. I hadn't thought of the rename idea, and it would address the concerns I brought up. I do think obsolete is the wrong word, as it sends the wrong message. The helpers are not obsolete; it is our _copy_ of them that is. Originally you said you would respect if I wanted the code out for v2.0, I said I would like it out at some point, not necessarily in v2.0. Junio said he was fine with that, but the proposals above don't do that. Now it seems you are changing your mind and you are OK with the code remaining in. Do what you will, but I already told you what I will do in response. -- Felipe Contreras -- 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] transport-helper: add trailing --
Stepan Kasal wrote: From: Sverre Rabbelier srabbel...@gmail.com Date: Sat, 28 Aug 2010 20:49:01 -0500 [PT: ensure we add an additional element to the argv array] Signed-off-by: Stepan Kasal ka...@ucw.cz --- Hi, this patch was present in msysgit from Mar 2012. Do you like it? Adding an extra '--' would make sense if we do something like 'git fast-export $stuff master' and there was a file named master. However, we do 'git fast-export $stuff refs/heads/master', which case the '--' is a no-nop *always*. It doesn't hurt to add it though. I think. -- Felipe Contreras -- 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] Always auto-gc after calling a fast-import transport
Stepan Kasal wrote: From: Johannes Schindelin johannes.schinde...@gmx.de Date: Mon, 9 Apr 2012 13:04:35 -0500 After importing anything with fast-import, we should always let the garbage collector do its job, since the objects are written to disk inefficiently. I'm not sure how slow `git gc --auto` is with a totally unpacked repository, but it guess it will be slow enough that some people might not want to do the gc initially. Not many people have complained about the size of the repoitory after cloning, so I think it should be OK to let users call `git gc` when they wish to. -- Felipe Contreras -- 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] contrib: remote-helpers: add move warnings (v2.0)
Ronnie Sahlberg wrote: On Tue, May 13, 2014 at 4:37 PM, Felipe Contreras felipe.contre...@gmail.com wrote: But if I have to adjust for saying that (which was true), what do you say to Junio for saying this? (which was not) I know I shouldn't but I will respond anyway. The problem is about you and your behaviour. Not Junio or anyone else. Right. So when I say something moderately aggressive (but true), I'm the problem, when Junio says something worst (and false), he is not. Got it. -- Felipe Contreras -- 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 01/17] contrib: remove outdated README
Philippe Vaucher wrote: I have had patches and contributions rejected in the past, sometimes rudely. Same has happened to many others, if you contribute long enough, it is pretty much guaranteed that it will happen to you. Maintainer is wrong, or you are wrong, or someone is just having a bad day. This is not about a couple of patches I worked in a weekend being rejected. This is about the work I've been doing since the past two years almost like a full-time job dropped to the floor with no explanation at all. I started with the expectation that they were going to move to the core, because Junio said so, then he changed his mind and didn't want to explain his reasoning. It's not just a bad day. Here are two posts where Junio and Michael Haggerty explain the reasoning to you: - http://article.gmane.org/gmane.comp.version-control.git/248727 - http://article.gmane.org/gmane.comp.version-control.git/248693 Basically, in your case it boils down to your social manners. You are not paying attention at all. Junio did *not* use my social manners as a reason to block the graduation, nor the quality of the code, he used a *TECHNICAL* reason. Prior to his decision there were no complaints about my manners since I returned. It was his *TECHNICAL* decision that triggered this. Junio never explained his *TECHNICAL* reason, and Michael Haggerty simply said there are good technical arguments for and against moving git-remote-hg out of contrib, that was all his explanation for the *TECHNICAL* reason. You, and other people, are using the behavior I displayed *AFTER* Junio made his *TECHNICAL* decision as the cause for his decision not to graduate. That's a wrong direction fallacy. -- Felipe Contreras -- 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] contrib: remote-helpers: add move warnings (v2.0)
Junio C Hamano wrote: So at this point, I would have to say that the users of remote-hg is taken hostage by its author. The users of remote-hg are being affected negatively *because* of your decisions. You have the power to help them by answering a simple question. Yet you refuse to do that. It's all on you. -- Felipe Contreras -- 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/4] remote-hg: more improvements
that the government is spying on everyone. Nah! that's haaard. Let's obliterate the little guy. -- Felipe Contreras -- 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] contrib: remote-helpers: add move warnings (v2.0)
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: So at this point, I would have to say that the users of remote-hg is taken hostage by its author. The users of remote-hg are being affected negatively *because* of your decisions. You have the power to help them by answering a simple question. Yet you refuse to do that. It's all on you. That is exactly what I would call taking users hostage. I think I already answered that one question: in $gmane/248853 with: You certainly are acting like one, aren't you? Do you need more? You know full well this is not the question I asked you repeatedly. Stop trying to spin the readers. I asked you here: http://article.gmane.org/gmane.comp.version-control.git/248683 And here: http://article.gmane.org/gmane.comp.version-control.git/248348 And here: http://article.gmane.org/gmane.comp.version-control.git/248368 I made it clear you were not answering the qustion here: http://article.gmane.org/gmane.comp.version-control.git/248685 And here: http://article.gmane.org/gmane.comp.version-control.git/248701 And here (apparently deleted mail): 1400013572-30232-1-git-send-email-felipe.contre...@gmail.com And probably many other times. And I will ask you once again. Please answer this *one* question: 1) Please clarify the reason why you blocked the graduation of remote helpers. Please give the full rationale and do not point to other mails, or other peoples' explanations. If necessary attach such explanations to your full reasoning. This is the *one* question you have refused to answer over and over. -- Felipe Contreras -- 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 01/17] contrib: remove outdated README
Jeff King wrote: On Wed, May 14, 2014 at 02:35:08PM -0500, Felipe Contreras wrote: Prior to his decision there were no complaints about my manners since I returned. It was his *TECHNICAL* decision that triggered this. There have been several complaints about your behavior since you returned[1,2,3,4], [1] http://article.gmane.org/gmane.comp.version-control.git/247108 This is not a complaint, you are merely saying you are not interested in discussing with me without mentioning any bad behavior at that time. And this is not related to remote-hg/bzr. [2] http://article.gmane.org/gmane.comp.version-control.git/247121 This is a complaint without pointing out what are the specific instances of bad behavior, present or past. [4] http://article.gmane.org/gmane.comp.version-control.git/247168 This is not a complaint about bad behavior. Unless you think making a bet is bad behavior. And this is unrelated to remote-hg/bzr. [3] http://article.gmane.org/gmane.comp.version-control.git/248000 This is a complaint about a factual statement, a prediction about the future that turned out to be true. Unflattering factual predictions can hardly be considered bad behavior And this is unrelated to remote-hg/bzr. I have not paid all that close attention to this remote-hg contrib argument. Maybe you are 100% right and Junio is wrong and lying and cannot back up his decision, but somehow needs to cover it up through rhetoric. But that does not at all match my past experiences with Junio's behavior. The fact that something hasn't happened in the past doesn't mean it's not happening right now. I am still waiting for Junio's answer to *one* question. If your expectation about Junio is correct, it should be easy for him to say Felipe is wrong, here's where I explained in full my rationale of the technical issues that triggered my decision to demote the remote helpers, and as you can see, the importance of the decision is well matched by the detail of my explanation. But he is not doing that, is he? It would be easy for him to do that, why isn't he doing so? You are giving him a free pass. I can understand that it hurts to be called a troll. I really do believe you are trying your best to improve git. But I hope you also understand that in terms of the time and emotional drains on other participants, from our perspective interacting with you is quite similar to interacting with a troll. Yes, I can understand that, and I would understand if Junio said I was acting *like* a troll. But he unequivocally said I was a troll, even when I asked for clarification. Maybe that's acceptable to you. That's where I draw the line. Your continued arguing on this topic does not seem like it is going anywhere, I'm not arguing on this topic any more. I gave up on Junio trying to answer my *one* question. The remote helpers will not graduate because Junio said so, and he didn't explain his reasoning. That's an unfortunate fact. All I'm trying now is to move foward, by: 1) Add a warning about the new location of remote-helpers (Junio chose to argue instead) 2) Remove the remote-helpers and replace them with warning stubs (Somehow the patches didn't reach the mailing list) 3) Make sure everything is in place for users and packagers to use the new location (it can't never be as good as graduating to the core) (The fact that Junio is preventing 1) and 2) doesn't help) Additionally: 4) Correct any misconceptions in the lingering threads and I believe is wasting time and hurting the atmosphere of the list. Please stop. Tell other people to stop. I am merely replying to misconstrued conceptions. If other people stop, so would my replies. I am not going to let the record about such an important decision be tainted by these misconceptions. [5] Even though you were previously asked to leave, I believe people on the list gave interacting with you a fair shot in the past month or two. And we somehow still ended up at the same place. That's just my perception, of course. I'd invite anybody watching to form their own opinions. And that's entirely Junio's fault for making a haste decision, and giving no rationale about it. Given all the time I've spent on these tools, I wasn't willing to let my work be threated like crap by Junio. I deserved an explanation, and if he wasn't going to give one, I'd rather leave the project trying to get one (even if that meant behaving in a way other people considered bad). And BTW, I still think git-archimport and git-quiltimport should be demoted from the core, and I think the contrib area should be cleaned up, many of the tools removed, and others maintained out-of-tree. Do not think I sent those patches to troll. Cheers. P.S. While we disagree on many topics, I do appreciate the fact that you are never condescending and try to be honest, and when it becomes difficult to do that, you explain so and leave the discussing. Never letting
Re: [PATCH 0/4] remote-hg: more improvements
David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: Philippe Vaucher wrote: [...] Do you feel Felipe is in control of what you label bad behavior? Do you feel you are in control over how you react to his behavior? I feel that Felipe cannot control this (or decided not to), I am pretty much in control of my behavior. Those who know me personally know that I *never* get angry. You are missing the point. The point is not what effect your behavior has on you but what it has on others. If me saying I do not believe in God has a negative effect on Mark, your answer seems to be do not tell Mark the truth. If Mark was a co-worker and I had no option but to interact with him, I would probably do something along those lines if possible. But if Mark was a member of an open source project, I do have an option and I'd rather tell it like it is. If Mark has a problem with that, I can always avoid Mark, or just leave the project (say if Mark was the maintainer). In both cases Mark is wrong. I do understand that most people would rather comprimise their beliefs in order to win penguing points. I'm not that way. If I can't speak my mind in an open source project where I'm contributing my time *for free*, I do not want to be part of that project. It's the project that's wrong, not me, and it's the project that looses, not me. -- Felipe Contreras -- 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/4] remote-hg: more improvements
David Kastrup wrote: Shouting your God is an imaginary shithead every time you see Mark There's no point in discussing with an unconstructive person as you. I've made my point, you are just talking nonsense. Every rational person on this list knows that if I wanted to, I could be much more offsensive and insulting. -- Felipe Contreras -- 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 01/17] contrib: remove outdated README
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio never explained his *TECHNICAL* reason, and Michael Haggerty simply said there are good technical arguments for and against moving git-remote-hg out of contrib, that was all his explanation for the *TECHNICAL* reason. I am not interested in distinction between technical and social that much. The points that were raised in the thread started by John Keeping, and some of the points that came to my mind while on that thread, even though I may not have mentioned in *that* thread, that affected the way *I* thought about the issue are these (not exhaustive): Let's be clear; the discussion in that thread was contrib vs. core. Most of the points you mention below are not related to that. == contrib vs. core == This is the only point relevant to contrib vs. core: - We may be painted in a hard place if remote-hg or remote-bzr take us to a position where the Git as a whole is blocked while it is incompatible with the other side. It will never happen. I already argued against it[1], multiple times. Essentially making the tests optional removes any possibility of blockage (pluse many more arguments). This is the crux of the problem, because as far as I know, it's the only suppsed argument against contrib vs. core. An argument very weak and already refuted. I repeatedly asked Junio to clarify his reasoning, because it can't possibly be that this is the only reason, and that's the full rationale. If this is it. Then it's very clear: core wins. == bundle vs. unbundle == The rest of the arguments are *not* related to contrib vs. core. They are a red herring, but I'll answer anyway. - A remote-helper has to depend on both sides. Keeping it in either contrib/ or in core, as opposed to unbundling, may make things easier for the remote-helper maintainer, because at least it would allow the helper to advance with Git in lock-step (but I never heard that you do not prefer unbundling for this reason). I am the maintainer I told you that wasn't the way to go and I'm telling you again. - In a longer term, a properly maintained remote-helpers should work with wide varieties of Git and the remote system versions anyway, so unbundling would be logically the more correct thing to do. I already argued against this (and so did you[2]); the same argument applies to git-p4, git-cvs, git-svn, git-archimport, etc. We are not seeing efforts to unbundle those. Why? Because it would be detrimental to our users, for many reasons, starting by the fact that there's no good visibility of out-of-tree tools. - Unbundling would make it less easier to use the remote-helpers for people who are used to keep up with my tree and pick them up from contrib/, but that is a tiny minority these days. Most people use what distros package, and the distros that already package contrib/ remote-helpers will switch their upstream to unbundled repositories in order not to regress their packages for their users. That is not true. Distributions mostly put everything in contrib/ into /usr/share/git without much care about what does what. If something is missing the users might notice, but the packages wouldn't. It would require different packagers that care to create the new packages, if it happens at all. The new packages might be created in a ppa, or some other third-party place not very visible. If proper packages manage to end up in the main distribution repositories, it will take a long time, and in the meantime users will be left with a bad taste in their mouth. It will take even more time if these tools remain in contrib/ because nobody will notice anything, until bugs start to pile up. - On the other hand, unbundling will make it easier for the the end-users (both the ones who are fed distro packaged versions and the ones who build from the source _and_ who overcome the less easier because now they have to pull from not just me but from the unbundled places inconvenience) to keep up with the leading/bleeding edge, because the remote-helpers do not have to freeze at the same time other parts of Git are frozen before the release, and users and distros can pick improved remote-helpers up and even mix and match, when they have some other reason that prevents them from updating Git itself. Users don't care much about being on the bleeding edge. They care that their tools keep working and in the same way. For that it's more important that the maintainers have as many eyes as possible no the patches. And sending the patches on git@vger.kernel.org has certain helped in that regard. You want to take that away from them. Additionally, they care that the tools are easy to set up. Being able to clone Mercurial repositories from an out-of-the-box version of Git is much more important to them than being on the bleeding edge. Plus this also applies got
Re: [PATCH v2 01/17] contrib: remove outdated README
Martin Langhoff wrote: On Wed, May 14, 2014 at 7:28 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Do we no longer have to be afraid of that? WHY? All the responses from the contrib cleanup patches seem to suggest that pretty much *everyone* The responses also been clear in that you are toxic. You are replying to a mail about a *TECHNICAL* reason. Junio made a good job of concentrating on the technical side. If you are not willing or unable to concentrate on the technical side, reply to something else, you are just tainting the discussion. If you are willing to concede that Junio made a wrong technical decision, I'd be willing to discuss about the social issues that happened *after* that with you. But I doubt you are interested in doing either one of those, so I don't don't see what's the point of you even replying. -- Felipe Contreras -- 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/2] wincred: avoid overwriting configured variables
On Tue, May 13, 2014 at 1:34 AM, Erik Faye-Lund kusmab...@gmail.com wrote: On Tue, May 13, 2014 at 8:01 AM, Stepan Kasal ka...@ucw.cz wrote: From: Pat Thoyts pattho...@users.sourceforge.net Date: Wed, 24 Oct 2012 00:15:29 +0100 Signed-off-by: Pat Thoyts pattho...@users.sourceforge.net Signed-off-by: Stepan Kasal ka...@ucw.cz --- contrib/credential/wincred/Makefile | 4 1 file changed, 4 deletions(-) diff --git a/contrib/credential/wincred/Makefile b/contrib/credential/wincred/Makefile index 39fa5e0..e64cd9a 100644 --- a/contrib/credential/wincred/Makefile +++ b/contrib/credential/wincred/Makefile @@ -1,9 +1,5 @@ all: git-credential-wincred.exe -CC = gcc -RM = rm -f -CFLAGS = -O2 -Wall - Would it be better to set these if not already set, i.e: -CC = gcc -RM = rm -f -CFLAGS = -O2 -Wall +CC ?= gcc +RM ?= rm -f +CFLAGS ?= -O2 -Wall instead? Set by whom? If it's by the environment you should be running 'make -e'. -- Felipe Contreras -- 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] contrib: completion: fix 'eread()' namespace
Otherwise it might collide with a function of the same name in the
user's environment.
Suggested-by: SZEDER Gábor sze...@ira.uka.de
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-prompt.sh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 96b8087..853425d 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -270,7 +270,7 @@ __git_ps1_colorize_gitstring ()
r=$c_clear$r
}
-eread ()
+__git_eread ()
{
f=$1
shift
@@ -339,9 +339,9 @@ __git_ps1 ()
local step=
local total=
if [ -d $g/rebase-merge ]; then
- eread $g/rebase-merge/head-name b
- eread $g/rebase-merge/msgnum step
- eread $g/rebase-merge/end total
+ __git_eread $g/rebase-merge/head-name b
+ __git_eread $g/rebase-merge/msgnum step
+ __git_eread $g/rebase-merge/end total
if [ -f $g/rebase-merge/interactive ]; then
r=|REBASE-i
else
@@ -349,10 +349,10 @@ __git_ps1 ()
fi
else
if [ -d $g/rebase-apply ]; then
- eread $g/rebase-apply/next step
- eread $g/rebase-apply/last total
+ __git_eread $g/rebase-apply/next step
+ __git_eread $g/rebase-apply/last total
if [ -f $g/rebase-apply/rebasing ]; then
- eread $g/rebase-apply/head-name b
+ __git_eread $g/rebase-apply/head-name b
r=|REBASE
elif [ -f $g/rebase-apply/applying ]; then
r=|AM
@@ -376,7 +376,7 @@ __git_ps1 ()
b=$(git symbolic-ref HEAD 2/dev/null)
else
local head=
- if ! eread $g/HEAD head; then
+ if ! __git_eread $g/HEAD head; then
if [ $pcmode = yes ]; then
PS1=$ps1pc_start$ps1pc_end
fi
--
1.9.3+fc1
--
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 v1 1/2] Remove 'git archimport'
Martin Langhoff wrote: On Thu, May 8, 2014 at 9:33 PM, Felipe Contreras felipe.contre...@gmail.com wrote: No updates since 2010, and no tests. NAK. IMHO, this is quite unfriendly. Is this removal based on your opinion, or Junio's position (or consensus from maintainers from the list)? If there is a clear consensus or direction for old code such as this, please let me know (but copy martin.langh...@gmail.com, not just my very old address!). This tool doesn't even work anyway. Why do we want to distribute code that doesn't work? -- Felipe Contreras -- 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: Error using git-remote-hg
Junio C Hamano wrote: It is time to catch regressions by asking wider audiences who do not normally follow Git development (i.e. those who are not the ones that follow 'master' and rebuild/install it once or twice a week for their daily use). And you have one of those regressions in Git v2.0. My understanding is that versions of remote-hg shipped with all versions of Git did not work with Hg 3.0, so 58aee08 is not a regression fix at all. Is working with Hg 3.0 at such a high priority that it makes it worth to slip the whole release schedule by a few weeks? I do not think so. It is in the contrib/ area, you don't need to slip the schedule for something that is not part of the core. Moreover, it *CANNOT POSSIBLY INTRODUCE REGRESSIONS*. I bet my reputation on that. Some time ago I asked you to trust my judgement and introduce changes late into a release, and I told you there wouldn't be any problems, and to trust me. If any problems arise I wouldn't be asking for something like that again. Well, I was right, there were no problems. And I'm right this time too, there would be no issues. But you don't care about reality and facts. You don't care about the intent behind the release-candidates rule, you would rather follow the rule blindly. Regarding the commit in question, I asked Felipe a question and never got a straight answer. Nor will you get one, because thanks to your stupid decision for which you still haven't provided a rationale, the git-remote-hg and git-remote-hg are no longer maintained in git.git. If you hadn't made such a move, you would have your answer, the fix would be properly explained, the regression fixed, and all your users would be happy that git-remote-hg and git-remote-bzr get distributed by default. -- Felipe Contreras -- 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 v1 1/2] Remove 'git archimport'
Martin Langhoff wrote: On Tue, May 13, 2014 at 2:05 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This tool doesn't even work anyway. It doesn't? Bug report / more info please? Show me that it does. The documentation is lacking, and there's no tests at all. So it's hard to say is anybody supposed to use this and verify that it works, but I ran this from Jeff: tla register-archive http://www.atai.org/archarchives/a...@atai.org--public/ tla my-default-archive a...@atai.org--public mkdir repo cd repo git archimport a...@atai.org--public And the command threw hundreds of errors and the result seemed to miss tons of commits. Does it work? -- Felipe Contreras -- 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 01/17] contrib: remove outdated README
Junio C Hamano wrote: Martin Langhoff martin.langh...@gmail.com writes: On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras felipe.contre...@gmail.com wrote: You are once more twisting the sequence of events. Found this gem looking for background to the proposed removal to code of mine. Felipe, if you are wanting to have a war of words with Junio, go have it, with him. Please don't feed the troll. I was happy to be done with it. I was going to let this comment go (as I let the endless stream of ad hominem attacks go), but this just one ridiculous. I've contributed 400 patches, changed 12700 lines, sent 4200 mails on the list. Then I'm not happy with a decision you made, and I ask you *one* question to clarify your rationale, and I'm still waiting for an answer. I think after this insane amount of work I'm entitled to an answer for this *one* question. Instead you passive aggressively label me as a troll? This is really disquieting. Junio, do you honestly think I am a troll? Have at least the decency of telling it to me. -- Felipe Contreras -- 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: Error using git-remote-hg
William Giokas wrote: On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote: Why do we import changegroup unconditionally, even though it is only used in the new codepath meant only for version 3.0 or higher, not inside the if block that decides if we need that module? changegroup is prefectly /okay/ to import unconditionally, though as you say it will never be used. As you say, it's perfectly OK. We can also be even more explicit with what we import by doing something like:: try: from mercurial.changegroup import getbundle except ImportError: def getbundle(__empty__, **kwargs): return repo.getbundle(**kwargs) We could try that, but that would assume we want to maintain getbundle() for the long run, and I personally don't want to do that. I would rather contact the Mercurial developers about ways in which the push() method can be improved so we don't need to have our own version. Hopefully after it's improved we wouldn't have to call getbundle(). Moreover, eventually there will be a Mercurial 4.0, even 5.0, and at some point we would want to remove the hacks for older versions. When we do so we would want the import to remain unconditionally, and remove the 'check_version(3, 0)' which is already helping to explain what the code is for without the need of comments. I was really sad to see that, and didn't have time to really look at it because of work and other projects, but I hope this presents a better solution than the current patch. Either way Junio doesn't maintain this code, I do. And it's not maintained in git.git, git's maintained out-of-tree (thanks to Junio's decisions). So please post your suggestions and patches to git...@googlegroups.com, and use the latest code at https://github.com/felipec/git-remote-hg. Cheers. -- Felipe Contreras -- 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: Error using git-remote-hg
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
Why do we import changegroup unconditionally, even though it
is only used in the new codepath meant only for version 3.0 or
higher, not inside the if block that decides if we need that
module?
changegroup is prefectly /okay/ to import unconditionally, though as you
say it will never be used.
As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
have a code review such as this. It should simply not be done and makes
no sense to do with an 'if check ver; else' kind of thing later in the
application.
That's exactly how it should be done. Maybe this visualization helps
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
if check_version(3, 0):
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
else:
cg = repo.getbundle('push', heads=list(p_revs) # for hg 3.0
Eventually the code would become:
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
The fact that at some point 'import changegroup' was not needed is
irrelevant.
Primarily we want to support the current version of Mercurial.
Secondarily we want to support older versions. That's why we add the
repo.getbundle() code (ass an addendum to the core part).
We can also be even more explicit with what we import by doing something
like::
try:
from mercurial.changegroup import getbundle
except ImportError:
def getbundle(__empty__, **kwargs):
return repo.getbundle(**kwargs)
We could try that, but that would assume we want to maintain getbundle()
for the long run, and I personally don't want to do that. I would rather
contact the Mercurial developers about ways in which the push() method
can be improved so we don't need to have our own version. Hopefully
after it's improved we wouldn't have to call getbundle().
Assuming that mercurial 3.0 will not change, then this should never
need to change.
But it should. Otherwise the code will keep having more and more hacks
and it will become less and less maintainable.
That's why we don't have code for hg 1.0; because it would require too
many hacks, and nobody cared anyway.
Just like nobody cares about hg 1.0, eventually nobody will care about
hg 2.0.
Changes in 'getbundle' upstream would require changes either way.
I doubt we will see any more changes in getbundle, at least not until
4.0, and hopefully by then we wouldn't be using it anyway. I am willing
to bet we won't see those changes.
Moreover, eventually there will be a Mercurial 4.0, even 5.0, and at
some point we would want to remove the hacks for older versions. When we
do so we would want the import to remain unconditionally, and remove the
'check_version(3, 0)' which is already helping to explain what the code
is for without the need of comments.
The same exact thing can be done with this. In fact, it would probably
allow us to have better future-proofing with regards to new versions of
mercurial, there would just be different try:except statements at the
beginning.
No, your code doesn't show that this is for versiosn = 3.0,
'check_version(3, 0)' does.
Plus, when we remove this code my version makes it straight forward:
-if check_version(3, 0):
-cg = changegroup.getbundle(repo, 'push', ...
-else:
-cg = repo.getbundle('push', heads=list(p_revs), ...
+cg = changegroup.getbundle(repo, 'push', ...
Not so with your code:
-
-try:
-from mercurial.changegroup import getbundle
-
-except ImportError:
-def getbundle(__empty__, **kwargs):
-return repo.getbundle(**kwargs)
+from mercurial import getbundle
import re
import sys
@@ -1036,7 +1030,7 @@ def push_unsafe(repo, remote, ...
if not checkheads(repo, remote, p_revs):
return None
-cg = getbundle(repo, 'push', heads=list(p_revs), ...
+cg = changegroup.getbundle(repo, 'push', ...
I was really sad to see that, and didn't have time to really look at it
because of work and other projects, but I hope this presents a better
solution than the current patch.
Either way Junio doesn't maintain this code, I do. And it's not
maintained in git.git, git's maintained out-of-tree (thanks to Junio's
decisions).
I still see it in git.git, and I will contribute this upstream for as
long as it is in the tree.
And what happens when it's eventually removed?
If you
Re: [PATCH] remote-hg: getbundle changed in mercurial 3.0
Junio C Hamano wrote: The way I envision the longer term shape of git-remote-hg.py in the contrib/ is either one of these two: (1) manage it just like contrib/hooks/multimail/, keeping a reasonably fresh and known-to-be-good snapshot, while making it clear that my tree is not the authoritative copy people should work off of; (2) treat it just like contrib/emacs/vc-git.el, which found a better home and left my tree at 78513869 (emacs: Remove the no longer maintained vc-git package., 2009-02-07); or The first one may be more preferrable between the two, if only because distros would need time to adjust where they pick up the source material to package up, but it still needs cooperation with the authoritative upstream and this project to allow us to at least learn when the good time to import such good snapshots. I will not do that. If you want my help to improve *your* tree, you have to start by answering the *one* question I've repeatedly asked you to clarify. In fact if you go for this I would consider it an act of sabotage against these new projects. If you hadn't made me waste all this time chasing a non-attainable goal, these projects would already be packaged by distributions, instead of hidden in some corner of /usr/share. Distributions wouldn't even be aware of the move, and it might take bug reports to make them realize that. There will be already enough damage to the reputation of these tools with Git v2.0 shipping them broken. Not aligned at all with your previous statement that you wanted these to flourisn. In fact, I think you should remove them already from v2.0. Because this doesn't need release candidates. Unless you think user feedback will make you change your mind about not graduating them, moving them in 2.0, or 2.1 will be the same, since you are going to ignore the feedback anyway. This also has the advantage that you won't be shipping them broken in v2.0. At the very least there should be a big fat message warning each time the tools are run, warning the users that they are unmaintained, and the right location for them. And yes, I also think this should be done for v2.0. -- Felipe Contreras -- 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] contrib: remote-helpers: add move warnings (v2.0)
The tools are now maintained out-of-tree, and they have a regression in
v2.0. It's better to start warning the users as soon as possible.
Can't possibly introduce regressions.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 3 +++
contrib/remote-helpers/git-remote-hg | 3 +++
2 files changed, 6 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 9abb58e..be4b9a3 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -43,6 +43,9 @@ import re
import StringIO
import atexit, shutil, hashlib, urlparse, subprocess
+sys.stderr.write('WARNING: git-remote-bzr is now maintained independently.\n')
+sys.stderr.write('WARNING: For more information visit
https://github.com/felipec/git-remote-bzr\n')
+
NAME_RE = re.compile('^([^]+)')
AUTHOR_RE = re.compile('^([^]+?)? ?[]([^]*)(?:$|)')
EMAIL_RE = re.compile(r'([^ \t]+@[^ \t]+)')
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 34cda02..989df66 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -25,6 +25,9 @@ import atexit
import urlparse, hashlib
import time as ptime
+sys.stderr.write('WARNING: git-remote-hg is now maintained independently.\n')
+sys.stderr.write('WARNING: For more information visit
https://github.com/felipec/git-remote-hg\n')
+
#
# If you want to see Mercurial revisions as Git commit notes:
# git config core.notesRef refs/notes/hg
--
1.9.2
--
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: Error using git-remote-hg
William Giokas wrote:
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
have a code review such as this. It should simply not be done and makes
no sense to do with an 'if check ver; else' kind of thing later in the
application.
That's exactly how it should be done. Maybe this visualization helps
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
if check_version(3, 0):
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
else:
cg = repo.getbundle('push', heads=list(p_revs) # for hg 3.0
Eventually the code would become:
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
No, the way that it's going to change is that the import statements will
change, not the 'if:else' things. It would work exactly the same with
this, however the things that are used only in a specific version for
this are stated up front. Maybe this visualization helps for what I have
set up::
from mercurial import ...# for all hg
try:
from mercurial.changegroup import getbundle # for hg with
# changegroup.getbundle,
# regardless of version
This would make sense if in our eyse all versions of Mercurial were
the same, and we would want the code to work optimally for all of them
forever.
But that's not the case. The current version of Mercurial is more
important, the fact that we have one unnecessary import in older
versions is not of consequence because eventually the won't be
supported.
When we eventually remove support for mercurial that uses
repo.getbundle:
from mercurial import changegroup, ... # for all hg
...
cg = changegroup.getbundle(...)
And the diff from my version to the final version is smaller.
The fact that at some point 'import changegroup' was not needed is
irrelevant.
Primarily we want to support the current version of Mercurial.
Secondarily we want to support older versions. That's why we add the
repo.getbundle() code (as an addendum to the core part).
So I use arch myself, and I am very used to the 'rolling release' model
that it employs. I do agree that we should concentrate support for the
latest release, but for a project like git the other versions of hg
cannot be ignored, as this project is used on so many different systems.
Older versions are not ignored, they are supported. It's just not worth
tainting the code to avoid an 'import'.
We could try that, but that would assume we want to maintain getbundle()
for the long run, and I personally don't want to do that. I would rather
contact the Mercurial developers about ways in which the push() method
can be improved so we don't need to have our own version. Hopefully
after it's improved we wouldn't have to call getbundle().
Assuming that mercurial 3.0 will not change, then this should never
need to change.
But it should. Otherwise the code will keep having more and more hacks
and it will become less and less maintainable.
That's why we don't have code for hg 1.0; because it would require too
many hacks, and nobody cared anyway.
Just like nobody cares about hg 1.0, eventually nobody will care about
hg 2.0.
Yes, it can change. Eventually hg 2.0 will be defunct and no one will
use it, but what happens if they go back to the old 2.0 style for
getbundle in hg 4.0?
Then you can tell me I was wrong and we go back to your version. But
that's not going to happen.
And even if it does, we still would need to fix the code.
We're already good. What if they switch it back in
4.1? This works for all of those conditions, and doesn't do anything if
we're able to get mercurial.changegroup.getbundle.
Every method can change, we can't have wrappers for all of them.
In reality few of them do. And we deal with them on a case by case
basis.
There's no need to worry about the unlikely, especially since there
isn't much difference between the likely and unlikely; we are still
going to need to fix the code.
Changes in 'getbundle' upstream would require changes either way.
I doubt we will see any more changes in getbundle, at least not until
4.0, and hopefully by then we wouldn't be using it anyway. I am willing
to bet we won't see those changes
Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: The tools are now maintained out-of-tree, and they have a regression in v2.0. You seem not to understand at all what a regression is. My understanding is that versions of remote-hg shipped with all versions of Git did not work with Hg 3.0, so not working with Hg 3.0 is a regression in v2.0 at all. I explained to you multiple times already that is a different issue, but it somehow doesn't get through your skull. Let me try a different approach. git-remote-bzr has a regression in Git v2.0. Did you get the BAZAAR part? That's right, this is unrelated to Mercurial v3.0 because it doesn't have anything to do with Mercurial. *BOTH* git-remote-hg and git-remote-bzr have a regression in Git v2.0. A recent report was about Hg 3.0 not working with 1.9.3, but I think you earlier said all versions of Git does not work with Hg 3.0, and I can believe it. That is hardly a regression. You could argue that Hg has a new regression to its external users of its API when it went to 3.0. We actually had a similar breakage in 1.5.4, where it was reported late in the cycle after -rc0 [*1*] that cgit that linked with our internal API libgit.a was broken by a change on our side, which resulted in us fixing the breakage (even though technically you may be able to say that it was cgit's fault to link with libgit.a in the first place) with 18125644 (Move sha1_file_to_archive into libgit, 2008-01-14) very late in the cycle. Calling that a regression in cgit would have been insane, even if we did not patch our side up to accomodate it. Stop this idiocy. Sigh, you just don't seem to understand that you are thinking about a different issue. I don't think there's any other way I can explain it to you. -- Felipe Contreras -- 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 01/17] contrib: remove outdated README
Martin Langhoff wrote: I have had patches and contributions rejected in the past, sometimes rudely. Same has happened to many others, if you contribute long enough, it is pretty much guaranteed that it will happen to you. Maintainer is wrong, or you are wrong, or someone is just having a bad day. This is not about a couple of patches I worked in a weekend being rejected. This is about the work I've been doing since the past two years almost like a full-time job dropped to the floor with no explanation at all. I started with the expectation that they were going to move to the core, because Junio said so, then he changed his mind and didn't want to explain his reasoning. It's not just a bad day. -- Felipe Contreras -- 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] contrib: remote-helpers: add move warnings (v2.0)
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Sigh, you just don't seem to understand that you are thinking about a different issue. I don't think there's any other way I can explain it to you. Perhaps pointing out which commit(s) to revert might be a good point to start. Oh, now you realize it might be nice to avoid this regression I warned you about. Why don't you continue schooling me about what constitutes a regression? I'm such a slow learner. I was going to do more than pointing to commits, I was going to provide the fixes with test cases and a detailed explanation. But then you made your decision. This patch is what I'm suggesting you to do now. And I'll repeat what I already told you. Good luck with your tree. -- Felipe Contreras -- 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 01/17] contrib: remove outdated README
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio, do you honestly think I am a troll? You certainly are acting like one, aren't you? I'm deeply offended by the fact that would think that I'm purposely intent on provoking people, or disrupting more important discussions. I understand how my style of communication can upset people, mainly because people are not used to frankness. But I thought you of all people would see how much effort I've put into so many areas of Git, and therefore that my primary objective is to improve Git, not offend people. That you would understand that me offending people is a side-effect of me trying to improve Git, not that I improve Git just so I can offend people. I understand why you would choose not to reply to some mails that might be too flammable, or unimportant, or difficult. But in this case, the culmination of countless hours of work, what I had in mind since the beginning; that the tools graduate into the core, was finally there, and you took it away. And then you didn't give an explanation, and then you ignored me. I thought you would understand that most of the code that arrived to the mailing list had different versions behind, experiments, discussion in different channels, tests, and that was the reason why most of the code I submitted to remote-hg and remote-bzr simply worked, and it was simple. And why when other people did the same, the results were not so satisfactory. But no, apparently you didn't value my work at all. Maybe you thought each line I sent took me the time it takes to write a tweet, maybe you thought because it's in Python even kids in primary school could write it. In fact it's worth so little to you that it's not even worth the time to respond *one* question, not even in consideration of all these years of effort. And then you have the nerve to call me a troll on top of that? I'm done with you. Consider the bridge burned. Good bye. -- Felipe Contreras -- 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] contrib: remote-helpers: add move warnings (v2.0)
Ronnie Sahlberg wrote: Could you please calm down and adjust your behavior. This constant hostility and rudeness makes the mailing list very unpleasant. I explaind that to him multiple times. In the mail I replied to he is once again assuming I'm a *insert-your-favorite-non-smart-adjective*, and explaining to me what a regression is. How many times must one repeat something before one is entitled so thay something is not getting through the skull of another person? 5? 10? 20? But fine, let's assume I do have to adjust my behavior. Maybe I should have said it doesn't register in your brain, or just it fails to grab your attention. But if I have to adjust for saying that (which was true), what do you say to Junio for saying this? (which was not) Stop this idiocy. I presume nothing, because Junio is a riskier target. -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Linus Torvalds wrote: On May 12, 2014 8:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: This move is already under way, but suddenly Junio changed his mind. That suddenly wouldn't have anything to do with you being an ass and difficult as usual, arguing about everything and just generally being contrary? No, here's where the thread started (A): http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167 Here I wasn't being an ass: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248186 Here I wasn't being an ass either: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248171 Neither here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248146 Nor here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248195 Nor here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248205 Not an ass here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248213 And not here either: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248236 Then Junio *suddenly* changed his mind (B): http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242 That is the sequence of mails (A..B) where I responded, and I wasn't an ass in eithe one of those, so whatever made Junio change his mind happened in that interum, and it wasn't me being an ass. I bet you made that statement without even botherting to read the thread. Go on, read the thread, tell where exactly me being an ass made Junio change his mind from A, to B. Nah, you wouldn't do that, backing up your claims take time, and you are not willing to spend time on this issue. Even if you were to try to back up your claim, you couldn't, becasue it's not true. It's much easier to just throw good sounding baseless claims and walk away. Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. You make absolutely everything be this horrible disaster, you redefine words (regression) to be whatever you need/want them to be to be git-remote-hg and git-remote-bzr will likely break in Git v2.0 in certain situations where they wouldn't in v1.9, or v1.8. Call it whatever you want. I call that a regression. Seriously. Don't try to make this about Junio somehow being the problem. So Junio is perfect. Got it. If you don't have the time to actually read the rationale behind Junio's decision, how would you even know he made the right one? You are just blindly assuming he is right, and therefore he is not the problem. What if he was wrong? Nah, that's impossible. Right? -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. Junio, can you answer these questions? 1) What is missing from git-remote-hg/bzr in order for them to be considered to be merged to the core? 2) If a different maintainer steps up, would you consider reconsider merging them to the core? 3) Is there any chance that in the future you would consider them after they are more mature, and/or perhaps with a different maintainer? Unless Junio changes his mind again, the answers to those questions should be clear already to the people following the discussion (i.e. not you). -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. You mention there are good technical arguments against the graduation of the tools. Surely if you have analyzed those arguments enough to form an opinion aligned with Junio's, it should be easy to provide a short summary of those good technical arguments. Can you do that? 1. That subproject has not been maintained to the standards of the Git project; The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. That's not true. I sent my patches at my own pace, it doesn't matter if they are in contrib or in the core, I would have kept sending them at the same pace. I have addressed all issues and responded to all questions as if they were already part of the core, which is why they have more quality than other tools already in the core. I only stopped doing that when Junio changed the direction we had since day one. Also a red herring. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. If you think being out-of-tree is not a negative, lets throw out git-archimport, git-quiltimport, git-p4, git-cvs, git-svn. Let us give them an opportunity to shine. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Cheers. -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Stefan Beller wrote: 2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. I suspect Linus had a reason not to include the mailing lists in the first place Huh? He did include the mailing lists in the first place[1]. Either something is wrong with the mailing list, or somebody is removing the mails. You can see the full thread in the git-fc mailing list, and there you can see the git ml is included in all the mails, including the one you just sent, where you included the git ml, and it doesn't show in the archives. and make a huge public discussion, but instead wrote to you personally. I guess this is just Linus desire not to waste the time of everybody as he learned that these discussions are fruitless sometimes. Don't you agree that including transparent bridges for Mercurial and Bazaar distributed by default would be benefitial to the project? If a discussion could potentially lead to them being included, I'd say that wouldn't be fruitless, but it's *precisely* what our end users would like us to be discussing right now. Junio C Hamano wrote [in another thread]: I would not mind asking the others, as your discussion tactic seems to be repeated voices start sounding like a chorus, and a chorus is project concensus. Those who are observing from the sideline, please raise your hand if you think the three-line Clarification Felipe gave us is a fair and accurate clarification. Anybody? I also do not mind seeing hands raised of those who do not agree, even though I already know that they would be a silent majority. I think Junio is behaving very professional unlike you, Felipe. This includes being polite and very patient. Also this includes weighting different reasons to make informed rational decisions. Where is he weighting the different reasons? I've asked him multiple times to provide those reasons. He mensions there's one, but he doesn't say which one it is. If I haven't see this reason, how do you know he is weighing different ones? Git being a project widely used and people trusting it for their work needs to have high quality and cannot go left today and go right tomorrow, but most of the decisions are done long-term. Yes. What is right, and what is left in this example? Presumably going right would be to include these tools in the core, but that would imply that he plans to go left in the future. But he hasn't said that. So what makes you think the project would go left in the future? Felipe, this may be the reason, why you think nothing changes. It's just slower than you'd like, but with more thoughts weighted. Really? I'll issue the same challenge I've issued to many people. Name a single important change in Git (was one way before, it's another way now) that has happened in the last 5 years. And by important I mean for starters users noticed it. You won't be able to, because nothing ever changes. Junio, I think you're doing an awesome job in maintaining Git and leading the community. Maintaining, yes, but leading? Leading it where? [1] https://groups.google.com/forum/#!original/git-fc/Clhss-fXS2k/9UtiilJ2WQ4J -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, Then there's no point in reading what else you have to say. Whatever reasons you might have to agree with Junio are known only to you, thus your agreement is opaque and meaningless. The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: I'll wait until somebody else calls into question the quality. Preferably somebody who backs up his claims with evidence. OK, maybe you are technically correct there. There is indeed a difference between and =. Let me amend my claim: 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? And there's the transport helper, and bash completion, and the zsh completion. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. I never made that claim. I claimed that it was nothing like jail, and I stand by that claim. In the context of the Git project what is the *worst* thing the maintainer can do to a piece of code but delete it? So I think you are right, the jail analogy is not correct; it's *execution*. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. People who need to do a conversion from A to B only have to Google for A B and they will find the best conversion tools pretty easily. Let's test that hypothesis: Google: how to conver mercurial to git * Convert Mercurial project to Git - Stack Overflow (NOPE) * Converting a Mercurial repository to Git (YEAP: one among many) Oh, but would you look at that: This script will actually be shipping with git at some point, which gives it some credibility in my book. * frej/fast-export · GitHub (NOPE) * Hg-Git Mercurial Plugin (NOPE) * Converting Hg repositories to Git (NOPE) * Converting from Mercurial to Git - Hivelogic (NOPE) * Converting Repositories From Git to Mercurial (NOPE) * hg-fast-export: convert Mercurial repositories (NOPE) * Converting Mercurial (Hg) to Git Repository on Mac (NOPE) * Bitbucket: Converting Hg repositories to Git (NOPE) So pretty much hypoethesis failed. That fact that you would even think people would quickly find about git-remote-hg shows exactly how detached you are from the problem. If the tools are packaged for their OS then they are just an apt-get install away from happiness. Oh, they are packaged already (as part of Git). Moving them out-of-tree will make it much more difficult for users to find them, and install them. It will take time for them to be packaged, if it happens at all. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Jumping at your every demand is not a prerequisite for being sincere. I spent a lot of time writing that mail. Not sincere it is then. -- Felipe Contreras-- 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: Should git-remote-hg/bzr be part of the core?
Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. I really *love* this paragraph. Felipe, you are a brilliant developer and you put a lot of work trying to improve GIT. Thanks. While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. If you are right, the different attitude would make the patches land in no time. I still think it's not right for patches to be rejected simply because of attitude, but I would accept you were right. But I think you already know that won't happen, the patches still won't get in, not because of the attitude, but because of what they are trying to do: change things. So if I *know* certain feature would be useful for Git users, I've listened to all the comments, and addressed all the problems, why would I give up on those patches? Why would I work on something more boring that won't benefit users as much but would have higher chances of getting in? I'm doing this on my own free time, I can choose to do whatever I want, in whatever way I want, so no, I'll keep working on what I think is important. If you really think the patches can be accepted with a different attitude, by all means, let's do the experiment and find out. -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. Well, you could at least try to act and communicate differently. I have, it doesn't make a difference. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. No, sorry but I'm NOT interested in lying to git community. Yeah, that's what I thought. I know what the result of such experiment would be though. -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 02:29 PM, Felipe Contreras wrote: Michael Haggerty wrote: [...] 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? No, actually my preference is that git-remote-hg be separated from the Git project altogether, for the reasons that I stated earlier. Exactly. So your point 2. is completely irrelevant to the contrb/ vs. core debate. -- Felipe Contreras -- 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: Error using git-remote-hg
Torsten Bögershausen wrote: I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew. It used to work before, on this same repository, since then git and hg were both upgraded. In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0 You can eiher downgrade hg, or rebuild Git and cherry-pick this commit: No need to rebuild Git. You can also use the latest version: https://github.com/felipec/git-remote-hg -- Felipe Contreras-- 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/4] remote-hg: more improvements
Junio C Hamano wrote: Philippe Vaucher philippe.vauc...@gmail.com writes: It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Junio, can you comment on this? I understand this probably doesn't really affect the issue at hand, but it'd help clarify if it's ever possible to move out of contrib/ nowadays. I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. This is bullshit, and a wrong direction fallacy. Event #1: Junio rejects the graduation http://article.gmane.org/gmane.comp.version-control.git/248263 Event #2: I give up improving remote helpers in git.git http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 Junio is trying to make you believe that his decision (#1) was caused by something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1, it can't possibly be the cause. But I would be lying if I said that I would expect that things will suddenly improve and that the codebase will be maintained for the long haul in a healthy way the minute we move it out of contrib/ to the core. Especially after seeing [*1*] [1] happened *AFTER* you made that stupid decision. Don't make it look as if your decision was caused by [1], *YOU* caused [1]. If you want to show that the quality of the commit messages or the code caused that decision, show an issue in that respect that happened *BEFORE* your decision. It is very clear what is happening. Junio made a wrong decision based a non-issue, then it became abudantly clear that there was no basis for such decision, this why he never clarified the reasoning behind. Then, *AFTER* I reacted to his decision he grabbed that opportunity to say no, look, this _new_ thing Felipe is doing is the reason. Nice try. If the behavior in [1] is the reason, the solution is easy; I'll revert back to my old behavior where I explained everything in detail, and updated the commit messages if something wasn't clear. I would: 1. Make sure the regression is fixed Git v2.0 2. Send a clarified patch for the hg 3.0 compatibility 3. Look for other important patches that might be missing and provide all the details why they are important 4. Rebase and clean the rest of the patches to make sure nothing is missing This is what I was going to do anyway *BEFORE* you made that decision. And this commitment to quality is what I've been doing since day one. *YOU* changed that by throwing away all my hard work. If the issue was truly the behavior in [1], the outline above should get rid of the (fake) problem you mention. We make a compromise, you ignore this temporary bump (that *you* caused), and I go back to high quality standards (which I was already doing anyway before). The graduation process continues, and *IF* another instance like [1] comes (it won't), then the graduation process is canceled. Ignoring temporary set-backs, finding common ground, and making an agreement on future behavior is in the best interest of our users. Will you do it? *1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 -- Felipe Contreras -- 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/4] remote-hg: more improvements
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: ... I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. This is bullshit, and a wrong direction fallacy. Event #1: Junio rejects the graduation http://article.gmane.org/gmane.comp.version-control.git/248263 Event #2: I give up improving remote helpers in git.git http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 Junio is trying to make you believe that his decision (#1) was caused by something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1, it can't possibly be the cause. I think you misunderstood. I never said that I do not want it to graduate up (out is an option) based on code quality. Fair enough, that was my understanding up until today. But because I was asked, I thought about it, and then answered honestly. I do not know what a trap you perceive is about, and I am not interested in your responses. Philippe Vaucher didn't ask about quality, he asked about moving out of contrib. -- Felipe Contreras -- 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] inline constant return from error() function
Junio C Hamano wrote: That's kind of W*A*T magic, and I generally try to avoid magic, as long as it solves your can we make both -O2 with new compilers and -O3 happy? I wouldn't complain ;-) In case anybody is looking for a non-hacky way of doing this that doesn't depend on the gcc version of the week, this is how I silenced the warnings in git-fc: https://github.com/felipec/git/commit/e14ca39ba0092f0305d5fb347e20b829f736b29b -- Felipe Contreras -- 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: What's cooking in git.git (May 2014, #02; Fri, 9)
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
- remote-hg: trivial cleanups
- remote-hg: make sure we omit multiple heads
- git-remote-hg: use internal clone's hgrc
- t: remote-hg: split into setup test
- remote-hg: properly detect missing contexts
- remote-{hg,bzr}: store marks only on success
- remote-hg: update to 'public' phase when pushing
- remote-hg: fix parsing of custom committer
(merged to 'next' on 2014-04-22 at fed170a)
+ remote-helpers: move tests out of contrib
+ remote-helpers: move out of contrib
+ remote-helpers: squelch python import exceptions
As there were announcements for these two to be maintained as
independent third-party projects ($gmane/248561, $gmane/248583),
Clarification: after Junio unlilaterally blocked any further progress
towards grauduation to the core, which was the intention since the very
beginning.
After seeing your repeated attempts to spread misinformation, I was
planning to totally ignore you, but because What's cooking is one
of the important project-wide report, I'll respond one last time.
Even though I was originally leaning towards moving them into core
(after all, why would I have merged the bottom three commits to
'next' otherwise?), I was later convinced, during the discussion
that started with John Keeping's objection [*1*], that I was wrong,
Funny how you simply put a reference to the objection, and don't even
mention it, even though I asked you multiple times to state clearly what
was this argument that moved you so deeply. Even now the link you
posted is to this same thread, not John Keeping's objection.
Since you have failed to clarify, I'll make a guess and assume it's this
one[1]:
I do not want to end up in a situation where an update to Git is
blocked by a distribution because git-remote-hg is not updated to
support newer versions of Mercurial sufficiently quickly; this
previously happened in Gentoo due to git-svn and meant that was stuck
on 1.7.8 until 1.7.13 was released [2].
First of all, John Keeping is not arguing that such situation *will*
arise, he is arguing that it *might*. Well, an asteriod *might* wipe all
humans on Earth tomorrow, should we all act like it *will* happen, throw
away all our money and run naked on the streets? No, we assess what is
the *likelihood* that such an event would happen.
That's what sane human beings do all the time; we try to calculate the
future using the past and logic as a reference. That's why you see most
people not check their chairs before sitting, they assume the chair
functions correctly, even it *might* be broken, and indeed sometimes
they are and they fall, but it happens so rarely that it doesn't make
sense to worry about.
But you are not like that, are you? To you is enough that something
*might* happen to act like it *will*. I told you the hypothetical event
that John Keeping was talking about would not happen, we have checks in
place to ensure that it doesn't[2].
And you don't use history as an indicator of the future; there hasn't
been *a single* change in git-remote-hg that was needed for newer
versions of Mercurial. The only one was extremely recent, and I didn't
catch it sooner because I wasn't testing for hg's development version,
which I am now.
Moreover, the reason of the failure was that I wrote my own custom
push() method, which relies on things too deep in the API, and those
things do change from time to time. To mitigate the possibility of that
happening I'm planning to contact the Mercurial developers to see how it
would be possible to change their API so I wouldn't need my custom
push() method in the future, and therefore if they change something
inside their push() method, that change wouldn't hit us.
But you are not interested in that are you? You are not interesed in how
likely is the event, nor on mitigation strategies, you only care that it
*might* happen, even though in reality it proably never *will*. Perhaps
you do check every chair before sitting.
Let's assume that it *will* happen (it won't), what is the worst case
scenario? The users of git-remote-hg might get some broken
functionality, but that would happen regardless if they are in the core,
contrib, or out-of-tree. 'make test' might break and prevent packages
and other people to build correctly. This is a real issue, however, it's
not impossible to solve (nothing is), and there's many ways to deal with
this:
a) Distribute remote-hg tests separately. This is actually how my patch
series started: t/remote-helpers was separate from the other tests.
This way we can tell distributions that they shouldn't rely on these
tests passing always.
b) Add a new test_expect_success_maybe. This way distributions can keep
running the tests, but if something fails the build wouldn't stop.
c) Just remove all tests
Should git-remote-hg/bzr be part of the core?
Hi, Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I have repeatedly asked him to clarify what argument changed his mind, but he hasn't done so. Hopefully he will do that in this thread, but I'll jump ahead and assume it's this one by John Keeping[2]: I do not want to end up in a situation where an update to Git is blocked by a distribution because git-remote-hg is not updated to support newer versions of Mercurial sufficiently quickly; this previously happened in Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was released [X]. Now, I feel I addressed this argument at length, specially in this thread [3], but I'll try to provide a summary of the strongest arguments against: 1) We can make the tests optional, say 't/optional'. So if they don't pass, the build of Git is not broken. Additionally, distributions might prefer to run test-essential if they don't want to run these optional tests. 2) There's already continuous integration builds[4] to make sure all the possible incoming changes in Mercurial are detected early on. 3) There has been a *single* case where a new Mercurial (3.0) broke things. This is due to the fact of how I implemented certain functionality due to limitations in Mercurial's API. Mercurial authors can be contacted to improve the API and minimize the possibility of it happening again. Given these arguments, I don't see how moving git-remote-hg to the core could possibly cause any problems, and I don't understand why Junio would think otherwise. Even if such a breakage causes a problem to the whole Git, it would make sense to demote these tools *when* such a problem comes (which I argue it won't). Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened. Thoughts? [1] http://article.gmane.org/gmane.comp.version-control.git/248676 [2] http://article.gmane.org/gmane.comp.version-control.git/248167 [3] http://article.gmane.org/gmane.comp.version-control.git/248683 [4] https://travis-ci.org/felipec/git [5] http://article.gmane.org/gmane.comp.version-control.git/220277 -- Felipe Contreras -- 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: Summary of the problems with git pull
Felipe Contreras wrote: == git update == Another proposed solution is to have a new command: `git update`. This command would be similar to `git pull --ff-only` by default, but it could be configured to do merges instead, and when doing so in reverse. And here it is: https://github.com/felipec/git/commits/fc/update Here's the documentation: https://github.com/felipec/git/wiki/git-update Works exactly as expected: non-fast-forwards are rejected by default, but can be configured, and parents are reversed when merging. -- Felipe Contreras -- 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
