> On Nov 7, 2016, at 10:35 AM, Sterling Smith wrote:
>
>
> On Nov 5, 2016, at 1:19AM, Mojca Miklavec wrote:
>
>> On 5 November 2016 at 08:33, Ryan Schmidt wrote:
>>
>>> So I have the impression that my feedback is reaching fewer viewers and is
>>> thus a worse use of my time.
>>
>> I wonde
On Monday November 07 2016 18:04:04 Brandon Allbery wrote:
> > VC?
>
>
> Version control. *Any* version control. RCS and CVS (and before them SCCS)
DOh, of course. I'm more used to the term VCS...
I still find $Id$s extremely practical constructed via special macro as a
static strings in obje
On Mon, Nov 7, 2016 at 5:59 PM, René J.V. Bertin
wrote:
> >The problem with these headers is they force VC to do a lot more work to
>
> VC?
Version control. *Any* version control. RCS and CVS (and before them SCCS)
used, and hacked around, keywords. SVN made most of them go away, and for
diehar
On Monday November 07 2016 16:04:00 Brandon Allbery wrote:
>The problem with these headers is they force VC to do a lot more work to
VC?
>determine when two files are "the same". It's not just a matter of
>convenience; if you do not either hook into git's diff mechanism or be
>*extremely* carefu
> On Nov 7, 2016, at 4:00 PM, Clemens Lang wrote:
>
> Please fix the test in src/macports1.0/tests/macports.test, too.
Oops, sorry.
https://github.com/macports/macports-base/commit/f4f2fbf9062ef8b365b2e291f34889f83883f7f0
vq
On Mon, Nov 7, 2016 at 3:54 AM, René J. V. Bertin
wrote:
> Re: $Id$ headers: I found them quite useful as a quick an unambiguous way
> to
> compare file versions chronologically. Isn't there a way to bring this
> back with
> a pre-commit hook and possibly `git interpret-trailers`?
>
The problem
Hi,
On Mon, Nov 07, 2016 at 09:25:40PM +0100, Lawrence Velázquez wrote:
> src/macports1.0/macports.tcl | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/macports1.0/macports.tcl b/src/macports1.0/macports.tcl
> index 14d628f..6aafa73 100644
> --- a/src/macports1
On Monday November 07 2016 09:31:49 Sterling Smith wrote:
>What is wrong with `git log -1 `? Such as
Nothing, except when it's impractical to execute an external command.
R
> On Nov 7, 2016, at 12:39 PM, Lawrence Velázquez wrote:
>
>> On Nov 7, 2016, at 12:29 PM, René J.V. Bertin wrote:
>>
>> As long as it doesn't cause problems elsewhere I think there
>> shouldn't be any hard rules making this kind of thing impossible.
>> That wouldn't fit in a model where people
> On Nov 7, 2016, at 12:29 PM, René J.V. Bertin wrote:
>
>> On Monday November 07 2016 11:52:17 Lawrence Velázquez wrote:
>>
>> Any sort of Git keyword expansion must happen client-side, which means
>> such keywords/markers would only be useful to developers who choose to
>> configure their loca
On Nov 7, 2016, at 5:15AM, René J.V. Bertin wrote:
>
> Well, I find it very practical to have a quick way to know when a file was
> last changed that doesn't involve git magic like wading through `git blame`
> output or simply invoking an external command. Of course YMMV and it's not
> someth
On Monday November 07 2016 11:52:17 Lawrence Velázquez wrote:
> Any sort of Git keyword expansion must happen client-side, which means
> such keywords/markers would only be useful to developers who choose to
> configure their local repositories appropriately, which means that they
> can never be u
On 07/11/16 16:52, Lawrence Velázquez wrote:
On Nov 7, 2016, at 11:16 AM, René J.V. Bertin wrote:
Well, yes, I was indeed thinking about something more readable than
the old syntax (though I don't see what'd be wrong with making it
compatible with the `what` command).
Any sort of Git keywor
> On Nov 5, 2016, at 1:03 PM, Marko Käning wrote:
>
>> On 04 Nov 2016, at 19:00 , Lawrence Velázquez wrote:
>>
>> Sure. I would encourage committers who want feedback to open as many PRs
>> as they want.
>>
>> (You get a PR! You get a PR! Everybody gets a PR!!!)
>
> good to know.
>
> That’s
> On Nov 7, 2016, at 11:16 AM, René J.V. Bertin wrote:
>
> Well, yes, I was indeed thinking about something more readable than
> the old syntax (though I don't see what'd be wrong with making it
> compatible with the `what` command).
Any sort of Git keyword expansion must happen client-side, whi
On Nov 5, 2016, at 1:19AM, Mojca Miklavec wrote:
> On 5 November 2016 at 08:33, Ryan Schmidt wrote:
>
>> So I have the impression that my feedback is reaching fewer viewers and is
>> thus a worse use of my time.
>
> I wonder if there is a solution for that. (Something like a special
> button
On Monday November 07 2016 10:43:44 Lawrence Velázquez wrote:
>If you want to dynamically insert last-changed information, you can set
>up your own smudge and clean filters in your local repository.
>
>https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion
Well, yes, I wa
> On Nov 2, 2016, at 11:20 AM, Rainer Müller wrote:
>
> Please join us in welcoming the following new MacPorts project member:
>
> - Chris Jones (jones)
Super!
Regards,
Bradley Giesbrecht (pixilla)
> On Nov 7, 2016, at 10:37 AM, Rainer Müller wrote:
>
> Multiple of the affected ports just change the '.cmd' to 'autogen.sh'.
> Would it make sense to have an additional use_autogensh that defaults to
> this and adds dependencies on autoconf, automake, libtool?
This is a good idea. Over 200 por
> On Nov 7, 2016, at 8:15 AM, René J.V. Bertin wrote:
>
> Well, I find it very practical to have a quick way to know when a file
> was last changed that doesn't involve git magic like wading through
> `git blame` output or simply invoking an external command. Of course
> YMMV and it's not somethi
> On Nov 7, 2016, at 6:38 AM, Thibaut Paumard wrote:
>
> I don't know whether I'll use your template (probably not) but at least
> seeing it here taught me a lot about git(hub) commit messages that I'll
> use in this project and others.
>
> I'll welcome finding all this information for reference
On 2016-11-07 12:13, Mihai Moldovan wrote:
> Mihai Moldovan (Ionic) pushed a commit to branch master
> in repository macports-ports.
>
> https://github.com/macports/macports-ports/commit/ce3e478b4aa910e128b737ff7523242ec6e63536
>
> The following commit(s) were added to refs/heads/master by this p
Mazel tov! This is really exciting. My hope is that this will bring greater
exposure to Macports.
Christopher
On Oct 30, 2016 9:54 PM, "Clemens Lang" wrote:
> Good day MacPorts developers and users,
>
> We are pleased to announce that MacPorts has moved to GitHub.
>
> Our Subversion repository
On Monday November 07 2016 03:58:35 Ryan Schmidt wrote:
>I don't think we're interested in doing this, even if it is possible. The Id
>lines were a relic from CVS that we kept when moving to Subversion but it is
>not the Git way so we're removing them.
Well, I find it very practical to have a
Le 04/11/2016 à 18:39, Marko Käning a écrit :
> I do know now what not to do in the future: trying to come up with such kind
> of suggestions - while not being a professional software developer and just
> some guy who tries to support a collaborative initiative like MacPorts to the
> best of his (
On Nov 7, 2016, at 02:54, René J. V. Bertin wrote:
>
> Re: $Id$ headers: I found them quite useful as a quick an unambiguous way to
> compare file versions chronologically. Isn't there a way to bring this back
> with
> a pre-commit hook and possibly `git interpret-trailers`? I've dabbled in
>
As to those who don't have commit access but consider doing pull requests: am I
right that they could set up their working copy of the ports tree to use a
personal fork on github as the default remote for pushing while still pulling
from the official repo? I don't think I've seen that mentioned
Re: $Id$ headers: I found them quite useful as a quick an unambiguous way to
compare file versions chronologically. Isn't there a way to bring this back
with
a pre-commit hook and possibly `git interpret-trailers`? I've dabbled in adding
things to my commit messages but never in modifying the f
28 matches
Mail list logo
