gmane.comp.version-control.git

[PATCH] peel_onion(): add support for ^{tag}

Richard Hansen — 2013-06-19T01:39:06

gitrevisions(7) implies that <rev>^{tag} should work, but before now
it did not:

    $ git rev-parse --verify v1.8.3.1^{tag}
    fatal: Needed a single revision

This commit fixes the omission:

    $ git rev-parse --verify v1.8.3.1^{tag}
    4bc068950abec778a02ebf3ee73cf0735affabb4

Other object type names work as expected:

    $ git rev-parse --verify v1.8.3.1^{commit}
    362de916c06521205276acb7f51c99f47db94727
    $ git rev-parse --verify v1.8.3.1^{tree}
    c1fef48675edd74e9af19405339e8bdaebd56b0c
    $ git rev-parse --verify v1.8.3.1^{blob}
    error: v1.8.3.1^{blob}: expected blob type, but the object dereferences to tree type
    fatal: Needed a single revision

Note that <rev>^{tag} is not the same as <rev>^{object} when <rev> is
not a tag:

    $ git rev-parse --verify v1.8.3.1^{}^{object}
    362de916c06521205276acb7f51c99f47db94727
    $ git rev-parse --verify v1.8.3.1^{}^{tag}
    error: v1.8.3.1^{}^{tag}: expected tag type, but the object dereferences to tree type
    fatal: Needed a single

small misspellings fixes

Veres Lajos — 2013-06-18T23:04:37

Hi,

I am trying to convert this pull request:
https://github.com/git/git/pull/42
to a proper patch email
(Sorry If I miss something about the process.)

I found a few trivial misspellings.

Signed-off-by: Veres Lajos <vlajos< at >gmail.com>
---
diff --git a/git-p4.py b/git-p4.py
index 911bbce..88fcf23 100755
--- a/git-p4.py
+++ b/git-p4.py
< at >< at > -3168,7 +3168,7 < at >< at > class P4Rebase(Command):
         if os.system("git update-index --refresh") != 0:
             die("Some files in your working directory are modified and different than what is in your index. You can use git update-index <filename> to bring the index up-to-date or stash away all your changes with git stash.");
         if len(read_pipe("git diff-index HEAD --")) > 0:
-            die("You have uncommited changes. Please commit them before rebasing or stash them away with git stash.");
+            die("You have uncommitted changes. Please commit them before rebasing or stash them away with git stash.");

         [upstream, settings] = findUpstreamBranch

Re: [PATCH] git-add--interactive.perl: Permit word-based diff

Jeff King — 2013-06-18T22:47:22


Right. My point is that the colorized version always lines up with the
"real" to-apply version line-for-line. But the word diff version does
not.

If we assume that they line up hunk for hunk (that is, --color-words
comes up with the same number of hunks, but the contents of each hunk
may be different), then swapping "colorized line diff" for "word diff"
in the presentation version (i.e., your patch) is fine. I think this is
the case with the current --word-diff, so the only question would be one
of not wanting to paint ourselves into a corner with implementation
details. I think that is OK, as if we later wanted to change --word-diff
to coalesce hunks, we could continue to support a
"--hunk-based-word-diff" mode for this type of operation that cares
about matching the normal diff hunks.

If we assume that the presentation version lines up line for line within
each hunk, then it is safe to do hunk-level operations like splitting.
That works with the current colorized diffs, but not with word-diff. I
think

Re: [PATCH] Avoid broken Solaris tr

Junio C Hamano — 2013-06-18T22:31:30


Almost all the tr invocations look like converting LF to NUL, except
for two that squash a colon ':', HT and LF all to NUL.  Is Solaris's
tr fine with the former but not the latter?


I am not suggesting to keep 'tr "\n" "\0"', but just wanted to make
sure I am reading the first paragraph correctly.  If we are
rewriting, we should do so consistently.


What is -pne?  Is it the same as -pe?

tr/\n/\0/ (or y/\n/\0/) may be more faithful to the original.



Ditto.  We may want to give the same script used in the above two
(and twice again in the later hunk) more descriptive name, e.g.

broken_c_unquote () {
perl -pe '... that script ...' "$< at >"
}

broken_c_quote stdin >stdin0

