Git drawbacks?

[Dmitry Smirnov]

Hi,

Sorry if I selected the wrong place to discuss the drawbacks of the Git. Just
point to the proper one...

I'm just trying to select the best VCS for me personally.
I have a very small experience with Git but I see is also not very sutable for
me.

First, it seems to be very hard to setup some really big project (like Android,
for example). Otherwise, why do they need to invent 'repo'? What purpose it
solves? It looks like it
1. Integrates few subcomponents (projects) and checkout the code in the proper
configuration. The question is why this is not the Git task? For me, it looks
like the ClearCase client spec.
2.? What others (except integration with review tool)?

The next issue with git is its clone. Why do I need the whole set of revisions?
Why do I need to get 1GB of Android? You could say this should happen once. I
would agree but when I tried to resync the Android tree after 2 months, I was
struggled with many errors (both git and repo). Finally, I had decided to sync
again. :-)
There is one point against clone. The typical situation in my office is to have
few Perforce clients with the same or slightly  different code. This is just
wasting a space since you need them all but versions of many files are the same.
I'm trying to imagine the same situation with Git. Are there any benefits? It
seems, no. Moreover, I will have not only few working trees but few repository
clones!

It is obvious that configuration management with Git is very difficult (for ex,
http://groups.google.com/group/repo-
discuss/browse_thread/thread/2fa368ed7cac5d79/64ced51656240ddc?
lnk=gst&q=create+android+bare+repository#64ced51656240ddc)

Let's consider the foolwing use case. Suppose I'm intending to create a new
product that consists of specific versions (or branches) of some subcomponents
(or directories). How can I do this with Git? Subsequent changes could either be
submitted to the appropriate component branch or branched to the new one (this
way is possible with Git, of course, if I will branch the code I need to this
new branch).

So, I'm wondering, why Git (or any other VCS) is not trying to solve these
problems? Perhaps, there is a simple solution with Git I'm not aware of?

Here is the wish list for the VCS I would prefer:
1. Atomit commits
2. The possibility to get any slice of the code repository with the possibility
to commit my changes on tip or on separate branch.
3. The minimum footprint of the same code on my local machine.
4. No code/history on my machine untill I really need it.
5. Easy mirroring and replication

I would say, ClearCase might be my favorite if it is not commercial. :-)

Dmitry




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Avery Pennarun]

On Fri, Nov 6, 2009 at 11:17 AM, Dmitry Smirnov <[hidden email]> wrote:
> Here is the wish list for the VCS I would prefer:
> 1. Atomit commits
> 2. The possibility to get any slice of the code repository with the possibility
> to commit my changes on tip or on separate branch.
> 3. The minimum footprint of the same code on my local machine.
> 4. No code/history on my machine untill I really need it.
> 5. Easy mirroring and replication
>
> I would say, ClearCase might be my favorite if it is not commercial. :-)

#1 and #5 are features of any DVCS, so git already has them.  #2, 3,
and 4 are all just saying the same thing: "I can't afford the disk
space to store the entire repo."  Are you sure this is true, or is it
a preconception?  Even a 1GB repository is tiny by modern disk
standards.

My (limited) experience with ClearCase is that it's so slow that you'd
do *anything* to track fewer files in your working copy, so they put a
lot of work into exactly that, and no work into performance.  This
lousy performance isn't the case in git (except in Windows).  Are you
using Windows, by chance?

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Smirnov]

> > Here is the wish list for the VCS I would prefer:
> > 1. Atomit commits
> > 2. The possibility to get any slice of the code repository with the
possibility
> > to commit my changes on tip or on separate branch.
> > 3. The minimum footprint of the same code on my local machine.
> > 4. No code/history on my machine untill I really need it.
> > 5. Easy mirroring and replication
> >
> > I would say, ClearCase might be my favorite if it is not commercial.
>
> #1 and #5 are features of any DVCS, so git already has them.  #2, 3,
> and 4 are all just saying the same thing:

