Re: [PATCH 1/2] am: handle stray $dotest directory
Ramkumar Ramachandra wrote: > Can you tell me how to get shell-script-mode to indent the > case statement properly? (I used the default indentation) Never mind; I figured it out: (setq sh-indent-for-case-label 0) (setq sh-indent-for-case-alt '+) Maybe we should dump the relevant parts of my .emacs somewhere in-tree? -- To unsubscribe from this list: send the line "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, #05; Sat, 15)
Junio C Hamano wrote:
> * rr/am-quit-empty-then-abort-fix (2013-06-14) 2 commits
> - SQUASH???
> - am: handle stray $dotest directory
Please pick up the latest iteration.
http://thread.gmane.org/gmane.comp.version-control.git/227946
> * rr/triangle-push-fix (2013-06-09) 4 commits
> - t/push-default: test pushdefault with all modes
> - t/push-default: generalize test_push_{success, commit}
> - push: make upstream, simple work with pushdefault
> - t/push-default: remove redundant test_config lines
>
> Tries to apply the 'push.default = upstream' semantics to
> triangular workflow where it does not quite apply.
>
> Waiting for a reroll.
Still haven't figured out a solution; will hopefully come up with
something in a few days. Discard if necessary.
There are some other topics I posted awaiting responses. Take some
time out to read especially the for-each-ref enhancement series that
Duy and I wrote.
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 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote: > [...] I have no desire to argue incessantly. I just want a solution to the problem! > A rerolled series that does: > > - Tweak wt-status.c to take information not from reflog, when >detached during rebase (this may need to tweak existing tests, >as different "rebase" modes may use 'checkout' liberally in >different ways); Please be more specific, and tell me what it should print when a rebase is in progress. Would a constant # rebase in progress; onto $ONTO be sufficient? > - Teach builtin/commit.c to pay attention to reflog-action; thanks >to the previous step, this will not have to change the tests; Where did builtin/commit.c enter into the equation? Doesn't it already respect GIT_REFLOG_ACTION? See line 1461. > - Update the reflog message rebase uses, but again this will not >affect wt-status.c at all. Okay. -- To unsubscribe from this list: send the line "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, #05; Sat, 15)
What's cooking in git.git (Jun 2013, #05; Sat, 15) -- 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 -- [Graduated to "master"] * bp/mediawiki-credential (2013-06-05) 1 commit (merged to 'next' on 2013-06-05 at ea07ec1) + git-remote-mediawiki: use Git.pm functions for credentials The bridge to MediaWiki has been updated to use the credential helper interface in Git.pm, losing its own and the original implementation the former was based on. * kb/full-history-compute-treesame-carefully-2 (2013-05-16) 15 commits (merged to 'next' on 2013-06-05 at 193242b) + revision.c: make default history consider bottom commits + revision.c: don't show all merges for --parents + revision.c: discount side branches when computing TREESAME + revision.c: add BOTTOM flag for commits + simplify-merges: drop merge from irrelevant side branch + simplify-merges: never remove all TREESAME parents + t6012: update test for tweaked full-history traversal + revision.c: Make --full-history consider more merges + Documentation: avoid "uninteresting" + rev-list-options.txt: correct TREESAME for P + t6111: add parents to tests + t6111: allow checking the parents as well + t6111: new TREESAME test set + t6019: test file dropped in -s ours merge + decorate.c: compact table when growing Major update to a very core part of the revision traversal logic to improve culling of irrelevant parents while traversing a mergy history. * mh/reflife (2013-06-02) 25 commits (merged to 'next' on 2013-06-05 at 291d863) + refs: document the lifetime of the args passed to each_ref_fn + register_ref(): make a copy of the bad reference SHA-1 + exclude_existing(): set existing_refs.strdup_strings + string_list_add_refs_by_glob(): add a comment about memory management + string_list_add_one_ref(): rename first parameter to "refname" + show_head_ref(): rename first parameter to "refname" + show_head_ref(): do not shadow name of argument + add_existing(): do not retain a reference to sha1 + do_fetch(): clean up existing_refs before exiting + do_fetch(): reduce scope of peer_item + object_array_entry: fix memory handling of the name field + find_first_merges(): remove unnecessary code + find_first_merges(): initialize merges variable using initializer + fsck: don't put a void*-shaped peg in a char*-shaped hole + object_array_remove_duplicates(): rewrite to reduce copying + revision: use object_array_filter() in implementation of gc_boundary() + object_array: add function object_array_filter() + revision: split some overly-long lines + cmd_diff(): make it obvious which cases are exclusive of each other + cmd_diff(): rename local variable "list" -> "entry" + cmd_diff(): use an object_array for holding trees + builtin_diff_tree(): make it obvious that function wants two entries + add_rev_cmdline(): make a copy of the name argument + fetch: make own copies of refnames + describe: make own copy of refname (this branch is used by mh/ref-races.) Define memory ownership and lifetime rules for what for-each-ref feeds to its callbacks (in short, "you do not own it, so make a copy if you want to keep it"). * mt/send-email-cc-match-fix (2013-06-05) 7 commits (merged to 'next' on 2013-06-06 at e4d0831) + test-send-email: test for pre-sanitized self name + t/send-email: test suppress-cc=self with non-ascii + t/send-email: add test with quoted sender + send-email: make --suppress-cc=self sanitize input + t/send-email: test suppress-cc=self on cccmd + send-email: fix suppress-cc=self on cccmd + t/send-email.sh: add test for suppress-cc=self Logic git-send-email used to suppress cc mishandled names like "A U. Thor" , where the human readable part needs to be quoted (the user input may not have the double quotes around the name, and comparison was done between quoted and unquoted strings). * rr/complete-difftool-fixup (2013-06-09) 2 commits (merged to 'next' on 2013-06-11 at fe91170) + completion: show can take both revlist and paths + completion: difftool takes both revs and files (this branch is tangled with rr/complete-difftool.) "git difftool" can take both revs to be compared and pathspecs. "git show" takes revs, revs:path and pathspecs. * rr/remove-contrib-some (2013-06-12) 2 commits (merged to 'next' on 2013-06-12 at 797644c) + contrib: drop blameview/ directory (merged to 'next' on 2013-06-05 at fc15705) + contrib: remove continuous/ and patches/ Remove stale contrib/ material. -- [New Topics] * rr/prompt-rebase-breakage-fix (2013-06-14) 1 commit - prompt: squelch er
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Two possibilities:
>>
>> (1) Assume that the other thread will produce a more reasonable
>> semantics when finished; perhaps the first line will go away
>> entirely, or maybe it would say something like "# Rebasing;
>> head at $commit".
>>
>> Your topic does not _care_ what it would say, so you tweak the
>> "status" test that is done during "rebase" so that they
>> ignore the first lines; or
>
> You said you didn't want to regress to show senseless information,...
Go back and read it again.
If you want to avoid regression, the codepath in wt-status.c
should compensate for the change to "rebase" so that it checks
$dotest/onto and show what is recorded in there.
> I agreed with that. What is wrong with the patch I showed in the
> previous email?
Which previous? My message you are responding to was a response to
your non-patch message, and tangling the In-reply-to backwards will
reach your original patch.
Puzzled
> Smudging is a bad hack, and must only be used as a
> last resort: when an another topics updates status to say something
> sensible, it will have to unsmudge the tests.
Yes. I just got an impression, from your incessant arguing, that you
are resisting the "ignore the top" as "extra work that is not
interesting to _me_", while I was trying to see what is the best way
to go forward for the _project_.
Honestly, I didn't want to waste my time and was trying to come up
with a compromise, which would be a small regression to the tests
that we will need to fix with the other topic. Because you already
said that you are not interested in that topic, I was anticipating
that the work to polish the topic would be a lot easier than
anything I would have to do with you in this topic, because others
are a lot easier to collaborate with than you are, and that is where
that suggestion comes from.
> diff --git a/wt-status.c b/wt-status.c
> index bf84a86..99c55e3 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s)
> if (!get_sha1("HEAD", sha1) &&
> !hashcmp(sha1, state.detached_sha1))
> on_what = _("HEAD detached at ");
> - else
> + else if (!state.rebase_in_progress)
> on_what = _("HEAD detached from ");
Is this supposed to be on top of your original patch?
The primary reason I suggested to special case "rebase-in-progress"
in the "how about this" patch was because that way, you can have the
"have builtin/commit.c honor reflog-action" much earlier in the
series, because what this part of the code would say will not be
affected by what is recorded in the reflog. If the above, together
with the original patch, makes the code match the expectation of the
"rebase stops in the middle and then status runs" tests, that's also
fine. The other topic needs to redo it in either case anyway.
> Unless we change the first line drastically to say: "rebase in
> progress: rebasing onto $ONTO" (or something), I don't think this
> makes sense. And if we were to do that, why not do it properly like
> "rebase ($N/$M): onto $ONTO, upstream $UPSTREAM, branch $BRANCH"?
> Other people on a different thread are already handling that,...
That is the thread I was referring to.
>
> So, you have three simple choices now:
>
> 1. Accept the simple patch I proposed above.
> 2. Propose an alternative patch quickly. *Patch*. No more English.
> 3. Reject all patches, and leave me no choice but to smudge.
>
> Which one is it going to be?
None of the above. After going back and forth this long, I won't
want to pick an incremental from the middle of discussion, so (1) is
out. This is not my itch and I am only helping you in a way that
the result will not hurt the project, so (2) is not it. But
assuming that "checkout that is done as an implementation detail in
rebase is _not_ checkout from end user's point of view" is where we
want to go, discarding this series is not something we want to see,
either.
A rerolled series that does:
- Tweak wt-status.c to take information not from reflog, when
detached during rebase (this may need to tweak existing tests,
as different "rebase" modes may use 'checkout' liberally in
different ways);
- Teach builtin/commit.c to pay attention to reflog-action; thanks
to the previous step, this will not have to change the tests;
- Update the reflog message rebase uses, but again this will not
affect wt-status.c at all.
would be one way to go.
--
To unsubscribe from this list: send the line "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 00/12] Fix some reference-related races
Thanks for all of the information.
On 06/15/2013 10:13 PM, Ramsay Jones wrote:
> Michael Haggerty wrote:
>> *This patch series must be built on top of mh/reflife.*
>>
>
> [...]
>
>> The other problem was that the for_each_ref() functions will die if
>> the ref cache that they are iterating over is freed out from under
>> them. This problem is solved by using reference counts to avoid
>> freeing the old packed ref cache (even if it is no longer valid) until
>> all users are done with it.
>
> Yes, I found exactly this happened to me on cygwin, earlier this week,
> with the previous version of this code. After seeing this mail, I had
> decided not to describe the failure on the old version, but wait and
> test this version instead.
>
> This version is a great improvement, but it still has some failures on
> cygwin. So, it may be worth (briefly) describing the old failure anyway!
> Note that several tests failed, but I will only mention t3211-peel-ref.sh
> tests #7-8.
>
> $ pwd
> /home/ramsay/git/t/trash directory.t3211-peel-ref
> $
>
> $ ../../bin-wrappers/git show-ref -d
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
> eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
> 5 [main] git 3540 _cygtls::handle_exceptions: Error while dumping
> state (p
> robably corrupted stack)
> Segmentation fault (core dumped)
> $
>
> The stack-trace for the faulting code looks something like:
>
> cmd_show_ref()
> for_each_ref(show_ref, NULL)
> do_for_each_ref(&ref_cache, "", show_ref, 0, 0, NULL)
> do_for_each_entry(&ref_cache, "", do_one_ref, &data)
> do_for_each_entry_in_dirs(packed_dir, loose_dir, do_one_ref, &data)
> *dfeeid() recursive calls*
> do_one_ref(entry, &data)
> show_ref("refs/outside/foo", sha1, NULL) [2nd match]
> peel_ref("refs/outside/foo", sha1)
> peel_entry(entry, 0)
> peel_object(name, sha1)
> deref_tag_noverify(o)
> parse_object(sha1 )
> lookup_replace_object(sha1)
> do_lookup_replace_object(sha1)
> prepare_replace_object()
>
> [un-indent here!]
> for_each_replace_ref(register_replace_ref, NULL)
> do_for_each_ref(&ref_cache, "refs/replace", fn, 13, 0, NULL)
> do_for_each_entry(&ref_cache, "refs/replace", fn, &data)
> get_packed_refs(&ref_cache)
> clear_packed_ref_cache(&ref_cache) *free_ref_entries etc*
> ** return to show_ref() [2nd match] above **
> ** return to recursive dfeeid() call in original iteration
> ** dir1->entries has been free()-ed and reused => segmentation fault
> [dir1->entries == 0x64633263 => dc2c => part of sha1 for refs/outside/foo]
>
> So, the nested "replace-reference-iteration" causes the ref_cache to be
> freed out from under the initial show-ref iteration, so this works:
>
> $ GIT_NO_REPLACE_OBJECTS=1 ../../bin-wrappers/git show-ref -d
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
> eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/base
> eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/tags/foo
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/foo^{}
> $
>
> You may be wondering why clear_packed_ref_cache() is called? Well, that
> is because stat_validity_check() *incorrectly* indicates that the
> packed-refs file has changed. Why does it do that? Well, this is one
> more example of the problems caused by the cygwin schizophrenic stat()
> functions. :( [ARGH]
>
> At this point, I tried running 'git show-ref' with core.checkstat set
> on the command line; but that didn't work! I had to fix show-ref and
> re-build git, and then, this works:
>
> $ ../../bin-wrappers/git -c core.checkstat=minimal -c core.trustctime=f
> alse show-ref -d
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
> eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/base
> eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/tags/foo
> d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/foo^{}
> $
So if I understand correctly, all of the above is *without* the
refcounting changes introduced in mh/ref-races? Is so, then it is not
surprising, as this is exactly the sort of problem that the reference
counting is meant to solve.
> Now, turning to the new code, t3211-peel-ref.sh test #7 now works, but
> test #8 still fails...
>
> $ ./t3211-peel-ref.sh -i -v
>
> ...
>
> ok 7 - refs are peeled outside of refs/tags (old packed)
>
> expecting success:
Re: [PATCH 1/3] rebase: guard against missing files in read_basic_state()
On Thu, Jun 13, 2013 at 3:29 PM, Junio C Hamano wrote: > Ramkumar Ramachandra writes: > > A more troublesome is that nobody seems to check the return value of > this function. If head-name, onto or orig-head is missing, is that > an error condition that should make the callers of read_basic_state > stop and refuse to proceed? Since we unconditionally write those three (and 'quiet'), it seems reasonable to require all of them to be there when continuing, so I think you're right that we should fail fast. > The way the && cascade is used seems to indicate that, but up to the > point where it sents $verbose. If and only if head-name, onto, orig-head > and quiet can be read in state-dir, verbose in state-dir is checked > and only then $verbose is set. > > Martin, this seems to be from your series around early Feburary > 2011. Do you recall why these checks are cascaded this way? > I do not offhand think of a good reason. Neither do I. I think the cascading after 'quiet' is just a mistake on my part. The consequences are probably close to none, since if one of earlier commands fail, the other files will probably not be there either. (Not defending it; I'm happy if it gets fixed, e.g. by making it fail fast.) -- To unsubscribe from this list: send the line "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 3/4] git-mw: Adding git-mw command
From: Benoit Person
Add the new git-mw command, with its 'help' subcommand as an example. Argument
parsing and subcommand choice is based on git-svn.perl.
Update Makefile to build, install and clean both scripts now (git-mw.perl and
git-remote-mediawiki.perl).
Signed-off-by: Benoit Person
Signed-off-by: Matthieu Moy
---
changes from V2:
- Perlcritic changes:
- Update for loops style to a more perlish one.
- All 'print's specify their output streams.
contrib/mw-to-git/Makefile| 7 ---
contrib/mw-to-git/git-mw.perl | 46 +++
2 files changed, 50 insertions(+), 3 deletions(-)
create mode 100644 contrib/mw-to-git/git-mw.perl
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index b0c7cf2..fe02c7e 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -6,6 +6,7 @@
GIT_MEDIAWIKI_PM=GitMediawiki.pm
SCRIPT_PERL=git-remote-mediawiki.perl
+SCRIPT_PERL+=git-mw.perl
GIT_ROOT_DIR=../..
HERE=contrib/mw-to-git/
@@ -22,15 +23,15 @@ install_pm:
cp $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)
build: copy_pm
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL="$(SCRIPT_PERL_FULL)" \
build-perl-script
install: install_pm
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL="$(SCRIPT_PERL_FULL)" \
install-perl-script
clean:
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL="$(SCRIPT_PERL_FULL)" \
clean-perl-script
rm $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM) \
$(GIT_ROOT_DIR)/perl/blib/lib/$(GIT_MEDIAWIKI_PM)
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 000..320c00e
--- /dev/null
+++ b/contrib/mw-to-git/git-mw.perl
@@ -0,0 +1,46 @@
+#!/usr/bin/perl
+
+# Copyright (C) 2013
+# Benoit Person
+# Celestin Matte
+# License: GPL v2 or later
+
+# Set of tools for git repo with a mediawiki remote.
+# Documentation & bugtracker: https://github.com/moy/Git-Mediawiki/
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+
+my %commands = (
+ 'help' =>
+ [\&help, {}, \&help]
+);
+
+# Search for sub-command
+my $cmd = $commands{'help'};
+for (0..@ARGV) {
+ if (defined $commands{$ARGV[$_]}) {
+ $cmd = $commands{$ARGV[$_]};
+ splice @ARGV, $_, 1;
+ last;
+ }
+};
+GetOptions( %{$cmd->[1]},
+ 'help|h' => \&{$cmd->[2]});
+
+# Launch command
+&{$cmd->[0]};
+
+## Help Functions
##
+
+sub help {
+ print {*STDOUT} <<'END';
+usage: git mw
+
+git mw commands are:
+helpDisplay help information about git mw
+END
+ exit;
+}
\ No newline at end of file
--
1.8.3.GIT
--
To unsubscribe from this list: send the line "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 2/4] git-mw: Move some functions from git-remote-mediawiki.perl to GitMediawiki.pm
From: Benoit Person
Move and rename subs 'mediawiki_clean_filename' into 'clean_filename',
'mediawiki_smudge_filename' into 'smudge_filename' and
'mw_connect_maybe' into 'connect_maybe' since we have a cleaner namespace in
a perl module.
Move constants 'EMPTY', 'SLASH_REPLACEMENT' and 'HTTP_CODE_OK'.
Remove side effects in those functions to provide a cleaner API.
Update git-remote-mediawiki for those changes.
Signed-off-by: Benoit Person
Signed-off-by: Matthieu Moy
---
changes from the V2:
- Move more constants to GitMediawiki.pm.
- Remove the encapsulation of Git::config calls into a git_cmd_try one.
contrib/mw-to-git/GitMediawiki.pm | 77 +-
contrib/mw-to-git/git-remote-mediawiki.perl | 85 +
2 files changed, 89 insertions(+), 73 deletions(-)
diff --git a/contrib/mw-to-git/GitMediawiki.pm
b/contrib/mw-to-git/GitMediawiki.pm
index 8a0ffc7..beae6d0 100644
--- a/contrib/mw-to-git/GitMediawiki.pm
+++ b/contrib/mw-to-git/GitMediawiki.pm
@@ -18,7 +18,82 @@ require Exporter;
@EXPORT = ();
# Methods which can be called as standalone functions as well:
-@EXPORT_OK = ();
+@EXPORT_OK = qw(clean_filename smudge_filename connect_maybe
+ EMPTY HTTP_CODE_OK);
+}
+
+# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
+use constant SLASH_REPLACEMENT => '%2F';
+
+# Used to test for empty strings
+use constant EMPTY => q{};
+
+# HTTP codes
+use constant HTTP_CODE_OK => 200;
+
+sub clean_filename {
+ my $filename = shift;
+ $filename =~ s{@{[SLASH_REPLACEMENT]}}{/}g;
+ # [, ], |, {, 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
+ # an actual special character.
+ $filename =~ s/[\[\]\{\}\|]/sprintf("_%%_%x", ord($&))/ge;
+ # If we use the uri escape before
+ # we should unescape here, before anything
+
+ return $filename;
+}
+
+sub smudge_filename {
+ my $filename = shift;
+ $filename =~ s{/}{@{[SLASH_REPLACEMENT]}}g;
+ $filename =~ s/ /_/g;
+ # Decode forbidden characters encoded in clean_filename
+ $filename =~ s/_%_([0-9a-fA-F][0-9a-fA-F])/sprintf('%c', hex($1))/ge;
+ return $filename;
+}
+
+sub connect_maybe {
+ my $wiki = shift;
+ if ($wiki) {
+ return $wiki;
+ }
+
+ my $remote_name = shift;
+ my $remote_url = shift;
+ my ($wiki_login, $wiki_password, $wiki_domain);
+
+ $wiki_login = Git::config("remote.${remote_name}.mwLogin");
+ $wiki_password = Git::config("remote.${remote_name}.mwPassword");
+ $wiki_domain = Git::config("remote.${remote_name}.mwDomain");
+
+ $wiki = MediaWiki::API->new;
+ $wiki->{config}->{api_url} = "${remote_url}/api.php";
+ if ($wiki_login) {
+ my %credential = (
+ 'url' => $remote_url,
+ 'username' => $wiki_login,
+ 'password' => $wiki_password
+ );
+ Git::credential(\%credential);
+ my $request = {lgname => $credential{username},
+ lgpassword => $credential{password},
+ lgdomain => $wiki_domain};
+ if ($wiki->login($request)) {
+ Git::credential(\%credential, 'approve');
+ print {*STDERR} qq(Logged in mediawiki user
"$credential{username}".\n);
+ } else {
+ print {*STDERR} qq(Failed to log in mediawiki user
"$credential{username}" on ${remote_url}\n);
+ print {*STDERR} ' (error ' .
+ $wiki->{error}->{code} . ': ' .
+ $wiki->{error}->{details} . ")\n";
+ Git::credential(\%credential, 'reject');
+ exit 1;
+ }
+ }
+
+ return $wiki;
}
1; # Famous last words
\ No newline at end of file
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 9ff45fd..3b6422b 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -14,6 +14,8 @@
use strict;
use MediaWiki::API;
use Git;
+use GitMediawiki qw(clean_filename smudge_filename connect_maybe
+ EMPTY HTTP_CODE_OK);
use DateTime::Format::ISO8601;
use warnings;
@@ -23,9 +25,6 @@ binmode STDOUT, ':encoding(UTF-8)';
use URI::Escape;
-# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
-use constant SLASH_REPLACEMENT => '%2F';
-
# It's not always possible to delete pages (may require some
# privileges). Deleted pages are replaced with this
[PATCH V3 4/4] git-mw: Add preview subcommand into git mw.
From: Benoit Person
Add the subcommand to 'git-mw.perl'.
Add a new constant in GitMediawiki.pm 'HTTP_CODE_PAGE_NOT_FOUND'.
Signed-off-by: Benoit Person
Signed-off-by: Matthieu Moy
---
changes from V2:
- Remove the --blob option, distinction between files and blobs is now
automatic.
- Add a --verbose option to output more information on what's going on.
- Rewrote the doc and the commit message.
- Rewrote of the template retrieving code (see 'get_template' sub).
- Use a configuration variable to define the content ID search in the
template. Default value set as 'bodyContent' since it seems more standard
than 'mw-content-text'.
- Final content is now saved as utf-8 to solve encoding issues.
- Perlcritic changes:
- All 'print's specify their output streams.
--> Same useless warnings left in git-remote-mediawiki.perl after
célestin's
work and git-mw.perl after this patch :) .
contrib/mw-to-git/GitMediawiki.pm | 3 +-
contrib/mw-to-git/git-mw.perl | 303 +-
2 files changed, 304 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/GitMediawiki.pm
b/contrib/mw-to-git/GitMediawiki.pm
index beae6d0..d1f2c41 100644
--- a/contrib/mw-to-git/GitMediawiki.pm
+++ b/contrib/mw-to-git/GitMediawiki.pm
@@ -19,7 +19,7 @@ require Exporter;
# Methods which can be called as standalone functions as well:
@EXPORT_OK = qw(clean_filename smudge_filename connect_maybe
- EMPTY HTTP_CODE_OK);
+ EMPTY HTTP_CODE_OK HTTP_CODE_PAGE_NOT_FOUND);
}
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
@@ -30,6 +30,7 @@ use constant EMPTY => q{};
# HTTP codes
use constant HTTP_CODE_OK => 200;
+use constant HTTP_CODE_PAGE_NOT_FOUND => 404;
sub clean_filename {
my $filename = shift;
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
index 320c00e..0b83108 100644
--- a/contrib/mw-to-git/git-mw.perl
+++ b/contrib/mw-to-git/git-mw.perl
@@ -12,10 +12,41 @@ use strict;
use warnings;
use Getopt::Long;
+use URI::URL qw(url);
+use LWP::UserAgent;
+use HTML::TreeBuilder;
+
+use Git;
+use MediaWiki::API;
+use GitMediawiki qw(smudge_filename connect_maybe
+ EMPTY HTTP_CODE_PAGE_NOT_FOUND);
+
+# By default, use UTF-8 to communicate with Git and the user
+binmode STDERR, ':encoding(UTF-8)';
+binmode STDOUT, ':encoding(UTF-8)';
+
+#preview parameters
+my $file_name = EMPTY;
+my $remote_name = EMPTY;
+my $preview_file_name = EMPTY;
+my $autoload = 0;
+my $verbose = 0;
+sub file {
+ $file_name = shift;
+ return $file_name;
+}
my %commands = (
'help' =>
- [\&help, {}, \&help]
+ [\&help, {}, \&help],
+ 'preview' =>
+ [\&preview, {
+ '<>' => \&file,
+ 'output|o=s' => \$preview_file_name,
+ 'remote|r=s' => \$remote_name,
+ 'autoload|a' => \$autoload,
+ 'verbose|v' => \$verbose
+ }, \&preview_help]
);
# Search for sub-command
@@ -33,6 +64,275 @@ GetOptions( %{$cmd->[1]},
# Launch command
&{$cmd->[0]};
+# Preview Functions
+
+# @TODO : add documentation for verbose option
+sub preview_help {
+ print {*STDOUT} <<'END';
+USAGE: git mw preview [--remote|-r ] [--autoload|-a]
+ [--output|-o ] [--verbose|-v]
+ |
+
+DESCRIPTION:
+Preview is an utiliy to preview local content of a mediawiki repo as if it was
+pushed on the remote.
+
+For that, preview searches for the remote name of the current branch's upstream
+if --remote is not set. If that remote is not found or if it is not a
mediawiki,
+it lists all mediawiki remotes configured and asks you to replay your command
+with the --remote option set properly.
+
+Then, it searches for a file named 'filename'. If it's not found in the current
+dir, it will assume it's a blob.
+
+The content retrieved in the file (or in the blob) will then be parsed by the
+distant mediawiki and combined with a template retrieved from the mediawiki.
+
+Finally, preview will save the HTML result in a file. and autoload it in your
+default web browser if the option --autoload is present.
+
+OPTIONS:
+ -r , --remote
+ If the remote is a mediawiki, the template and the parse engine
used for
+ the preview will be those of that remote.
+ If not, a list of valid remotes will be shown.
+
+ -a, --autoload
+ Try to load the HTML output in a new tab (or new window) of
your default
+ web browser.
+
+ -o , --output
+ Change the HTML output filename. Default filename is based on
the input
+ filename with its extension r
[PATCH V3 1/4] git-mw: Introduction of GitMediawiki.pm
From: Benoit Person
GitMediawiki.pm enable code factoring between several scripts in mw-to-git.
To make it usable in scripts (ie: accessible in @INC) it adds two targets
(copy_pm & install_pm) into the Makefile, one for tests and one for
installation.
Signed-off-by: Benoit Person
Signed-off-by: Matthieu Moy
---
changes from the V2:
- Add a way to test, without installation, code that uses GitMediawiki.pm.
contrib/mw-to-git/GitMediawiki.pm | 24
contrib/mw-to-git/Makefile| 26 +++---
2 files changed, 47 insertions(+), 3 deletions(-)
create mode 100644 contrib/mw-to-git/GitMediawiki.pm
diff --git a/contrib/mw-to-git/GitMediawiki.pm
b/contrib/mw-to-git/GitMediawiki.pm
new file mode 100644
index 000..8a0ffc7
--- /dev/null
+++ b/contrib/mw-to-git/GitMediawiki.pm
@@ -0,0 +1,24 @@
+package GitMediawiki;
+
+use 5.008;
+use strict;
+use Git;
+
+BEGIN {
+
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK);
+
+# Totally unstable API.
+$VERSION = '0.01';
+
+require Exporter;
+
+@ISA = qw(Exporter);
+
+@EXPORT = ();
+
+# Methods which can be called as standalone functions as well:
+@EXPORT_OK = ();
+}
+
+1; # Famous last words
\ No newline at end of file
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index 1fb2424..b0c7cf2 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -4,16 +4,36 @@
#
## Build git-remote-mediawiki
+GIT_MEDIAWIKI_PM=GitMediawiki.pm
SCRIPT_PERL=git-remote-mediawiki.perl
GIT_ROOT_DIR=../..
HERE=contrib/mw-to-git/
SCRIPT_PERL_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL))
+INSTLIBDIR=$(shell $(MAKE) -C $(GIT_ROOT_DIR)/perl \
+-s --no-print-directory instlibdir)
all: build
-build install clean:
+copy_pm:
+ cp $(GIT_MEDIAWIKI_PM) $(GIT_ROOT_DIR)/perl/blib/lib/
+
+install_pm:
+ cp $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)
+
+build: copy_pm
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+build-perl-script
+
+install: install_pm
$(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
-$@-perl-script
+install-perl-script
+
+clean:
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+clean-perl-script
+ rm $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM) \
+ $(GIT_ROOT_DIR)/perl/blib/lib/$(GIT_MEDIAWIKI_PM)
+
perlcritic:
- perlcritic -2 *.perl
+ perlcritic -2 *.perl
\ No newline at end of file
--
1.8.3.GIT
--
To unsubscribe from this list: send the line "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/4] git-remote-mediawiki: new tool to preview local changes without pushing
From: Benoit Person The #7 issue on git-mediawiki's issue tracker [1] states that the ability to preview content without pushing would be a nice thing to have. changes from V2: - Add a way to test, without installation, code that uses GitMediawiki.pm. - Move more constants to GitMediawiki.pm - Remove the encapsulation of Git::config calls into a git_cmd_try one. - Remove the --blob option, distinction between files and blobs is now automatic. - Add a --verbose option to output more information on what's going on. - Rewrote the doc and the commit message. - Rewrote of the template retrieving code (see 'get_template' sub). - Use a configuration variable to define the content ID search in the template. Default value set as 'bodyContent' since it seems more standard than 'mw-content-text'. - Final content is now saved as utf-8 to solve encoding issues. - Perlcritic changes: - Update for loops style to a more perlish one. - All 'print's specify their output streams. --> Same useless warnings left in git-remote-mediawiki.perl after célestin's work and git-mw.perl after this patch :) . changes from V1: - add new package GitMediawiki - move some of git-remote-mediawiki functions into the package - update git-remote-mediawiki to use those "moved" functions - add a hacky-way to install it in the Makefile - use it in the new git mw tool - add a way to give to the preview tool blobs as argument - add a fallback when the upstream's branch remote is not a mediawiki remote - update the `autoload` option to use `git web--browse` and not `xdg-open` - update the way we find the upstream's branch remote name This serie is based on the 'master' branch merged with célestin's patch series. [1] https://github.com/moy/Git-Mediawiki/issues/7 Benoit Person (4): git-mw: Introduction of GitMediawiki.pm git-mw: Move some functions from git-remote-mediawiki.perl to GitMediawiki.pm git-mw: Adding git-mw command git-mw: Add preview subcommand into git mw. contrib/mw-to-git/GitMediawiki.pm | 100 contrib/mw-to-git/Makefile | 29 ++- contrib/mw-to-git/git-mw.perl | 347 contrib/mw-to-git/git-remote-mediawiki.perl | 85 ++- 4 files changed, 485 insertions(+), 76 deletions(-) create mode 100644 contrib/mw-to-git/GitMediawiki.pm create mode 100644 contrib/mw-to-git/git-mw.perl -- 1.8.3.GIT -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Slightly prettier reflog message from checkout
Ramkumar Ramachandra writes: > [1/2] is important. [2/2] is a minor prettification, that wouldn't > have been possible without [1/2]. > > Thanks. > > Ramkumar Ramachandra (2): > sha1_name: stop hard-coding 40-character hex checks > checkout: do not write full sha1 to reflog > > builtin/checkout.c | 2 +- > sha1_name.c| 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) I view the two codepaths touched by these patches the other way around. An abbreviated unique SHA-1 you have today may not be unique tomorrow. There is no reason to deliberately lose information (e.g. by using "Then, instead of the absolute minimum, let's record a bit more bytes" heuristics) when we record. The reflog recording code in checkout writes full 40-characters on purpose and there is no reason not to do so (i.e. the codepath that is the topic of 2/2). That is a more important design decision between the two codepaths. Once we accept that design principle of not losing information when we do not have to, it naturally follows that the writing side should write full 40-hex, and also the reading side (i.e. the codepath that is the topic of 1/2) should make sure that it reads 40-hex and nothing else. This also reduces the risk of a funny branch name that consists only of [0-9a-f] getting mistaken as an object name, but that is not the primary point. So I am fairly strongly negative on both changes. -- To unsubscribe from this list: send the line "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 0/5] Write a good 'stash store' for autostash
Ramkumar Ramachandra writes: > Ramkumar Ramachandra (5): > stash doc: add a warning about using create > stash doc: document short form -p in synopsis > stash: simplify option parser for create > stash: introduce 'git stash store' > rebase: use 'git stash store' to simplify logic Looked sensible overall. I briefly debated myself if "git stash store" even needs its own error message that needs to be squelched with -q (as there is no reason for the end user to invoke it), but I think it does not matter that much, and we can remove that part fairly easily before it hits 'next'. Will queue (but I am not on my main machine today, so not very soon). 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] rebase -i: fixup fixup! fixup!
Junio C Hamano writes: > Andrew Pimlott writes: > >> Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013: >>> It happened to work and I added a test. But then it occurred to me that >>> it might have been better to fix commit --fixup/--squash to strip the >>> fixup! or squash! from the referenced commit in the first place. >>> Anyhow, below is my patch for --autosquash, but unles someone has an >>> objection to doing it in commit, I'll work on that. > ... > If you strip out the prefix when you make commits, you may lose the > information if you want to use in order to express these different > orders. One design principle I would use as a yardstick is to see any code that deliberately lose information to achieve something as highly suspicious. You can discard extra information when you read and use, if you do not need it, but if you do not record it in the first place, you cannot later enhance the reader to take advantage of it. In general, whenever you see yourself _discarding_ information to solve an issue, you should carefully ask yourself if that is the right solution. I wish we can make sure contributors can learn various design principles we have benefited from over the course of this project much better. But it is a bit difficult to _teach_ others. Writing them down is difficult, not because the rules are vague, but because they are like air. I am sure regular contributors with good design taste share this sentiment. You will know a violation of them when you see one, you naturally stick to them yourself without even having to think about them, but enumerating them without seeing concrete issues takes effort. And this "lets squash multiple --fixup/--squash" happened to realize that "we try not to deliberately lose information" is one of them. 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] unpack-trees: don't shift conflicts left and right
René Scharfe writes:
> If o->merge is set, the struct traverse_info member conflicts is shifted
> left in unpack_callback, then passed through traverse_trees_recursive
> to unpack_nondirectories, where it is shifted right before use.
> @@ -807,13 +802,6 @@ static int unpack_callback(int n, unsigned long mask,
> unsigned long dirmask, str
>
> /* Now handle any directories.. */
> if (dirmask) {
> - unsigned long conflicts = mask & ~dirmask;
> - if (o->merge) {
> - conflicts <<= 1;
> - if (src[0])
> - conflicts |= 1;
> - }
> -
> /* special case: "diff-index --cached" looking at a tree */
> if (o->diff_index_cached &&
> n == 1 && dirmask == 1 && S_ISDIR(names->mode)) {
> @@ -832,7 +820,7 @@ static int unpack_callback(int n, unsigned long mask,
> unsigned long dirmask, str
> }
> }
>
> - if (traverse_trees_recursive(n, dirmask, conflicts,
> + if (traverse_trees_recursive(n, dirmask, mask & ~dirmask,
>names, info) < 0)
> return -1;
> return mask;
This loses the bottom bit (i.e. are we merging and do have an index
entry?) passed to traverse_trees_recursive(), but when that bitmask
comes back to our callback, we immediately discard the bottom bit by
shifting before using it in unpack_nondirectories(), so this seems a
valid clean-up.
One thing renaming df_conficts to conflicts really proves is that
this field is not used by the traverse_trees machinery at all.
Before this patch, the bits in conflicts (now df_conflicts) mask had
the semantics that is not consistent with the dirmask/mask the
tree-walk machinery uses to communicate with its callers and
callbacks. Everything in tree-walk.[ch] is about "walk N trees",
and bit 0 of dirmask and mask always means the first tree, not
"first tree, or in index if the callback is doing a merge", which
is used in the conflicts field before this patch.
I think the true source of the confusion is that the "conflicts"
field does not logically belong there. It is not needed in the
general "walk N trees" machinery.
The information is only useful for the unpack_trees callback, and
"info->data" is a more appropriate place to hang such a callback
specific data.
Perhaps we should use info->data field to point at
struct {
struct unpack_trees_options *o;
unsigned long df_conflict;
};
and get rid of info->conflicts field?
--
To unsubscribe from this list: send the line "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] unpack-trees: don't shift conflicts left and right
If o->merge is set, the struct traverse_info member conflicts is shifted
left in unpack_callback, then passed through traverse_trees_recursive
to unpack_nondirectories, where it is shifted right before use. Stop
the shifting and just pass the conflict bit mask as is. Rename the
member to df_conflicts to prove that it isn't used anywhere else.
Signed-off-by: René Scharfe
---
tree-walk.h| 2 +-
unpack-trees.c | 18 +++---
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/tree-walk.h b/tree-walk.h
index 2bf0db9..ae04b64 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -46,7 +46,7 @@ struct traverse_info {
int pathlen;
struct pathspec *pathspec;
- unsigned long conflicts;
+ unsigned long df_conflicts;
traverse_callback_t fn;
void *data;
int show_all_errors;
diff --git a/unpack-trees.c b/unpack-trees.c
index 57b4074..b27f2a6 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -464,7 +464,7 @@ static int traverse_trees_recursive(int n, unsigned long
dirmask,
newinfo.pathspec = info->pathspec;
newinfo.name = *p;
newinfo.pathlen += tree_entry_len(p) + 1;
- newinfo.conflicts |= df_conflicts;
+ newinfo.df_conflicts |= df_conflicts;
for (i = 0; i < n; i++, dirmask >>= 1) {
const unsigned char *sha1 = NULL;
@@ -565,17 +565,12 @@ static int unpack_nondirectories(int n, unsigned long
mask,
{
int i;
struct unpack_trees_options *o = info->data;
- unsigned long conflicts;
+ unsigned long conflicts = info->df_conflicts | dirmask;
/* Do we have *only* directories? Nothing to do */
if (mask == dirmask && !src[0])
return 0;
- conflicts = info->conflicts;
- if (o->merge)
- conflicts >>= 1;
- conflicts |= dirmask;
-
/*
* Ok, we've filled in up to any potential index entry in src[0],
* now do the rest.
@@ -807,13 +802,6 @@ static int unpack_callback(int n, unsigned long mask,
unsigned long dirmask, str
/* Now handle any directories.. */
if (dirmask) {
- unsigned long conflicts = mask & ~dirmask;
- if (o->merge) {
- conflicts <<= 1;
- if (src[0])
- conflicts |= 1;
- }
-
/* special case: "diff-index --cached" looking at a tree */
if (o->diff_index_cached &&
n == 1 && dirmask == 1 && S_ISDIR(names->mode)) {
@@ -832,7 +820,7 @@ static int unpack_callback(int n, unsigned long mask,
unsigned long dirmask, str
}
}
- if (traverse_trees_recursive(n, dirmask, conflicts,
+ if (traverse_trees_recursive(n, dirmask, mask & ~dirmask,
names, info) < 0)
return -1;
return mask;
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] git-gui: bring Wish process to front on Mac
On 14 June 2013 18:54, Junio C Hamano wrote: > Stefan Haller writes: > >> 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 >> --- > > Pat, is there any progress on this? I do not mind, and I actually > would prefer, a pull request early in the development cycle. > yep - I applied this and a couple of others and sent up a pull request now. I see there are some commits in git's tree that I don't have on this side so I'll merge those in here shortly. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
REQUEST PULL: git-gui
The following changes since commit f6dd784ed4c1705d465b1238f9a5971f2733e582: git-gui 0.17 (2012-10-17 21:57:29 +0100) are available in the git repository at: git://repo.or.cz/git-gui.git tags/gitgui-0.18.0 for you to fetch changes up to 8a383db4b28059becc3ebfd1b402299e34c3151f: git-gui 0.18 (2013-06-15 23:53:34 +0100) git-gui 0.18.0 Christian Couder (1): Makefile: replace "echo 1>..." with "echo >..." Grahack (1): French translation:Â copy -> copie. Heiko Voigt (1): git-gui: allow "\ No newline at end of file" for linewise staging John Keeping (1): git-gui: fix file name handling with non-empty prefix Kirill Smelkov (1): git-gui: Fix parsing of Pat Thoyts (4): git-gui: fix the mergetool launcher for the Beyond Compare tool. git-gui: change dialog button positions for Windows to suit platform. git-gui: avoid an error message when removing the last remote git-gui 0.18 Stefan Haller (1): git-gui: bring wish process to front on Mac GIT-VERSION-GEN | 2 +- Makefile | 6 +++--- git-gui.sh| 27 +-- lib/choose_repository.tcl | 4 +++- lib/diff.tcl | 11 +-- lib/mergetool.tcl | 4 ++-- lib/remote.tcl| 6 -- po/fr.po | 2 +- 8 files changed, 40 insertions(+), 22 deletions(-) -- To unsubscribe from this list: send the line "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-VERSION-GEN: support non-standard $GIT_DIR path
make and make test both work when $GIT_DIR isn't .git, but make dist included a bogus GIT-VERSION-FILE. Signed-off-by: Dennis Kaarsemaker --- I'm doing daily builds of git, using many workers and a shared git.git, with per-worker checkouts, it would be really useful if GIT-VERSION-GEN actually supports this and doesn't generate a fairly bogus GIT-VERSION-FILE. GIT-VERSION-GEN | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN index 390782f..7dcca28 100755 --- a/GIT-VERSION-GEN +++ b/GIT-VERSION-GEN @@ -11,7 +11,7 @@ LF=' if test -f version then VN=$(cat version) || VN="$DEF_VER" -elif test -d .git -o -f .git && +elif test -d .git -o -f .git -o test -d $GIT_DIR && VN=$(git describe --match "v[0-9]*" --abbrev=7 HEAD 2>/dev/null) && case "$VN" in *$LF*) (exit 1) ;; -- 1.8.2.4.g940421e -- To unsubscribe from this list: send the line "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] tests: allow sha1's as part of the path
When running 'make test' from a path such as
.../daily-build/master@bdff0e3a374617dce784f801b97500d9ba2e4705, the
logic in fuzz.sed as generated by t5105-request-pull.sh was backwards,
replacing object names before replacing urls, making the test fail.
Signed-off-by: Dennis Kaarsemaker
---
t/t5150-request-pull.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 432f98c..1afa0d5 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -80,12 +80,12 @@ test_expect_success 'setup: two scripts for reading pull
requests' '
cat <<-EOT >fuzz.sed
#!/bin/sed -nf
+ s/$downstream_url_for_sed/URL/g
s/$_x40/OBJECT_NAME/g
s/A U Thor/AUTHOR/g
s/[-0-9]\{10\} [:0-9]\{8\} [-+][0-9]\{4\}/DATE/g
s/[^ ].*/SUBJECT/g
s/ [^ ].* (DATE)/ SUBJECT (DATE)/g
- s/$downstream_url_for_sed/URL/g
s/for-upstream/BRANCH/g
s/mnemonic.txt/FILENAME/g
s/^version [0-9]/VERSION/
--
1.8.2.4.g940421e
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add missing calls to git_config()
Hi Junio,
I recently had need to use the '-c' option to git in order to
set some config variables from the command line; specifically
with 'git show-ref' and 'git pack-refs'. I haven't looked to
see if any other commands need similar attention, but:
$ git grep 'cmd_.*(int argc' -- builtin | wc -l
109
$ git grep 'git_config(' -- builtin | wc -l
80
$
... maybe. ;-)
[I did think about separating the command line processing from
the config file processing; maybe some commands could accept
config settings from the command line, but do not need/want
the regular config file processing? *dunno*.]
ATB,
Ramsay Jones
Ramsay Jones (2):
show-ref.c: Add missing call to git_config()
pack-refs.c: Add missing call to git_config()
builtin/pack-refs.c | 3 +++
builtin/show-ref.c | 2 ++
2 files changed, 5 insertions(+)
--
1.8.3
--
To unsubscribe from this list: send the line "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 00/12] Fix some reference-related races
Michael Haggerty wrote:
> *This patch series must be built on top of mh/reflife.*
>
[...]
> The other problem was that the for_each_ref() functions will die if
> the ref cache that they are iterating over is freed out from under
> them. This problem is solved by using reference counts to avoid
> freeing the old packed ref cache (even if it is no longer valid) until
> all users are done with it.
Yes, I found exactly this happened to me on cygwin, earlier this week,
with the previous version of this code. After seeing this mail, I had
decided not to describe the failure on the old version, but wait and
test this version instead.
This version is a great improvement, but it still has some failures on
cygwin. So, it may be worth (briefly) describing the old failure anyway!
Note that several tests failed, but I will only mention t3211-peel-ref.sh
tests #7-8.
$ pwd
/home/ramsay/git/t/trash directory.t3211-peel-ref
$
$ ../../bin-wrappers/git show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
5 [main] git 3540 _cygtls::handle_exceptions: Error while dumping state
(p
robably corrupted stack)
Segmentation fault (core dumped)
$
The stack-trace for the faulting code looks something like:
cmd_show_ref()
for_each_ref(show_ref, NULL)
do_for_each_ref(&ref_cache, "", show_ref, 0, 0, NULL)
do_for_each_entry(&ref_cache, "", do_one_ref, &data)
do_for_each_entry_in_dirs(packed_dir, loose_dir, do_one_ref, &data)
*dfeeid() recursive calls*
do_one_ref(entry, &data)
show_ref("refs/outside/foo", sha1, NULL) [2nd match]
peel_ref("refs/outside/foo", sha1)
peel_entry(entry, 0)
peel_object(name, sha1)
deref_tag_noverify(o)
parse_object(sha1 )
lookup_replace_object(sha1)
do_lookup_replace_object(sha1)
prepare_replace_object()
[un-indent here!]
for_each_replace_ref(register_replace_ref, NULL)
do_for_each_ref(&ref_cache, "refs/replace", fn, 13, 0, NULL)
do_for_each_entry(&ref_cache, "refs/replace", fn, &data)
get_packed_refs(&ref_cache)
clear_packed_ref_cache(&ref_cache) *free_ref_entries etc*
** return to show_ref() [2nd match] above **
** return to recursive dfeeid() call in original iteration
** dir1->entries has been free()-ed and reused => segmentation fault
[dir1->entries == 0x64633263 => dc2c => part of sha1 for refs/outside/foo]
So, the nested "replace-reference-iteration" causes the ref_cache to be
freed out from under the initial show-ref iteration, so this works:
$ GIT_NO_REPLACE_OBJECTS=1 ../../bin-wrappers/git show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/base
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/tags/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/foo^{}
$
You may be wondering why clear_packed_ref_cache() is called? Well, that
is because stat_validity_check() *incorrectly* indicates that the
packed-refs file has changed. Why does it do that? Well, this is one
more example of the problems caused by the cygwin schizophrenic stat()
functions. :( [ARGH]
At this point, I tried running 'git show-ref' with core.checkstat set
on the command line; but that didn't work! I had to fix show-ref and
re-build git, and then, this works:
$ ../../bin-wrappers/git -c core.checkstat=minimal -c core.trustctime=f
alse show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/base
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/tags/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/foo^{}
$
Now, turning to the new code, t3211-peel-ref.sh test #7 now works, but
test #8 still fails...
$ ./t3211-peel-ref.sh -i -v
...
ok 7 - refs are peeled outside of refs/tags (old packed)
expecting success:
git pack-refs --all &&
cp .git/packed-refs fully-peeled &&
git branch yadda &&
git pack-refs --all &&
git branch -d yadda &&
test_cmp fully-peeled .git/packed-refs
fatal: internal error: packed-ref cache cleared while locked
not ok 8 - peeled refs survive deletion of packed ref
#
# git pack-refs --all &&
# cp .git/packed-refs fully-peeled &&
# git branch yadda &&
# git pack-refs --all &
[PATCH 1/2] show-ref.c: Add missing call to git_config()
At present, 'git show-ref' ignores any attempt to set config variables (e.g. core.checkstat) from the command line using the -c option to git. In order to enable such usage, add the missing call to git_config() from cmd_show_ref(). Signed-off-by: Ramsay Jones --- builtin/show-ref.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/show-ref.c b/builtin/show-ref.c index 8d9b76a..95f5ca9 100644 --- a/builtin/show-ref.c +++ b/builtin/show-ref.c @@ -191,6 +191,8 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix) if (argc == 2 && !strcmp(argv[1], "-h")) usage_with_options(show_ref_usage, show_ref_options); + git_config(git_default_config, NULL); + argc = parse_options(argc, argv, prefix, show_ref_options, show_ref_usage, PARSE_OPT_NO_INTERNAL_HELP); -- 1.8.3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] pack-refs.c: Add missing call to git_config()
At present, 'git pack-refs' ignores any attempt to set config
variables (e.g. core.checkstat) from the command line using
the -c option to git. In order to enable such usage, add the
missing call to git_config() from cmd_pack_refs().
Signed-off-by: Ramsay Jones
---
builtin/pack-refs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/pack-refs.c b/builtin/pack-refs.c
index b20b1ec..ade1ae5 100644
--- a/builtin/pack-refs.c
+++ b/builtin/pack-refs.c
@@ -15,6 +15,9 @@ int cmd_pack_refs(int argc, const char **argv, const char
*prefix)
OPT_BIT(0, "prune", &flags, N_("prune loose refs (default)"),
PACK_REFS_PRUNE),
OPT_END(),
};
+
+ git_config(git_default_config, NULL);
+
if (parse_options(argc, argv, prefix, opts, pack_refs_usage, 0))
usage_with_options(pack_refs_usage, opts);
return pack_refs(flags);
--
1.8.3
--
To unsubscribe from this list: send the line "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: SSL socks proxy list: CONNECTABLE 100%
24.21.139.76:9855 173.57.153.187:62189 96.43.245.75:26101 24.107.48.229:8169 75.136.147.231:4351 SSL socks proxy list: CONNECTABLE 100% More socks at: http://actualproxy.biz/ -- View this message in context: http://git.661346.n2.nabble.com/Using-socks-proxy-with-git-for-http-s-transport-tp7579041p7589492.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log: Add a switch to limit the number of displayed lines from the commit messages
Hi Paul, Paul Menzel wrote: > there are people out there disliking elaborate commit messages, as going > over `git log` is tedious as you have to scroll a lot. As I do not like > the suggestion to make commit messages shorter by omitting certain > details, a way to limit the number displayed lines of the commit > messages would be nice to have. Have you tried gitk or tig? They split the screen so you can browse through commits, one per line, in one half and read the corresponding commit messages and patches in the other. Hope that helps, 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
git log: Add a switch to limit the number of displayed lines from the commit messages
Dear git folks, there are people out there disliking elaborate commit messages, as going over `git log` is tedious as you have to scroll a lot. As I do not like the suggestion to make commit messages shorter by omitting certain details, a way to limit the number displayed lines of the commit messages would be nice to have. The switch `--format=oneline` exists already. Unfortunately a lot of commits do not have a informative enough summary, so the first lines of the commit message are still needed/desired to understand the commit more. Could a switch be added, like `--commit-message-lines` (sorry for not coming up with something better) to limit the number of displayed lines? That would be great! For older git versions, do you know of editor/pager options to achieve this? Thanks, Paul signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/2] Slightly prettier reflog message from checkout
Ramkumar Ramachandra wrote: > [1/2] is important. [2/2] is a minor prettification, that wouldn't > have been possible without [1/2]. I forgot to mention: some tests fail, and I'm investigating. This is an early preview. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] sha1_name: stop hard-coding 40-character hex checks
In two places, get_sha1_basic() assumes that strings are possibly sha1
hexes if they are 40 characters long, and calls get_sha1_hex() in these
two cases. This 40-character check is ugly and wrong: there is nothing
preventing a revision or branch name from being exactly 40 characters.
Replace it with a call to the more robust get_short_sha1().
Signed-off-by: Ramkumar Ramachandra
---
sha1_name.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 90419ef..d862af3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -451,7 +451,7 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
int refs_found = 0;
int at, reflog_len, nth_prior = 0;
- if (len == 40 && !get_sha1_hex(str, sha1)) {
+ if (!get_short_sha1(str, strlen(str), sha1, GET_SHA1_QUIETLY)) {
refs_found = dwim_ref(str, len, tmp_sha1, &real_ref);
if (refs_found > 0 && warn_ambiguous_refs) {
warning(warn_msg, len, str);
@@ -492,9 +492,9 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
int detached;
if (interpret_nth_prior_checkout(str, &buf) > 0) {
- detached = (buf.len == 40 && !get_sha1_hex(buf.buf,
sha1));
+ detached = get_short_sha1(buf.buf, buf.len, sha1,
GET_SHA1_QUIETLY);
strbuf_release(&buf);
- if (detached)
+ if (detached != SHORT_NAME_NOT_FOUND)
return 0;
}
}
--
1.8.3.1.438.g96d34e8
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] checkout: do not write full sha1 to reflog
A snippet from a typical git session may look like this: $ git checkout @~3 ... $ git checkout - The reflog entries corresponding to the two checkouts look like: f855138: checkout: moving from bdff0e3a374617dce784f801b97500d9ba2e4705 to co-reflog bdff0e3: checkout: moving from co-reflog to HEAD~3 There is no need to write the full SHA-1 to the user-visible reflog; use find_unique_abbrev() to shorten the first line like: f855138: checkout: moving from bdff0e3 to co-reflog Signed-off-by: Ramkumar Ramachandra --- builtin/checkout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index f5b50e5..41b1929 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -619,7 +619,7 @@ static void update_refs_for_switch(const struct checkout_opts *opts, old_desc = old->name; if (!old_desc && old->commit) - old_desc = sha1_to_hex(old->commit->object.sha1); + old_desc = find_unique_abbrev(old->commit->object.sha1, DEFAULT_ABBREV); strbuf_addf(&msg, "checkout: moving from %s to %s", old_desc ? old_desc : "(invalid)", new->name); -- 1.8.3.1.438.g96d34e8 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Slightly prettier reflog message from checkout
[1/2] is important. [2/2] is a minor prettification, that wouldn't have been possible without [1/2]. Thanks. Ramkumar Ramachandra (2): sha1_name: stop hard-coding 40-character hex checks checkout: do not write full sha1 to reflog builtin/checkout.c | 2 +- sha1_name.c| 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- 1.8.3.1.438.g96d34e8 -- To unsubscribe from this list: send the line "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 ignore logic does not work as advertised
On Sat, Jun 15, 2013 at 06:18:46PM +0200, Thomas Koch wrote: > I'm using vcsh[1] to have my dotfiles in GIT. With that I use a .gitignore > file > referenced by core.excludesfile that looks like this: > > # ignore everything by default > * > > # but do not ignore emacs stuff > !.emacs.d/ > > # but than again please ignore backup files inside the .emacs.d folder > .emacs.d/backups > > Now I'd expect git status to show everything in .emacs.d but not to show > .emacs.d/backups. However the .emacs.d/backups folder is still shown in git > status. I'd say that this is not in line with the man page and might be > considered a bug. Which version of Git are you using? You may be hitting a regression that was introduced in Git 1.8.3 and is fixed in Git 1.8.3.1. -- To unsubscribe from this list: send the line "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 ignore logic does not work as advertised
Hi, I'm using vcsh[1] to have my dotfiles in GIT. With that I use a .gitignore file referenced by core.excludesfile that looks like this: # ignore everything by default * # but do not ignore emacs stuff !.emacs.d/ # but than again please ignore backup files inside the .emacs.d folder .emacs.d/backups Now I'd expect git status to show everything in .emacs.d but not to show .emacs.d/backups. However the .emacs.d/backups folder is still shown in git status. I'd say that this is not in line with the man page and might be considered a bug. [1] https://github.com/RichiH/vcsh Thank you, Thomas Koch, http://www.koch.ro -- To unsubscribe from this list: send the line "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] config: support mixed-case aliases
To support mixed-case aliases like:
bM = branch -M
bD = branch -D
add an argument to git_config_with_options() to block the tolower()
calls on key characters.
Signed-off-by: Ramkumar Ramachandra
---
The static variable is somewhat disturbing, but it's the most obvious
choice to avoid refactoring config.c heavily. What do you think?
alias.c| 2 +-
builtin/config.c | 8
cache.h| 2 +-
config.c | 13 ++---
t/t1300-repo-config.sh | 7 +++
5 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/alias.c b/alias.c
index eb9f08b..c428592 100644
--- a/alias.c
+++ b/alias.c
@@ -18,7 +18,7 @@ char *alias_lookup(const char *alias)
{
alias_key = alias;
alias_val = NULL;
- git_config(alias_lookup_cb, NULL);
+ git_config_with_options(alias_lookup_cb, NULL, NULL, 1, 1);
return alias_val;
}
diff --git a/builtin/config.c b/builtin/config.c
index 19ffcaf..633b38a 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -218,7 +218,7 @@ static int get_value(const char *key_, const char *regex_)
}
git_config_with_options(collect_config, &values,
- given_config_file, respect_includes);
+ given_config_file, respect_includes, 0);
ret = !values.nr;
@@ -302,7 +302,7 @@ static void get_color(const char *def_color)
get_color_found = 0;
parsed_color[0] = '\0';
git_config_with_options(git_get_color_config, NULL,
- given_config_file, respect_includes);
+ given_config_file, respect_includes, 0);
if (!get_color_found && def_color)
color_parse(def_color, "command line", parsed_color);
@@ -330,7 +330,7 @@ static int get_colorbool(int print)
get_colorbool_found = -1;
get_diff_color_found = -1;
git_config_with_options(git_get_colorbool_config, NULL,
- given_config_file, respect_includes);
+ given_config_file, respect_includes, 0);
if (get_colorbool_found < 0) {
if (!strcmp(get_colorbool_slot, "color.diff"))
@@ -438,7 +438,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
check_argc(argc, 0, 0);
if (git_config_with_options(show_all_config, NULL,
given_config_file,
- respect_includes) < 0) {
+ respect_includes, 0) < 0) {
if (given_config_file)
die_errno("unable to read config file '%s'",
given_config_file);
diff --git a/cache.h b/cache.h
index 820aa05..27d201e 100644
--- a/cache.h
+++ b/cache.h
@@ -1161,7 +1161,7 @@ extern void git_config_push_parameter(const char *text);
extern int git_config_from_parameters(config_fn_t fn, void *data);
extern int git_config(config_fn_t fn, void *);
extern int git_config_with_options(config_fn_t fn, void *,
- const char *filename, int respect_includes);
+ const char *filename, int respect_includes, int
respect_mixedcase);
extern int git_config_early(config_fn_t fn, void *, const char *repo_config);
extern int git_parse_ulong(const char *, unsigned long *);
extern int git_config_int(const char *, const char *);
diff --git a/config.c b/config.c
index 7a85ebd..53ad448 100644
--- a/config.c
+++ b/config.c
@@ -23,6 +23,7 @@ typedef struct config_file {
static config_file *cf;
static int zlib_compression_seen;
+static int allow_mixedcase_keys;
#define MAX_INCLUDE_DEPTH 10
static const char include_depth_advice[] =
@@ -270,7 +271,9 @@ static int get_value(config_fn_t fn, void *data, struct
strbuf *name)
break;
if (!iskeychar(c))
break;
- strbuf_addch(name, tolower(c));
+ if (!allow_mixedcase_keys)
+ c = tolower(c);
+ strbuf_addch(name, c);
}
while (c == ' ' || c == '\t')
@@ -1005,7 +1008,8 @@ int git_config_early(config_fn_t fn, void *data, const
char *repo_config)
}
int git_config_with_options(config_fn_t fn, void *data,
- const char *filename, int respect_includes)
+ const char *filename, int respect_includes,
+ int respect_mixedcase)
{
char *repo_config = NULL;
int ret;
@@ -1018,6 +1022,9 @@ int git_config_with_options(config_fn_t fn, void *data,
data = &inc;
}
+ /* For mixed-case aliases */
+ allow_mixedcase_keys = respect_mixedcase ? 1 : 0;
+
/*
* If we have a specific filename, use it. Otherwise, follow the
* regular lookup se
Re: [PATCH] prompt: squelch error output from cat
Hi Junio,
I see you picked up this patch in branch
'rr/prompt-autostash-breakage-fix'. This patch has actually nothing
to do with autostash, it is a fix for b71dc3e1 (bash-prompt.sh: show
where rebase is at when stopped, 2013-04-25).
Gábor
On Thu, Jun 13, 2013 at 07:16:49PM +0530, Ramkumar Ramachandra wrote:
> The files $g/rebase-{merge,apply}/{head-name,msgnum,end} are not
> guaranteed to exist. When attempting to cat them, squelch the error
> output to get rid of messages like these:
>
> cat: .git/rebase-merge/msgnum: No such file or directory
> cat: .git/rebase-merge/end: No such file or directory
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> contrib/completion/git-prompt.sh | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/completion/git-prompt.sh
> b/contrib/completion/git-prompt.sh
> index 86a4f3f..07a6218 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -347,9 +347,9 @@ __git_ps1 ()
> local step=""
> local total=""
> if [ -d "$g/rebase-merge" ]; then
> - b="$(cat "$g/rebase-merge/head-name")"
> - step=$(cat "$g/rebase-merge/msgnum")
> - total=$(cat "$g/rebase-merge/end")
> + b="$(cat "$g/rebase-merge/head-name" 2>/dev/null)"
> + step=$(cat "$g/rebase-merge/msgnum" 2>/dev/null)
> + total=$(cat "$g/rebase-merge/end" 2>/dev/null)
> if [ -f "$g/rebase-merge/interactive" ]; then
> r="|REBASE-i"
> else
> @@ -357,10 +357,10 @@ __git_ps1 ()
> fi
> else
> if [ -d "$g/rebase-apply" ]; then
> - step=$(cat "$g/rebase-apply/next")
> - total=$(cat "$g/rebase-apply/last")
> + step=$(cat "$g/rebase-apply/next" 2>/dev/null)
> + total=$(cat "$g/rebase-apply/last" 2>/dev/null)
> if [ -f "$g/rebase-apply/rebasing" ]; then
> - b="$(cat "$g/rebase-apply/head-name")"
> + b="$(cat "$g/rebase-apply/head-name"
> 2>/dev/null)"
> r="|REBASE"
> elif [ -f "$g/rebase-apply/applying" ]; then
> r="|AM"
> --
> 1.8.3.1.384.g7cec0b4
>
>
--
To unsubscribe from this list: send the line "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/3] rebase: use peel_committish() where appropriate
Junio C Hamano wrote: > You can also specify the commit at the end of the history to be > rebased (very useful while trial runs to see where a series should > apply): > > git rebase foo ":/Add B" > > This is already handled properly because it first gets turned into > an object name $orig_head and then we use it (without ^0) to update > the ORIG_HEAD. Correct, but what sense does it make unless is a ref to update? $ git rebase master :/v1.8.1 First, rewinding head to replay your work on top of it... Fast-forwarded :/v1.8.1 to master. Huh? The message is wrong, and no end-user can figure out what happened. > Even after this patch, there is > > git checkout -q "$onto^0" > > when detaching the HEAD to that commit. Can that peeling be dropped > now (I am not suggesting to drop it in this patch)? Yeah, that can be dropped. > What would happen when you are given "--onto :/f...o" is somewhat > interesting, but that may be a separate topic, I think. At that > point, it is probably in the realm of "don't do it then" ;-) The utility of this very series can be questioned. I've rarely wanted to use the :/fommery with rebase, so this mostly an exercise in "theoretical correctness" (something I usually stay away from). -- To unsubscribe from this list: send the line "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 3/4] git-mw: Adding git-mw.perl script
The V3 is ready, but I am still not sure about what is the best way to do it for this issue though. On 13 June 2013 15:01, Matthieu Moy wrote: > benoit.per...@ensimag.fr writes: > How does the "make" Vs "make install" work? How does a developer run the > tool without installing? Well it does not work without installing but I think you know that now :) > I first tried: > > $ ../../bin-wrappers/git mw > git: 'mw' is not a git command. See 'git --help'. > > Then, this first seem OK: > > $ ./git-mw > usage: git mw > > git mw commands are: > HelpDisplay help information about git mw > Preview Parse and render local file into HTML > > BUT, this will take the installed GitMediawiki.pm if it is available, > and we don't want this (if one hacks GitMediawiki.pm locally, one wants > the new hacked to be taken into account without "make install"ing it). > > To understand better how it works, try adding this in git-mw.perl: > > print "$_\n" for @INC; > > I get this: > > /home/moy/local/usr-squeeze/share/perl/5.14.2 > /home/moy/local/usr-squeeze/src/MediaWiki-API-0.39/blib/lib > /etc/perl > /usr/local/lib/perl/5.14.2 > /usr/local/share/perl/5.14.2 > /usr/lib/perl5 > /usr/share/perl5 > /usr/lib/perl/5.14 > /usr/share/perl/5.14 > /usr/local/lib/site_perl > . > > The '.' is there, but it comes after the hardcoded > /home/moy/local/usr-squeeze/share/perl/5.14.2 (which has to comes first, > to let the install version be robust to whatever comes after). Thanks for the explanations > I think you need an equivalent of Git's toplevel bin-wrappers/git, or > perhaps use the same bin-wrapper/git but let "make install" in > contrib/mw-to-git/ install GitMediawiki.pm in perl/blib/lib Typo s/make install/make/ ? For now, I have implemented that one : each time you do `make`, if there is changes in GitMediawiki.pm, it gets copied to $GITPERLLIB (perl/blib/lib). But I am not sure it's the best approach here. If we want something entirely self-contained for GitMediawiki, creating a new git wrapper seems like the best way. But then, we could say that since GitMediawiki Makefile uses Git toplevel Makefile, it's not entirely self-contained :/ maybe it's the "copying file" that makes it weird ? > BTW, I just noticed we had a Git::SVN, so perhaps GitMediawiki should be > Git::MediaWiki. For that one, I am not really sure Git::Mediawiki makes more sense than GitMediawiki. The point of the GitMediawiki.pm package is to contain all the stuff for the bidirectionnal-thingy. So they are not really Git-related, nor Mediawiki-related. Making it part of a "Git" directory / namespace does not really feels right, even if it's how it's done for SVN :/ . Thank you for the all the reviews, (it works for Ensiwiki now \o/) Benoit Person -- To unsubscribe from this list: send the line "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/5] rebase: use 'git stash store' to simplify logic
rebase has no reason to know about the implementation of the stash. In
the case when applying the autostash results in conflicts, replace the
relevant code in finish_rebase () to simply call 'git stash store'.
Signed-off-by: Ramkumar Ramachandra
---
git-rebase.sh | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index d0c11a9..17be392 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -153,11 +153,8 @@ finish_rebase () {
then
echo "$(gettext 'Applied autostash.')"
else
- ref_stash=refs/stash &&
- >>"$GIT_DIR/logs/$ref_stash" &&
- git update-ref -m "autostash" $ref_stash $stash_sha1 ||
- die "$(eval_gettext 'Cannot store $stash_sha1')"
-
+ git stash store -m "autostash" -q $stash_sha1 ||
+ die "$(eval_gettext "Cannot store \$stash_sha1")"
gettext 'Applying autostash resulted in conflicts.
Your changes are safe in the stash.
You can run "git stash pop" or "git stash drop" it at any time.
--
1.8.3.1.441.gd7d6b72.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] Write a good 'stash store' for autostash
The interface actually makes sense in this iteration, thanks to Junio. Also fix minor nits pointed out by Phil Hord. Thanks. Ramkumar Ramachandra (5): stash doc: add a warning about using create stash doc: document short form -p in synopsis stash: simplify option parser for create stash: introduce 'git stash store' rebase: use 'git stash store' to simplify logic Documentation/git-stash.txt | 13 ++-- git-rebase.sh | 7 ++ git-stash.sh| 52 - t/t3903-stash.sh| 19 + 4 files changed, 74 insertions(+), 17 deletions(-) -- 1.8.3.1.441.gd7d6b72.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/5] stash: introduce 'git stash store'
save_stash() contains the logic for doing two potentially independent
operations; the first is preparing the stash merge commit, and the
second is updating the stash ref/ reflog accordingly. While the first
operation is abstracted out into a create_stash() for callers to access
via 'git stash create', the second one is not. Fix this by factoring
out the logic for storing the stash into a store_stash() that callers
can access via 'git stash store'.
Like create, store is not intended for end user interactive use, but for
callers in other scripts. We can simplify the logic in the
rebase.autostash feature using this new subcommand.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-stash.txt | 7 +++
git-stash.sh| 47 +++--
t/t3903-stash.sh| 19 ++
3 files changed, 67 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 632d4fb..db7e803 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -17,6 +17,7 @@ SYNOPSIS
[-u|--include-untracked] [-a|--all] []]
'git stash' clear
'git stash' create []
+'git stash' store [-m|--message ] [-q|--quiet]
DESCRIPTION
---
@@ -154,6 +155,12 @@ create::
This is intended to be useful for scripts. It is probably not
the command you want to use; see "save" above.
+store::
+
+ Store a given stash created via 'git stash create' (which is a
+ dangling merge commit) in the stash ref, updating the stash
+ reflog. This is intended to be useful for scripts. It is
+ probably not the command you want to use; see "save" above.
DISCUSSION
--
diff --git a/git-stash.sh b/git-stash.sh
index 64800b8..62e8cb6 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -156,6 +156,41 @@ create_stash () {
die "$(gettext "Cannot record working tree state")"
}
+store_stash () {
+ while test $# != 0
+ do
+ case "$1" in
+ -m|--message)
+ shift
+ stash_msg="$1"
+ ;;
+ -q|--quiet)
+ quiet=t
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+ test $# == 1 ||
+ die "$(eval_gettext "\"$dashless store\" requires one
argument")"
+
+ w_commit="$1"
+ if test -z "$stash_msg"
+ then
+ stash_msg="Created via \"git stash store\"."
+ fi
+
+ # Make sure the reflog for stash is kept.
+ : >>"$GIT_DIR/logs/$ref_stash"
+ git update-ref -m "$stash_msg" $ref_stash $w_commit
+ ret=$?
+ test $ret != 0 && test -z $quiet &&
+ die "$(eval_gettext "Cannot update \$ref_stash with \$w_commit")"
+ return $ret
+}
+
save_stash () {
keep_index=
patch_mode=
@@ -227,12 +262,8 @@ save_stash () {
clear_stash || die "$(gettext "Cannot initialize stash")"
create_stash "$stash_msg" $untracked
-
- # Make sure the reflog for stash is kept.
- : >>"$GIT_DIR/logs/$ref_stash"
-
- git update-ref -m "$stash_msg" $ref_stash $w_commit ||
- die "$(gettext "Cannot save the current status")"
+ store_stash -m "$stash_msg" -q $w_commit ||
+ die "$(gettext "Cannot save the current status")"
say Saved working directory and index state "$stash_msg"
if test -z "$patch_mode"
@@ -549,6 +580,10 @@ create)
shift
create_stash "$*" && echo "$w_commit"
;;
+store)
+ shift
+ store_stash "$@"
+ ;;
drop)
shift
drop_stash "$@"
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 5dfbda7..75189ec 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -637,4 +637,23 @@ test_expect_success 'stash where working directory
contains "HEAD" file' '
test_cmp output expect
'
+test_expect_success 'store called with invalid commit' '
+ test_must_fail git stash store foo
+'
+
+test_expect_success 'store updates stash ref and reflog' '
+ git stash clear &&
+ git reset --hard &&
+ echo quux >bazzy &&
+ git add bazzy &&
+ STASH_ID=$(git stash create) &&
+ git reset --hard &&
+ ! grep quux bazzy &&
+ git stash store -m quuxery $STASH_ID &&
+ test $(cat .git/refs/stash) = $STASH_ID &&
+ grep $STASH_ID .git/logs/refs/stash &&
+ git stash pop &&
+ grep quux bazzy
+'
+
test_done
--
1.8.3.1.441.gd7d6b72.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/5] stash: simplify option parser for create
The option parser for create unnecessarily checks "$1" inside a case statement that matches "$1" in the first place. Signed-off-by: Ramkumar Ramachandra --- git-stash.sh | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/git-stash.sh b/git-stash.sh index bbefdf6..64800b8 100755 --- a/git-stash.sh +++ b/git-stash.sh @@ -546,10 +546,7 @@ clear) clear_stash "$@" ;; create) - if test $# -gt 0 && test "$1" = create - then - shift - fi + shift create_stash "$*" && echo "$w_commit" ;; drop) -- 1.8.3.1.441.gd7d6b72.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/5] stash doc: document short form -p in synopsis
'git stash save' can take -p, the short form of --patch, as an option. Document this. Signed-off-by: Ramkumar Ramachandra --- Documentation/git-stash.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index cb0c1a6..632d4fb 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -13,7 +13,7 @@ SYNOPSIS 'git stash' drop [-q|--quiet] [] 'git stash' ( pop | apply ) [--index] [-q|--quiet] [] 'git stash' branch [] -'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] +'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] []] 'git stash' clear 'git stash' create [] -- 1.8.3.1.441.gd7d6b72.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] stash doc: add a warning about using create
Add a note saying that the user probably wants "save" in the create description. While at it, document that it can optionally take a message in the synopsis. Signed-off-by: Ramkumar Ramachandra --- Documentation/git-stash.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 711ffe1..cb0c1a6 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -16,7 +16,7 @@ SYNOPSIS 'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] []] 'git stash' clear -'git stash' create +'git stash' create [] DESCRIPTION --- @@ -151,6 +151,8 @@ create:: Create a stash (which is a regular commit object) and return its object name, without storing it anywhere in the ref namespace. + This is intended to be useful for scripts. It is probably not + the command you want to use; see "save" above. DISCUSSION -- 1.8.3.1.441.gd7d6b72.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] diff: add --ignore-blank-lines option
The goal of the patch is to introduce the GNU diff -B/--ignore-blank-lines as closely as possible. The short option is not available because it's already used for "break-rewrites". When this option is used, git-diff will not create hunks that simply add or remove empty lines, but will still show empty lines addition/suppression if they are close enough to "valuable" changes. There are two differences between this option and GNU diff -B option: - GNU diff doesn't have "--inter-hunk-context", so this must be handled - The following sequence looks like a bug (context is displayed twice): $ seq 5 >file1 $ catxdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF); else if (!strcmp(arg, "--histogram")) diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh index cc3db13..6ed6934 100755 --- a/t/t4015-diff-whitespace.sh +++ b/t/t4015-diff-whitespace.sh @@ -142,6 +142,314 @@ EOF git diff --ignore-space-at-eol > out test_expect_success 'another test, with --ignore-space-at-eol' 'test_cmp expect out' +test_expect_success 'ignore-blank-lines: only new lines' ' + test_seq 5 >x && + git update-index x && + test_seq 5 | sed "/3/i \\ +" >x && + git diff --ignore-blank-lines >out && + >expect && + test_cmp out expect +' + +test_expect_success 'ignore-blank-lines: only new lines with space' ' + test_seq 5 >x && + git update-index x && + test_seq 5 | sed "/3/i \ " >x && + git diff -w --ignore-blank-lines >out && + >expect && + test_cmp out expect +' + +test_expect_success 'ignore-blank-lines: after change' ' + cat <<-\EOF >x && + 1 + 2 + + 3 + 4 + 5 + + 6 + 7 + EOF + git update-index x && + cat <<-\EOF >x && + change + + 1 + 2 + 3 + 4 + 5 + 6 + + 7 + EOF + git diff --inter-hunk-context=100 --ignore-blank-lines >out.tmp && + cat <<-\EOF >expected && + diff --git a/x b/x + --- a/x + +++ b/x + @@ -1,6 +1,7 @@ + +change + + +1 +2 + - +3 +4 +5 + EOF + compare_diff_patch expected out.tmp +' + +test_expect_success 'ignore-blank-lines: before change' ' + cat <<-\EOF >x && + 1 + 2 + +
[PATCH v3 0/2] Fix am with stray $dotest directory
The test in [1/2] was too loose in the previous iteration: guard it with "test -z $rebasing". Also fix a couple of minor problems pointed out by Junio (extra indentation, $-unescaped). Thanks. Ramkumar Ramachandra (2): am: handle stray $dotest directory t/am: use test_path_is_missing() where appropriate git-am.sh | 17 + t/t4150-am.sh | 40 +++- 2 files changed, 40 insertions(+), 17 deletions(-) -- 1.8.3.1.383.g8881048.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] am: handle stray $dotest directory
The following bug has been observed: $ git am # no input file ^C $ git am --abort Resolve operation not in progress, we are not resuming. This happens because the following test fails: test -d "$dotest" && test -f "$dotest/last" && test -f "$dotest/next" and the codepath for an "am in-progress" is not executed. It falls back to the codepath that treats this as a "fresh execution". Before rr/rebase-autostash, this condition was test -d "$dotest" It would incorrectly execute the "normal" am --abort codepath: git read-tree --reset -u HEAD ORIG_HEAD git reset ORIG_HEAD by incorrectly assuming that an am is "in progress" (i.e. ORIG_HEAD etc. was written during the previous execution). Notice that $ git am ^C executes nothing of significance, is equivalent to $ mkdir .git/rebase-apply Therefore, the correct solution is to treat .git/rebase-apply as a "stray directory" and remove it on --abort in the fresh-execution codepath. Also ensure that we're not called with --rebasing from git-rebase--am.sh; in that case, it is the responsibility of the caller to handle and stray directories. While at it, tell the user to run "git am --abort" to get rid of the stray $dotest directory, if she attempts anything else. Reported-by: Junio C Hamano Signed-off-by: Ramkumar Ramachandra --- git-am.sh | 17 + t/t4150-am.sh | 6 ++ 2 files changed, 23 insertions(+) diff --git a/git-am.sh b/git-am.sh index 1cf3d1d..91a2bcc 100755 --- a/git-am.sh +++ b/git-am.sh @@ -506,6 +506,23 @@ then esac rm -f "$dotest/dirtyindex" else + # Possible stray $dotest directory in the independent-run + # case; in the --rebasing case, it is upto the caller + # (git-rebase--am) to take care of stray directories. + if test -d "$dotest" && test -z "$rebasing" + then + case "$skip,$resolved,$abort" in + ,,t) + rm -fr "$dotest" + exit 0 + ;; + *) + die "$(eval_gettext "Stray \$dotest directory found. +Use \"git am --abort\" to remove it.")" + ;; + esac + fi + # Make sure we are not given --skip, --resolved, nor --abort test "$skip$resolved$abort" = "" || die "$(gettext "Resolve operation not in progress, we are not resuming.")" diff --git a/t/t4150-am.sh b/t/t4150-am.sh index 12f6b02..6c2cc3e 100755 --- a/t/t4150-am.sh +++ b/t/t4150-am.sh @@ -363,6 +363,12 @@ test_expect_success 'am --skip works' ' test_cmp expected another ' +test_expect_success 'am --abort removes a stray directory' ' + mkdir .git/rebase-apply && + git am --abort && + test_path_is_missing .git/rebase-apply +' + test_expect_success 'am --resolved works' ' echo goodbye >expected && rm -fr .git/rebase-apply && -- 1.8.3.1.383.g8881048.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] t/am: use test_path_is_missing() where appropriate
Replace instances of ! test -d with test_path_is_missing. Signed-off-by: Ramkumar Ramachandra --- t/t4150-am.sh | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/t/t4150-am.sh b/t/t4150-am.sh index 6c2cc3e..5edb79a 100755 --- a/t/t4150-am.sh +++ b/t/t4150-am.sh @@ -147,7 +147,7 @@ test_expect_success 'am applies patch correctly' ' git checkout first && test_tick && git am actual && grep "Re: Re: Re: \[PATCH 1/5 v2\] \[foo\] third" actual ' @@ -268,7 +268,7 @@ test_expect_success 'am --keep-non-patch really keeps the non-patch part' ' git reset --hard && git checkout HEAD^ && git am --keep-non-patch patch4 && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && git cat-file commit HEAD >actual && grep "^\[foo\] third" actual ' @@ -283,7 +283,7 @@ test_expect_success 'am -3 falls back to 3-way merge' ' test_tick && git commit -m "copied stuff" && git am -3 lorem-move.patch && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && git diff --exit-code lorem ' @@ -297,7 +297,7 @@ test_expect_success 'am -3 -p0 can read --no-prefix patch' ' test_tick && git commit -m "copied stuff" && git am -3 -p0 lorem-zero.patch && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && git diff --exit-code lorem ' @@ -307,7 +307,7 @@ test_expect_success 'am can rename a file' ' git reset --hard && git checkout lorem^0 && git am rename.patch && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && git update-index --refresh && git diff --exit-code rename ' @@ -318,7 +318,7 @@ test_expect_success 'am -3 can rename a file' ' git reset --hard && git checkout lorem^0 && git am -3 rename.patch && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && git update-index --refresh && git diff --exit-code rename ' @@ -329,7 +329,7 @@ test_expect_success 'am -3 can rename a file after falling back to 3-way merge' git reset --hard && git checkout lorem^0 && git am -3 rename-add.patch && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && git update-index --refresh && git diff --exit-code rename ' @@ -358,7 +358,7 @@ test_expect_success 'am pauses on conflict' ' test_expect_success 'am --skip works' ' echo goodbye >expected && git am --skip && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && git diff --exit-code lorem2^^ -- file && test_cmp expected another ' @@ -379,7 +379,7 @@ test_expect_success 'am --resolved works' ' echo resolved >>file && git add file && git am --resolved && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && test_cmp expected another ' @@ -388,7 +388,7 @@ test_expect_success 'am takes patches from a Pine mailbox' ' git reset --hard && git checkout first && cat pine patch1 | git am && - ! test -d .git/rebase-apply && + test_path_is_missing .git/rebase-apply && git diff --exit-code master^..HEAD ' @@ -397,7 +397,7 @@ test_expect_success 'am fails on mail without patch' ' git reset --hard && test_must_fail git am >failmail && test_must_fail git am http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] am: handle stray $dotest directory
Junio C Hamano wrote: > I _think_ the new check you added may be too loose. Yep, I totally forgot about the case when git-am.sh is called from an existing script. In that case, it is upto the caller to handle whatever stray directories; we have no business meddling with that. > A fix-up may look like this. No, don't leak autostash detail. Just change that condition to if test -d "$dotest" && test -z "$rebasing" and we're done. I'll send in a re-roll. -- To unsubscribe from this list: send the line "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 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote: > The first line from status in the middle of > a rebase is secondary. End-user initiated "checkout" to detach is > the primary thing. > >> 3. The problem is not unique to rebase at all; yet you have >> special-cased it. If this isn't a band-aid, what is? > > It is an illustration for approach (2) in the other message. > > In the longer term, you would want richer status output for various > detached state, and that "how about this" patch shows where new code > to support other cases should be added. Fine. If that is what you want, we'll have to special-case every known script-in-progress to stop writing the usual "HEAD detached from" message. That'll leave out only the "end-user cases", where you argue that the message is helpful. -- To unsubscribe from this list: send the line "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 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote:
> Two possibilities:
>
> (1) Assume that the other thread will produce a more reasonable
> semantics when finished; perhaps the first line will go away
> entirely, or maybe it would say something like "# Rebasing;
> head at $commit".
>
> Your topic does not _care_ what it would say, so you tweak the
> "status" test that is done during "rebase" so that they
> ignore the first lines; or
You said you didn't want to regress to show senseless information, and
I agreed with that. What is wrong with the patch I showed in the
previous email? Smudging is a bad hack, and must only be used as a
last resort: when an another topics updates status to say something
sensible, it will have to unsmudge the tests.
diff --git a/wt-status.c b/wt-status.c
index bf84a86..99c55e3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s)
if (!get_sha1("HEAD", sha1) &&
!hashcmp(sha1, state.detached_sha1))
on_what = _("HEAD detached at ");
- else
+ else if (!state.rebase_in_progress)
on_what = _("HEAD detached from ");
} else {
branch_name = "";
> (2) Starting from the same assumption as above, but try to minimize
> the semantics change to user-visible behaviour this series
> makes.
The "try to minimize" is a somewhat admirable goal, but I have shown
that your midway solution is wrong. Either dedicate a lot of time and
effort towards improving status for rebase, or don't attempt it.
> That means that even though the _primary_ thing you want to do
> is to tweak "rebase" and its internal use of "checkout" in such
> a way that reflog will not record the implementation-detail
> checkout (because that will affect the next "checkout -"), make
> sure that "status" while doing "rebase" reports where the
> internal "checkout" of $ONTO detached HEAD from/at.
Unless we change the first line drastically to say: "rebase in
progress: rebasing onto $ONTO" (or something), I don't think this
makes sense. And if we were to do that, why not do it properly like
"rebase ($N/$M): onto $ONTO, upstream $UPSTREAM, branch $BRANCH"?
Other people on a different thread are already handling that, and I am
not interested.
So, you have three simple choices now:
1. Accept the simple patch I proposed above.
2. Propose an alternative patch quickly. *Patch*. No more English.
3. Reject all patches, and leave me no choice but to smudge.
Which one is it going to be?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Angebot sehr dringlich
guten Tag! ich bin ein privater Darlehensgeber, und ich mache die Darlehen zu all jenen, die im Bedürfnis sind und die bestimmte Bedingungen erfüllen. ich mache gehende Darlehen von 2000 Euro zu 50.000.000 Euro zu sehr interessanten Zinssätzen (3%; 3,7%). all jene, die ein Darlehen benötigen, schreiben Sie mich an die folgende Adresse. -- To unsubscribe from this list: send the line "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 5/6] status: do not depend on flaky reflog messages
Ramkumar Ramachandra writes: >> I have been assuming the "main" thing Duy wanted to do was the last >> test (and the one below), but was this meant as an improvement for >> "git status" output during that state? > > On what basis are you making that assumption? List archive helps. http://thread.gmane.org/gmane.comp.version-control.git/217342/focus=217444 Not just that single message, but a few messages in the discussion that led to the design shows that we wanted both "at" and "from" to mean something sensible, when a "checkout" initiated by the end-user detached HEAD and we are not on any branch, even after making commits or doing resets. -- To unsubscribe from this list: send the line "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] rebase -i: fixup fixup! fixup!
Andrew Pimlott writes: > Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013: >> It happened to work and I added a test. But then it occurred to me that >> it might have been better to fix commit --fixup/--squash to strip the >> fixup! or squash! from the referenced commit in the first place. >> Anyhow, below is my patch for --autosquash, but unles someone has an >> objection to doing it in commit, I'll work on that. Is it always true that you would squash and fixup in the same order as these follow-up commits happened? That is, if you did this (time flows from top to bottom): 1 A 2 B 3 fixup A 4 squash B 5 fixup fixup A 6 fixup A I am wondering if applying 6 on top of 5 is always what you want, or you would want to apply it to 3 instead. Otherwise you would have written 6 fixup fixup fixup A instead. The two reordering possibilities are: 1 A1 A 3 fixup A 3 fixup A 5 fixup fixup A6 fixup A 6 fixup A 5 fixup fixup A 2 B2 B 4 squash B 4 squash B If you strip out the prefix when you make commits, you may lose the information if you want to use in order to express these different orders. I am not sure if it matters in practice, but I am not yet convinced it is a good idea. By the way, the message I am responding to is not something we can apply. I am assuming these paches are for discussion-only; before sending the final one, please check Documentation/SubmittingPatches. 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 5/6] status: do not depend on flaky reflog messages
Ramkumar Ramachandra writes: > 2. The following no longer updates status: > > # in the middle of a rebase > $ git reset @~2 > > The constant "HEAD detached at $onto" message is misleading and Bad. > Besides, wasn't this the primary usecase you wanted? See the other message. The first line from status in the middle of a rebase is secondary. End-user initiated "checkout" to detach is the primary thing. > You previously wrote: >> *1* One thing I could think of is to start sightseeing or (more >> realistically) manually bisecting at a given release point, >> reset the detached HEAD around several times, and then want to >> be reminded where the session started from. I do not think it >> is particularly a very good example, though. > > Whether the HEAD is detached by bisect or rebase is irrelevant. You read and reacted to "bisect" too literally and missed "manually". The scenario I had in mind does _not_ use "git bisect" command, which may _internally_ run "git checkout" to detach, but for exactly the same reason why you want to touch "git rebase" in this series, its use of "checkout" should not count for the next "checkout -". The sequence of "manually bisecting" is like $ git checkout v1.8.3 ... test $ git status $ git log --oneline --first-parent v1.8.2..$detached_from ... pick a likely point $ git reset --hard $that_point ... go back to test further which I actually do fairly often, as I tend to know more about the likely place something may have been broken than a mechanical "split the history into about the same number of commits" bisection. > 3. The problem is not unique to rebase at all; yet you have > special-cased it. If this isn't a band-aid, what is? It is an illustration for approach (2) in the other message. In the longer term, you would want richer status output for various detached state, and that "how about this" patch shows where new code to support other cases should be added. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Youur wiif will bee the happieeest lady on the plllaaneeet
Get beetter sex lifee withh ttthese gggreat piills http://ozdecor.com/admin/popups/6e71.php -- To unsubscribe from this list: send the line "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 5/6] status: do not depend on flaky reflog messages
Ramkumar Ramachandra writes: > Junio C Hamano wrote: >> I am only saying that the last test the commit adds must be kept >> unbroken. I am also saying that, even though that commit did not >> add a test for "detached from" case, we should add something like >> the attached to protect the behaviour. These two are sacred. >> >> What happens to be shown during a stopped "git rebase" is not. > ... > The question is: what do _you_ want now? It should be fairly clear what _I_ want now. Re-read the first four lines you quoted above. > Read the various "HEAD detached from/to" messages in the rebase tests > in t/status-help and tell me that they make some sense. Again, re-read the part you did _not_ quote before those four lines. I do not think all of them make lot of sense; some of them may. Unless you are also tackling the topic of the other thread: http://thread.gmane.org/gmane.comp.version-control.git/227432/focus=227469 (which I would not suggest to do in this topic), what these lines say during "rebase" does not really matter, as far as your topic is concerned. Two possibilities: (1) Assume that the other thread will produce a more reasonable semantics when finished; perhaps the first line will go away entirely, or maybe it would say something like "# Rebasing; head at $commit". Your topic does not _care_ what it would say, so you tweak the "status" test that is done during "rebase" so that they ignore the first lines; or (2) Starting from the same assumption as above, but try to minimize the semantics change to user-visible behaviour this series makes. That means that even though the _primary_ thing you want to do is to tweak "rebase" and its internal use of "checkout" in such a way that reflog will not record the implementation-detail checkout (because that will affect the next "checkout -"), make sure that "status" while doing "rebase" reports where the internal "checkout" of $ONTO detached HEAD from/at. The "something along this line" patch was an illustration of how the beginning of the effort for (2) would look like. As I already said, I could see us going either way. If we can do (2), that may be better, but at end it would not matter that much as long as we will be doing the other topic, too. -- To unsubscribe from this list: send the line "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 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote: > I am only saying that the last test the commit adds must be kept > unbroken. I am also saying that, even though that commit did not > add a test for "detached from" case, we should add something like > the attached to protect the behaviour. These two are sacred. > > What happens to be shown during a stopped "git rebase" is not. > > I have been assuming the "main" thing Duy wanted to do was the last > test (and the one below), but was this meant as an improvement for > "git status" output during that state? On what basis are you making that assumption? b397ea4 did not add a test for "detached HEAD from", and there is no evidence of what the author wanted in the commit message. What has happened has happened; the question is: what do _you_ want now? Read the various "HEAD detached from/to" messages in the rebase tests in t/status-help and tell me that they make some sense. It does _not_ show a constant "HEAD detached from $onto", contrary to your assumption (evidenced by your patch in the later email). Look at these hunk added by b397ea4, and tell me that it's not a monkey-patch: @@ -187,9 +187,10 @@ test_expect_success 'status when rebasing -i in edit mode' ' export FAKE_LINES && test_when_finished "git rebase --abort" && ONTO=$(git rev-parse --short HEAD~2) && + TGT=$(git rev-parse --short two_rebase_i) && git rebase -i HEAD~2 && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached from $TGT # You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''$ONTO'\''. # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) @@ -214,8 +215,9 @@ test_expect_success 'status when splitting a commit' ' ONTO=$(git rev-parse --short HEAD~3) && git rebase -i HEAD~3 && git reset HEAD^ && + TGT=$(git rev-parse --short HEAD) && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached at $TGT # You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''$ONTO'\''. # (Once your working directory is clean, run "git rebase --continue") # @@ -243,10 +245,11 @@ test_expect_success 'status after editing the last commit with --amend during a export FAKE_LINES && test_when_finished "git rebase --abort" && ONTO=$(git rev-parse --short HEAD~3) && + TGT=$(git rev-parse --short three_amend) && git rebase -i HEAD~3 && git commit --amend -m "foo" && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached from $TGT # You are currently editing a commit while rebasing branch '\''amend_last'\'' on '\''$ONTO'\''. # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) > Showing $ONTO certainly > makes some sense, and from that point of view, the change we are > discussing _will_ be a regression if it just shows a random thing. If showing $ONTO were the intent of the patch, this is no way to go about it. Reliable information is readily available in .git/rebase-apply; no parsing is required, and it is ready for consumption. Your argument now is: because the patch _incidentally_ shows $ONTO in many cases (as evidenced by the hunks above), the objective of the patch _must_ have been to show $ONTO. Should I laugh or cry? > If you want to avoid regression, the codepath in wt-status.c should > compensate for the change to "rebase" so that it checks $dotest/onto > and show what is recorded in there. Now you want to achieve the exact same accidental behavior after patching rebase/checkout. This is a never-ending nightmare. > You are misreading me. I am not defending every bit at all. I am not misreading anything. Despite me having repeatedly shown that b397ea4 is poorly done with far-reaching unintended consequences, you are unwilling to admit it. Instead, you are trying to somehow preserve this accidental behavior. And you still haven't been able to show me how to do that. As a result, checkout-dash is stalled. -- To unsubscribe from this list: send the line "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 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote:
> wt-status.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index bf84a86..403d48d 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1176,7 +1176,11 @@ void wt_status_print(struct wt_status *s)
> branch_name += 11;
> else if (!strcmp(branch_name, "HEAD")) {
> branch_status_color = color(WT_STATUS_NOBRANCH, s);
> - if (state.detached_from) {
> +
> + if (state.rebase_in_progress) {
> + on_what = _("HEAD detached at ");
> + branch_name = state.onto;
> + } else if (state.detached_from) {
> unsigned char sha1[20];
> branch_name = state.detached_from;
Good. You have proposed a solution to the problem. However, it is
wrong for the following reasons:
1. It shows a pseudo "HEAD detached at" message. Everywhere else,
when the user sees a "HEAD detached at $committish" message, git
rev-parse $committish = git rev-parse HEAD. A rebase-in-progress
seems to be the only exception, and the user has no idea this is
happened.
2. The following no longer updates status:
# in the middle of a rebase
$ git reset @~2
The constant "HEAD detached at $onto" message is misleading and Bad.
Besides, wasn't this the primary usecase you wanted?
You previously wrote:
> *1* One thing I could think of is to start sightseeing or (more
> realistically) manually bisecting at a given release point,
> reset the detached HEAD around several times, and then want to
> be reminded where the session started from. I do not think it
> is particularly a very good example, though.
Whether the HEAD is detached by bisect or rebase is irrelevant.
3. The problem is not unique to rebase at all; yet you have
special-cased it. If this isn't a band-aid, what is? The larger
problem, as I have stated previously, is that 'git status' output
depends on the _implementations_ of various commands (do they write a
"checkout: " message to the reflog or not?). Therefore, a future
contributor who updates a command to write more sensible reflog
messages will have to apply a similar band-aid.
If you want to take the band-aid approach, I think this is the right
way to do it:
diff --git a/wt-status.c b/wt-status.c
index bf84a86..99c55e3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s)
if (!get_sha1("HEAD", sha1) &&
!hashcmp(sha1, state.detached_sha1))
on_what = _("HEAD detached at ");
- else
+ else if (!state.rebase_in_progress)
on_what = _("HEAD detached from ");
} else {
branch_name = "";
You have already mentioned that there is a topic cooking to improve
this first-line in the case of rebase, so this regression from a
senseless message isn't a problem.
The problem with this bad-aid, as with all band aids, is that this
will soon explode to become else if(!state.rebase_in_progress &&
!state.bisect_in_progress && ) when people update those scripts.
If you don't want to go with the band-aid, I have no choice but to
smudge the first-line.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
