On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
Just to clear up on what the best practice is, I'd imagine the setup
to be something like:
(a) Makefile contains inclusion of Makefile.include.
(b) There is a file like Makefile.include.template containing
a
On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:
On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
Just to clear up on what the best practice is, I'd imagine the setup
to be something like:
(a) Makefile contains inclusion of Makefile.include.
(b)
On Fri, May 24, 2013 at 11:40:07AM +0200, Petr Baudis wrote:
On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:
On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
Just to clear up on what the best practice is, I'd imagine the setup
to be something like:
(a)
On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:
I don't see anything wrong with having a template file documenting the
parameters, but I think it's important that there are sensible defaults
in place when the user's configuration file does not specify a value for
a parameter. It
On Fri, May 24, 2013 at 12:14:16PM +0200, Petr Baudis wrote:
On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:
I don't see anything wrong with having a template file documenting the
parameters, but I think it's important that there are sensible defaults
in place when the user's
On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:
So that it continues to Just Work for people using buildroot but you can
create Makefile.config to override those defaults.
Indeed, that doesn't cover some corner cases of (c), but that's not a
big deal in practice I guess.
My
On Fri, May 24, 2013 at 01:03:22PM +0200, Petr Baudis wrote:
On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:
So that it continues to Just Work for people using buildroot but you can
create Makefile.config to override those defaults.
Indeed, that doesn't cover some corner
- Original Message -
From: Thomas Rast tr...@inf.ethz.ch
Sent: Thursday, May 23, 2013 6:56:50 PM
Subject: Re: git stash deletes/drops changes of
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
So maybe it would be time to first make up our
On Thu, May 23, 2013 at 7:20 PM, Junio C Hamano gits...@pobox.com wrote:
Thomas Rast tr...@inf.ethz.ch writes:
What are the workflows that are helped if we had such a bit? If
we need to support them, I think you need a real --ignore-changes
bit, not an abuse of --assume-unchanged.
I gather
Phil Hord phil.hord at gmail.com writes:
The wording of --ignore-changes suffers the same lack of clarity that
--assume-unchanged does.
What's better? --sequester is probably too obscure. Maybe --hold.
Or --silence. Or --shut-up.
How about --freeze?
--
To unsubscribe from this list:
On Fri, May 24, 2013 at 03:34:26PM +, Jim Greenleaf wrote:
Phil Hord phil.hord at gmail.com writes:
The wording of --ignore-changes suffers the same lack of clarity that
--assume-unchanged does.
What's better? --sequester is probably too obscure. Maybe --hold.
Or --silence. Or
John Keeping john at keeping.me.uk writes:
I wonder if this would be better as a file rather than another option to
git-update-index. We already have .git/info/exclude so we could add
.git/info/freeze or .git/info/local with the same syntax as the normal
.gitignore file.
.git/info/freeze
On Fri, May 24, 2013 at 03:42:37PM +, Jim Greenleaf wrote:
John Keeping john at keeping.me.uk writes:
I wonder if this would be better as a file rather than another option to
git-update-index. We already have .git/info/exclude so we could add
.git/info/freeze or .git/info/local with
Adeodato Simó dato at net.com.org.es writes:
I was unpleasantly surprised to discover yesterday that doing `git
stash` on a repository where I had previously run `git update-index
--assume-unchanged FOO` completely lost all changes I had in file FOO.
I just ran into this today.
Was a
Jim Greenleaf james.a.greenl...@gmail.com writes:
Adeodato Simó dato at net.com.org.es writes:
I was unpleasantly surprised to discover yesterday that doing `git
stash` on a repository where I had previously run `git update-index
--assume-unchanged FOO` completely lost all changes I had in
Thomas Rast tr...@inf.ethz.ch writes:
So maybe it would be time to first make up our minds as to what
--assume-unchanged should actually mean:
* Ignore changes to a tracked file, but treat them as valuable. In
this case we'd have to make sure that failures like git-stash's are
handled
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
So maybe it would be time to first make up our minds as to what
--assume-unchanged should actually mean:
* Ignore changes to a tracked file, but treat them as valuable. In
this case we'd have to make sure
Thomas Rast tr...@inf.ethz.ch writes:
What are the workflows that are helped if we had such a bit? If
we need to support them, I think you need a real --ignore-changes
bit, not an abuse of --assume-unchanged.
I gather -- from #git -- that it's mostly used for config files, which
have an
Hi!
On Fri, May 24, 2013 at 12:56:50AM +0200, Thomas Rast wrote:
It is not --ignore-changes bit, and has never been.
Indeed, it has been my lack of imagination regarding what can go
wrong. I am fine with the changes not being shown in `git diff` and even
not so worried about them being
19 matches
Mail list logo