No, #2 is about the repository slicing, branching, merging (SCM in other words).
Let's suppose I have the product that have 2 directories: component1 and
component2. They were developing together for  previous product (on the same
branch, for example). Now, I would like to have component1 and replace
component2 with some 3rd party component. What should I do with Git to get this?
Or maybe I wish to stick with some version of component2 and provide only bug
fixes for this product...
Or let's take a look at GDB. They are using binutils which are in separate
repository (they use CVS, but let's imagine they use Git). How many effors they
will need for SCM? For example, they would prefer to stick to some stable
version/branch of the binutils but should be able to commit bug fixes.

Once again, perhaps there is some way to do this with Git? I did not yet find
it.

> "I can't afford the disk
> space to store the entire repo."  Are you sure this is true, or is it
> a preconception?  Even a 1GB repository is tiny by modern disk
> standards.

oh, yes, since we have big drives and fast internet, we do not have to worry
about space and download time... :-)

> My (limited) experience with ClearCase is that it's so slow that you'd
> do *anything* to track fewer files in your working copy, so they put a
> lot of work into exactly that, and no work into performance.

This probably true. Thought I did not have a lot of problems with it unless I
use GUI.

>  This
> lousy performance isn't the case in git (except in Windows).  Are you
> using Windows, by chance?

yes. I did not yet noticed any performance problems with Git on windows, except
a sync/download time (for android, mostly)




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jacob Helwig]

On Fri, Nov 6, 2009 at 09:35, Dmitry Smirnov <[hidden email]> wrote:

> No, #2 is about the repository slicing, branching, merging (SCM in other words).
> Let's suppose I have the product that have 2 directories: component1 and
> component2. They were developing together for  previous product (on the same
> branch, for example). Now, I would like to have component1 and replace
> component2 with some 3rd party component. What should I do with Git to get this?
> Or maybe I wish to stick with some version of component2 and provide only bug
> fixes for this product...
> Or let's take a look at GDB. They are using binutils which are in separate
> repository (they use CVS, but let's imagine they use Git). How many effors they
> will need for SCM? For example, they would prefer to stick to some stable
> version/branch of the binutils but should be able to commit bug fixes.
>
> Once again, perhaps there is some way to do this with Git? I did not yet find
> it.
>

Sounds like you want submodules.  Check out the git-submodule(1) manpage.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Avery Pennarun]

On Fri, Nov 6, 2009 at 12:35 PM, Dmitry Smirnov <[hidden email]> wrote:
> No, #2 is about the repository slicing, branching, merging (SCM in other words).
> Let's suppose I have the product that have 2 directories: component1 and
> component2. They were developing together for  previous product (on the same
> branch, for example). Now, I would like to have component1 and replace
> component2 with some 3rd party component. What should I do with Git to get this?
> Or maybe I wish to stick with some version of component2 and provide only bug
> fixes for this product...

There are three methods I know of to manage this:

1) Just commit whatever version of a subproject you want as a subtree
of your current project, and if you want to replace/delete/upgrade it,
just do that.  (You rarely want to track the actual *history* of the
third party tool, just the history of versions *you* used, which is
easy to do.)

2) Use git-submodule to link repositories together.  (Arguably, one
major reason 'repo' was written is that git-submodule is too
complicated, though.)

