On 22 August 2011 12:31, Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote: > On Mon, Aug 22, 2011 at 14:49, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >> On 22 August 2011 05:46, Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote: >>> On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >>>> On 21 August 2011 20:01, Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote: >>>>> Obviously the easiest way to work around that issue is "git clean", >>>>> which has options to select all untracked files or just ignored ones. >>>> >>>> As I mentioned above, I don't want to *delete* untracked/ignored >>>> files, I just want them to stick to the branch I was working on. So if >>>> I change to a different branch I get the appropriate build artifacts. >>>> >>>> Something like: git stash --everything "All artifacts for >>>> this-branch." && git checkout other-branch && git stash apply >>>> stash-for-other-branch. >>> >>> When I am in those sorts of situations I generally just use separate >>> working directories or separate checkouts entirely; if you really prefer >>> to have everything in one directory you would be better served by >>> integrating "ccache" into your workflow. >> >> Unfortunately, that seems for C/C++ code only. I use Java. Besides, >> it's not the Java compilation that takes most of the time. > > Hm, that sounds like a very serious Eclipse limitation with almost all forms > of source control. What is done with other VCSes (IE: Subversion, etc)? It has nothing to do with Eclipse. There is just a lot going on in the build. > From this I believe the best option is to just make use of multiple separate > checkouts or worktrees. Sounds like it. >>> In particular, even "git stash" intentionally does not preserve file times, >>> so you would end up rebuilding everything anyways because all of your >>> source files would be as new as your object files. >> >> Yes, I just noticed that. Why do you say "intentionally"? Is extra >> work being done to make it so? If yes, then shouldn't that be >> configurable? > > Well, there's 2 reasons: > > (1) The GIT data-structures simply have no place for file timestamps, and > "git stash" is simply a special way of dumping files into a temporary commit. That's what I thought. The "intentionally" threw me off. It's not intentional, it's just a side effect. > This is exactly the same as the There seems to be some text missing here? > (2) You almost always *don't* want to preserve timestamps. For example: > > $ git checkout -b my-feature origin/master > $ vim some-file.c > $ make > $ git add some-file.c && git commit -m "A new feature" > $ git checkout -b my-bugfix origin/master > $ vim other-file.c > $ make > > If GIT preserved timestamps, the second "make" would fail to rebuild the > product "some-file.o" because "some-file.c" is still older than it, even > though "some-file.c" has changed since the last build!!! > > Really, GIT is only intended for storing source code. If you want to store > other kinds of things (like timestamps, permissions, etc), then you need to > turn them into source code (IE: a text file and a "make install" target) and > then store them that way. Yep, that all makes sense. I just wish there was at least an option to keep the timestamp (and possibly other such things). Even Subversion can do that... ;-) After all, not everybody uses C & make. Cheers, Hilco -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html