On Wednesday, September 11, 2013 8:07:13 PM UTC+4, sylvain bougnoux wrote: When one is working on an include with many dependancies, eg top.h, and > wants to pull, eg to get very_bottom.cpp; first git asks to stash > everything, does the pull, and pops the stash back. > So at the end, top.h has not changed, very_bottom.cpp is updated. Fine. > But in the loop, VisualC++ understands that the file top.h has changed, > and asks to recompil everything. >
The stash reverts the state of files in your work tree back to what's in the HEAD, and after pulling changes them once again. This inevitably leads to changed modification times. > The same trouble appears when one wants to push a tiny fix in > very_bottom.cpp and that he is not up-to-date with the repository. First he > has to pull, hence stash... > > We pull using a rebase to avoid these ugly little useless branches. > But afaiu, a merge does the same. > I understand it is related with the branching model. But it is definitely > not that obvious to make a good one with frequent pull/push (eg 1/h). > You *might* do merges (and hence pulls) into a dirty work tree, they're just not guaranteed to happen if `git merge` detects what it's about to change in a work tree file overlaps with local changes in it. But I suspect the problem might be rooted deeper. I'd ask on the main Git list [1] what's the envisioned Git semantics with regard to modification time of files in your situation. Be sure to explain what you're doing and which platform this is on (and Git version). 1. https://gist.github.com/tfnico/4441562 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
