26.07.2017 16:23, Jeff King пишет:
In git.git we do something like:
-- >8 --
other: version
cat $< >$@
.PHONY: FORCE
version: FORCE
@git rev-parse HEAD >$@+
@if cmp $@+ $@ >/dev/null 2>&1; then rm $@+; else mv $@+ $@; fi
-- >8 --
Yes, thats a nice recipe that I would be
On Wed, Jul 26, 2017 at 11:40:46AM +0300, Stas Sergeev wrote:
> 26.07.2017 03:36, Jacob Keller пишет:
> > If your goal is to make it so users filling out bug reports have a
> > version, then using git descrsibe and making that be part of your
> > version (based off your tags, and commits) is how p
26.07.2017 03:36, Jacob Keller пишет:
If your goal is to make it so users filling out bug reports have a
version, then using git descrsibe and making that be part of your
version (based off your tags, and commits) is how pretty much every
other project I've worked on does this.
I really don't th
On Sun, Jul 23, 2017 at 12:23 PM, Stas Sergeev wrote:
> 23.07.2017 11:40, Jacob Keller пишет:
>>
>> On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev wrote:
>>>
>>> I wanted some kind of file to use it as a
>>> build dependency for the files that needs
>>> to be re-built when the head changes.
>>> T
24.07.2017 07:02, Jacob Keller пишет:
generally, I'd suggest using "git describe" to output a version based
on tag, and as part of your build system set that in some sort of
--version output of some kind.
I came to the following solution which
looks quite simple (avoids comparing the
output of g
24.07.2017 07:02, Jacob Keller пишет:
generally, I'd suggest using "git describe" to output a version based
on tag, and as part of your build system set that in some sort of
--version output of some kind.
I am not sure I understand that suggestion.
I can use 'git describe' (and that seems to be
On Sun, Jul 23, 2017 at 12:23 PM, Stas Sergeev wrote:
> 23.07.2017 11:40, Jacob Keller пишет:
>>
>> On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev wrote:
>>>
>>> I wanted some kind of file to use it as a
>>> build dependency for the files that needs
>>> to be re-built when the head changes.
>>> T
23.07.2017 11:40, Jacob Keller пишет:
On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev wrote:
I wanted some kind of file to use it as a
build dependency for the files that needs
to be re-built when the head changes.
This works very well besides git gc.
What other method can be used as simply
as t
On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev wrote:
> I wanted some kind of file to use it as a
> build dependency for the files that needs
> to be re-built when the head changes.
> This works very well besides git gc.
> What other method can be used as simply
> as that? git show-ref does not se
21.07.2017 21:56, Junio C Hamano пишет:
Stas Sergeev writes:
I do the following:
$ git rev-parse --symbolic-full-name devel
refs/heads/devel
$ ls -l .git/`git rev-parse --symbolic-full-name devel`
-rw-rw-r-- 1 stas stas 41 июл 21 15:05 .git/refs/heads/devel
This is fine. But after git gc:
$
Stas Sergeev writes:
> I do the following:
>
> $ git rev-parse --symbolic-full-name devel
> refs/heads/devel
> $ ls -l .git/`git rev-parse --symbolic-full-name devel`
> -rw-rw-r-- 1 stas stas 41 июл 21 15:05 .git/refs/heads/devel
>
> This is fine. But after git gc:
>
> $ git rev-parse --symbolic-
Hello.
I do the following:
$ git rev-parse --symbolic-full-name devel
refs/heads/devel
$ ls -l .git/`git rev-parse --symbolic-full-name devel`
-rw-rw-r-- 1 stas stas 41 июл 21 15:05 .git/refs/heads/devel
This is fine. But after git gc:
$ git rev-parse --symbolic-full-name devel
refs/heads/deve
12 matches
Mail list logo
