Catalin, Daniel,
thank you both for your input.
I'll try your recommendations (when time is available ;-) and see how it
goes.
Best regards,
Jan
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 30 Aug 2005, Catalin Marinas wrote:
Back from holiday. Thanks to all who replied to this thread.
On Tue, 2005-08-23 at 14:05 -0400, Daniel Barkalow wrote:
Having a useful diff isn't really a requirement for a parent; the diff in
the case of a merge is going to be the total of
Daniel Barkalow [EMAIL PROTECTED] wrote:
One factor not mentioned there is that, as things move upstream, we often
want to discard a lot of history; if someone commits constantly to deal
with editor malfunction or something, we don't really want to take all of
this junk into the project
On Tue, 23 Aug 2005, Catalin Marinas wrote:
So the point is that there are things which are, in fact, parents, but we
don't want to list them, because it's not desired information.
What's the definition of a parent in GIT terms? What are the
restriction for a commit object to be a parent?
Daniel Barkalow wrote:
On Tue, 23 Aug 2005, Catalin Marinas wrote:
Something is legitimate as a parent if someone took that commit and did
something to it to get the new commit. The operation which caused the
change is not specified. But you only want to include it if anyone cares
about
On Tue, 23 Aug 2005, Jan Veldeman wrote:
Daniel Barkalow wrote:
On Tue, 23 Aug 2005, Catalin Marinas wrote:
Something is legitimate as a parent if someone took that commit and did
something to it to get the new commit. The operation which caused the
change is not specified. But you
Catalin Marinas [EMAIL PROTECTED] writes:
What's the definition of a parent in GIT terms? What are the
restriction for a commit object to be a parent? Can a parent be an
arbitrarily chosen commit?
Yes it can. GIT does not care if the commit ancestry does not
make sense in contents terms
On Sun, 21 Aug 2005, Jan Veldeman wrote:
Catalin Marinas wrote:
So for example, you only tag (freeze) the history when exporting the
patches. When an error is being reported on that version, it's easy to
view
it and also view the progress that was already been made on those
On Fri, 2005-08-19 at 21:48 +0200, Jan Veldeman wrote:
I've quickly reread the threads about stg commit. Am I right to assume that
_all_ history was being recorded? Because this is not what I want. The
person controlling the archive should specify when to record the history.
True, I was
Hi,
I like stgit very much, but I feel there is still something missing:
stgit is very handy when you use it for patches which should be pushed to
mainline rather quickly. But for pacthes which won't be pushed immediately
to mainline, it would be usefull to have a history of the patches itself.
10 matches
Mail list logo
