Re: Setting file timestamps to commit time (git-checkout)

2013-12-10 Thread Dominik Vogt
On Tue, Dec 10, 2013 at 08:02:29PM +0100, Andreas Schwab wrote: > Dominik Vogt writes: > > > The second best approach I could think of is to stamp files with the > > timestamp of the last commit that touched that, but I guess that is > > not a cheap operation either. > > I'm using this script fo

Re: Setting file timestamps to commit time (git-checkout)

2013-12-10 Thread Constantine A. Murenin
On 10 December 2013 00:35, Dominik Vogt wrote: > that sounds awfully expensive, and really out of the scope of an > RCS. The second best approach I could think of is to stamp files > with the timestamp of the last commit that touched that, but I > guess that is not a cheap operation either. You

Re: Setting file timestamps to commit time (git-checkout)

2013-12-10 Thread Jonathan Nieder
Duy Nguyen wrote: > I wonder if we could promote multiple worktree from a hack to a > supported feature. What I have in mind is when you "clone > --separate-worktree" it would create a .git file that describes > separate worktree: > > gitbasedir: /path/to/the/original/.git > name: foo > > HEAD, in

Re: Setting file timestamps to commit time (git-checkout)

2013-12-10 Thread Jonathan Nieder
Dominik Vogt wrote: > How does git-new-workdir cope with > rebasing (e.g. you have the same branch checked out in two working > trees and "rebase -i" it in one of them)? Generally you don't have the same branch checked out in two working trees. I tend to use "git checkout

Re: Setting file timestamps to commit time (git-checkout)

2013-12-10 Thread Andreas Schwab
Dominik Vogt writes: > The second best approach I could think of is to stamp files with the > timestamp of the last commit that touched that, but I guess that is > not a cheap operation either. I'm using this script for this: #!/bin/sh git log --name-only --format=format:%n%ct -- "$@" | perl -e

Re: Setting file timestamps to commit time (git-checkout)

2013-12-10 Thread Duy Nguyen
On Tue, Dec 10, 2013 at 3:46 PM, Dominik Vogt wrote: > > > I suspect the simplest way to accomplish what you're looking for would > > be to keep separate worktrees for each branch you regularly build. > > It's possible to do that using entirely independent clones, clones > > sharing some objects (

Re: Setting file timestamps to commit time (git-checkout)

2013-12-10 Thread Dominik Vogt
On Mon, Dec 09, 2013 at 12:48:16PM -0800, Jonathan Nieder wrote: > Dominik Vogt wrote: > > when I switch to one of the other branches, said file is not > > identical anymore and stamped with the _current_ time during > > checkout. Although branch b and c have not changed at all, they > > will now

Re: Setting file timestamps to commit time (git-checkout)

2013-12-10 Thread Dominik Vogt
On Mon, Dec 09, 2013 at 12:35:38PM -0800, Junio C Hamano wrote: > Dominik Vogt writes: > > > Me and some colleagues work on gcc in lots of different branches. > > For each branch there is a separate build directory for each > > branch, e.g. build-a, build-b and build-c. Let's assume that all > >

Re: Setting file timestamps to commit time (git-checkout)

2013-12-09 Thread Jonathan Nieder
Hi, Dominik Vogt wrote: >Now, > when I switch to one of the other branches, said file is not > identical anymore and stamped with the _current_ time during > checkout. Although branch b and c have not changed at all, they > will now be

Re: Setting file timestamps to commit time (git-checkout)

2013-12-09 Thread Junio C Hamano
Dominik Vogt writes: > Me and some colleagues work on gcc in lots of different branches. > For each branch there is a separate build directory for each > branch, e.g. build-a, build-b and build-c. Let's assume that all > branches are identical at the moment. If a file in branch a is > changed t

Setting file timestamps to commit time (git-checkout)

2013-12-09 Thread Dominik Vogt
Me and some colleagues work on gcc in lots of different branches. For each branch there is a separate build directory for each branch, e.g. build-a, build-b and build-c. Let's assume that all branches are identical at the moment. If a file in branch a is changed that triggers a complete rebuild o