A switch or setting to --perservemtime sounds like it would be easy to do,
and useful.
It would leave the default behaviour for legacy reasons but allow Zoltan
and others who are willing to do the make clean;make (like me) to have a
useful set of file times.
The nice thing would be that if you're
Thus said to...@acm.org on Wed, 17 Feb 2016 15:43:07 +0200:
> FOSSIL UPDATE BRANCH FILENAME
>
> will merge only that specific file.
Interesting way to get a cherrypick. Does this also include the Q-card
so one knows where the cherrypick comes from?
Thanks,
Andy
--
TAI64 timestamp: 40005
Thus said =?UTF-8?B?Wm9sdMOhbiBLw7Njc2k=?= on Wed, 17 Feb 2016 21:27:26 +1100:
> 1. How do you merge only certain files?
You cannot merge certain files, but you can merge certain checkins. For
example, if you have committed a fix on one branch and want just that
commit on another branch, you
On Wed, Feb 17, 2016 at 3:06 PM, Zoltán Kócsi wrote:
> ...
Nevertheless, the whole issue about not breaking make might be
> debatable. If you generate the dependency files automagically (i.e. gcc
> writes them for you and then make includes them), then if you renamed or
> moved a header form one
> Yes, it does - i know that because i ported those bits to libfossil
> and was very surprised by that behaviour ;).
> [...]
> Fossil NEVER sets the timestamp of checked-out/update'd files to a
> previous time because this completely breaks build tools which use
> timestamps to determine if a build
1. How do you merge only certain files?
The way I deal with the problem you described is with the UPDATE command.
FOSSIL UPDATE BRANCH FILENAME
will merge only that specific file.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http:/
On 2/17/16, Zoltán Kócsi wrote:
>
> In fact, what I saw was that fossil didn't even do that. I checked out
> two branches (with different last mod dates) into two separate
> directories and every file had the same mtime: the current time when I
> checked them out. That is, fossil simply wrote the
On Wed, Feb 17, 2016 at 1:56 PM, Zoltán Kócsi wrote:
> > > 2. Does fossil store the mtime for the files?
> >
> > It doesn't, actually. It _calculates_ the mtime based on the time of
> > the commit containing it. Thus the mtime for all files aligns to time
> > of the commit which last included tha
> > 1. How do you merge only certain files?
> >
>
> AFAIR, you can't. Commit will refuse to commit a partial merge, if i
> recall correctly.
OK, that's one thing I'll need to write a tool to do, then :-(
> > 2. Does fossil store the mtime for the files?
>
> It doesn't, actually. It _calculates_
On Wed, Feb 17, 2016 at 11:27 AM, Zoltán Kócsi wrote:
> I have two questions. I looked at the archives, but only one of the
> issues I found some mentioning of, and even that was not clear-cut.
>
> 1. How do you merge only certain files?
>
AFAIR, you can't. Commit will refuse to commit a partial
I have two questions. I looked at the archives, but only one of the
issues I found some mentioning of, and even that was not clear-cut.
1. How do you merge only certain files?
Let's say, we have two branches, 'release' and 'devel'.
The development branch is fairly different from the current releas
On Monday 29 Dec 2014 06:30:58 Richard Hipp wrote:
> Unfortunately, there is no way to do this for every check-in all at once.
> You would have to go through and create separate tags for each check-in.
> There is probably a way to script this. But it would be better to change
> the names in git pr
Ciao,
On Wed, Jan 7, 2015 at 9:03 AM, Stephan Beal wrote:
> When you move a repo you need to close/re-open it again because its location
> is stored in the checkout db.
thanks! I didn't know that.
Luca
___
fossil-users mailing list
fossil-users@lists.
On Wed, Jan 7, 2015 at 8:52 AM, Luca Ferrari wrote:
> % fossil status
> fossil: repository does not exist or is in an unreadable directory
>
When you move a repo you need to close/re-open it again because its
location is stored in the checkout db.
--
- stephan beal
http://wanderinghorse.n
Ciao,
On Mon, Dec 29, 2014 at 10:17 AM, Baruch Burstein wrote:
> No. The Fossil repo is completely self contained and does not depend in any
> way on the git repo or even on the git-export file it was created from.
>
I've moved the fossil repository file to a location where I'd like to
keep all
On Mon, Dec 29, 2014 at 12:30 PM, Richard Hipp wrote:
> separate tags for each check-in. There is probably a way to script this.
>
fossil tag add user VERSION USERNAME
should do the trick. You'd just need to feed it the list of versions, which
you can fetch with something like:
echo "select b
On Mon, Dec 29, 2014 at 4:17 AM, Baruch Burstein
wrote:
>
>
>> 2) is there a way to change the author name and email of all presents
>> commits?
>>
>
> Once the data is in the Fossil repo it cannot be changed. Any changes have
> to be done either in the git repository before exporting, or on the
On Pon, 2014-12-29 at 11:17 +0200, Baruch Burstein wrote:
> Once the data is in the Fossil repo it cannot be changed. Any changes
> have to be done either in the git repository before exporting, or on
> the exported file before importing. I am not familiar enough with git
> to know if such tools e
On Mon, Dec 29, 2014 at 10:45 AM, Luca Ferrari
wrote:
> Hi all,
> I'm new to fossil, therefore apologize for my trivial questions. I've
> imported a quite big git repository (around 500 GB) to fossil without
> any problem, but:
> 1) if I get it right the fossil repo file must be in the same
> dir
Hi all,
I'm new to fossil, therefore apologize for my trivial questions. I've
imported a quite big git repository (around 500 GB) to fossil without
any problem, but:
1) if I get it right the fossil repo file must be in the same
directory of the git tree, and therefore I cannot place it somewhere
el
20 matches
Mail list logo
