* Re: [PATCH] post-checkout hook, and related docs and tests
From: Junio C Hamano @ 2007-09-25 21:29 UTC (permalink / raw)
To: Josh England; +Cc: git
In-Reply-To: <1190738473.6078.102.camel@beauty>
"Josh England" <jjengla@sandia.gov> writes:
> So this leads to my next question: Should the post-merge patch be
> brought in under this same umbrella to form a single post-checkout hook,
> or should it stay a separate hook?
I think it is called would be inconvenient for the callee if you
call the same hook without telling the hook script why it is
called, so if you go in the unification route the caller of the
unified hook needs to supply an extra parameter and existing
hooks if any need to be updated --- neither sounds like a very
idea. The writer of the hooks however can choose to call one
from the other if he wants the same action for both hooks, so it
looks to me that separate hooks for separate purposes is the way
to go.
^ permalink raw reply
* Re: [PATCH] diffcore-rename: cache file deltas
From: Junio C Hamano @ 2007-09-25 21:29 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, git
In-Reply-To: <20070925192941.GA8564@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We find rename candidates by computing a fingerprint hash of
> each file, and then comparing those fingerprints. There are
> inherently O(n^2) comparisons, so it pays in CPU time to
> hoist the (rather expensive) computation of the fingerprint
> out of that loop (or to cache it once we have computed it once).
>
> Previously, we didn't keep the filespec information around
> because then we had the potential to consume a great deal of
> memory. However, instead of keeping all of the filespec
> data, we can instead just keep the fingerprint.
>
> This patch implements and uses diff_free_filespec_data_large
> to accomplish that goal. We also have to change
> estimate_similarity not to needlessly repopulate the
> filespec data when we already have the hash.
>
> Practical tests showed 4.5x speedup for a 10% memory usage
> increase.
>
> Signed-off-by: Jeff King <peff@peff.net>
Very nice.
> The implementation is a little less nice than I would like, but I was
> trying to be non-invasive. Specifically:
>
> - the name diff_free_filespec_data_large is horrible, but this is based
> on the fact that diff_free_filespec_data actually does too much (it
> frees the data _and_ some other auxiliary data). And renaming that
> would entail changing many callsites.
True. But we can rename it to diff_file_filespec_blob() and
that would perfectly well describe what it does. Will do so
when applying if it is Ok to you.
> - It seems that a better place to call diffcore_populate_filespec
> (rather than in estimate_similarity) would actually be in
> diffcore_count_changes (when we _know_ that we need to populate the
> contents data).
>
> - The hash_chars() should arguably be tied into
> diffcore_populate_filespec, which should have more of a "what
> information do you want" interface. I.e., the "size_only" parameter
> could be extended to a bitfield to say "populate this, and I need the
> delta fingerprint, size, actual contents, etc". Then callers could
> just use "populate" before looking at the filespec and it would
> lazily load whatever they needed.
Both good points, but I agree with you that it is wise to do
that with a follow-up patch.
^ permalink raw reply
* Re: Workflow question
From: Junio C Hamano @ 2007-09-25 21:28 UTC (permalink / raw)
To: Russ Brown; +Cc: Jeff King, git
In-Reply-To: <46F97618.9010207@gmail.com>
Russ Brown <pickscrape@gmail.com> writes:
> I keep reading things similar to this and bit by bit I'm starting to get
> it. :) I suppose this is one case in which it's definitely a
> disadvantage to have a good understanding of svn before coming to git...
>
> <yoda>You must unlearn what you have learned</yoda>
You do not have to unlearn; if Jeff truly unlearned he wouldn't
have spotted you were trapped in SVN mentality. You just need
to learn there could be other ways ;-).
> If you delete a branch that has commits on it that aren't referenced by
> any other branches, will those commits be removed by something like git
> pack or git gc?
Yes, eventually.
> I suppose what has me the most confused is how a developer works with a
> remote branch: I've come to understand that a developer should never
> check out and work on a remote branch, and always create a local one and
> work on that. If he does that using the above hierarchy, there then
> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
> is possible for a developer to work directory on a remote branch?
The statement in the last sentence does not make any sense.
Remote is called remote because it is remote and supposed to be
out of reach ;-)
More seriously, remotes are used as reference points so if you
"work directly on them", you cannot use them as reference points
any more; you defeat the sole purpose of existence of remotes.
You can work _without_ using remote tracking branches, but that
is mostly for merge based workflow. It appears that you are
leaning towards rebase-heavy workflow, so I do not think it is
applicable to your project.
^ permalink raw reply
* Re: Workflow question
From: Russ Brown @ 2007-09-25 20:56 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070925201717.GB19549@segfault.peff.net>
Jeff King wrote:
> On Tue, Sep 25, 2007 at 02:42:11PM -0500, Russ Brown wrote:
>
>>> This isn't necessary. Branches in git are very nearly zero-cost, so having
>>> them in the same repo as the master branch won't hurt a bit. You can add
>>> an update-hook on the mothership repo to restrict access to the master
>>> branch if you like, but creating two separate repos will likely give
>>> more headache than it's worth.
>>>
>> Ah, right. I'm just trying to remember why it was I came up with that
>> idea in the first place, but I'm struggling a bit. :)
>
> It's not entirely true that branches are zero-cost. They cost nothing to
> make, but fetching a branch that has commits that you don't want is
> going to cost something. And since git-clone doesn't have good support
> for "fetch only this subset of the branches" you end up getting them
> all.
>
> That being said, you will be amazed how _little_ that cost is unless
> one of the branches doesn't delta well (e.g., if one branch introduces 100M
> of unrelated images, then getting that branch is going to cost). But
> it's almost certainly worth seeing what your workload is like.
>
That's pretty much what I thought. Given that we'll probably only port
across a few (active) branches if we do decide to convert, I figure we
might as well start off by cloning them all and see how it goes.
>> Here's a question: is the creation and deletion of a branch also version
>> controlled as it is in Subversion? In other words, if I create a branch,
>> develop on it and delete it without merging it anywhere, will the
>> revisions hang around and get pulled down by future people cloning the
>> repository, or do they get thrown away?
>
> Branch creation isn't version controlled, but your frame of reference is
> obviously svn branches, not git branches. A git repo is just a
> collection of refs, and each ref is a pointer to some commit (which
> points to a tree and to further commits). Branches are just refs in a
> given namespace (where the namespace refs/heads/ indicates "it's ok to
> make further commits on top of these").
>
I keep reading things similar to this and bit by bit I'm starting to get
it. :) I suppose this is one case in which it's definitely a
disadvantage to have a good understanding of svn before coming to git...
<yoda>You must unlearn what you have learned</yoda>
> So if you create a branch in your private repo, it is a totally private
> thing; the central repo has no notion of it. When you push that branch
> to the central repo, you are creating a new ref at the central location
> that points to some commits you made. People who clone it will clone
> that ref and your commits. If you delete the branch locally, again it
> has no effect on the master repo. If you delete the branch from the
> central repo, then nobody will fetch those commits anymore (since
> nothing will be pointing to them).
>
If you delete a branch that has commits on it that aren't referenced by
any other branches, will those commits be removed by something like git
pack or git gc?
>> I've seen the term 'topic-branch' used here quite a bit but it's
>> unfamiliar to me. It is basically synonymous with what we call a
>> 'project branch'? i.e. Management decide that feature X is required so
>> we create a branch to develop it on which all developers on the project
>> commit to.
>
> Yes, that's exactly right. You have a "branch" for working on a "topic".
>
>> Note that in step 4 above I mean the developer takes a local branch of
>> the topic branch. For example, we start projectX/main, and create branch
>> projectX on the shared repo. Developer 'jeff' works on the project and
>> so creates local branch projectX/jeff and begins work. In step 5 they
>
> You are actually talking about per-developer, per-topic branches. Which
> is fine, too. It sounds like these projects are big (many participants
> over an extended period), so you may want to do things hierarchically:
>
> 1. project X starts, so you make a branch projectX and assign Bob to
> be the integrator (or if you prefer, nobody is the integrator).
> 2. Jeff starts to work on project X, feature Y. He makes a branch
> projectX/featureY, based on projectX. He may publish this to the
> shared repo if he wants to communicate his progress.
> 3. When featureY is "ready", he tells Bob to pull it into the main
> projectX branch (or if no integrator, he does it himself).
>
> Any developer can see the progress of any "topic" by looking at its
> branch. But only things which have advanced to the main "projectX"
> branch are used as the basis for other topics. If you want, you can
> replace featureY with "jeff" to indicate "this is the work Jeff is doing
> on projectX", but then you will run into issues when Jeff is working on
> two different topics of projectY.
>
Yes, that's kinda like what I was thinking. The distinction between a
developer working on a named branch or a feature branch I suppose is one
to think about.
I suppose what has me the most confused is how a developer works with a
remote branch: I've come to understand that a developer should never
check out and work on a remote branch, and always create a local one and
work on that. If he does that using the above hierarchy, there then
becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
is possible for a developer to work directory on a remote branch?
>> Having been using git-svn for a while I really like the clean history
>> result that rebase gives, however my understanding was that you should
>> never rebase any published branch as it could screw up clones of that
>> branch. In fact, this is what has me the most confused: how to rebase a
>> project branch that is on a shared repository against master when
>> everyone will have it cloned? Or is this something that I clearly don't
>> understand properly?
>
> You generally don't want to rebase that branch. If there are other
> branches based on some work, then it will become more difficult to merge
> those branches into the rebased work. IOW, rebase works well only at the
> "outermost" level of development. So if branch "featureY" is branched from
> "projectX" which is branched from "main", then it is reasonable to
> rebase featureY against projectX. But rebasing projectX against master
> will make integrating "featureY" more difficult. So you should either:
> - just do regular merges of projectX into main (and hopefully, if
> projectX is an aggregate of features, it won't have _that_ many
> merges, so the history should still be quite readable)
> - wait until all such "featureY" branches are merged into projectX,
> announce a freeze of branching from projectX, and then rebase it
> forward.
>
> -Peff
Ah,I see... The light is beginning to come on somewhat here, though it's
dimmed somewhat by the remote/local branch confusion I mention above,
which tends to imply that rebase is only really useful in local branches
since it is always the outer-most branch (assuming that my understanding
on that is correct, which it may well not be).
I actually quite like the idea of the freezing before re-basing in the
sub-branches. However, to answer the question of which merge strategy
would work best for us I think I need to actually set this up and have a
play with it to see how it all pans out using the various options available.
Thanks for your help!
--
Russ
^ permalink raw reply
* Re: Workflow question
From: Wincent Colaiuta @ 2007-09-25 20:37 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Russ Brown, git
In-Reply-To: <20070925202022.GC19549@segfault.peff.net>
El 25/9/2007, a las 22:20, Jeff King escribió:
> On Tue, Sep 25, 2007 at 09:50:34PM +0200, Wincent Colaiuta wrote:
>
>> Google has a pretty interesting internal code review system:
>>
>> <http://video.google.com/videoplay?docid=-8502904076440714866>
>
> Interesting pointer, thanks. Though I did get a little concerned
> when I
> saw that it is based on Perforce. ;)
Yes (poor Google employees!), and not only that, I'm not aware of any
public access to the code. But still, there are some interesting
ideas about the review process in there.
W
^ permalink raw reply
* Re: Workflow question
From: Jeff King @ 2007-09-25 20:20 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Andreas Ericsson, Russ Brown, git
In-Reply-To: <24DF51B9-1BF9-40C0-A1EF-80EF5072570F@wincent.com>
On Tue, Sep 25, 2007 at 09:50:34PM +0200, Wincent Colaiuta wrote:
> Google has a pretty interesting internal code review system:
>
> <http://video.google.com/videoplay?docid=-8502904076440714866>
Interesting pointer, thanks. Though I did get a little concerned when I
saw that it is based on Perforce. ;)
-Peff
^ permalink raw reply
* Re: Workflow question
From: Jeff King @ 2007-09-25 20:17 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46F96493.8000607@gmail.com>
On Tue, Sep 25, 2007 at 02:42:11PM -0500, Russ Brown wrote:
> > This isn't necessary. Branches in git are very nearly zero-cost, so having
> > them in the same repo as the master branch won't hurt a bit. You can add
> > an update-hook on the mothership repo to restrict access to the master
> > branch if you like, but creating two separate repos will likely give
> > more headache than it's worth.
> >
>
> Ah, right. I'm just trying to remember why it was I came up with that
> idea in the first place, but I'm struggling a bit. :)
It's not entirely true that branches are zero-cost. They cost nothing to
make, but fetching a branch that has commits that you don't want is
going to cost something. And since git-clone doesn't have good support
for "fetch only this subset of the branches" you end up getting them
all.
That being said, you will be amazed how _little_ that cost is unless
one of the branches doesn't delta well (e.g., if one branch introduces 100M
of unrelated images, then getting that branch is going to cost). But
it's almost certainly worth seeing what your workload is like.
> Here's a question: is the creation and deletion of a branch also version
> controlled as it is in Subversion? In other words, if I create a branch,
> develop on it and delete it without merging it anywhere, will the
> revisions hang around and get pulled down by future people cloning the
> repository, or do they get thrown away?
Branch creation isn't version controlled, but your frame of reference is
obviously svn branches, not git branches. A git repo is just a
collection of refs, and each ref is a pointer to some commit (which
points to a tree and to further commits). Branches are just refs in a
given namespace (where the namespace refs/heads/ indicates "it's ok to
make further commits on top of these").
So if you create a branch in your private repo, it is a totally private
thing; the central repo has no notion of it. When you push that branch
to the central repo, you are creating a new ref at the central location
that points to some commits you made. People who clone it will clone
that ref and your commits. If you delete the branch locally, again it
has no effect on the master repo. If you delete the branch from the
central repo, then nobody will fetch those commits anymore (since
nothing will be pointing to them).
> I've seen the term 'topic-branch' used here quite a bit but it's
> unfamiliar to me. It is basically synonymous with what we call a
> 'project branch'? i.e. Management decide that feature X is required so
> we create a branch to develop it on which all developers on the project
> commit to.
Yes, that's exactly right. You have a "branch" for working on a "topic".
> Note that in step 4 above I mean the developer takes a local branch of
> the topic branch. For example, we start projectX/main, and create branch
> projectX on the shared repo. Developer 'jeff' works on the project and
> so creates local branch projectX/jeff and begins work. In step 5 they
You are actually talking about per-developer, per-topic branches. Which
is fine, too. It sounds like these projects are big (many participants
over an extended period), so you may want to do things hierarchically:
1. project X starts, so you make a branch projectX and assign Bob to
be the integrator (or if you prefer, nobody is the integrator).
2. Jeff starts to work on project X, feature Y. He makes a branch
projectX/featureY, based on projectX. He may publish this to the
shared repo if he wants to communicate his progress.
3. When featureY is "ready", he tells Bob to pull it into the main
projectX branch (or if no integrator, he does it himself).
Any developer can see the progress of any "topic" by looking at its
branch. But only things which have advanced to the main "projectX"
branch are used as the basis for other topics. If you want, you can
replace featureY with "jeff" to indicate "this is the work Jeff is doing
on projectX", but then you will run into issues when Jeff is working on
two different topics of projectY.
> Having been using git-svn for a while I really like the clean history
> result that rebase gives, however my understanding was that you should
> never rebase any published branch as it could screw up clones of that
> branch. In fact, this is what has me the most confused: how to rebase a
> project branch that is on a shared repository against master when
> everyone will have it cloned? Or is this something that I clearly don't
> understand properly?
You generally don't want to rebase that branch. If there are other
branches based on some work, then it will become more difficult to merge
those branches into the rebased work. IOW, rebase works well only at the
"outermost" level of development. So if branch "featureY" is branched from
"projectX" which is branched from "main", then it is reasonable to
rebase featureY against projectX. But rebasing projectX against master
will make integrating "featureY" more difficult. So you should either:
- just do regular merges of projectX into main (and hopefully, if
projectX is an aggregate of features, it won't have _that_ many
merges, so the history should still be quite readable)
- wait until all such "featureY" branches are merged into projectX,
announce a freeze of branching from projectX, and then rebase it
forward.
-Peff
^ permalink raw reply
* Re: [PATCH] Remove 'submodules' from the TODO section of the User Manual.
From: J. Bruce Fields @ 2007-09-25 20:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20070925201306.GW30845@fieldses.org>
On Tue, Sep 25, 2007 at 04:13:06PM -0400, J. Bruce Fields wrote:
> On Tue, Sep 25, 2007 at 04:02:52PM -0400, bfields wrote:
> > I think we should try to keep the git documentation mostly confined to
> > tools that are distributed with git itself. So it might be worth a few
> > words just to mention the existance of tailor and how it compares to
> > other tools, but I'd leave it at that.
>
> So in fact it might be that what's needed isn't any new documentation on
> the available tools with their features and limitations.
(Uh, I meant to say: "isn't any new documentation on individual tools,
but rather a list of the available tools with their features and
limitations.")
>
> I know that when I recently had to deal with a svn tree the hardest part
> was figuring out where to start (git-svn? git-svnimport?). I seem to
> recall threads here suggesting this is a general problem.
>
> One exception--the "series of tarballs" thing--I think it's cool that
> you can just unpack a bunch of tarballs and string them together into a
> git history. It gives a good sense of how git works, and I don't think
> it's documented explicitly anywhere. I think that might be kinda fun to
> write up. But I haven't tried.
>
> --b.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Remove 'submodules' from the TODO section of the User Manual.
From: J. Bruce Fields @ 2007-09-25 20:13 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20070925200252.GV30845@fieldses.org>
On Tue, Sep 25, 2007 at 04:02:52PM -0400, bfields wrote:
> I think we should try to keep the git documentation mostly confined to
> tools that are distributed with git itself. So it might be worth a few
> words just to mention the existance of tailor and how it compares to
> other tools, but I'd leave it at that.
So in fact it might be that what's needed isn't any new documentation on
the available tools with their features and limitations.
I know that when I recently had to deal with a svn tree the hardest part
was figuring out where to start (git-svn? git-svnimport?). I seem to
recall threads here suggesting this is a general problem.
One exception--the "series of tarballs" thing--I think it's cool that
you can just unpack a bunch of tarballs and string them together into a
git history. It gives a good sense of how git works, and I don't think
it's documented explicitly anywhere. I think that might be kinda fun to
write up. But I haven't tried.
--b.
^ permalink raw reply
* Re: [PATCH] Remove 'submodules' from the TODO section of the User Manual.
From: J. Bruce Fields @ 2007-09-25 20:02 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20070925195731.GJ18370@genesis.frugalware.org>
On Tue, Sep 25, 2007 at 09:57:31PM +0200, Miklos Vajna wrote:
> i was this in the todo:
>
> "Add a section on working with other version control systems, including
> CVS, Subversion, and just imports of series of release tarballs."
>
> to questions:
>
> 1) does this include documentation about git-svn? i mean a howto similar
> to the submodules chapter.
Could be. Though when I used it I thought the git-svn manpage was
actually very good, so I'd be tempted to just point to that.
> 2) does it worth to document a typical usage of tailor? we used it a lot
> when converting from darcs to git and once you figure out the right
> options, it's really easy to use it. but maybe it's unrelated.
I think we should try to keep the git documentation mostly confined to
tools that are distributed with git itself. So it might be worth a few
words just to mention the existance of tailor and how it compares to
other tools, but I'd leave it at that.
--b.
^ permalink raw reply
* Re: [PATCH] Remove 'submodules' from the TODO section of the User Manual.
From: Miklos Vajna @ 2007-09-25 19:57 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20070925194936.GU30845@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
On Tue, Sep 25, 2007 at 03:49:36PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> And there's a ton of other stuff on that todo list if you're looking to
> make more "noise"--patches always welcomed....
i was this in the todo:
"Add a section on working with other version control systems, including
CVS, Subversion, and just imports of series of release tarballs."
to questions:
1) does this include documentation about git-svn? i mean a howto similar
to the submodules chapter.
2) does it worth to document a typical usage of tailor? we used it a lot
when converting from darcs to git and once you figure out the right
options, it's really easy to use it. but maybe it's unrelated.
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-25 19:55 UTC (permalink / raw)
To: git
In-Reply-To: <fdbmve$8lj$1@sea.gmane.org>
"Steven Burns" <royalstream@hotmail.com> writes:
> The C++ community in general suffers a lot from the NIH Syndrome.
> Matrixes, Strings, Vectors, everybody creates their own which are always, or
> course, superior to what's already available.
>
> Again, is not the language's fault, a language is just a language.
> It's the way it has been driven.
Having loose wires instead of a brake pedal in a car because the user
might prefer to brake with his teeth or by wiggling his backside or
building any other contraption of his own invention is a design
mistake. Especially when we are talking about public transportation
with changing drivers.
Making a language huge and bloated in order to be able to use the
language itself for defining a set of basic data types is just
masturbation. C++ has the most complicated set of implicit
conversions from any language in the world, and what for? It is
modeled for being able to create a user-defined "complex" type which
behaves almost as well as Fortran's. Too bad that this mostly means
everybody will define his own type (well, at least we have seen two or
three different library "standards" by now), and that the implicit
conversion rules and chains are appallingly wrong for a number of
other possible user-defined arithmetic types.
--
David Kastrup
^ permalink raw reply
* Re: diffcore-rename performance mode
From: Jeff King @ 2007-09-25 19:52 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86641y4k34.fsf@lola.quinscape.zz>
On Tue, Sep 25, 2007 at 09:32:31PM +0200, David Kastrup wrote:
> > | stock | nofree | old somefree | fixed somefree
> > -----------------|-----------------------------------------------
> > user time (s) | 76.78 | 16.96 | 46.26 | 16.99
> > peak memory (Kb) | 52300 | 66796 | 59156 | 57328
> >
> > So now we're at a 4.5x speedup for about 10% extra memory usage. Patch
> > will follow.
>
> Sounds good except when we happen to just hit the "memory working set
> exceeds physical memory" sweet spot. But the odds are much better
> than for "nofree".
Of course, there is the possibility that it is the 10% that pushes you
into swap (or kills your ability to cache the entire pack in RAM).
However, this is probably not a big deal for two reasons:
1. this is a 50M process handling the linux-2.6 repository. Other
operations such as repacking already consume significantly more
memory (git-repack -a allocates 290M on the same repo).
2. I specifically turned off rename limiting (-l0) to do rename
detection on these large-ish diffs. If you have a machine which is
on the cusp of swapping, then don't do that. Jumping from -l100
(the default) to -l0 in my tests is _already_ moving you from 28M
to 52M, a much larger jump.
-Peff
^ permalink raw reply
* Re: Workflow question
From: Wincent Colaiuta @ 2007-09-25 19:50 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Russ Brown, git
In-Reply-To: <20070925193416.GB8564@coredump.intra.peff.net>
El 25/9/2007, a las 21:34, Jeff King escribió:
> On Tue, Sep 25, 2007 at 09:09:00PM +0200, Andreas Ericsson wrote:
>
>> We came to the same conclusion at our workplace. Email works
>> great, but
>> it's faster and better to just walk over to your colleague and ask
>> what
>> he/she thinks about something.
>
> One of the projects I am working on does things this way, but I
> have to
> admit that I miss the email code-review process. There are often small
> fixups (stylistic, minor nits, "I would have done it this way...",
> etc)
> that are worth pointing out at the time, but are more painful to go
> back
> and correct much later.
>
> And documenting those discussions can really help other developers
> besides the author and reviewer.
Google has a pretty interesting internal code review system:
<http://video.google.com/videoplay?docid=-8502904076440714866>
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Remove 'submodules' from the TODO section of the User Manual.
From: J. Bruce Fields @ 2007-09-25 19:49 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20070925194745.GI18370@genesis.frugalware.org>
On Tue, Sep 25, 2007 at 09:47:45PM +0200, Miklos Vajna wrote:
> On Tue, Sep 25, 2007 at 03:23:15PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > Thanks, but it looks like Michael Smith already included this in his
> > latest patch:
> >
> > http://marc.info/?l=git&m=119072428615724&w=2
>
> ah, my bad. i missed that. sorry for the noise :)
No problem.
And there's a ton of other stuff on that todo list if you're looking to
make more "noise"--patches always welcomed....
--b.
^ permalink raw reply
* Re: [PATCH] Remove 'submodules' from the TODO section of the User Manual.
From: Miklos Vajna @ 2007-09-25 19:47 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20070925192315.GR30845@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Tue, Sep 25, 2007 at 03:23:15PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> Thanks, but it looks like Michael Smith already included this in his
> latest patch:
>
> http://marc.info/?l=git&m=119072428615724&w=2
ah, my bad. i missed that. sorry for the noise :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Workflow question
From: Russ Brown @ 2007-09-25 19:42 UTC (permalink / raw)
To: git
In-Reply-To: <46F95CCC.4080209@op5.se>
Andreas Ericsson wrote:
> Russ Brown wrote:
>> Hi,
>>
>> I've been trying to think of a git workflow that we could use to replace
>> our current svn/svk setup without simply using git in exactly the same
>> way that we use svn/svk.
>>
>> Basically, we develop, maintain and enhance a website. On the central
>> repo is trunk which represents live, and any number of project branches.
>> Developers don't use local branches: they check out the project branches
>> they're working on and commit to those. Developers merge from trunk to
>> project branch from time to time to keep them current, and when a
>> project rolls out the branch is merged to trunk.
>>
>> In addition to the obvious advantages that git would give us (such as
>> properly tracking that code author as opposed to the person who did the
>> merge), I'm wanting to gain the following benefits:
>>
>> * The repository is very large (multiple gigabytes) and mirroring using
>> svk obviously takes a lot of time and space, so I'm keen to bring that
>> down, most likely by the developer not needing to mirror branches he
>> doesn't care about, or by being able to throw away branches he's done
>> with.
>> * The repository is full of revisions that fail review (or break
>> things) and are fixed by subsequent revisions. We'd much rather be able
>> to have the developer fix his revisions before they get committed
>> 'upstream' (whatever that ends up meaning).
>>
>> I asked earlier about the email-based model that git itself uses, and
>> while it appears to work very well for a widely-dispersed open-source
>> project, I think it will be too cumbersome and slow for a fast-paced
>> internal development team who make a number of live releases every day.
>>
>
> We came to the same conclusion at our workplace. Email works great, but
> it's faster and better to just walk over to your colleague and ask what
> he/she thinks about something.
>
Very true, with the minor exception that at my place there are
developers working at different sites, so the walk-over method will only
work for specific subsets of the team. :)
>> So, I've been thinking and have come up with this, which I'd appreciate
>> comments about:
>>
>> 1. On a server we stick a git repository which contains the master
>> branch, which represents what trunk did (i.e. the live platform). This
>> branch contains the full history for the live platform.
>
> A must-have for any more-than-two-developers setup, so so far so good ;-)
>
>> 2. On the same server we clone that repo to create a second repository
>> which is the developer area. In this we track master from the live repo,
>> and also create project branches.
>
> This isn't necessary. Branches in git are very nearly zero-cost, so having
> them in the same repo as the master branch won't hurt a bit. You can add
> an update-hook on the mothership repo to restrict access to the master
> branch if you like, but creating two separate repos will likely give
> more headache than it's worth.
>
Ah, right. I'm just trying to remember why it was I came up with that
idea in the first place, but I'm struggling a bit. :)
>> 3. Developers clone this developer repo, but I'd like them to be able
>> to decide which branches they actually want to clone from that
>> repository rather than simply cloning them all. Is this possible?
>
> Yes, although I'd actually recommend you to clone the full repo anyway.
> Since the various branches are likely to share quite a lot of history
> the added overhead of a few extra branches will most likely be negligible.
> git makes even very large codebases appear small and unobtrusive. The
> linux kernel history since 2.6.12 contains 554853 objects and compresses
> down to 178MiB.
>
Makes sense. Thing is, with git-svn (which I've been using for a while
now) it's possible to 'bring in' an upstream branch at will by adding it
to your config file, and on next git-svn fetch revisions that affect
that branch are automatically fetched. I figured it would just be a
little more efficient, though I appreciate it involves more 'fiddling'
by the client users.
Here's a question: is the creation and deletion of a branch also version
controlled as it is in Subversion? In other words, if I create a branch,
develop on it and delete it without merging it anywhere, will the
revisions hang around and get pulled down by future people cloning the
repository, or do they get thrown away?
> I think KDE is the largest repo imported to git so far. I've forgotten
> the exact numbers, but everyone was very impressed, and quite surprised,
> at the vast difference between SVN and git storage requirements.
>
>
>> 4. Developers create a local branch of the project they
>> are working on and commit to that.
>> 5. Once they think they're done, they publish their branch to the
>> development repo and request for comments.
>
> Using topic-branches is a much better strategy, usually, since that
> allows each feature to be evaluated and improved on on its own, rather
> than having to merge *all* of a particular developers changes just to
> get desirable feature X. Note that cherry-pick provides ways of doing
> that anyways, but in a much less elegant way, and your integrator/
> release engineer will likely tear his hair out on a daily basis without
> topic branches.
>
I've seen the term 'topic-branch' used here quite a bit but it's
unfamiliar to me. It is basically synonymous with what we call a
'project branch'? i.e. Management decide that feature X is required so
we create a branch to develop it on which all developers on the project
commit to.
Note that in step 4 above I mean the developer takes a local branch of
the topic branch. For example, we start projectX/main, and create branch
projectX on the shared repo. Developer 'jeff' works on the project and
so creates local branch projectX/jeff and begins work. In step 5 they
push this local branch to the shared repo so everyone can see it
(alternative to the 'walk-over' method or emailing). Note that all
changes jeff making in projectX/jeff are specific to the project branch,
so he can rebase against other changes that get committed to that
project branch.
If colleagues don't like his changes he can create projectXjeff2 and try
again.
Jeff can also have other local branches to keep separate changes he is
making on the other projects he is involved in.
That's how I'd thought of it happening...
>> 6. If all is not well, the developer creates a new local branch and
>> moves good revisions from his previous one to the new one, modifying
>> things as he goes, and republishes his new branch.
>> 7. If all is well, their works gets merged or rebased onto the main
>> project branch, and once that's ready it gets pushed to the master and
>> rolled to live. The developer's individual branches get deleted from the
>> dev repo since they're no longer required.
>
> Topic branches would work the same, basically, except they can be pushed up
> for review a lot faster.
>
> If all the pushing gets cumbersome, it also makes it easy to send the
> patches
> out as emails for discussion. It's usually easier to let git handle the
> actual code transmissions, but discussing patches in emails works quite
> well if it's intended for a wider audience.
>
Yes, I am going to experiment with this a little too to see just how
much work it would involve for the developers (if it's too much they
won't do it) :)
>> 8. From time to time the master branch gets merged to the project
>> branches. Developer's local branches can be rebased against the project
>> branch as they please.
>>
>
> criss-cross merging can turn kinda nasty though, as you may have a hard
> time
> finding *the* common point when you run into that rogue merge with conflict
> markers everywhere (it happens for everyone sooner or later).
>
> I'd suggest you rebase the developer/topic branches onto master with
> regular
> intervals instead.
>
Having been using git-svn for a while I really like the clean history
result that rebase gives, however my understanding was that you should
never rebase any published branch as it could screw up clones of that
branch. In fact, this is what has me the most confused: how to rebase a
project branch that is on a shared repository against master when
everyone will have it cloned? Or is this something that I clearly don't
understand properly?
(Thanks for your answers BTW Andreas)
--
Russ
^ permalink raw reply
* Re: diffcore-rename performance mode
From: David Kastrup @ 2007-09-25 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <20070925190640.GA4613@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Sep 25, 2007 at 12:38:43PM -0400, Jeff King wrote:
>
>>[...]
>>
>> What is most confusing is why the 'somefree' case performs so badly,
>> since we should just be using the cnt_data. I'll see if gprof can shed
>
> OK, I found the problem. estimate_similarity calls
> diff_populate_filespec each time, even if we already have the cnt_data,
> which leads to recomputing the blob contents from deltas. Oops.
>
> Fixing this, the correct numbers are:
>
> | stock | nofree | old somefree | fixed somefree
> -----------------|-----------------------------------------------
> user time (s) | 76.78 | 16.96 | 46.26 | 16.99
> peak memory (Kb) | 52300 | 66796 | 59156 | 57328
>
> So now we're at a 4.5x speedup for about 10% extra memory usage. Patch
> will follow.
Sounds good except when we happen to just hit the "memory working set
exceeds physical memory" sweet spot. But the odds are much better
than for "nofree".
--
David Kastrup
^ permalink raw reply
* Re: Workflow question
From: Jeff King @ 2007-09-25 19:34 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Russ Brown, git
In-Reply-To: <46F95CCC.4080209@op5.se>
On Tue, Sep 25, 2007 at 09:09:00PM +0200, Andreas Ericsson wrote:
> We came to the same conclusion at our workplace. Email works great, but
> it's faster and better to just walk over to your colleague and ask what
> he/she thinks about something.
One of the projects I am working on does things this way, but I have to
admit that I miss the email code-review process. There are often small
fixups (stylistic, minor nits, "I would have done it this way...", etc)
that are worth pointing out at the time, but are more painful to go back
and correct much later.
And documenting those discussions can really help other developers
besides the author and reviewer.
-Peff
^ permalink raw reply
* [PATCH] diffcore-rename: cache file deltas
From: Jeff King @ 2007-09-25 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
We find rename candidates by computing a fingerprint hash of
each file, and then comparing those fingerprints. There are
inherently O(n^2) comparisons, so it pays in CPU time to
hoist the (rather expensive) computation of the fingerprint
out of that loop (or to cache it once we have computed it once).
Previously, we didn't keep the filespec information around
because then we had the potential to consume a great deal of
memory. However, instead of keeping all of the filespec
data, we can instead just keep the fingerprint.
This patch implements and uses diff_free_filespec_data_large
to accomplish that goal. We also have to change
estimate_similarity not to needlessly repopulate the
filespec data when we already have the hash.
Practical tests showed 4.5x speedup for a 10% memory usage
increase.
Signed-off-by: Jeff King <peff@peff.net>
---
The implementation is a little less nice than I would like, but I was
trying to be non-invasive. Specifically:
- the name diff_free_filespec_data_large is horrible, but this is based
on the fact that diff_free_filespec_data actually does too much (it
frees the data _and_ some other auxiliary data). And renaming that
would entail changing many callsites.
- It seems that a better place to call diffcore_populate_filespec
(rather than in estimate_similarity) would actually be in
diffcore_count_changes (when we _know_ that we need to populate the
contents data).
- The hash_chars() should arguably be tied into
diffcore_populate_filespec, which should have more of a "what
information do you want" interface. I.e., the "size_only" parameter
could be extended to a bitfield to say "populate this, and I need the
delta fingerprint, size, actual contents, etc". Then callers could
just use "populate" before looking at the filespec and it would
lazily load whatever they needed.
This patch cuts my pathological case from 20 minutes to 2 minutes, which
is a great improvement, but still unusable. However, now I should be
able to get more useful numbers on what else can be sped up.
diff.c | 7 ++++++-
diffcore-rename.c | 7 ++++---
diffcore.h | 1 +
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 2216d75..647bcf0 100644
--- a/diff.c
+++ b/diff.c
@@ -1654,7 +1654,7 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
return 0;
}
-void diff_free_filespec_data(struct diff_filespec *s)
+void diff_free_filespec_data_large(struct diff_filespec *s)
{
if (s->should_free)
free(s->data);
@@ -1665,6 +1665,11 @@ void diff_free_filespec_data(struct diff_filespec *s)
s->should_free = s->should_munmap = 0;
s->data = NULL;
}
+}
+
+void diff_free_filespec_data(struct diff_filespec *s)
+{
+ diff_free_filespec_data_large(s);
free(s->cnt_data);
s->cnt_data = NULL;
}
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 41b35c3..4fc2000 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -184,7 +184,8 @@ static int estimate_similarity(struct diff_filespec *src,
if (base_size * (MAX_SCORE-minimum_score) < delta_size * MAX_SCORE)
return 0;
- if (diff_populate_filespec(src, 0) || diff_populate_filespec(dst, 0))
+ if ((!src->cnt_data && diff_populate_filespec(src, 0))
+ || (!dst->cnt_data && diff_populate_filespec(dst, 0)))
return 0; /* error but caught downstream */
@@ -377,10 +378,10 @@ void diffcore_rename(struct diff_options *options)
m->score = estimate_similarity(one, two,
minimum_score);
m->name_score = basename_same(one, two);
- diff_free_filespec_data(one);
+ diff_free_filespec_data_large(one);
}
/* We do not need the text anymore */
- diff_free_filespec_data(two);
+ diff_free_filespec_data_large(two);
dst_cnt++;
}
/* cost matrix sorted by most to least similar pair */
diff --git a/diffcore.h b/diffcore.h
index eef17c4..4bf175b 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -48,6 +48,7 @@ extern void fill_filespec(struct diff_filespec *, const unsigned char *,
extern int diff_populate_filespec(struct diff_filespec *, int);
extern void diff_free_filespec_data(struct diff_filespec *);
+extern void diff_free_filespec_data_large(struct diff_filespec *);
extern int diff_filespec_is_binary(struct diff_filespec *);
struct diff_filepair {
--
1.5.3.2.1061.gc056e-dirty
^ permalink raw reply related
* Re: [PATCH] Remove 'submodules' from the TODO section of the User Manual.
From: J. Bruce Fields @ 2007-09-25 19:23 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20070925191159.GG18370@genesis.frugalware.org>
On Tue, Sep 25, 2007 at 09:11:59PM +0200, Miklos Vajna wrote:
> A chapter about this topic has been added recently.
Thanks, but it looks like Michael Smith already included this in his
latest patch:
http://marc.info/?l=git&m=119072428615724&w=2
--b.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Steven Burns @ 2007-09-25 19:19 UTC (permalink / raw)
To: git
In-Reply-To: <86odfstbc6.fsf@lola.quinscape.zz>
The C++ community in general suffers a lot from the NIH Syndrome.
Matrixes, Strings, Vectors, everybody creates their own which are always, or
course, superior to what's already available.
Again, is not the language's fault, a language is just a language.
It's the way it has been driven.
My two cents.
"David Kastrup" <dak@gnu.org> wrote in message
news:86odfstbc6.fsf@lola.quinscape.zz...
> figo <rcc_dark@hotmail.com> writes:
>
>> http://www.research.att.com/~bs/applications.html
>>
>> just as Bjarne once wrote in his TC++PL, its hard to teach an old dog new
>> tricks. Its even harder to give quality education about how to use
>> something
>> to someone who doesnt want to learn.
>>
>> you hate high level, then continue programming operative systems,
>> please NEVER DO something else. C++ was designed to give programmers
>> high level tools and still being able to take care about
>> performance.
>>
>> portability wont be possible after a standard is published and some
>>couple of years given to the compiler developers. C++ had its
>>standard in 1998, and add two or three years for compiler development
>>= 2002. "Quite recently", way more recently that your last use of C++
>>I can bet.
>
> Care to explain why there are still not two numerical C++ libraries
> with compatible matrix classes?
>
> What use is talking about portability and high level when a basic
> interoperability feature that has been available since the sixties
> (more than 4 decades ago) in Fortran has not yet managed to make it
> into C++? C++ by now more or less offers a (somewhat deficient)
> standardized way to work with complex numbers, but matrices are still
> not standardized in any manner, and libraries won't interoperate.
>
> So C++ should get its head wrapped around the _low_ level problems
> first. It is a bloody shame that it still has not caught up with
> Fortran IV (or even Fortran II) with regard to usefulness for
> numerical libraries.
>
> It is not a matter of "hating high level" to see that C++ is mostly
> focused about addressing the wrong kinds of problems in the wrong
> ways. The pain/gain ratio is just bad.
>
> --
> David Kastrup
>
^ permalink raw reply
* [PATCH] Remove 'submodules' from the TODO section of the User Manual.
From: Miklos Vajna @ 2007-09-25 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
A chapter about this topic has been added recently.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
i forgot to include this change in my previous patch, so here is the
correction.
Documentation/user-manual.txt | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a085ca1..e4b04d0 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4277,5 +4277,3 @@ Write a chapter on using plumbing and writing scripts.
Alternates, clone -reference, etc.
git unpack-objects -r for recovery
-
-submodules
--
1.5.3.2.80.g077d6f-dirty
^ permalink raw reply related
* Re: diffcore-rename performance mode
From: Andreas Ericsson @ 2007-09-25 19:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070925190640.GA4613@coredump.intra.peff.net>
Jeff King wrote:
> On Tue, Sep 25, 2007 at 12:38:43PM -0400, Jeff King wrote:
>
>> [...]
>>
>> What is most confusing is why the 'somefree' case performs so badly,
>> since we should just be using the cnt_data. I'll see if gprof can shed
>
> OK, I found the problem. estimate_similarity calls
> diff_populate_filespec each time, even if we already have the cnt_data,
> which leads to recomputing the blob contents from deltas. Oops.
>
> Fixing this, the correct numbers are:
>
> | stock | nofree | old somefree | fixed somefree
> -----------------|-----------------------------------------------
> user time (s) | 76.78 | 16.96 | 46.26 | 16.99
> peak memory (Kb) | 52300 | 66796 | 59156 | 57328
>
> So now we're at a 4.5x speedup for about 10% extra memory usage. Patch
> will follow.
>
Nice work :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Workflow question
From: Andreas Ericsson @ 2007-09-25 19:09 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46F93A99.5080707@gmail.com>
Russ Brown wrote:
> Hi,
>
> I've been trying to think of a git workflow that we could use to replace
> our current svn/svk setup without simply using git in exactly the same
> way that we use svn/svk.
>
> Basically, we develop, maintain and enhance a website. On the central
> repo is trunk which represents live, and any number of project branches.
> Developers don't use local branches: they check out the project branches
> they're working on and commit to those. Developers merge from trunk to
> project branch from time to time to keep them current, and when a
> project rolls out the branch is merged to trunk.
>
> In addition to the obvious advantages that git would give us (such as
> properly tracking that code author as opposed to the person who did the
> merge), I'm wanting to gain the following benefits:
>
> * The repository is very large (multiple gigabytes) and mirroring using
> svk obviously takes a lot of time and space, so I'm keen to bring that
> down, most likely by the developer not needing to mirror branches he
> doesn't care about, or by being able to throw away branches he's done with.
> * The repository is full of revisions that fail review (or break
> things) and are fixed by subsequent revisions. We'd much rather be able
> to have the developer fix his revisions before they get committed
> 'upstream' (whatever that ends up meaning).
>
> I asked earlier about the email-based model that git itself uses, and
> while it appears to work very well for a widely-dispersed open-source
> project, I think it will be too cumbersome and slow for a fast-paced
> internal development team who make a number of live releases every day.
>
We came to the same conclusion at our workplace. Email works great, but
it's faster and better to just walk over to your colleague and ask what
he/she thinks about something.
> So, I've been thinking and have come up with this, which I'd appreciate
> comments about:
>
> 1. On a server we stick a git repository which contains the master
> branch, which represents what trunk did (i.e. the live platform). This
> branch contains the full history for the live platform.
A must-have for any more-than-two-developers setup, so so far so good ;-)
> 2. On the same server we clone that repo to create a second repository
> which is the developer area. In this we track master from the live repo,
> and also create project branches.
This isn't necessary. Branches in git are very nearly zero-cost, so having
them in the same repo as the master branch won't hurt a bit. You can add
an update-hook on the mothership repo to restrict access to the master
branch if you like, but creating two separate repos will likely give
more headache than it's worth.
> 3. Developers clone this developer repo, but I'd like them to be able
> to decide which branches they actually want to clone from that
> repository rather than simply cloning them all. Is this possible?
Yes, although I'd actually recommend you to clone the full repo anyway.
Since the various branches are likely to share quite a lot of history
the added overhead of a few extra branches will most likely be negligible.
git makes even very large codebases appear small and unobtrusive. The
linux kernel history since 2.6.12 contains 554853 objects and compresses
down to 178MiB.
I think KDE is the largest repo imported to git so far. I've forgotten
the exact numbers, but everyone was very impressed, and quite surprised,
at the vast difference between SVN and git storage requirements.
> 4. Developers create a local branch of the project they
> are working on and commit to that.
> 5. Once they think they're done, they publish their branch to the
> development repo and request for comments.
Using topic-branches is a much better strategy, usually, since that
allows each feature to be evaluated and improved on on its own, rather
than having to merge *all* of a particular developers changes just to
get desirable feature X. Note that cherry-pick provides ways of doing
that anyways, but in a much less elegant way, and your integrator/
release engineer will likely tear his hair out on a daily basis without
topic branches.
> 6. If all is not well, the developer creates a new local branch and
> moves good revisions from his previous one to the new one, modifying
> things as he goes, and republishes his new branch.
> 7. If all is well, their works gets merged or rebased onto the main
> project branch, and once that's ready it gets pushed to the master and
> rolled to live. The developer's individual branches get deleted from the
> dev repo since they're no longer required.
Topic branches would work the same, basically, except they can be pushed up
for review a lot faster.
If all the pushing gets cumbersome, it also makes it easy to send the patches
out as emails for discussion. It's usually easier to let git handle the
actual code transmissions, but discussing patches in emails works quite
well if it's intended for a wider audience.
> 8. From time to time the master branch gets merged to the project
> branches. Developer's local branches can be rebased against the project
> branch as they please.
>
criss-cross merging can turn kinda nasty though, as you may have a hard time
finding *the* common point when you run into that rogue merge with conflict
markers everywhere (it happens for everyone sooner or later).
I'd suggest you rebase the developer/topic branches onto master with regular
intervals instead.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox