* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: H. Peter Anvin @ 2005-10-31 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q6xfpqg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I do not know much about how things are done in the RPM world,
> but is there a concept of "the upstream" vs "packaging
> maintainer" there? IOW, are the majority of RPM binary packages
> done by the upstream maintainer?
>
It does both ways. I think Chris Wright has been doing the formal
maintenance of RPM for Fedora.
Latency is an issue, though, especially for kernel.org.
-hpa
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Randal L. Schwartz @ 2005-10-31 19:44 UTC (permalink / raw)
To: wa1ter; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510311013200.11219@x2.ybpnyarg>
>>>>> "wa1ter" == wa1ter <wa1ter@myrealbox.com> writes:
wa1ter> Ahh -- the lightbulb just lit up. Using CVS is just like
wa1ter> being married. No wonder you hate it...
Now, hey hey. I've met Tove. She's very nice. I doubt that Linus
would compare his marriage to her with CVS. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Joel Becker @ 2005-10-31 19:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, walt, git
In-Reply-To: <Pine.LNX.4.64.0510310804400.27915@g5.osdl.org>
On Mon, Oct 31, 2005 at 08:18:49AM -0800, Linus Torvalds wrote:
> With git (or with BK, or any truly decentralized model), you just make
> your own repo, do your development there, and you never need to ask for
> permissions from the central repo people. If the development works out,
> you just ask people to merge back. And if it doesn't, you don't even have
> to tell people what a total failure you were.
Actually, Linus, this provokes a question I've always wanted the
answer to. I'm well aware of the centralized/distributed stuff you are
discussing, but there is policy regarding the distributed merges I've
never been quite clear on.
When one does a feature branch, one creates a "throw-away"
repository. They work on the feature, and when they are done, they
pull/push back to the main repository. This pattern is pretty much
identical in both centralized in distributed environments, even if the
nuts-and-bolts are different.
In the CVS/Subversion world, this merge becomes a single commit
on the "main" line of development ("trunk", or whatever you call it).
The merge has no concept of the steps taken to create the change, just
the actual patch. This has the disadvantage that you have to work hard
in the branch namespace to find the actual steps taken (the working
repository for the feature), but the advantage that a quick look does
not have to wade through fits and starts as the feature takes shape.
In the distributed world, a pull of the "feature" repository
pulls in all changes - the full history of the work. This includes
aborted tries, rewritten pieces, bug fixes, etc. Here, the main
repository has the detritus of the development process, but that also
contains the full context of the work. It goes against your claim that:
> So with the distributed model, you don't have to publicly humiliate
> yourself when you do something stupid. Similarly, you don't have to
because that history will contain all your something stupids, plus your
fixes for them.
But that's not how the kernel and git appear to work. Many
developers have popularized dropping that context. They take their
working repository, diff it against your mainline repository, and then
create a new repository that is merely your mainline plus one commit,
the patch of their changes.
This violently breaks the model of "work in a new repository,
then have it pulled into the 'main' repository." It has no real support
in the git/cogito command space (that I know of). It does, however,
leave all the intermediate commits out of your tree, with only a feature
commit remaining.
Where do you stand on this? Would you rather see the full
history pulled? Do you prefer the one-clean-patch approach? If so, is
there any way to get a cogito/git command for it (git-pull-as-one?)?
Joel
--
"Drake! We're LEAVING!"
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: git push sends more objects than it needs to
From: Luck, Tony @ 2005-10-31 19:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510311119170.27915@g5.osdl.org>
On Mon, Oct 31, 2005 at 11:36:09AM -0800, Linus Torvalds wrote:
> a) The "don't do that then" approach:
>
> Don't go behind git's back and add objects on your own, and expect git
> to realize what you did. ;^p
To be a responsible kernel.org git user I need to use packfiles. The
cheapest and easiest way to do that is to steal them from you.
> b) The "live with it" approach:
>
> You copied the pack by hand, and that will keep git-unpack-objects
> from duplicating the objects, but you'll still waste time and network
> when trying pushing the objects (just once, though).
>
> Ie this is what happened this time: nothing really lost, and the end
> result is fine. Now you know why it happened, and you're fine.
I like this one best. There's a pretty fat pipe between here and
kernel.org ... more of the time wasted appeared to be on the
unpacking part than on the transfer.
> d) Just let git do it for you.
>
> Copy the pack-files, or add my object directory as an "alternates" for
> your object directory, do the "git prune-objects", and then _locally_
> on master.kernel.org just do something like
Longer term (when everyone is pulling using the "git" protocol)
adding your object directory to my info/alternates looks to be
the best thing.
-Tony
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Martin Langhoff @ 2005-10-31 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git, Sebastian Kuzminsky
In-Reply-To: <7v4q6xfpqg.fsf@assigned-by-dhcp.cox.net>
On 11/1/05, Junio C Hamano <junkio@cox.net> wrote:
> git-tla-import, git-cvs-import, git-svn-import, ...::
> Importers, one per foreign SCMs.
I concur generally with the plan, except that I think we should wrap
the import/export scripts together(*). One-script-per-package is
pretty awkward, and yet the dependencies for a
git-export-import-scripts packages are going to be awful as they'll
often pull a whole raft of SCMs.
Hmmm.
Perhaps git-tla-glue, git-cvs-glue, git-svn-glue, where glue stands
for importers, exporters, tools, etc?
*- I'm starting to think that the script to replay git commits into
cvs that I posted last week (cleaned up patch coming soon) should
follow the git-cvsimport convertion and be something along the lines
of git-cvsexportpatch, to be followed by git-cvsexport which would
automate discovering what patches need exporting and drive
git-cvsexportpatch.
> git-docs::
> Generated documentation from Documentation hierarchy.
>
> git-core::
> All the rest, plus man pages. We could separate out
> commit walkers if we wanted to, but I do not think that
> is necessary.
git-gitk ;-)
> I am currently generating i386 RPMs and i386 debs myself but I
> am not particularly proud of the current setup. I do not have
> an RPM based machine that I can install the result myself to
> test (which is what started this thread). Since I am not a
> Debian developer (and I do not particularly wish to become one
> myself), the debs I generate will not be official anyway.
> Personally I'd be happier if I can just lose rpm and deb targets
> from the "upstream" Makefile (git-core.spec file and debian/
> subdirectory as well while we are at it), ask "packaging
> maintainers" to pull from kernel.org/ tree and do RPMs and Debs
> outside.
I'd say you can probably keep the current setup, and as distro
(format?) specific maintainers show up and start maintaining bits and
pieces, merge from them. git should make that easy ;-)
I'm not a DD -- but I'm on the 'NM queue' which means I'm in the
process of turning into one (delayed at the moment, but hapenning
soonish). Have a package in the archive, and a few sponsors who are
generally happy to upload my work. Would be happy to give it a go if
noone else steps up.
(Sebastian _did_ indicate interest, and fought a long, hard battle in
debian-devel about the naming of the git and cg utilities. I haven't
seen him around lately (last post:
http://marc.theaimsgroup.com/?l=git&m=112747921603277&w=2 ). May be on
holiday? CC'd)
> On the other hand, having the basic support for packagers in the
> upstream might be easier for port maintainers. I honestly do
> not know.
I think it'd be easier for all people involved if each port/packjage
maintainer keeps a published repo and you merge from them. Patches
have higher visibility and easier path towards "upstream".
Maintainers want to keep the delta between their package and upstream
to the bare minimum.
> One thing we could do without breaking much of the current
> arrangement is to have a team of people to help porting for
> major packaging formats (RPMs and Debs mostly but I know we have
> OpenBSD and Darwin people here too), and ask them to feed me the
> updates to rpm/deb/whatever target in the Makefile as needed.
That's another good strategy. I suspect that you can push work towards
maintainers, so they publish 2 branches: one of forupstream patches
and one of 'local' patches. They have to do that anyway ;-)
cheers,
martin
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Martin Langhoff @ 2005-10-31 20:28 UTC (permalink / raw)
To: Joel Becker; +Cc: Linus Torvalds, Johannes Schindelin, walt, git
In-Reply-To: <20051031195010.GM11488@ca-server1.us.oracle.com>
On 11/1/05, Joel Becker <Joel.Becker@oracle.com> wrote:
> Where do you stand on this? Would you rather see the full
> history pulled? Do you prefer the one-clean-patch approach? If so, is
> there any way to get a cogito/git command for it (git-pull-as-one?)?
You can do a diff that spans all the commits and apply it with a new
commit msg. With cogito:
cg-diff -r from:to | patch -p1
With git you can also do it directly within the repo/index with
git-read-tree -m from HEAD to
In practice, a new developer will often roll up commits to avoid
sending a string of shameful patches and corrections on top -- I often
do that ;-) . Developers with more "mana" will have published repos
where Junio pulls directly from -- and they get merged with full
history. Of course -- they don't have brown-paper-bag commits like I
do...
Sounds like a reasonable, organic/dynamic way of doing it.
cheers,
martin
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Linus Torvalds @ 2005-10-31 20:32 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, H. Peter Anvin, git, Sebastian Kuzminsky
In-Reply-To: <46a038f90510311213n565010d6g5586a7484b25da7e@mail.gmail.com>
On Tue, 1 Nov 2005, Martin Langhoff wrote:
> >
> > git-core::
> > All the rest, plus man pages. We could separate out
> > commit walkers if we wanted to, but I do not think that
> > is necessary.
>
> git-gitk ;-)
I really really prefer gitk in the core, even if it means that there's
that strange tcl/tk dependency.
It's very small, and having something that visualizes what git does for
people who don't understand git is _invaluable_.
It wouldn't have to be gitk, but that's the least pain right now. qgit
needs QT, which is much more contentious than tcl/tk.
Linus
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Sebastian Kuzminsky @ 2005-10-31 20:39 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <46a038f90510311213n565010d6g5586a7484b25da7e@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 11/1/05, Junio C Hamano <junkio@cox.net> wrote:
> > I am currently generating i386 RPMs and i386 debs myself but I
> > am not particularly proud of the current setup. I do not have
> > an RPM based machine that I can install the result myself to
> > test (which is what started this thread). Since I am not a
> > Debian developer (and I do not particularly wish to become one
> > myself), the debs I generate will not be official anyway.
> > Personally I'd be happier if I can just lose rpm and deb targets
> > from the "upstream" Makefile (git-core.spec file and debian/
> > subdirectory as well while we are at it), ask "packaging
> > maintainers" to pull from kernel.org/ tree and do RPMs and Debs
> > outside.
>
> I'd say you can probably keep the current setup, and as distro
> (format?) specific maintainers show up and start maintaining bits and
> pieces, merge from them. git should make that easy ;-)
>
> I'm not a DD -- but I'm on the 'NM queue' which means I'm in the
> process of turning into one (delayed at the moment, but hapenning
> soonish). Have a package in the archive, and a few sponsors who are
> generally happy to upload my work. Would be happy to give it a go if
> noone else steps up.
>
> (Sebastian _did_ indicate interest, and fought a long, hard battle in
> debian-devel about the naming of the git and cg utilities. I haven't
> seen him around lately (last post:
> http://marc.theaimsgroup.com/?l=3Dgit&m=3D112747921603277&w=3D2 ). May be
> on holiday? CC'd)
I'm here :-)
The GNU Interactive Tools people are changing their name (to "gitfm"),
but they want a script called "git" to remind people that the name
has changed... So I still have to rename our git to "gt" or something,
until they remove their git script.
We're going to use update-alternatives so people who dont care about
GNU Interactive Tools can call their git "git". This is in violation
of Debian Policy, but I'm hoping my sponsor will forgive me, as it is
just a temporary violation.
I hope to get this work done sometime this week, and if I have anything
useful I'll send the patches to the list.
--
Sebastian Kuzminsky
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Martin Langhoff @ 2005-10-31 20:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, H. Peter Anvin, git, Sebastian Kuzminsky
In-Reply-To: <Pine.LNX.4.64.0510311230290.27915@g5.osdl.org>
On 11/1/05, Linus Torvalds <torvalds@osdl.org> wrote:
> I really really prefer gitk in the core, even if it means that there's
> that strange tcl/tk dependency.
I agree, but that's kind of a bummer for servers where someone just
wants to publish a couple of repos. tk depends on xlibs/libx11 and
that's just _nasty_.
git-core should be good for deployment on a server. Perhaps we want to
provide a git-scm package that brings in all the goodies you're likely
to want, including gitk?
martin
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: H. Peter Anvin @ 2005-10-31 20:46 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Junio C Hamano, git, Sebastian Kuzminsky
In-Reply-To: <46a038f90510311244n5fc35166k43ea2410e92d83d4@mail.gmail.com>
Martin Langhoff wrote:
>
> I agree, but that's kind of a bummer for servers where someone just
> wants to publish a couple of repos. tk depends on xlibs/libx11 and
> that's just _nasty_.
>
> git-core should be good for deployment on a server. Perhaps we want to
> provide a git-scm package that brings in all the goodies you're likely
> to want, including gitk?
>
How about calling it just "git"?
-hpa
^ permalink raw reply
* [PATCH] Add an option to delete a patch from a certain branch
From: Paolo 'Blaisorblade' Giarrusso @ 2005-10-31 20:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Actually, simply adding the option is enough...
Restrict print_crt_patch() to the case when we didn't specify --branch (as it's
useless otherwise).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
stgit/commands/delete.py | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/delete.py b/stgit/commands/delete.py
--- a/stgit/commands/delete.py
+++ b/stgit/commands/delete.py
@@ -32,8 +32,8 @@ be part of the unapplied list or be the
case the command also popping it from the stack. Note that the
'delete' operation is irreversible."""
-options = []
-
+options = [make_option('-b', '--branch',
+ help = 'use BRANCH instead of the default one')]
def func(parser, options, args):
"""Deletes a patch
@@ -48,4 +48,6 @@ def func(parser, options, args):
crt_series.delete_patch(args[0])
print 'Patch "%s" successfully deleted' % args[0]
- print_crt_patch()
+
+ if not options.branch:
+ print_crt_patch()
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Junio C Hamano @ 2005-10-31 21:00 UTC (permalink / raw)
To: Joel Becker; +Cc: git
In-Reply-To: <20051031195010.GM11488@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> In the distributed world, a pull of the "feature" repository
> pulls in all changes - the full history of the work. This includes
> aborted tries, rewritten pieces, bug fixes, etc. Here, the main
> repository has the detritus of the development process, but that also
> contains the full context of the work. It goes against your claim that:
>
>> So with the distributed model, you don't have to publicly humiliate
>> yourself when you do something stupid. Similarly, you don't have to
>
> because that history will contain all your something stupids, plus your
> fixes for them.
Do you think anybody is that perfect?
What happens in reality is something like this:
- you have a master tree, and your own throwaway topic
branches.
- you play in your own topic branches. you make stupid
mistakes and redo your changes many times.
- when the tips of your topic branches are in good shape, you
review the changes from the master tree as a whole, without
the history.
- you decompose the diff between the tips of your topic branch
and the master branch into logical steps.
- you branch off "sanitized" branches from the tip of the
master, and apply the decomposed diffs, making one commit per
logical change, until all your decomposed diffs are applied.
- after making sure that the tips of the sanitized branches
match the tips of their corresponding topic branch you did
your work on, you throw away your true history and pretend
you are perfect human. Either ask your peer to pull from
your sanitized branch tips, or run git-format-patch between
the master and the sanitized branch tips and send them out as
patches.
I do not know about the kernel tree but I would be surprised if
any self-respecting developer wouldn't be doing this. The
review-decomposition-reapplication cycle is *very* important for
both keeping the public history clean and reviewable, and
preservign your public image ;-).
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Junio C Hamano @ 2005-10-31 21:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: H. Peter Anvin, git, Sebastian Kuzminsky
In-Reply-To: <46a038f90510311213n565010d6g5586a7484b25da7e@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Perhaps git-tla-glue, git-cvs-glue, git-svn-glue, where glue stands
> for importers, exporters, tools, etc?
That sounds sensible. Also I think not having to install xlib
on the repository server is an advantage as you said in your
reply to Linus.
So here is a revised strawman, just to keep things in one place:
git::
Depends on all of the below (may not be necessary).
git-*-glue::
Tools to interoperate with foreign SCM systems,
including importing (i.e. obtaining changes from them)
and exporting (i.e. injecting our changes into them).
git-doc::
Generated documentation from Documentation hierarchy.
git-scm::
Depends on git-gitk and git-core -- people who want just
a self contained SCM can install this and perhaps
git-doc.
git-gitk::
The gitk history browser.
git-core::
The rest. Meant for repository server installation.
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Joel Becker @ 2005-10-31 21:30 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Johannes Schindelin, walt, git
In-Reply-To: <46a038f90510311228v50743158q80d79e963bd503ce@mail.gmail.com>
On Tue, Nov 01, 2005 at 09:28:30AM +1300, Martin Langhoff wrote:
> You can do a diff that spans all the commits and apply it with a new
> commit msg. With cogito:
>
> cg-diff -r from:to | patch -p1
I'm well aware of this, my question was rather one of
applicability. First, do we want it to work this way, losing the
history. Second, you'd like the process to be all encompasing if you go
this route.
((cd old-repo && cg-diff -r from) | patch -p1) && cg-commit
or any equivalent. Why should I have to muck with patch and diff, when
I can have a 'pull-as-one' operation. Sure, it's a wrapper, but if its
the intended mode of development, let's make it a first-class citizen.
Joel
--
Life's Little Instruction Book #157
"Take time to smell the roses."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: David Lang @ 2005-10-31 21:31 UTC (permalink / raw)
To: Martin Langhoff
Cc: Linus Torvalds, Junio C Hamano, H. Peter Anvin, git,
Sebastian Kuzminsky
In-Reply-To: <46a038f90510311244n5fc35166k43ea2410e92d83d4@mail.gmail.com>
On Tue, 1 Nov 2005, Martin Langhoff wrote:
> On 11/1/05, Linus Torvalds <torvalds@osdl.org> wrote:
>> I really really prefer gitk in the core, even if it means that there's
>> that strange tcl/tk dependency.
>
> I agree, but that's kind of a bummer for servers where someone just
> wants to publish a couple of repos. tk depends on xlibs/libx11 and
> that's just _nasty_.
>
> git-core should be good for deployment on a server. Perhaps we want to
> provide a git-scm package that brings in all the goodies you're likely
> to want, including gitk?
for debian make it a reccomendation not a requirement, for RPM the admins
will just have to override the dependancy (it's not like they don't have
to do this for a bunch of other packages that have an optional GUI piece,
RPM just doesn't have the option to list a reccomendation)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Linus Torvalds @ 2005-10-31 21:35 UTC (permalink / raw)
To: Joel Becker; +Cc: Johannes Schindelin, walt, git
In-Reply-To: <20051031195010.GM11488@ca-server1.us.oracle.com>
On Mon, 31 Oct 2005, Joel Becker wrote:
>
> In the CVS/Subversion world, this merge becomes a single commit
> on the "main" line of development ("trunk", or whatever you call it).
> The merge has no concept of the steps taken to create the change, just
> the actual patch. This has the disadvantage that you have to work hard
> in the branch namespace to find the actual steps taken (the working
> repository for the feature), but the advantage that a quick look does
> not have to wade through fits and starts as the feature takes shape.
Note that I'm a big proponent of people cleaning up their private
work-in-progress trees before merging.
In fact, I'll refuse to merge with too dirty a repository. It's ok to have
some fixes for mistakes, but if you have a lot of ugly stuff, use git to
first track the development, and then start a new branch that has the
cleaned-up version in it.
> > So with the distributed model, you don't have to publicly humiliate
> > yourself when you do something stupid. Similarly, you don't have to
>
> because that history will contain all your something stupids, plus your
> fixes for them.
No, exactly because you do _not_ have to publicly humiliate yourself with
showing what a nincompoop you are.
People should try things out, but they should clean up their worst
mistakes too. Git allows both.
Linus
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Joel Becker @ 2005-10-31 21:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7a1e719.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 31, 2005 at 01:00:18PM -0800, Junio C Hamano wrote:
> Do you think anybody is that perfect?
I was being slightly facetious. Of course everyone makes
mistakes and corrects them. But if you _want_ the history, you have to
take it. Otherwise, you are required to throw away the history
completely. And that -- do you want the whole history or none of it --
is the crux of my question.
> What happens in reality is something like this:
[ understood work model snipped ]
> I do not know about the kernel tree but I would be surprised if
> any self-respecting developer wouldn't be doing this. The
> review-decomposition-reapplication cycle is *very* important for
> both keeping the public history clean and reviewable, and
> preservign your public image ;-).
I could care less about preserving my public image. I'm an
idiot, I screw up all the time. I only care that the tip of my tree is
respectable.
I've seen arguments from folks on both sides -- the intermediate
history is important, warts and all, vs throw it all out for a clean
public history. It seems that you fall into the second camp.
That's fine, but can we make that work model a first-class
citizen? Can we get a script that pulls one branch as a single,
un-historied (sic) commit into the current branch? If this is The Way,
I should have to be mucking about with many steps of diff/patch (at
least unless my change is large enough to require split patches).
Joel
--
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
- Robert H. Jackson
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: Another problem with not existing directories
From: Marcel Holtmann @ 2005-10-31 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6ftil38.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
> >> Are you sure you just don't have an old version of git on the other end?
> >
> > this might be possible, but then it is an old git on kernel.org. I never
> > installed any git by myself on it.
>
> I just tried this myself; master.kernel.org seems to have
> 0.99.8f in /usr/bin/, which explains this symptom.
so as soon as kernel.org switches to 0.99.9 everything should be fine
again. That's great.
Regards
Marcel
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Linus Torvalds @ 2005-10-31 21:53 UTC (permalink / raw)
To: Joel Becker; +Cc: Junio C Hamano, git
In-Reply-To: <20051031213616.GO11488@ca-server1.us.oracle.com>
On Mon, 31 Oct 2005, Joel Becker wrote:
>
> I could care less about preserving my public image. I'm an
> idiot, I screw up all the time. I only care that the tip of my tree is
> respectable.
I definitely care about more than just the tip.
A broken history is a _problem_. Automatic tools like "git bisect" can't
help you if you have lots of commits in between that are fundamentally
broken. And even ignoring that, it just makes it harder for everybody to
understand what the code does when "git-whatchanged" shows total crap that
was undone.
History is important. It's important enough that you should keep it
meaningful. And "meaningful" does not mean "show all your mistakes".
Some people will say that the mistakes are as important as the fixes. I
call bull on that. Mistakes are mistakes. Dead ends aren't useful, even as
historical examples.
At the same time, I'm not a rabid "history must be perfect" freak.
Mistakes happen. Just fix then and move on.
When you have guests over, I sure hope that you don't walk around in your
bathrobe, with pieces of your anatomy sticking out that shouldn't stick
out. Sure, it may be the "real you", but there's a difference between
being honest, and just being disgusting.
The same is true of SCM history. There's "honesty", and there's "digusting
mess". At least when it comes to the kernel, I want the "honest" kind of
history, not the "disgusting" kind.
Linus
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Junio C Hamano @ 2005-10-31 22:14 UTC (permalink / raw)
To: git
In-Reply-To: <20051031213616.GO11488@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> On Mon, Oct 31, 2005 at 01:00:18PM -0800, Junio C Hamano wrote:
>> Do you think anybody is that perfect?
>
> I was being slightly facetious. Of course everyone makes
> mistakes and corrects them. But if you _want_ the history, you have to
> take it. Otherwise, you are required to throw away the history
> completely. And that -- do you want the whole history or none of it --
> is the crux of my question.
> I could care less about preserving my public image. I'm an
> idiot, I screw up all the time. I only care that the tip of my tree is
> respectable.
> I've seen arguments from folks on both sides -- the intermediate
> history is important, warts and all, vs throw it all out for a clean
> public history. It seems that you fall into the second camp.
> That's fine, but can we make that work model a first-class
> citizen? Can we get a script that pulls one branch as a single,
> un-historied (sic) commit into the current branch?
I think you read me wrong. Didn't I say "decompose and make
them into logical stepS", emphasis on plural "S"?
Single big consolidated patch is not what I am advocating for.
It is impossible to review and evaluate. To be merged into a
public tree, such unhistoried commit is often unacceptable.
^ permalink raw reply
* Re: Question on GIT usage.
From: Daniel Barkalow @ 2005-10-31 23:03 UTC (permalink / raw)
To: Ben Greear; +Cc: Git Mailing List
In-Reply-To: <4362C700.6020901@candelatech.com>
On Fri, 28 Oct 2005, Ben Greear wrote:
> I have a kernel GIT tree to hold my developing patches...
>
> I need to build this kernel for 4-5 different processors (c3, p2, p4, p4-smp,
> etc).
>
> Is there any clever way to have this one git repository keep these
> other source trees in sync so that I can do incremental builds?
The following is not at all standard; AFAICT, I'm the only person who does
it. But...
You can have a single repository shared between multiple working trees, by
having the repository somewhere and making
.git/{objects,refs,info,remotes} be symlinks to the corresponding
directories in the repository. I've got a script to set this up, if you
want.
The system will be unhappy if you commit to a branch that is checked out
elsewhere (because the head of that branch will change out from under the
checked out version), like having someone push to a repository with the
branch checked out.
You need to think about this as there only being one repository that has
multiple working trees, rather than having working tree/repository pairs,
where the repositories are connected as an optimization; anything you do
in one of the working trees will automatically affect what the others see.
This isn't official supported, but it actually works quite well, except
that things that should be shared are occasionally added to the .git
directory (like remotes not too long ago).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Question on GIT usage.
From: Linus Torvalds @ 2005-10-31 23:21 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ben Greear, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510311749080.25300@iabervon.org>
On Mon, 31 Oct 2005, Daniel Barkalow wrote:
>
> The system will be unhappy if you commit to a branch that is checked out
> elsewhere (because the head of that branch will change out from under the
> checked out version), like having someone push to a repository with the
> branch checked out.
Well, the good news is that a "git checkout -f" in the other trees will do
the right thing (and only check out the files that have changed).
The bad news is that you need to remember to do that ;)
Linus
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Joel Becker @ 2005-10-31 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6ftcp0d.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 31, 2005 at 02:14:58PM -0800, Junio C Hamano wrote:
> I think you read me wrong. Didn't I say "decompose and make
> them into logical stepS", emphasis on plural "S"?
>
> Single big consolidated patch is not what I am advocating for.
> It is impossible to review and evaluate. To be merged into a
> public tree, such unhistoried commit is often unacceptable.
No, you're reading me wrong, but I wasn't clear enough either.
At the end of my message, I'm noting that I'm considering smaller
changes here, not huge features.
Basically, I'm not talking about merging with Linus. I'm
talking about merging with myself. Let's assume we're all going with
the clean-up-your-history model. It is quite clear that you and Linus
agree on that model, and I wasn't so much arguing against it as querying
everyone's opinion on it.
So, I have a git repository that is my For-Linus repository.
It's got a clean history. What's my workflow?
1) Clone the repo to a Work tree.
2) Create and test fix X, with perhaps some >1 number of commits.
3) Bring that fix back to the For-Linus repository.
This is a small change. It's not something that needs stepS, as
you put them. But my history in the Work tree is "dirty," so I cannot
just pull from Work to For-Linus.
As the tools currently stand, I need to hand-diff and patch my
commits. Neither git nor cogito have a command to do this first-class
"the way you should do it" common operation. It is, in my experience, a
pain. Not as large a pain as some things, but certainly second class to
much of the workflow git/cogito provide. If it is supposed to be a
regular part of my workflow, what's wrong with making it a first-class
operation?
Obviously, large features should and do have logical steps. I'm
never going to be against that.
Joel
--
Life's Little Instruction Book #15
"Own a great stereo system."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: Question on GIT usage.
From: Daniel Barkalow @ 2005-10-31 23:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ben Greear, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510311520190.27915@g5.osdl.org>
On Mon, 31 Oct 2005, Linus Torvalds wrote:
> On Mon, 31 Oct 2005, Daniel Barkalow wrote:
> >
> > The system will be unhappy if you commit to a branch that is checked out
> > elsewhere (because the head of that branch will change out from under the
> > checked out version), like having someone push to a repository with the
> > branch checked out.
>
> Well, the good news is that a "git checkout -f" in the other trees will do
> the right thing (and only check out the files that have changed).
>
> The bad news is that you need to remember to do that ;)
If we wanted to make this work reliably, we could have a
"LAST_CHECKED_OUT" which has an actual hash (rather than being a link like
HEAD is), and gets set by the checkout. Then it would always know what
commit you have checked out, even if something causes HEAD to not match.
I personally just never have the same branch checked out twice, so the
situation doesn't happen to me. It's easy enough to add additional
branches.
Oh, that reminds me: is there a simple way to merge a branch with another
local branch or remote branch that's already up-to-date? E.g., I've
already fetched the latest git from kernel.org, built it, and installed
it. Now I want to merge my development branch with that. Last time I was
looking, I had to write the message for the merge myself, unlike "pull",
which takes care of that.
Also, I have a repository on my server for one of my projects. I push from
my workstation to the "mainline" branch, and I have "deploy" checked out
(with some configuration changes that shouldn't propagate back). Then I
merge "mainline" into "deploy", build, and install. Same thing; I have to
write the "merge with mainline" argument myself.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Question on GIT usage.
From: Linus Torvalds @ 2005-10-31 23:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ben Greear, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510311821410.25300@iabervon.org>
On Mon, 31 Oct 2005, Daniel Barkalow wrote:
>
> Oh, that reminds me: is there a simple way to merge a branch with another
> local branch or remote branch that's already up-to-date? E.g., I've
> already fetched the latest git from kernel.org, built it, and installed
> it. Now I want to merge my development branch with that. Last time I was
> looking, I had to write the message for the merge myself, unlike "pull",
> which takes care of that.
Umm.. Why don't you just use "pull"?
I _think_ you should be able to just do
git pull <repodir> <branchname>
where <repodir> can even be just "." for the very same repository.
I've not tested it, but dammit, it should work. If it doesn't, it's a bug.
Linus
^ 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