* Re: Weird problem with git-submodule.sh
From: Phil Hord @ 2012-12-12 19:10 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: Junio C Hamano, Marc Branchaud, Git Mailing List
In-Reply-To: <50C4FD00.4010003@gmail.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to
> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.
Dash has been the default '/bin/sh' for Ubuntu for quite a long time
now[1] in spite of repeated reports of compatibility problems[2].
Phil
[1] https://wiki.ubuntu.com/DashAsBinSh
[2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481
^ permalink raw reply
* Re: [RFC/PATCH] ignoring a fetch that overwrites local symref
From: Shawn Pearce @ 2012-12-12 19:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jay Soffian, Stefan Zager
In-Reply-To: <7v62488j8a.fsf_-_@alter.siamese.dyndns.org>
On Tue, Dec 11, 2012 at 11:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> This is a companion to an ancient thread
>
> http://thread.gmane.org/gmane.comp.version-control.git/145311/focus=145337
>
> in which an error was dealt with while pushing into a "mirror"
> repository that has a symbolic reference refs/remotes/origin/HEAD
> pointing at refs/remotes/origin/master with "git push --mirror".
> The issue was that the receiving end was told to update origin/HEAD
> and origin/master separately; if origin/HEAD is updated, that would
> update origin/master at the same time, and then when attempting to
> update origin/master, it would notice that it no longer has the
> expected old value and barf. After the series, we started ignoring
> such pushes to HEAD on the receiving end.
>
> But you can suffer from a similar issue transferring objects in the
> opposite direction. If you run "fetch --mirror" in to such a
> "mirror" repository, the other side would advertise both 'master'
> and 'HEAD' under refs/remotes/origin/ hierarchy, and refs/*:refs/*
> wildcard would try to grab both of them.
>
> Work it around by noticing a wildcard match that attempts to update
> a local symbolic ref and ignoring it.
At what point should we just support symrefs on the protocol? :-(
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Kevin @ 2012-12-12 19:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcc73yzh.fsf@alter.siamese.dyndns.org>
Yeah, I didn't mention it, but I didn't think it was doing this wrong
in a systematic way. I only wondered if there was some kind of
heuristic that could improve the cases where it goes wrong, without
affecting the cases where it would do it right.
I know this is not an easy problem, lest it would already been fixed.
On Wed, Dec 12, 2012 at 7:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Kevin <ikke@ikke.info> writes:
>
>> Regularly I notice that the diffs that are provided (through diff, or
>> add -p) tend to disconnect changes that belong to each other and
>> report lines being changed that are not changed.
>>
>> An example for this is:
>>
>> /**
>> + * Default parent
>> + *
>> + * @var int
>> + * @access protected
>> + * @index
>> + */
>> + protected $defaultParent;
>> +
>> + /**
>>
>> I understand this is a valid view of what is changed, but not a very
>> logical view from the point of the user.
>>
>> I wondered if there is a way to improve this, or would that have other
>> consequences.
>
> I think your example shows a case where the end of the pre-context
> matches the end of the added text in the hunk, and it appears it may
> produce a better result if you shift the hunk up. But I think that
> works only half the time. Imagine:
>
> @@ -K,L +M,N @@
> }
>
> +void new_function(void)
> +{
> + printf("hello, world.\n");
> +}
> +
> void existing_one(void)
> {
> printf("goodbye, world.\n");
>
> Here the end of the pre-context matches the end of the added lines,
> but it will produce worse result if you blindly apply the "shift the
> hunk up" trick:
>
> ... what was before the } we saw in the precontext ...
> +}
> +
> +void new_function(void)
> +{
> + printf("hello, world.\n");
> }
>
> void existing_one(void)
>
> So I think with s/Regularly/About half the time/, your observation
> above is correct.
>
> I think the reason you perceived this as "Regularly" is that you do
> not notice nor appreciate it when things go right (half the time),
> but you tend to notice and remember only when a wrong side happened
> to have been picked (the other half).
^ permalink raw reply
* Re: [PATCH v2] submodule: add 'deinit' command
From: Junio C Hamano @ 2012-12-12 19:32 UTC (permalink / raw)
To: Jens Lehmann
Cc: Michael J Gruber, Phil Hord, W. Trevor King, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <50C8BD6B.9010702@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Especially as I suspect the number of submodule users having
> customized those in .git/config is not that high ...
I thought the point of "deinit" was to say "I am not interested in
having a checkout of these submodules in my working tree anymore".
The user could do "rm -fr submodule && mkdir submodule" to remove it
locally and keep "diff" and "status" from noticing the removal, but
the primary reason the user needs an explicit "deinit" is because
many subcommands of "git submodule" are documented to operate on all
submodules that have been "init"ed when given no explicit submodule
names [*1*].
Your "deinit" is documented not to actually remove the submodule
checkout, but that very much goes against my intuition. What is the
justification behind that choice? "We'll remove the configuration,
you remove the tree yourself" will invite the mistake of running
"git rm" on it, which you wanted to avoid with the addition to the
"git rm" documentation, no?
[Footnote]
*1* In reality, the code looks at presense of .git in the submodule
path to decide if it has been "init"ed (cf. cmd_update), but this
implementation of "deinit" does not seem to cause that .git to be
removed, leaving the submodule in "init"ed state from these other
command's perspective.
^ permalink raw reply
* Re: [PATCH] Documentation/git: add missing info about --git-dir command-line option
From: Junio C Hamano @ 2012-12-12 19:35 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50C8B92F.8020408@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> The Documentation/git.txt file, in the GIT_DIR environment variable
> section, did not mentioned that this value can also be set using the
> --git-dir command line option.
> ---
s/mentioned/mention/; Also it may help to say
Unlike other environment variables (e.g. GIT_WORK_TREE,
GIT_NAMESPACE),
somewhere in the description.
Please sign-off your patch (see Documentation/SubmittingPatches).
Thanks.
> Documentation/git.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index e643683..60db292 100644
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -650,6 +650,7 @@ git so take care if using Cogito etc.
> If the 'GIT_DIR' environment variable is set then it
> specifies a path to use instead of the default `.git`
> for the base of the repository.
> + The '--git-dir' command-line option also sets this value.
> 'GIT_WORK_TREE'::
> Set the path to the working tree. The value will not be
^ permalink raw reply
* Re: [RFC/PATCH] ignoring a fetch that overwrites local symref
From: Junio C Hamano @ 2012-12-12 19:38 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Jay Soffian, Stefan Zager
In-Reply-To: <CAJo=hJu2X5u4oCGRVHK5a4sbf4X2meUbq_8kaGiQB1mdQspaXw@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
>> Work it around by noticing a wildcard match that attempts to update
>> a local symbolic ref and ignoring it.
>
> At what point should we just support symrefs on the protocol? :-(
I think it is entirely an orthogonal matter. When we learn that the
other side now has this ref as a symref pointing to this other ref,
an update of the local ref on the RHS of the refspec that has such a
symref on its LHS will not be using the current codepath to call
update_ref() to write the object name thru an existing symref.
^ permalink raw reply
* Re: Weird problem with git-submodule.sh
From: Junio C Hamano @ 2012-12-12 19:44 UTC (permalink / raw)
To: Phil Hord; +Cc: Stefano Lattarini, Marc Branchaud, Git Mailing List
In-Reply-To: <CABURp0oc_g3T3n0A4on=n8443sTFR6SKf1xcgN2EAFcx9eU_Ng@mail.gmail.com>
Phil Hord <phil.hord@gmail.com> writes:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to
>> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.
>
> Dash has been the default '/bin/sh' for Ubuntu for quite a long time
> now[1] in spite of repeated reports of compatibility problems[2].
Wasn't the ancestry more like BSD ash (buggy) came before dash and
Marc is running a BSD ash decendant that shared common ancestor
with, not a decendant of, dash?
In any case, I do not think that is relevant; does does not seem to
have this IFS bug.
> [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481
None of the ones listed seems to me a bug. Rather, I see it as a
sign that the reporter does not know POSIX shell well and only
learned his/her shell through bash.
^ permalink raw reply
* Re: [PATCH v7 2/3] submodule update: add --remote for submodule's upstream changes
From: Junio C Hamano @ 2012-12-12 19:54 UTC (permalink / raw)
To: Phil Hord
Cc: W. Trevor King, Git, Heiko Voigt, Jeff King, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <CABURp0oLmSjiZAOJxEzwSmL+jimpVj8DcDi-odPTzCpCcyH8yA@mail.gmail.com>
Phil Hord <phil.hord@gmail.com> writes:
>> + if test -n "$remote"
>> + then
>> + if test -z "$nofetch"
>> + then
>> + # Fetch remote before determining tracking $sha1
>> + (clear_local_git_env; cd "$sm_path" && git-fetch) ||
>
> You should 'git fetch $remote_name' here, and of course, initialize
> remote_name before this. But how can we know the remote_name in the
> first place? Is it safe to assume the submodule remote names will
> match those in the superproject?
>
>> + die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
>> + fi
>> + remote_name=$(get_default_remote)
>
> This get_default_remote finds the remote for the remote-tracking
> branch for HEAD in the superproject. It is possible that HEAD !=
> $branch, so we have very few clues to go on here to get a more
> reasonable answer, so I do not have any good suggestions to improve
> this.
>
> One option would be to find the remote given for
> submodule."$branch".merge, but this would suppose there is some
> remote-tracking branch configured in the submodule, and that is not
> likely to be the case.
>
>> + sha1=$(clear_local_git_env; cd "$sm_path" &&
>> + git rev-parse --verify "${remote_name}/${branch}") ||
>
> This does assume the submodule remote names will match those in the
> superproject. Is this safe?
All good points. Thanks for reviewing.
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Junio C Hamano @ 2012-12-12 19:57 UTC (permalink / raw)
To: Yann Dirson; +Cc: git list
In-Reply-To: <20121212094432.6e1e48c8@chalon.bertin.fr>
Yann Dirson <dirson@bertin.fr> writes:
> .... In this respect, they seem to be
> lacking a few features, when compared to "replace" refs, but they have different
> uses, ...
Not reallyl; grafts were old hack whose use is still supported with
its original limitations; replace is meant to replace all uses of
grafts while removing grafts' largest warts.
^ permalink raw reply
* Re: [PATCH] RFC Optionally handle symbolic links as copies
From: Junio C Hamano @ 2012-12-12 20:22 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Michael J Gruber, git
In-Reply-To: <1141725649.20938344.1355328914240.JavaMail.root@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> I want the copy on checkout. The intent is to change things and
> then commit.
That largely depends on what purpose each symlink is used for in the
project.
Suppose you have a symlink A and another symlink X in the project,
where A points at another path B inside the working tree, and X
points at a path outside, say, /etc/motd. Upon checkout, you make
regular files A and X that store the contents of the files they
point at, and then you edit A and X.
Now, what should happen on the next "git add A X"?
* Perhaps it (or any step before "git add", or something even
outside git) should notice that you modified A that is supposed
to represent a copy of B but their contents have drifted. It
should raise a red flag, or take a remedial action, no?
* Perhaps it should copy the updated contents in A to B and run
"git add" on that one instead, without changing anything else?
* Imagine a project with many template files B, C, ..., where A
points at "the default template". You may be designating a
different template file as the new default. On a symlink-capable
system you would just do "rm -f A && ln -s C A", but because you
chose to make a copy of B and store it as a regular file in A, a
natural way to update it may be to do "cp C A".
Would you find another file C in the working tree that may be
different from B that has the same contents as A, and update the
symbolic link A to point at C instead? Do so only with the
contents of A and all the other files in the working tree? What
if there is another template file identical to C?
I didn't even touched the cases where you have to deal with your
updates to X.
This is looking more and more outside the scope of Git to me.
^ permalink raw reply
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Simon Oosthoek @ 2012-12-12 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Piotr Krukowiecki, git
In-Reply-To: <7vlid35fe4.fsf@alter.siamese.dyndns.org>
On 12/12/12 18:50, Junio C Hamano wrote:
> Simon Oosthoek <s.oosthoek@xs4all.nl> writes:
>
>> This removes most of the ambiguities :-)
>> Ack from me!
>
> OK, as this is a low-impact finishing touch for a new feature, I'll
> fast-track this to 'master' before the final release.
>
Ok, wonderful!
BTW, I tried the thing I mentioned and it was safe to do:
PS1='blabla$(__git_ps1 x y)blabla'
will not eat your prompt, although I'd recommend putting something
useful instead of blabla ;-)
Cheers
Simon
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Junio C Hamano @ 2012-12-12 20:29 UTC (permalink / raw)
To: Kevin; +Cc: git
In-Reply-To: <7vvcc73yzh.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Kevin <ikke@ikke.info> writes:
>
>> Regularly I notice that the diffs that are provided (through diff, or
>> add -p) tend to disconnect changes that belong to each other and
>> report lines being changed that are not changed.
>>
>> An example for this is:
>>
>> /**
>> + * Default parent
>> + *
>> + * @var int
>> + * @access protected
>> + * @index
>> + */
>> + protected $defaultParent;
>> +
>> + /**
>>
>> I understand this is a valid view of what is changed, but not a very
>> logical view from the point of the user.
>>
>> I wondered if there is a way to improve this, or would that have other
>> consequences.
I forgot to mention consequences. Changing it obviously changes the
shape of the diff, hence changes the patch id. Anything that caches
output from "git cherry" to match up "identical patches" will need
to discard and repopulate its cache. Your "rerere" database will go
stale.
Also "kup" tool used at k.org allows an uploader to pretend to
upload an incremental diff between two known commits by only sending
the GPG signature of the diff the uploader generates. The actual
diff is generated on the k.org machine locally and deposited next to
the GPG signature file, with the expectation that the signture
matches the diff. Changing the output from diff between two
versions will break the optimization and force the uploader to
upload the diff over the wire.
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Morten Welinder @ 2012-12-12 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin, git
In-Reply-To: <7vvcc73yzh.fsf@alter.siamese.dyndns.org>
> So I think with s/Regularly/About half the time/, your observation
> above is correct.
>
> I think the reason you perceived this as "Regularly" is that you do
> not notice nor appreciate it when things go right (half the time),
> but you tend to notice and remember only when a wrong side happened
> to have been picked (the other half).
Is there a reason why picking among the choices in a sliding window
must be contents neutral?
I see these "illogical" (== stylistically not matching user intent) diffs
quite often. C comments (as in the example given) and #ifdef blocks
are typical cases.
Purely anecdotically, I have seen more trouble applying "illogical"
diffs than I would have expected from the corresponding "logical" diffs.
Morten
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Junio C Hamano @ 2012-12-12 21:53 UTC (permalink / raw)
To: Morten Welinder; +Cc: Kevin, git
In-Reply-To: <CANv4PNm45xGBn2veKi1o0wB4K9NgsbtCsiymHNO4xbCDpJ5tDg@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
> Is there a reason why picking among the choices in a sliding window
> must be contents neutral?
Sorry, you might be getting at something interesting but I do not
understand the question. I have no idea what you mean by "contents
neutral".
Picking between these two choices
/** + /**
+ * Default parent + * Default parent
+ * + *
+ * @var int + * @var int
+ * @access protected + * @access protected
+ * @index + * @index
+ */ + */
+ protected $defaultParent; + protected $defaultParent;
+ +
+ /** /**
would not affect the correctness of the patch. You may pick
whatever you deem the most desirable, but your answer must be a
correct patch (the definition of "correct" here is "applying that
patch to the preimage produces the intended postimage").
And I think if you inserted a block of text B after a context C
where the tail of B matches the tail of C like the above, you can
shift what you treat as "inserted" up and still come up with a
correct patch.
The output being "a correct patch" is not the only thing we need to
consider, though, as I mentioned in another response to Kevin
regarding the "consequences".
^ permalink raw reply
* Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Felipe Contreras @ 2012-12-12 22:14 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <1354057407-83151-2-git-send-email-max@quendi.de>
On Tue, Nov 27, 2012 at 5:03 PM, Max Horn <max@quendi.de> wrote:
> index 5ce4cda..9a7e583 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https',
> 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
> 'fetch', 'option', and 'push'.
>
> +INVOCATION
> +----------
> +
> +Remote helper programs are invoked with one or (optionally) two
> +arguments. The first argument specifies a remote repository as in git;
> +it is either the name of a configured remote or a URL. The second
> +argument specifies a URL; it is usually of the form
> +'<transport>://<address>', but any arbitrary string is possible.
> +The 'GIT_DIR' environment variable is set up for the remote helper
> +and can be used to determine where to store additional data or from
> +which directory to invoke auxiliary git commands.
> +
> +When git encounters a URL of the form '<transport>://<address>', where
> +'<transport>' is a protocol that it cannot handle natively, it
> +automatically invokes 'git remote-<transport>' with the full URL as
> +the second argument. If such a URL is encountered directly on the
> +command line, the first argument is the same as the second, and if it
> +is encountered in a configured remote, the first argument is the name
> +of that remote.
Maybe it's worth mentioning that if the alias of the remote is not
specified, the URL is used instead.
> +A URL of the form '<transport>::<address>' explicitly instructs git to
> +invoke 'git remote-<transport>' with '<address>' as the second
> +argument. If such a URL is encountered directly on the command line,
> +the first argument is '<address>', and if it is encountered in a
> +configured remote, the first argument is the name of that remote.
> +
> +Additionally, when a configured remote has 'remote.<name>.vcs' set to
> +'<transport>', git explicitly invokes 'git remote-<transport>' with
> +'<name>' as the first argument. If set, the second argument is
> +'remote.<name>.url'; otherwise, the second argument is omitted.
I find all this text a bit confusing. First argument, second argument,
etc. Personally, I would describe everything in the terms of alias
(1st arg), and URL (2nd arg).
--
Felipe Contreras
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Andrew Ardill @ 2012-12-12 22:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Eric S. Raymond, Sitaram Chamarty, Patrick Donnelly,
Nguyen Thai Ngoc Duy, Michael Haggerty, Felipe Contreras,
git@vger.kernel.org
In-Reply-To: <7vpq2f5ffu.fsf@alter.siamese.dyndns.org>
On 13 December 2012 04:49, Junio C Hamano <gitster@pobox.com> wrote:
> "bisect" with "<used-to-be, now-is> vs
> <good, bad>" issue unsettled
Would you want to see this issue resolved in-script before a porting
attempt was started?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH 0/6] Improve remote helper documentation
From: Felipe Contreras @ 2012-12-12 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Max Horn, git, Sverre Rabbelier, Florian Achleitner
In-Reply-To: <7v1uf1he6m.fsf@alter.siamese.dyndns.org>
On Fri, Dec 7, 2012 at 1:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Max Horn <max@quendi.de> writes:
>
>> Various remote helper capabilities and commands were not
>> documented, in particular 'export', or documented in a misleading
>> way (e.g. 'for-push' was listed as a ref attribute understood by
>> git, which is not the case). This patch series changes that, and
>> also address some other things in the remote helper documentation
>> that I found jarring when reading through it.
>>
>> Note that the description of export and (im|ex)port-marks probably can be
>> improved, and I hope that somebody who knows more about them
>> than me and/or is better at writing documentation will do just that.
>> But I felt it was better to provide something than to do nothing
>> and only complain, as I did previously on this subject ;-).
>
> A second ping to people who have touched transport-helper.c,
> remote-testsvn.c, git-remote-testgit, and contrib/remote-helpers/ in
> the past 18 months for comments. I've re-read the documentation
> updates myself and didn't find anything majorly objectionable.
>
> Except for a minor nit in 6/6; I think "defined options" should be
> "defined attributes".
I think the wording in 1/6 can be improved. Other than that I don't
have any comments, what I'm familiar with looks good to me.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2] submodule: add 'deinit' command
From: Jens Lehmann @ 2012-12-12 22:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael J Gruber, Phil Hord, W. Trevor King, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <7vr4mv3w2x.fsf@alter.siamese.dyndns.org>
Am 12.12.2012 20:32, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Especially as I suspect the number of submodule users having
>> customized those in .git/config is not that high ...
>
> I thought the point of "deinit" was to say "I am not interested in
> having a checkout of these submodules in my working tree anymore".
Yes. (But I'm not sure users expect that command to also remove
the work tree)
> The user could do "rm -fr submodule && mkdir submodule" to remove it
> locally and keep "diff" and "status" from noticing the removal, but
> the primary reason the user needs an explicit "deinit" is because
> many subcommands of "git submodule" are documented to operate on all
> submodules that have been "init"ed when given no explicit submodule
> names [*1*].
The real reason we need deinit is that the next run of "submodule
update" will otherwise happily recreate the submodule checkout you
just removed as long as it finds the url setting in .git/config.
> Your "deinit" is documented not to actually remove the submodule
> checkout, but that very much goes against my intuition. What is the
> justification behind that choice?
I thought it should match what "submodule init" does, which is to do
nothing to the work tree until the next "submodule update" is run.
(But I agree that analogy is somewhat flawed until we teach "update"
to remove a deinitialized submodule - or maybe teach it the --deinit
option which could do both). On the other hand with current git
submodule work trees always stay around anyway until you remove them
by hand (e.g. when you switch to a branch that doesn't have it), so
I'm not sure what would surprise people more here. So I just left
the work tree unchanged.
> "We'll remove the configuration,
> you remove the tree yourself" will invite the mistake of running
> "git rm" on it, which you wanted to avoid with the addition to the
> "git rm" documentation, no?
I think that'll happen only if git would remind them that they
still have a populated work tree, which I believe it shouldn't.
> [Footnote]
>
> *1* In reality, the code looks at presense of .git in the submodule
> path to decide if it has been "init"ed (cf. cmd_update), but this
> implementation of "deinit" does not seem to cause that .git to be
> removed, leaving the submodule in "init"ed state from these other
> command's perspective.
Nope, cmd_update() checks first if the url is found in .git/config
and skips the submodule if not. I rechecked and only "summary" and
"foreach" still recurse into a deinitialized submodule, which they
shouldn't. But a quick test shows that "git status" and "git diff"
also still inspect a deinitialized submodule, so there's some work
left to do to handle the case where the work tree is not removed.
So unless people agree that deinit should also remove the work
tree I'll prepare some patches teaching all git commands to
consistently ignore deinitialized submodules. Opinions?
^ permalink raw reply
* Re: [PATCH] completion: add option --recurse-submodules to "git push"
From: Felipe Contreras @ 2012-12-12 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Jaeckel, git, Heiko Voigt
In-Reply-To: <7vehj1ixr6.fsf@alter.siamese.dyndns.org>
On Fri, Dec 7, 2012 at 11:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Steffen Jaeckel <steffen.jaeckel@stzedn.de> writes:
>
>> Signed-off-by: Steffen Jaeckel <steffen.jaeckel@stzedn.de>
>> ---
>> contrib/completion/git-completion.bash | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index 0b77eb1..5b4d2e1 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1434,6 +1434,10 @@ _git_pull ()
>> __git_complete_remote_or_refspec
>> }
>>
>> +__git_push_recurse_submodules_options="
>> + check on-demand
>> +"
>
> Most of the existing completion functions do not seem to define
> separate variables like this; instead, they literally embed their
> choices at the point of use.
>
> Is it expected that the same set of choices will appear in the
> completion of many other subcommand options? [jc: Cc'ed Heiko so
> that we can sanity check the answer to this question]. If so, the
> variable may be justified; otherwise, not.
>
>> _git_push ()
>> {
>> case "$prev" in
>> @@ -1446,10 +1450,15 @@ _git_push ()
>> __gitcomp_nl "$(__git_remotes)" "" "${cur##--repo=}"
>> return
>> ;;
>> + --recurse-submodules=*)
>> + __gitcomp "$__git_push_recurse_submodules_options" "" "${cur##--recurse-submodules=}"
>> + return
>> + ;;
>
> Owners of the completion script, does this look reasonable?
> [jc: Cc'ed Felipe for this]
>
> This is a tangent, but why is it a double-hash "##" not a
> single-hash "#", other than "because all others use ##"?
Seems OK by me, but I agree, the options should be inline.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2] If `egrep` is aliased, temporary disable it in bash.completion
From: Felipe Contreras @ 2012-12-12 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Tkac, git, SZEDER Gábor
In-Reply-To: <7v4njzjbzo.fsf@alter.siamese.dyndns.org>
On Thu, Dec 6, 2012 at 12:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Adam Tkac <atkac@redhat.com> writes:
>
>> On Thu, Nov 29, 2012 at 09:33:53AM -0800, Junio C Hamano wrote:
>> ...
>>> IOW, something along this line?
>>
>> This won't work, unfortunately, because shopt settings aren't inherited by
>> subshell (and for example egrep is called in subshell).
>>
>> I discussed this issue with colleagues and we found basically two "fixes":
>>
>> 1. Tell people "do not use aliases which breaks completion script"
>> 2. Prefix all commands with "command", i.e. `command egrep` etc.
>>
>> In my opinion "2." is better long time solution, what do you think?
>
> Judging from what is in /etc/bash_completion.d/ (I am on Debian), I
> think that others are divided. Many but not all prefix "command" in
> front of "grep", but nobody does the same for "egrep", "cut", "tr",
> "sed", etc.
>
> If it were up to me, I would say we pick #1, but I cc'ed the people
> who have been more involved in our bash-completion code because they
> are in a better position to argue between the two than I am.
Why not both? I do prefer #1, but I don't see why we wouldn't prefix
some commonly problematic ones (\egrep), prefixing all of them seems
overkill for me.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2] submodule: add 'deinit' command
From: Junio C Hamano @ 2012-12-12 22:34 UTC (permalink / raw)
To: Jens Lehmann
Cc: Michael J Gruber, Phil Hord, W. Trevor King, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <50C90469.8080303@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> So unless people agree that deinit should also remove the work
> tree I'll prepare some patches teaching all git commands to
> consistently ignore deinitialized submodules. Opinions?
While I agree that consistency is good, "deinit" that does not
remove the working tree of the submodule the user explicitly said he
no longer wants to have the checkout for is a bug, and I think these
two are orthogonal issues.
In other words, "Ignore deinitialized submodules even when an
earlier bug in deinit failed to remove the working tree" is a
robustness issue for the other recursing commands, not an excuse for
"deinit" to have such a bug in the first place, I think.
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Andrew Ardill @ 2012-12-12 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, Kevin, git
In-Reply-To: <7vpq2f2az4.fsf@alter.siamese.dyndns.org>
On 13 December 2012 08:53, Junio C Hamano <gitster@pobox.com> wrote:
> The output being "a correct patch" is not the only thing we need to
> consider, though, as I mentioned in another response to Kevin
> regarding the "consequences".
The main benefit of picking a more 'natural' diff is a usability one.
I know that when a chunk begins and ends one line after the logical
break point (typically with braces in my experience) mentally parsing
the diff becomes significantly harder. If there was a way to teach git
where it should try and break out a chunk (potentially per filetype?)
this is a good thing for readability, and I think would outweigh any
temporary pain with regards to cached rerere and diff data.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Junio C Hamano @ 2012-12-12 22:43 UTC (permalink / raw)
To: Andrew Ardill
Cc: Jeff King, Eric S. Raymond, Sitaram Chamarty, Patrick Donnelly,
Nguyen Thai Ngoc Duy, Michael Haggerty, Felipe Contreras,
git@vger.kernel.org
In-Reply-To: <CAH5451nVqnS0UFBVDW5=Xmaj_6geiw7D7J4mR7922U+074W2qQ@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> On 13 December 2012 04:49, Junio C Hamano <gitster@pobox.com> wrote:
>> "bisect" with "<used-to-be, now-is> vs
>> <good, bad>" issue unsettled
>
> Would you want to see this issue resolved in-script before a porting
> attempt was started?
Honestly, I do not care too much either way, but for the people who
want to work either on the rewrite-to-C or on the semantics issue,
it would be easier to manage it that way.
And that "issue resolved in-script" does not have to be "implemented
in-script". The resolution could be to declare that it is not worth
it and a promise to call the two states <good, bad> and with no
other names. It would give a semantics for the rewriters-to-C can
start working on that is stable enough ;-).
^ permalink raw reply
* Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-12 22:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <7vzk1j3zgr.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
On Wed, Dec 12, 2012 at 10:19:32AM -0800, Junio C Hamano wrote:
> In any case, I ended up applying them by editing the patches, and I
> should have a good copy in 'pu'. Please double check the result.
Your 'pu' branch looks good to me. Most of the differences with my
initial patch are due to irrelevant context lines. I would change
patch 3 (commit 2f507f9a in 'pu') to use
git config -f .gitmodules submodule."$sm_name".branch "$branch"
^
instead of
git config -f .gitmodules submodule."$sm_path".branch "$branch"
^
to match the nearby changes from 73b0898d.
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Max Horn @ 2012-12-12 22:58 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3vO9b4-XxqatEc2w3KJLqLGgyjPuKpQkAXHQwTJJEQTg@mail.gmail.com>
On 12.12.2012, at 23:14, Felipe Contreras wrote:
> On Tue, Nov 27, 2012 at 5:03 PM, Max Horn <max@quendi.de> wrote:
>
>> index 5ce4cda..9a7e583 100644
>> --- a/Documentation/git-remote-helpers.txt
>> +++ b/Documentation/git-remote-helpers.txt
>> @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https',
>> 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
>> 'fetch', 'option', and 'push'.
>>
>> +INVOCATION
>> +----------
>> +
>> +Remote helper programs are invoked with one or (optionally) two
>> +arguments. The first argument specifies a remote repository as in git;
>> +it is either the name of a configured remote or a URL. The second
>> +argument specifies a URL; it is usually of the form
>> +'<transport>://<address>', but any arbitrary string is possible.
>> +The 'GIT_DIR' environment variable is set up for the remote helper
>> +and can be used to determine where to store additional data or from
>> +which directory to invoke auxiliary git commands.
>> +
>> +When git encounters a URL of the form '<transport>://<address>', where
>> +'<transport>' is a protocol that it cannot handle natively, it
>> +automatically invokes 'git remote-<transport>' with the full URL as
>> +the second argument. If such a URL is encountered directly on the
>> +command line, the first argument is the same as the second, and if it
>> +is encountered in a configured remote, the first argument is the name
>> +of that remote.
>
> Maybe it's worth mentioning that if the alias of the remote is not
> specified, the URL is used instead.
Worth a thought yeah -- but beyond the scope of this patch: I merely moved this text around, but did not touch it otherwise.
>
>> +A URL of the form '<transport>::<address>' explicitly instructs git to
>> +invoke 'git remote-<transport>' with '<address>' as the second
>> +argument. If such a URL is encountered directly on the command line,
>> +the first argument is '<address>', and if it is encountered in a
>> +configured remote, the first argument is the name of that remote.
>> +
>> +Additionally, when a configured remote has 'remote.<name>.vcs' set to
>> +'<transport>', git explicitly invokes 'git remote-<transport>' with
>> +'<name>' as the first argument. If set, the second argument is
>> +'remote.<name>.url'; otherwise, the second argument is omitted.
>
> I find all this text a bit confusing. First argument, second argument,
> etc. Personally, I would describe everything in the terms of alias
> (1st arg), and URL (2nd arg).
Yeah, I also thought about that, but as above, deliberately did not touch it here, but only moved it around. I'll be happy to revisit this on a future date, though.
Thanks for the feedback,
Max
^ 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