3) Try my git-subtree tool, which basically makes it easier to
split/join repositories (similar to #1) without losing the history
(similar to #2).

>> This
>> lousy performance isn't the case in git (except in Windows).  Are you
>> using Windows, by chance?
>
> yes. I did not yet noticed any performance problems with Git on windows, except
> a sync/download time (for android, mostly)

Basically, performance is linear with the number of files in your
repo.  If you can check out just a "slice" of your repo (say 10% of
the whole), you'll have faster performance (eg. 10x) from any VCS.

git on Linux is so fast that this isn't very necessary most of the
time.  But git on Windows isn't really any faster than other VCSes on
Windows, so the time-per-file is much greater, and thus the penalty
for huge repositories is much worse.  Doing things like switching
branches, which is near-instantaneous on Linux even with tens of
thousands of files, really crawls on Windows.

So I can see an argument that Windows users would want arbitrary
"slices" much more often than Linux+git users, but I think this is
largely due to performance, not because people really *want* to be
stuck with a restricted view of the repo.

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, 6 Nov 2009, Avery Pennarun wrote:

>>> This
>>> lousy performance isn't the case in git (except in Windows).  Are you
>>> using Windows, by chance?
>>
>> yes. I did not yet noticed any performance problems with Git on windows, except
>> a sync/download time (for android, mostly)
>
> Basically, performance is linear with the number of files in your
> repo.  If you can check out just a "slice" of your repo (say 10% of
> the whole), you'll have faster performance (eg. 10x) from any VCS.
>
> git on Linux is so fast that this isn't very necessary most of the
> time.  But git on Windows isn't really any faster than other VCSes on
> Windows, so the time-per-file is much greater, and thus the penalty
> for huge repositories is much worse.  Doing things like switching
> branches, which is near-instantaneous on Linux even with tens of
> thousands of files, really crawls on Windows.

but is that scale based on the number of files you are tracking, or the
number of revisions that exist in the repository.

i.e.  10,000 files in the source code with 10 revisions each vs 1,000
files with 100 revisions each.

my understanding of git is that it's the number of files, with very little
impact due to having lots of revisions. so eliminating 90 revisions of
each file would not significantly speed up git in the second case.

going back to the initial poster's comments. if the android repo is 1G,
eliminating the history will probably have significantly less impact than
you expect it to. for source code the compression factor that git is able
to get is spectacular. I've seen several cases posted with large projects
where the full repo with ALL history is <2x the size of a tar.gz of the
latest release.

David Lang

> So I can see an argument that Windows users would want arbitrary
> "slices" much more often than Linux+git users, but I think this is
> largely due to performance, not because people really *want* to be
> stuck with a restricted view of the repo.
>
> Have fun,
>
> Avery
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to [hidden email]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[Dmitry Smirnov]

Avery Pennarun <apenwarr <at> gmail.com> writes:

> There are three methods I know of to manage this:
>
> 1) Just commit whatever version of a subproject you want as a subtree
> of your current project, and if you want to replace/delete/upgrade it,
> just do that.  (You rarely want to track the actual *history* of the
> third party tool, just the history of versions *you* used, which is
> easy to do.)

Ok. Does that mean that new component2 and common component1 should leave on the
new branch (having in mind that old component2 and component1 are still living
on previous branch)? So, how many efforts will I need to get both component1
versions in sync (it is supposed that most of the changes in this component are
common for both)? Is is supposed that having 2 branches for this component is
cheaper (from development cycle POW)?

> 2) Use git-submodule to link repositories together.  (Arguably, one
> major reason 'repo' was written is that git-submodule is too
> complicated, though.)

> 3) Try my git-subtree tool, which basically makes it easier to
> split/join repositories (similar to #1) without losing the history
> (similar to #2).

I'll try to learn it.

I suppose, both these tools (repo and git-subtree) are the indication of some
contradiction between  the tool and SCM practice (especially, for big projects).

>
> Basically, performance is linear with the number of files in your
> repo.  If you can check out just a "slice" of your repo (say 10% of
> the whole), you'll have faster performance (eg. 10x) from any VCS.

Yes, I just wish to see this feature in some VCS. Why not Git? ;-)

> So I can see an argument that Windows users would want arbitrary
> "slices" much more often than Linux+git users, but I think this is
> largely due to performance, not because people really *want* to be
> stuck with a restricted view of the repo.

How offten do you use this info? I mean the whole stuff?





--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Smirnov]

 <david <at> lang.hm> writes:

> going back to the initial poster's comments. if the android repo is 1G,
> eliminating the history will probably have significantly less impact than
> you expect it to.

Do you have 2 or more copies of the same repository at the same time?
If yes, can I skip cloning new copy from network?
Or even skip cloning it at all?
Is it possible with Git to chekout into two (few) working trees?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jacob Helwig]

On Sun, Nov 8, 2009 at 23:53, Dmitry Smirnov <[hidden email]> wrote:

>  <david <at> lang.hm> writes:
>
>> going back to the initial poster's comments. if the android repo is 1G,
>> eliminating the history will probably have significantly less impact than
>> you expect it to.
>
> Do you have 2 or more copies of the same repository at the same time?
> If yes, can I skip cloning new copy from network?
> Or even skip cloning it at all?
> Is it possible with Git to chekout into two (few) working trees?
>

