* Re: dangling commits
From: Junio C Hamano @ 2006-01-15 22:55 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20060115221108.3ED2E352659@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> 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?
The easiest is to repack into a single big ball of wax:
$ git repack -a -d
If you know the pack the stale object is in, you can move it out
of objects/pack/ and repack only that one.
$ mv .git/objects/packs/pack-$badone.{idx,pack} .
$ git unpack-objects <pack-$badone.pack
$ git repack
After you are done:
$ git prune
^ permalink raw reply
* Re: [PATCH] new tutorial
From: Junio C Hamano @ 2006-01-15 23:26 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060115185458.GA3985@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> OK, now to partially contradict this,...
>...
> I think it makes sense for the main tutorial to address those beginnning
> users, so with this patch I'm proposing that we move
> Documentation/tutorial.txt to Documentation/core-tutorial.txt and
> replace it by a new tutorial.
Well done, and I think this new organization would serve people better.
> ** Documentation/tutorial.txt **
>...
> Finally,
>
> ------------------------------------------------
> $ git commit -a
> ------------------------------------------------
>
> will prompt you for a commit message, then record the current state of all the
> files to the repository.
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. The core does not enforce it, but it is a
good practice to get into because that is more compatible with
the e-mail workflow. The first line becomes subject and the rest
the message body, and we do not want the first line of an
multi-line sentence to be on the subject line, with the message
body starting in the middle of that sentence.
> This actually pulls from the branch in Bob's repository named "master". Alice
> could specify a different branch to pull from in a third argument to pull.
>
>...
A bit narrower fill-column settings, please.
> She can do this by creating a temporary branch just for the purpose of
> studying Bob's changes:
>
> -------------------------------------
> $ git branch bob-incoming
> $ git checkout bob-incoming
> $ git pull /home/bob/myrepo
> $ git-whatchanged -p
> --------------------------------------
Easier would be:
$ git fetch /home/bob/myrepo master:refs/heads/bob-incoming
$ git whatchanged -p HEAD..bob-incoming
You do not have to switch out of your "master" branch only to
fetch into a different branch. And it is usually a good
discipline not to commit yourself into a branch you use to keep
track of foreign branch. Which means you do not do the fixup in
bob-incoming branch, but either in your master or another
branch:
$ git checkout -b bob-fixup bob-incoming
$ edit
$ git commit -a -m 'Fixup frotz and filfre'
Then you can:
$ git checkout master
$ git pull . bob-fixup
> Fixing Mistakes
>...
> -------------------------------------
> $ git reset --mixed HEAD^
> -------------------------------------
I have a mixed feeling on this one. I tend to recommend --soft
instead --mixed to people, but both have their pros and cons:
* "reset --mixed HEAD^" reads the HEAD^ tree into the index, so
"git diff" shows your changes. However, it *forgets* all the
"git add" you did [*1*].
* "reset --soft HEAD^" does not touch the index, so "git diff"
would show the same thing as what you would have seen before
your reset, which means nothing after a commit you regret
about. You need to say "git diff --cached". But it does not
forget about "git add".
> $ git-cat-file commit 67ad31933f09677d0fed6ac62287f07441b215c6
> tree 4662df01e0e9cfd9b7fab83d7a5234ee651d8804
> parent 9e9b26751a5ca7a257b3e1cfb319fe3e4efc663c
> author J. Bruce Fields <bfields@puzzle.fieldses.org> 1137281075 -0500
> committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1137281075 -0500
>
> minor copyediting of recent additions to git-commit and git-reset ...
If this is intended to be a beginner documentation, I'd prefer
if it did not talk about cat-file, nor how commit objects are
internally represented.
> Note that by default git pull does not fetch new tags; use
>
> -------------------------------------
> $ git-fetch --tags
> -------------------------------------
>
> to get all of the tags from a repository.
These days by default "git fetch" (and "git pull") fetches the
tags that refer to the commits you fetch as part of regular
updates, so this part is mostly redundant. It still is useful
to slurp tags that do not belong to the commit chain you are
following.
> You can revisit the old state of a tree, and make further modifications
> if you wish, using git branch:
>
> -------------------------------------
> $ git branch stable-release 67ad31933f09677d
> -------------------------------------
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, but of
course that would not hold true forever. 16 is way overkill and
an eyesore.
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...
BTW^2, it might be interesting to do
$ git format-patch -C origin..master
the next time around.
[Footnote]
*1* If we taught the index file how to record "intent to add"
(or, "keep an eye on this path for me"), we could fix the
implementation of reset --mixed to take advantage of it.
^ permalink raw reply
* Re: [PATCH] cg-seek should not complain if run twice
From: Petr Baudis @ 2006-01-15 23:59 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060115010335.dj4swocs000k008o@webmail.spamcop.net>
Hello,
Dear diary, on Sun, Jan 15, 2006 at 07:03:35AM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> Quoting Petr Baudis <pasky@suse.cz>:
>
> > It seems cleaner to just make cg-seek fail with a sensible error message
> > if it's already unseeked.
>
> I don't like this. What if "cvs up -A" would fail if run twice? What if
> cg-clean would fail if there was nothing to clean? What if sync would fail if
> it didn't cause a single disk write? Idempotent operations are easier to work
> with. Please see http://en.wikipedia.org/wiki/Idempotent_(software)
>
> I could make an exception for the case when the command invocation indicates
> that the user is unaware of something, and that it would endanger the user's
> data. But it's not the case for cg-seek without arguments on non-seeked
> repository. The intention is clear, and the knowledge of the current state of
> the repository doesn't matter, since there will be no merge or something.
I have my reservations to this argumentation in the specific cg-seek
case, but it's very subjective, unclear, and I personally really don't
care. So let it be your way. ;-)
Thanks for your opinion,
--
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
* 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
* 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
* [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: [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
* 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: 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
* 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: [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
* 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
* [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: 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
* 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: [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: 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: [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: [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: 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: 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: 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: 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: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: 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
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