Re: Branches & directories

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
>>> On Sun, Aug 21, 2011 at 22:13, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote:
>>>> Thanks for sticking it out. :-) That all makes sense. I think it's all
>>>> pretty clear now.
>>>
>>> It's worth mentioning that in most cases you DON'T want to delete untracked and
>>> ignored files when switching branches.
>>
>> For the record, I don't want them deleted but replaced with the
>> artifacts in the other branch. A bit wasteful but it saves a lot of
>> build time.
>>
>>> For example, when I'm doing kernel development, I will frequently do this:
>>>
>>> $ git checkout -b my-new-feature origin/master
>>> [...hack hack hack...]
>>> $ make -j16 && make install && reboot
>>> [...find unrelated bug...]
>>> $ git checkout -b my-new-bugfix origin/master
>>> [...fix the bug...]
>>> $ make -j16 && make install && reboot
>>> $ git commit -m 'I fixed this bug'
>>> $ git checkout my-new-feature
>>> $ git rebase my-new-bugfix
>>> $ make -j16 && make install && reboot
>>>
>>> To avoid wasting time I don't want to completely rebuild the kernel each
>>> and every time I switch branches, I just want to rebuild the files that
>>> changed when I switched.  The way GIT works lets me do that quite
>>> easily, and the kernel Makefiles detect the changed files and rebuild
>>> the minimum amount necessary.
>>>
>>> GIT's behavior when you switch between branches is effectively the
>>> same as applying a patch generated by diffing between the two
>>> branches.  Any files which would not be changed are left alone, their
>>> timestamps completely unchanged.
>>
>> For small changes that makes perfect sense. I'm at a stage where APIs
>> are still evolving and changing an API means rebuilding lots of code.
>> I'd like to avoid that.
>>
>>> It sounds like Eclipse is simply not detecting changes to your working
>>> tree by outside programs, and as a result it's not rebuilding files and
>>> indexes the way that it should.
>>
>> While Eclipse isn't great at detecting such changes, this isn't really
>> an Eclipse problem. It's just that lots of things are still changing
>> and that leads to lots of building.
>>
>>> 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.

> 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?

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]