* 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
* Re: (bug?) Inconsistent workdir file timestamps after initial clone.
From: Torsten Bögershausen @ 2012-12-12 17:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Branchaud, Git Mailing List
In-Reply-To: <7vr4mw6x3p.fsf@alter.siamese.dyndns.org>
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.
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.
>>> 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
>
^ permalink raw reply
* Re: [PATCH] fetch: ignore wildcarded refspecs that update local symbolic refs
From: Jay Soffian @ 2012-12-12 17:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O . Pearce, Stefan Zager
In-Reply-To: <7vmwxk6x0a.fsf_-_@alter.siamese.dyndns.org>
On Tue, Dec 11, 2012 at 5:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> In a repository cloned from somewhere else, you typically have a
> [...]
> * This time with minimal tests and an updated log message.
Sorry I haven't been reading the list much lately, so I don't know the
context which motivated this patch beyond the commit message. But,
this message is quite clear. So:
Acked-by: Jay Soffian
> diff --git a/remote.c b/remote.c
> index 04fd9ea..a72748c 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1370,6 +1370,16 @@ int branch_merge_matches(struct branch *branch,
> return refname_match(branch->merge[i]->src, refname, ref_fetch_rules);
> }
>
> +static int ignore_symref_update(const char *refname)
s/ignore_symref_update/is_existing_symref/ ?
j.
^ permalink raw reply
* [PATCH] Documentation/git: add missing info about --git-dir command-line option
From: Manlio Perillo @ 2012-12-12 17:04 UTC (permalink / raw)
To: git
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.
---
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
--
1.8.0.1.347.gf94c325.dirty
^ permalink raw reply related
* Re: How to avoid the ^M induced by Meld and Git
From: Karl Brand @ 2012-12-12 16:17 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50C8AC0A.1010306@drmicha.warpmail.net>
On 12/12/12 17:08, Michael J Gruber wrote:
> Karl Brand venit, vidit, dixit 12.12.2012 16:34:
>>
>>
>> On 12/12/12 15:57, Michael J Gruber wrote:
>>> Karl Brand venit, vidit, dixit 11.12.2012 13:33:
>>>> Esteemed Git users,
>>>>
>>>> What i do:
>>>>
>>>> 1. Create a script.r using Emacs/ESS.
>>>> 2. Make some modifications to script.r with the nice diff gui, Meld
>>>> 3. Commit these modifications using git commit -am "my message"
>>>> 4. Reopen script.r in Emacs/ESS to continue working.
>>>>
>>>> The lines added (&/edited ?) using Meld all end with ^M which i
>>>> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
>>>
>>> What happens if you leave out step 3? If the same happens then Meld is
>>> the culprit. (Unless you've set some special options, git does not
>>> modify your file on commit, so this can't be git related.)
>>>
>>
>> Leaving out step 3. results in exactly the same thing. Thus Git doesn't
>> appear to be responsible for the ^M's. Thanks a lot for your effort on
>> this and my apologies for not taking the care to dissect this more
>> carefully as you suggested. Over to the Meld mailing list...
>
> I didn't mean to shy you away ;)
Applying recent lessons form StackO'flow :P
>
> Could it be that there is a ^M very early in the file (or rather
> something else which isn't covered by dos2unix) so that Meld thinks it's
> DOS and inserts line endings as DOS? At least that's what vim would do.
>
If there is i don't find it using Emacs, but Emacs may only show what
dos2unix sees... Will post back the Meld insights (here's hoping!)
> In any case, Meld people over there should know (or get to know) that
> effect.
>
>>>> There are plenty of posts around about these being line endings used for
>>>> windows which can appear when working on a script under a *nix OS which
>>>> has previously been edited in a Windows OS. This is not the case here -
>>>> everything is taking place on Ubuntu 12.04.
>>>>
>>>> FWIW: the directory is being synced by dropbox; and in Meld, Preferences
>>>> > Encoding tab, "utf8" is entered in the text box.
>>>>
>>>> Current work around is running in a terminal: dos2unix /path/to/script.r
>>>> which strips the ^M's
>>>>
>>>> But this just shouldn't be necessary and I'd really appreciate the
>>>> reflections & advice on how to stop inducing these ^M's !
>>>>
>>>> With thanks,
>>>>
>>>> Karl
>>>>
>>>> (re)posted here as suggested off topic at SO:
>>>> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
>>>>
>>>
>>
--
Karl Brand
Dept of Cardiology and Dept of Bioinformatics
Erasmus MC
Dr Molewaterplein 50
3015 GE Rotterdam
T +31 (0)10 703 2460 |M +31 (0)642 777 268 |F +31 (0)10 704 4161
^ permalink raw reply
* Re: [PATCH] RFC Optionally handle symbolic links as copies
From: Robin Rosenberg @ 2012-12-12 16:15 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <50C89822.9050900@drmicha.warpmail.net>
----- Ursprungligt meddelande -----
> Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23:
> >
> >
> > ----- Ursprungligt meddelande -----
> >> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> >>
> >>> If core.symlinks is set to copy then symbolic links in a git
> >>> repository
> >>> will be checked out as copies of the file it points to.
> >>
> >> That all sounds nice on surface when the primary thing you care
> >> about is to fetch and check out other people's code and extract it
> >> to the working tree, but how well would that work on the checkin
> >> side? What happens if I check out a symlink that points at a file
> >> (either in-tree or out-of-tree), make some changes that do not
> >> involve the symlink, and before I make the commit, an unrelated
> >> change is made to the file the symlink is pointing at?
> >>
> >>> - git status - when do we report a diff.
> >>> - After checkout we should probably not
> >>> - if the "linked" files change?
> >>
> >> Yeah, exactly.
> >>
> >>> - if a change in the copied directory chsnges
> >>
> >> That, too.
> >>
> >>> - if a file in the copied diretory is added/removed
> >>> - update, should we update the copied structure automatically
> >>> when the link target changes
> >
> > Some of the questions have proposals in the includes test script. A
> > little more dangerous than having real symlinks ofcourse, but
> > regardless
> > of what one does with or without copied symlinks one can make
> > mistakes
> > and I feel letting Git do the copying is way better than having
> > real
> > copies in the git repository. Another crappy scm which the users
> > are
> > converting from does this and it works. A difference to git is that
> > it (ok clearcase) makes all files read-only so there are fewer mays
> > of making mistakes with the copies.
> >
> >> I personally do not think this is worth it. It would be very
> >> useful
> >> on the export/checkout side, so it may make sense to add it to
> >> "git
> >> archive", though.
> >
> > It makes sense, but it does not solve the problem at hand.
> >
> > -- robin
> >
>
> Well, what is the problem at hand?
The problem is that I'm converting a repo from clearcase to git and
there are lots of symbolic links. Symbolic links in clearcase on
Windows is treated as file copy in snapshot views which means that
you get a copy of the linked file when you update the view. If the
link target changes you can update your view to refersh your copies.
> Your commit message begins in present tense as if it described the
> current state of git, when in fact it describes what the patch is
> about
> to achieve. This is confusing enough already,
You're right.
> I don't see any mention of the purpose, other than "content may be
> used", which would be served perfectly by a copy-on-link feature on
> the
> export side, as mentioned by Junio. Is git-archive|tar an option?
I want the copy on checkout. The intent is to change things and
then commit.
Perhaps I can convince people to let a script copy stuff instead.
-- robin
^ permalink raw reply
* Re: How to avoid the ^M induced by Meld and Git
From: Michael J Gruber @ 2012-12-12 16:08 UTC (permalink / raw)
To: Karl Brand; +Cc: git
In-Reply-To: <50C8A403.9050304@erasmusmc.nl>
Karl Brand venit, vidit, dixit 12.12.2012 16:34:
>
>
> On 12/12/12 15:57, Michael J Gruber wrote:
>> Karl Brand venit, vidit, dixit 11.12.2012 13:33:
>>> Esteemed Git users,
>>>
>>> What i do:
>>>
>>> 1. Create a script.r using Emacs/ESS.
>>> 2. Make some modifications to script.r with the nice diff gui, Meld
>>> 3. Commit these modifications using git commit -am "my message"
>>> 4. Reopen script.r in Emacs/ESS to continue working.
>>>
>>> The lines added (&/edited ?) using Meld all end with ^M which i
>>> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
>>
>> What happens if you leave out step 3? If the same happens then Meld is
>> the culprit. (Unless you've set some special options, git does not
>> modify your file on commit, so this can't be git related.)
>>
>
> Leaving out step 3. results in exactly the same thing. Thus Git doesn't
> appear to be responsible for the ^M's. Thanks a lot for your effort on
> this and my apologies for not taking the care to dissect this more
> carefully as you suggested. Over to the Meld mailing list...
I didn't mean to shy you away ;)
Could it be that there is a ^M very early in the file (or rather
something else which isn't covered by dos2unix) so that Meld thinks it's
DOS and inserts line endings as DOS? At least that's what vim would do.
In any case, Meld people over there should know (or get to know) that
effect.
>>> There are plenty of posts around about these being line endings used for
>>> windows which can appear when working on a script under a *nix OS which
>>> has previously been edited in a Windows OS. This is not the case here -
>>> everything is taking place on Ubuntu 12.04.
>>>
>>> FWIW: the directory is being synced by dropbox; and in Meld, Preferences
>>> > Encoding tab, "utf8" is entered in the text box.
>>>
>>> Current work around is running in a terminal: dos2unix /path/to/script.r
>>> which strips the ^M's
>>>
>>> But this just shouldn't be necessary and I'd really appreciate the
>>> reflections & advice on how to stop inducing these ^M's !
>>>
>>> With thanks,
>>>
>>> Karl
>>>
>>> (re)posted here as suggested off topic at SO:
>>> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
>>>
>>
>
^ permalink raw reply
* Re: (bug?) Inconsistent workdir file timestamps after initial clone.
From: Marc Branchaud @ 2012-12-12 15:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vr4mw6x3p.fsf@alter.siamese.dyndns.org>
On 12-12-11 05:30 PM, 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?
I'm lucky enough to just care about git these days.
> Even "tar xf" wouldn't do that, I think.
"tar xf" uses the timestamps that are stored in the tar file. I see this as
an argument against git's exact-current-time-per-file approach: even the tar
guys understand that it's insane.
>>> 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?
Well, I thought that while I wait for some dozen-or-so projects to accept
changes to their builds, it might be nice for git to solve this problem for
me. It is, after all, an effect of the way git operates.
M.
^ permalink raw reply
* Re: How to avoid the ^M induced by Meld and Git
From: Karl Brand @ 2012-12-12 15:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50C89B68.8090309@drmicha.warpmail.net>
On 12/12/12 15:57, Michael J Gruber wrote:
> Karl Brand venit, vidit, dixit 11.12.2012 13:33:
>> Esteemed Git users,
>>
>> What i do:
>>
>> 1. Create a script.r using Emacs/ESS.
>> 2. Make some modifications to script.r with the nice diff gui, Meld
>> 3. Commit these modifications using git commit -am "my message"
>> 4. Reopen script.r in Emacs/ESS to continue working.
>>
>> The lines added (&/edited ?) using Meld all end with ^M which i
>> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
>
> What happens if you leave out step 3? If the same happens then Meld is
> the culprit. (Unless you've set some special options, git does not
> modify your file on commit, so this can't be git related.)
>
Leaving out step 3. results in exactly the same thing. Thus Git doesn't
appear to be responsible for the ^M's. Thanks a lot for your effort on
this and my apologies for not taking the care to dissect this more
carefully as you suggested. Over to the Meld mailing list...
>> There are plenty of posts around about these being line endings used for
>> windows which can appear when working on a script under a *nix OS which
>> has previously been edited in a Windows OS. This is not the case here -
>> everything is taking place on Ubuntu 12.04.
>>
>> FWIW: the directory is being synced by dropbox; and in Meld, Preferences
>> > Encoding tab, "utf8" is entered in the text box.
>>
>> Current work around is running in a terminal: dos2unix /path/to/script.r
>> which strips the ^M's
>>
>> But this just shouldn't be necessary and I'd really appreciate the
>> reflections & advice on how to stop inducing these ^M's !
>>
>> With thanks,
>>
>> Karl
>>
>> (re)posted here as suggested off topic at SO:
>> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
>>
>
--
Karl Brand
Dept of Cardiology and Dept of Bioinformatics
Erasmus MC
Dr Molewaterplein 50
3015 GE Rotterdam
T +31 (0)10 703 2460 |M +31 (0)642 777 268 |F +31 (0)10 704 4161
^ permalink raw reply
* Fwd: possible Improving diff algoritm
From: Kevin @ 2012-12-12 15:03 UTC (permalink / raw)
To: git
In-Reply-To: <CAO54GHC4AXQO1MbU2qXMdcDO5mtUFhrXfXND5evc93kQhNfCrw@mail.gmail.com>
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.
^ permalink raw reply
* Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-12 15:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <7vtxrr6d2f.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
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.
> The preimage of git-submodule.sh in [2/3] does not seem to match
> anything I have (I could wiggle the patch, but in general I would
> rather prefer not having to).
From patch 1/3:
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..f969f28 100755
And from patch 2/3:
diff --git a/git-submodule.sh b/git-submodule.sh
index f969f28..1395079 100755
ab6b110 is in v1.8.0:
$ git ls-tree v1.8.0 git-submodule.sh
100755 blob ab6b1107b6090494f192f361471ed5748ffa7dc1 git-submodule.sh
I can reroll if necessary, but I'm not sure what I've done wrong…
Cheers,
Trevor
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] submodule: add 'deinit' command
From: Michael J Gruber @ 2012-12-12 15:08 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Phil Hord, W. Trevor King, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <50BE6FB9.70301@web.de>
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?
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.
> Add tests and link the man pages of "git submodule deinit" and "git rm"
> to assist the user in deciding whether removing or unregistering the
> submodule is the right thing to do for him.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> Am 03.12.2012 08:58, schrieb Junio C Hamano:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>
>>> Maybe the principle of least surprise is better followed when we
>>> nuke the whole section, as it might surprise the user more to have
>>> a setting resurrected he customized in the last life cycle of the
>>> submodule than seeing that after an deinit followed by an init all
>>> former customizations are consistently gone. So I tend to think now
>>> that removing the whole section would be the better solution here.
>>
>> I tend to agree; I suspect that a "deinit" would be mostly done
>> either to
>>
>> (1) correct mistakes the user made during a recent "init" and
>> perhaps "sync"; or
>>
>> (2) tell Git that the user has finished woing with this particular
>> submodule and does not intend to use it for quite a while.
>>
>> For both (1) and (2), I think it would be easier to users if we gave
>> them a clean slate, the same state as the one the user who never had
>> ran "init" on it would be in. A user in situation (1) is asking for
>> a clean slate, and a user in situation (2) is better served if he
>> does not have to worry about leftover entries in $GIT_DIR/config he
>> has long forgotten from many months ago (during which time the way
>> the project uses the particular submodule may well have changed)
>> giving non-standard experience different from what other project
>> participants would get.
>
> Changes in v2:
> - Remove the whole submodule section instead of only removing the
> "url" setting and explain why we do that in a comment
> - Reworded commit message and git-submodule.txt to reflect that
> - Extend the test to check that a custom settings are removed
>
>
> Documentation/git-rm.txt | 4 ++++
> Documentation/git-submodule.txt | 12 ++++++++++
> git-submodule.sh | 52 ++++++++++++++++++++++++++++++++++++++++-
> t/t7400-submodule-basic.sh | 12 ++++++++++
> 4 files changed, 79 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
> index 262436b..ec42bf5 100644
> --- a/Documentation/git-rm.txt
> +++ b/Documentation/git-rm.txt
> @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.
> Ignored files are deemed expendable and won't stop a submodule's work
> tree from being removed.
>
> +If you only want to remove the local checkout of a submodule from your
> +work tree without committing that use `git submodule deinit` instead
> +(see linkgit:git-submodule[1]).
> +
> EXAMPLES
> --------
> `git rm Documentation/\*.txt`::
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b1de3ba..08b55a7 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,6 +13,7 @@ SYNOPSIS
> [--reference <repository>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> +'git submodule' [--quiet] deinit [--] [<path>...]
> 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
> @@ -134,6 +135,17 @@ init::
> the explicit 'init' step if you do not intend to customize
> any submodule locations.
>
> +deinit::
> + Unregister the submodules, i.e. remove the whole `submodule.$name`
> + section from .git/config. Further calls to `git submodule update`,
> + `git submodule foreach` and `git submodule sync` will skip any
> + unregistered submodules until they are initialized again, so use
> + this command if you don't want to have a local checkout of the
> + submodule in your work tree anymore (but note that this command
> + does not remove the submodule work tree). If you really want to
> + remove a submodule from the repository and commit that use
> + linkgit:git-rm[1] instead.
> +
> update::
> Update the registered submodules, i.e. clone missing submodules and
> checkout the commit specified in the index of the containing repository.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2365149..3f558ed 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
> USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] init [--] [<path>...]
> + or: $dashless [--quiet] deinit [--] [<path>...]
> or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
> or: $dashless [--quiet] foreach [--recursive] <command>
> @@ -516,6 +517,55 @@ cmd_init()
> }
>
> #
> +# Unregister submodules from .git/config
> +#
> +# $@ = requested paths (default to all)
> +#
> +cmd_deinit()
> +{
> + # parse $args after "submodule ... init".
> + while test $# -ne 0
> + do
> + case "$1" in
> + -q|--quiet)
> + GIT_QUIET=1
> + ;;
> + --)
> + shift
> + break
> + ;;
> + -*)
> + usage
> + ;;
> + *)
> + break
> + ;;
> + esac
> + shift
> + done
> +
> + module_list "$@" |
> + while read mode sha1 stage sm_path
> + do
> + die_if_unmatched "$mode"
> + name=$(module_name "$sm_path") || exit
> + url=$(git config submodule."$name".url)
> + if test -z "$url"
> + then
> + # Only mention uninitialized submodules when its
> + # path have been specified
> + test "$#" != "0" &&
> + say "$(eval_gettext "No url found for submodule path '\$sm_path' in .git/config")"
> + continue
> + fi
> + # Remove the whole section so we have a clean state when the user
> + # later decides to init this submodule again
> + git config --remove-section submodule."$name" &&
> + say "$(eval_gettext "Submodule '\$name' (\$url) unregistered")"
> + done
> +}
> +
> +#
> # Update each submodule path to correct revision, using clone and checkout as needed
> #
> # $@ = requested paths (default to all)
> @@ -1108,7 +1158,7 @@ cmd_sync()
> while test $# != 0 && test -z "$command"
> do
> case "$1" in
> - add | foreach | init | update | status | summary | sync)
> + add | foreach | init | deinit | update | status | summary | sync)
> command=$1
> ;;
> -q|--quiet)
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index de7d453..ee4f0ab 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -756,4 +756,16 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
> )
> '
>
> +test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '
> + git config submodule.example.foo bar &&
> + git submodule deinit &&
> + test -z "$(git config submodule.example.url)" &&
> + test -z "$(git config submodule.example.foo)"
> +'
> +
> +test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '
> + git submodule deinit &&
> + test_must_fail git submodule deinit example
> +'
> +
> test_done
>
^ permalink raw reply
* Re: How to avoid the ^M induced by Meld and Git
From: Michael J Gruber @ 2012-12-12 14:57 UTC (permalink / raw)
To: Karl Brand; +Cc: git
In-Reply-To: <50C72821.10908@erasmusmc.nl>
Karl Brand venit, vidit, dixit 11.12.2012 13:33:
> Esteemed Git users,
>
> What i do:
>
> 1. Create a script.r using Emacs/ESS.
> 2. Make some modifications to script.r with the nice diff gui, Meld
> 3. Commit these modifications using git commit -am "my message"
> 4. Reopen script.r in Emacs/ESS to continue working.
>
> The lines added (&/edited ?) using Meld all end with ^M which i
> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
What happens if you leave out step 3? If the same happens then Meld is
the culprit. (Unless you've set some special options, git does not
modify your file on commit, so this can't be git related.)
> There are plenty of posts around about these being line endings used for
> windows which can appear when working on a script under a *nix OS which
> has previously been edited in a Windows OS. This is not the case here -
> everything is taking place on Ubuntu 12.04.
>
> FWIW: the directory is being synced by dropbox; and in Meld, Preferences
> > Encoding tab, "utf8" is entered in the text box.
>
> Current work around is running in a terminal: dos2unix /path/to/script.r
> which strips the ^M's
>
> But this just shouldn't be necessary and I'd really appreciate the
> reflections & advice on how to stop inducing these ^M's !
>
> With thanks,
>
> Karl
>
> (re)posted here as suggested off topic at SO:
> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
>
^ permalink raw reply
* Re: [PATCH] RFC Optionally handle symbolic links as copies
From: Michael J Gruber @ 2012-12-12 14:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, git
In-Reply-To: <1622149333.19335600.1354756984435.JavaMail.root@dewire.com>
Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23:
>
>
> ----- Ursprungligt meddelande -----
>> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>>
>>> If core.symlinks is set to copy then symbolic links in a git
>>> repository
>>> will be checked out as copies of the file it points to.
>>
>> That all sounds nice on surface when the primary thing you care
>> about is to fetch and check out other people's code and extract it
>> to the working tree, but how well would that work on the checkin
>> side? What happens if I check out a symlink that points at a file
>> (either in-tree or out-of-tree), make some changes that do not
>> involve the symlink, and before I make the commit, an unrelated
>> change is made to the file the symlink is pointing at?
>>
>>> - git status - when do we report a diff.
>>> - After checkout we should probably not
>>> - if the "linked" files change?
>>
>> Yeah, exactly.
>>
>>> - if a change in the copied directory chsnges
>>
>> That, too.
>>
>>> - if a file in the copied diretory is added/removed
>>> - update, should we update the copied structure automatically
>>> when the link target changes
>
> Some of the questions have proposals in the includes test script. A
> little more dangerous than having real symlinks ofcourse, but regardless
> of what one does with or without copied symlinks one can make mistakes
> and I feel letting Git do the copying is way better than having real
> copies in the git repository. Another crappy scm which the users are
> converting from does this and it works. A difference to git is that
> it (ok clearcase) makes all files read-only so there are fewer mays
> of making mistakes with the copies.
>
>> I personally do not think this is worth it. It would be very useful
>> on the export/checkout side, so it may make sense to add it to "git
>> archive", though.
>
> It makes sense, but it does not solve the problem at hand.
>
> -- robin
>
Well, what is the problem at hand?
Your commit message begins in present tense as if it described the
current state of git, when in fact it describes what the patch is about
to achieve. This is confusing enough already,
I don't see any mention of the purpose, other than "content may be
used", which would be served perfectly by a copy-on-link feature on the
export side, as mentioned by Junio. Is git-archive|tar an option?
Michael
^ permalink raw reply
* Re: Bad URL passed to RA layer ('https')
From: Eugene @ 2012-12-12 14:36 UTC (permalink / raw)
To: git
In-Reply-To: <l2y5208b6091005040218t2890b871x1753a1788b67350b@mail.gmail.com>
Here I. Come <me.detected <at> gmail.com> writes:
> ------------------8<-----------------------
> $ git svn clone https://host/svn/myrepo
> Initialized empty Git repository in /tmp/myrepo/.git/
> Bad URL passed to RA layer: Unrecognized URL scheme for
> 'https://host/svn/myrepo' at /usr/libexec/git-core/git-svn line 1770
> ------------------8<-----------------------
Hi, I have faced with the same problem. Did you find out who to resolve it?
^ permalink raw reply
* Re: [PATCH 4/5] pretty: Use mailmap to display username and email
From: Antoine Pelisse @ 2012-12-12 13:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Rich Midwinter
In-Reply-To: <7vehiw6wc1.fsf@alter.siamese.dyndns.org>
> Or it might be better to make those two strbufs output-only
> parameter, e.g.
>
> map_user(struct string_list *mailmap,
> const char *name, size_t namelen,
> const char *mail, size_t maillen,
> struct strbuf *name_out, struct strbuf *mail_out);
>
> then after split_ident_line(), this caller could feed two pointers
> into the original "line" as name and mail parameter, without making
> any copies (the callee has to make a copy but it has to be done
> anyway when the name/mail is mapped). I suspect it would make this
> caller simpler, but I do not know how invasive such changes are for
> other callers of map_user().
It makes a lot of sense.
blame.c::get_commit_info() hard code the length
shortlog.c::insert_one_record() hard code the length
pretty.c::format_person_part() hard code the length
I don't think it will be invasive.
> Such an update can be left outside of this series, of course.
I will try to make it at the beginning of the series. It will avoid unnecessary
conflicts.
>> + strbuf_addch(sb, ' ');
>> + strbuf_addch(sb, '<');
>> + strbuf_add(sb, person_mail, strlen(person_mail));
>> + strbuf_addch(sb, '>');
>> strbuf_addch(sb, '\n');
>
> Is that strbuf_addf(sb, " <%s>\n", person_mail)?
Of couse ;) Fixed.
^ permalink raw reply
* [PATCH] index-format.txt: be more liberal on what can represent invalid cache tree
From: Nguyễn Thái Ngọc Duy @ 2012-12-12 12:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
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.
Correct the document to reflect the fact that -1 is not the only magic
number. At least one implementation, libgit2, is found to treat -1
this way.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/technical/index-format.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-12-12 12:43 UTC (permalink / raw)
To: Patrick Donnelly
Cc: Sitaram Chamarty, Nguyen Thai Ngoc Duy, Michael Haggerty,
Felipe Contreras, git
In-Reply-To: <CACh33Fpk8_ZXw8Ladx83J+rmdRYf7ruYAMMkqOKcoH3OApKPJQ@mail.gmail.com>
Patrick Donnelly <batrick@batbytes.com>:
> On Tue, Dec 11, 2012 at 10:30 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > It might be a good fit for extending git; I wouldn't be very surprised if
> > that worked. However, I do have concerns about the "Oh, we'll just
> > lash together a binding to C" attitude common among lua programmers; I
> > foresee maintainability problems and the possibility of slow death by
> > low-level details as that strategy tries to scale up.
>
> I think this is quite a prediction? Could you give an example
> scenario?
Everything old is new again. I'm going by experience with Tcl back in the day.
> How would another language (e.g. Python) mitigate this?
The way you mitigate this sort of problem is to have a good set of
high-level bindings for standard services (like socket I/O) built in
your extension language and using its abstractions, so you don't get a
proliferation of low-level semi-custom APIs for doing the same stuff.
I have elsewhere referred to this as "the harsh lesson of Perl", which
I do not love but which was the first scripting language to get this
right. There is a reason Tcl and a couple of earlier designs like csh
that we would now call "scripting languages" were displaced by Python
and Perl; this is it.
My favorite present-day example of getting this right is the Python bindings
for GTK. They're lovely. A work of art.
> I don't see how these languages are more appropriate based on your concerns.
Your previous exchange with Jeff King indicates that you don't
understand glue scripting very well. Your puzzlement here just
confirms that. Trust both of us on this, it's important. And
reread my previous three paragraphs.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Jeff King @ 2012-12-12 12:29 UTC (permalink / raw)
To: Eric S. Raymond
Cc: Sitaram Chamarty, Patrick Donnelly, Nguyen Thai Ngoc Duy,
Michael Haggerty, Felipe Contreras, git
In-Reply-To: <20121212122625.GB25981@thyrsus.com>
On Wed, Dec 12, 2012 at 07:26:25AM -0500, Eric S. Raymond wrote:
> Jeff King <peff@peff.net>:
> > 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.
>
> That's good analysis. I agree with your use-case split, I guess I'm just not
> very aware of the places in git where (1) is important.
Yeah, I don't think (1) is your use case at all. But when people talk
about "Jeff's lua experiment", they are talking about some patches I had
to do (1), which covered "log --format" (but ultimately would need more
cleanup to be acceptable upstream). Maybe that clears up the discussion
a little bit.
-Peff
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-12-12 12:26 UTC (permalink / raw)
To: Jeff King
Cc: 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>:
> 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.
That's good analysis. I agree with your use-case split, I guess I'm just not
very aware of the places in git where (1) is important.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Jeff King @ 2012-12-12 12:24 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <CACsJy8Dg1a0siDbiHtk4m1RhjLt-XKiS8kOO7qPKjwRczLF9vA@mail.gmail.com>
On Mon, Dec 10, 2012 at 07:04:40PM +0700, Nguyen Thai Ngoc Duy wrote:
> > With or without "--no-merges", the big picture you can get out of
> > "git shortlog -s -n --since=1.year" does not change very much, but
> > the headline numbers give a wrong impression.
>
> These numbers are approximate anyway. Commit counts or the number of
> changed lines do not accurately reflect the effort in many cases. And
> about merges, in this particular case of Git where the maintainer imo
> has done an excellent job as a guard, I'd say it's the credit for
> reviewing, not simply merging.
I agree that commit count is approximate. But counting merges is really
quite a large factor of error (in git.git, it more than doubles Junio's
count, and represents over 20% of the total number of commits).
The GitHub contributors page counts merges _and_ fails to use mailmap.
Yuck. I'm working on fixing that now.
> But not using the link is fine too. We can wait for Jeff's patch to be
> merged.
After the discussion in the PR, I am inclined to think the site (and
possibly the manpage) should just point to some decent contributors
graph (either GitHub, ohloh, or something else; suggestions welcome).
Anything else is just recreating a crappy static version of something
that could be much more dynamic and explorable.
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).
-Peff
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-12-12 12:23 UTC (permalink / raw)
To: Joshua Jensen
Cc: Sitaram Chamarty, Patrick Donnelly, Nguyen Thai Ngoc Duy,
Michael Haggerty, Felipe Contreras, git
In-Reply-To: <50C811ED.4000600@workspacewhiz.com>
Joshua Jensen <jjensen@workspacewhiz.com>:
> Anyway, my preference is to allow scripts to run in-process within
> Git, because it is far, far faster on Windows. I imagine it is
> faster than forking processes on non-Windows machines, too, but I
> have no statistics to back that up.
>
> Python, Perl, or Ruby can be embedded, too, but Lua probably embeds
> the easiest and smallest out of those other 3 languages.
>
> And shell scripts tend to be the slowest on Windows due to the
> excessive numbers of process invocations needed to get anything
> reasonable done.
I don't think there's *any* dimension along which lua is not clearly
better than shell for this sort of thing, so no argument there.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH 5/5] log: Add --use-mailmap option
From: Antoine Pelisse @ 2012-12-12 11:58 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Rich Midwinter, Antoine Pelisse
In-Reply-To: <1355264493-8298-6-git-send-email-apelisse@gmail.com>
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 ?
My opinion is that it belongs to 'Commit Formatting'.
It would also make sense to be able to use '--use-mailmap' when running
format-patch for example.
Also, I've noticed that my series break some tests (linked with
format-patch BTW).
I fixed that and re-ran all tests successfully. I will resubmit it later.
^ permalink raw reply
* [PATCH 5/5] contrib: update stats/mailmap script
From: Jeff King @ 2012-12-12 11:41 UTC (permalink / raw)
To: git
In-Reply-To: <20121212113036.GB19625@sigill.intra.peff.net>
This version changes quite a few things:
1. The original parsed the mailmap file itself, and it did
it wrong (it did not understand entries with an extra
email key).
Instead, this version uses git's "%aE" and "%aN"
formats to have git perform the mapping, meaning we do
not have to read .mailmap at all, but still operate on
the current state that git sees (and it also works
properly from subdirs).
2. The original would find multiple names for an email,
but not the other way around.
This version can do either or both. If we find multiple
emails for a name, the resolution is less obvious than
the other way around. However, it can still be a
starting point for a human to investigate.
3. The original would order only by count, not by recency.
This version can do either. Combined with showing the
counts, it can be easier to decide how to resolve.
4. This version shows similar entries in a blank-delimited
stanza, which makes it more clear which options you are
picking from.
Signed-off-by: Jeff King <peff@peff.net>
---
contrib/stats/mailmap.pl | 108 ++++++++++++++++++++++++++++++-----------------
1 file changed, 70 insertions(+), 38 deletions(-)
rewrite contrib/stats/mailmap.pl (97%)
diff --git a/contrib/stats/mailmap.pl b/contrib/stats/mailmap.pl
dissimilarity index 97%
index 4b852e2..9513f5e 100755
--- a/contrib/stats/mailmap.pl
+++ b/contrib/stats/mailmap.pl
@@ -1,38 +1,70 @@
-#!/usr/bin/perl -w
-my %mailmap = ();
-open I, "<", ".mailmap";
-while (<I>) {
- chomp;
- next if /^#/;
- if (my ($author, $mail) = /^(.*?)\s+<(.+)>$/) {
- $mailmap{$mail} = $author;
- }
-}
-close I;
-
-my %mail2author = ();
-open I, "git log --pretty='format:%ae %an' |";
-while (<I>) {
- chomp;
- my ($mail, $author) = split(/\t/, $_);
- next if exists $mailmap{$mail};
- $mail2author{$mail} ||= {};
- $mail2author{$mail}{$author} ||= 0;
- $mail2author{$mail}{$author}++;
-}
-close I;
-
-while (my ($mail, $authorcount) = each %mail2author) {
- # %$authorcount is ($author => $count);
- # sort and show the names from the most frequent ones.
- my @names = (map { $_->[0] }
- sort { $b->[1] <=> $a->[1] }
- map { [$_, $authorcount->{$_}] }
- keys %$authorcount);
- if (1 < @names) {
- for (@names) {
- print "$_ <$mail>\n";
- }
- }
-}
-
+#!/usr/bin/perl
+
+use warnings 'all';
+use strict;
+use Getopt::Long;
+
+my $match_emails;
+my $match_names;
+my $order_by = 'count';
+Getopt::Long::Configure(qw(bundling));
+GetOptions(
+ 'emails|e!' => \$match_emails,
+ 'names|n!' => \$match_names,
+ 'count|c' => sub { $order_by = 'count' },
+ 'time|t' => sub { $order_by = 'stamp' },
+) or exit 1;
+$match_emails = 1 unless $match_names;
+
+my $email = {};
+my $name = {};
+
+open(my $fh, '-|', "git log --format='%at <%aE> %aN'");
+while(<$fh>) {
+ my ($t, $e, $n) = /(\S+) <(\S+)> (.*)/;
+ mark($email, $e, $n, $t);
+ mark($name, $n, $e, $t);
+}
+close($fh);
+
+if ($match_emails) {
+ foreach my $e (dups($email)) {
+ foreach my $n (vals($email->{$e})) {
+ show($n, $e, $email->{$e}->{$n});
+ }
+ print "\n";
+ }
+}
+if ($match_names) {
+ foreach my $n (dups($name)) {
+ foreach my $e (vals($name->{$n})) {
+ show($n, $e, $name->{$n}->{$e});
+ }
+ print "\n";
+ }
+}
+exit 0;
+
+sub mark {
+ my ($h, $k, $v, $t) = @_;
+ my $e = $h->{$k}->{$v} ||= { count => 0, stamp => 0 };
+ $e->{count}++;
+ $e->{stamp} = $t unless $t < $e->{stamp};
+}
+
+sub dups {
+ my $h = shift;
+ return grep { keys($h->{$_}) > 1 } keys($h);
+}
+
+sub vals {
+ my $h = shift;
+ return sort {
+ $h->{$b}->{$order_by} <=> $h->{$a}->{$order_by}
+ } keys($h);
+}
+
+sub show {
+ my ($n, $e, $h) = @_;
+ print "$n <$e> ($h->{$order_by})\n";
+}
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
* [PATCH 4/5] .mailmap: normalize emails for Linus Torvalds
From: Jeff King @ 2012-12-12 11:41 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <20121212113036.GB19625@sigill.intra.peff.net>
Linus used a lot of different per-machine email addresses in
the early days. This means that "git shortlog -nse" does not
aggregate his counts, and he is listed well below where he
should be (8th instead of 3rd).
Signed-off-by: Jeff King <peff@peff.net>
---
Linus,
I recall you considered "email ident from random machine" as a feature
very early on in git's history, but you seem to have settled on using
the linux-foundation address pretty consistently these days. Please let
me know if you object to normalizing your entries in this way.
.mailmap | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/.mailmap b/.mailmap
index 4a27b7f..c7e8618 100644
--- a/.mailmap
+++ b/.mailmap
@@ -52,6 +52,12 @@ Li Hong <leehong@pku.edu.cn>
Lars Doelle <lars.doelle@on-line ! de>
Lars Doelle <lars.doelle@on-line.de>
Li Hong <leehong@pku.edu.cn>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@woody.linux-foundation.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@g5.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@evo.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@ppc970.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@ppc970.osdl.org.(none)>
Lukas Sandström <lukass@etek.chalmers.se>
Marc-André Lureau <marcandre.lureau@gmail.com>
Mark Rada <marada@uwaterloo.ca>
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
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