Side note: the script is broken as a generic C-unquote function in
multiple ways.  It does not work if it has more than one backslash
quoted characters, it does not understand \t, \b, \015, \\, etc. to
name two.

But the breakage does not matter for the strings used in the test
vector.

Re: [PATCH] http.c: don't rewrite the user:passwd string multiple times

Jeff King — 2013-06-18T22:13:28


Yeah, I didn't mean to imply "we don't care about these versions", only
that our analysis is different between the two sets. We have #ifdefs for
curl going back to 7.7.4. That's probably excessive, but AFAIK, we would
still work with such old versions.


Yes, we do; the dumb http walker will pipeline loose pack and object
requests (which makes a big difference when fetching small files). The
smart http code may use the curl-multi interface under the hood, but it
should only have a single handle, and the use of the multi interface is
just for sharing code with the dumb fetch.


Agreed. I did not so much mean to dispute your "potentially dangerous"
claim as clarify exactly what the potential is. :)


I don't think curl does any threading; when we are not inside
curl_*_perform, there is no curl code running at all (Daniel can correct
me if I'm wrong on that).

So I think from curl's perspective a truncation and exact rewrite is
atomic, and it sees only the final content.  I don't know what would
happen if you

[PATCH] Avoid broken Solaris tr

Ben Walton — 2013-06-18T21:17:27

Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) fail to handle the case
where the first argument is a multi-character set and the second is a
single null character. Use perl to perform these substitutions
instead. Now that we're using perl for the transliteration, we might
as well replace the sed invocations with it too.

We make this change globally in t0008-ignores instead of just for the
cases where it matters in order to maintain consistency.

Signed-off-by: Ben Walton <bdwalton< at >gmail.com>
---
 t/t0008-ignores.sh | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index a56db80..9e4987e 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
< at >< at > -552,12 +552,13 < at >< at > cat <<-EOF >expected-verbose
 $global_excludes:2:!globaltwob/globaltwo
 EOF
 
-sed -e 's/^"//' -e 's/\\//' -e 's/"$//' stdin | \
-tr "\n" "\0" >stdin0
-sed -e 's/^"//' -e 's/\\//' -e 's/"$//' expected-default | \
-tr "\n" "\0" >expected-default0
-sed -e 's/

Re: [PATCH] git-add--interactive.perl: Permit word-based diff

Mark Abraham — 2013-06-18T21:12:59

Yes, that was probably it. I tried to find a gmail configuration, but
I now discover it is done per-email, not globally. Apologies. I have
forwarded the original to Thomas, but based on current feedback, it
seems not worth re-sending the original mail to the list. See below.


My choice of "permit" in the description was not best. My
implementation showed a word-based diff, but preserved the existing
mechanism for actually applying the hunk. I understand the way
colorization in git-add--interactive.perl works right now is to
colorize one version to display and use another - I think I preserved
that. I intended to permit the user to choose to show a word-based
diff of a patch during interactive add.


Hmm, I will have to re-consider the implications on that kind of
workflow. Thanks!


Yes, that was what I was aiming to make easier.


Good point. What I think I really want is "git add
--interactive=color" (with or without --patch) to permit the user to
choose to see the (colorized) word-based diff when they w

Re: [PATCH v2 7/7] rebase -i: write better reflog messages

Junio C Hamano — 2013-06-18T20:55:16


Sorry, you've already used my time allotment for this week.

What's cooking in git.git (Jun 2013, #06; Tue, 18)

Junio C Hamano — 2013-06-18T20:41:38

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

We are at the beginning of week #3 of this cycle, which is expected
to end around mid August.  There are some patches on the list that I
didn't manage to pick up, either they were still in flux or they
came too late after I started today's integration cycle, but we seem
to be making a good progress.

The biggest achievement for me is that all the in-flight topics in
this issue is properly annotated, and "Meta/cook -w" output does not
have any "Undecided" entries ;-)

You can find the changes described here in the integration branches
of the repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[New Topics]

* rr/rebase-checkout-reflog (2013-06-17) 8 commits
 - SQUASH???
 - rebase -i: use a better reflog message
 - rebase: use a better reflog message
 - checkout: respect

