* Re: [PATCH/RFC] launch_editor: ignore SIGINT while the editor has control
From: Paul Fox @ 2012-11-07 23:35 UTC (permalink / raw)
To: git; +Cc: Krzysztof Mazur, gitster
In-Reply-To: <20121107220027.GA17463@shrek.podlesie.net>
the user's editor likely catches SIGINT (ctrl-C). but if the user
spawns a command from the editor and uses ctrl-C to kill that command,
the SIGINT will likely also kill git itself. (depending on the
editor, this can leave the terminal in an unusable state.)
Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
---
krzysztof wrote:
...
> editor.c: In function 'launch_editor':
> editor.c:42:3: warning: implicit declaration of function 'sigchain_push' [-Wimplicit-function-declaration]
> editor.c:44:3: warning: implicit declaration of function 'sigchain_pop' [-Wimplicit-function-declaration]
sigh. i had that initially, lost the patch, and then recreated
without it. but i'm surprised my build (i did rebuild! :-) doesn't
emit those errors. in any case, here's the fixed patch.
editor.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/editor.c b/editor.c
index d834003..3ca361b 100644
--- a/editor.c
+++ b/editor.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "strbuf.h"
#include "run-command.h"
+#include "sigchain.h"
#ifndef DEFAULT_EDITOR
#define DEFAULT_EDITOR "vi"
@@ -37,8 +38,12 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
+ int ret;
- if (run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env))
+ sigchain_push(SIGINT, SIG_IGN);
+ ret = run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env);
+ sigchain_pop(SIGINT);
+ if (ret)
return error("There was a problem with the editor '%s'.",
editor);
}
--
1.7.5.4
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 26.6 degrees)
^ permalink raw reply related
* Re: What about SHA-1 collisions?
From: Andrew Ardill @ 2012-11-07 23:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Josef Wolf, git
In-Reply-To: <CAJo=hJtF2+Z1BDQnysB7hk2MM336iEUMHd3zSLCm14yvw1_-wg@mail.gmail.com>
A recent article [1] did an analysis on the number of items needed
from a given range to have a 50% chance of a collision. The famous
birthday paradox scenario was used, where you only need 23 people
before the chance of two of them having the same birthday is over 50%.
In this scenario there are ~366 options available to be picked from,
and 23 is significantly small in comparison.
The mathematics behind these statistics was extended to account for
any sized range (call it N) and it turns out that the number of items
(k) that can be picked before you have exceeded a given percentage
chance (T) of _not_ having a collision is roughly
k ~= sqrt(-2N.ln(T))
As pedrocr pointed out on Hacker News [2]
"Applying the formula for 160bit SHA-1 you need 1.7e23 objects to get
a 1% chance of collision. The current Linus kernel repository has 2.7
million objects. So to get a collision you'd need a repository that's
6e16 times larger. That should be plenty.
For some wacky perspective that's 10 million kernel sized
contributions for every man woman and child on earth together in a
single repository. It would seem git will reach plenty of other
bottlenecks before SHA-1 becomes a problem..."
An interesting analysis, even given that the OP presumes a collision
in their question.
Regards,
Andrew Ardill
[1] http://www.solipsys.co.uk/new/TheBirthdayParadox.html
[2] http://news.ycombinator.com/item?id=4753198
^ permalink raw reply
* Revert option for git add --patch
From: Nathan Broadbent @ 2012-11-07 23:54 UTC (permalink / raw)
To: git
In-Reply-To: <CAPXHQbOxNG0XN80rH6mM6iSVtCtU26Yio_XQ=5ofBHBpZN3VyQ@mail.gmail.com>
Hi,
I would like to propose a revert option for 'git add --patch', that
reverts the hunk. I often use `git add -p` to skip whitespace changes
when preparing a patch, and a 'revert' option would save me from
running 'git checkout <file>' after I've staged the desired changes.
I would propose adding r and R options for the 'Stage this hunk' menu,
with the following actions:
r: Revert this hunk
R: Revert this hunk and all other remaining hunks
e.g. Stage this hunk [y/n/a/d/K/j/J/e/r/R?]?
Please let me know if you think this is a good idea.
Best,
Nathan
^ permalink raw reply
* Re: Revert option for git add --patch
From: Simon Rozet @ 2012-11-08 1:00 UTC (permalink / raw)
To: git
In-Reply-To: <CAPXHQbN0x-o_4rQO-Lq_gDTqs=beBE5XrrzJ1Th+7G2Lq7Dh_Q@mail.gmail.com>
help
On Wed, Nov 7, 2012 at 3:54 PM, Nathan Broadbent <nathan.f77@gmail.com> wrote:
> Hi,
>
> I would like to propose a revert option for 'git add --patch', that
> reverts the hunk. I often use `git add -p` to skip whitespace changes
> when preparing a patch, and a 'revert' option would save me from
> running 'git checkout <file>' after I've staged the desired changes.
>
> I would propose adding r and R options for the 'Stage this hunk' menu,
> with the following actions:
>
> r: Revert this hunk
> R: Revert this hunk and all other remaining hunks
>
> e.g. Stage this hunk [y/n/a/d/K/j/J/e/r/R?]?
>
>
> Please let me know if you think this is a good idea.
>
>
> Best,
> Nathan
> --
> 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: Revert option for git add --patch
From: Michal Kiedrowicz @ 2012-11-08 8:46 UTC (permalink / raw)
To: git
In-Reply-To: <CAPXHQbN0x-o_4rQO-Lq_gDTqs=beBE5XrrzJ1Th+7G2Lq7Dh_Q@mail.gmail.com>
Nathan Broadbent <nathan.f77 <at> gmail.com> writes:
> I would like to propose a revert option for 'git add --patch', that
> reverts the hunk. I often use `git add -p` to skip whitespace changes
> when preparing a patch, and a 'revert' option would save me from
> running 'git checkout <file>' after I've staged the desired changes.
Doesn't `git checkout -p` do what you describe?
Kind regards,
Michal Kiedrowicz
^ permalink raw reply
* Re: Revert option for git add --patch
From: Jonathon Mah @ 2012-11-08 8:57 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Nathan Broadbent
Nathan,
I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p).
The interactive staging-and-editing tool could be improved, but I'm not sure that tool should be called 'git add -p'. git add doesn't touch the working tree — at least I hope not, because I wouldn't expect it.
But I eagerly support more discussion. If someone does want to add this feature to "git add -p" (or named differently), I'll add a request for another letter (perhaps '!') to edit the hunk in the working tree.
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply
* Re: [RFC] Add a new email notification script to "contrib"
From: Michael Haggerty @ 2012-11-08 9:42 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Andy Parkins, Sitaram Chamarty, Stefan Näwe,
Junio C Hamano, Marc Branchaud, Matthieu Moy
In-Reply-To: <CACBZZX6=e6_qO=wMcxLdUAc6XxYpdiP-9RPRsCXrVC_iuJ11Jg@mail.gmail.com>
On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 07/14/2012 08:59 AM, mhagger@alum.mit.edu wrote:
>>>
>>> Add a new Python script, contrib/hooks/post-receive-multimail.py, that
>>> can be used to send notification emails describing pushes into a git
>>> repository. [...]
>>
>>
>> Thanks to everybody for your feedback. I will try to incorporate it in a
>> new version of the script, which I will put forward as a replacement for
>> contrib/hooks/post-receive-email rather than as an alternative. But I have
>> very little open-sourcing time these days, and will be on vacation next
>> week, so please be patient (or feel free to lend a hand if you are so
>> inclined).
>
> I'm curious as to whether you got around to this? I'd be interested in
> updates on this script.
Thanks for asking. I have made many of the changes that were requested
and/or I had planned:
* Tentatively renamed the system to git-multimail
* Store the configuration in namespace "multimailhook.*" instead of
"hooks.*".
* Reinstated (optional) support for including shortlogs since the last
tag in announce emails.
* Script to migrate post-receive-email configuration to the equivalent
git-multimail config.
* Better documentation (including of the migration process).
* Made it easier to use Python code to customize the script's behavior
(by allowing it to be imported as a Python module), plus a demo script
showing this usage.
* Some primitive testing tools to generate a test git repository and
generate many kinds of notification emails (though the emails still have
to be checked manually for correctness).
But I haven't submitted the new version because I just haven't had a
good block of time to really wrap it up and call it a "final" version.
One remaining question is how to fit it into the git source tree along
with its supporting materials (or even whether to maintain it as a
separate project).
Nevertheless I think that the script is quite usable as it is and it
would be great if other people could try it out, give feedback, and even
submit patches.
So I just created a github repository containing my current version:
https://github.com/mhagger/git-multimail
Enjoy!
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* bare vs non-bare <1.7 then >=1.7 ?
From: Mihamina Rakotomandimby @ 2012-11-08 10:11 UTC (permalink / raw)
To: Git Issues
Hi all,
We're on the way to have our first project using Git.
We're currently mostly using Hg (90%) & SVN (10%).
When experimenting in order to train some colleagues, I saw that If I
clone a repository, I couldn't push to it because it was a non-bare one.
Searchin for some explanations, I found this ressource:
http://www.bitflop.com/document/111
It's told to be reliable information for Git < v1.7.
What would be different for Git > 1.7 so that I could be up to date with
the facts?
Thank you.
--
RMA.
^ permalink raw reply
* Re: [RFC] Add a new email notification script to "contrib"
From: Ævar Arnfjörð Bjarmason @ 2012-11-08 11:39 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Andy Parkins, Sitaram Chamarty, Stefan Näwe,
Junio C Hamano, Marc Branchaud, Matthieu Moy
In-Reply-To: <509B7E6B.1030407@alum.mit.edu>
On Thu, Nov 8, 2012 at 10:42 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
>> I'm curious as to whether you got around to this? I'd be interested in
>> updates on this script.
>
> Thanks for asking. I have made many of the changes that were requested
> and/or I had planned:
I was playing around with it for some work repos last night.
> * Tentatively renamed the system to git-multimail
>
> * Store the configuration in namespace "multimailhook.*" instead of
> "hooks.*".
Great, I had made this change locally myself, makes it much easier to
keep the configuration separate, and I think doing and having a
migration script is better than using the original config variables.
> * Reinstated (optional) support for including shortlogs since the last
> tag in announce emails.
>
> * Script to migrate post-receive-email configuration to the equivalent
> git-multimail config.
>
> * Better documentation (including of the migration process).
>
> * Made it easier to use Python code to customize the script's behavior
> (by allowing it to be imported as a Python module), plus a demo script
> showing this usage.
That's very nice, I was monkeypatching the script to overwrite some
templates. This makes that easy.
> * Some primitive testing tools to generate a test git repository and
> generate many kinds of notification emails (though the emails still have
> to be checked manually for correctness).
>
> Nevertheless I think that the script is quite usable as it is and it
> would be great if other people could try it out, give feedback, and even
> submit patches.
I'll test it out some more, the issues I've had with it so far in
migrating from the existing script + some custom hacks we have to it
have been:
* Overly verbose default templates, easy to overwrite now. Might send
patches for some of them.
* No ability to link to a custom gitweb, probably easy now.
* If someone only pushes one commit I'd like to only have one e-mail
with the diff, but if they push multiple commits I'd like to have a
summary e-mail and replies to that which have the patches.
It only seemed to support the latter mode, so you send out two
e-mails for pushing one commit.
* Ability to limit the number of lines, but not line length, that's
handy for some template repositories. Should be easy to add
* I wanted a hook to override the options passed to sendmail in some
cases, looks easier now with the modular design.
But in addition to that we have our own custom E-Mail notification
scripts for:
* People can subscribe to changes to certain files. I.e. if you
modify very_important.c we'll send an E-Mail to a more widely seen
review list.
* Invididuals can also edit a config file to watch individual files /
glob patterns of files, e.g. src/main.c or src/crypto*
I think a good way to support that would be to have either a path to a
config file with those watch specs, or a command so you could run "git
show ..." on some repo users can push to.
But overall it's very nice. I'll make some time to test it in my
organization (with lots of commits and people reading commit e-mails).
^ permalink raw reply
* Re: Revert option for git add --patch
From: Nguyen Thai Ngoc Duy @ 2012-11-08 12:00 UTC (permalink / raw)
To: Jonathon Mah; +Cc: git@vger.kernel.org, Nathan Broadbent
In-Reply-To: <EE89F0A1-1C07-4597-B654-035F657AD09F@me.com>
On Thu, Nov 8, 2012 at 3:57 PM, Jonathon Mah <jmah@me.com> wrote:
> Nathan,
>
> I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p).
I agree. I'd be really nice to have an interactive command about hunk
manipulation between HEAD (or some other ref), index and worktree in
both directions (except writing to HEAD, of course). This reminds me
of the "git put" discussion a while ago, which also moves code between
different locations..
--
Duy
^ permalink raw reply
* Re: [RFC] Add a new email notification script to "contrib"
From: Michael Haggerty @ 2012-11-08 12:17 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Andy Parkins, Sitaram Chamarty, Stefan Näwe,
Junio C Hamano, Marc Branchaud, Matthieu Moy
In-Reply-To: <CACBZZX5FihEMSyrws-D7GyWvxtpMCPwvaiM18ZqOBaoBcvEjDA@mail.gmail.com>
On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote:
> [...]
I'm glad it's getting some use. Thanks for the feedback.
> I'll test it out some more, the issues I've had with it so far in
> migrating from the existing script + some custom hacks we have to it
> have been:
>
> * Overly verbose default templates, easy to overwrite now. Might send
> patches for some of them.
The templating is currently not super flexible nor very well documented,
but simple changes should be easy enough. I mostly carried over the
text explanations from the old post-receive-email script; it is true
that they are quite verbose.
> * No ability to link to a custom gitweb, probably easy now.
What do you mean by "a custom gitweb"? What are the commitmail issues
involved?
> * If someone only pushes one commit I'd like to only have one e-mail
> with the diff, but if they push multiple commits I'd like to have a
> summary e-mail and replies to that which have the patches.
>
> It only seemed to support the latter mode, so you send out two
> e-mails for pushing one commit.
That's correct, and I've also thought about the feature that you
described. I think it would be pretty easy to implement; it is only not
quite obvious to which mailing list(s?) such emails should be sent.
> * Ability to limit the number of lines, but not line length, that's
> handy for some template repositories. Should be easy to add
Should too-long lines be folded or truncated? Either way, it should be
pretty straightforward (Python even has a textwrap module that could be
used).
> But in addition to that we have our own custom E-Mail notification
> scripts for:
>
> * People can subscribe to changes to certain files. I.e. if you
> modify very_important.c we'll send an E-Mail to a more widely seen
> review list.
>
> * Invididuals can also edit a config file to watch individual files /
> glob patterns of files, e.g. src/main.c or src/crypto*
I implemented something like this back when we were using Subversion,
but it didn't get much use and seemed like more configuration hassle
than it was worth.
If this were implemented and I asked for notifications about a
particular file, and a particular reference change affects the file,
what should I see?
* The summary email for the reference change (yes/no)?
* Detail emails for all commits within the reference change, or only for
the individual commits that modify the file?
* Should the detail emails include the full patch for the corresponding
commit, or only the diffs affecting the file(s) of interest? (The
latter would start to get expensive, because the script would have to
generate individual emails per subscriber instead of letting sendmail
fan the emails out across all subscribers.)
> I think a good way to support that would be to have either a path to a
> config file with those watch specs, or a command so you could run "git
> show ..." on some repo users can push to.
*How* this feature would be configured depends strongly on how the repo
is hosted. For example, gitolite has a well-developed scheme for how
the server should be configured, and it would make sense to work
together with that. Other people might configure user access via LDAP
or Apache.
> But overall it's very nice. I'll make some time to test it in my
> organization (with lots of commits and people reading commit e-mails).
Cool, thanks!
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [RFC/PATCH] __git_ps1: migrate out of contrib/completion
From: Todd Zullinger @ 2012-11-08 13:19 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Danny Yates, git@vger.kernel.org, Anders Kaseorg,
Felipe Contreras, Ted Pavlic, SZEDER Gábor, Dan McGee
In-Reply-To: <20121025074549.GC15790@elie.Belkin>
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
Jonathan Nieder wrote:
> Different installers put the git-prompt.sh shell library at different
> places on the installed system, so there is no shared location users
> can count on:
>
> Fedora - /etc/profile.d/git-prompt.sh
FWIW, we moved it to /usr/share/git-core/contrib/completion/ -- it was
only ever in /etc/profile.d in an unreleased version of Fedora for a
short time. (Side note: at some point, we'll likely install most or
all of contrib under /usr/share/git-core/contrib in Fedora.)
Having it in a more standard location would be excellent, it would
avoid bugs like: https://bugzilla.redhat.com/show_bug.cgi?id=854061 :)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Oh, very funny! Now tell the one that doesn't suck.
-- Stewie Griffin
[-- Attachment #2: Type: application/pgp-signature, Size: 543 bytes --]
^ permalink raw reply
* Re: bare vs non-bare <1.7 then >=1.7 ?
From: Carlos Martin Nieto @ 2012-11-08 13:26 UTC (permalink / raw)
To: Mihamina Rakotomandimby; +Cc: Git Issues
In-Reply-To: <509B8552.4080303@rktmb.org>
Mihamina Rakotomandimby <mihamina@rktmb.org> writes:
> Hi all,
>
> We're on the way to have our first project using Git.
> We're currently mostly using Hg (90%) & SVN (10%).
>
> When experimenting in order to train some colleagues, I saw that If I
> clone a repository, I couldn't push to it because it was a non-bare
> one.
> Searchin for some explanations, I found this ressource:
> http://www.bitflop.com/document/111
>
> It's told to be reliable information for Git < v1.7.
>
> What would be different for Git > 1.7 so that I could be up to date
> with the facts?
Bare vs. non-bare hasn't changed. The reasoning behind the two types
hasn't changed and is pretty fundamental. There is no reason for it to
change.
cmn
^ permalink raw reply
* git-svn with ignore-paths misses/skips some revisions during fetch
From: McHenry, Matt @ 2012-11-08 13:50 UTC (permalink / raw)
To: git@vger.kernel.org
My company has a fairly large SVN repository, and I'm running into a bug with git-svn where some revisions aren't being fetched.
The repository has a standard trunk/tags/branches layout, but there are some top-level directories under trunk/ that clearly don't belong in Git, and some that do. So, I've been experimenting with two approaches: a single git-svn clone that uses 'ignore-paths' to exclude the stuff that I don't want; and a series of per-subdir clones that use "fetch = trunk/<subdir>:refs/remotes/trunk" to pull in only that subdir.
The problem is that the 'ignore-paths' approach sometimes misses commits during a fetch, and then at some later time will "realize" it and squash those changes onto some other, unrelated commit. (I've never seen this happen with the per-subdir 'fetch' approach.) Here are three commits in SVN:
$ svn log -v -r 172602 -r 172605 -r 172626 svn://dev
------------------------------------------------------------------------
r172602 | matt | 2012-10-31 16:03:08 -0400 (Wed, 31 Oct 2012) | 1 line
Changed paths:
M /branches/localization-merge/buildprocess/antfiles/dmg.xml
D /branches/localization-merge/buildprocess/resources/CDs/JavaApplicationStub
M /branches/localization-merge/buildprocess/resources/launchanywhere/Cognitive Tutor.app.zip
update to use newer java application stub
------------------------------------------------------------------------
r172605 | matt | 2012-10-31 16:29:25 -0400 (Wed, 31 Oct 2012) | 1 line
Changed paths:
M /branches/localization-merge/buildprocess/antfiles/dmg.xml
M /branches/localization-merge/buildprocess/antfiles/lmstree.xml
ensure that sdk-fe code is installed; fix to get correct app-dir value for antcalls; add problem authoring tool
------------------------------------------------------------------------
r172626 | leslie | 2012-11-01 08:49:36 -0400 (Thu, 01 Nov 2012) | 1 line
Changed paths:
M /branches/localization-merge/authoring/sdk/src/sdk-cc/src/main/java/cl/sdk/tdde/problemspace/problemtypes/geo/area/AreaPerimeterTutorInstance_PPV.java
check the right shape-values for the gn
------------------------------------------------------------------------
The first two are not to be found in git: 'git log --all --grep 17260[25]' returns nothing. However, the third commit is there, and has had the changes from the earlier two (and some others) squashed into it somehow:
$ git log --grep 172626 --numstat --summary
commit 6d9a10abc17c74396e07bb4bc7692059ac0e8b99
Author: leslie <leslie@752fcc94-cd22-0410-baa8-ef54ac2c6973>
Date: Thu Nov 1 12:49:36 2012 +0000
check the right shape-values for the gn
git-svn-id: svn://dev.carnegielearning.com/branches/localization-merge@172626 752fcc94-cd22-0410-baa8-ef54ac2c6973
13 8 authoring/sdk/src/sdk-cc/src/main/java/cl/sdk/tdde/problemspace/problemtypes/geo/area/AreaPerimeterTutorInstance_PPV.java
11 2 buildprocess/antfiles/dmg.xml
2 0 buildprocess/antfiles/lmstree.xml
- - buildprocess/resources/CDs/JavaApplicationStub
- - buildprocess/resources/launchanywhere/Cognitive Tutor.app.zip
0 25 runtime/sdk-be/src/main/resources/cl/sdk/common/localized_words_es.properties
9815 5143 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules
773 5 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules_strings
773 5 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules_strings_es
1562 79 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes
261 3 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes_strings
261 3 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes_strings_es
217 17 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ttspec
25 0 runtime/sdk-be/src/main/resources_es/cl/sdk/common/localized_words_es.properties
246 0 runtime/ui/src/main/resources/tp-tx-formula-sheet_es.html
delete mode 100755 buildprocess/resources/CDs/JavaApplicationStub
delete mode 100644 runtime/sdk-be/src/main/resources/cl/sdk/common/localized_words_es.properties
create mode 100644 runtime/sdk-be/src/main/resources_es/cl/sdk/common/localized_words_es.properties
create mode 100644 runtime/ui/src/main/resources/tp-tx-formula-sheet_es.html
The directories on the server are:
$ svn ls svn://dev/trunk
IDEs/
QA-automation/
authoring/
bugtracking/
buildprocess/
curriculum/
doc/
images/
installer/
lib/
misc-tools/
research/
runtime/
scripts/
serversearch/
user-assistance/
web/
My config file is:
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[svn-remote "svn"]
url = svn://dev.carnegielearning.com
fetch = trunk:refs/remotes/trunk
ignore-paths="^(trunk|tags/[^/]*|branches/[^/]*)/(doc|doc-old|IDEs|images|marathon-testing|QA-automation|research|Sikuli-Automation|bugtracking)/"
branches = branches/{sdk-bug-258,2007-Q2-problemcounter,2008-Q2-bugfix,WEBEQ-REDUCTION,proof-gng,2009-Q2-marathon,2008-Q4,2009-Q4-bugfix,2009-Q2-bugfix-client,modules,2009-Q2-bugfix,2007-Q2-webstart,2011-Q3-math-lounge,2011-Q3-nyc,2011-Q2,2011-Q3-bugfix,cstoy,2010-Q2-bugfix,localization,localization-merge,2012-Q2-bugfix,hs_web_20120524,2012-research-casl,2012-Q3-math-208-9,2012-Q3-aug-localization}:refs/remotes/branches/*
tags = tags/{webeq-3.7,2009-Q2-release,2010-Q2-release,ui-old-impl-code,2011-Q3-release,2011-Q2-release,2012-Q2-release}:refs/remotes/tags/*
My git and OS versions are:
$ uname -a
Linux alpha 3.3.8-gentoo #1 SMP PREEMPT Thu Jul 26 21:25:22 EDT 2012 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux
$ git svn --version
git-svn version 1.7.8.6 (svn 1.6.17)
On the svn server, I have:
mmchenry@dev:~$ svnserve --version
svnserve, version 1.6.16 (r1073529)
compiled Mar 4 2011, 09:05:11
Matt McHenry
Software Developer
Carnegie Learning, Inc.
(888) 851-7094 x150 toll free
(412) 690-2444 fax
mmchenry@carnegielearning.com
www.carnegielearning.com
Decision 2012: Election Math | Engaging Video Content | FREE Interactive Math Problems
http://www.nbclearn.com/portal/site/learn/decision2012
^ permalink raw reply
* three questions: proper forum? & reverting changes to the working directory
From: McKown, John @ 2012-11-08 14:26 UTC (permalink / raw)
To: 'git@vger.kernel.org'
1) is this the proper forum for asking general git usage questions, such as "how to"? If not, what is?
2) I am unsure that I did things the "proper" way. I have a git maintained subdirectory. I made some changes and saved them in the working directory, but did not "git add" or "git commit" them. I then decided that I really messed up what I was doing (basically reformatting some source code). So to revert the changes back to what was last committed, I did a "git reset --hard HEAD". I think this is the proper way. But I picked up that command in the section of the documentation which was talking about abandoning a "git merge" attempt. What I did worked, but is it the proper way? If not, what is?
3) More generically, suppose I have a file in my working directory that I want to put back the way it was "n" commits ago. The best that I can see, so far, is "git show HEAD~n:file >|file", replacing the "n" and "file" with appropriate values.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mckown@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
^ permalink raw reply
* RE: three questions: proper forum? & reverting changes to the working directory
From: McKown, John @ 2012-11-08 14:39 UTC (permalink / raw)
To: McKown, John, 'git@vger.kernel.org'
In-Reply-To: <A6B9336CDB62BB46B9F8708E686A7EA0115BAA1404@NRHMMS8P02.uicnrh.dom>
Well, a message I read after posting seems to have answered question #3. I'll look at "git checkout", which ignorant me thought was only used to change branches.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mckown@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of McKown, John
> Sent: Thursday, November 08, 2012 8:26 AM
> To: 'git@vger.kernel.org'
> Subject: three questions: proper forum? & reverting changes to the
> working directory
>
> 1) is this the proper forum for asking general git usage questions,
> such as "how to"? If not, what is?
>
> 2) I am unsure that I did things the "proper" way. I have a git
> maintained subdirectory. I made some changes and saved them in the
> working directory, but did not "git add" or "git commit" them. I then
> decided that I really messed up what I was doing (basically
> reformatting some source code). So to revert the changes back to what
> was last committed, I did a "git reset --hard HEAD". I think this is
> the proper way. But I picked up that command in the section of the
> documentation which was talking about abandoning a "git merge" attempt.
> What I did worked, but is it the proper way? If not, what is?
>
> 3) More generically, suppose I have a file in my working directory that
> I want to put back the way it was "n" commits ago. The best that I can
> see, so far, is "git show HEAD~n:file >|file", replacing the "n" and
> "file" with appropriate values.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
>
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone *
> john.mckown@healthmarkets.com * www.HealthMarkets.com
>
> Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the
> original message. HealthMarkets(r) is the brand name for products
> underwritten and issued by the insurance subsidiaries of HealthMarkets,
> Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life
> Insurance Company of TennesseeSM and The MEGA Life and Health Insurance
> Company.SM
>
>
> --
> 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: three questions: proper forum? & reverting changes to the working directory
From: Konstantin Khomoutov @ 2012-11-08 14:51 UTC (permalink / raw)
To: McKown, John; +Cc: 'git@vger.kernel.org'
In-Reply-To: <A6B9336CDB62BB46B9F8708E686A7EA0115BAA1404@NRHMMS8P02.uicnrh.dom>
On Thu, 8 Nov 2012 08:26:22 -0600
"McKown, John" <John.McKown@healthmarkets.com> wrote:
> 1) is this the proper forum for asking general git usage questions,
> such as "how to"? If not, what is?
This list is okay for the general usage questions.
But since it's the place where the development questions are discussed
as well, and patches get posted, you might find its signal-to-noise
ratio to be not very convenient for a casual user.
For "mere mortals", we have another list, git-users, hosted on Google
Groups [1]. It deals only with problems Git newbies have with Git.
> 2) I am unsure that I did things the "proper" way. I have a git
> maintained subdirectory. I made some changes and saved them in the
> working directory, but did not "git add" or "git commit" them. I then
> decided that I really messed up what I was doing (basically
> reformatting some source code). So to revert the changes back to what
> was last committed, I did a "git reset --hard HEAD". I think this is
> the proper way. But I picked up that command in the section of the
> documentation which was talking about abandoning a "git merge"
> attempt. What I did worked, but is it the proper way? If not, what
> is?
Yes, that was the proper way. A failed Git merge attempt could be
considered as just another case of a messed-up state of the work tree
and the index.
You might want to read the "Reset Demystified" [2] document for a
friendly descriptions of how different ways to invoke `git reset`
affect the repository, the index and the work tree.
>
> 3) More generically, suppose I have a file in my working directory
> that I want to put back the way it was "n" commits ago. The best that
> I can see, so far, is "git show HEAD~n:file >|file", replacing the
> "n" and "file" with appropriate values.
`git checkout` is able to fetch specific versions of the specified
files if called like this:
$ git checkout HEAD~n -- filename
1. http://groups.google.com/group/git-users/
2. http://git-scm.com/2011/07/11/reset.html
^ permalink raw reply
* Re: three questions: proper forum? & reverting changes to the working directory
From: Andy Hawkins @ 2012-11-08 14:54 UTC (permalink / raw)
To: git
In-Reply-To: <A6B9336CDB62BB46B9F8708E686A7EA0115BAA1404@NRHMMS8P02.uicnrh.dom>
Hi,
In article <A6B9336CDB62BB46B9F8708E686A7EA0115BAA1404@NRHMMS8P02.uicnrh.dom>,
McKown, John<John.McKown@healthmarkets.com> wrote:
> 1) is this the proper forum for asking general git usage questions, such
> as "how to"? If not, what is?
I'd say that here is fine. #git on freenode is also a good source of advice.
> 2) I am unsure that I did things the "proper" way. I have a git maintained
> subdirectory. I made some changes and saved them in the working
> directory, but did not "git add" or "git commit" them. I then decided
> that I really messed up what I was doing (basically reformatting some
> source code). So to revert the changes back to what was last committed, I
> did a "git reset --hard HEAD". I think this is the proper way. But I
> picked up that command in the section of the documentation which was
> talking about abandoning a "git merge" attempt. What I did worked, but is
> it the proper way? If not, what is?
The easiest answer to this is run 'git status'. It'll list the files in
various states, and tell you how to undo the changes.
Andy
^ permalink raw reply
* Re: bare vs non-bare <1.7 then >=1.7 ?
From: Jeff King @ 2012-11-08 14:59 UTC (permalink / raw)
To: Carlos Martin Nieto; +Cc: Mihamina Rakotomandimby, Git Issues
In-Reply-To: <87zk2sz0mn.fsf@flaca.cmartin.tk>
On Thu, Nov 08, 2012 at 02:26:40PM +0100, Carlos Martín Nieto wrote:
> > When experimenting in order to train some colleagues, I saw that If I
> > clone a repository, I couldn't push to it because it was a non-bare
> > one.
> > Searchin for some explanations, I found this ressource:
> > http://www.bitflop.com/document/111
> >
> > It's told to be reliable information for Git < v1.7.
> >
> > What would be different for Git > 1.7 so that I could be up to date
> > with the facts?
>
> Bare vs. non-bare hasn't changed. The reasoning behind the two types
> hasn't changed and is pretty fundamental. There is no reason for it to
> change.
Right. The key thing that changed in git v1.7 is that we started warning
about and denying an operation that had always been dangerous, and that
is why the referenced document mentions that version.
-Peff
^ permalink raw reply
* Re: Revert option for git add --patch
From: Jeff King @ 2012-11-08 15:15 UTC (permalink / raw)
To: Jonathon Mah; +Cc: git@vger.kernel.org, Nathan Broadbent
In-Reply-To: <EE89F0A1-1C07-4597-B654-035F657AD09F@me.com>
On Thu, Nov 08, 2012 at 12:57:19AM -0800, Jonathon Mah wrote:
> I find myself performing similar actions to you: using git add -p to
> stage hunks, sometimes editing the staged patch; and keeping mental
> notes of things I wanted to revert, sometimes changing them in the
> editor in another window, and sometimes reverting them after the add
> session with git checkout -p).
Yeah, I often use a similar workflow. A related one is:
(1) Make lots of unrelated changes in the working tree.
$ hack hack hack
(2) Pick out hunks for the first commit.
$ git add -p
(3) Put the rest of the changes aside.
$ git stash -k
(4) Test (and possibly tweak) the result, then commit.
$ make test
$ git commit -m "topic 1"
(5) Bring back the stashed changes.
$ git stash pop
(6) If there are still interesting changes, goto step 2.
(7) Otherwise, discard with "git reset --hard" or "git checkout -p".
I.e., iterating on the changes to put them into several different
commits (and achieving a clean, testable state before making each
commit).
The downside of these workflows is that you have to say "no" to hunks
multiple times (one per iteration) instead of just sorting them in a
single pass. This works OK in practice, but it might be nice to have a
tool that makes a single pass and lets you drop hunks into buckets
(topic 1 vs topic 2 vs discard), and then apply the buckets in order,
stopping to test, tweak, and commit after each one.
> The interactive staging-and-editing tool could be improved, but I'm
> not sure that tool should be called 'git add -p'. git add doesn't
> touch the working tree — at least I hope not, because I wouldn't
> expect it.
Right. I think the idea of one-pass tool is a good one, but it should
not be called "git add -p".
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] launch_editor: ignore SIGINT while the editor has control
From: Jeff King @ 2012-11-08 15:33 UTC (permalink / raw)
To: Paul Fox; +Cc: git, Krzysztof Mazur, gitster
In-Reply-To: <20121107233515.107ED2E8089@grass.foxharp.boston.ma.us>
On Wed, Nov 07, 2012 at 06:35:15PM -0500, Paul Fox wrote:
> the user's editor likely catches SIGINT (ctrl-C). but if the user
> spawns a command from the editor and uses ctrl-C to kill that command,
> the SIGINT will likely also kill git itself. (depending on the
> editor, this can leave the terminal in an unusable state.)
>
> Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
Thanks, I think this makes sense.
> krzysztof wrote:
> ...
> > editor.c: In function 'launch_editor':
> > editor.c:42:3: warning: implicit declaration of function 'sigchain_push' [-Wimplicit-function-declaration]
> > editor.c:44:3: warning: implicit declaration of function 'sigchain_pop' [-Wimplicit-function-declaration]
>
> sigh. i had that initially, lost the patch, and then recreated
> without it. but i'm surprised my build (i did rebuild! :-) doesn't
> emit those errors. in any case, here's the fixed patch.
gcc will not warn about implicit declarations by default; try compiling
with "-Wall".
-Peff
^ permalink raw reply
* Re: [RFC] Add a new email notification script to "contrib"
From: Ævar Arnfjörð Bjarmason @ 2012-11-08 15:38 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Andy Parkins, Sitaram Chamarty, Stefan Näwe,
Junio C Hamano, Marc Branchaud, Matthieu Moy
In-Reply-To: <509BA2E7.4080102@alum.mit.edu>
On Thu, Nov 8, 2012 at 1:17 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote:
>> [...]
>
> I'm glad it's getting some use. Thanks for the feedback.
>
>> I'll test it out some more, the issues I've had with it so far in
>> migrating from the existing script + some custom hacks we have to it
>> have been:
>>
>> * Overly verbose default templates, easy to overwrite now. Might send
>> patches for some of them.
>
> The templating is currently not super flexible nor very well documented,
> but simple changes should be easy enough. I mostly carried over the
> text explanations from the old post-receive-email script; it is true
> that they are quite verbose.
>
>> * No ability to link to a custom gitweb, probably easy now.
>
> What do you mean by "a custom gitweb"? What are the commitmail issues
> involved?
Just for the E-Mail to include a link to
http://gitweb.example.com/git/....?h=$our_hash etc.
>> * If someone only pushes one commit I'd like to only have one e-mail
>> with the diff, but if they push multiple commits I'd like to have a
>> summary e-mail and replies to that which have the patches.
>>
>> It only seemed to support the latter mode, so you send out two
>> e-mails for pushing one commit.
>
> That's correct, and I've also thought about the feature that you
> described. I think it would be pretty easy to implement; it is only not
> quite obvious to which mailing list(s?) such emails should be sent.
>
>> * Ability to limit the number of lines, but not line length, that's
>> handy for some template repositories. Should be easy to add
>
> Should too-long lines be folded or truncated? Either way, it should be
> pretty straightforward (Python even has a textwrap module that could be
> used).
>
>> But in addition to that we have our own custom E-Mail notification
>> scripts for:
>>
>> * People can subscribe to changes to certain files. I.e. if you
>> modify very_important.c we'll send an E-Mail to a more widely seen
>> review list.
>>
>> * Invididuals can also edit a config file to watch individual files /
>> glob patterns of files, e.g. src/main.c or src/crypto*
>
> I implemented something like this back when we were using Subversion,
> but it didn't get much use and seemed like more configuration hassle
> than it was worth.
>
> If this were implemented and I asked for notifications about a
> particular file, and a particular reference change affects the file,
> what should I see?
>
> * The summary email for the reference change (yes/no)?
>
> * Detail emails for all commits within the reference change, or only for
> the individual commits that modify the file?
>
> * Should the detail emails include the full patch for the corresponding
> commit, or only the diffs affecting the file(s) of interest? (The
> latter would start to get expensive, because the script would have to
> generate individual emails per subscriber instead of letting sendmail
> fan the emails out across all subscribers.)
I think just sending the individual patch e-mails to all people who
subscribe to paths that got changed in that patch that match their
watchlist makes sense.
That's how an internal E-mailing script that I'm hopign to replace
with this works.
That script *also* supports sending the whole batch of patches pushed
in that push to someone watching any file that got modified in one of
the patches, in case you also want to get other stuff pushed in pushes
for files you're interested in.
But it doesn't generate individual E-Mails per recipient. I think that
way lies madness because as you rightly point out you have to start
worrying about the combinatorial nightmare of generating the E-mails
per subscriber.
>> I think a good way to support that would be to have either a path to a
>> config file with those watch specs, or a command so you could run "git
>> show ..." on some repo users can push to.
>
> *How* this feature would be configured depends strongly on how the repo
> is hosted. For example, gitolite has a well-developed scheme for how
> the server should be configured, and it would make sense to work
> together with that. Other people might configure user access via LDAP
> or Apache.
>
>> But overall it's very nice. I'll make some time to test it in my
>> organization (with lots of commits and people reading commit e-mails).
^ permalink raw reply
* Re: Long clone time after "done."
From: Jeff King @ 2012-11-08 15:56 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5ASL1UPfzUmfXqACuYuGhXQjJLqbsjq7dfpRpF4K-hZFtA@mail.gmail.com>
On Wed, Nov 07, 2012 at 11:32:37AM -0600, Uri Moszkowicz wrote:
> #4 parse_object (sha1=0xb0ee98
> "\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D") at
> object.c:212
> #5 0x00000000004ae9ec in handle_one_ref (path=0xb0eec0
> "refs/tags/<removed>", sha1=0xb0ee98
> "\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D", flags=2,
> cb_data=<optimized out>) at pack-refs.
>
> [...]
>
> It looks like handle_one_ref() is called for each ref and most result
> in a call to read_sha1_file().
Right. When generating the packed-refs file, we include the "peeled"
reference for a tag (i.e., the commit that a tag object points to). So
we have to actually read any tag objects to get the value.
The upload-pack program generates a similar list, and I recently added
some optimizations. This code path could benefit from some of them by
using "peel_ref" instead of hand-rolling the tag dereferencing. The main
optimization, though, is reusing peeled values that are already in
packed-refs; we would probably need some additional magic to reuse the
values from the source repository.
However:
> It only takes a second or so for each call but when you have thousands
> of them (one for each ref) it adds up.
I am more concerned that it takes a second to read each tag. Even in my
pathological tests for optimizing upload-pack, peeling 50,000 refs took
only half a second.
> Adding --single-branch --branch <branch> doesn't appear to help as
> it is implemented afterwards. I would like to debug this problem
> further but am not familiar enough with the implementation to know
> what the next step is. Can anyone offer some suggestions? I don't see
> why a clone should be dependent on an O(#refs) operations.
Does this patch help? In a sample repo with 5000 annotated tags, it
drops my local clone time from 0.20s to 0.11s. Which is a big percentage
speedup, but this code isn't taking a long time in the first place for
me.
---
diff --git a/pack-refs.c b/pack-refs.c
index f09a054..3344749 100644
--- a/pack-refs.c
+++ b/pack-refs.c
@@ -40,13 +40,9 @@ static int handle_one_ref(const char *path, const unsigned char *sha1,
fprintf(cb->refs_file, "%s %s\n", sha1_to_hex(sha1), path);
if (is_tag_ref) {
- struct object *o = parse_object(sha1);
- if (o->type == OBJ_TAG) {
- o = deref_tag(o, path, 0);
- if (o)
- fprintf(cb->refs_file, "^%s\n",
- sha1_to_hex(o->sha1));
- }
+ unsigned char peeled[20];
+ if (!peel_ref(path, peeled))
+ fprintf(cb->refs_file, "^%s\n", sha1_to_hex(peeled));
}
if ((cb->flags & PACK_REFS_PRUNE) && !do_not_prune(flags)) {
^ permalink raw reply related
* Re: [RFC] Add a new email notification script to "contrib"
From: Marc Branchaud @ 2012-11-08 16:03 UTC (permalink / raw)
To: Michael Haggerty
Cc: Ævar Arnfjörð Bjarmason, git, Andy Parkins,
Sitaram Chamarty, Stefan Näwe, Junio C Hamano, Matthieu Moy
In-Reply-To: <509B7E6B.1030407@alum.mit.edu>
On 12-11-08 04:42 AM, Michael Haggerty wrote:
> On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> On 07/14/2012 08:59 AM, mhagger@alum.mit.edu wrote:
>>>>
>>>> Add a new Python script, contrib/hooks/post-receive-multimail.py, that
>>>> can be used to send notification emails describing pushes into a git
>>>> repository. [...]
>>>
>>>
>>> Thanks to everybody for your feedback. I will try to incorporate it in a
>>> new version of the script, which I will put forward as a replacement for
>>> contrib/hooks/post-receive-email rather than as an alternative. But I have
>>> very little open-sourcing time these days, and will be on vacation next
>>> week, so please be patient (or feel free to lend a hand if you are so
>>> inclined).
>>
>> I'm curious as to whether you got around to this? I'd be interested in
>> updates on this script.
I installed the script in our main repository here. Some folks complained
about the "flood" of emails for large pushes, but having separate mailing
lists solved that.
Others really appreciate the individual messages with full patches. It's a
challenge to create one script that can satisfy all users, but IMHO this
comes pretty close.
> Thanks for asking. I have made many of the changes that were requested
> and/or I had planned:
>
> * Tentatively renamed the system to git-multimail
>
> * Store the configuration in namespace "multimailhook.*" instead of
> "hooks.*".
>
> * Reinstated (optional) support for including shortlogs since the last
> tag in announce emails.
>
> * Script to migrate post-receive-email configuration to the equivalent
> git-multimail config.
>
> * Better documentation (including of the migration process).
>
> * Made it easier to use Python code to customize the script's behavior
> (by allowing it to be imported as a Python module), plus a demo script
> showing this usage.
I look forward to trying out your updates. One thing I had to do to the
original script was override get_envelopesender() in GenericEnvironment to
use $USER if hooks.envelopesender is not set. (This is what the old
post-receive-email script does.)
This script is one of a couple of things on my git back-burner. Hopefully
things will settle down here soon and I'll be able to get back to some git
hacking in the next few weeks.
M.
^ permalink raw reply
* Re: [RFC] Add a new email notification script to "contrib"
From: Marc Branchaud @ 2012-11-08 16:24 UTC (permalink / raw)
To: Michael Haggerty
Cc: Ævar Arnfjörð Bjarmason, git, Andy Parkins,
Sitaram Chamarty, Stefan Näwe, Junio C Hamano, Matthieu Moy
In-Reply-To: <509BA2E7.4080102@alum.mit.edu>
On 12-11-08 07:17 AM, Michael Haggerty wrote:
> On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote:
>> [...]
>
> I'm glad it's getting some use. Thanks for the feedback.
>
>> I'll test it out some more, the issues I've had with it so far in
>> migrating from the existing script + some custom hacks we have to it
>> have been:
>>
>> * Overly verbose default templates, easy to overwrite now. Might send
>> patches for some of them.
>
> The templating is currently not super flexible nor very well documented,
> but simple changes should be easy enough. I mostly carried over the
> text explanations from the old post-receive-email script; it is true
> that they are quite verbose.
>
>> * No ability to link to a custom gitweb, probably easy now.
>
> What do you mean by "a custom gitweb"? What are the commitmail issues
> involved?
We would also like to have a gitweb link in the summary email, like Ævar
describes.
>> * If someone only pushes one commit I'd like to only have one e-mail
>> with the diff, but if they push multiple commits I'd like to have a
>> summary e-mail and replies to that which have the patches.
>>
>> It only seemed to support the latter mode, so you send out two
>> e-mails for pushing one commit.
>
> That's correct, and I've also thought about the feature that you
> described. I think it would be pretty easy to implement; it is only not
> quite obvious to which mailing list(s?) such emails should be sent.
Overall, what should be the approach to the separate mailing lists?
Maybe I don't understand how the script is meant to work. We configured
things here with 'mailinglist' and 'commitlist' set to different lists. Now
if someone wants to get both the summary and per-commit emails, they need to
be on both lists. If I understand correctly, if all 4 mailing lists are
distinct, someone who wants all the emails needs to be on all of them. This
seems a little awkward.
I'd like there to be one list that always gets everything, and the other
lists should get subsets of the everything list.
M.
^ 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