[PATCH] t0005: skip signal death exit code test on Windows
From: Johannes Sixt j...@kdbg.org The test case depends on that test-sigchain can commit suicide by a call to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect as death through a signal. There are no POSIX signals on Windows, and a sufficiently close emulation is not available in the Microsoft C runtime (and probably not even possible). The particular deficiency is that when a signal is raise()d whose SIG_DFL action will cause process death (SIGTERM in this case), the implementation of raise() just calls exit(3). We could check for exit code 3 in addition to 143, but that would miss the point of the test entirely. Hence, just skip it on Windows. Signed-off-by: Johannes Sixt j...@kdbg.org --- t/t0005-signals.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh index ad9e604..981437b 100755 --- a/t/t0005-signals.sh +++ b/t/t0005-signals.sh @@ -20,7 +20,7 @@ test_expect_success 'sigchain works' ' test_cmp expect actual ' -test_expect_success 'signals are propagated using shell convention' ' +test_expect_success !MINGW 'signals are propagated using shell convention' ' # we use exec here to avoid any sub-shell interpretation # of the exit code git config alias.sigterm !exec test-sigchain -- 1.8.3.1489.g15123b5 -- 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] t0005: skip signal death exit code test on Windows
On Thu, Jun 06, 2013 at 08:34:41AM +0200, Johannes Sixt wrote: From: Johannes Sixt j...@kdbg.org The test case depends on that test-sigchain can commit suicide by a call to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect as death through a signal. There are no POSIX signals on Windows, and a sufficiently close emulation is not available in the Microsoft C runtime (and probably not even possible). The particular deficiency is that when a signal is raise()d whose SIG_DFL action will cause process death (SIGTERM in this case), the implementation of raise() just calls exit(3). We could check for exit code 3 in addition to 143, but that would miss the point of the test entirely. Hence, just skip it on Windows. Thanks. I wasn't quite clear on how the signal handling worked on Windows, but from your description, I agree there is not any point in running the test at all. Acked-by: Jeff King p...@peff.net -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0005: skip signal death exit code test on Windows
On Thu, Jun 6, 2013 at 1:44 AM, Jeff King p...@peff.net wrote: On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote: Thanks. I wasn't quite clear on how the signal handling worked on Windows, but from your description, I agree there is not any point in running the test at all. Shouldn't we clarify that Git exit codes only work on UNIX-like operating systems? Clarify where? Documentation/technical/api-run-command.txt My impression is that this issue is well-known in the msys world, and it is a platform issue, not a git issue. If somebody wants to write a note somewhere in the git documentation, that's fine with me, but I'm not clear on exactly what it would even say. That the exit code is not the same in Windows (not msys). -- 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: [Administrivia] On ruby and contrib/
On 5 June 2013 16:45, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote: That might make sense for the shorter term, but in longer term I see Perl as declining in favor of other languages. It's only a matter of time before Ruby surpasses Perl in popularity, and soon enough new contributors to the Git project will have problems trying to improve Git because parts of it are written in a language they are not familiar with, and have trouble learning (isn't that already happening?). The Ruby vs. Python is another question altogether, I could go into detail about why I think Ruby is a better choice, but my point right now is that Perl is not a good choice for the future. Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Yves -- 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: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: On 5 June 2013 16:45, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote: That might make sense for the shorter term, but in longer term I see Perl as declining in favor of other languages. It's only a matter of time before Ruby surpasses Perl in popularity, and soon enough new contributors to the Git project will have problems trying to improve Git because parts of it are written in a language they are not familiar with, and have trouble learning (isn't that already happening?). The Ruby vs. Python is another question altogether, I could go into detail about why I think Ruby is a better choice, but my point right now is that Perl is not a good choice for the future. Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png -- 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 4/4] archive: ignore blob objects when checking reachability
On 06/06/2013 12:40 AM, Jeff King wrote: We cannot create an archive from a blob object, so we would not expect anyone to provide one to us. And if they do, we will fail anyway just after the reachability check. We can therefore optimize our reachability check to ignore blobs completely, and not even create a struct blob for them. Depending on the repository size and the exact place we find the reachable object in the traversal, this can save 20-25%, a we can avoid many lookups in the object hash. The downside of this is that a blob provided to a remote archive process will fail with no such object rather than object is not a tree (we could organize the code to retain the old message, but since we no longer know whether the blob is reachable or not, we would potentially be leaking information about the existence of unreachable objects). Could we change the error message to no such tree object to be non-committal about the reason for the failure? For a moment I thought that one could get correct error messages while retaining the speed gain in the usual case by doing a quick object lookup, and then check type of object if object is missing: die(there is no such object) else if object is a blob: do reachability test including blobs if object is not reachable: die(there is no such object) else die(object is not a tree) else do reachability test excluding blobs etc However, even this would leak information about the existence of nonreachable objects to a client measuring time time for the response because the death due to non-reachability would take longer than death due to missing object. So, if one would insist on correct error messages and no information leakage, one could just skip the first object is missing optimization (it should be pretty rare anyway!) like so: check type of object if object is missing or object is a blob: /* Force the same delay in either case: */ do reachability test including blobs if object is missing or object is not reachable: die(there is no such object) else die(object is not a tree) else do reachability test excluding blobs etc I'm not suggesting that the extra effort is worth it; I just wanted to mention the possibility. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-gui: bring Wish process to front on Mac
On Mac OS X, any application that is started from the Terminal will open
behind all running applications; as a work-around, manually bring ourselves
to the front. (Stolen from gitk, commit 76bf6ff93e.)
We do this as the very first thing, so that any message boxes that might pop
up during the rest of the startup sequence are actually seen by the user.
Signed-off-by: Stefan Haller ste...@haller-berlin.de
---
git-gui.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/git-gui.sh b/git-gui.sh
index e11..c464928 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -29,6 +29,19 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA}]
##
##
+## On Mac, bring the current Wish process window to front
+
+if {[tk windowingsystem] eq aqua} {
+ exec osascript -e [format {
+ tell application System Events
+ set frontmost of processes whose unix id is %d to true
+ end tell
+ } [pid] ]
+}
+
+
+##
+##
## Tcl/Tk sanity check
if {[catch {package require Tcl 8.4} err]
--
1.8.3.14.g33f718c
--
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
Ignoring pattern in un-ignored directory not working anymore
Hey, What I want to do: * ignore certain patterns completely * but keep one important directoy * but not the patterns from the first step that are located within that directory. Concrete example: I'm tracking certain parts of my $HOME including ~/.emacs.d/ -- but I don't want the compiled Emacs Lisp files therein. This used to work until recently, though I'm not sure up to which version excatly. I'm on Arch Linux and therefore usually pretty much up to date. My current git version is 1.8.3. More details and how to reproduce: My ~/.gitignore usually looked like this: --- cut - /* *.elc !/.emacs.d/ --- cut - With this setup the scenario described at the beginning was possible. Now it's not as all files within ~/.emacs.d are always considered regardless of what patterns came before. Not even putting '*.elc' into ~/.emacs.d/.gitignore will work in such a case, even though gitignore(5) seems to imply that .gitignore files closer to the actual file have higher precendence. Here's a copy paste of a simple session demonstrating the problem on a new repo: --- cut - [0 mbunkus@chai-latte ~/tmp/repo] git init Initialized empty Git repository in /home/mbunkus/tmp/repo/.git/ [0 mbunkus@chai-latte (branchless-repo) ~/tmp/repo] cat .gitignore # Ignore all compiled Emacs lisp files *.elc # But I want this one directory !important/ [0 mbunkus@chai-latte (branchless-repo) ~/tmp/repo] mkdir important [0 mbunkus@chai-latte (branchless-repo) ~/tmp/repo] touch important/wanted.el [0 mbunkus@chai-latte (branchless-repo) ~/tmp/repo] git add important [0 mbunkus@chai-latte (branchless-repo) ~/tmp/repo] git commit -m 'all ok' [master (root-commit) 5ab6055] all ok 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 important/wanted.el [0 mbunkus@chai-latte (master) ~/tmp/repo] touch unwanted1.elc [0 mbunkus@chai-latte (master) ~/tmp/repo] touch important/unwanted2.elc [0 mbunkus@chai-latte (master) ~/tmp/repo] git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # .gitignore # important/unwanted2.elc nothing added to commit but untracked files present (use git add to track) [0 mbunkus@chai-latte (master) ~/tmp/repo] cat .gitignore # Second try: list *.elc twice *.elc !important/ *.elc [0 mbunkus@chai-latte (master) ~/tmp/repo] git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # .gitignore # important/unwanted2.elc nothing added to commit but untracked files present (use git add to track) [0 mbunkus@chai-latte (master) ~/tmp/repo] cat .gitignore # Third times' the charm *.elc !important/ important/**/*elc [0 mbunkus@chai-latte (master) ~/tmp/repo] git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # .gitignore # important/unwanted2.elc nothing added to commit but untracked files present (use git add to track) [0 mbunkus@chai-latte (master) ~/tmp/repo] echo '*.elc' important/.gitignore [0 mbunkus@chai-latte (master) ~/tmp/repo] git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # .gitignore # important/.gitignore # important/unwanted2.elc nothing added to commit but untracked files present (use git add to track) --- cut - Kind regards, mosu -- 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 v3 9/9] cherry-pick: don't barf when there's nothing to do
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- sequencer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sequencer.c b/sequencer.c index dd9de49..c3a17f8 100644 --- a/sequencer.c +++ b/sequencer.c @@ -754,8 +754,8 @@ static void prepare_revs(struct replay_opts *opts) if (prepare_revision_walk(opts-revs)) die(_(revision walk setup failed)); - if (!opts-revs-commits) - die(_(empty commit set passed)); + if (!opts-revs-commits !opts-quiet) + error(_(empty commit set passed)); } static void read_and_refresh_cache(struct replay_opts *opts) -- 1.8.3.698.g079b096 -- 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 v3 4/9] cherry-pick: store rewritten commits
Will be useful for the next commits.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 102 +++-
sequencer.h | 1 +
2 files changed, 102 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index d3c7d72..76ff2ff 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -20,6 +20,18 @@
const char sign_off_header[] = Signed-off-by: ;
static const char cherry_picked_prefix[] = (cherry picked from commit ;
+struct rewritten_list_item {
+ unsigned char from[20];
+ unsigned char to[20];
+};
+
+struct rewritten_list {
+ struct rewritten_list_item *items;
+ unsigned int nr, alloc;
+};
+
+static struct rewritten_list rewritten;
+
static int is_rfc2822_line(const char *buf, int len)
{
int i;
@@ -102,6 +114,19 @@ static int has_conforming_footer(struct strbuf *sb, struct
strbuf *sob,
return 1;
}
+static void add_rewritten(unsigned char *from, unsigned char *to)
+{
+ struct rewritten_list_item *item;
+ if (rewritten.nr + 1 = rewritten.alloc) {
+ rewritten.alloc += 32;
+ rewritten.items = xrealloc(rewritten.items, rewritten.alloc *
sizeof(*rewritten.items));
+ }
+ item = rewritten.items[rewritten.nr];
+ hashcpy(item-from, from);
+ hashcpy(item-to, to);
+ rewritten.nr++;
+}
+
static void remove_sequencer_state(void)
{
struct strbuf seq_dir = STRBUF_INIT;
@@ -641,6 +666,14 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
if (!opts-no_commit)
res = run_git_commit(defmsg, opts, allow);
+ if (!res opts-action == REPLAY_PICK) {
+ unsigned char to[20];
+
+ if (read_ref(HEAD, to))
+ goto leave;
+
+ add_rewritten(commit-object.sha1, to);
+ }
leave:
free_message(msg);
free(defmsg);
@@ -786,6 +819,40 @@ static void read_populate_todo(struct commit_list
**todo_list,
die(_(Unusable instruction sheet: %s), todo_file);
}
+static void read_populate_rewritten(void)
+{
+ const char *rewritten_file = git_path(SEQ_REWR_FILE);
+ struct strbuf buf = STRBUF_INIT;
+ char *p;
+ int fd;
+
+ fd = open(rewritten_file, O_RDONLY);
+ if (fd 0)
+ return;
+ if (strbuf_read(buf, fd, 0) 0) {
+ close(fd);
+ strbuf_release(buf);
+ return;
+ }
+ close(fd);
+
+ for (p = buf.buf; *p;) {
+ unsigned char from[20];
+ unsigned char to[20];
+ char *eol = strchrnul(p, '\n');
+ if (eol - p != 81)
+ /* wrong size */
+ break;
+ if (get_sha1_hex(p, from))
+ break;
+ if (get_sha1_hex(p + 41, to))
+ break;
+ add_rewritten(from, to);
+ p = *eol ? eol + 1 : eol;
+ }
+ strbuf_release(buf);
+}
+
static int populate_opts_cb(const char *key, const char *value, void *data)
{
struct replay_opts *opts = data;
@@ -958,6 +1025,29 @@ static void save_todo(struct commit_list *todo_list,
struct replay_opts *opts)
strbuf_release(buf);
}
+static void save_rewritten(void)
+{
+ const char *todo_file = git_path(SEQ_REWR_FILE);
+ static struct lock_file rewritten_lock;
+ struct strbuf buf = STRBUF_INIT;
+ int fd, i;
+
+ fd = hold_lock_file_for_update(rewritten_lock, todo_file,
LOCK_DIE_ON_ERROR);
+ for (i = 0; i rewritten.nr; i++) {
+ struct rewritten_list_item *item = rewritten.items[i];
+ strbuf_addf(buf, %s %s\n, sha1_to_hex(item-from),
sha1_to_hex(item-to));
+ }
+ if (write_in_full(fd, buf.buf, buf.len) 0) {
+ strbuf_release(buf);
+ die_errno(_(Could not write to %s), todo_file);
+ }
+ if (commit_lock_file(rewritten_lock) 0) {
+ strbuf_release(buf);
+ die(_(Error wrapping up %s.), todo_file);
+ }
+ strbuf_release(buf);
+}
+
static void save_opts(struct replay_opts *opts)
{
const char *opts_file = git_path(SEQ_OPTS_FILE);
@@ -1003,8 +1093,11 @@ static int pick_commits(struct commit_list *todo_list,
struct replay_opts *opts)
for (cur = todo_list; cur; cur = cur-next) {
save_todo(cur, opts);
res = do_pick_commit(cur-item, opts);
- if (res)
+ if (res) {
+ if (opts-action == REPLAY_PICK)
+ save_rewritten();
return res;
+ }
}
/*
@@ -1033,6 +1126,8 @@ static int sequencer_continue(struct replay_opts *opts)
return continue_single_pick();
read_populate_opts(opts);
[PATCH v3 2/9] sequencer: trivial fix
We should free objects before leaving.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index b4989ba..f7be7d8 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -628,8 +628,10 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
allow = allow_empty(opts, commit);
- if (allow 0)
- return allow;
+ if (allow 0) {
+ res = allow;
+ goto leave;
+ }
if (!opts-no_commit)
res = run_git_commit(defmsg, opts, allow);
--
1.8.3.698.g079b096
--
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 v3 8/9] revert/cherry-pick: add --skip option
Akin to 'am --skip' and 'rebase --skip'.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-cherry-pick.txt | 1 +
Documentation/git-revert.txt | 1 +
Documentation/sequencer.txt | 3 +++
builtin/revert.c | 6 ++
sequencer.c | 32 +---
sequencer.h | 3 ++-
t/t3510-cherry-pick-sequence.sh | 12
7 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index da0bd81..d95c63c 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -10,6 +10,7 @@ SYNOPSIS
[verse]
'git cherry-pick' [-q] [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
commit...
'git cherry-pick' --continue
+'git cherry-pick' --skip
'git cherry-pick' --quit
'git cherry-pick' --abort
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 98a8e7a..52e146e 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -10,6 +10,7 @@ SYNOPSIS
[verse]
'git revert' [-q] [--[no-]edit] [-n] [-m parent-number] [-s] commit...
'git revert' --continue
+'git revert' --skip
'git revert' --quit
'git revert' --abort
diff --git a/Documentation/sequencer.txt b/Documentation/sequencer.txt
index 5747f44..df2d355 100644
--- a/Documentation/sequencer.txt
+++ b/Documentation/sequencer.txt
@@ -3,6 +3,9 @@
'.git/sequencer'. Can be used to continue after resolving
conflicts in a failed cherry-pick or revert.
+--skip::
+ Skip the current commit, and then continue.
+
--quit::
Forget about the current operation in progress. Can be used
to clear the sequencer state after a failed cherry-pick or
diff --git a/builtin/revert.c b/builtin/revert.c
index ec83748..d3d5600 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -99,11 +99,13 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
int remove_state = 0;
int contin = 0;
int rollback = 0;
+ int skip = 0;
struct option options[] = {
OPT__QUIET(opts-quiet, N_(suppress progress reporting)),
OPT_BOOLEAN(0, quit, remove_state, N_(end revert or
cherry-pick sequence)),
OPT_BOOLEAN(0, continue, contin, N_(resume revert or
cherry-pick sequence)),
OPT_BOOLEAN(0, abort, rollback, N_(cancel revert or
cherry-pick sequence)),
+ OPT_BOOLEAN(0, skip, skip, N_(skip current commit in the
sequence)),
OPT_BOOLEAN('n', no-commit, opts-no_commit, N_(don't
automatically commit)),
OPT_BOOLEAN('e', edit, opts-edit, N_(edit the commit
message)),
OPT_NOOP_NOARG('r', NULL),
@@ -164,6 +166,8 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
opts-subcommand = REPLAY_CONTINUE;
else if (rollback)
opts-subcommand = REPLAY_ROLLBACK;
+ else if (skip)
+ opts-subcommand = REPLAY_SKIP;
else
opts-subcommand = REPLAY_NONE;
@@ -174,6 +178,8 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
this_operation = --quit;
else if (opts-subcommand == REPLAY_CONTINUE)
this_operation = --continue;
+ else if (opts-subcommand == REPLAY_SKIP)
+ this_operation = --skip;
else {
assert(opts-subcommand == REPLAY_ROLLBACK);
this_operation = --abort;
diff --git a/sequencer.c b/sequencer.c
index 4b91bd4..dd9de49 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1181,7 +1181,9 @@ static int continue_single_pick(void)
return run_command_v_opt(argv, RUN_GIT_CMD);
}
-static int sequencer_continue(struct replay_opts *opts)
+static void add_rewritten(unsigned char *from, unsigned char *to);
+
+static int sequencer_continue(struct replay_opts *opts, int skip)
{
struct commit_list *todo_list = NULL;
@@ -1201,7 +1203,7 @@ static int sequencer_continue(struct replay_opts *opts)
}
if (index_differs_from(HEAD, 0))
return error_dirty_index(opts);
- if (opts-action == REPLAY_PICK) {
+ if (opts-action == REPLAY_PICK !skip) {
unsigned char to[20];
if (!read_ref(HEAD, to))
add_rewritten(todo_list-item-object.sha1, to);
@@ -1210,6 +1212,28 @@ static int sequencer_continue(struct replay_opts *opts)
return pick_commits(todo_list, opts);
}
+static int sequencer_skip(struct replay_opts *opts)
+{
+ const char *argv[4]; /* reset --hard HEAD + NULL */
+ struct string_list merge_rr = STRING_LIST_INIT_DUP;
+ int ret;
+
+ if (setup_rerere(merge_rr, 0) = 0) {
+
[PATCH v3 3/9] cherry-pick: add --skip-empty option
Pretty much what it says on the tin.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-cherry-pick.txt | 3 +++
builtin/revert.c| 8
sequencer.c | 6 ++
sequencer.h | 1 +
t/t3508-cherry-pick-many-commits.sh | 13 +
5 files changed, 31 insertions(+)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c205d23..fccd936 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -129,6 +129,9 @@ effect to your index in a row.
redundant commits are ignored. This option overrides that behavior and
creates an empty commit object. Implies `--allow-empty`.
+--skip-empty::
+ Instead of failing, skip commits that are or become empty.
+
--strategy=strategy::
Use the given merge strategy. Should only be used once.
See the MERGE STRATEGIES section in linkgit:git-merge[1]
diff --git a/builtin/revert.c b/builtin/revert.c
index 0401fdb..5a8453d 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -118,6 +118,7 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
OPT_END(),
OPT_END(),
OPT_END(),
+ OPT_END(),
};
if (opts-action == REPLAY_PICK) {
@@ -127,6 +128,7 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
OPT_BOOLEAN(0, allow-empty, opts-allow_empty,
N_(preserve initially empty commits)),
OPT_BOOLEAN(0, allow-empty-message,
opts-allow_empty_message, N_(allow commits with empty messages)),
OPT_BOOLEAN(0, keep-redundant-commits,
opts-keep_redundant_commits, N_(keep redundant, empty commits)),
+ OPT_BOOLEAN(0, skip-empty, opts-skip_empty,
N_(skip empty commits)),
OPT_END(),
};
if (parse_options_concat(options, ARRAY_SIZE(options),
cp_extra))
@@ -144,6 +146,12 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
--abort, rollback,
NULL);
+ verify_opt_mutually_compatible(me,
+ --allow-empty, opts-allow_empty,
+ --skip-empty, opts-skip_empty,
+ --keep-redundant-commits,
opts-keep_redundant_commits,
+ NULL);
+
/* implies allow_empty */
if (opts-keep_redundant_commits)
opts-allow_empty = 1;
diff --git a/sequencer.c b/sequencer.c
index f7be7d8..d3c7d72 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -627,6 +627,12 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
goto leave;
}
+ if (opts-skip_empty is_index_unchanged() == 1) {
+ warning(_(skipping %s... %s),
+ find_unique_abbrev(commit-object.sha1, DEFAULT_ABBREV),
+ msg.subject);
+ goto leave;
+ }
allow = allow_empty(opts, commit);
if (allow 0) {
res = allow;
diff --git a/sequencer.h b/sequencer.h
index 1fc22dc..3b04844 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -34,6 +34,7 @@ struct replay_opts {
int allow_empty;
int allow_empty_message;
int keep_redundant_commits;
+ int skip_empty;
int mainline;
diff --git a/t/t3508-cherry-pick-many-commits.sh
b/t/t3508-cherry-pick-many-commits.sh
index 19c99d7..3dc19c6 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -187,4 +187,17 @@ test_expect_success 'cherry-pick --stdin works' '
check_head_differs_from fourth
'
+test_expect_success 'cherry-pick skip empty' '
+ git clean -fxd
+ git checkout -b empty fourth
+ git commit --allow-empty -m empty
+ test_commit ontop
+ git checkout -f master
+ git reset --hard fourth
+ git cherry-pick --skip-empty fourth..empty
+ echo ontop expected
+ git log --format=%s fourth..HEAD actual
+ test_cmp expected actual
+'
+
test_done
--
1.8.3.698.g079b096
--
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 v3 6/9] cherry-pick: add support to copy notes
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 74480d7..6d13e63 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -14,6 +14,7 @@
#include merge-recursive.h
#include refs.h
#include argv-array.h
+#include builtin.h
#define GIT_REFLOG_ACTION GIT_REFLOG_ACTION
@@ -158,6 +159,32 @@ static void run_rewrite_hook(const char *name)
finish_command(proc);
}
+static void copy_notes(const char *name)
+{
+ struct notes_rewrite_cfg *cfg;
+ int i;
+
+ cfg = init_copy_notes_for_rewrite(name);
+ if (!cfg)
+ return;
+
+ for (i = 0; i rewritten.nr; i++) {
+ struct rewritten_list_item *item = rewritten.items[i];
+ copy_note_for_rewrite(cfg, item-from, item-to);
+ }
+
+ finish_copy_notes_for_rewrite(cfg);
+}
+
+static void finish(struct replay_opts *opts)
+{
+ if (opts-action != REPLAY_PICK)
+ return;
+
+ run_rewrite_hook(cherry-pick);
+ copy_notes(cherry-pick);
+}
+
static void remove_sequencer_state(void)
{
struct strbuf seq_dir = STRBUF_INIT;
@@ -1131,8 +1158,7 @@ static int pick_commits(struct commit_list *todo_list,
struct replay_opts *opts)
}
}
- if (opts-action == REPLAY_PICK)
- run_rewrite_hook(cherry-pick);
+ finish(opts);
/*
* Sequence of picks finished successfully; cleanup by
@@ -1188,8 +1214,7 @@ static int single_pick(struct commit *cmit, struct
replay_opts *opts)
ret = do_pick_commit(cmit, opts);
if (ret)
return ret;
- if (opts-action == REPLAY_PICK)
- run_rewrite_hook(cherry-pick);
+ finish(opts);
return 0;
}
--
1.8.3.698.g079b096
--
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 v3 5/9] sequencer: run post-rewrite hook
As we should.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index 76ff2ff..74480d7 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -127,6 +127,37 @@ static void add_rewritten(unsigned char *from, unsigned
char *to)
rewritten.nr++;
}
+static void run_rewrite_hook(const char *name)
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct child_process proc;
+ const char *argv[3];
+ int code, i;
+
+ argv[0] = find_hook(post-rewrite);
+ if (!argv[0])
+ return;
+
+ argv[1] = name;
+ argv[2] = NULL;
+
+ memset(proc, 0, sizeof(proc));
+ proc.argv = argv;
+ proc.in = -1;
+ proc.stdout_to_stderr = 1;
+
+ code = start_command(proc);
+ if (code)
+ return;
+ for (i = 0; i rewritten.nr; i++) {
+ struct rewritten_list_item *item = rewritten.items[i];
+ strbuf_addf(buf, %s %s\n, sha1_to_hex(item-from),
sha1_to_hex(item-to));
+ }
+ write_in_full(proc.in, buf.buf, buf.len);
+ close(proc.in);
+ finish_command(proc);
+}
+
static void remove_sequencer_state(void)
{
struct strbuf seq_dir = STRBUF_INIT;
@@ -1100,6 +1131,9 @@ static int pick_commits(struct commit_list *todo_list,
struct replay_opts *opts)
}
}
+ if (opts-action == REPLAY_PICK)
+ run_rewrite_hook(cherry-pick);
+
/*
* Sequence of picks finished successfully; cleanup by
* removing the .git/sequencer directory
@@ -1149,8 +1183,14 @@ static int sequencer_continue(struct replay_opts *opts)
static int single_pick(struct commit *cmit, struct replay_opts *opts)
{
+ int ret;
setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
- return do_pick_commit(cmit, opts);
+ ret = do_pick_commit(cmit, opts);
+ if (ret)
+ return ret;
+ if (opts-action == REPLAY_PICK)
+ run_rewrite_hook(cherry-pick);
+ return 0;
}
int sequencer_pick_revisions(struct replay_opts *opts)
--
1.8.3.698.g079b096
--
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 v3 7/9] revert/cherry-pick: add --quiet option
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-cherry-pick.txt | 6 +-
Documentation/git-revert.txt | 6 +-
builtin/revert.c | 1 +
sequencer.c | 9 ++---
sequencer.h | 1 +
5 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index fccd936..da0bd81 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -8,7 +8,7 @@ git-cherry-pick - Apply the changes introduced by some existing
commits
SYNOPSIS
[verse]
-'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] commit...
+'git cherry-pick' [-q] [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
commit...
'git cherry-pick' --continue
'git cherry-pick' --quit
'git cherry-pick' --abort
@@ -51,6 +51,10 @@ OPTIONS
feed all commit... arguments to a single revision walk
(see a later example that uses 'maint master..next').
+-q::
+--quiet::
+ Quiet, suppress feedback messages.
+
-e::
--edit::
With this option, 'git cherry-pick' will let you edit the commit
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index f79c9d8..98a8e7a 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -8,7 +8,7 @@ git-revert - Revert some existing commits
SYNOPSIS
[verse]
-'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] commit...
+'git revert' [-q] [--[no-]edit] [-n] [-m parent-number] [-s] commit...
'git revert' --continue
'git revert' --quit
'git revert' --abort
@@ -40,6 +40,10 @@ OPTIONS
default, see linkgit:git-rev-list[1] and its '--no-walk'
option.
+-q::
+--quiet::
+ Quiet, suppress feedback messages.
+
-e::
--edit::
With this option, 'git revert' will let you edit the commit
diff --git a/builtin/revert.c b/builtin/revert.c
index 5a8453d..ec83748 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -100,6 +100,7 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
int contin = 0;
int rollback = 0;
struct option options[] = {
+ OPT__QUIET(opts-quiet, N_(suppress progress reporting)),
OPT_BOOLEAN(0, quit, remove_state, N_(end revert or
cherry-pick sequence)),
OPT_BOOLEAN(0, continue, contin, N_(resume revert or
cherry-pick sequence)),
OPT_BOOLEAN(0, abort, rollback, N_(cancel revert or
cherry-pick sequence)),
diff --git a/sequencer.c b/sequencer.c
index 6d13e63..4b91bd4 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -472,6 +472,8 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
argv_array_init(array);
argv_array_push(array, commit);
argv_array_push(array, -n);
+ if (opts-quiet)
+ argv_array_push(array, -q);
if (opts-signoff)
argv_array_push(array, -s);
@@ -711,9 +713,10 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
if (opts-skip_empty is_index_unchanged() == 1) {
- warning(_(skipping %s... %s),
- find_unique_abbrev(commit-object.sha1, DEFAULT_ABBREV),
- msg.subject);
+ if (!opts-quiet)
+ warning(_(skipping %s... %s),
+ find_unique_abbrev(commit-object.sha1,
DEFAULT_ABBREV),
+ msg.subject);
goto leave;
}
allow = allow_empty(opts, commit);
diff --git a/sequencer.h b/sequencer.h
index 84b9957..6fc416d 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -36,6 +36,7 @@ struct replay_opts {
int allow_empty_message;
int keep_redundant_commits;
int skip_empty;
+ int quiet;
int mainline;
--
1.8.3.698.g079b096
--
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 v3 1/9] sequencer: remove useless indentation
By using good ol' goto.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index ab6f8a7..b4989ba 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -474,7 +474,7 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
struct commit_message msg = { NULL, NULL, NULL, NULL, NULL };
char *defmsg = NULL;
struct strbuf msgbuf = STRBUF_INIT;
- int res, unborn = 0;
+ int res, unborn = 0, allow;
if (opts-no_commit) {
/*
@@ -624,14 +624,16 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
msg.subject);
print_advice(res == 1, opts);
rerere(opts-allow_rerere_auto);
- } else {
- int allow = allow_empty(opts, commit);
- if (allow 0)
- return allow;
- if (!opts-no_commit)
- res = run_git_commit(defmsg, opts, allow);
+ goto leave;
}
+ allow = allow_empty(opts, commit);
+ if (allow 0)
+ return allow;
+ if (!opts-no_commit)
+ res = run_git_commit(defmsg, opts, allow);
+
+leave:
free_message(msg);
free(defmsg);
--
1.8.3.698.g079b096
--
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 v3 0/9] cherry-pick: improvements
Hi, Sames as v2, plus a few changes from the feedback, and cleanups. Felipe Contreras (9): sequencer: remove useless indentation sequencer: trivial fix cherry-pick: add --skip-empty option cherry-pick: store rewritten commits sequencer: run post-rewrite hook cherry-pick: add support to copy notes revert/cherry-pick: add --quiet option revert/cherry-pick: add --skip option cherry-pick: don't barf when there's nothing to do Documentation/git-cherry-pick.txt | 10 +- Documentation/git-revert.txt| 7 +- Documentation/sequencer.txt | 3 + builtin/revert.c| 15 +++ sequencer.c | 230 ++-- sequencer.h | 6 +- t/t3508-cherry-pick-many-commits.sh | 13 ++ t/t3510-cherry-pick-sequence.sh | 12 ++ 8 files changed, 280 insertions(+), 16 deletions(-) -- 1.8.3.698.g079b096 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] completion: add common options for blame
Ramkumar Ramachandra: Yeah. We generally prefer the long-form equivalents while doing completions, but these blame options do not have equivalent long-forms. Perhaps that is the real bug, then. -M and -C already have long names for diff (and its friends), perhaps blame should have the same long option names for them? -- \\// Peter - http://www.softwolves.pp.se/ -- 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 v3 6/9] cherry-pick: add support to copy notes
On Thu, Jun 6, 2013 at 3:59 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 74480d7..6d13e63 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -14,6 +14,7 @@
#include merge-recursive.h
#include refs.h
#include argv-array.h
+#include builtin.h
#define GIT_REFLOG_ACTION GIT_REFLOG_ACTION
@@ -158,6 +159,32 @@ static void run_rewrite_hook(const char *name)
finish_command(proc);
}
+static void copy_notes(const char *name)
+{
+ struct notes_rewrite_cfg *cfg;
+ int i;
+
+ cfg = init_copy_notes_for_rewrite(name);
+ if (!cfg)
+ return;
+
+ for (i = 0; i rewritten.nr; i++) {
+ struct rewritten_list_item *item = rewritten.items[i];
+ copy_note_for_rewrite(cfg, item-from, item-to);
+ }
+
+ finish_copy_notes_for_rewrite(cfg);
+}
Unfortunately this doesn't work, because all these functions are part
of the builtins, not git lib.
--
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: [Administrivia] On ruby and contrib/
On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png I don't think the usefulness of a language should be judged by hits on a web site. Personally I would like the Git client to be packaged with as few dependencies as possible. Right now that seems to require Shell, Sed, Awk and Perl. The documentation has other requirements, but a prebuild tar file is available. I would have the rest of the distribution be bundled as something like git-utils which could have a subdirectory for each support language. Then one could even make available alternative implementations of higher level utilities and people could decide if support of a specific language was useful to them. Most such extension code is simple, although more complex than suitable for just Shell/Sed/Awk. People in each language community could provide code which meets the needs of their community, and the Git project itself would not need to make (Solomon like) decisions about what extension languages to support. -- Barry Fishman -- 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: [Administrivia] On ruby and contrib/
Michael Haggerty mhag...@alum.mit.edu writes: * at the source-code level, a tool in contrib can take advantage of some of the Git build/test infrastructure, though I don't know whether they currently do. They do not do much AFAICT. For example, contrib/subtree/t/Makefile is essentially copy-pasted from Git's equivalent. But they can do to some extend, for example make install in contrib/mw-to-git/ re-uses Git's Makefile to hardcode the PERL_PATH in the file, find Git's exec-path so. I'd love to be able to use Documentation/Makefile and t/Makefile too for external programs meant to be used as a Git command. That does not strictly imply that these commands be maintained within git.git, as we could imagine: * Ask the user to build external programs with make GIT_ROOT=where/git/lives/ * or, ask users to checkout the external program as a subdirectory of git.git to build it (for example, clang's build installation ask you to put clang as a subdirectory of LLVM's tree). But my main point is that I think it would be easier to phase out contrib/ if there were a good alternate way of providing visibility to satellite projects. [...] Perhaps ranking the tools based on the results of the Git user surveys would help bring the most popular to the top of each category. I think this is the most important point. A good example would be git-multimail: for now, the shell version in contrib/ is somehow considered as the official hook to send emails, just because it is in contrib, while git-multimail is clearly superior (unless you don't have a python interpreter on your server). I also see contrib/ as a safe place to live, in that the likeliness for the project to be abandonned is rather small. Especially for small pieces of code, it's easy to create a repo and throw the code somewhere on GitHub, but maintaining it is harder. Take again the example of post-receive-email, the code was originally written by Andy Parkins, but the community took over it (Andy's last commit on the script was in 2008). I'm not sure this would have been so easy with a script hosted on an arbitrary repo. I'm not opposed to Junio's proposal to restrict contrib/ (although a bit reluctant), but I think this should be done with care, at least to give potential users a way to chose which tool to use (really, nobody want to go use https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools to pick the right tool. It's a great list, but not a guide). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman barry_fish...@acm.org wrote: On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png I don't think the usefulness of a language should be judged by hits on a web site. Nobody is judging the usefulness of a language, I have plenty of arguments for that, but this is about popularity. Personally I would like the Git client to be packaged with as few dependencies as possible. Right now that seems to require Shell, Sed, Awk and Perl. The documentation has other requirements, but a prebuild tar file is available. I would be perfectly fine with replacing shell, sed, awk and perl with ruby. But that's not what you are arguing, is 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: [Administrivia] On ruby and contrib/
On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman barry_fish...@acm.org wrote: On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png I don't think the usefulness of a language should be judged by hits on a web site. Nobody is judging the usefulness of a language, I have plenty of arguments for that, but this is about popularity. I used usefulness in its general vague sense. It is useful to be popular, I don't make choices solely on that or I would be writing everything in Java. Personally I would like the Git client to be packaged with as few dependencies as possible. Right now that seems to require Shell, Sed, Awk and Perl. The documentation has other requirements, but a prebuild tar file is available. I would be perfectly fine with replacing shell, sed, awk and perl with ruby. But that's not what you are arguing, is it? I'm talking about porcelain code and not core functionality which should be left in C. I'm saying that you should be free to provide Ruby implementations of all such superstructure. And the same can be done by (but not required by) the Perl, Python, Tcl and even C, Haskel, Guile and whatever communities. Most such higher level code is fairly trivial, and if the file names are kept the same, the same test procedures could be run. I don't think the cost of duplication of code functionality is that significant, since it would bring new people to the project. After all this is a free project and not a commerical venture. It certainly helps porting to new platforms. Separate language communities would be maintaining their own contributions, with their own experimental directories. Translating the same functionality to multiple languages requires careful reading which can help identify some hidden bugs. -- Barry Fishman -- 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: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 8:46 AM, Barry Fishman barry_fish...@acm.org wrote: On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote: Nobody is judging the usefulness of a language, I have plenty of arguments for that, but this is about popularity. I used usefulness in its general vague sense. It is useful to be popular, I don't make choices solely on that or I would be writing everything in Java. Straw man. Personally I would like the Git client to be packaged with as few dependencies as possible. Right now that seems to require Shell, Sed, Awk and Perl. The documentation has other requirements, but a prebuild tar file is available. I would be perfectly fine with replacing shell, sed, awk and perl with ruby. But that's not what you are arguing, is it? I don't know what you are saying, but it clearly has nothing to do with the point. Perl is declining, and it would be wise to use another language instead of 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] git-gui: bring Wish process to front on Mac
On 6 June 2013 09:17, Stefan Haller ste...@haller-berlin.de wrote:
On Mac OS X, any application that is started from the Terminal will open
behind all running applications; as a work-around, manually bring ourselves
to the front. (Stolen from gitk, commit 76bf6ff93e.)
We do this as the very first thing, so that any message boxes that might pop
up during the rest of the startup sequence are actually seen by the user.
Signed-off-by: Stefan Haller ste...@haller-berlin.de
---
git-gui.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/git-gui.sh b/git-gui.sh
index e11..c464928 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -29,6 +29,19 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA}]
##
##
+## On Mac, bring the current Wish process window to front
+
+if {[tk windowingsystem] eq aqua} {
+ exec osascript -e [format {
+ tell application System Events
+ set frontmost of processes whose unix id is %d to true
+ end tell
+ } [pid] ]
+}
+
+
+##
+##
## Tcl/Tk sanity check
if {[catch {package require Tcl 8.4} err]
--
1.8.3.14.g33f718c
Seems fine to me. I can't test this as I have no access to this
platform. Possibly you should run this in a catch statement so it can
ignore any errors and I would tend to use the 'auto_execok' command to
ensure that osascript actually exists. Something like
set arg [format {tell application..}]
catch {exec {*}[auto_execok osascript] -e $arg [pid]}
but possibly this is guaranteed to exist on all macs which would make
the above redundant. What I'm thinking is you dont want the app to
exit just because something goes wrong in this call.
--
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: [Administrivia] On ruby and contrib/
On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote: I don't know what you are saying, but it clearly has nothing to do with the point. Perl is declining, and it would be wise to use another language instead of it. You want a simple statement. I don't particulary like Perl, but it has worked well for the project. If you have a better solution, then write all the code to replace it, and demonstrate with a significant number of active users that your solution works out better in practice. Wasn't that how Git started? -- Barry Fishman -- 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: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 9:41 AM, Barry Fishman barry_fish...@acm.org wrote: On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote: I don't know what you are saying, but it clearly has nothing to do with the point. Perl is declining, and it would be wise to use another language instead of it. You want a simple statement. I don't particulary like Perl, but it has worked well for the project. It would serve it less and less as the years go by. If you have a better solution, then write all the code to replace it, False dichotomy fallacy. I don't need to 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: [PATCH] git-gui: bring Wish process to front on Mac
Pat Thoyts pattho...@gmail.com wrote:
On 6 June 2013 09:17, Stefan Haller ste...@haller-berlin.de wrote:
+## On Mac, bring the current Wish process window to front
+
+if {[tk windowingsystem] eq aqua} {
+ exec osascript -e [format {
+ tell application System Events
+ set frontmost of processes whose unix id is %d to
true
+ end tell
+ } [pid] ]
+}
Seems fine to me. I can't test this as I have no access to this
platform. Possibly you should run this in a catch statement so it can
ignore any errors and I would tend to use the 'auto_execok' command to
ensure that osascript actually exists. Something like
set arg [format {tell application..}]
catch {exec {*}[auto_execok osascript] -e $arg [pid]}
but possibly this is guaranteed to exist on all macs which would make
the above redundant. What I'm thinking is you dont want the app to
exit just because something goes wrong in this call.
I don't think we need auto_execok here, as osascript is available on
every Mac system. We might even specify the exact path, it's always
/usr/bin/osascript. Is that preferable?
I agree that catch might be a good idea though. It raises two
questions though:
1) Should we make the same change in gitk then? It already has the same
code without the catch (released in 1.8.3 already, btw).
2) Should we think about some way of sharing code between gitk and
git gui, so that these kinds of changes don't have to be made twice?
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
--
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: [Administrivia] On ruby and contrib/
On Thu, 6 Jun 2013, Felipe Contreras wrote: In the end my point remains unchanged; Perl is declining, so it would be wise for the future to use another scripting language instead. Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? what's the ROI of this? Perl isn't going to disappear any time soon. What makes you think that whatever language you pick to replace Perl is going to be more stable than Perl is? and, like the parent poster, by 'stable' I mean from the compatibility point of view. What are the odds that the 'newer' language that you pick is going to pull a python 3 on you? There have been a very large number of scripting languages show up, make a lot of press, and then fade in favor of other languages while Perl has continued. It's not the sexy languange nowdays, but it's there, reliable, and used so heavily that there's really no chance of it dissapearing in the forseable future. David Lang -- 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: [Administrivia] On ruby and contrib/
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel g...@ir.bbn.com wrote:
git is a core tool that people use on almost the smallest of boxes,
perhaps even replacing rcs for managing local config files. On such
machines, even perl may be large, but a second scripting language seems
excessive.
You can compile Git without any of them.
That ignores the 99% of people who use packaged versions. The question
is really Should the standared approach for building be to use or not
use dependency X?. Really this should be expressed in the README, and
it creates expectations for someone who just installs the git package in
terms of whether pieces of functionality are there. Packagers generally
should be reading the README and including required/recommended
dependencies and not including optional dependencies (in the main
package). The information in INSTALL is pretty reasonable, but it
doesn't really clearly say if you hand someone git built without perl,
it is { perfectly ok but missing a fringe optional feature | deficient
because git add -p won't work }. I'm leaning towards the deficient
camp.
So you can compile git without X should really translate into when
one runs the default build following the instructions, and does not take
affirmative steps to use X, X should not be used or depended on. If it
doesn't mean that, it doesn't help the packaging/expectations discussion.
It's of course fine that one can hand-compile a smaller than standard
but still useful subset. But that's entirely different from the
definition of normal.
On a NetBSD 6 i386 system, the size of the ruby193-base
binary package (as installed) is 25 MB (vs 15 MB for the git base
package, which lacks gitk and docs). (Presently, the git base package
defaults to requiring python and installing the git_remote_helpers, but
I think that's a bug.) perl is 54 MB.
That's only the default, if the default doesn't suit you, don't use
the default.
It's not about what I want. It's about making choices that affect other
people, and trying to find a plan that will be overall reasonable;
that's the essence of stewardship in packaging. Compiling for just
myself is far easier.
pgpEWOFl1E9Ut.pgp
Description: PGP signature
Re: [PATCH] t0005: skip signal death exit code test on Windows
Jeff King p...@peff.net writes: On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote: Thanks. I wasn't quite clear on how the signal handling worked on Windows, but from your description, I agree there is not any point in running the test at all. Shouldn't we clarify that Git exit codes only work on UNIX-like operating systems? Clarify where? My impression is that this issue is well-known in the msys world, and it is a platform issue, not a git issue. I actually was scratching my head while reading the implementation of raise() just calls exit(3). part, in this: The particular deficiency is that when a signal is raise()d whose SIG_DFL action will cause process death (SIGTERM in this case), the implementation of raise() just calls exit(3). After a bit of web searching, it seems to me that this behaviour of raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls that. In other words, the implementation of raise() is at an even lower level than mingw/msys, and I would agree that it is a platform issue. If somebody wants to write a note somewhere in the git documentation, that's fine with me, but I'm not clear on exactly what it would even say. I agree with both points. I can suggest to clarify the log message a bit with the implementation of raise() in msvcrt (Microsoft C Runtime library) just calls exit(3), but that does not address the end-user documentation issue. I tried to summarize the issue for end-user documentation and came up with this: The Git implementation on MinGW exits with status code 3 upon receiving an uncaught process-terminating signal, just like any program that link with msvcrt (Microsoft C Runtime library) whose raise() implementation just calls exit(3). This is different from Git on POSIX, which reports a death by receiving a signal with the exit status code (128 + signal number). But when stated this way, it feels that it belongs to Msysgit documentation, not ours, at least to me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/4] real reachability checks for upload-archive
Jeff King p...@peff.net writes: On Wed, Jun 05, 2013 at 12:38:23PM -0400, Jeff King wrote: 2. Actually do a reachability check. Doing a full object check to allow fetching an arbitrary tree by sha1 is probably prohibitively expensive[2], but we could allow the form commit[:path], check that commit is reachable, and then allow arbitrary paths within it. Thinking on this more, the full reachability check is no worse than what a clone has to do to fetch the full repository. Here's a series that does the full check. I'm not entirely happy with the performance, though; details are in patch 3. For some repository-servers, it may be OK to enable this by default, but I suspect it would be better to have at least an opt-out server configuration. I think I'd be tempted to just go the more limiting commit is reachable route, instead, which would solve your case (and most sane cases). Yes, I think that is a reasonable thing to do. After all, as you noted in 4/4, you cannot ask for a single blob, and not being able to ask for a single tree is not much different. [1/4]: clear parsed flag when we free tree buffers [2/4]: upload-archive: restrict remote objects with reachability check [3/4]: list-objects: optimize revs-blob_objects = 0 case [4/4]: archive: ignore blob objects when checking reachability -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0005: skip signal death exit code test on Windows
On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote: The particular deficiency is that when a signal is raise()d whose SIG_DFL action will cause process death (SIGTERM in this case), the implementation of raise() just calls exit(3). After a bit of web searching, it seems to me that this behaviour of raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls that. In other words, the implementation of raise() is at an even lower level than mingw/msys, and I would agree that it is a platform issue. Yeah, if it were mingw_raise responsible for this, I would suggest using the POSIX shell 128+sig instead. We could potentially check for SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if that would create headaches or confusion for other msys programs, though. I'd leave that up to the msysgit people to decide whether it is worth the trouble. [1] I'd use sigaction to do that on POSIX, but I would not be surprised to find that there is no support for it in msys. :) I tried to summarize the issue for end-user documentation and came up with this: The Git implementation on MinGW exits with status code 3 upon receiving an uncaught process-terminating signal, just like any program that link with msvcrt (Microsoft C Runtime library) whose raise() implementation just calls exit(3). This is different from Git on POSIX, which reports a death by receiving a signal with the exit status code (128 + signal number). But when stated this way, it feels that it belongs to Msysgit documentation, not ours, at least to me. Yeah, I think I agree. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] clear parsed flag when we free tree buffers
Jeff King p...@peff.net writes:
Many code paths will free a tree object's buffer and set it
to NULL after finishing with it in order to keep memory
usage down during a traversal. However, out of 8 sites that
do this, only one actually unsets the parsed flag back.
Those sites that don't are setting a trap for later users of
the tree object; even after calling parse_tree, the buffer
will remain NULL, causing potential segfaults.
It is not known whether this is triggerable in the current
code. Most commands do not do an in-memory traversal
followed by actually using the objects again. However, it
does not hurt to be safe for future callers.
In most cases, we can abstract this out to a
free_tree_buffer helper. However, there are two
exceptions:
1. The fsck code relies on the parsed flag to know that we
were able to parse the object at one point. We can
switch this to using a flag in the flags field.
2. The index-pack code sets the buffer to NULL but does
not free it (it is freed by a caller). We should still
unset the parsed flag here, but we cannot use our
helper, as we do not want to free the buffer.
Signed-off-by: Jeff King p...@peff.net
---
This shouldn't have any behavior change, but I'd worry a bit that I
missed some case in builtin/fsck.c where the new HAS_OBJ flag would need
set.
check-unreachable-object?
I am wondering if you can use SEEN which is already there, or at
least set HAS_OBJ at the same place where SEEN is set.
The overall structure of fsck is:
* we scan objects we see in the object store; they are marked with
SEEN to avoid duplicated work in fsck_obj() and this scanning
does not have anything to do with connectivity; then
* we traverse connectivity graph from the starting points (refs,
index, etc.).
and this obj-parsed check is used in the latter phase, so...
An unrelated tangent.
I suspect that 271b8d25b25 made a copypaste error to broken link
message in builtin/fsck.c while looking at this patch, by the way.
The lookup_object() to compute the first parameter given to the
callback in fsck_walk() returned NULL case has two from; the
latter should be to (and I think in the longer term the function
signature of the callback needs to be enhanced to let us tell what
object name we found in parent that failed to give us an object).
builtin/fsck.c | 17 -
builtin/index-pack.c | 1 +
builtin/reflog.c | 3 +--
http-push.c | 3 +--
list-objects.c | 3 +--
reachable.c | 3 +--
revision.c | 3 +--
tree.c | 8
tree.h | 1 +
walker.c | 5 +
10 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index bb9a2cd..579fdcc 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -16,6 +16,7 @@
#define REACHABLE 0x0001
#define SEEN 0x0002
+#define HAS_OBJ 0x0004
static int show_root;
static int show_tags;
@@ -101,7 +102,7 @@ static int mark_object(struct object *obj, int type, void
*data)
if (obj-flags REACHABLE)
return 0;
obj-flags |= REACHABLE;
- if (!obj-parsed) {
+ if (!(obj-flags HAS_OBJ)) {
if (parent !has_sha1_file(obj-sha1)) {
printf(broken link from %7s %s\n,
typename(parent-type),
sha1_to_hex(parent-sha1));
@@ -127,16 +128,13 @@ static int traverse_one_object(struct object *obj)
struct tree *tree = NULL;
if (obj-type == OBJ_TREE) {
- obj-parsed = 0;
tree = (struct tree *)obj;
if (parse_tree(tree) 0)
return 1; /* error already displayed */
}
result = fsck_walk(obj, mark_object, obj);
- if (tree) {
- free(tree-buffer);
- tree-buffer = NULL;
- }
+ if (tree)
+ free_tree_buffer(tree);
return result;
}
@@ -178,7 +176,7 @@ static void check_reachable_object(struct object *obj)
* except if it was in a pack-file and we didn't
* do a full fsck
*/
- if (!obj-parsed) {
+ if (!(obj-flags HAS_OBJ)) {
if (has_sha1_pack(obj-sha1))
return; /* it is in pack - forget about it */
printf(missing %s %s\n, typename(obj-type),
sha1_to_hex(obj-sha1));
@@ -306,8 +304,7 @@ static int fsck_obj(struct object *obj)
if (obj-type == OBJ_TREE) {
struct tree *item = (struct tree *) obj;
- free(item-buffer);
- item-buffer = NULL;
+ free_tree_buffer(item);
}
if (obj-type == OBJ_COMMIT) {
@@ -340,6 +337,7 @@ static int fsck_sha1(const unsigned char *sha1)
return error(%s: object corrupt or missing,
sha1_to_hex(sha1));
}
+ obj-flags |= HAS_OBJ;
return
Re: [PATCH/RFC] add --authorship-order flag to git log / rev-list
On Tue, Jun 4, 2013 at 2:53 PM, Junio C Hamano gits...@pobox.com wrote: After reading the subject alone, my reaction was is this sorting commits by the name of the author? That is one of the expected natural reactions when people hear about this option, which is not what you want. Perhaps naming it --authordate-order (or enhance the command line parsing to allow --date-order=author|committer) would give us a better UI. The same comment was raised by someone in IRC when I submitted an RFC on this. The conclusion we'd arrived at, IIRC, was that the only remotely-not-ugly solutions were either --authorship-order or --author-date-order. I really like the idea of [--date-order[=author|committer]], but that's getting beyond my knowledge of the code-base. Perhaps I should just implement the changes to the implementation in *my* revision of the patch, and leave it up to a future patcher with the requisite knowledge of the argumentation features to throw in the changes to that flag quickly? Either that, or implement it as --author-date-order right *now*, and change it later before it hits Master (so we don't end up with a no-longer-supported feature?) (It'd take me many hours to track down the details of how git's codebase goes around doing that, and then attempting to replicate it, whereas someone familiar could probably do it in fifteen minutes, hence the thought-process. Commentary welcome.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-gui: bring Wish process to front on Mac
Pat Thoyts pattho...@gmail.com writes:
Seems fine to me. I can't test this as I have no access to this
platform. Possibly you should run this in a catch statement so it can
ignore any errors and I would tend to use the 'auto_execok' command to
ensure that osascript actually exists. Something like
set arg [format {tell application..}]
catch {exec {*}[auto_execok osascript] -e $arg [pid]}
but possibly this is guaranteed to exist on all macs which would make
the above redundant. What I'm thinking is you dont want the app to
exit just because something goes wrong in this call.
Sounds like a sensible concern; gitk in v1.8.3 has it without catch
so we may see failure reports from OSX users soonish, in which case
both this patch and gitk need to be updated for it.
Stefan (as your name appears in 76bf6ff93e, I am assuming that you
were the OSX-osascript guru in that commit) could you keep an eye on
the list traffic to see if users of latest gitk have issues with
that change, please?
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 11:09 AM, David Lang da...@lang.hm wrote: On Thu, 6 Jun 2013, Felipe Contreras wrote: In the end my point remains unchanged; Perl is declining, so it would be wise for the future to use another scripting language instead. Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? But that's exactly what we are asking the newer generations of developers; to learn another language. Fewer and fewer new contributors will come with knowledge of Perl. What are the odds that the 'newer' language that you pick is going to pull a python 3 on you? Ruby 2 speaks volumes on that front. There have been a very large number of scripting languages show up, make a lot of press, and then fade in favor of other languages while Perl has continued. It's not the sexy languange nowdays, but it's there, reliable, and used so heavily that there's really no chance of it dissapearing in the forseable future. Yet it's declining, more and more every year. And the more the time goes by, the more we hurt ourselves. -- 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: Ignoring pattern in un-ignored directory not working anymore
Moritz Bunkus mor...@bunkus.org writes: This used to work until recently, though I'm not sure up to which version excatly. I'm on Arch Linux and therefore usually pretty much up to date. My current git version is 1.8.3. Could you test if 'master' at 3684101a654d (Merge branch 'kb/status-ignored-optim-2', 2013-06-03) or later fixes it? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 12:16 PM, Greg Troxel g...@ir.bbn.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel g...@ir.bbn.com wrote: git is a core tool that people use on almost the smallest of boxes, perhaps even replacing rcs for managing local config files. On such machines, even perl may be large, but a second scripting language seems excessive. You can compile Git without any of them. That ignores the 99% of people who use packaged versions. The 99% of people who use packaged versions wouldn't care about the additional dependency. On a NetBSD 6 i386 system, the size of the ruby193-base binary package (as installed) is 25 MB (vs 15 MB for the git base package, which lacks gitk and docs). (Presently, the git base package defaults to requiring python and installing the git_remote_helpers, but I think that's a bug.) perl is 54 MB. That's only the default, if the default doesn't suit you, don't use the default. It's not about what I want. It is exactly about what you want. You use the argument that 99% of the people use packaged versions, yet you ignore the fact that 99% of the people don't care about a single extra dependency (specially one that would be transitory). It is all about 1% of the users, in fact, not even that, because of this 1% of users who dread extra dependencies, most of them would be happy that it's only temporary, and eventually a heavier dependency would be replaced with a lighter one. It is for all intents and purposes only you, the person you are speaking on behalf of. If the Git project considers a new dependency that would be needed in addition to Perl for a finite period of time, your argument does absolutely nothing to block this route. -- 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 v3 3/9] cherry-pick: add --skip-empty option
Felipe Contreras felipe.contre...@gmail.com writes:
Pretty much what it says on the tin.
And a bit more, isn't it?
The --keep-redundant-commits option implies the --allow-empty option
and it was perfectly acceptable to give both. By making sure that
only at most one of -k-r-d, -a-e or -s-e is given, this forbids that
usage.
It is implied so there is no *need* to give it redundantly is
different from It is implied so you shouldn't give it redundantly.
Like 7 and 8 that adds --quiet/--skip, don't we want this also for
revert?
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-cherry-pick.txt | 3 +++
builtin/revert.c| 8
sequencer.c | 6 ++
sequencer.h | 1 +
t/t3508-cherry-pick-many-commits.sh | 13 +
5 files changed, 31 insertions(+)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c205d23..fccd936 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -129,6 +129,9 @@ effect to your index in a row.
redundant commits are ignored. This option overrides that behavior and
creates an empty commit object. Implies `--allow-empty`.
+--skip-empty::
+ Instead of failing, skip commits that are or become empty.
+
--strategy=strategy::
Use the given merge strategy. Should only be used once.
See the MERGE STRATEGIES section in linkgit:git-merge[1]
diff --git a/builtin/revert.c b/builtin/revert.c
index 0401fdb..5a8453d 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -118,6 +118,7 @@ static void parse_args(int argc, const char **argv,
struct replay_opts *opts)
OPT_END(),
OPT_END(),
OPT_END(),
+ OPT_END(),
};
if (opts-action == REPLAY_PICK) {
@@ -127,6 +128,7 @@ static void parse_args(int argc, const char **argv,
struct replay_opts *opts)
OPT_BOOLEAN(0, allow-empty, opts-allow_empty,
N_(preserve initially empty commits)),
OPT_BOOLEAN(0, allow-empty-message,
opts-allow_empty_message, N_(allow commits with empty messages)),
OPT_BOOLEAN(0, keep-redundant-commits,
opts-keep_redundant_commits, N_(keep redundant, empty commits)),
+ OPT_BOOLEAN(0, skip-empty, opts-skip_empty,
N_(skip empty commits)),
OPT_END(),
};
if (parse_options_concat(options, ARRAY_SIZE(options),
cp_extra))
@@ -144,6 +146,12 @@ static void parse_args(int argc, const char **argv,
struct replay_opts *opts)
--abort, rollback,
NULL);
+ verify_opt_mutually_compatible(me,
+ --allow-empty, opts-allow_empty,
+ --skip-empty, opts-skip_empty,
+ --keep-redundant-commits,
opts-keep_redundant_commits,
+ NULL);
+
/* implies allow_empty */
if (opts-keep_redundant_commits)
opts-allow_empty = 1;
diff --git a/sequencer.c b/sequencer.c
index f7be7d8..d3c7d72 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -627,6 +627,12 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
goto leave;
}
+ if (opts-skip_empty is_index_unchanged() == 1) {
+ warning(_(skipping %s... %s),
+ find_unique_abbrev(commit-object.sha1, DEFAULT_ABBREV),
+ msg.subject);
+ goto leave;
+ }
allow = allow_empty(opts, commit);
if (allow 0) {
res = allow;
diff --git a/sequencer.h b/sequencer.h
index 1fc22dc..3b04844 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -34,6 +34,7 @@ struct replay_opts {
int allow_empty;
int allow_empty_message;
int keep_redundant_commits;
+ int skip_empty;
int mainline;
diff --git a/t/t3508-cherry-pick-many-commits.sh
b/t/t3508-cherry-pick-many-commits.sh
index 19c99d7..3dc19c6 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -187,4 +187,17 @@ test_expect_success 'cherry-pick --stdin works' '
check_head_differs_from fourth
'
+test_expect_success 'cherry-pick skip empty' '
+ git clean -fxd
+ git checkout -b empty fourth
+ git commit --allow-empty -m empty
+ test_commit ontop
+ git checkout -f master
+ git reset --hard fourth
+ git cherry-pick --skip-empty fourth..empty
+ echo ontop expected
+ git log --format=%s fourth..HEAD actual
+ test_cmp expected actual
+'
+
test_done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH] t0005: skip signal death exit code test on Windows
On Thu, Jun 6, 2013 at 12:21 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: If somebody wants to write a note somewhere in the git documentation, that's fine with me, but I'm not clear on exactly what it would even say. I agree with both points. I can suggest to clarify the log message a bit with the implementation of raise() in msvcrt (Microsoft C Runtime library) just calls exit(3), but that does not address the end-user documentation issue. I tried to summarize the issue for end-user documentation and came up with this: The Git implementation on MinGW That's not accurate at all. MinGW is essentially a compiler for Windows. It doesn't matter if you use MinGW, Visual C++, or any other compiler for Windows, the result would be the same. But when stated this way, it feels that it belongs to Msysgit documentation, not ours, at least to me. Are we saying then that Git doesn't support Windows? That wouldn't be wise considering it's one of the most widely used reasons to argue that Git is not a good choice of a SCM; lack of Windows support. The truth of the matter is that exit codes are platform-dependent. Period. -- 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 v3 3/9] cherry-pick: add --skip-empty option
On Thu, Jun 6, 2013 at 1:30 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Pretty much what it says on the tin. And a bit more, isn't it? The --keep-redundant-commits option implies the --allow-empty option and it was perfectly acceptable to give both. By making sure that only at most one of -k-r-d, -a-e or -s-e is given, this forbids that usage. It is implied so there is no *need* to give it redundantly is different from It is implied so you shouldn't give it redundantly. Remove that line then. Like 7 and 8 that adds --quiet/--skip, don't we want this also for revert? If we don't want --allow-empty in revert, we don't want --skip-empty either. That is a separate patch. -- 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 v3 5/9] sequencer: run post-rewrite hook
Felipe Contreras felipe.contre...@gmail.com writes:
As we should.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index 76ff2ff..74480d7 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -127,6 +127,37 @@ static void add_rewritten(unsigned char *from, unsigned
char *to)
rewritten.nr++;
}
+static void run_rewrite_hook(const char *name)
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct child_process proc;
+ const char *argv[3];
+ int code, i;
+
+ argv[0] = find_hook(post-rewrite);
+ if (!argv[0])
+ return;
+
+ argv[1] = name;
+ argv[2] = NULL;
+
+ memset(proc, 0, sizeof(proc));
+ proc.argv = argv;
+ proc.in = -1;
+ proc.stdout_to_stderr = 1;
+
+ code = start_command(proc);
+ if (code)
+ return;
+ for (i = 0; i rewritten.nr; i++) {
+ struct rewritten_list_item *item = rewritten.items[i];
+ strbuf_addf(buf, %s %s\n, sha1_to_hex(item-from),
sha1_to_hex(item-to));
+ }
+ write_in_full(proc.in, buf.buf, buf.len);
+ close(proc.in);
+ finish_command(proc);
+}
It probably is worth inserting a commit before 4/9 that adds
rewrite.[ch], and
- introduces struct rewritten_list[_item];
- moves run_rewrite_hook() in builtin/commit.c to rewrite.c;
- changes its function signature so that it takes char
*action_name and struct rewritten * as parameters; and
- adjust its sole call site in cmd_commit() to feed a single-item
rewritten_list to it.
Then 4/9 can teach cherry-pick to prepare the rewritten-list and
probably this commit can be part of that to call run_rewrite_hook().
--
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] rev-list: add --authorship-order alternative ordering
On Tue, Jun 4, 2013 at 3:14 PM, Junio C Hamano gits...@pobox.com wrote:
elliottcable m...@ell.io writes:
Thus, I've added an --authorship-order version of --date-order, which relies
upon the AUTHOR_DATE instead of the COMMITTER_DATE; this means that old
commits
will continue to show up chronologically in-order despite rebasing.
---
Missing sign-off. Please see Documentation/SubmittingPatches.
Will-do.
I read that part, and was rather confused. At no point did I get the
idea that I should sign-off *my own initial commit*. Perhaps that part
of the documentation needs to be slightly re-written? Would that be a
welcome change?
On Tue, Jun 4, 2013 at 3:14 PM, Junio C Hamano gits...@pobox.com wrote:
elliottcable m...@ell.io writes:
diff --git a/builtin/log.c b/builtin/log.c
index 9e21232..54d4d7f 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -237,7 +237,7 @@ static void log_show_early(struct rev_info *revs, struct
commit_list *list)
int i = revs-early_output;
int show_header = 1;
- sort_in_topological_order(list, revs-lifo);
+ sort_in_topological_order(list, revs-lifo, revs-use_author);
The name use-author is a clear sign that the person who added this
code were too narrowly focused to think author automatically would
mean author date ;-).
It probably makes sense to revamp sort_in_topological_order(), so
that its second parameter is not a boolean 'lifo' that tells too
much about its implementation without telling what it actually
means. Instead, we can make it an enum sort_order, that tells it to
emit the commits in committer-date order, author-date order, or
graph-traversal order.
And update revs-lifo to use that same enum, without adding
use_author_date bit to rev_info.
I'll look into replacing lifo with an enum as soon as I can sit back
down to update this patch. For the moment, nothing more than
committer_date_sort and author_date_sort, I suppose?
Overview being, I suppose, that `lifo` will no longer exist (since it
effectively determines, when truthy, that we operate in a
*non*-date-ordered topological method); then have commiter_date_order
and author_date_order bits in an enum, with zero being
lifo/straightforward-topological-order. Sound about right?
I'll try and make this a separate patch. First commit, to replace lifo
with an enum; second commit, to *actually implement* the code obeying
that enum when it is set to author_date_order.
On Tue, Jun 4, 2013 at 5:22 PM, Jeff King p...@peff.net wrote:
On Tue, Jun 04, 2013 at 12:14:21PM -0700, Junio C Hamano wrote:
diff --git a/commit.h b/commit.h
index 67bd509..de07525 100644
--- a/commit.h
+++ b/commit.h
@@ -17,6 +17,7 @@ struct commit {
void *util;
unsigned int indegree;
unsigned long date;
+ unsigned long author_date;
While walking we keep many of them in-core, and 8-byte each for each
commit objects add up. We do not want to make struct commit any
larger than it already is.
Having said that, I do not see a reasonable alternative
implementation than adding an author-date field to struct commit
without major restructuring if we were to add this feature.
So please do not take this part of the response as a patch rejected
because we do not want to add anything to this structure. We'll
think of something down the road, but as an independent topic after
this gets in (or doesn't).
Yeah, I had the same thought. Maybe this is a good candidate to build on
top of the jk/commit-info slab experiment. The topo-sort could allocate
an extra slab for author-date (or even expand the indegree slab to hold
both indegree and author date), use it during the sort, and then free it
afterwards.
Elliott: you can see the relevant changes to the topo-sort in commit
96c4f4a (commit: allow associating auxiliary info on-demand,
2013-04-09).
-Peff
Again, might be a little over my head. If you really think it's best
that I look into that branch, I will try. :)
Meantime, is there any other, more-immediate approach you can think
of? I thought, for a moment, of only storing *either* the committer
*or* the author date in the commit-struct at a given time, and
flagging with a single bit ... but I'm not sure how widely-spread the
nead for committer-date currently is. Maybe I can go back and
parse-out the author date *when I need it*, instead, though that
sounds slow …
Epilogue: I'll make the *obvious* changes mentioned above sometime
within the next week (I'm more than a little swamped; in the middle of
a big breakup, and a big move, simultaneously! :( ), especially the
enum instead of the use_author bit … and submit another patch RFC. It
won't be finalized until we can decide what to do about the extra
8bytes in the commit struct, though. More input welcome.
--
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 v3 3/9] cherry-pick: add --skip-empty option
Felipe Contreras felipe.contre...@gmail.com writes: On Thu, Jun 6, 2013 at 1:30 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Pretty much what it says on the tin. And a bit more, isn't it? The --keep-redundant-commits option implies the --allow-empty option and it was perfectly acceptable to give both. By making sure that only at most one of -k-r-d, -a-e or -s-e is given, this forbids that usage. It is implied so there is no *need* to give it redundantly is different from It is implied so you shouldn't give it redundantly. Remove that line then. That's what the submitter does. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/9] cherry-pick: add --skip-empty option
Felipe Contreras felipe.contre...@gmail.com writes: On Thu, Jun 6, 2013 at 1:30 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Pretty much what it says on the tin. And a bit more, isn't it? The --keep-redundant-commits option implies the --allow-empty option and it was perfectly acceptable to give both. By making sure that only at most one of -k-r-d, -a-e or -s-e is given, this forbids that usage. It is implied so there is no *need* to give it redundantly is different from It is implied so you shouldn't give it redundantly. Remove that line then. Like 7 and 8 that adds --quiet/--skip, don't we want this also for revert? If we don't want --allow-empty in revert, we don't want --skip-empty either. That is a separate patch. OK. -- 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] rev-list: add --authorship-order alternative ordering
Elliott Cable m...@ell.io writes: On Tue, Jun 4, 2013 at 3:14 PM, Junio C Hamano gits...@pobox.com wrote: elliottcable m...@ell.io writes: Thus, I've added an --authorship-order version of --date-order, which relies upon the AUTHOR_DATE instead of the COMMITTER_DATE; this means that old commits will continue to show up chronologically in-order despite rebasing. --- Missing sign-off. Please see Documentation/SubmittingPatches. Will-do. I read that part, and was rather confused. At no point did I get the idea that I should sign-off *my own initial commit*. Perhaps that part of the documentation needs to be slightly re-written? Would that be a welcome change? I fail to see what more needs to be clarified on top of what we already have; please re-read (5) Sign your work section, paying with special attention to: - YOU WROTE IT or otherwise have the right to pass it on. - the contribution was created in whole or in part BY ME and I HAVE THE RIGHT TO SUBMIT. But perhaps you meant something else by *my own initial commit*??? -- 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] rev-list: add --authorship-order alternative ordering
Wow. That's my bad entirely. I apparently hallucinated a section suggesting that you “sign-off” commits that you'd reviewed, or something; and I'd completely skipped the section on certifying that you have legal rights to the work, because I'd *written* it, and didn't think it'd be relevant. I feel like an idiot. Forgive me. I'll --signoff my next version of the patch. o7 On Thu, Jun 6, 2013 at 3:29 PM, Junio C Hamano gits...@pobox.com wrote: Elliott Cable m...@ell.io writes: On Tue, Jun 4, 2013 at 3:14 PM, Junio C Hamano gits...@pobox.com wrote: elliottcable m...@ell.io writes: Thus, I've added an --authorship-order version of --date-order, which relies upon the AUTHOR_DATE instead of the COMMITTER_DATE; this means that old commits will continue to show up chronologically in-order despite rebasing. --- Missing sign-off. Please see Documentation/SubmittingPatches. Will-do. I read that part, and was rather confused. At no point did I get the idea that I should sign-off *my own initial commit*. Perhaps that part of the documentation needs to be slightly re-written? Would that be a welcome change? I fail to see what more needs to be clarified on top of what we already have; please re-read (5) Sign your work section, paying with special attention to: - YOU WROTE IT or otherwise have the right to pass it on. - the contribution was created in whole or in part BY ME and I HAVE THE RIGHT TO SUBMIT. But perhaps you meant something else by *my own initial commit*??? -- 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/18] Follow perlcritic's recommendations - level 5 and 4
Fix warnings from perlcritic's level 5 and 4. They correspond to the following
cases:
- always end a submodule with a return
- don't use the constant pragma, use the Readonly module instead
- some syntax details for maps, and others.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 81 +--
1 file changed, 51 insertions(+), 30 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 410eae9..83cf292 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -15,32 +15,32 @@ use strict;
use MediaWiki::API;
use Git;
use DateTime::Format::ISO8601;
+use warnings;
# By default, use UTF-8 to communicate with Git and the user
-binmode STDERR, :utf8;
-binmode STDOUT, :utf8;
+binmode STDERR, :encoding(UTF-8);
+binmode STDOUT, :encoding(UTF-8);
use URI::Escape;
use IPC::Open2;
-
-use warnings;
+use Readonly;
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
-use constant SLASH_REPLACEMENT = %2F;
+Readonly my $SLASH_REPLACEMENT = %2F;
# It's not always possible to delete pages (may require some
# privileges). Deleted pages are replaced with this content.
-use constant DELETED_CONTENT = [[Category:Deleted]]\n;
+Readonly my $DELETED_CONTENT = [[Category:Deleted]]\n;
# It's not possible to create empty pages. New empty files in Git are
# sent with this content instead.
-use constant EMPTY_CONTENT = !-- empty page --\n;
+Readonly my $EMPTY_CONTENT = !-- empty page --\n;
# used to reflect file creation or deletion in diff.
-use constant NULL_SHA1 = ;
+Readonly my $NULL_SHA1 = ;
# Used on Git's side to reflect empty edit messages on the wiki
-use constant EMPTY_MESSAGE = '*Empty MediaWiki Message*';
+Readonly my $EMPTY_MESSAGE = '*Empty MediaWiki Message*';
if (@ARGV != 2) {
exit_error_usage();
@@ -96,6 +96,9 @@ unless ($fetch_strategy) {
$fetch_strategy = by_page;
}
+# Remember the timestamp corresponding to a revision id.
+my %basetimestamps;
+
# Dumb push: don't update notes and mediawiki ref to reflect the last push.
#
# Configurable with mediawiki.dumbPush, or per-remote with
@@ -198,12 +201,14 @@ sub mw_connect_maybe {
exit 1;
}
}
+ return;
}
## Functions for listing pages on the remote wiki
sub get_mw_tracked_pages {
my $pages = shift;
get_mw_page_list(\@tracked_pages, $pages);
+ return;
}
sub get_mw_page_list {
@@ -219,6 +224,7 @@ sub get_mw_page_list {
get_mw_first_pages(\@slice, $pages);
@some_pages = @some_pages[51..$#some_pages];
}
+ return;
}
sub get_mw_tracked_categories {
@@ -241,6 +247,7 @@ sub get_mw_tracked_categories {
$pages-{$page-{title}} = $page;
}
}
+ return;
}
sub get_mw_all_pages {
@@ -260,6 +267,7 @@ sub get_mw_all_pages {
foreach my $page (@{$mw_pages}) {
$pages-{$page-{title}} = $page;
}
+ return;
}
# queries the wiki for a set of pages. Meant to be used within a loop
@@ -290,6 +298,7 @@ sub get_mw_first_pages {
$pages-{$page-{title}} = $page;
}
}
+ return;
}
# Get the list of pages to be fetched according to configuration.
@@ -358,11 +367,12 @@ sub get_all_mediafiles {
foreach my $page (@{$mw_pages}) {
$pages-{$page-{title}} = $page;
}
+ return;
}
sub get_linked_mediafiles {
my $pages = shift;
- my @titles = map $_-{title}, values(%{$pages});
+ my @titles = map { $_-{title} } values(%{$pages});
# The query is split in small batches because of the MW API limit of
# the number of links to be returned (500 links max).
@@ -390,11 +400,13 @@ sub get_linked_mediafiles {
while (my ($id, $page) = each(%{$result-{query}-{pages}})) {
my @media_titles;
if (defined($page-{links})) {
- my @link_titles = map $_-{title},
@{$page-{links}};
+ my @link_titles
+ = map { $_-{title} } @{$page-{links}};
push(@media_titles, @link_titles);
}
if (defined($page-{images})) {
- my @image_titles = map $_-{title},
@{$page-{images}};
+ my @image_titles
+ = map { $_-{title} } @{$page-{images}};
push(@media_titles, @image_titles);
[PATCH 00/18] git-remote-mediawiki: Follow perlcritic's recommandations
Hi,
This series of commits intends to follow most of perlcritic's recommandations
in order to make the code more maintainable and readable.
I followed most recommandations from level 5 (most critical ones )to 2, but
left a great part of the level 1 ones, as they were more about personal choices
of coding style and less about actually improving maintainability and preventing
bugs. Among those I did *not* take into account were:
- ValuesAndExpressions::ProhibitNoisyQuotes: use q(*) instead of '*' for quoting
some characters
- RegularExpressions::ProhibitEnumeratedClasses: e.g., use [0-9] instead of \d
- CodeLayout::ProhibitParensWithBuiltins: don't use parentheses with builtin
functions
- RegularExpressions::RequireExtendedFormatting,
RegularExpressions::RequireDotMatchAnything and
RegularExpressions::RequireLineBoundaryMatching: use s, m and x flags for
*every* regexp
- and some others. Run perlcritic -1 on patched file to so what is left.
Please tell me if you think some of them should be applied anyway.
On the other hand, if quite not sure of the relevance of some commits:
- Add newline in the end of die() error messages [3/18]: are die() messages
correctly handled already?
- Place the open() call inside the do{} struct and prevent failing close
[17/18]: current code fails to close the filehandle (try adding a
or warn(..) after the close() to check this). However, perlcritic complains
as well if you don't put an explicit close(), which fails when you put it.
I'm not sure of what's happening and what's the best solution for this.
I checked Documentation/CodingGuidelines and none of these modifications should
contradict it.
This is my first patch, so don't hesitate to point to me anything wrong with it.
Célestin Matte (18):
Follow perlcritic's recommendations - level 5 and 4
Change style of some regular expressions to make them clearer
Add newline in the end of die() error messages
Prevent local variable $url to have the same name as a global
variable
Turn double-negated expressions into simple expressions
Remove unused variable
Rename a variable ($last) so that it does not have the name of a
keyword
Explicitely assign local variable as undef and make a proper
one-instruction-by-line indentation
Check return value of open and remove import of unused open2
Put long code into a submodule
Modify strings for a better coding-style
Brace file handles for print for more clarity
Remove unless statements and replace them by negated if
statements
Don't use quotes for empty strings
Put non-trivial numeric values (e.g., different from 0, 1 and 2) in
constants.
Fix a typo (mediwiki instead of mediawiki)
Place the open() call inside the do{} struct and prevent failing
close
Clearly rewrite double dereference
contrib/mw-to-git/git-remote-mediawiki.perl | 558 ++-
1 file changed, 298 insertions(+), 260 deletions(-)
--
1.7.9.5
--
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 02/18] Change style of some regular expressions to make them clearer
- Remove m modifier when useless (m// and // was used randomly; this makes the
code more coherent)
- Remove stringy split (split('c', ...) instead of split(/c/, ...))
- Use {}{} instead of /// when slashes or used inside the regexp so as not to
escape it.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 83cf292..482cd95 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -121,7 +121,7 @@ chomp($dumb_push);
$dumb_push = ($dumb_push eq true);
my $wiki_name = $url;
-$wiki_name =~ s/[^\/]*:\/\///;
+$wiki_name =~ s{[^/]*://}{};
# If URL is like http://user:passw...@example.com/, we clearly don't
# want the password in $wiki_name. While we're there, also remove user
# and '@' sign, to avoid author like MWUser@httpu...@host.com
@@ -762,7 +762,7 @@ sub get_more_refs {
my @refs;
while (1) {
my $line = STDIN;
- if ($line =~ m/^$cmd (.*)$/) {
+ if ($line =~ /^$cmd (.*)$/) {
push(@refs, $1);
} elsif ($line eq \n) {
return @refs;
@@ -1168,11 +1168,11 @@ sub mw_push_revision {
my @local_ancestry = split(/\n/, run_git(rev-list --boundary
--parents $local ^$parsed_sha1));
my %local_ancestry;
foreach my $line (@local_ancestry) {
- if (my ($child, $parents) = $line =~ m/^-?([a-f0-9]+)
([a-f0-9 ]+)/) {
- foreach my $parent (split(' ', $parents)) {
+ if (my ($child, $parents) = $line =~ /^-?([a-f0-9]+)
([a-f0-9 ]+)/) {
+ foreach my $parent (split(/ /, $parents)) {
$local_ancestry{$parent} = $child;
}
- } elsif (!$line =~ m/^([a-f0-9]+)/) {
+ } elsif (!$line =~ /^([a-f0-9]+)/) {
die Unexpected output from git rev-list:
$line;
}
}
@@ -1190,10 +1190,10 @@ sub mw_push_revision {
# history (linearized with --first-parent)
print STDERR Warning: no common ancestor, pushing complete
history\n;
my $history = run_git(rev-list --first-parent --children
$local);
- my @history = split('\n', $history);
+ my @history = split(/\n/, $history);
@history = @history[1..$#history];
foreach my $line (reverse @history) {
- my @commit_info_split = split(/ |\n/, $line);
+ my @commit_info_split = split(/[ \n]/, $line);
push(@commit_pairs, \@commit_info_split);
}
}
@@ -1272,7 +1272,7 @@ sub get_mw_namespace_id {
# Look at configuration file, if the record for that namespace
is
# already cached. Namespaces are stored in form:
# Name_of_namespace:Id_namespace, ex.: File:6.
- my @temp = split(/[\n]/, run_git(config --get-all remote.
+ my @temp = split(/\n/, run_git(config --get-all remote.
. $remotename
..namespaceCache));
chomp(@temp);
foreach my $ns (@temp) {
--
1.7.9.5
--
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/18] Put long code into a submodule
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 44 ---
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 1c34ada..1271527 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -133,24 +133,7 @@ while (STDIN) {
@cmd = split(/ /);
if (defined($cmd[0])) {
# Line not blank
- if ($cmd[0] eq capabilities) {
- die(Too many arguments for capabilities\n) if
(defined($cmd[1]));
- mw_capabilities();
- } elsif ($cmd[0] eq list) {
- die(Too many arguments for list\n) if
(defined($cmd[2]));
- mw_list($cmd[1]);
- } elsif ($cmd[0] eq import) {
- die(Invalid arguments for import\n) if ($cmd[1] eq
|| defined($cmd[2]));
- mw_import($cmd[1]);
- } elsif ($cmd[0] eq option) {
- die(Too many arguments for option\n) if ($cmd[1] eq
|| $cmd[2] eq || defined($cmd[3]));
- mw_option($cmd[1],$cmd[2]);
- } elsif ($cmd[0] eq push) {
- mw_push($cmd[1]);
- } else {
- print STDERR Unknown command. Aborting...\n;
- last;
- }
+ parse_commands();
} else {
# blank line: we should terminate
last;
@@ -168,6 +151,31 @@ sub exit_error_usage {
die ERROR: git-remote-mediawiki module was not called with a correct
number of parameters\n;
}
+sub parse_commands {
+ if ($cmd[0] eq capabilities) {
+ die(Too many arguments for capabilities\n)
+ if (defined($cmd[1]));
+ mw_capabilities();
+ } elsif ($cmd[0] eq list) {
+ die(Too many arguments for list\n) if (defined($cmd[2]));
+ mw_list($cmd[1]);
+ } elsif ($cmd[0] eq import) {
+ die(Invalid arguments for import\n)
+ if ($cmd[1] eq || defined($cmd[2]));
+ mw_import($cmd[1]);
+ } elsif ($cmd[0] eq option) {
+ die(Too many arguments for option\n)
+ if ($cmd[1] eq || $cmd[2] eq || defined($cmd[3]));
+ mw_option($cmd[1],$cmd[2]);
+ } elsif ($cmd[0] eq push) {
+ mw_push($cmd[1]);
+ } else {
+ print STDERR Unknown command. Aborting...\n;
+ last;
+ }
+ return;
+}
+
# MediaWiki API instance, created lazily.
my $mediawiki;
--
1.7.9.5
--
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/18] Prevent local variable $url to have the same name as a global variable
There is already a global variable called $url. Changing the name of the local
variable prevents future possible misunderstanding.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 4baad95..68fd129 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -455,14 +455,14 @@ sub get_mw_mediafile_for_page_revision {
}
sub download_mw_mediafile {
- my $url = shift;
+ my $download_url = shift;
- my $response = $mediawiki-{ua}-get($url);
+ my $response = $mediawiki-{ua}-get($download_url);
if ($response-code == 200) {
return $response-decoded_content;
} else {
print STDERR Error downloading mediafile from :\n;
- print STDERR URL: $url\n;
+ print STDERR URL: $download_url\n;
print STDERR Server response: . $response-code . .
$response-message . \n;
exit 1;
}
--
1.7.9.5
--
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/18] Add newline in the end of die() error messages
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 482cd95..4baad95 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -136,16 +136,16 @@ while (STDIN) {
if (defined($cmd[0])) {
# Line not blank
if ($cmd[0] eq capabilities) {
- die(Too many arguments for capabilities) unless
(!defined($cmd[1]));
+ die(Too many arguments for capabilities\n) unless
(!defined($cmd[1]));
mw_capabilities();
} elsif ($cmd[0] eq list) {
- die(Too many arguments for list) unless
(!defined($cmd[2]));
+ die(Too many arguments for list\n) unless
(!defined($cmd[2]));
mw_list($cmd[1]);
} elsif ($cmd[0] eq import) {
- die(Invalid arguments for import) unless ($cmd[1] ne
!defined($cmd[2]));
+ die(Invalid arguments for import\n) unless ($cmd[1]
ne !defined($cmd[2]));
mw_import($cmd[1]);
} elsif ($cmd[0] eq option) {
- die(Too many arguments for option) unless ($cmd[1] ne
$cmd[2] ne !defined($cmd[3]));
+ die(Too many arguments for option\n) unless ($cmd[1]
ne $cmd[2] ne !defined($cmd[3]));
mw_option($cmd[1],$cmd[2]);
} elsif ($cmd[0] eq push) {
mw_push($cmd[1]);
@@ -242,7 +242,7 @@ sub get_mw_tracked_categories {
cmtitle = $category,
cmlimit = 'max' } )
|| die $mediawiki-{error}-{code} . ': '
- . $mediawiki-{error}-{details};
+ . $mediawiki-{error}-{details} . \n;
foreach my $page (@{$mw_pages}) {
$pages-{$page-{title}} = $page;
}
@@ -767,7 +767,7 @@ sub get_more_refs {
} elsif ($line eq \n) {
return @refs;
} else {
- die(Invalid command in a '$cmd' batch: . $_);
+ die(Invalid command in a '$cmd' batch: $_\n);
}
}
return;
@@ -879,7 +879,7 @@ sub mw_import_revids {
my $result = $mediawiki-api($query);
if (!$result) {
- die Failed to retrieve modified page for revision
$pagerevid;
+ die Failed to retrieve modified page for revision
$pagerevid\n;
}
if (defined($result-{query}-{badrevids}-{$pagerevid})) {
@@ -888,7 +888,7 @@ sub mw_import_revids {
}
if (!defined($result-{query}-{pages})) {
- die Invalid revision $pagerevid.;
+ die Invalid revision $pagerevid.\n;
}
my @result_pages = values(%{$result-{query}-{pages}});
@@ -999,7 +999,7 @@ sub mw_upload_file {
}, {
skip_encoding = 1
} ) || die $mediawiki-{error}-{code} . ':'
-. $mediawiki-{error}-{details};
+. $mediawiki-{error}-{details} . \n;
my $last_file_page = $mediawiki-get_page({title =
$path});
$newrevid = $last_file_page-{revid};
print STDERR Pushed file: $new_sha1 -
$complete_file_name.\n;
@@ -1079,7 +1079,7 @@ sub mw_push_file {
# Other errors. Shouldn't happen = just die()
die 'Fatal: Error ' .
$mediawiki-{error}-{code} .
- ' from mediwiki: ' .
$mediawiki-{error}-{details};
+ ' from mediwiki: ' .
$mediawiki-{error}-{details} . \n;
}
}
$newrevid = $result-{edit}-{newrevid};
@@ -1101,7 +1101,7 @@ sub mw_push {
my $pushed;
for my $refspec (@refsspecs) {
my ($force, $local, $remote) = $refspec =~
/^(\+)?([^:]*):([^:]*)$/
- or die(Invalid refspec for push. Expected src:dst or
+src:dst);
+ or die(Invalid refspec for push. Expected src:dst or
+src:dst\n);
if ($force) {
print STDERR Warning: forced push not allowed on a
MediaWiki.\n;
}
@@ -1173,7 +1173,7 @@ sub mw_push_revision {
[PATCH 13/18] Remove unless statements and replace them by negated if statements
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 757a7a3..b7a7012 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -87,11 +87,11 @@ $shallow_import = ($shallow_import eq 'true');
# - by_rev: perform one query per new revision on the remote wiki
# - by_page: query each tracked page for new revision
my $fetch_strategy = run_git(config --get
remote.${remotename}.fetchStrategy);
-unless ($fetch_strategy) {
+if (! $fetch_strategy) {
$fetch_strategy = run_git('config --get mediawiki.fetchStrategy');
}
chomp($fetch_strategy);
-unless ($fetch_strategy) {
+if (! $fetch_strategy) {
$fetch_strategy = 'by_page';
}
@@ -113,7 +113,7 @@ my %basetimestamps;
# deterministic, this means everybody gets the same sha1 for each
# MediaWiki revision.
my $dumb_push = run_git(config --get --bool remote.${remotename}.dumbPush);
-unless ($dumb_push) {
+if (! $dumb_push) {
$dumb_push = run_git('config --get --bool mediawiki.dumbPush');
}
chomp($dumb_push);
@@ -668,7 +668,7 @@ sub fetch_mw_revisions_for_page {
push(@page_revs, $page_rev_ids);
$revnum++;
}
- last unless $result-{'query-continue'};
+ last if (! $result-{'query-continue'});
$query-{rvstartid} =
$result-{'query-continue'}-{revisions}-{rvstartid};
}
if ($shallow_import @page_revs) {
@@ -1240,7 +1240,7 @@ sub mw_push_revision {
die(Unknown error from mw_push_file()\n);
}
}
- unless ($dumb_push) {
+ if (! $dumb_push) {
run_git(qq(notes --ref=${remotename}/mediawiki add -f
-m mediawiki_revision: ${mw_revision} ${sha1_commit}));
run_git(qq(update-ref -m Git-MediaWiki push
refs/mediawiki/${remotename}/master ${sha1_commit} ${sha1_child}));
}
@@ -1320,7 +1320,7 @@ sub get_mw_namespace_id {
my $ns = $namespace_id{$name};
my $id;
- unless (defined $ns) {
+ if (! defined $ns) {
print {*STDERR} No such namespace ${name} on MediaWiki.\n;
$ns = {is_namespace = 0};
$namespace_id{$name} = $ns;
--
1.7.9.5
--
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 18/18] Clearly rewrite double dereference
@$var structures are re-written in the following way: @{ $var }
It makes them more readable.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 20ddccb..06e6f4d 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -233,7 +233,7 @@ sub get_mw_tracked_pages {
sub get_mw_page_list {
my $page_list = shift;
my $pages = shift;
- my @some_pages = @$page_list;
+ my @some_pages = @{ $page_list };
while (@some_pages) {
my $last_page = $SLICE_SIZE;
if ($#some_pages $last_page) {
@@ -733,7 +733,7 @@ sub import_file_revision {
print {*STDOUT} commit refs/mediawiki/${remotename}/master\n;
print {*STDOUT} mark :${n}\n;
- print {*STDOUT} committer ${author} ${author}\@${wiki_name} .
$date-epoch . +\n;
+ print {*STDOUT} committer ${author} ${author}\@{ ${wiki_name} } .
$date-epoch . +\n;
literal_data($comment);
# If it's not a clone, we need to know where to start from
@@ -759,7 +759,7 @@ sub import_file_revision {
print {*STDOUT} reset refs/notes/${remotename}/mediawiki\n;
}
print {*STDOUT} commit refs/notes/${remotename}/mediawiki\n;
- print {*STDOUT} committer ${author} ${author}\@${wiki_name} .
$date-epoch . +\n;
+ print {*STDOUT} committer ${author} ${author}\@{ ${wiki_name} } .
$date-epoch . +\n;
literal_data('Note added by git-mediawiki during import');
if (!$full_import $n == 1) {
print {*STDOUT} from refs/notes/${remotename}/mediawiki^0\n;
@@ -881,7 +881,7 @@ sub mw_import_revids {
my $n_actual = 0;
my $last_timestamp = 0; # Placeholer in case $rev-timestamp is
undefined
- foreach my $pagerevid (@$revision_ids) {
+ foreach my $pagerevid (@{ $revision_ids }) {
# Count page even if we skip it, since we display
# $n/$total and $total includes skipped pages.
$n++;
@@ -916,7 +916,7 @@ sub mw_import_revids {
my $page_title = $result_page-{title};
if (!exists($pages-{$page_title})) {
- print {*STDERR} ${n}/, scalar(@$revision_ids),
+ print {*STDERR} ${n}/, scalar(@ { $revision_ids }),
: Skipping revision #$rev-{revid} of
${page_title}\n;
next;
}
@@ -949,7 +949,7 @@ sub mw_import_revids {
# If this is a revision of the media page for new version
# of a file do one common commit for both file and media page.
# Else do commit only for that page.
- print {*STDERR} ${n}/, scalar(@$revision_ids), : Revision
#$rev-{revid} of $commit{title}\n;
+ print {*STDERR} ${n}/, scalar(@{ $revision_ids }), :
Revision #$rev-{revid} of $commit{title}\n;
import_file_revision(\%commit, ($fetch_from == 1), $n_actual,
\%mediafile);
}
--
1.7.9.5
--
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/18] Check return value of open and remove import of unused open2
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index ae6dd2e..1c34ada 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -22,7 +22,6 @@ binmode STDERR, :encoding(UTF-8);
binmode STDOUT, :encoding(UTF-8);
use URI::Escape;
-use IPC::Open2;
use Readonly;
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
@@ -338,7 +337,8 @@ sub get_mw_pages {
sub run_git {
my $args = shift;
my $encoding = (shift || encoding(UTF-8));
- open(my $git, -|:$encoding, git . $args);
+ open(my $git, -|:$encoding, git . $args)
+ or die Unable to open: $!\n;
my $res = do {
local $/ = undef;
$git
--
1.7.9.5
--
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 17/18] Place the open() call inside the do{} struct and prevent failing close
Placing the open() call inside the do{} struct will automatically close the
filehandle if possible.
Placing the close() call outside the do{} struct is useless and will make it
fail systematically
Change the error message to state that what fails is a fork(), not a file
opening.
Use autodie to properly exit when a print or open call fails.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 952ddcc..20ddccb 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -23,6 +23,7 @@ binmode STDOUT, ':encoding(UTF-8)';
use URI::Escape;
use Readonly;
+use autodie;
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
Readonly my $SLASH_REPLACEMENT = '%2F';
@@ -363,8 +364,6 @@ sub run_git {
local $/ = undef;
$git
};
- close($git);
-
return $res;
}
--
1.7.9.5
--
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/18] Turn double-negated expressions into simple expressions
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 68fd129..a6c7de2 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -136,16 +136,16 @@ while (STDIN) {
if (defined($cmd[0])) {
# Line not blank
if ($cmd[0] eq capabilities) {
- die(Too many arguments for capabilities\n) unless
(!defined($cmd[1]));
+ die(Too many arguments for capabilities\n) if
(defined($cmd[1]));
mw_capabilities();
} elsif ($cmd[0] eq list) {
- die(Too many arguments for list\n) unless
(!defined($cmd[2]));
+ die(Too many arguments for list\n) if
(defined($cmd[2]));
mw_list($cmd[1]);
} elsif ($cmd[0] eq import) {
- die(Invalid arguments for import\n) unless ($cmd[1]
ne !defined($cmd[2]));
+ die(Invalid arguments for import\n) if ($cmd[1] eq
|| defined($cmd[2]));
mw_import($cmd[1]);
} elsif ($cmd[0] eq option) {
- die(Too many arguments for option\n) unless ($cmd[1]
ne $cmd[2] ne !defined($cmd[3]));
+ die(Too many arguments for option\n) if ($cmd[1] eq
|| $cmd[2] eq || defined($cmd[3]));
mw_option($cmd[1],$cmd[2]);
} elsif ($cmd[0] eq push) {
mw_push($cmd[1]);
--
1.7.9.5
--
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 12/18] Brace file handles for print for more clarity
This follows the following rule:
InputOutput::RequireBracedFileHandleWithPrint (Severity: 1)
The `print' and `printf' functions have a unique syntax that supports an
optional file handle argument. Conway suggests wrapping this argument in
braces to make it visually stand out from the other arguments. When you
put braces around any of the special package-level file handles like
`STDOUT', `STDERR', and `DATA', you must the `'*'' sigil or else it
won't compile under `use strict 'subs''.
print $FH Mary had a little lamb\n; #not ok
print {$FH} Mary had a little lamb\n; #ok
print STDERR $foo, $bar, $baz; #not ok
print {STDERR} $foo, $bar, $baz; #won't compile under 'strict'
print {*STDERR} $foo, $bar, $baz; #perfect!
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 184 +--
1 file changed, 92 insertions(+), 92 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 0e2152d..757a7a3 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -170,7 +170,7 @@ sub parse_commands {
} elsif ($cmd[0] eq 'push') {
mw_push($cmd[1]);
} else {
- print STDERR Unknown command. Aborting...\n;
+ print {*STDERR} Unknown command. Aborting...\n;
last;
}
return;
@@ -197,7 +197,7 @@ sub mw_connect_maybe {
lgdomain = $wiki_domain};
if ($mediawiki-login($request)) {
Git::credential \%credential, 'approve';
- print STDERR qq(Logged in mediawiki user
$credential{username}.\n);
+ print {*STDERR} qq(Logged in mediawiki user
$credential{username}.\n);
} else {
print {*STDERR} qq(Failed to log in mediawiki user
$credential{username} on ${url}\n);
print {*STDERR} ' (error ' .
@@ -265,9 +265,9 @@ sub get_mw_all_pages {
aplimit = 'max'
});
if (!defined($mw_pages)) {
- print STDERR fatal: could not get the list of wiki pages.\n;
- print STDERR fatal: '${url}' does not appear to be a
mediawiki\n;
- print STDERR fatal: make sure '${url}/api.php' is a valid
page.\n;
+ print {*STDERR} fatal: could not get the list of wiki
pages.\n;
+ print {*STDERR} fatal: '${url}' does not appear to be a
mediawiki\n;
+ print {*STDERR} fatal: make sure '${url}/api.php' is a valid
page.\n;
exit 1;
}
foreach my $page (@{$mw_pages}) {
@@ -292,14 +292,14 @@ sub get_mw_first_pages {
titles = $titles,
});
if (!defined($mw_pages)) {
- print STDERR fatal: could not query the list of wiki pages.\n;
- print STDERR fatal: '${url}' does not appear to be a
mediawiki\n;
- print STDERR fatal: make sure '${url}/api.php' is a valid
page.\n;
+ print {*STDERR} fatal: could not query the list of wiki
pages.\n;
+ print {*STDERR} fatal: '${url}' does not appear to be a
mediawiki\n;
+ print {*STDERR} fatal: make sure '${url}/api.php' is a valid
page.\n;
exit 1;
}
while (my ($id, $page) = each(%{$mw_pages-{query}-{pages}})) {
if ($id 0) {
- print STDERR Warning: page $page-{title} not found on
wiki\n;
+ print {*STDERR} Warning: page $page-{title} not found
on wiki\n;
} else {
$pages-{$page-{title}} = $page;
}
@@ -311,7 +311,7 @@ sub get_mw_first_pages {
sub get_mw_pages {
mw_connect_maybe();
- print STDERR Listing pages on remote wiki...\n;
+ print {*STDERR} Listing pages on remote wiki...\n;
my %pages; # hash on page titles to avoid duplicates
my $user_defined;
@@ -329,14 +329,14 @@ sub get_mw_pages {
get_mw_all_pages(\%pages);
}
if ($import_media) {
- print STDERR Getting media files for selected pages...\n;
+ print {*STDERR} Getting media files for selected pages...\n;
if ($user_defined) {
get_linked_mediafiles(\%pages);
} else {
get_all_mediafiles(\%pages);
}
}
- print STDERR (scalar keys %pages) . pages found.\n;
+ print {*STDERR} (scalar keys %pages) . pages found.\n;
return %pages;
}
@@ -369,9 +369,9 @@ sub get_all_mediafiles {
aplimit = 'max'
});
if (!defined($mw_pages)) {
- print STDERR fatal:
[PATCH 15/18] Put non-trivial numeric values (e.g., different from 0, 1 and 2) in constants.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 059bd1a..ff9fd8f 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -43,6 +43,16 @@ Readonly my $EMPTY_MESSAGE = '*Empty MediaWiki Message*';
Readonly my $EMPTY = q{};
+# Number of pages taken into account at once in submodule get_mw_page_list
+Readonly my $SLICE_SIZE = 50;
+
+# Number of linked mediafile to get at once in get_linked_mediafiles
+# The query is split in small batches because of the MW API limit of
+# the number of links to be returned (500 links max).
+Readonly my $BATCH_SIZE = 10;
+
+Readonly my $HTTP_CODE_OK = 200;
+
if (@ARGV != 2) {
exit_error_usage();
}
@@ -224,13 +234,13 @@ sub get_mw_page_list {
my $pages = shift;
my @some_pages = @$page_list;
while (@some_pages) {
- my $last_page = 50;
+ my $last_page = $SLICE_SIZE;
if ($#some_pages $last_page) {
$last_page = $#some_pages;
}
my @slice = @some_pages[0..$last_page];
get_mw_first_pages(\@slice, $pages);
- @some_pages = @some_pages[51..$#some_pages];
+ @some_pages = @some_pages[($SLICE_SIZE + 1)..$#some_pages];
}
return;
}
@@ -386,9 +396,7 @@ sub get_linked_mediafiles {
my $pages = shift;
my @titles = map { $_-{title} } values(%{$pages});
- # The query is split in small batches because of the MW API limit of
- # the number of links to be returned (500 links max).
- my $batch = 10;
+ my $batch = $BATCH_SIZE;
while (@titles) {
if ($#titles $batch) {
$batch = $#titles;
@@ -470,7 +478,7 @@ sub download_mw_mediafile {
my $download_url = shift;
my $response = $mediawiki-{ua}-get($download_url);
- if ($response-code == 200) {
+ if ($response-code == $HTTP_CODE_OK) {
return $response-decoded_content;
} else {
print {*STDERR} Error downloading mediafile from :\n;
--
1.7.9.5
--
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/18] Explicitely assign local variable as undef and make a proper one-instruction-by- line indentation
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 7fbc998..ae6dd2e 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -339,7 +339,10 @@ sub run_git {
my $args = shift;
my $encoding = (shift || encoding(UTF-8));
open(my $git, -|:$encoding, git . $args);
- my $res = do { local $/; $git };
+ my $res = do {
+ local $/ = undef;
+ $git
+ };
close($git);
return $res;
--
1.7.9.5
--
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/18] Modify strings for a better coding-style
- strings which don't need interpolation are single-quoted for more clarity and
slight gain of performance
- interpolation is preferred over concatenation in many cases, for more clarity
- variables are always used with the ${} operator inside strings
- strings including double-quotes are written with qq() so that the quotes do
not have to be escaped
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 250 +--
1 file changed, 124 insertions(+), 126 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 1271527..0e2152d 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -18,14 +18,14 @@ use DateTime::Format::ISO8601;
use warnings;
# By default, use UTF-8 to communicate with Git and the user
-binmode STDERR, :encoding(UTF-8);
-binmode STDOUT, :encoding(UTF-8);
+binmode STDERR, ':encoding(UTF-8)';
+binmode STDOUT, ':encoding(UTF-8)';
use URI::Escape;
use Readonly;
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
-Readonly my $SLASH_REPLACEMENT = %2F;
+Readonly my $SLASH_REPLACEMENT = '%2F';
# It's not always possible to delete pages (may require some
# privileges). Deleted pages are replaced with this content.
@@ -36,7 +36,7 @@ Readonly my $DELETED_CONTENT = [[Category:Deleted]]\n;
Readonly my $EMPTY_CONTENT = !-- empty page --\n;
# used to reflect file creation or deletion in diff.
-Readonly my $NULL_SHA1 = ;
+Readonly my $NULL_SHA1 = '';
# Used on Git's side to reflect empty edit messages on the wiki
Readonly my $EMPTY_MESSAGE = '*Empty MediaWiki Message*';
@@ -50,35 +50,35 @@ my $url = $ARGV[1];
# Accept both space-separated and multiple keys in config file.
# Spaces should be written as _ anyway because we'll use chomp.
-my @tracked_pages = split(/[ \n]/, run_git(config --get-all remote..
$remotename ..pages));
+my @tracked_pages = split(/[ \n]/, run_git(config --get-all
remote.${remotename}.pages));
chomp(@tracked_pages);
# Just like @tracked_pages, but for MediaWiki categories.
-my @tracked_categories = split(/[ \n]/, run_git(config --get-all remote..
$remotename ..categories));
+my @tracked_categories = split(/[ \n]/, run_git(config --get-all
remote.${remotename}.categories));
chomp(@tracked_categories);
# Import media files on pull
-my $import_media = run_git(config --get --bool remote.. $remotename
..mediaimport);
+my $import_media = run_git(config --get --bool
remote.${remotename}.mediaimport);
chomp($import_media);
-$import_media = ($import_media eq true);
+$import_media = ($import_media eq 'true');
# Export media files on push
-my $export_media = run_git(config --get --bool remote.. $remotename
..mediaexport);
+my $export_media = run_git(config --get --bool
remote.${remotename}.mediaexport);
chomp($export_media);
-$export_media = !($export_media eq false);
+$export_media = !($export_media eq 'false');
-my $wiki_login = run_git(config --get remote.. $remotename ..mwLogin);
+my $wiki_login = run_git(config --get remote.${remotename}.mwLogin);
# Note: mwPassword is discourraged. Use the credential system instead.
-my $wiki_passwd = run_git(config --get remote.. $remotename ..mwPassword);
-my $wiki_domain = run_git(config --get remote.. $remotename ..mwDomain);
+my $wiki_passwd = run_git(config --get remote.${remotename}.mwPassword);
+my $wiki_domain = run_git(config --get remote.${remotename}.mwDomain);
chomp($wiki_login);
chomp($wiki_passwd);
chomp($wiki_domain);
# Import only last revisions (both for clone and fetch)
-my $shallow_import = run_git(config --get --bool remote.. $remotename
..shallow);
+my $shallow_import = run_git(config --get --bool
remote.${remotename}.shallow);
chomp($shallow_import);
-$shallow_import = ($shallow_import eq true);
+$shallow_import = ($shallow_import eq 'true');
# Fetch (clone and pull) by revisions instead of by pages. This behavior
# is more efficient when we have a wiki with lots of pages and we fetch
@@ -86,13 +86,13 @@ $shallow_import = ($shallow_import eq true);
# Possible values:
# - by_rev: perform one query per new revision on the remote wiki
# - by_page: query each tracked page for new revision
-my $fetch_strategy = run_git(config --get remote.$remotename.fetchStrategy);
+my $fetch_strategy = run_git(config --get
remote.${remotename}.fetchStrategy);
unless ($fetch_strategy) {
- $fetch_strategy = run_git(config --get mediawiki.fetchStrategy);
+ $fetch_strategy = run_git('config --get mediawiki.fetchStrategy');
}
chomp($fetch_strategy);
unless ($fetch_strategy) {
- $fetch_strategy = by_page;
+ $fetch_strategy = 'by_page';
}
# Remember the timestamp
[PATCH 06/18] Remove unused variable
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index a6c7de2..cf8dfc8 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -128,7 +128,6 @@ $wiki_name =~ s{[^/]*://}{};
$wiki_name =~ s/^.*@//;
# Commands parser
-my $entry;
my @cmd;
while (STDIN) {
chomp;
--
1.7.9.5
--
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/18] Rename a variable ($last) so that it does not have the name of a keyword
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index cf8dfc8..7fbc998 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -215,11 +215,11 @@ sub get_mw_page_list {
my $pages = shift;
my @some_pages = @$page_list;
while (@some_pages) {
- my $last = 50;
- if ($#some_pages $last) {
- $last = $#some_pages;
+ my $last_page = 50;
+ if ($#some_pages $last_page) {
+ $last_page = $#some_pages;
}
- my @slice = @some_pages[0..$last];
+ my @slice = @some_pages[0..$last_page];
get_mw_first_pages(\@slice, $pages);
@some_pages = @some_pages[51..$#some_pages];
}
--
1.7.9.5
--
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 14/18] Don't use quotes for empty strings
Empty strings are replaced by an $EMPTY constant.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index b7a7012..059bd1a 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -41,6 +41,8 @@ Readonly my $NULL_SHA1 =
'';
# Used on Git's side to reflect empty edit messages on the wiki
Readonly my $EMPTY_MESSAGE = '*Empty MediaWiki Message*';
+Readonly my $EMPTY = q{};
+
if (@ARGV != 2) {
exit_error_usage();
}
@@ -161,11 +163,11 @@ sub parse_commands {
mw_list($cmd[1]);
} elsif ($cmd[0] eq 'import') {
die(Invalid arguments for import\n)
- if ($cmd[1] eq || defined($cmd[2]));
+ if ($cmd[1] eq $EMPTY || defined($cmd[2]));
mw_import($cmd[1]);
} elsif ($cmd[0] eq 'option') {
die(Too many arguments for option\n)
- if ($cmd[1] eq || $cmd[2] eq || defined($cmd[3]));
+ if ($cmd[1] eq $EMPTY || $cmd[2] eq $EMPTY ||
defined($cmd[3]));
mw_option($cmd[1],$cmd[2]);
} elsif ($cmd[0] eq 'push') {
mw_push($cmd[1]);
@@ -556,7 +558,7 @@ sub mediawiki_clean {
# Mediawiki does not allow blank space at the end of a page and ends
with a single \n.
# This function right trims a string and adds a \n at the end to follow
this rule
$string =~ s/\s+$//;
- if ($string eq $page_created) {
+ if ($string eq $EMPTY $page_created) {
# Creating empty pages is forbidden.
$string = $EMPTY_CONTENT;
}
@@ -567,7 +569,7 @@ sub mediawiki_clean {
sub mediawiki_smudge {
my $string = shift;
if ($string eq $EMPTY_CONTENT) {
- $string = ;
+ $string = $EMPTY;
}
# This \n is important. This is due to mediawiki's way to handle end of
files.
return ${string}\n;
@@ -993,7 +995,7 @@ sub mw_upload_file {
} else {
# Don't let perl try to interpret file content as UTF-8 = use
raw
my $content = run_git(cat-file blob ${new_sha1}, 'raw');
- if ($content ne ) {
+ if ($content ne $EMPTY) {
mw_connect_maybe();
$mediawiki-{config}-{upload_url} =
${url}/index.php/Special:Upload;
@@ -1035,7 +1037,7 @@ sub mw_push_file {
my $newrevid;
if ($summary eq $EMPTY_MESSAGE) {
- $summary = '';
+ $summary = $EMPTY;
}
my $new_sha1 = $diff_info_split[3];
@@ -1046,7 +1048,7 @@ sub mw_push_file {
my ($title, $extension) = $complete_file_name =~ /^(.*)\.([^\.]*)$/;
if (!defined($extension)) {
- $extension = ;
+ $extension = $EMPTY;
}
if ($extension eq 'mw') {
my $ns = get_mw_namespace_id_for_page($complete_file_name);
@@ -1114,7 +1116,7 @@ sub mw_push {
if ($force) {
print {*STDERR} Warning: forced push not allowed on a
MediaWiki.\n;
}
- if ($local eq ) {
+ if ($local eq $EMPTY) {
print {*STDERR} Cannot delete remote branch on a
MediaWiki\n;
print {*STDOUT} error ${remote} cannot delete\n;
next;
--
1.7.9.5
--
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 16/18] Fix a typo (mediwiki instead of mediawiki)
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index ff9fd8f..952ddcc 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -1091,14 +1091,14 @@ sub mw_push_file {
# edit conflicts, considered as non-fast-forward
print {*STDERR} 'Warning: Error ' .
$mediawiki-{error}-{code} .
- ' from mediwiki: ' .
$mediawiki-{error}-{details} .
+ ' from mediawiki: ' .
$mediawiki-{error}-{details} .
.\n;
return ($oldrevid, 'non-fast-forward');
} else {
# Other errors. Shouldn't happen = just die()
die 'Fatal: Error ' .
$mediawiki-{error}-{code} .
- ' from mediwiki: ' .
$mediawiki-{error}-{details} . \n;
+ ' from mediawiki: ' .
$mediawiki-{error}-{details} . \n;
}
}
$newrevid = $result-{edit}-{newrevid};
--
1.7.9.5
--
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] rev-list: add --authorship-order alternative ordering
Elliott Cable m...@ell.io writes: And update revs-lifo to use that same enum, without adding use_author_date bit to rev_info. I'll look into replacing lifo with an enum as soon as I can sit back down to update this patch. For the moment, nothing more than committer_date_sort and author_date_sort, I suppose? I'll try and make this a separate patch. First commit, to replace lifo with an enum; second commit, to *actually implement* the code obeying that enum when it is set to author_date_order. If you want to do this in a multi-step series (which may not be a bad idea), I would imagine that the enum starts as a choice between the two: traversal-order vs committer-date-order. The first patch would change nothing else. And then you would add the third choice, author-date-order, and implement the logic to sort them using author instead of committer date in the same patch. Elliott: you can see the relevant changes to the topo-sort in commit 96c4f4a (commit: allow associating auxiliary info on-demand, 2013-04-09). -Peff Again, might be a little over my head. If you really think it's best that I look into that branch, I will try. :) Meantime, is there any other, more-immediate approach you can think of? I thought, for a moment, of only storing *either* the committer *or* the author date in the commit-struct at a given time, and flagging with a single bit ... but I'm not sure how widely-spread the nead for committer-date currently is. Maybe I can go back and parse-out the author date *when I need it*, instead, though that sounds slow … You would parse all of them at the beginning of topo-sort function once and store these dates in the commit-info-slab (alongside with indegree). Once you are done sorting, you can discard the slab. This could be done as a follow-up patch, but the tons of helper functions you added to compare by author date to revision.c will have to be removed in such a transition, because the whole point of using commit-info-slab is not to have commit-author_date field, which these new helpers work on. -- 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: [Administrivia] On ruby and contrib/
On Wed, Jun 5, 2013 at 6:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: But my main point is that I think it would be easier to phase out contrib/ if there were a good alternate way of providing visibility to satellite projects. The relevant Git wiki page [1] is the most likely candidate, but it is a bit overwhelming due to its size, it has fallen into disuse because it was broken for such a long time, and it is not prominently linked to from git-scm.com. If it were curated a bit, it would help users find the best ancillary tools quickly. Perhaps ranking the tools based on the results of the Git user surveys would help bring the most popular to the top of each category. One idea here could be to mirror what the libgit2 project [1] (and many others) are doing on GitHub. Use the organization unit [2] as an umbrella for the contrib projects. If necessary, put a pretty web-page on top [3]. Of course you don't have to tie it to GitHub, but they do have some nice mechanisms for showing off popularity (stars and forks). I heard that clojure/contrib [4] went through a big clean-up recently, although I'm not sure if there was an equivalent reasoning behind it. But their guide-lines on what should go into contrib may have some good ideas [5]. [1] https://github.com/libgit2 [2] https://github.com/git [3] http://libgit2.github.com/ [4] http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go [5] http://dev.clojure.org/pages/viewpage.action?pageId=5767464 -- 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: [Administrivia] On ruby and contrib/
David Lang wrote: Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? what's the ROI of this? Let's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is absolutely massive. It's an incredibly useful tool in that it actually works, and that there is nothing replacing it in the foreseeable future. This monster was written almost entirely by one brilliant person, and nobody is going to rewrite it. We don't start a huge discussion about what languages are approved before accepting such a contribution: if the contributor wants to write something in a dominant language (Perl in this case), and it's going to be useful, we merge it. End of story. All this planning is a colossal waste of time, in my opinion. Perl isn't going to disappear any time soon. What makes you think that whatever language you pick to replace Perl is going to be more stable than Perl is? Why are we discussing something that is indeterminate? It is impossible to foresee the future, but that is no reason to freeze _present_ development. and, like the parent poster, by 'stable' I mean from the compatibility point of view. Various programming languages have different philosophies, and have grown in different ways. What matters is that some of them have a large number of users, and we're talking about one such example. What are the odds that the 'newer' language that you pick is going to pull a python 3 on you? This has to be a rhetorical, because I don't imagine you expect anyone to predict the future. As Felipe already pointed out Ruby 2.0 is a good sign. There have been a very large number of scripting languages show up, make a lot of press, and then fade in favor of other languages while Perl has continued. It's not the sexy languange nowdays, but it's there, reliable, and used so heavily that there's really no chance of it dissapearing in the forseable future. Nobody claimed that press coverage is a good metric. We can only talk about facts, and Felipe already showed you a TIOBE index graph. If you have overwhelming _evidence_ that Ruby is a weak language that will die soon, share it: otherwise, I see no value in this discussion. -- 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
Пл
Отправлено с iPhonegmail-- 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: [Administrivia] On ruby and contrib/
Johannes Schindelin wrote: My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). Nevertheless, we had to do it, and we did it. We will do it again, if we get enough important code written in Ruby. As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Rewriting everything in C? Is anyone bored enough to pick up this task? Bourne shell is a great language for prototyping; git-rebase.sh (and friends), git-stash.sh, git-pull.sh are doing just fine. Sure, it makes sense to do heavy-lifting in C, and this is happening as it has always been happening (remember git-commit.sh?). If you followed the list emails, you'd know that Felipe is looking into delegating large portions of the work done by git-rebase.sh to sequencer.c. Anyway, all this talk about some hypothetical ideas just bores me. What matters is what is currently happening. And nobody is actively rewriting the core in Git in C, so I don't see the point of discussing anything but patches. -- 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: [Administrivia] On ruby and contrib/
On 06/06/2013 01:46 AM, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png The linchpin of your argument is that Perl is dying. Let's assume that the TIOBE index is a reliable basis for making business decisions--it's not, but let's pretend--the graph you linked to doesn't even seem to support your conclusion (or am I missing something?). It looks like Perl's popularity has pretty much been constant for at least two years. It's apparently not increasing in popularity, but this isn't an electrocardiogram (i.e. flat-lining is not dead or even dying). The same graph shows that Ruby's popularity also hasn't changed very much since 2007 after its initial surge. Now, it's probably too off-topic to pick apart TIOBE's methodology here, but suffice it to say that, like any trend indicator, it's only as useful as your knowledge of its limitations, and this has been discussed enough elsewhere. It's true that Perl isn't soon going to win any trendiness awards, but the same reasons that made Perl a good choice for git so many years ago are still there and then some. You would probably also be surprised at the number of new kids learning Perl. I guess I just denied the undeniable fact that Perl is going away, so maybe I'm one of those with whom you do not want to discuss this, but, for my part, I am willing to consider other evidence for the claim. As I pointed out, the evidence shown so far (one reference to the TIOBE index) isn't nearly enough to settle the matter. I also apologize for dragging this out if this thread is judged to not be worth a whole lot. -- Charles McGarvey signature.asc Description: OpenPGP digital signature
Re: [Administrivia] On ruby and contrib/
Greg Troxel wrote:
It's not about what I want. It's about making choices that affect other
people, and trying to find a plan that will be overall reasonable;
that's the essence of stewardship in packaging. Compiling for just
myself is far easier.
Have you asked the SBCL or Google-Chrome package maintainers what they
have to deal with? I believe they're packaging nightmares. GHC/
Haskell projects aren't far behind. Git is probably the _last_ thing
to be complaining about when it comes to packaging.
Sure, people want to run Git on embedded devices like Rpi. The core
is already in C and Bourne Shell, and I don't see anyone rewriting
that in Ruby. No cause for concern.
That ignores the 99% of people who use packaged versions. The question
is really Should the standared approach for building be to use or not
use dependency X?. Really this should be expressed in the README, and
it creates expectations for someone who just installs the git package in
terms of whether pieces of functionality are there. Packagers generally
should be reading the README and including required/recommended
dependencies and not including optional dependencies (in the main
package). The information in INSTALL is pretty reasonable, but it
doesn't really clearly say if you hand someone git built without perl,
it is { perfectly ok but missing a fringe optional feature | deficient
because git add -p won't work }. I'm leaning towards the deficient
camp.
So whom is this extra dependency affecting, if 99% of users are using
packaged versions? So, it's just extra burden for the package
maintainers (and users on source-based distributions)? git-svn and
git-send-email are already separate packages on Ubuntu/Debian because
they depend on lots of CPAN packages that can be non-trivial to
install for new users. If we do get one important Ruby script, ship
it as a separate package: done?
At the moment, there's just contrib/git-related that depends on ruby.
Can we just stop planning centuries in advance, and tackle the problem
when it arises? It remains to be determined whether or not git.git
will grow a healthy ruby sub-ecosystem. If it does, package
maintainers will be inconvenienced slightly. Otherwise, we'll just
throw out the ruby code that's rotting in our tree, and get on with
our lives.
The direction of the project is not decided on the basis of some vague
future packaging expectations. It's decided on the basis of what
patches come in from contributors, and everything else is secondary.
If people want to write ruby, they will write ruby. Whether or not
the git project welcomes their contributions.
--
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: Ignoring pattern in un-ignored directory not working anymore
Hey, yes, the problem is gone at 3684101a654d. Thanks. Kind regards, mosu -- 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 17/18] Place the open() call inside the do{} struct and prevent failing close
Célestin Matte celestin.ma...@ensimag.fr writes:
Placing the open() call inside the do{} struct will automatically close the
filehandle if possible.
Placing the close() call outside the do{} struct is useless and will make it
fail systematically
Change the error message to state that what fails is a fork(), not a file
opening.
Use autodie to properly exit when a print or open call fails.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 952ddcc..20ddccb 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -23,6 +23,7 @@ binmode STDOUT, ':encoding(UTF-8)';
use URI::Escape;
use Readonly;
+use autodie;
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
Readonly my $SLASH_REPLACEMENT = '%2F';
@@ -363,8 +364,6 @@ sub run_git {
local $/ = undef;
$git
};
- close($git);
-
return $res;
}
Confused. Which part of this patch moves open inside a do{} block?
This was last touched by [9/18] but it doesn't do any such thing,
either.
Upon leaving this subroutine, $git filehandle will go out of scope,
so in that sense, close may not be necessary, but that does not
match what the proposed log message claims what the patch does.
Also, this patch does not remove or die 9/18 added, even though
the proposed log message claims that with autodie it is no longer
necessary.
I am not convinced that using autodie globally, without vetting the
calls the original code make, is a good idea in the first place.
How does this change interact with existing calls to open, close,
etc. that check the return value from them, now these calls throw
exception and will not give a chance for the existing error handling
codepath to intervene?
--
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: [Administrivia] On ruby and contrib/
On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote: David Lang wrote: Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? what's the ROI of this? Let's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is absolutely massive. It's an incredibly useful tool in that it actually works, and that there is nothing replacing it in the foreseeable future. This monster was written almost entirely by one brilliant person, and nobody is going to rewrite it. We don't start a huge discussion about what languages are approved before accepting such a contribution: if the contributor wants to write something in a dominant language (Perl in this case), and it's going to be useful, we merge it. End of story. Well, Felipe is saying that Perl is dieing and we should re-write everything that exists in Perl to Ruby. Part of the reason for the discussion now is because not having similar discussions in the past have caused problems. All this planning is a colossal waste of time, in my opinion. Perl isn't going to disappear any time soon. What makes you think that whatever language you pick to replace Perl is going to be more stable than Perl is? Why are we discussing something that is indeterminate? It is impossible to foresee the future, but that is no reason to freeze _present_ development. and it's not a reason to throw away existing stuff based on the argument that Perl is dieing There have been a very large number of scripting languages show up, make a lot of press, and then fade in favor of other languages while Perl has continued. It's not the sexy languange nowdays, but it's there, reliable, and used so heavily that there's really no chance of it dissapearing in the forseable future. Nobody claimed that press coverage is a good metric. We can only talk about facts, and Felipe already showed you a TIOBE index graph. If you have overwhelming _evidence_ that Ruby is a weak language that will die soon, share it: otherwise, I see no value in this discussion. TIOBE index graph is press coverage as far as I'm concerned. I'm not saying that Ruby in particular has a fatal flaw, I'm just questioning the Perl is dead, re-write everything in Ruby mantra. The language that you choose to use when writing a new application is related to things related to that type of application. Ruby is not an extremely common language for sysadmins to use. Perl remains a common language for these sorts of tasks, even if it's not used for user visible applications. Arguing that Perl is dieing, we need to abandon it is just wrong. David Lang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git diff bug?
Hello All, If I did 'git diff HEAD^..HEAD -- file' should git not report some kind of warning if it could not match the file? For example, if 'file' were infact 'dir/file' and 'file' were unique, would it not be a good idea to report that in the present working directory 'file' were not found but 'dir/file' were a match? Apologies if I missed this in the man page. Thanks -- 010 001 111 -- 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 17/18] Place the open() call inside the do{} struct and prevent failing close
Le 06/06/2013 23:13, Junio C Hamano a écrit :
Confused. Which part of this patch moves open inside a do{} block?
This was last touched by [9/18] but it doesn't do any such thing,
either.
I must have failed the rebase, as the first part of the commit moved to
[14/18] because it modifies a part of it:
@@ -344,10 +344,10 @@ sub get_mw_pages {
#$out = run_git(command args, raw); # don't interpret
output as UTF-8.
sub run_git {
my $args = shift;
- my $encoding = (shift || encoding(UTF-8));
- open(my $git, -|:$encoding, git . $args)
- or die Unable to open: $!\n;
- my $res = do {
+ my $encoding = (shift || 'encoding(UTF-8)');
+ my $res = do {
+ open(my $git, -|:$encoding, git ${args})
+ or die Unable to fork: $!\n;
local $/ = undef;
$git
};
I'm not sure how I should correct this. I'll have a look if this commit
actually is useful.
Upon leaving this subroutine, $git filehandle will go out of scope,
so in that sense, close may not be necessary, but that does not
match what the proposed log message claims what the patch does.
Also, this patch does not remove or die 9/18 added, even though
the proposed log message claims that with autodie it is no longer
necessary.
I am not convinced that using autodie globally, without vetting the
calls the original code make, is a good idea in the first place.
How does this change interact with existing calls to open, close,
etc. that check the return value from them, now these calls throw
exception and will not give a chance for the existing error handling
codepath to intervene?
So using autodie may not be a good idea.
But the problem is that in the current state, open() return values are
checked, but print ones are not, although it should be. So, either:
- we use autodie and remove checking of existing return values, or
- we don't use autodie and add checking of return value of print calls
- or I'm missing some point :)
--
Célestin Matte
--
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
Dependencies and packaging (Re: [Administrivia] On ruby and contrib/)
Ramkumar Ramachandra wrote: Git is probably the _last_ thing to be complaining about when it comes to packaging. It would be nice if contrib/ files supported the usual make; make install; make clean targets. That's missing functionality that does matter to at least one packager. It would be nice if the dependencies associated to each piece of functionality or makefile flag were documented more clearly. Currently when e.g. features of gitweb gain dependencies I don't notice until the testsuite fails. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git diff bug?
Le 06/06/2013 23:26, Sarma Tangirala a écrit : Hello All, If I did 'git diff HEAD^..HEAD -- file' should git not report some kind of warning if it could not match the file? For example, if 'file' were infact 'dir/file' and 'file' were unique, would it not be a good idea to report that in the present working directory 'file' were not found but 'dir/file' were a match? I don't know any program doing such a thing, and I don't think it is the role of the program to predict which file the user actually wanted to provide in the command line. That would imply looking for files with the same name or a close name in the current directory and its subdirectories - and maybe even in the superdirectory? It is hard to decide when you have to stop looking for the file. -- 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 17/18] Place the open() call inside the do{} struct and prevent failing close
Célestin Matte celestin.ma...@ensimag.fr writes:
So using autodie may not be a good idea.
But the problem is that in the current state, open() return values are
checked, but print ones are not, although it should be.
I tried man autodie and tried to spot 'print' in the categories
list that shows things like :all covers :default which in turn
covers :io which in turn covers read, seek, ... and didn't see any.
Running the attached as
$ perl ad.perl -
gave me Hi (i.e. no failure from print) but of course killed a
failing syswrite().
So I am not sure your we must check print matches well with use of
autodie, either.
-- 8 --
#!/usr/bin/perl -w
use warnings;
use autodie;
for (my $i = 0; $i 256; $i++) {
print Did this die?\n;
}
print STDERR Hi\n;
for (my $i = 0; $i 256; $i++) {
syswrite(1, Did this die?\n);
}
print STDERR Lo\n;
exit(0);
--- 8 --
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git diff bug?
Célestin Matte celestin.ma...@ensimag.fr writes: Le 06/06/2013 23:26, Sarma Tangirala a écrit : Hello All, If I did 'git diff HEAD^..HEAD -- file' should git not report some kind of warning if it could not match the file? For example, if 'file' were infact 'dir/file' and 'file' were unique, would it not be a good idea to report that in the present working directory 'file' were not found but 'dir/file' were a match? I don't know any program doing such a thing, and I don't think it is the role of the program to predict which file the user actually wanted to provide in the command line. That would imply looking for files with the same name or a close name in the current directory and its subdirectories - and maybe even in the superdirectory? It is hard to decide when you have to stop looking for the file. The parameters after -- are pathspecs, which is a set of patterns the paths discovered by the operation (in this case diff that finds paths in HEAD^ and HEAD) are matched against. They are used to filter out uninteresting paths. If HEAD^ and HEAD does not have anything that match the given pattern (in this case, literal four-letter string file), the set of interesting paths may become empty and that is perfectly normal. So this is working as designed. Having said that, we do detect typo by noticing when a pathspec did not find _any_ path that matched it in some front-end Porcelain commands, e.g. $ git add 'foo*' fatal: pathspec 'foo*' did not match any files It is unreasonable to do the same in git log old..new -- path and error out when the pathspec does not match, because it is normal for some revisions to have path while some other revisions to lack it. But for a two-endpoint diff Porcelain (not the plumbing diff-files, diff-index and diff-tree), I do not think it is particularly a bad idea to add such a typo-detection feature. -- 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 17/18] Place the open() call inside the do{} struct and prevent failing close
Le 06/06/2013 23:58, Junio C Hamano a écrit : Célestin Matte celestin.ma...@ensimag.fr writes: So using autodie may not be a good idea. But the problem is that in the current state, open() return values are checked, but print ones are not, although it should be. I tried man autodie and tried to spot 'print' in the categories list that shows things like :all covers :default which in turn covers :io which in turn covers read, seek, ... and didn't see any. Running the attached as $ perl ad.perl - gave me Hi (i.e. no failure from print) but of course killed a failing syswrite(). You're right, print is not in the list of function checked by autodie. So I am not sure your we must check print matches well with use of autodie, either. So I'm not sure what we should do for print calls: should we systematically check them all? That would be a painful and less-readable thing to do. We may just not bother about it, after all... -- 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
What's cooking in git.git (Jun 2013, #03; Thu, 6)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * jk/list-objects-sans-blobs (2013-06-06) 4 commits - archive: ignore blob objects when checking reachability - list-objects: optimize revs-blob_objects = 0 case - upload-archive: restrict remote objects with reachability check - clear parsed flag when we free tree buffers Attempt to allow archive --remote=$there $arbitrary_sha1 while keeping the reachability safety. -- [Graduated to master] * dm/unbash-subtree (2013-05-21) 1 commit (merged to 'next' on 2013-06-03 at 2c9d2fb) + contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash It turns out that git-subtree script does not have to be run with bash. * fc/cleanups (2013-05-28) 3 commits (merged to 'next' on 2013-06-03 at 527cf93) + test: rebase: fix --interactive test + test: trivial cleanups + remote: trivial style cleanup * fc/makefile (2013-05-26) 5 commits (merged to 'next' on 2013-06-03 at d1074e4) + build: do not install git-remote-testpy + build: add NO_INSTALL variable + build: cleanup using $ + build: cleanup using $^ + build: trivial simplification (this branch is used by fc/remote-helpers-use-specified-python.) Stop installing the git-remote-testpy script that is only used for testing. Also use handy magic variables to simplify rules. * fc/send-email-chainreplyto-warning (2013-05-28) 1 commit (merged to 'next' on 2013-06-03 at e04764f) + send-email: remove warning about unset chainreplyto An overdue removal of behaviour changed at 1.7.0; if you were living in a cave, here is what you can adjust to it message. * fc/show-branch-in-rebase-am (2013-05-29) 1 commit (merged to 'next' on 2013-06-03 at 176f6b7) + prompt: fix for simple rebase The bash prompt code (in contrib/) displayed the name of the branch being rebased when rebase -i/-m/-p modes are in use, but not the plain vanilla rebase. * fc/transport-helper-no-refspec (2013-05-21) 2 commits (merged to 'next' on 2013-06-03 at 8763bda) + transport-helper: check if the dry-run is supported + transport-helper: barf when user tries old:new With export remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run, so detect such problematic cases and disable them for now. * jc/core-checkstat (2013-05-06) 1 commit (merged to 'next' on 2013-06-03 at 2166cb3) + deprecate core.statinfo at Git 2.0 boundary (this branch is used by jc/core-checkstat-2.0.) The configuration variable core.checkstat was advertised in the documentation but the code expected core.statinfo instead. For now, we accept both core.checkstat and core.statinfo, but the latter will be removed in the longer term. * ks/difftool-dir-diff-copy-fix (2013-05-29) 1 commit (merged to 'next' on 2013-06-03 at ca0cae0) + difftool --dir-diff: allow changing any clean working tree file difftool --dir-diff did not copy back changes made by the end-user in the diff tool backend to the working tree in some cases. * nd/clone-connectivity-shortcut (2013-05-28) 4 commits (merged to 'next' on 2013-06-03 at 812bd80) + clone: open a shortcut for connectivity check + index-pack: remove dead code (it should never happen) + fetch-pack: prepare updated shallow file before fetching the pack + clone: let the user know when check_everything_connected is run git clone uses a lighter-weight implementation when making sure that the history behind refs are complete. * nd/prune-packed-dryrun-verbose (2013-05-28) 1 commit (merged to 'next' on 2013-06-03 at 3445b27) + prune-packed: avoid implying 1 is DRY_RUN in prune_packed_objects() * nd/urls-doc-no-file-hyperlink-fix (2013-05-24) 1 commit (merged to 'next' on 2013-06-03 at 54903b2) + urls.txt: avoid auto converting to hyperlink An entry for file:// scheme in the enumeration of URL types Git can take in the HTML documentation was made into a clickable link by mistake. * rj/mingw-compat-st-mode-bits (2013-05-29) 1 commit (merged to 'next' on 2013-06-03 at 2efe84c) + path: Fix a sparse warning * rr/push-head (2013-05-29) 3 commits (merged to 'next' on 2013-06-03 at ecd5be7) + push: make push.default = current use resolved HEAD + push: fail early with detached HEAD and current + push: factor out the detached HEAD error message git push $there HEAD:branch did not resolve HEAD early enough, so it was easy to flip it around while push is still going on and push out a branch that the user did not originally intended when the command was
Re: [PATCH/RFC] rev-list: add --authorship-order alternative ordering
Junio C Hamano gits...@pobox.com writes: If you want to do this in a multi-step series (which may not be a bad idea), I would imagine that the enum starts as a choice between the two: traversal-order vs committer-date-order. The first patch would change nothing else. And then you would add the third choice, author-date-order, and implement the logic to sort them using author instead of committer date in the same patch. ... You would parse all of them at the beginning of topo-sort function once and store these dates in the commit-info-slab (alongside with indegree). Once you are done sorting, you can discard the slab. This could be done as a follow-up patch, but the tons of helper functions you added to compare by author date to revision.c will have to be removed in such a transition, because the whole point of using commit-info-slab is not to have commit-author_date field, which these new helpers work on. As I needed to have an excuse to push jk/commit-info-slab topic further (I have an unpublished show-branch rewrite on top of it), I may take a look at doing this myself if/when I find some time. -- 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] toposort: rename lifo field
When sorting commits topologically, the primary invariant is to emit
all children before its parent is emitted. When traversing a forked
history like this with git log C E:
ABC
\
DE
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown. Most of the time, we would want to see C and B emitted
together, and then E and D, and finally A. This is the default
behaviour for --topo-order output.
The lifo parameter of the sort_in_topological_order() function is
used to control this. After inspecting C, we notice and record that
B needs to be inspected, and by structuring the work to be done
set as a LIFO stack, we ensure that B is inspected next, before
other in-flight commits we had known that we will need to inspect,
e.g. E, that have already been in the work to be done set.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, mixing commits from two parallel histories together. When lifo
is set to false, the function keeps the work to be done set sorted
in the date order to realize this sematics.
But the name lifo is too tied to the way how the function implements
its behaviour, and does not describe _what_ is the desired semantcs.
Replace the lifo field with an enum rev_sort_order, with two
possible values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE.
The mechanical replacement rule is:
lifo == 0 is equivalent to sort_order == REV_SORT_BY_COMMIT_DATE
lifo == 1 is equivalent to sort_order == REV_SORT_IN_GRAPH_ORDER
Signed-off-by: Junio C Hamano gits...@pobox.com
---
As I needed to have an excuse to push jk/commit-info-slab topic
further (I have an unpublished show-branch rewrite on top of it),
I may take a look at doing this myself if/when I find some time.
So this is the first step, applies on top of jk/commit-info-slab.
builtin/log.c | 2 +-
builtin/show-branch.c | 14 --
commit.c | 12
commit.h | 14 +++---
revision.c| 10 +-
revision.h| 6 +-
6 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 8f0b2e8..8d26042 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -205,7 +205,7 @@ static void log_show_early(struct rev_info *revs, struct
commit_list *list)
int i = revs-early_output;
int show_header = 1;
- sort_in_topological_order(list, revs-lifo);
+ sort_in_topological_order(list, revs-sort_order);
while (list i) {
struct commit *commit = list-item;
switch (simplify_commit(revs, commit)) {
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index d208fd6..7c57985 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -631,7 +631,7 @@ int cmd_show_branch(int ac, const char **av, const char
*prefix)
int num_rev, i, extra = 0;
int all_heads = 0, all_remotes = 0;
int all_mask, all_revs;
- int lifo = 1;
+ enum rev_sort_order sort_order = REV_SORT_IN_GRAPH_ORDER;
char head[128];
const char *head_p;
int head_len;
@@ -666,15 +666,17 @@ int cmd_show_branch(int ac, const char **av, const char
*prefix)
N_(show possible merge bases)),
OPT_BOOLEAN(0, independent, independent,
N_(show refs unreachable from any other ref)),
- OPT_BOOLEAN(0, topo-order, lifo,
- N_(show commits in topological order)),
+ OPT_SET_INT(0, topo-order, sort_order,
+ N_(show commits in topological order),
+ REV_SORT_IN_GRAPH_ORDER),
OPT_BOOLEAN(0, topics, topics,
N_(show only commits not on the first branch)),
OPT_SET_INT(0, sparse, dense,
N_(show merges reachable from only one tip), 0),
- OPT_SET_INT(0, date-order, lifo,
+ OPT_SET_INT(0, date-order, sort_order,
N_(show commits where no parent comes before its
- children), 0),
+ children),
+ REV_SORT_BY_COMMIT_DATE),
{ OPTION_CALLBACK, 'g', reflog, reflog_base,
N_(n[,base]),
N_(show n most recent ref-log entries starting
at
base),
@@ -901,7 +903,7 @@ int cmd_show_branch(int ac, const char **av, const char
*prefix)
exit(0);
/* Sort topologically */
- sort_in_topological_order(seen, lifo);
+ sort_in_topological_order(seen,
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote: * rr/complete-difftool (2013-06-03) 2 commits (merged to 'next' on 2013-06-04 at 01c7611) + completion: clarify ls-tree, archive, show completion + completion: difftool takes both revs and files Update command line completion (in contrib/) to use a better named completion helper function for commands that take revisions and paths. Will merge to 'master'. This should not be merged to master as is; the one at the top because of the reasons given in $gmane/226272, the one at the bottom because of the misleading commit message (__git_complete_file() always completed refs first as part of the ref:file notation, so it worked just fine except for the ref1...ref2 notation; the real reason for calling __git_complete_revlist_file() for difftool is to make clear that difftool takes ref1...ref2:file, too). Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] archive: ignore blob objects when checking reachability
On Wed, Jun 5, 2013 at 6:40 PM, Jeff King p...@peff.net wrote: We cannot create an archive from a blob object, so we would not expect anyone to provide one to us. And if they do, we will fail anyway just after the reachability check. We can therefore optimize our reachability check to ignore blobs completely, and not even create a struct blob for them. Depending on the repository size and the exact place we find the reachable object in the traversal, this can save 20-25%, a we can avoid many lookups in the object hash. s/a/as/ The downside of this is that a blob provided to a remote archive process will fail with no such object rather than object is not a tree (we could organize the code to retain the old message, but since we no longer know whether the blob is reachable or not, we would potentially be leaking information about the existence of unreachable objects). Signed-off-by: Jeff King p...@peff.net -- 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 (Jun 2013, #03; Thu, 6)
SZEDER Gábor sze...@ira.uka.de writes: On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote: * rr/complete-difftool (2013-06-03) 2 commits (merged to 'next' on 2013-06-04 at 01c7611) + completion: clarify ls-tree, archive, show completion + completion: difftool takes both revs and files Update command line completion (in contrib/) to use a better named completion helper function for commands that take revisions and paths. Will merge to 'master'. This should not be merged to master as is; the one at the top because of the reasons given in $gmane/226272, the one at the bottom because of the misleading commit message (__git_complete_file() always completed refs first as part of the ref:file notation, so it worked just fine except for the ref1...ref2 notation; the real reason for calling __git_complete_revlist_file() for difftool is to make clear that difftool takes ref1...ref2:file, too). Oops. It is too late to amend the log messages now, but at least a follow-up patch can fix the breakage by adding __git_complete_file() back. Would you mind doing that? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/18] Explicitely assign local variable as undef and make a proper one-instruction-by- line indentation
On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte celestin.ma...@ensimag.fr wrote: [PATCH 08/18] Explicitely assign local variable as undef and make a proper one-instruction-by- line indentation s/Explicitely/Explicitly/ s/by- /by-/ Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr -- 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] toposort: rename lifo field
Junio C Hamano gits...@pobox.com writes:
When sorting commits topologically, the primary invariant is to emit
all children before its parent is emitted. When traversing a forked
s/its/their/;
As I needed to have an excuse to push jk/commit-info-slab topic
further (I have an unpublished show-branch rewrite on top of it),
I may take a look at doing this myself if/when I find some time.
So this is the first step, applies on top of jk/commit-info-slab.
The next step will be to replace the use of commit_list in this
function with a priority queue, whose API may look like what is at
the end of this message.
Then write a compare function that looks at commit-date field to
compare committer timestamp, and set it to commit_queue-compare
when REV_SORT_BY_COMMIT_DATE is asked for. When doing the graph
traversal order, set compare function to NULL when initializing the
commit_queue and use it as a LIFO stack.
And the step after that will be to add an author-date field to the
commit-info-slab we currently use to keep track of indegree, grab
author timestamp from commits as we encounter them, and write
another comparison function to use that information (using the
cb_data field of commit_queue to point at the info slab) to
implement REV_SORT_BY_AUTHOR_DATE. That step can also implement the
command line option parsing for the new --author-date-order option
(or alternatively, --date-order={author,committer}).
#ifndef COMMIT_QUEUE_H
#define COMMIT_QUEUE_H
/*
* Compare two commits; the third parameter is cb_data in the
* commit_queue structure.
*/
typedef int (*commit_compare_fn)(struct commit *, struct commit *, void *);
struct commit_queue {
commit_compare_fn compare;
void *cb_data;
int alloc, nr;
struct commit **array;
};
/*
* Add the commit to the queue
*/
struct commit *commit_queue_put(struct commit_queue *, struct commit *);
/*
* Extract the commit that compares the smallest out of the queue,
* or NULL. If compare function is NULL, the queue acts as a LIFO
* stack.
*/
struct commit *commit_queue_get(struct commit_queue *);
#endif /* COMMIT_QUEUE_H */
--
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
is there a fast web-interface to git for huge repos?
Hi, On a relatively-empty Intel Core i7 975 @ 3.33GHz (quad-core): Cns# cd DragonFly/ Cns# time git log sys/sys/sockbuf.h /dev/null 0.540u 0.140s 0:04.30 15.8% 0+0k 2754+55io 6484pf+0w Cns# time git log sys/sys/sockbuf.h /dev/null 0.000u 0.030s 0:00.52 5.7% 0+0k 0+0io 0pf+0w Cns# time git log sys/sys/sockbuf.h /dev/null 0.180u 0.020s 0:00.52 38.4% 0+0k 0+2io 0pf+0w Cns# time git log sys/sys/sockbuf.h /dev/null 0.420u 0.020s 0:00.52 84.6% 0+0k 0+0io 0pf+0w And, right away, a semi-cold git-blame: Cns# time git blame sys/sys/sockbuf.h /dev/null 0.340u 0.040s 0:01.91 19.8% 0+0k 769+45io 2078pf+0w Cns# time git blame sys/sys/sockbuf.h /dev/null 0.340u 0.010s 0:00.36 97.2% 0+0k 0+2io 0pf+0w Cns# time git blame sys/sys/sockbuf.h /dev/null 0.310u 0.040s 0:00.36 97.2% 0+0k 0+0io 0pf+0w Cns# time git blame sys/sys/sockbuf.h /dev/null 0.310u 0.050s 0:00.36 100.0%0+0k 0+0io 0pf+0w I'm interested in running a web interface to this and other similar git repositories (FreeBSD and NetBSD git repositories are even much, much bigger). Software-wise, is there no way to make cold access for git-log and git-blame to be orders of magnitude less than ~5s, and warm access less than ~0.5s? C. -- 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 01/18] Follow perlcritic's recommendations - level 5 and 4
On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Fix warnings from perlcritic's level 5 and 4. They correspond to the following
cases:
- always end a submodule with a return
- don't use the constant pragma, use the Readonly module instead
- some syntax details for maps, and others.
Although loosely related by being mentioned by perlcritic (4,5), each
bullet point is otherwise unrelated, and mixing such unrelated changes
into a single patch can make review more difficult.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 81
+--
1 file changed, 51 insertions(+), 30 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 410eae9..83cf292 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -15,32 +15,32 @@ use strict;
use MediaWiki::API;
use Git;
use DateTime::Format::ISO8601;
+use warnings;
# By default, use UTF-8 to communicate with Git and the user
-binmode STDERR, :utf8;
-binmode STDOUT, :utf8;
+binmode STDERR, :encoding(UTF-8);
+binmode STDOUT, :encoding(UTF-8);
This change isn't explained or rationalized in the commit message.
@@ -96,6 +96,9 @@ unless ($fetch_strategy) {
$fetch_strategy = by_page;
}
+# Remember the timestamp corresponding to a revision id.
+my %basetimestamps;
Although this is a simple textual relocation, it's not clear why it's
needed or preferable, and the commit message does not explain it.
@@ -473,9 +486,6 @@ sub get_last_local_revision {
return $lastrevision_number;
}
-# Remember the timestamp corresponding to a revision id.
-my %basetimestamps;
-
# Get the last remote revision without taking in account which pages are
# tracked or not. This function makes a single request to the wiki thus
# avoid a loop onto all tracked pages. This is useful for the fetch-by-rev
@@ -555,7 +565,7 @@ sub mediawiki_smudge {
sub mediawiki_clean_filename {
my $filename = shift;
- $filename =~ s/@{[SLASH_REPLACEMENT]}/\//g;
+ $filename =~ s{$SLASH_REPLACEMENT}{/}g;
Although patch 2/18 replaces regex // with {}, the change sneaked into
this patch (1/18) prematurely.
# [, ], |, {, and } are forbidden by MediaWiki, even URL-encoded.
# Do a variant of URL-encoding, i.e. looks like URL-encoding,
# but with _ added to prevent MediaWiki from thinking this is
@@ -569,7 +579,7 @@ sub mediawiki_clean_filename {
sub mediawiki_smudge_filename {
my $filename = shift;
- $filename =~ s/\//@{[SLASH_REPLACEMENT]}/g;
+ $filename =~ s{/}{$SLASH_REPLACEMENT}g;
Ditto regarding // to {}.
$filename =~ s/ /_/g;
# Decode forbidden characters encoded in mediawiki_clean_filename
$filename =~ s/_%_([0-9a-fA-F][0-9a-fA-F])/sprintf(%c, hex($1))/ge;
@@ -588,7 +599,8 @@ sub literal_data_raw {
utf8::downgrade($content);
binmode STDOUT, :raw;
print STDOUT data , bytes::length($content), \n, $content;
- binmode STDOUT, :utf8;
+ binmode STDOUT, :encoding(UTF-8);
Unexplained change.
+ return;
}
sub mw_capabilities {
@@ -1314,7 +1334,8 @@ sub get_mw_namespace_id {
}
sub get_mw_namespace_id_for_page {
- if (my ($namespace) = $_[0] =~ /^([^:]*):/) {
+ my $namespace = shift;
+ if ($namespace =~ /^([^:]*):/) {
Another change not mentioned by the commit message.
return get_mw_namespace_id($namespace);
} else {
return;
--
--
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 02/18] Change style of some regular expressions to make them clearer
On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
- Remove m modifier when useless (m// and // was used randomly; this makes the
code more coherent)
- Remove stringy split (split('c', ...) instead of split(/c/, ...))
- Use {}{} instead of /// when slashes or used inside the regexp so as not to
escape it.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 83cf292..482cd95 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -121,7 +121,7 @@ chomp($dumb_push);
$dumb_push = ($dumb_push eq true);
my $wiki_name = $url;
-$wiki_name =~ s/[^\/]*:\/\///;
+$wiki_name =~ s{[^/]*://}{};
# If URL is like http://user:passw...@example.com/, we clearly don't
# want the password in $wiki_name. While we're there, also remove user
# and '@' sign, to avoid author like MWUser@httpu...@host.com
@@ -762,7 +762,7 @@ sub get_more_refs {
my @refs;
while (1) {
my $line = STDIN;
- if ($line =~ m/^$cmd (.*)$/) {
+ if ($line =~ /^$cmd (.*)$/) {
push(@refs, $1);
} elsif ($line eq \n) {
return @refs;
@@ -1168,11 +1168,11 @@ sub mw_push_revision {
my @local_ancestry = split(/\n/, run_git(rev-list --boundary
--parents $local ^$parsed_sha1));
my %local_ancestry;
foreach my $line (@local_ancestry) {
- if (my ($child, $parents) = $line =~ m/^-?([a-f0-9]+)
([a-f0-9 ]+)/) {
- foreach my $parent (split(' ', $parents)) {
+ if (my ($child, $parents) = $line =~ /^-?([a-f0-9]+)
([a-f0-9 ]+)/) {
+ foreach my $parent (split(/ /, $parents)) {
This is a behavior-altering change. split(' ',...) is handled as a
special case[*1*] which strips leading whitespace and then splits on
/\s+/ (run of whitespace). Changing it to split(/ /,...) makes it
match only a single space (rather than a run of whitespace).
[*1*] http://perldoc.perl.org/functions/split.html
$local_ancestry{$parent} = $child;
}
- } elsif (!$line =~ m/^([a-f0-9]+)/) {
+ } elsif (!$line =~ /^([a-f0-9]+)/) {
die Unexpected output from git rev-list:
$line;
}
}
@@ -1190,10 +1190,10 @@ sub mw_push_revision {
# history (linearized with --first-parent)
print STDERR Warning: no common ancestor, pushing complete
history\n;
my $history = run_git(rev-list --first-parent --children
$local);
- my @history = split('\n', $history);
+ my @history = split(/\n/, $history);
@history = @history[1..$#history];
foreach my $line (reverse @history) {
- my @commit_info_split = split(/ |\n/, $line);
+ my @commit_info_split = split(/[ \n]/, $line);
push(@commit_pairs, \@commit_info_split);
}
}
@@ -1272,7 +1272,7 @@ sub get_mw_namespace_id {
# Look at configuration file, if the record for that
namespace is
# already cached. Namespaces are stored in form:
# Name_of_namespace:Id_namespace, ex.: File:6.
- my @temp = split(/[\n]/, run_git(config --get-all remote.
+ my @temp = split(/\n/, run_git(config --get-all remote.
. $remotename
..namespaceCache));
chomp(@temp);
foreach my $ns (@temp) {
--
1.7.9.5
--
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
--
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 02/18] Change style of some regular expressions to make them clearer
Eric Sunshine sunsh...@sunshineco.com writes:
- if (my ($child, $parents) = $line =~
m/^-?([a-f0-9]+) ([a-f0-9 ]+)/) {
- foreach my $parent (split(' ', $parents)) {
+ if (my ($child, $parents) = $line =~ /^-?([a-f0-9]+)
([a-f0-9 ]+)/) {
+ foreach my $parent (split(/ /, $parents)) {
This is a behavior-altering change. split(' ',...) is handled as a
special case[*1*] which strips leading whitespace and then splits on
/\s+/ (run of whitespace). Changing it to split(/ /,...) makes it
match only a single space (rather than a run of whitespace).
I initially had the same reaction, but this is reading the output of
the rev-list --parents command, whose fields are separated by one
SP each, so there is indeed no behaviour change.
--
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
Is there a library for monitoring a git repository for any changes?
Hi git, I want to work on a visualization program for git. I was hoping there was a library that would allow me to monitor a git repo for changes. Consider it like inotify, but for a git repository (in fact, I think it would probably have inotify under the hood). This hypothetical library would trigger an event any time the repository was modified, i.e. any time the graph that represents history was changed. Is there such a library? If not, is there a better way to monitor the repository so that I wouldn't need to write it myself? Would anyone else be interested if I wrote it myself? Cheers, Robert -- 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: [Administrivia] On ruby and contrib/
Hi Ram, On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote: Johannes Schindelin wrote: My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). Nevertheless, we had to do it, and we did it. That is not quite correct. *I* did it. Not *we*. And I will not do it again. We will do it again, if we get enough important code written in Ruby. I am a bit bored by this hypothetical talk. This hypothetical we will do it again, to be precise. Given my experience, it would be very painful if enough important code was written in Ruby. Nobody would help me do it again. Just like nobody helps right now to upgrade to a newer Perl. Feel free to prove me wrong. Until that time, I will firmly believe that there is no we will do it again. So here is a chance to prevent that: not repeat the mistake, and stay away from language hell by avoiding to require yet another language. As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Rewriting everything in C? Is anyone bored enough to pick up this task? Bourne shell is a great language for prototyping; git-rebase.sh (and friends), git-stash.sh, git-pull.sh are doing just fine. Sure, it makes sense to do heavy-lifting in C, and this is happening as it has always been happening (remember git-commit.sh?). If you followed the list emails, you'd know that Felipe is looking into delegating large portions of the work done by git-rebase.sh to sequencer.c. As you know, there are very good reasons why I do not follow those mails. Anyway, all this talk about some hypothetical ideas just bores me. What matters is what is currently happening. And nobody is actively rewriting the core in Git in C, so I don't see the point of discussing anything but patches. Exactly. Nobody really cares about keeping Git portable enough. Hence my impression that this idea to start requiring yet another language for core parts of Git is a bit misguided, and only logical from the point of view: If you don't like it, why don't you install Linux? (which, just in case you wondered, is a pretty naive way of looking at the real world). Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/18] Remove unless statements and replace them by negated if statements
On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 757a7a3..b7a7012 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -87,11 +87,11 @@ $shallow_import = ($shallow_import eq 'true');
# - by_rev: perform one query per new revision on the remote wiki
# - by_page: query each tracked page for new revision
my $fetch_strategy = run_git(config --get
remote.${remotename}.fetchStrategy);
-unless ($fetch_strategy) {
+if (! $fetch_strategy) {
Minor style nit: Existing code in git-remote-mediawiki.perl does not
have whitespace following '!'. This nit applies to this entire patch,
so: s/! /!/g
$fetch_strategy = run_git('config --get mediawiki.fetchStrategy');
}
chomp($fetch_strategy);
-unless ($fetch_strategy) {
+if (! $fetch_strategy) {
$fetch_strategy = 'by_page';
}
@@ -113,7 +113,7 @@ my %basetimestamps;
# deterministic, this means everybody gets the same sha1 for each
# MediaWiki revision.
my $dumb_push = run_git(config --get --bool remote.${remotename}.dumbPush);
-unless ($dumb_push) {
+if (! $dumb_push) {
$dumb_push = run_git('config --get --bool mediawiki.dumbPush');
}
chomp($dumb_push);
@@ -668,7 +668,7 @@ sub fetch_mw_revisions_for_page {
push(@page_revs, $page_rev_ids);
$revnum++;
}
- last unless $result-{'query-continue'};
+ last if (! $result-{'query-continue'});
$query-{rvstartid} =
$result-{'query-continue'}-{revisions}-{rvstartid};
}
if ($shallow_import @page_revs) {
@@ -1240,7 +1240,7 @@ sub mw_push_revision {
die(Unknown error from mw_push_file()\n);
}
}
- unless ($dumb_push) {
+ if (! $dumb_push) {
run_git(qq(notes --ref=${remotename}/mediawiki add -f
-m mediawiki_revision: ${mw_revision} ${sha1_commit}));
run_git(qq(update-ref -m Git-MediaWiki push
refs/mediawiki/${remotename}/master ${sha1_commit} ${sha1_child}));
}
@@ -1320,7 +1320,7 @@ sub get_mw_namespace_id {
my $ns = $namespace_id{$name};
my $id;
- unless (defined $ns) {
+ if (! defined $ns) {
print {*STDERR} No such namespace ${name} on MediaWiki.\n;
$ns = {is_namespace = 0};
$namespace_id{$name} = $ns;
--
1.7.9.5
--
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
--
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
