On 22 August 2011 20:06, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: > On 22 August 2011 16:21, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> Hilco Wijbenga wrote: >> >>> You mean an extra dotfile per file in the commit? >> >> Let me step back a moment. >> >> When you mentioned mtime, a switch went off and reminded me of the >> problem of metadata in general, especially owner and permissions. That >> problem is important for people keeping track of /etc or $HOME in >> version control (always a little dangerous because of the effect of a >> stray "git reset --hard", but never mind). And the last time it came >> up, I convinced myself that a hook script setting up entries in >> .gitattributes, .gitmetadata, or .etckeepr with information like "all >> files are owned by root:root unless otherwise specified" could be a >> good and not too invasive way to deal with that. >> >> Now that you remind me that the mtime of every file is likely to >> differ from every other file, it is harder to imagine what situation >> would make this meaningful information that should be stored in the >> repository and shared with other people. It seems more like something >> associated to the worktree, which fits more closely with what you are >> trying to do, anyway. > > Yes, indeed. > >> Regarding the problem "eclipse metadata is not carried over from one >> worktree to another", isn't that going to be a problem regardless? In >> your proposed setup, each time you stash everything and start work on >> a different branch, the eclipse metadata before would be stashed along >> with everything else, which doesn't make anything any easier (unless >> disk space is very scarce or metadata stores the absolute path to the >> cwd). > > Eclipse is a wonderful IDE except for how it makes sharing workspaces > practically impossible (where "share" means "put in SCM", not "used my > several developers at the same time"). It's mostly (AFAICT) binary > data with lots of absolute paths. So it's a pain but it doesn't make > my scenario all that much more complicated. > > The hard part is creating a new branch. Somehow I would need to > duplicate the state in the parent branch in the child branch. It needs > to be duplicated because I need to be able to do git stash in the > child branch *and* the parent branch. Is it possible to do git stash > pop without losing the stash? Or to "copy" a stash? Otherwise, it's > probably easier to simply write a separate script to do it. That > should not be very hard. I would not use git stash at all. > > For a new branch, the script would > 1. in "parent", move workspace (i.e. the root working dir, where .git > is) into .git/branches/parent/ > 2. create and jump to "child" > 3. in "child", copy .git/branches/parent into workspace (so creating a > new branch is no longer a cheap operation) > > For an existing branch, the script would > 1. in "current-branch", move workspace into .git/branches/current-branch > 2. jump to "other-branch" > 3. in "other-branch", move .git/branches/other-branch into workspace > > The moves (assuming everything is on the same partition) should make > switching branches relatively cheap. Not very elegant (quite brute > force in fact) but it's simple and I think it would work. Or did I > overlook something? Better/other ideas are certainly welcome. :-) P.S. I do not mean to imply that I have discounted simply using different clones or git-new-workdir. Those are still valid options. The script is probably a bit faster, though. -- 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