* Re: [PATCH 0/3] Move api-command.txt from ./technical/ to ./howto
From: Junio C Hamano @ 2012-12-21 18:33 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <1595193006.286662.1356112971883.JavaMail.ngmail@webmail14.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> "api-command.txt" describes a different kind of API than the other api-* documents.
> So better move it to the howto documents in ./Documentation/howto and rename
> to "new-command.txt".
>
> [PATCH 1/3] Move ./technical/api-command.txt to ./howto/new-command.txt
> [PATCH 2/3] Add new-command.txt to ./Documentation/Makefile
> [PATCH 3/3] Amend new-command.txt to be processed correctly by howto-index.sh
>
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Seems good from a cursory look, but I think this is better done in a
single patch. If you do not mind, I'll squash them into one.
Thanks.
^ permalink raw reply
* Re: Python version auditing followup
From: Junio C Hamano @ 2012-12-21 18:28 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <000d01cddf4c$8cbf2ca0$a63d85e0$@schmitz-digital.de>
"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
>> > We have a working 2.4.2 for HP-NonStop and some major problems getting
>> > 2.7.3 to work.
>>
>> I do not think a platform that stops at 2.4.2 instead of going to
>> higher 2.4.X series deserves to be called "long term maintained by
>> their vendors". It sounds more like "attempted to supply 2.4.X and
>> abandoned the users once one port was done" to me.
>
> Well, not entirely wrong, but not all true at too.
> I guess I need to defend the vendor here: It is not really the
> Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3,
> it is a volunteer and community effort. HP did sponsor the 2.4.2
> port though (by allowing an HP employee to do the port inn his
> regular working hours). It is not doing this any longer (since
> 2007). Since then it is a small group doing this on a purely
> voluntary basis in their spare time (one HP employee amongst them,
> me). Same goes for the git port BTW.
For the purpose of "if we draw the line at 2.6, would it hurt many
people who have been happily using the existing release of Git that
was happy with 2.4", it is dubious HP-NonStop counts. It is not
like the users on that platform have been happily using Python based
Porcelain at the fringe of Git, and drawing the line at 2.6 will not
give them any regression.
It does add more things that needs to be done to the volunteer
developers for that platform and the organization that may want to
support the platform (as they have to finish 2.6 port if we decide
to draw the line there), but that is a secondary consideration.
^ permalink raw reply
* Re: [PATCH] http.c: Avoid username prompt for certifcate credentials
From: Junio C Hamano @ 2012-12-21 18:19 UTC (permalink / raw)
To: Jeff King; +Cc: Rene Bredlau, git
In-Reply-To: <20121221170927.GA23574@sigill.intra.peff.net>
Thanks, both.
^ permalink raw reply
* Re: recommendation for patch maintenance
From: Junio C Hamano @ 2012-12-21 18:17 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50D49C81.5060007@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> I lose the history of all the changes I have made to produce the final
> version of a patch.
>
> Since for every new version of a patch I do a commit --amend, I can not
> see, as an example, the changes I have made between x and y versions of
> a patch.
>
> Of course the commits are not really lost, but I have to search them
> using the reflog.
Yeah, these days with "rebase -i" that does not leave individual
steps as separate reflog entries, for an easy series, you can do
things like:
$ git rebase -i ;# work on polishing the series
$ git show-branch -g ;# view where it diverged
$ git diff HEAD~4 @{1}~4
Of course you can plan ahead (this is what I usually do when working
on a series that is not "how about this" throw-away patch I send to
this list all the time) and name the topic "topic-v1", fork the new
round "topic-v2", "topic-v3", etc. and do things like
$ sh -c 'git diff topic-v2~$1 topic-v3~$1' - 4
(the point being that then you do ^P or whatever shell command
history mechanism to recall that line, edit "4" to "3" and rerun the
comparison for other corresponding ones).
On a related but different front, I've been thinking about improving
the "format-patch --subject-prefix" mechanism to make it even easier
to use. With the current interface, when you prepare your reroll,
you would do:
$ git format-patch --cover-letter \
--subject-prefix='PATCH v4' -o ./+mp master
and end up overwriting the patches from the previous round (if their
subject did not change). You will always overwrite the cover
because its subject never changes and that is where the filename is
taken from.
What if we added another option, say --reroll $n (or -v$n), to let
you write:
$ git format-patch --cover-letter -v4 -o ./+mp master
that produces output files named like:
./+mp/v4-0000-cover-letter.txt
./+mp/v4-0001-git-completion.bash.add-support-for-pa.txt
with the subject '[PATCH v4]' prefix?
Then you can transplant the cover letter material from the cover
letter from the older iteration to the new cover letter in your
editor, and sending them out will become
$ git send-email ... ./+mp/v4-*.txt
Hmm?
^ permalink raw reply
* [PATCH 3/3] Amend new-command.txt to be processed correctly by howto-index.sh
From: Thomas Ackermann @ 2012-12-21 18:07 UTC (permalink / raw)
To: git; +Cc: th.acker
In-Reply-To: <1595193006.286662.1356112971883.JavaMail.ngmail@webmail14.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/howto/new-command.txt | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/howto/new-command.txt b/Documentation/howto/new-command.txt
index d3b9781..36502f6 100644
--- a/Documentation/howto/new-command.txt
+++ b/Documentation/howto/new-command.txt
@@ -1,5 +1,10 @@
-Integrating new subcommands
-===========================
+From: Eric S. Raymond <esr@thyrsus.com>
+Abstract: This is how-to documentation for people who want to add extension
+ commands to git. It should be read alongside api-builtin.txt.
+Content-type: text/asciidoc
+
+How to integrate new subcommands
+================================
This is how-to documentation for people who want to add extension
commands to git. It should be read alongside api-builtin.txt.
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 2/3] Add new-command.txt to ./Documentation/Makefile
From: Thomas Ackermann @ 2012-12-21 18:06 UTC (permalink / raw)
To: git; +Cc: th.acker
In-Reply-To: <1595193006.286662.1356112971883.JavaMail.ngmail@webmail14.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 7df75d0..f3afcb6 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -21,6 +21,7 @@ ARTICLES += git-tools
ARTICLES += git-bisect-lk2009
# with their own formatting rules.
SP_ARTICLES = user-manual
+SP_ARTICLES += howto/new-command
SP_ARTICLES += howto/revert-branch-rebase
SP_ARTICLES += howto/using-merge-subtree
SP_ARTICLES += howto/using-signed-tag-in-pull-request
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 1/3] Move ./technical/api-command.txt to ./howto/new-command.txt
From: Thomas Ackermann @ 2012-12-21 18:05 UTC (permalink / raw)
To: git; +Cc: th.acker
In-Reply-To: <1595193006.286662.1356112971883.JavaMail.ngmail@webmail14.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/{technical/api-command.txt => howto/new-command.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/{technical/api-command.txt => howto/new-command.txt} (100%)
diff --git a/Documentation/technical/api-command.txt b/Documentation/howto/new-command.txt
similarity index 100%
rename from Documentation/technical/api-command.txt
rename to Documentation/howto/new-command.txt
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply
* [PATCH 0/3] Move api-command.txt from ./technical/ to ./howto
From: Thomas Ackermann @ 2012-12-21 18:02 UTC (permalink / raw)
To: git; +Cc: th.acker
"api-command.txt" describes a different kind of API than the other api-* documents.
So better move it to the howto documents in ./Documentation/howto and rename
to "new-command.txt".
[PATCH 1/3] Move ./technical/api-command.txt to ./howto/new-command.txt
[PATCH 2/3] Add new-command.txt to ./Documentation/Makefile
[PATCH 3/3] Amend new-command.txt to be processed correctly by howto-index.sh
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Thomas
^ permalink raw reply
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: Junio C Hamano @ 2012-12-21 17:59 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git, szeder, felipe.contreras
In-Reply-To: <1356108872-5881-1-git-send-email-manlio.perillo@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> + case "$path" in
> + ?*/*) echo "${path%%/*}/" ;;
> + *) echo $path ;;
$path unquoted???
> +# __git_index_files accepts 1 or 2 arguments:
> +# 1: Options to pass to ls-files (required).
> +# Supported options are --cached, --modified, --deleted, --others,
> +# and --directory.
> +# 2: A directory path (optional).
> +# If provided, only files within the specified directory are listed.
> +# Sub directories are never recursed. Path must have a trailing
> +# slash.
> +__git_index_files ()
> +{
> + local dir="$(__gitdir)"
> +
> + if [ -d "$dir" ]; then
> + # NOTE: $1 is not quoted in order to support multiple options
Good thinking to document this. Thanks.
I take it that $1 never comes from the end user and it is known that
it is correct to split them at $IFS? That is the way I read callers
of this function in this patch, but I am just double-checking.
> @@ -998,7 +1093,13 @@ _git_commit ()
> "
> return
> esac
> - COMPREPLY=()
> +
> + if git rev-parse --verify --quiet HEAD 1>/dev/null; then
s/1>/>/;
> + __git_complete_diff_index_file "HEAD"
As this runs "git diff-index" without --cached,
The completion will give only for paths that have difference between
the working tree and the HEAD. If the user has a bogus contents
that was "git add"ed earlier, (i.e. the index is different from
HEAD), then realizes the mistake and fixes it in the working tree
with his editor to match "HEAD" (i.e. the working tree is the same
as HEAD):
git commit the-prefix-to-that-file<TAB>
to complete the filename will not give that file. I do not think it
is a show-stopper, but it may puzzle the users when they encounter
the situation.
I am wondering if reading from "git status --porcelain" might be a
better alternative, or if it is too much trouble and slow things
down to cover such a corner case.
> @@ -1362,7 +1464,14 @@ _git_mv ()
> return
> ;;
> esac
> - COMPREPLY=()
> +
> + if [ $cword -gt 2 ]; then
> + # We need to show both cached and untracked files (including
> + # empty directories) since this may not be the last argument.
> + __git_complete_index_file "--cached --others --directory"
> + else
> + __git_complete_index_file "--cached"
> + fi
Is $cword affected by the presense of "-f" in "git mv [-f] foo bar"?
Just being curious.
Other than that, I do not see anything majorly wrong from the coding
and semantics point of view in the patch. As to the interaction
with the rest of the completion machinery, I'll leave the review to
the area experts CC'ed and wait for their comments.
Thanks.
^ permalink raw reply
* [PATCH] http.c: Avoid username prompt for certifcate credentials
From: Rene Bredlau @ 2012-12-21 16:31 UTC (permalink / raw)
To: git; +Cc: peff, gitster, Rene Bredlau
If sslCertPasswordProtected is set to true do not ask for username to decrypt rsa key. This question is pointless, the key is only protected by a password. Internaly the username is simply set to "".
Signed-off-by: Rene Bredlau <git@unrelated.de>
---
http.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index 0a8abf3..44f3525 100644
--- a/http.c
+++ b/http.c
@@ -236,6 +236,7 @@ static int has_cert_password(void)
return 0;
if (!cert_auth.password) {
cert_auth.protocol = xstrdup("cert");
+ cert_auth.username = xstrdup("");
cert_auth.path = xstrdup(ssl_cert);
credential_fill(&cert_auth);
}
--
1.7.9
^ permalink raw reply related
* Re: recommendation for patch maintenance
From: Manlio Perillo @ 2012-12-21 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcbv1grr.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 21/12/2012 18:01, Junio C Hamano ha scritto:
> Manlio Perillo <manlio.perillo@gmail.com> writes:
>
>> I would like to have advices about some possible workflows to use when
>> maintaining a patch, that can evolve over the time (fixing bugs, and
>> applying advices from reviewers).
>>
> [...]
>> when I need to update the patch:
>>
>> 1) modify code
>> 2) commit --amend
>> 3) format-patch --subject-prefix="PATCH v<n>" \
>> --output=mp/complete-patch master
>> 4) edit patch to add a list of what was changed
>> 5) review the patch
>> 6) send-email
>>
>> This is far from ideal, since all my local changes are lost.
>
> Not offering any answer, but it is unclear to me what local changes
> you are losing here. Care to explain?
I lose the history of all the changes I have made to produce the final
version of a patch.
Since for every new version of a patch I do a commit --amend, I can not
see, as an example, the changes I have made between x and y versions of
a patch.
Of course the commits are not really lost, but I have to search them
using the reflog.
Thanks Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDUnIAACgkQscQJ24LbaUTf0QCfX9WtA+/GLzVWDJFPbLMCPucJ
bKQAnj0HJuQs9SVCPV/TlDXcpGDqIqfD
=lhZ5
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Junio C Hamano @ 2012-12-21 17:12 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6ibS7ORY=QMS3WQzXYJQQH4ZYvPO75qgLgv-oWGMSBBrw@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> I keep forgetting what "git diff A..B" does.
"diff" is always about two endpoints, not the path that connects
these two endpoints (aka "range"), and when you want to "diff"
between two commits, you say "diff A B". "A..B" happens to be
accepted as such only by accident (e.g. the old command line parser
did not have a reliable way to tell "^A B" and "A..B" apart), not by
design.
side note: incidentally, now we have rev_cmdline_info support,
we could start deprecating "diff A..B" syntax.
The special case "git checkout master...branch" is not about
specifying a range. The command knows it wants a single point (not
two endpoints, nor a range), and A...B as a notation to specify a
single point is $(merge-base A B).
> I would have much preferred if
> it was possible to make the revision parser generally interpret e.g.
> "A.^.B" as "the merge base of A and B" (failing if not exactly one).
Actually, in many places where the command line parser knows it
wants a single point, and never a range, we should be able to apply
the "A...B as a notation to specify a single point" rule.
Of course you could come up with a symbol other than "..." for that
purpose, and migrate the current "git checkout A...B" special case
to use that other symbol, but that would be more work and also you
would need to retrain existing users.
^ permalink raw reply
* Re: [PATCH] Documentation/git-clean: Document --force --force
From: Soren Brinkmann @ 2012-12-21 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Soren Brinkmann, git
In-Reply-To: <7vr4mk2jmy.fsf@alter.siamese.dyndns.org>
On Thu, Dec 20, 2012 at 07:01:41PM -0800, Junio C Hamano wrote:
> Soren Brinkmann <soren.brinkmann@xilinx.com> writes:
>
> > Ping?
>
> I *think* it is a mistake for the command to remove a separate
> project repository within, with any number of "-f", so I'd rather
> see a patch to fix it, instead of casting such a misbehaviour as a
> feature in stone by documenting it.
>
> I dunno.
Since I use this feature, I naturally have to disagree. But fair point. And with
the patch rectifying git-clean output it's probably tolerable.
Though, what would be your way of cleaning files/dirs from a repository where
git-clean will report to have some left undeleted? Manually calling rm -rf?
Soren
^ permalink raw reply
* Re: [PATCH] http.c: Avoid username prompt for certifcate credentials
From: Jeff King @ 2012-12-21 17:09 UTC (permalink / raw)
To: Rene Bredlau; +Cc: git, gitster
In-Reply-To: <1356107479-6668-1-git-send-email-git@unrelated.de>
On Fri, Dec 21, 2012 at 05:31:19PM +0100, Rene Bredlau wrote:
> If sslCertPasswordProtected is set to true do not ask for username to
> decrypt rsa key. This question is pointless, the key is only protected
> by a password. Internaly the username is simply set to "".
Yeah, that makes sense. I suspect the cert-unlocking code paths for
credential helpers are not that well used (and I do not think we have
any test coverage for them at all), so I am not too surprised that this
went unreported for a long time.
Thanks.
> Signed-off-by: Rene Bredlau <git@unrelated.de>
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: recommendation for patch maintenance
From: Junio C Hamano @ 2012-12-21 17:01 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50D475EF.6060303@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> I would like to have advices about some possible workflows to use when
> maintaining a patch, that can evolve over the time (fixing bugs, and
> applying advices from reviewers).
>
> In my case I have a single commit to maintain.
>
>
> The workflow I use now is this:
>
> 1) create a topic branch, e.g. mp/complete-path
> 2) write code
> 3) commit
> 4) format-patch --output=mp/complete-patch master
> 5) review the patch
> 6) send-email
>
> when I need to update the patch:
>
> 1) modify code
> 2) commit --amend
> 3) format-patch --subject-prefix="PATCH v<n>" \
> --output=mp/complete-patch master
> 4) edit patch to add a list of what was changed
> 5) review the patch
> 6) send-email
>
> This is far from ideal, since all my local changes are lost.
Not offering any answer, but it is unclear to me what local changes
you are losing here. Care to explain?
^ permalink raw reply
* Re: [PATCH v7 2/7] tests: paint known breakages in yellow
From: Stefano Lattarini @ 2012-12-21 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adam Spiers, Jeff King
In-Reply-To: <7vd2y32ys0.fsf@alter.siamese.dyndns.org>
On 12/21/2012 04:46 PM, Junio C Hamano wrote:
>
> [SNIP]
>
> The only thing the additional knowledge adds seems to be to give
> rationale for the old choice of "bold green"---it was not chosen
> from thin-air but can be viewed as following the automake/autotest
> scheme, and other systems cannot agree on what color to pick for
> this purpose.
>
> I do not see a need to justify why we chose differently from
> automake/autotest; we could say something like:
>
> Yellow seems a more appropriate color than bold green when
> considering the universal traffic lights coloring scheme, where
> green conveys the impression that everything's OK, and amber that
> something's not quite right. This is in line with what 'prove'
> uses, but different from 'automake/autotest' do.
>
> but we are not in the business of choosing which is more correct
> between prove and automake/autotest, and I do not see how it adds
> much value to tell readers that color choices are not universally
> agreed upon across various test software suites---that's kind of
> known, isn't it?
>
> So...
>
That is fine with me, I just pointed it out because I suspected not
everybody was aware of all these details. If you decide they don't
matter, it's perfectly OK -- but at least now it's an informed
choice ;-)
Thanks,
Stefano
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Junio C Hamano @ 2012-12-21 16:58 UTC (permalink / raw)
To: Michael J Gruber
Cc: Thomas Rast, Yann Dirson, Andreas Schwab, Christian Couder,
git list, Jeff King
In-Reply-To: <50D45A78.3020104@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> While replace refs are much more general than grafts, it seems the two
> main uses are:
>
> - grafts (change the recorded parents for a commit)
> - svn cleanup (convert tagging commits into tag objects)
>
> The latter one being quite a special case already.
>
> The script below has helped me move from grafts to replace objects.
> While not being super clean, something like it may be fit for contrib.
>
> I think we ought to help John Doe get along with parents, while we can
> safely leave most more advanced operations to people who know how to
> edit a raw object file. Putting that facility into "git-commit" seems to
> be too encouraging, though - people would use replace when they should
> use amend or rebase-i. I'd prefer a special git-replace mode (be it
> "--graft" or "--graft-commit") which does just what my script does. We
> could add things like "--commit-tag" later, a full blown
> "object-factory" seems like overkill.
>
> Michael
>
> --->%---
>
> #!/bin/sh
>
> die () {
> echo "$@"
> rm -f "$commitfile"
> exit 1
> }
>
> warn () {
> echo "$@"
> }
>
> test $# -gt 0 || die "Usage: $0 <commit> [<parent>]*"
>
> for commit
> do
> git rev-parse --verify -q "$commit" >/dev/null || die "Cannot parse
> $commit."
> test x$(git cat-file -t $commit) == "xcommit" || die "$commit is no
> commit."
s/==/=/ or you have to say #!/bin/bash on the first line, I think.
Appears multiple times throughout this script.
> done
>
> commit="$1"
> shift
>
> commitfile=$(mktemp)
>
> git cat-file commit "$commit" | while read a b
> do
> if test "$a" != "parent"
> then
> echo $a $b
You are losing information on non-header lines by reading without
"-r" in the above, and also multi-line headers (e.g. mergetag),
aren't you?
> fi
> if test "$a" == "tree"
> then
> for parent
> do
> echo "parent $(git rev-parse $parent)"
> done
> fi
> done >$commitfile
> hash=$(git hash-object -t commit -w "$commitfile") || die "Cannot create
> commit object."
> git replace "$commit" $hash
> rm -f $commitfile
^ permalink raw reply
* Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Martin von Zweigbergk @ 2012-12-21 16:55 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <CANiSa6jP_JN+DpDgYpWA9Aky9REJvFq3aR3Yj0vF3+axWvtmsw@mail.gmail.com>
Oops, meant for all of you.
---------- Forwarded message ----------
From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Fri, Dec 21, 2012 at 8:45 AM
Subject: Re: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
To: Junio C Hamano <gitster@pobox.com>
On Fri, Dec 21, 2012 at 7:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
> $ git checkout -B branch <old fork point>
>
> Unfortunately, master...branch syntax does not seem to work for
> specifying the "old fork point" for this purpose
I have personally always found it confusing to use the same syntax for
specifying ranges/sets and single revisions. I keep forgetting what
"git diff A..B" does. I know it doesn't do what I expect (i.e. "git
diff $(git merge-base A B) B"), but I don't know what it does (maybe
same as "git diff A B" (?), but that's besides the point). Having
worked a bit on rebase, I know that $onto can also take the "A...B"
form. So there is clearly some precedence for the "..." syntax to
refer to a revision in some contexts. I would have much preferred if
it was possible to make the revision parser generally interpret e.g.
"A.^.B" as "the merge base of A and B" (failing if not exactly one).
It seems like something that must have come up before. Is there a
particular reason this would not be a good idea?
^ permalink raw reply
* [PATCH v4] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2012-12-21 16:54 UTC (permalink / raw)
To: git; +Cc: szeder, felipe.contreras, Manlio Perillo
The git-completion.bash script did not implemented full, git aware,
support to complete paths, for git commands that operate on files within
the current working directory or the index.
As an example:
git add <TAB>
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Support path completion, for git commands where the non-option arguments
always refer to paths within the current working directory or the index,
as the follow:
* the path completion for the "git rm" and "git ls-files"
commands will suggest all cached files.
* the path completion for the "git add" command will suggest all
untracked and modified files. Ignored files are excluded.
* the path completion for the "git clean" command will suggest all
untracked files. Ignored files are excluded.
* the path completion for the "git mv" command will suggest all cached
files when expanding the first argument, and all untracked and cached
files for subsequent arguments. In the latter case, empty directories
are included and ignored files are excluded.
* the path completion for the "git commit" command will suggest all
files that have been modified from the HEAD, if HEAD exists, otherwise
it will suggest all cached files.
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---
Changes from version 3:
* Fixed quoting issues
* Fixed default parameters handling
* Fixed a typo in the commit message: the affected command was ls-files,
not ls-tree.
* Fixed incorrect behavior when expanding a path in "git commit"
command, for a newly created repository (when HEAD does not
exists).
* Make sure to always execute git commands with stderr redirected to
/dev/null.
* Improved path completion for the git mv command.
This required a small refactorization of the __git_index_files
function, in order to support multiple options for ls-files.
contrib/completion/git-completion.bash | 140 +++++++++++++++++++++++++++++----
1 file changed, 124 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..c8c6464 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
# *) .git/remotes file names
# *) git 'subcommands'
# *) tree paths within 'ref:path/to/file' expressions
+# *) file paths within current working directory and index
# *) common --long-options
#
# To use these routines:
@@ -233,6 +234,62 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
}
+# Process path list returned by "ls-files" and "diff-index --name-only"
+# commands, in order to list only file names relative to a specified
+# directory, and append a slash to directory names.
+# It accepts 1 optional argument: a directory path. The path must have
+# a trailing slash.
+__git_index_file_list_filter ()
+{
+ local pfx="${1-}" offset=${#pfx} path
+
+ while read -r path; do
+ path="${path:$offset}"
+
+ case "$path" in
+ ?*/*) echo "${path%%/*}/" ;;
+ *) echo $path ;;
+ esac
+ done
+}
+
+# __git_index_files accepts 1 or 2 arguments:
+# 1: Options to pass to ls-files (required).
+# Supported options are --cached, --modified, --deleted, --others,
+# and --directory.
+# 2: A directory path (optional).
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed. Path must have a trailing
+# slash.
+__git_index_files ()
+{
+ local dir="$(__gitdir)"
+
+ if [ -d "$dir" ]; then
+ # NOTE: $1 is not quoted in order to support multiple options
+ git --git-dir="$dir" ls-files --exclude-standard $1 ${2+"$2"} 2>/dev/null |
+ __git_index_file_list_filter ${2+"$2"} |
+ uniq
+ fi
+}
+
+# __git_diff_index_files accepts 1 or 2 arguments:
+# 1) The id of a tree object.
+# 2) A directory path (optional).
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed. Path must have a trailing
+# slash.
+__git_diff_index_files ()
+{
+ local dir="$(__gitdir)"
+
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" diff-index --name-only "$1" 2>/dev/null |
+ __git_index_file_list_filter ${2+"$2"} |
+ uniq
+ fi
+}
+
__git_heads ()
{
local dir="$(__gitdir)"
@@ -430,6 +487,46 @@ __git_complete_revlist_file ()
}
+# __git_complete_index_file requires 1 argument: the options to pass to
+# ls-file
+__git_complete_index_file ()
+{
+ local pfx cur_="$cur"
+
+ case "$cur_" in
+ ?*/*)
+ pfx="${cur_%/*}"
+ cur_="${cur_##*/}"
+ pfx="${pfx}/"
+
+ __gitcomp_nl "$(__git_index_files "$1" "$pfx")" "$pfx" "$cur_" ""
+ ;;
+ *)
+ __gitcomp_nl "$(__git_index_files "$1")" "" "$cur_" ""
+ ;;
+ esac
+}
+
+# __git_complete_diff_index_file requires 1 argument: the id of a tree
+# object
+__git_complete_diff_index_file ()
+{
+ local pfx cur_="$cur"
+
+ case "$cur_" in
+ ?*/*)
+ pfx="${cur_%/*}"
+ cur_="${cur_##*/}"
+ pfx="${pfx}/"
+
+ __gitcomp_nl "$(__git_diff_index_files "$1" "$pfx")" "$pfx" "$cur_" ""
+ ;;
+ *)
+ __gitcomp_nl "$(__git_diff_index_files "$1")" "" "$cur_" ""
+ ;;
+ esac
+}
+
__git_complete_file ()
{
__git_complete_revlist_file
@@ -770,8 +867,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "
@@ -780,7 +875,9 @@ _git_add ()
"
return
esac
- COMPREPLY=()
+
+ # XXX should we check for --update and --all options ?
+ __git_complete_index_file "--others --modified"
}
_git_archive ()
@@ -930,15 +1027,15 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--dry-run --quiet"
return
;;
esac
- COMPREPLY=()
+
+ # XXX should we check for -x option ?
+ __git_complete_index_file "--others"
}
_git_clone ()
@@ -969,8 +1066,6 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash && return
-
case "$cur" in
--cleanup=*)
__gitcomp "default strip verbatim whitespace
@@ -998,7 +1093,13 @@ _git_commit ()
"
return
esac
- COMPREPLY=()
+
+ if git rev-parse --verify --quiet HEAD 1>/dev/null; then
+ __git_complete_diff_index_file "HEAD"
+ else
+ # This is the first commit
+ __git_complete_index_file "--cached"
+ fi
}
_git_describe ()
@@ -1216,8 +1317,6 @@ _git_init ()
_git_ls_files ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --deleted --modified --others --ignored
@@ -1230,7 +1329,10 @@ _git_ls_files ()
return
;;
esac
- COMPREPLY=()
+
+ # XXX ignore options like --modified and always suggest all cached
+ # files.
+ __git_complete_index_file "--cached"
}
_git_ls_remote ()
@@ -1362,7 +1464,14 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+
+ if [ $cword -gt 2 ]; then
+ # We need to show both cached and untracked files (including
+ # empty directories) since this may not be the last argument.
+ __git_complete_index_file "--cached --others --directory"
+ else
+ __git_complete_index_file "--cached"
+ fi
}
_git_name_rev ()
@@ -2068,15 +2177,14 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
return
;;
esac
- COMPREPLY=()
+
+ __git_complete_index_file "--cached"
}
_git_shortlog ()
--
1.8.1.rc1.18.g9db0d25
^ permalink raw reply related
* Right way to import a repo
From: Florian Lindner @ 2012-12-21 16:11 UTC (permalink / raw)
To: git
Hello,
I have two repositories. tools and flof. I want to merge flof into tools (and
flof will be deleted after that) while keeping history intact. Of course I've
googled that and found a number of different solution which all seem to be
pretty komplex, so I just tried it myself. It seems to work.... are there any
problems with my approach?
~/software/tools.test (git)-[master] % git remote add fl ~/flof
~/software/tools.test (git)-[master] % git fetch fl
warning: no common commits
remote: Counting objects: 475, done.
remote: Compressing objects: 100% (460/460), done.
remote: Total 475 (delta 251), reused 0 (delta 0)
Receiving objects: 100% (475/475), 190.40 KiB, done.
Resolving deltas: 100% (251/251), done.
From /home/florian/flof
* [new branch] master -> fl/master
* [new branch] v2-rewrite -> fl/v2-rewrite
/software/tools.test (git)-[master] % git checkout -b import fl/master
Branch import set up to track remote branch master from fl.
Switched to a new branch 'import'
Doing some mkdir und git mv for reorganisation.
~/software/tools.test/flof (git)-[import] % git commit -m "Reorganize flof."
[import a00ab54] Reorganize flof.
152 files changed, 0 insertions(+), 0 deletions(-)
rename {doc => flof/doc}/common.rst (100%)
rename {doc => flof/doc}/conf.py (100%)
[...]
~/software/tools.test/flof (git)-[import] % git checkout master
Switched to branch 'master'
~/software/tools.test (git)-[master] % git merge import
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Automatic merge failed; fix conflicts and then commit the result.
Resolving the conflict.
~/software/tools.test (git)-[master|merge] % git add .gitignore
~/software/tools.test (git)-[master|merge] % git commit -m "Merged flof."
[master b8c85be] Merged flof.
~/software/tools.test (git)-[master] % git remote rm fl
Are thery any problems with this procedure? The history seems to intact. I'm
quite unsure since still being a git beginner.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH v2] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
From: Junio C Hamano @ 2012-12-21 16:08 UTC (permalink / raw)
To: David Aguilar; +Cc: Jeremy Morton, git
In-Reply-To: <1356073023-15376-1-git-send-email-davvid@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Use $TMPDIR when creating the /dev/null placeholder for p4merge.
> This keeps it out of the current directory.
The usual $REMOTE "this is theirs" and $LOCAL "this is ours" are
still created in the current directory, no? It is unclear why this
"this side does not exist" case wants to be outside of the current
directory in the first place.
In other words, "This keeps it out of the current directory" only
explains what this patch changes, without explaining why it is a
good thing to do in the first place.
> +create_empty_file () {
> + empty_file="${TMPDIR:-/tmp}/git-difftool-p4merge-empty-file.$$"
> + >"$empty_file"
> +
> + printf "$empty_file"
> +}
Assuming that it makes sense to create only the "this side doe not
exist, and here is a placeholder empty file" in $TMPDIR, I think
this is probably sufficient.
By the way, who is going to remove this temporary file once the
command is done?
^ permalink raw reply
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Manlio Perillo @ 2012-12-21 15:58 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121220141855.05DAA44105@snark.thyrsus.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 20/12/2012 15:13, Eric S. Raymond ha scritto:
> Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
> ---
Just my two cents.
Isn't it better to have some core Python support inside a "python/"
directory in the git source tree (e.g. e simple python/git.py), and have
*all* python code import that module?
Then you can impose a reasonable version limitation (e.g. Python >= 2.5)
inside that module (and/or inside its setup.py file).
Another advantage is that the python/git.py module can contain some very
base support for interfacing git plumbing commands, instead of having
all internal (and external) modules reinventing the wheel.
I'm writing an external command for Git, and I do plan to write such a
package, so that I don't have to reimplement all the base support in my
command source code.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDUhzoACgkQscQJ24LbaUQFuQCfb6QgkJHdxQSEB7nLXMN8TSmI
6/IAn3svylllaIBQfZKf0lEzNBtZJQMK
=Ar20
-----END PGP SIGNATURE-----
^ permalink raw reply
* [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Junio C Hamano @ 2012-12-21 15:58 UTC (permalink / raw)
To: git
When you want to redo a branch forked from another branch (say
'master'), a handy way to work is to first detach HEAD at the
previous fork point:
$ git checkout master...branch
and build an updated history on top of this state. Once you are
done, you can verify your results with commands like:
$ git show-branch branch HEAD
$ git diff branch HEAD
and then finish it off with:
$ git checkout -B branch
This way, you can keep the history of the previous round on 'branch'
until you are done with the new history you build on the detached
HEAD state, and if you do not like updated history, you can reset
back to branch@{1} easily.
But you may not even need to have such an easy access to the old
history and just want to restart, with:
$ git checkout -B branch <old fork point>
Unfortunately, master...branch syntax does not seem to work for
specifying the "old fork point" for this purpose, even though we
have special case to support the syntax in the "detach at that
commit" case (the first command line example in this message).
Perhaps we should teach the <start-point> parser this syntax as
well?
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Matthieu Moy @ 2012-12-21 15:49 UTC (permalink / raw)
To: Yngve Nysaeter Pettersen; +Cc: Michael J Gruber, git
In-Reply-To: <op.wpn9d6xuvqd7e2@damia.oslo.osa>
"Yngve Nysaeter Pettersen" <yngve@opera.com> writes:
> The split command will create a new repository for all files foo in a
> folder (path/foo) and their commit history.
>
> The replant command reverses that process, re-adding the path prefix
> for each file. It may be possible to extend that process into one that
> automatically reintegrates the new commits in the original history,
> but I never had time to complete that work.
>
> I did originally add the "replant" functionality into my version of
> the git-subtree script, but given the number of commits in the
> original repository, git-subtree turned out to be inefficient, due to
> the use of temporary files (tens of thousands of files IIRC).
>
> Those problems led to my development of git-splitter in Python
> (bypassing the problem of temporary files), but just including the
> functionality I needed, join was not one of those functions.
That still doesn't answer the question: why did you need to write a new
tool instead of extending git-subtree?
If one doesn't use "replant", is your tool different from git-subtree?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v7 2/7] tests: paint known breakages in yellow
From: Junio C Hamano @ 2012-12-21 15:46 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git, Adam Spiers, Jeff King
In-Reply-To: <50D4230F.9080502@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> On 12/21/2012 04:12 AM, Junio C Hamano wrote:
>> From: Adam Spiers <git@adamspiers.org>
>>
>> Yellow seems a more appropriate color than bold green when
>> considering the universal traffic lights coloring scheme, where
>> green conveys the impression that everything's OK, and amber that
>> something's not quite right.
>>
> Here are few more details about the behaviour of other testing
> tools, in case you want to squash them in the commit message for
> future references:
>
> 1. Automake (at least up to 1.13) and Autotest (at least up to the
> 2.69 Autoconf release) use "bold" green for reporting expected
> failures.
>
> 2. On the other hand, the 'prove' utility (as of TAP::Harness v3.23
> and Perl v5.14.2) use yellow (not bold) for the same purpose.
Nice to know, thanks.
I re-read the above three times, trying to see how to add it to the
log message, but having hard time phrasing it.
The only thing the additional knowledge adds seems to be to give
rationale for the old choice of "bold green"---it was not chosen
from thin-air but can be viewed as following the automake/autotest
scheme, and other systems cannot agree on what color to pick for
this purpose.
I do not see a need to justify why we chose differently from
automake/autotest; we could say something like:
Yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right. This is in line with what 'prove'
uses, but different from 'automake/autotest' do.
but we are not in the business of choosing which is more correct
between prove and automake/autotest, and I do not see how it adds
much value to tell readers that color choices are not universally
agreed upon across various test software suites---that's kind of
known, isn't it?
So...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox