On 3/1/07, Bill Lear <rael@zopyra.com> wrote:
quoted text
> I wonder if it would be possible or desirable to have a config flag
> that told git to restore the timestamps across branch checkouts in
> order to prevent this perturbation.

Almost every SCM has such a flag. And every one of them warn
against using it.

quoted text
> So, when git does a checkout of a branch, it would look to see which
> files in the current branch are changed, tuck away the timestamps for
> those, and switch to the new branch.  On return to the former, the
> same would be done for the new branch, then after the changed files
> were restored, the timestamps would be reset.

For instance, timestamp of which machine do you want to restore?
How do you know if they are synchronized?

quoted text
> One thing this would enable is to be able to hold the compilation
> products of multiple branches at the same time in the same working
> tree, switch back and forth between branches, and only have to compile
> code that you actually modify.  Currently, we store compilation
> products in a directory that is composed of the architecture, compiler,
> compiler options, and so forth, among which also could be the branch
> name.

Usually, you will just screw up the build process beyond all repair.

quoted text
> Anyway, just an idea I thought worth batting about.

Consider separating build and working repositories.
Merge things into build repo, switch the branches
freely in your working repo. Works just fine for me.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html