Take a look at git-new-workdir.  It's in the contrib directory of
git.git.  This lets you skip re-cloning the same repository over
again, if you want a new working copy of it.  It'll also give you some
space savings, by sharing certain key things in the .git directory
between working copies, by using symlinks.

It does have a few caveats, however.  If you have the same branch
checked out in two different working copies created using
git-new-workdir, and update the branch in one of them, then the other
will appear to have a bunch of staged changes, even though you haven't
done anything in it. The branch pointer will have been updated out
from underneath it, and it will be "confused".  As long as you
remember not to update a branch that is checked out in more than one
place on your machine, you'll never notice, thuogh.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Potapov]

On Mon, Nov 09, 2009 at 07:53:24AM +0000, Dmitry Smirnov wrote:

>  <david <at> lang.hm> writes:
>
> > going back to the initial poster's comments. if the android repo is 1G,
> > eliminating the history will probably have significantly less impact than
> > you expect it to.
>
> Do you have 2 or more copies of the same repository at the same time?
> If yes, can I skip cloning new copy from network?
> Or even skip cloning it at all?
> Is it possible with Git to chekout into two (few) working trees?

Jacob has already mentioned git-new-workdir from Git contrib, but
there are other ways to do the same or almost the same....

First of all, you can always copy your directory and thus creating
another clone. It is very simple and straightforward solution, but
it takes extra space due an extra copy of the repository. Usually,
it is not a big issue in practice, because your working tree tends
to be larger than the repository itself...

However, if you want to save disk space, you can use local clone. When
you clone your (like: git clone old_dir new_dir), git tries to use hard
links if it is possible. So, it may save disk space. However, if you
repack your original repo then a new pack will be created, and saving
from using the hard link will be lost.  To prevent that from happening,
you can tell to the garbage collector to keep the main existing pack by
create a file that has the same name as the pack file plus the .keep
suffix:

   touch .git/objects/pack-<SHA-1>.keep

then all changes will be put into a separate pack.

There is one more way to save disk space is to use git clone --shared.
It does not require hard links, but it has some caveats. If you want to
use it, then read the documentation carefully and make sure you understand
all implications.


Actually, in most use cases, there is no reason to have more than one
working tree. Git is designed to work well with plenty branches and one
working tree. So, switching between two branches and recompiling a few
changed files is much faster then going to another directory and try to
work there, because when you go to another directory, you may hit cold
cache and disk is *slow*... Another thing is that you can do a lot of
things without checking out some branch. You can grep any revision in
your repository, you can insect any file from it, etc and you do not
have to checkout this revision in your working tree.


Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Smirnov]

Jacob Helwig <jacob.helwig <at> gmail.com> writes:

> It does have a few caveats, however.  If you have the same branch
> checked out in two different working copies created using
>...
> place on your machine, you'll never notice, thuogh.


So, i cannot recover from this situation by upmerging to the new head?




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Smirnov]

Dmitry Potapov <dpotapov <at> gmail.com> writes:


> Actually, in most use cases, there is no reason to have more than one
> working tree. Git is designed to work well with plenty branches and one
> working tree. So, switching between two branches and recompiling a few
> changed files is much faster then going to another directory and try to
> work there, because when you go to another directory, you may hit cold
> cache and disk is *slow*... Another thing is that you can do a lot of
> things without checking out some branch. You can grep any revision in
> your repository, you can insect any file from it, etc and you do not
> have to checkout this revision in your working tree.

Shouldn't I even worry about my not yet commited changes before switching the
branch?

I would say that this approach does not work if the build and test could take
significant time. While in CR fix I don't want to wait for a build to complete
before I countinue with another bug/fix. That is why I'm curious about
few working trees...



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jacob Helwig]

On Mon, Nov 9, 2009 at 07:59, Dmitry Smirnov <[hidden email]> wrote:

> Jacob Helwig <jacob.helwig <at> gmail.com> writes:
>
>> It does have a few caveats, however.  If you have the same branch
>> checked out in two different working copies created using
>>...
>> place on your machine, you'll never notice, thuogh.
>
>
> So, i cannot recover from this situation by upmerging to the new head?
>