Re: [PATCH v2 7/7] rebase -i: write better reflog messages

Ramkumar Ramachandra — 2013-06-18T20:38:16

Oh, okay.  Then just tweak before applying, if you don't mind?

Re: [PATCH v2 7/7] rebase -i: write better reflog messages

Junio C Hamano — 2013-06-18T20:36:21


Why did this have to change back from branch-reflog-test to branch1
(which I used by mistake in "how about this" patch, but fixed in the
version queued on 'pu')?

The reason I did not use 'branch1' in the version I queued on 'pu'
is because rr/rebase-sha1-by-string-query, when merged on top of
this, makes an assumption on where branch1 is in the test and
fliping its tip here will break it.

Have you tested this with combination of that topic before sending
it out?

Re: [PATCH v2 6/7] rebase: write better reflog messages

Junio C Hamano — 2013-06-18T20:35:47


So the approach taken by this round is to change everybody's
assumption so far that they can start from a clean and usable
GIT_REFLOG_ACTION when creating their own message, and stop
depending on what is left in GIT_REFLOG_ACTION.

That would certainly allow this patch to leave whatever cruft in
GIT_REFLOG_ACTION, because everybody else will now create the value
to be assigned to that variable from scratch based on a new and
different variable.  All existing "everybody else" is converted to
adjust to the new reality.

A one-shot assignment "VAR=VAL git checkout" is sometimes cumbersome
to arrange, especially when what calls the "git checkout" is wrapped
in a shell function like "output", I think this is an OK approach.

If we are adopting that convention, however, the new variable that
holds the name of the overall program, base_reflog_action, needs to
be a bit more prominently documented in the code, to let the other
people know that is the new convention to follow.

Something like...

# Use this as the

Re: [PATCH] t/t5800-remote-testpy: skip all tests if not built

Ramkumar Ramachandra — 2013-06-18T20:35:06

How exactly?  I'm not exactly competent in make, but this is what I
understood from what you said (and it's obviously wrong):

diff --git a/Makefile b/Makefile
index 03524d0..da91937 100644
--- a/Makefile
+++ b/Makefile
< at >< at > -580,6 +580,7 < at >< at > TEST_PROGRAMS_NEED_X += test-svn-fe
 TEST_PROGRAMS_NEED_X += test-wildmatch

 TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
+TEST_PROGRAMS += git-remote-testpy

 # List built-in command $C whose implementation cmd_$C() is not in
 # builtin/$C.o but is linked in as part of some other command.

Re: [PATCH] t/t5800-remote-testpy: skip all tests if not built

Junio C Hamano — 2013-06-18T20:28:56


Sounds like making "make test" build it is a more correct approach,
at least to me.  What am I missing?

[PATCH] t/t5800-remote-testpy: skip all tests if not built

Ramkumar Ramachandra — 2013-06-18T20:06:46

416fda6 (build: do not install git-remote-testpy, 2013-05-24) added
git-remote-testpy to NO_INSTALL, with the intent of excluding it from
the default install.  This is typically meant for scripts in contrib/
with their own testsuite and Makefile (e.g. git remote-bzr, git
remote-hg).  Unfortunately, git-remote-testpy.py is a toplevel script
without its own Makefile; its testsuite is located in
t/t5800-remote-testpy.sh.

What this means is that git-remote-testpy is not built by default (when
'make' is invoked), but t5800 runs by default (like every other test in
t/).  As a result, a new contributor cloning git.git and running 'make
test' for the first time will notice test failures.  Fix this
unpleasantness by patching t5800 to check for git-remote-testpy as a
prerequisite.

Signed-off-by: Ramkumar Ramachandra <artagnon< at >gmail.com>
---
 Candidate for maint?

 t/t5800-remote-testpy.sh | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/t/t5800-remote-testpy.sh b/t/t5800-remote-testpy.sh
index 1e683d4..9df35

Re: [PATCH v2 00/13] bash prompt speedup

Simon Oosthoek — 2013-06-18T19:35:51

* Junio C Hamano <gitster< at >pobox.com> [2013-06-18 09:48:28 -0700]:


Hi Junio e.a.

Unfortunately I'm very busy with lots of stuff, so hardly time to look at this. (I didn't read the full patch or resulting file)

