Re: need help adjusting workflow to git (or vice versa)

[Stephen Berman <stephen.berman@gmx.net>]

On Thu, 13 Nov 2014 12:58:24 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 11/13/2014 12:44 PM, Stephen Berman wrote:
>> That's what Martin referred to, isn't it? It takes considerably longer on my
>> older and feebler hardware, also compared with `bzr update' and `bzr pull
>> --overwrite' in a shared repository.
>
> By "shared repository" do you mean you have just one copy of the working
> files?  I thought you had multiple copies, one for each branch.  That's what I
> do, as it helps 'make' go faster.

I also have copies of the working files for each bzr branch, but just
one copy of the history; but it appears I had a wrong idea of what
cloning does...

>> And the size is also not insignificant, if it means having a copy of the
>> entire Emacs repository for each build (~540M).
>
> No, the repository is shared:
>
> $ time git clone master tmp
> Cloning into 'tmp'...
> done.
>
> real    0m1.314s
> user    0m0.997s
> sys    0m0.280s
> $ du -s master/.git tmp/.git
> 205500    master/.git
> 768    tmp/.git

Ok, this is not what I had thought, but I'm glad I was mistaken.

On Thu, 13 Nov 2014 21:58:27 +0100 (CET) Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:

> [Stephen Berman <stephen.berman@gmx.net> (2014-11-13 20:44:22 UTC)]
>
>> That's what Martin referred to, isn't it?  It takes considerably longer
>> on my older and feebler hardware, also compared with `bzr update' and
>> `bzr pull --overwrite' in a shared repository.  And the size is also not
>> insignificant, if it means having a copy of the entire Emacs repository
>> for each build (~540M).
>
> You might have a look at the options --local and --shallow to git
> clone. The idea would be to have one full clone that pulls from
> savannah, then any number of local clones pulling from from that one.
>
> After running  git clone --local emacs emacs2
> I get this:
>
> ; du -sh emacs/.git emacs2/.git
> 199M    emacs/.git
> 392K    emacs2/.git
>
> The clone operation was pretty fast, too. 7 seconds on an SSD.

Thanks, that's information I was missing, and seems to be just what I want.

On Thu, 13 Nov 2014 15:53:24 -0500 Kelvin White <kwhite@gnu.org> wrote:

> On Nov 13, 2014 2:51 PM, "Stephen Berman" <stephen.berman@gmx.net> wrote:
>>
>> On Thu, 13 Nov 2014 10:49:05 -0500 Kelvin White <kwhite@gnu.org> wrote:
>>
[...]
>> >
>> > The uncommitted changes will not be included unless you add them and
>> > commit them.
>>
>> But they are included in the build (I confirmed this by building from my
>> build branch, not from task branch (i.e., with my build branch currently
>> checked out), and that's what I want to avoid.
>
> Before checking out your build branch, either commit your changes, or stash
> them. This will keep the changes in the build branch and not carry them over
> into whatever branch you check out first.

Thanks, I didn't know about stashing either, and it seems to be close to
what I wanted.

Thanks to all of you for the feedback, it's been edifying.

Steve Berman