If you haven't actually made any changes in the second checkout of the
branch, then recovery is a simple reset --hard.  If you have made any
changes in that working copy, then recovery is a bit more complicated,
and it's probably best if I leave that explanation up to someone else,
since I'm very careful to avoid this situation in the first place, and
have never actually had to recover from it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Potapov]

On Mon, Nov 09, 2009 at 04:11:48PM +0000, Dmitry Smirnov wrote:

> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
>
> > Actually, in most use cases, there is no reason to have more than one
> > working tree. Git is designed to work well with plenty branches and one
> > working tree. So, switching between two branches and recompiling a few
> > changed files is much faster then going to another directory and try to
> > work there, because when you go to another directory, you may hit cold
> > cache and disk is *slow*... Another thing is that you can do a lot of
> > things without checking out some branch. You can grep any revision in
> > your repository, you can insect any file from it, etc and you do not
> > have to checkout this revision in your working tree.
>
> Shouldn't I even worry about my not yet commited changes before switching the
> branch?

You probably want to use 'git stash save' and when you return back you
just do 'git stash pop'. Also, keep in mind that you can amend any
previous commit using 'git commit --amend'.

>
> I would say that this approach does not work if the build and test could take
> significant time.

Yes, but then I do not see any reason to do any time consuming building
and testing in the working tree. I create a snapshot of the interesting
version using 'git archive' and then run build&test on it... In this
way, I can make sure that the archive I deliver is tested properly. If
you do your testing in the working tree, sometimes uncommitted or some
other files that are left over from previous builds may affect result.
So, if it takes considerable time anyhow, why do not do clean build and
test? And if you worry about compilation time, you can use ccache.


Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[B Smith-Mannschott]

On Mon, Nov 9, 2009 at 17:11, Dmitry Smirnov <[hidden email]> wrote:

> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
>
>> Actually, in most use cases, there is no reason to have more than one
>> working tree. Git is designed to work well with plenty branches and one
>> working tree. So, switching between two branches and recompiling a few
>> changed files is much faster then going to another directory and try to
>> work there, because when you go to another directory, you may hit cold
>> cache and disk is *slow*... Another thing is that you can do a lot of
>> things without checking out some branch. You can grep any revision in
>> your repository, you can insect any file from it, etc and you do not
>> have to checkout this revision in your working tree.
>
> Shouldn't I even worry about my not yet commited changes before switching the
> branch?

commit them before you switch. you could:

- commit them to the current branch before you switch the branch.
- commit them to a new branch before you switch
- use git stash to move your changes aside.

> I would say that this approach does not work if the build and test could take
> significant time. While in CR fix I don't want to wait for a build to complete
> before I countinue with another bug/fix. That is why I'm curious about
> few working trees...

You don't have to wait to comitting to your own branches, but do make
sure to run your usual builds and tests before pushing or asking
another to pull changes from you.

// Ben
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Potapov]

On Mon, Nov 09, 2009 at 07:47:08PM +0100, B Smith-Mannschott wrote:
>
> You don't have to wait to comitting to your own branches, but do make
> sure to run your usual builds and tests before pushing or asking
> another to pull changes from you.

Yes, it is one most useful feature of Git that you can commit (save)
your changes immediately but amend them later. This helps a lot to
make changes smaller, cleaner and easier to review.

With many other VCS, a typical policy is that you do not commit your
changes unless you have finished and tested them. But it means that
your changes are not committed and stored only in the work tree for
a long time. Moreover, when you eventually decide that they are good
enough to commit, you will produce a huge patch, which will be difficult
to review or to bisect history later.

With Git you do not have to worry about testing when you can commit your
changes. Typically I would commit some my changes as I progress to my
goal, but later I will review all commits. Probably, squash some changes
with fixes, clean up some other, add better explanations of what is done
and why, etc... But I do not have to worry about all those trifles as
I write code to see if some feature is worth or not, if this solution
works or I should try something else...

So, you can always commit your changes as your progress to your goal and
review amend them later before publishing. This means that you can have
as many work-in-progress branches as you wish, and you do not need a
separate work tree for each of them -- everything can be stored in the
repository, and you can go to another computer, issue 'git fetch' and
continue your work at the exact point where you left it. So, it is very
flexible.


Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Smirnov]

Dmitry Potapov <dpotapov <at> gmail.com> writes:
 
