On Fri, May 24, 2013 at 03:42:37PM +, Jim Greenleaf wrote:
> John Keeping 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
John Keeping 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 would
On Fri, May 24, 2013 at 03:34:26PM +, Jim Greenleaf wrote:
> Phil Hord 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 --sh
Phil Hord 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: send the l
On Thu, May 23, 2013 at 7:20 PM, Junio C Hamano wrote:
> Thomas Rast 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 -- tha
- Original Message -
> From: "Thomas Rast"
> Sent: Thursday, May 23, 2013 6:56:50 PM
> Subject: Re: git stash deletes/drops changes of
>
> Junio C Hamano writes:
>
> > Thomas Rast writes:
> >
> > > So maybe it would be time to
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 cor
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 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 u
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.
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:
> >
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.
> >
>
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
>
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 ov
Thomas Rast 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 annoying ha
Junio C Hamano writes:
> Thomas Rast 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-sta
Thomas Rast 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 properly.
>
Jim Greenleaf writes:
> Adeodato Simó 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 in
Adeodato Simó 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 decision ab
19 matches
Mail list logo