The PROMPT_COMMAND business was not something I was glad to use, I was unable to get command substitution mode to work with colours and keep bash happy about the prompt string length. The thing to test is not whether or not colours appear when using substitution in PS1, but to see whether bash will not mess up the commandline when browsing through the history. This is especially inconvenient with very long commandlines (as you can imagine).

An optimisation which I've not yet had time to work on would be to do a lot of the processing in separate functions and use the result in separate functions for pcmode and subst. mode. The idea being that the maintainability of the logic for generating the prompt goes up (no duplicate code, clear separation, etc.) and the size of the called functions to gerenate

Re: [PATCH] unpack-trees: don't shift conflicts left and right

René Scharfe — 2013-06-18T19:33:25

Am 18.06.2013 01:42, schrieb Junio C Hamano:

Yes, that's not pretty.  It's like make_traverse_path in that regard, 
though, so it fits in somehow.

I suspect the *real* solution is to put something like 
traverse_trees_recursive into tree-walk.c.  Both callers of 
traverse_tree recurse into subdirectories in slightly different ways. 
Providing that functionality in a central place should reduce code 
duplication.

René

Re: [PATCH] http.c: don't rewrite the user:passwd string multiple times

Brandon Casey — 2013-06-18T19:29:03

Daniel mentions that the change happened in libcurl 7.17.  RHEL 4.X
(yes, ancient, dead, I realize) provides 7.12 and RHEL 5.X (yes,
ancient, but still widely in use) provides 7.15.  Just pointing it
out.


I was probably reading the docs on one of these older platforms when I
wrote this.  I've actually had this patch sitting around for a while.


Don't we have multiple handles in play at the same time?  What's going
on in get_active_slot() when USE_CURL_MULTI is defined?  It appears to
be maintaining a list of "slot" 's, each with its own curl handle
initialized either by curl_easy_duphandle() or get_curl_handle().

So, yeah, this is what I was referring to when I mentioned
"potentially dangerous".  Since the current code does not change the
size of the string, the pointer will never change, so we won't ever
invalidate a pointer that another handle is using.

The other thing I thought was potentially dangerous, was just
truncating the string.  Again, if there are multiple curl handles in
use (which I thoug

[PATCH] completion: complete diff --word-diff

Ramkumar Ramachandra — 2013-06-18T19:24:05

Signed-off-by: Ramkumar Ramachandra <artagnon< at >gmail.com>
---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index fd9a1d5..6c3bafe 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
< at >< at > -1163,7 +1163,7 < at >< at > __git_diff_common_options="--stat --numstat --shortstat --summary
 --no-prefix --src-prefix= --dst-prefix=
 --inter-hunk-context=
 --patience --histogram --minimal
---raw
+--raw --word-diff
 --dirstat --dirstat= --dirstat-by-file
 --dirstat-by-file= --cumulative
 --diff-algorithm=

Re: [PATCH] sequencer: write useful reflog message for fast-forward

Ramkumar Ramachandra — 2013-06-18T19:02:56

Agreed.  Can you just fix it up locally?

Thanks.

[PATCH v2 7/7] rebase -i: write better reflog messages

Ramkumar Ramachandra — 2013-06-18T18:55:37

Now that the "checkout" invoked internally from "rebase -i" knows to
honor GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when "rebase -i anotherbranch", "rebase -i --onto branch",
etc. internally checks out the new fork point.  We will write:

  rebase -i (start): checkout master

instead of the old

  rebase -i (start)

[jc: add rebase-reflog test]

Signed-off-by: Ramkumar Ramachandra <artagnon< at >gmail.com>
Signed-off-by: Junio C Hamano <gitster< at >pobox.com>
---
 git-rebase--interactive.sh    | 14 ++++++++++----
 t/t3404-rebase-interactive.sh | 15 +++++++++++++++
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f953d8d..8429c87 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
< at >< at > -95,12 +95,15 < at >< at > commit_message () {
 git cat-file commit "$1" | sed "1,/^$/d"
 }
 
-orig_reflog_action="$GIT_REFLOG_ACTION"
+base_reflog_action="$GIT_REFLOG_ACTION"
 
 comment_for_reflog () {
-case "$orig