* 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: [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: [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 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: 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: [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: [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: [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: 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: [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: 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: Fwd: possible Improving diff algoritm
From: Brian J. Murrell @ 2012-12-12 18:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin, git
In-Reply-To: <7vvcc73yzh.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On 12-12-12 01:29 PM, Junio C Hamano wrote:
>
> 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:
Yeah. I would not think a blind shift would be appropriate. But I
wonder if diff can take whitespace hints about when to shift and when
not to.
It would still never be perfect but might be more accurate than it is
now. Can't imagine it would be any worse.
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Junio C Hamano @ 2012-12-12 18:29 UTC (permalink / raw)
To: Kevin; +Cc: git
In-Reply-To: <CAO54GHD3C2RKUvE5jK_XOCVbbDuE_c5xfe28rOL+DaE5anL-Wg@mail.gmail.com>
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 v7 0/3] submodule update: add --remote for submodule's upstream changes
From: Junio C Hamano @ 2012-12-12 18:19 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121212152437.GB5157@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Tue, Dec 11, 2012 at 09:42:48PM -0800, Junio C Hamano wrote:
>> What branch did you base this series on?
>
> Every version of this series has been based on v1.8.0.
Thanks.
There were quite a few changes to git-submodule.sh since then to
'master' and I had to either wiggle the patch or know which exact
one 1/3 needs to be applied to in order to allow 2/3 to apply (try
applying these three to 'master' yourself---you will likely to see
that 2/3 will stop with conflicts).
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.
Thanks.
^ permalink raw reply
* Re: [PATCH] index-format.txt: be more liberal on what can represent invalid cache tree
From: Junio C Hamano @ 2012-12-12 18:14 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1355316276-7661-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> We have been writing -1 as "invalid" since day 1. On that same day we
> accept all negative entry counts as "invalid". So in theory all C Git
> versions out there would be happy to accept any negative numbers. JGit
> seems to do exactly the same.
I am of two minds here.
The existing code is being more lenient than specified when they
read stuff others wrote, but it still adheres to -1 when writing.
Allowing random implementations to write random negative values will
close the door for us to later update the specification to encode
more informatin about these invalid entries by using negative value
other than -1 here.
I am OK with a reword to say "negative means invalid, and writers
should write -1 for invalid entries", but without the latter half,
this change is not justified.
> diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt
> index 9d25b30..2028a49 100644
> --- a/Documentation/technical/index-format.txt
> +++ b/Documentation/technical/index-format.txt
> @@ -161,8 +161,8 @@ GIT index format
> this span of index as a tree.
>
> An entry can be in an invalidated state and is represented by having
> - -1 in the entry_count field. In this case, there is no object name
> - and the next entry starts immediately after the newline.
> + a negative number in the entry_count field. In this case, there is no
> + object name and the next entry starts immediately after the newline.
>
> The entries are written out in the top-down, depth-first order. The
> first entry represents the root level of the repository, followed by the
^ permalink raw reply
* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Junio C Hamano @ 2012-12-12 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20121212122448.GA20057@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I find the ohloh one a little more informative than the GitHub graph. I
> couldn't find any others (Google Code does not seem to have one,
> kernel.org and other gitweb sites do not, and I can't think of anywhere
> else that hosts a mirror).
Then let's do this.
-- >8 --
Subject: git(1): show link to contributor summary page
We earlier removed a link to list of contributors that pointed to a
defunct page; let's use a working one from Ohloh.net to replace it
instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git c/Documentation/git.txt w/Documentation/git.txt
index e643683..25e2f3a 100644
--- c/Documentation/git.txt
+++ w/Documentation/git.txt
@@ -869,7 +869,10 @@ Authors
-------
Git was started by Linus Torvalds, and is currently maintained by Junio
C Hamano. Numerous contributions have come from the git mailing list
-<git@vger.kernel.org>. If you have a clone of git.git itself, the
+<git@vger.kernel.org>. http://www.ohloh.net/p/git/contributors/summary
+gives you a more complete list of contributors.
+
+If you have a clone of git.git itself, the
output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you
the authors for specific parts of the project.
^ permalink raw reply related
* Re: [PATCH 0/2] mailmap from blobs
From: Jeff King @ 2012-12-12 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhanr5f74.fsf@alter.siamese.dyndns.org>
On Wed, Dec 12, 2012 at 09:54:23AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I noticed recently that the GitHub contributions page for git.git did
> > not seem very accurate. The problem is that while it uses shortlog, it
> > does not respect .mailmap, because we do not have a working tree from
> > which to read the .mailmap.
> >
> > This series adds a config option analogous to mailmap.file, but which
> > reads from a blob in the repository (so the obvious thing to set it to
> > is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you
> > frequently want to traverse while on unrelated branches). The obvious
> > alternative is to checkout a temporary file of .mailmap and point
> > mailmap.file at it, but this is a bit more convenient.
>
> Yeah, I think this is sane.
>
> Have you considered defaulting to read from HEAD:.mailmap even when
> this new configuration is not there if core.bare is set? I would
> imagine that it would be the most convenient and match people's
> expectations.
Yeah, I almost suggested that, but I figured it could wait for the
feature to prove itself in the real world before turning it on by
default. It _should_ be pretty harmless, though, so I don't mind turning
it on by default.
-Peff
^ permalink raw reply
* Re: [PATCH 5/5] log: Add --use-mailmap option
From: Junio C Hamano @ 2012-12-12 17:58 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git, Rich Midwinter
In-Reply-To: <CALWbr2xmRVS9m623yrxY88Ftaen_B8Tb2vd+VxhYV1ceAmbDSg@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> On Tue, Dec 11, 2012 at 11:21 PM, Antoine Pelisse <apelisse@gmail.com> wrote:
>> Add the --use-mailmap option to log commands. It allows
>> to display names from mailmap file when displaying logs,
>> whatever the format used.
>
> The question is which log commands actually ?
> Shouldn't we put the option in revision.c::handle_revision_opt instead ?
I was trying to avoid that to make it harder to trigger the
"feature" by mistake. The rewriting with mailmap is for human
consumption and when we replay the history (e.g. format-patch used
as input for am or rebase), we should never be applying it.
^ permalink raw reply
* Re: [PATCH 0/2] mailmap from blobs
From: Junio C Hamano @ 2012-12-12 17:54 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121212105822.GA15842@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I noticed recently that the GitHub contributions page for git.git did
> not seem very accurate. The problem is that while it uses shortlog, it
> does not respect .mailmap, because we do not have a working tree from
> which to read the .mailmap.
>
> This series adds a config option analogous to mailmap.file, but which
> reads from a blob in the repository (so the obvious thing to set it to
> is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you
> frequently want to traverse while on unrelated branches). The obvious
> alternative is to checkout a temporary file of .mailmap and point
> mailmap.file at it, but this is a bit more convenient.
Yeah, I think this is sane.
Have you considered defaulting to read from HEAD:.mailmap even when
this new configuration is not there if core.bare is set? I would
imagine that it would be the most convenient and match people's
expectations.
^ permalink raw reply
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Junio C Hamano @ 2012-12-12 17:50 UTC (permalink / raw)
To: Simon Oosthoek; +Cc: Piotr Krukowiecki, git
In-Reply-To: <20121212085507.GA32187@xs4all.nl>
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.
Thanks.
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Junio C Hamano @ 2012-12-12 17:49 UTC (permalink / raw)
To: Jeff King
Cc: Eric S. Raymond, Sitaram Chamarty, Patrick Donnelly,
Nguyen Thai Ngoc Duy, Michael Haggerty, Felipe Contreras, git
In-Reply-To: <20121212063208.GA18322@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think there are really two separate use cases to consider:
>
> 1. Providing snippets of script to Git to get Turing-complete behavior
> for existing Git features. For example, selecting commits during a
> traversal (e.g., a better "log --grep"), formatting output (e.g., a
> better "log --format" or "for-each-ref --format").
>
> 2. Writing whole new git commands in a language that is quicker or
> easier to develop in than C.
>
> I think (1) is a good match for lua....
>
> But for (2), you are going to care a lot more about the language and its
> ecosystem (because you'll be interacting more with the world outside of
> git), and about having bindings to lots of different parts of git
> (because you'll want to do more interesting things than just examine a
> few data structures).
Good summary. We also need to realize that adding a native
subcommand written in C has become much easier over time as our
internal API has evolved and matured. These days, we still do a
whole new command in scripts (and we have whole commands still in
scripts) not because "quicker or easier to develop" (that is still
true for throw-away experiments) but primarily because that is
easier to modify and experiment over time until we find a solid
design.
Among the more important subcommands that are still scripts, I think
"add -i", "repack", "pull", "stash" and possibly "rebase" have
interfaces facing to both the end users and to the core part
solidified enough that they can now be ported to C. Others either
are not important enough or still have rooms to improve the
interfaces in either direction that it would still be better to
leave them in scripts (e.g. "bisect" with "<used-to-be, now-is> vs
<good, bad>" issue unsettled, "submodule" with "floating" issue
unsettled, etc.).
^ permalink raw reply
* Re: [PATCH v7 2/3] submodule update: add --remote for submodule's upstream changes
From: Phil Hord @ 2012-12-12 17:43 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Junio C Hamano, Heiko Voigt, Jeff King, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <64d109da03c521303ad87b8370bf09ab28a5c09f.1355251862.git.wking@tremily.us>
Thanks for looking after this.
On Tue, Dec 11, 2012 at 1:58 PM, W. Trevor King <wking@tremily.us> wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> The current `update` command incorporates the superproject's gitlinked
> SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
> options you use, it may checkout $sha1, rebase the $subsha1 onto
> $sha1, or merge $sha1 into $subsha1. This helps you keep up with
> changes in the upstream superproject.
>
> However, it's also useful to stay up to date with changes in the
> upstream subproject. Previous workflows for incorporating such
> changes include the ungainly:
>
> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> With this patch, all of the useful functionality for incorporating
> superproject changes can be reused to incorporate upstream subproject
> updates. When you specify --remote, the target $sha1 is replaced with
> a $sha1 of the submodule's origin/master tracking branch. If you want
> to merge a different tracking branch, you can configure the
> `submodule.<name>.branch` option in `.gitmodules`. You can override
> the `.gitmodules` configuration setting for a particular superproject
> by configuring the option in that superproject's default configuration
> (using the usual configuration hierarchy, e.g. `.git/config`,
> `~/.gitconfig`, etc.).
>
> Previous use of submodule.<name>.branch
> =======================================
>
> Because we're adding a new configuration option, it's a good idea to
> check if anyone else is already using the option. The foreach-pull
> example above was described by Ævar in
>
> commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
> Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Date: Fri May 21 16:10:10 2010 +0000
>
> git-submodule foreach: Add $toplevel variable
>
> Gerrit uses the same interpretation for the setting, but because
> Gerrit has direct access to the subproject repositories, it updates
> the superproject repositories automatically when a subproject changes.
> Gerrit also accepts the special value '.', which it expands into the
> superproject's branch name.
>
> Although the --remote functionality is using `submodule.<name>.branch`
> slightly differently, the effect is the same. The foreach-pull
> example uses the option to record the name of the local branch to
> checkout before pulls. The tracking branch to be pulled is recorded
> in `.git/modules/<name>/config`, which was initialized by the module
> clone during `submodule add` or `submodule init`. Because the branch
> name stored in `submodule.<name>.branch` was likely the same as the
> branch name used during the initial `submodule add`, the same branch
> will be pulled in each workflow.
>
> Implementation details
> ======================
>
> In order to ensure a current tracking branch state, `update --remote`
> fetches the submodule's remote repository before calculating the
> SHA-1. However, I didn't change the logic guarding the existing fetch:
>
> if test -z "$nofetch"
> then
> # Run fetch only if $sha1 isn't present or it
> # is not reachable from a ref.
> (clear_local_git_env; cd "$path" &&
> ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> test -z "$rev") || git-fetch)) ||
> die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
> fi
>
> There will not be a double-fetch, because the new $sha1 determined
> after the `--remote` triggered fetch should always exist in the
> repository. If it doesn't, it's because some racy process removed it
> from the submodule's repository and we *should* be re-fetching.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/config.txt | 7 ++++++-
> Documentation/git-submodule.txt | 25 ++++++++++++++++++++++++-
> Documentation/gitmodules.txt | 5 +++++
> git-submodule.sh | 22 +++++++++++++++++++++-
> t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++
> 5 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 11f320b..6f4663c 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1998,7 +1998,12 @@ submodule.<name>.update::
> for a submodule. These variables are initially populated
> by 'git submodule init'; edit them to override the
> URL and other values found in the `.gitmodules` file. See
> - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
> +
> +submodule.<name>.branch::
> + The remote branch name for a submodule, used by `git submodule
> + update --remote`. Set this option to override the value found in
> + the `.gitmodules` file. See linkgit:git-submodule[1] and
> + linkgit:gitmodules[5] for details.
>
> submodule.<name>.fetchRecurseSubmodules::
> This option can be used to control recursive fetching of this
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b4683bb..72dd52f 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,7 +13,7 @@ SYNOPSIS
> [--reference <repository>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> +'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase]
> [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
> [commit] [--] [<path>...]
> @@ -236,6 +236,29 @@ OPTIONS
> (the default). This limit only applies to modified submodules. The
> size is always limited to 1 for added/deleted/typechanged submodules.
>
> +--remote::
> + This option is only valid for the update command. Instead of using
> + the superproject's recorded SHA-1 to update the submodule, use the
> + status of the submodule's remote tracking branch. The remote used
> + is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
> + The remote branch used defaults to `master`, but the branch name may
> + be overridden by setting the `submodule.<name>.branch` option in
> + either `.gitmodules` or `.git/config` (with `.git/config` taking
> + precedence).
> ++
> +This works for any of the supported update procedures (`--checkout`,
> +`--rebase`, etc.). The only change is the source of the target SHA-1.
> +For example, `submodule update --remote --merge` will merge upstream
> +submodule changes into the submodules, while `submodule update
> +--merge` will merge superproject gitlink changes into the submodules.
> ++
> +In order to ensure a current tracking branch state, `update --remote`
> +fetches the submodule's remote repository before calculating the
> +SHA-1. This makes `submodule update --remote --merge` similar to
> +running `git pull` in the submodule. If you don't want to fetch (for
> +something closer to `git merge`), you should use `submodule update
> +--remote --no-fetch --merge`.
I assume the same can be said for 'submodue update --remote --rebase',
right? I wonder if this can be made merge/rebase-agnostic. Is it
still true if I word it like this?:
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. If you don't want to fetch, you should use `submodule update
--remote --no-fetch`.
> +
> -N::
> --no-fetch::
> This option is only valid for the update command.
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index 4effd78..4004fa6 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -47,6 +47,11 @@ submodule.<name>.update::
> This config option is overridden if 'git submodule update' is given
> the '--merge', '--rebase' or '--checkout' options.
>
> +submodule.<name>.branch::
> + A remote branch name for tracking updates in the upstream submodule.
> + If the option is not specified, it defaults to 'master'. See the
> + `--remote` documentation in linkgit:git-submodule[1] for details.
> +
> submodule.<name>.fetchRecurseSubmodules::
> This option can be used to control recursive fetching of this
> submodule. If this option is also present in the submodules entry in
> diff --git a/git-submodule.sh b/git-submodule.sh
> index f969f28..1395079 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -8,7 +8,8 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
> USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] init [--] [<path>...]
> - or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> + or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> +ges
I think there's an unintentionally added line here with "ges".
> or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
> or: $dashless [--quiet] foreach [--recursive] <command>
> or: $dashless [--quiet] sync [--] [<path>...]"
> @@ -26,6 +27,7 @@ cached=
> recursive=
> init=
> files=
> +remote=
> nofetch=
> update=
> prefix=
> @@ -535,6 +537,9 @@ cmd_update()
> -i|--init)
> init=1
> ;;
> + --remote)
> + remote=1
> + ;;
> -N|--no-fetch)
> nofetch=1
> ;;
> @@ -595,6 +600,7 @@ cmd_update()
> fi
> name=$(module_name "$sm_path") || exit
> url=$(git config submodule."$name".url)
> + branch=$(get_submodule_config "$name" branch master)
> if ! test -z "$update"
> then
> update_module=$update
> @@ -629,6 +635,20 @@ Maybe you want to use 'update --init'?")"
> die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
> fi
>
> + 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?
> + die "$(eval_gettext "Unable to find current ${remote_name}/${branch} revision in submodule path '\$sm_path'")"
> + fi
> +
> if test "$subsha1" != "$sha1" -o -n "$force"
> then
> subforce=$force
> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
> index 1542653..a567834 100755
> --- a/t/t7406-submodule-update.sh
> +++ b/t/t7406-submodule-update.sh
> @@ -135,6 +135,37 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '
> )
> '
>
> +test_expect_success 'submodule update --remote should fetch upstream changes' '
> + (cd submodule &&
> + echo line4 >> file &&
> + git add file &&
> + test_tick &&
> + git commit -m "upstream line4"
> + ) &&
> + (cd super &&
> + git submodule update --remote --force submodule &&
> + cd submodule &&
> + test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline)"
> + )
> +'
> +
> +test_expect_success 'local config should override .gitmodules branch' '
> + (cd submodule &&
> + git checkout -b test-branch &&
> + echo line5 >> file &&
> + git add file &&
> + test_tick &&
> + git commit -m "upstream line5" &&
> + git checkout master
> + ) &&
> + (cd super &&
> + git config submodule.submodule.branch test-branch &&
> + git submodule update --remote --force submodule &&
> + cd submodule &&
> + test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)"
> + )
> +'
> +
> test_expect_success 'submodule update --rebase staying on master' '
> (cd super/submodule &&
> git checkout master
> --
> 1.8.0
>
^ permalink raw reply
* FW: Git log --graph doesn't output color when redirected
From: Srb, Michal @ 2012-12-12 17:35 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <72BB37CB88C48F4B925365539F1EE46C182613A9@icexch-m3.ic.ac.uk>
Unlike --pretty-format, --graph doesn’t output colors when the git log output
is redirected.
Tested on Ubuntu 12.04 and msys on Windows 8.
Is there a setting somewhere in config to change this?
Thanks,
Michal
^ permalink raw reply
* RE: (bug?) Inconsistent workdir file timestamps after initial clone.
From: Pyeron, Jason J CTR (US) @ 2012-12-12 17:26 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <50C8BC71.8030204@web.de>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
> -----Original Message-----
> From: Torsten Bögershausen
> Sent: Wednesday, December 12, 2012 12:19 PM
>
>
>
> On 11.12.12 23:30, Junio C Hamano wrote:
> > Marc Branchaud <marcnarc@xiplink.com> writes:
> >
> >> My point is that the initial checkout into an empty working
> directory should
> >> create all files with the same timestamp.
> >>
> >> Or, to be a bit more precise, whenever git-checkout *creates* files
> in the
> >> work dir, *all* the created files should have the *same* timestamp
> (i.e. the
> >> current time measured at the start of the checkout's execution, not
> some
> >> bizarro other time specified by some arcane heuristic).
> >
> > My knee-jerk reaction is that it is insane to do so, but what other
> > SCM does such a thing? Even "tar xf" wouldn't do that, I think.
> >
>
>
> ClearCase is doing such a thing.
>
> You need to check out a file to make it writable:
> "cleartool checkout main.c"
> [hack hack]
> If you after some hacking don't like your changes at all,
> you run
> "cleartool unco main.c" (Undo checkout)
> (In git we just use "git checkout")
>
> While in ClearCase the timestamp of your file jumps back to where
> it was before the checkout, it gets the current timestamp in git.
I do think that a user preference should decide if git uses metadata timestamps or current timestamp on file operations. I don’t think that the current time is proper as a default operation.
>
> One consequence is that ClearCase users may wish to use "ClearMake"
> rather then make.
>
> A better make (which records all timestamps somewhere) would be
> helpful.
That is why I always do "make clean" after a rollback. Do you really expect build managers to handle a bi-directional, with regards to time, SDLC? Build managers have worked hard to ensure incremental builds, it is silly to think that they should be re worked.
>
> >>> While not including files that can be rebuilt from the source may
> be
> >>> the ideal solution, I've seen projects hide rules to rebuild such a
> >>> "generated but needs special tools to build" and/or a "generated
> but
> >>> normal developers do not have any business rebuilding" file (in
> your
> >>> case, Makefile.in) in their Makefiles from the normal targets (like
> >>> "make all") for this exact reason, when they choose to distribute
> >>> such files by including in their commits.
> >>
> >> I prefer to use the third-party code as-is, without hacking it, to
> have
> >> smooth upgrades in the future.
> >
> > Then perhaps take the complaints to that third-party upstream, not
> > here?
> > --
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: [PATCH v2] submodule: add 'deinit' command
From: Jens Lehmann @ 2012-12-12 17:22 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Phil Hord, W. Trevor King, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <50C89DF3.20303@drmicha.warpmail.net>
Am 12.12.2012 16:08, schrieb Michael J Gruber:
> Jens Lehmann venit, vidit, dixit 04.12.2012 22:48:
>> With "git submodule init" the user is able to tell git he cares about one
>> or more submodules and wants to have it populated on the next call to "git
>> submodule update". But currently there is no easy way he could tell git he
>> does not care about a submodule anymore and wants to get rid of his local
>> work tree (except he knows a lot about submodule internals and removes the
>> "submodule.$name.url" setting from .git/config himself).
>>
>> Help those users by providing a 'deinit' command. This removes the whole
>> submodule.<name> section from .git/config either for the given
>> submodule(s) or for all those which have been initialized if none were
>> given. Complain only when for a submodule given on the command line the
>> url setting can't be found in .git/config.
>
> Whoaaa, so why not have "git rm" remove everything unless I specify a
> file to be removed?
Because "git add" doesn't add any file in that case either?
> I know I'm exaggerating a bit, but defaulting to "--all" for a
> destructive operation seems to be a bit harsh, especially when the
> command is targeted at "those" users that you mention.
All other submodule commands (except add, which only operates on a
single submodule to be) iterate over all submodules if none were
explicitly given on the command line. So I made deinit just behave
like all the others - and especially init - do. But if people really
are surprised by being consistent here I won't argue against adding
such a "--all" option, but currently I'm not convinced it is worth
it. Especially as I suspect the number of submodule users having
customized those in .git/config is not that high ...
^ 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