> Yes, but then I do not see any reason to do any time consuming building
> and testing in the working tree. I create a snapshot of the interesting
> version using 'git archive' and then run build&test on it... In this
> way, I can make sure that the archive I deliver is tested properly. If
> you do your testing in the working tree, sometimes uncommitted or some
> other files that are left over from previous builds may affect result.
> So, if it takes considerable time anyhow, why do not do clean build and
> test? And if you worry about compilation time, you can use ccache.

It is not clear for me. Yes, I have to get some fixed version to reproduce
the bug reported by someone. Then I need to fix it and commit the change
back (on the head). Also, it is obvious to reproduce the issue and
test the fix on the tip. Can do this with 'git archive'?
BTW, doesn't 'git archive' sync to some version that I probably already
have in other clone? ;-)




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Smirnov]

Dmitry Potapov <dpotapov <at> gmail.com> writes:

> With many other VCS, a typical policy is that you do not commit your
> changes unless you have finished and tested them. But it means that
> your changes are not committed and stored only in the work tree for
> a long time. Moreover, when you eventually decide that they are good
> enough to commit, you will produce a huge patch, which will be difficult
> to review or to bisect history later.

oh, yes. but this is just a policy. You can make your changes on your
branch and commit them (for example, for review). Later someone just
need to integrate it on original branch. The same as with Git,
isn't it? The problem is just a price to branch.
BTW, once I started to talk about review, we can see that most
"benefits" of DVCS go away... Just because you still need some
central storage to save the record of this review that should
be available for SQA later...
 
> So, you can always commit your changes as your progress to your goal and
> review amend them later before publishing. This means that you can have
> as many work-in-progress branches as you wish, and you do not need a
> separate work tree for each of them -- everything can be stored in the
> repository, and you can go to another computer, issue 'git fetch' and
> continue your work at the exact point where you left it. So, it is very
> flexible.

As for me, I would not to have more than 4-5 such deferred changes in the same
repository. Otherwise, I will be entangled finally :-)



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Smirnov]

B Smith-Mannschott <bsmith.occs <at> gmail.com> writes:
 
> You don't have to wait to comitting to your own branches, but do make
> sure to run your usual builds and tests before pushing or asking
> another to pull changes from you.

Perhaps, I was not clear in my questions.
I do not want to build and test to complete before I get back to my stashed
or commited changes. I.e. I need to have 2 working trees (perhaps different, but
from the same repository): one for build/test and one for another task.

Dmitry



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Dmitry Potapov]

On Tue, Nov 10, 2009 at 08:31:48AM +0000, Dmitry Smirnov wrote:

> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>  
> > Yes, but then I do not see any reason to do any time consuming building
> > and testing in the working tree. I create a snapshot of the interesting
> > version using 'git archive' and then run build&test on it... In this
> > way, I can make sure that the archive I deliver is tested properly. If
> > you do your testing in the working tree, sometimes uncommitted or some
> > other files that are left over from previous builds may affect result.
> > So, if it takes considerable time anyhow, why do not do clean build and
> > test? And if you worry about compilation time, you can use ccache.
>
> It is not clear for me. Yes, I have to get some fixed version to reproduce
> the bug reported by someone. Then I need to fix it and commit the change
> back (on the head). Also, it is obvious to reproduce the issue and
> test the fix on the tip. Can do this with 'git archive'?
> BTW, doesn't 'git archive' sync to some version that I probably already
> have in other clone? ;-)

I am not sure I understood your question. What 'git archive' does is to
create a tar or zip archive or any version that you specify. So, you can
use it to export the snapshot of any version to a temporary directory
for testing if this testing takes a noticeable time and you want to be
able to work on something else in meanwhile. If necessary, you can
create a temporary branch starting at the intesting point and to add
some commits there (such as a new test case to reproduce the problem)
and then run test on it. Later, you can either rebase or merge these
commits to any branch that needs them.

Actually, when someone reports a problem, I do not use 'git archive'
because I write a test case for this bug and run it alone, and it does
not take much time to run it. But periodically (a few times a day), I
run the full test suit, which takes considerable amount of time, so I
run this test outside of my working directory, using 'git archive'.


Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html