On 10 November 2016 at 10:43, René J.V. Bertin wrote:
>
> How complicated would it be to set up the fork such that you can put custom
> ports in the default branch, and set up another branch to track the official
> ports tree? I have a hunch that it shouldn't be too hard to do in .git/config
> o
Out of curiosity:
The typical situation for ports tree forks will be that the master branch
tracks macports-ports/origin/master while anything personal/custom will be kept
in a personal branch.
How complicated would it be to set up the fork such that you can put custom
ports in the default bra
On 07 Nov 2016, at 16:43 , Lawrence Velázquez wrote:
> No, we should absolutely forbid "$Id$" lines. New ports should not have
> them.
+1
This goes back to CVS. Who needs that? That’s what “git log -1 FILENAME” is
for! :)
On Wednesday November 09 2016 12:09:24 Michael wrote:
> Git is practical. With git, and it took me a while to learn this, when you
> clone a repository, commit to your repository, and then push upstream to the
> clone source, your clone source has both their commits and your commits, and
> can
On 2016-11-09, at 6:18 AM, René J.V. Bertin wrote:
> On Wednesday November 09 2016 13:01:42 Christopher Jones wrote:
>
>> In my view, no it is not practical. Pull requests are to pull one branch,
>> all diffs, from one to another. This is why I maintain the sooner people get
>> use to the ide
On 2016-11-09 15:18, René J.V. Bertin wrote:
> [...] If a change can be
> expressed as "please have a look at my version of this/ese file(s)
> and consider incorporating them", why would you have to jump through
> all kinds of hoops that only increase the chance for error?
Remember we still have T
On Wednesday November 09 2016 13:01:42 Christopher Jones wrote:
>In my view, no it is not practical. Pull requests are to pull one branch, all
>diffs, from one to another. This is why I maintain the sooner people get use
>to the idea of making a separate branch for each piece of work, and pull
On 2016-11-09 13:51, René J.V. Bertin wrote:
> 1- Initially I followed github's suggestions as usual and added a
> README.md (in a first commit), thinking I'd be able to avoid that
> file easily enough. Instead it appears that pull requests can not be
> made for a specific commit or file/directory;
> On 9 Nov 2016, at 12:51 pm, René J.V. Bertin wrote:
>
> Hi,
>
> I've just managed (I think) to fork macports-ports via github.com, add it as
> an additional remote to my working copy of the original, created a topic
> branch in my fork and made a pull request from there.
>
> Questions rais
Hi,
I've just managed (I think) to fork macports-ports via github.com, add it as an
additional remote to my working copy of the original, created a topic branch in
my fork and made a pull request from there.
Questions raised during that process:
1- Initially I followed github's suggestions as
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 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
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 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 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 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
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
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
