* Re: dangling commits
From: Marco Roeland @ 2006-01-16 11:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Marco Roeland, Junio C Hamano, git
In-Reply-To: <43CB753D.2030706@op5.se>
On Monday January 16th 2006 Andreas Ericsson wrote:
> Since "pu" = "proposed updates" it only makes sense to keep it on top of
> the current master, otherwise the effort required for anyone to test it
> in conjunction with the latest master branch would simply be too great.
Certainly. And it probably is a good testbed for testing the rebasing
routines as well.
But couldn't (in theory) the new "rebased" versions of blobs in the "pu"
branch be first committed as the old not yet rebased version and then
as the new version. Not the fact that the blobs in "pu" are constantly
based on the latest master was the problem if I recollect, but the fact
that blobs sometimes disappeared. In comparing this with Linus' recent
explanation how git-bisect works in terms of light cones this might be
understood as the inherent problems with tachyons I think...
Anyway this is now solved I understand. Thanks.
> >I since removed it from the "Pull" list, but understand that "+pu"
> >should do the trick. I'll retry using it one of these days.
>
> It does. I also remember seeing lots of errors on that one when I first
> started with git (around 0.99b), but that was fixed quite some time ago.
Ok, thanks very much for explaining.
--
Marco Roeland
^ permalink raw reply
* Re: What's cooking in git.git
From: Petr Baudis @ 2006-01-16 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd8al3ae.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jan 12, 2006 at 01:04:41AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - Disable USE_SYMLINK_HEAD by default (Pavel Roskin).
>
> This has been on hold for almost two months -- forever in git
> timescale.
>
> One offender that could have been broken by this change was
> fixed recently (gitweb), so this can go in anytime now. Do
> people still care about it? The argument for the change when
> it was proposed was "then we only have to worry about one
> format of .git/HEAD, not two", and it still is a valid
> argument from Porcelain writers' point of view. To be
> honest, since I do not do Porcelain, I am neutral about it.
Yes, I'd still be pleased to see this. Cogito should be ready for this
for long enough, as far as I'm concerned.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: RFC: Subprojects
From: Josef Weidendorfer @ 2006-01-16 10:44 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7vek3ah8f9.fsf@assigned-by-dhcp.cox.net>
On Saturday 14 January 2006 21:16, you wrote:
> Yes, I agree to the above 100%; the serious disadvantages come
> from the fact that we do not have clear separation between
> subprojects -- which new files belong to what subproject. I
> ...
> - Extend "commit" objects for the toplevel project to record
> what subprojects with what head commits are contained at
> which subdirectory.
The suggested "bind" info in commit objects has the same problem
as the original overlay: if the superproject already has a
subdirectory kernel/, and there is an additional "bind" specification
in commits also for kernel/, what should be done?
So the gitlink object seems to be the only solution if we want to
bind git versions of subprojects into a superproject.
But as this seems to make everything quite complex and not-obvious for
a user, I am with Paskys simple subproject idea.
Josef
^ permalink raw reply
* Re: dangling commits
From: Andreas Ericsson @ 2006-01-16 10:28 UTC (permalink / raw)
To: Marco Roeland; +Cc: Junio C Hamano, git
In-Reply-To: <20060116101722.GB5196@fiberbit.xs4all.nl>
Marco Roeland wrote:
> On Monday January 16th Junio C Hamano wrote:
>
>
>>Even when you use git native protocol, the objects the initial
>>clone gives you are kept packed, so when I rewind and rebuild
>>"pu" to make some of these objects orphaned, they will stay in
>>the pack the initial clone gave you. Unpack+repack is needed to
>>get rid of them.
>
>
> Thanks very much for explaining. It makes sense now.
>
> Does it bring many advantages for you to keep rebasing "pu"?
Since "pu" = "proposed updates" it only makes sense to keep it on top of
the current master, otherwise the effort required for anyone to test it
in conjunction with the latest master branch would simply be too great.
> I started
> out following that branch long ago (well in git reckoning anyway) but
> got very scared each time I got a bunch of "errors" on that one.
> I since removed it from the "Pull" list, but understand that "+pu"
> should do the trick. I'll retry using it one of these days.
It does. I also remember seeing lots of errors on that one when I first
started with git (around 0.99b), but that was fixed quite some time ago.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: dangling commits
From: Marco Roeland @ 2006-01-16 10:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Roeland, git
In-Reply-To: <7vr778wmj3.fsf@assigned-by-dhcp.cox.net>
On Monday January 16th Junio C Hamano wrote:
> Even when you use git native protocol, the objects the initial
> clone gives you are kept packed, so when I rewind and rebuild
> "pu" to make some of these objects orphaned, they will stay in
> the pack the initial clone gave you. Unpack+repack is needed to
> get rid of them.
Thanks very much for explaining. It makes sense now.
Does it bring many advantages for you to keep rebasing "pu"? I started
out following that branch long ago (well in git reckoning anyway) but
got very scared each time I got a bunch of "errors" on that one. I even
recloned a couple of times to get it "clean" again, until I understood
from the mailing-list that the rebasing was the cause, not something I
did. I since removed it from the "Pull" list, but understand that "+pu"
should do the trick. I'll retry using it one of these days.
--
Marco Roeland
^ permalink raw reply
* Re: RFC: Subprojects
From: Andreas Ericsson @ 2006-01-16 10:16 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Junio C Hamano, git
In-Reply-To: <200601161328.04985.lan@ac-sw.com>
Alexander Litvinov wrote:
> On Saturday 14 January 2006 14:59, Junio C Hamano wrote:
>
>>Now I'll think aloud about a completely different design.
>>
>>We could simply overlay the projects. I think this is what
>>Johannes suggested earlier.
>>
>>You keep one branch for each "subproject", and make commits into
>>each branch (i.e. if you modified files for the upstream kernel,
>>the change is committed to the branch for linux-2.6 subproject),
>>but when checking things out, you do an equivalent of octopus
>>merge across subprojects.
>
> If I cleary understand this idea it is NOT that I dreaming about. Almost all
> our sub-projects are used in more than one project (imaging network layer
> library). So variant with gitlink is that I willing.
Then it isn't so much a subproject as a separate project of its own.
Otherwise glibc would be a subproject of pretty much everything and
that's hardly a sane setup.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: dangling commits
From: Marco Roeland @ 2006-01-16 10:08 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Marco Roeland, git
In-Reply-To: <20060116093249.8F939353A3F@atlas.denx.de>
On Monday January 16th 2006 Wolfgang Denk wrote:
> I like to have my repository "clean" so there are no warnings
> normally from git-fsck-objects - if you get used to expect some
> "harmless" messages you might easily miss a critical error.
That's right, yes.
> > However you can easily get rid of them by using "git prune".
>
> Tried this, didn't work.
Ok, didn't know that it didn't prune directly from packs. I should have
realised that it only can do so efficiently by repacking I suppose.
> Ummm... please have a look at the .git/objects/pack/ directory for
> example in your Linux repository.
I did as a matter of fact, but I use "git" as protocol and also
regularly "repack" the repository, when I'm not using the machine for
a while, to make 'gitk' and 'qgit' work faster. It is less apparent
then! Thanks very much for clearing up my knowledge. It only shows the
power of git that even ignorant gits like myself still find it useful
and productive. There's just enough rope to wiggle yourself out of
precarious situations but fortunately most of the time not enough to
hang yourself.
--
Marco Roeland
^ permalink raw reply
* Re: dangling commits
From: Wolfgang Denk @ 2006-01-16 9:32 UTC (permalink / raw)
To: Marco Roeland; +Cc: git
In-Reply-To: <20060116085238.GA3768@fiberbit.xs4all.nl>
In message <20060116085238.GA3768@fiberbit.xs4all.nl> you wrote:
>
> Note that apart from the disk space they use up, dangling commits don't
> do any harm.
I like to have my repository "clean" so there are no warnings
normally from git-fsck-objects - if you get used to expect some
"harmless" messages you might easily miss a critical error.
> However you can easily get rid of them by using "git prune".
Tried this, didn't work.
> As far as I know although packs are used in transferring the commits to
> your local repository they are stored there as separate objects, so you
Ummm... please have a look at the .git/objects/pack/ directory for
example in your Linux repository.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It seems intuitively obvious to me, which means that it might be
wrong. -- Chris Torek
^ permalink raw reply
* Re: dangling commits
From: Junio C Hamano @ 2006-01-16 9:27 UTC (permalink / raw)
To: Marco Roeland; +Cc: git
In-Reply-To: <20060116085238.GA3768@fiberbit.xs4all.nl>
Marco Roeland <marco.roeland@xs4all.nl> writes:
> As far as I know although packs are used in transferring the commits to
> your local repository they are stored there as separate objects,...
That is true only when you are using git native protocols
(i.e. git:// and git over ssh). Some people pull over dumb
transport (http -- some others still use rsync which is even
dumber and has serious limitations), and when you need objects
that are contained in a pack at the upstream, the packfile is
downloaded as a whole, and it is left packed on your end.
Even when you use git native protocol, the objects the initial
clone gives you are kept packed, so when I rewind and rebuild
"pu" to make some of these objects orphaned, they will stay in
the pack the initial clone gave you. Unpack+repack is needed to
get rid of them.
As you said, they should not hurt much in practice, though.
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: Junio C Hamano @ 2006-01-16 9:15 UTC (permalink / raw)
To: John Ellson; +Cc: git
In-Reply-To: <43C95E25.3070006@research.att.com>
John Ellson <ellson@research.att.com> writes:
>> Of course you can keep a patch with the sed -e 's/-/_/' in
>> GIT-VERSION-GEN as Linus suggested in your development branch.
>>
> Thats basically all I'm looking for. I agree that is only necessary
> to fix the "make rpm" target.
> Further changes are not strictly necessary. I don't understand why
> it would only be useful to me?
OK, if somebody is RPM savvy enough to do his own binary RPM and
install it, he would know how to override the downgrade guard
the binary package manager would give him, so it probably is not
such a big deal. A patch to do "sed -e 's/-/./g'" will be
pushed out in the "master" branch shortly.
I hope if we later see complains on the list that some RPM cut
from an interim snapshot would not install, somebody would take
time to answer such complaints, pretty please?
^ permalink raw reply
* Re: [kernel.org users] [RFC] "clone --naked"?
From: Arjan van de Ven @ 2006-01-16 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ulrich Windl, git, users
In-Reply-To: <7vfynoy5p5.fsf_-_@assigned-by-dhcp.cox.net>
On Sun, 2006-01-15 at 23:47 -0800, Junio C Hamano wrote:
> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.DE> writes:
>
> > On 14 Jan 2006 at 15:39, Junio C Hamano wrote:
> >
> > [...]
> >> BTW, I have been meaning to make this easier, by introducing a
> >> new option to "git clone", like this:
> > ...
> > You must be over 21 to use --naked, however ;-)
> > Maybe you find a better word.
>
> Linus seems to use word "bare" sometimes. Checking the git-core
> documentation, repository-layout documentation first used the
> word naked on Sep 1 2005, while there is no mention of "bare"
> repository anywhere. Maybe "bare" is preferred?
>
> I hope you do not mind my sending this message out to git list
> to take a quick poll.
While I don't give a rats bottom about the "21"-ness of naked, "naked"
is more likely to trigger spam traps than "bare" though... just a side
consideration but unfortunately needed nowadays ;(
^ permalink raw reply
* Re: dangling commits
From: Marco Roeland @ 2006-01-16 8:52 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Junio C Hamano, git
In-Reply-To: <20060115221108.3ED2E352659@atlas.denx.de>
On Sunday January 15th 2006 Wolfgang Denk wrote:
> Is ther eany way to clean up such a situation and really get rid of
> the dangling commits? I understand that I'd first need some way to
> "unpack" the packs, but how to do this?
Note that apart from the disk space they use up, dangling commits don't
do any harm.
However you can easily get rid of them by using "git prune".
As far as I know although packs are used in transferring the commits to
your local repository they are stored there as separate objects, so you
certainly don't have to unpack things yourself for using "git prune".
Git is quite smart, fast and safe on its own I find each time! It really
is a wonderful tool by giving you every possibility to work with it
without inflicting policy on you.
If wanted you can use "git repack -a -d" followed by "git prune-packed"
to create a tight packed repository (all commits and blobs in one pack)
but there is no specific need to.
--
Marco Roeland
^ permalink raw reply
* Re: [PATCH] stgit: make tutorial a valid asciidoc article
From: Catalin Marinas @ 2006-01-16 8:21 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1137142486.20073.77.camel@dv>
On 13/01/06, Pavel Roskin <proski@gnu.org> wrote:
> There should be only one level 0 title in an article, so lower ranks of
> all headers by one. Make capitalization uniform in the headers - level
> 1 is capitalized, but level 2 is not. Create a new level 1 part
> "Technical Information".
>
> Make ".git/ Directory Structure" a level 2 header and rephrase.
> asciidoc doesn't like headers starting with a dot.
I agree with most of this but what's the difference when adding "~~~~"
instead of "----"?
Thanks.
--
Catalin
^ permalink raw reply
* Re: StGIT: "stg new" vs "stg new --force"
From: Catalin Marinas @ 2006-01-16 8:18 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Charles Lever
In-Reply-To: <1137144291.20073.104.camel@dv>
Hi Pavel,
On 13/01/06, Pavel Roskin <proski@gnu.org> wrote:
> Maybe I don't understand something in StGIT, but it seems strange that
> "stg new" creates empty patch by default and requires "--force" to
> create a non-empty patch.
The 'new' command would fail to create a new patch if there are
changes in the tree.
I also find myself using the '--force' option most of the time. Even
when I create a an empty patch, I use to run 'status' before. The
current implementation is closer to Quilt where, AFAIK, you first
create a new patch and use 'add' for every modified file. Since 'add'
has a different meaning in StGIT, it might also make sense to remove
the '--force' option.
> 1) "stg new --force" becomes "stg new" and "stg new" becomes "stg new
> --empty", i.e. empty files can only be created with the "--empty"
> switch.
> 2) "stg new --force" becomes "stg record" or something.
> 3) "stg new --force" becomes "stg new --record" or something.
> 4) "stg new" works both with and without modified files.
Regarding (1), the newly created patch is empty anyway, you would need
to run 'refresh' to add the modified patches to it ('stg series -e'
would show the empty patches prefixed with a 0).
Anyway, I would also prefer option 4. If there are no objections, I'll
modify StGIT accordingly. It would also be useful to have a wiki page
about StGIT vs. Quilt to show the main differences.
--
Catalin
^ permalink raw reply
* Re: RFC: Subprojects
From: Alex Riesen @ 2006-01-16 7:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: A Large Angry SCM, git, Junio C Hamano, Johannes Schindelin,
Simon Richter
In-Reply-To: <Pine.LNX.4.64.0601141154590.13339@g5.osdl.org>
On 1/14/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > So far I've not seen any convincing arguments why the sub-projects can not be
> > managed by the Makefile, or equivalent, of the super-project. Particularly
> > when the sub-projects have a life of their own.
>
> Now, from a developer standpoint I actually agree with you. I find
> sub-projects totally useless - I'm much happier just having separate
> trees.
>
> The advantage (as far as I can tell) of sub-projects is not that they are
> easier to develop in, but that it's a total nightmare for the technical
> _user_ to download ten different projects from ten different sites, and
> configure them properly and install them in the right order, and keep them
> up-to-date.
>
> There are projects that I simply gave up even trying to track: I wasn't
> interested in being a developer per se, but I _was_ interested in trying
> to test and give feedback to the current development tree - but it was
> just too damn confusing to get it working.
>
> If I could have just done a "git clone <top-level>" to get it all, I'd
> have been a much more productive user.
>
> This is why I think sub-projects are more about "git checkout" and an
> automated "git fetch" than anything else. Doing actual development etc you
> can easily do one project at a time. "git diff" and "git commit" wouldn't
> need any real ability to recurse into subprojects and try to make it
> seamless. And if you do a "git pull" that needs to do anything but
> fast-forward, you might as well resolve the sub-projects one by one.
That is exactly how subprojects are used in Perforce- and ClearCase-like SCM:
the working tree is "configured" to contain the super-project (build
configuration)
and the actual work happens in the subproject and _only_ there. The mentioned
systems even have heavily used permission system just to prevent either
checkout or commit anywhere outside the area of responsibility of a developer.
(The "permissions" are somehow pointless in git context, just mentioned them
to underline the main point).
^ permalink raw reply
* [RFC] "clone --naked"?
From: Junio C Hamano @ 2006-01-16 7:47 UTC (permalink / raw)
To: Ulrich Windl; +Cc: users, git
In-Reply-To: <43CB57A0.29999.F89D30F@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.DE> writes:
> On 14 Jan 2006 at 15:39, Junio C Hamano wrote:
>
> [...]
>> BTW, I have been meaning to make this easier, by introducing a
>> new option to "git clone", like this:
> ...
> You must be over 21 to use --naked, however ;-)
> Maybe you find a better word.
Linus seems to use word "bare" sometimes. Checking the git-core
documentation, repository-layout documentation first used the
word naked on Sep 1 2005, while there is no mention of "bare"
repository anywhere. Maybe "bare" is preferred?
I hope you do not mind my sending this message out to git list
to take a quick poll.
^ permalink raw reply
* Re: RFC: Subprojects
From: Alexander Litvinov @ 2006-01-16 7:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
On Saturday 14 January 2006 14:59, Junio C Hamano wrote:
> Now I'll think aloud about a completely different design.
>
> We could simply overlay the projects. I think this is what
> Johannes suggested earlier.
>
> You keep one branch for each "subproject", and make commits into
> each branch (i.e. if you modified files for the upstream kernel,
> the change is committed to the branch for linux-2.6 subproject),
> but when checking things out, you do an equivalent of octopus
> merge across subprojects.
If I cleary understand this idea it is NOT that I dreaming about. Almost all
our sub-projects are used in more than one project (imaging network layer
library). So variant with gitlink is that I willing.
^ permalink raw reply
* Re: [PATCH] new tutorial
From: Junio C Hamano @ 2006-01-16 5:32 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060116035731.GA14849@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
>> Empirically the first 7 hexdigits are enough (even 5 for small
>> projects such as git itself). In fact, in the linux-2.6
>> repository itself, it appears 5 hexdigits are enough to identify
>> all 171902 objects (not just commits) uniquely currently
>
> Five hex digits is only 20 bits, and 171902/2^20 > 1/10, so each
> additional object has a better than 1-in-10 chance of colliding with an
> existing object. The chances there hasn't been a collision in the first
> 5 digits by now must be practically zero. Maybe you're thinking bytes,
> not hex digits? Unless my math is wrong.
Your math is right and my script was wrong.
For linux-2.6 repository:
$ git rev-list --objects HEAD | sort >/var/tmp/objnames
$ wc -l </var/tmp/objnames
171902
$ sed -e 's/^\(........\).*/\1/' </var/tmp/objnames | uniq | wc -l
171899
$ sed -e 's/^\(.........\).*/\1/' </var/tmp/objnames | uniq | wc -l
171902
So 8 is enough for most but not all objects; you need 9 to
uniquely cover everybody.
^ permalink raw reply
* gitweb: latest blob date (request)
From: Randy.Dunlap @ 2006-01-16 5:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, kay.sievers
In-Reply-To: <17355.10749.834774.642712@cargo.ozlabs.ibm.com>
On Mon, 16 Jan 2006 16:07:09 +1100 Paul Mackerras wrote:
> Randy,
>
> > I would find it helpful (a user optimization) if each tree list
> > contained a date-last-modified/updated. This could be used
> > to help decide if I (someone) wanted to click on a particular
> > blob or history (OK, blobs are quick, but history can be
> > very time-consuming, so being able to shortcut or skip
> > history would be very helpful IMO).
>
> Are you talking about gitk or gitweb? If you mean gitweb on
> kernel.org, Kay Sievers is who you need to talk to.
Sheesh, you are correct. Sorry.
Redirecting to Kay.
---
~Randy
^ permalink raw reply
* Re: latest blob date (request)
From: Paul Mackerras @ 2006-01-16 5:07 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: git
In-Reply-To: <20060115173100.1134256b.rdunlap@xenotime.net>
Randy,
> I would find it helpful (a user optimization) if each tree list
> contained a date-last-modified/updated. This could be used
> to help decide if I (someone) wanted to click on a particular
> blob or history (OK, blobs are quick, but history can be
> very time-consuming, so being able to shortcut or skip
> history would be very helpful IMO).
Are you talking about gitk or gitweb? If you mean gitweb on
kernel.org, Kay Sievers is who you need to talk to.
Paul.
^ permalink raw reply
* Re: RFC: Subprojects
From: Daniel Barkalow @ 2006-01-16 5:06 UTC (permalink / raw)
To: Martin Langhoff
Cc: Junio C Hamano, gitzilla, git, Johannes Schindelin, Simon Richter
In-Reply-To: <46a038f90601141628n2ec32e8fy7fc23d8d7884c0f2@mail.gmail.com>
On Sun, 15 Jan 2006, Martin Langhoff wrote:
> On 1/15/06, Junio C Hamano <junkio@cox.net> wrote:
> > > The "get" rule for each sub-project could be something like:
> > >
> > > git_sub-project:
> > > mkdir sub-project
> > > cd sub-project
> > > git-init-db
> > > git-fetch <fetch-options> <repository> <refspec>
> > > git-checkout <branch>
> > > $(MAKE) get_sub_components
> >
> > There lies a drake here --- <repository> is not the same for
> > everybody. It is not a big showstopper dragon, though.
>
> Well, that /little complication/ applies to doing it in git too ;-)
> There's no way to tell how the dev doing the top level checkout has
> access to the subproject repos.
>
> I am with gitzilla on this one. Let the projects have their own
> bootstraping mechanisms, using make, ant or whatever catches their
> fancy. One of the great things about git is that it doesn't assume
> that it's being used by all the projects in the world -- thanks to
> Linus' disregard for arbitrary metadata and to your git-cherry
> implementation, it's all about the content -- and so it interoperates
> great with Arch, SVN, CVS, etc.
But most of the content of the project that started this thread is the
revisions of the subprojects. Sure, it could all be done in the build
system, but then it becomes impractical to manage. Git could refuse to
support tracking the executable bit on files, or what directories things
are in, and we could tell people to use their build systems to set these
things, but it would make the tool impractical to use. We want to track
some metadata, because it's actually important; what we don't want to
track is the metadata that is local to the particular working tree. That's
why we track only one executable bit, not a full set of permissions; it's
a matter of local policy who can interact with the files in a working
tree, but it's part of the content whether a file is executable.
So the problem with handling subprojects with the build system is that it
is too tempting to use the revision control system directly on the
subproject, at which point the thing you're developing and testing isn't
at all what other people will get if they check out your commit. You want
"git status" to report it as an uncommitted change if you have a different
revision of the subproject than your previous commit had, and it can't
tell if this information is buried in the build system.
I like Linus's proposal: which revision of which project goes where is
part of the content, while how you manipulate data for that project is a
matter of local policy, and is not tracked, although it might be a good
idea to let project provide overridable defaults (so that, if you're a
random member of the general public and don't have a special method for
accessing the repository, you don't have to track it down yourself).
The tricky question is whether we should permit the "subproject" objects
to specify a revision that isn't a hash, for use in identifying revisions
of subprojects in other systems.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] new tutorial
From: J. Bruce Fields @ 2006-01-16 3:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64olysw2.fsf@assigned-by-dhcp.cox.net>
On Sun, Jan 15, 2006 at 03:26:53PM -0800, Junio C Hamano wrote:
> We may want to mention that the canonical commit log message
> format is a single line "summary phrase", an empty line, and the
> body of the message.
Sounds reasonable. After the second mention of "commit -a" I've added:
A note on commit messages: though not required, it's a good idea
to begin the commit message with a single short (less than 50
character) line summarizing the change, followed by a blank line
and then a more thorough description. Tools that turn commits
into email, for example, use the first line on the Subject line
and the rest of the commit in the body.
(Alternatively, if we had more of this sort of thing we could collect
them into a "best practices" document to reference at the end.)
> A bit narrower fill-column settings, please.
Does 70 characters work for you?
And thanks for the rest of the comments; I'll work through them and then
send an update. (May be a few days.) I'll assume you want a
replacement unless you tell me you'd prefer an incremental diff.
This caught my eye:
> Empirically the first 7 hexdigits are enough (even 5 for small
> projects such as git itself). In fact, in the linux-2.6
> repository itself, it appears 5 hexdigits are enough to identify
> all 171902 objects (not just commits) uniquely currently
Five hex digits is only 20 bits, and 171902/2^20 > 1/10, so each
additional object has a better than 1-in-10 chance of colliding with an
existing object. The chances there hasn't been a collision in the first
5 digits by now must be practically zero. Maybe you're thinking bytes,
not hex digits? Unless my math is wrong.
But for these purposes we're just worried about the chance of a
particular string having a collision, which should be more like
(number of objects) / 2^(4*number of digits), so yeah, 16 digits is
overkill, good point.
> BTW, I do not see the CC'ed copy on list archives and am wondering why
> even though I see CC: header in the copy I received...
Maybe the list software didn't like the big patch?
> BTW^2, it might be interesting to do
>
> $ git format-patch -C origin..master
>
> the next time around.
Oh, I see, it catches the rename then. Neat.
--b.
^ permalink raw reply
* [ANNOUNCE] Cogito-0.16.3
From: Petr Baudis @ 2006-01-16 1:51 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
this is Cogito version 0.16.3, the next stable release of the
human-friendly version control UI for the Linus' GIT tool. Share
and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
All the fixes are of minor to normal severity. Pretty boring, and
that's what I love on the release the most - it seems that we are in a
quite stable state now. However, I am probably going to disrupt that
state with the v0.17 release, hopefully very soon - I got so used to it
that I wouldn't realize all the v0.16 users were deprived of the goodies
like cg-switch.
Michael Richardson:
Mark that gawk (not mawk) is required for cg-diff -c
Only show the fetch progress bar on terminals
Paolo 'Blaisorblade' Giarrusso:
Fix unconditional early exit of cg-fetch over rsync, v2
Petr Baudis:
Fix cg-push not always defaulting to 'master' remotely
Make it possible to push out new branches
Fix cg-clone -l of specific branch
Make cg-fetch return false if fetch_tags fails.
cogito-0.16.3
Happy hacking,
--
Petr "Pasky the Broken Hand" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: cvs-migration.txt
From: Martin Langhoff @ 2006-01-16 1:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, git
In-Reply-To: <7vy81h2o3a.fsf@assigned-by-dhcp.cox.net>
On 1/16/06, Junio C Hamano <junkio@cox.net> wrote:
> what we are
> saying here is that you should never commit into these branches
> yourself and let cvsimport be the only one that touch them, so
> using commiter date and author date would not make a difference.
Exactly. You should make a new head off the one imported from cvs, and
work there. This supports continued use of cvsimport if the cvs repo
is still active. To bring in those changes you will have to merge them
into your branch.
If you are 200% certain that the cvs repo is going to be removed
immediately, you can ignore this advice. Run the cvsimport once, and
then start developing on top. If you do this, however, don't run that
cvsimport ever again, for it will mess up things royally ;)
But it's a bad idea to keep using the same branches in any case. Life
is saner if you work on new heads.
martin
^ permalink raw reply
* latest blob date (request)
From: Randy.Dunlap @ 2006-01-16 1:31 UTC (permalink / raw)
To: paulus; +Cc: git
Hi,
I would find it helpful (a user optimization) if each tree list
contained a date-last-modified/updated. This could be used
to help decide if I (someone) wanted to click on a particular
blob or history (OK, blobs are quick, but history can be
very time-consuming, so being able to shortcut or skip
history would be very helpful IMO).
---
~Randy
^ 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