* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Shawn Pearce @ 2006-11-15 22:16 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <455B90AD.3060707@freescale.com>
Timur Tabi <timur@freescale.com> wrote:
> After doing a "make mrproper" in my Linux git tree, the result is still
> 1.1GB of files. Compare that with just the tarball, which is just
> one-forth the size.
>
> Is there a way to "trim away" old commits from the repository, so that it
> just doesn't take up that much space? I don't care about any commits made
> in 2005. As long as I can still do "git pull" from the source repo to
> update mine, that's good enough.
No. However...
Have you tried "git repack -a -d" to repack the loose objects into
a pack file? Doing this every so often should reduce your disk
space consumed by a HUGE amount.
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-15 22:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20061115220054.GA24861@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
On Wed, 15 Nov 2006 17:00:54 -0500, Shawn Pearce wrote:
> > There is git-stash/git-unstash floating somewhere in the archive.
Yes, I did write those once upon a time. ;-)
It's the manual stash/unstash that I don't want though. I want to be
able to make this happen automatically when switching branches.
> I find that a "git commit -a -m parked; git checkout -b ..." works
> well to stash my current stuff off. Then I just amend the commit
> when I come back to that branch.
Yes, I do stuff like that as well. And often "reset HEAD~" instead of
amend, (always with a moment's pause as reset justly deserves).
> The problem I just ran into today was "git checkout" doesn't double
> check the file stat data against the index before switching branches.
> If the file is unchanged between the two branches there's no error.
> So I switched branches with dirty files that I forgot to park on
> the old branch.
Right, so that's just more evidence that this approach is a little
awkward.
Anyway, the stashing thing I want is a minor thing that should be easy
to fix in git, (as is everything we're talking about here I think).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Timur Tabi @ 2006-11-15 22:26 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061115221616.GD24861@spearce.org>
Shawn Pearce wrote:
> Have you tried "git repack -a -d" to repack the loose objects into
> a pack file? Doing this every so often should reduce your disk
> space consumed by a HUGE amount.
Woah! It shrunk that bad boy down to 420M! That should do it, thanks!
I wonder why the powerpc tree shrank so much. Do you think the maintainer
just needs to run git-repack on his tree?
--
Timur Tabi
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Sean @ 2006-11-15 22:28 UTC (permalink / raw)
To: Marko Macek
Cc: Shawn Pearce, Linus Torvalds, Junio C Hamano, git, cworth, pasky
In-Reply-To: <455B64F7.9040506@gmx.net>
On Wed, 15 Nov 2006 20:05:27 +0100
Marko Macek <marko.macek@gmx.net> wrote:
> I guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.
> (which is very confusing for someone coming to _git_ home page, trying to learn git).
IMHO this is really bad. Pasky runs the Git web site and feels
that Cogito comes hand in hand with Git. When I asked him about
it he mentioned that Junio had approved. But it's very confusing
to click a link that purports to show you how to use Git and get
shown a bunch of Cogito stuff.
Git is confusing enough for new users without "Git" and "Cogito"
being mixed without comment on the Git webpage. At the very
least, the links should be changed to "Cogito for CVS/SVN users".
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Shawn Pearce @ 2006-11-15 22:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <455B9411.4090708@freescale.com>
Timur Tabi <timur@freescale.com> wrote:
> Shawn Pearce wrote:
>
> >Have you tried "git repack -a -d" to repack the loose objects into
> >a pack file? Doing this every so often should reduce your disk
> >space consumed by a HUGE amount.
>
> Woah! It shrunk that bad boy down to 420M! That should do it, thanks!
>
> I wonder why the powerpc tree shrank so much. Do you think the maintainer
> just needs to run git-repack on his tree?
Possible, yes.
However published repositories don't tend to repack as often as
it makes things harder for people who clone/fetch over HTTP rather
than the native git protocol.
The reason is that HTTP can fetch individual loose objects that
you don't have yet, but if the object is only available in a pack
file then you need to fetch the entire pack file. But you might
already have most of that pack file, so now you are downloading
lots of data you already have. :-(
--
^ permalink raw reply
* Re: git-svn bug?
From: Seth Falcon @ 2006-11-15 22:33 UTC (permalink / raw)
To: git
In-Reply-To: <op.ti2svo0ozidtg1@rygel.lnxi.com>
"Troy Telford" <ttelford.groups@gmail.com> writes:
> I've got a repository I've converted over to git from svn. (using
> git-svn. since there's only been one branch, I figured I could skip
> git-svnimport).
>
> For quite a while, all I did was fetch/rebase from the svn repository
> to my git repository; all of my own work was committed to the git
> repository; none of the changes were commited to the svn repository.
>
> Then came the time to commit changes from my git repository to the svn
> repository.
>
> Being somewhat cautious, I created an empty 'dummy' svn repository and
> familiarize myself with using git-svn to commit from git -> svn.
>
> I ran:
> git-svn fetch
> git-svn rebase remotes/git-svn (already updated)
> git-svn dcommit (to push my changes to the svn repository)
I always send commits as:
git-svn dcommit remotes/git-svn..master
Possibly replacing master with whatever git branch I'm working on.
One nice thing about this approach is that you can sort of preview the
commit as:
git diff remotes/git-svn..master
[but that just shows overall diffs and git-svn dcommit will apply each
commit in master separately to svn]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-15 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vmz6sjtw8.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
On Wed, 15 Nov 2006 13:13:11 -0800, Junio C Hamano wrote:
> That is a very fine example, but I do not see why it is a
> problem. I do not think the goal of Porcelain is to make it
> totally unnecessary for users to know about the plumbing.
If not, then the promise of the porcelain fails. If cogito offers
"Here are 40 commands so you don't have to learn git's 140" and then
next says "Oh, and you'll still want to learn all those git commands
too", then its existence only makes the "too much stuff to learn"
problem worse, not better.
But I think you agree with me (for now) that fixing the git UI should
not involve creating a new primary command to replace "git".
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn bug?
From: Shawn Pearce @ 2006-11-15 22:37 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2psbocpbo.fsf@ziti.local>
Seth Falcon <sethfalcon@gmail.com> wrote:
> I always send commits as:
>
> git-svn dcommit remotes/git-svn..master
>
> Possibly replacing master with whatever git branch I'm working on.
Or just:
git-svn dcommit remotes/git-svn..
to send the current branch.
> One nice thing about this approach is that you can sort of preview the
> commit as:
>
> git diff remotes/git-svn..master
Or see the log and patch of each commit on the current branch:
git log -p remotes/git-svn..
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-15 22:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151339500.3349@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]
On Wed, 15 Nov 2006 13:45:58 -0800 (PST), Linus Torvalds wrote:
> On Wed, 15 Nov 2006, Carl Worth wrote:
> >
> > Well, one of the problems is that with current git I can teach, (and I
> > have), that there's a conceptual:
> >
> > pull = fetch + merge
> >
> > But then shortly after I have to teach an interface notion:
> >
> > merge = pull .
>
> This is why I would suggest teaching the _concept_ of the "merge", and not
> the actual command.
>
> I don't think you should basically ever use the "git merge" command
> itself, not in teaching, and not in real life.
I think that's just and accident of git-merge having such a bad
syntax, (requiring a merge message, not using -m for that, requiring
two heads instead of defaulting to current, etc.). So the result is
accepting another bad syntax "pull ." for an operation that really is
merge.
> Once you've explained the _concept_ of merging, you then introduce the
> command to actually _execute_ the merge: it's "git pull".
I think we'll be doing better when there is a stronger correlation
between the concepts of the operations and the command names for
carrying them out.
Plus, when I'm teaching "fetch everything first, then manipulate it
locally", (which is what I teach, since that's the only way I use
git), then the "." looks really out of place when I teach the 'merge'
command. I end up saying, "Oh, that's there because you could do the
fetch and merge all in one step if you really wanted, but I never do
that.".
And that's because I _do_ teach fetch first, as you've suggested.
> changes from both branches. So it's a _conceptual_ issue, and that's why I
> said I think you should just totally gloss over the whole issue of "git
> merge" syntax.
That doesn't work. I know I went looking at the git-merge
documentation when I started to learn git. "It can't really be this
hard, can it?" was my reaction to it. And then only after attending a
tutorial did I learn that "pull ." is the way it's really done.
That's nothing more than a user-interface trap for new users, plain
and simple.
The real fix is to stop glossing over git-merge and just give it a
usable syntax.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn bug?
From: Troy Telford @ 2006-11-15 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <7vejs4jshp.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Nov 2006 14:43:30 -0700, Junio C Hamano <junkio@cox.net> wrote:
> "Troy Telford" <ttelford.groups@gmail.com> writes:
>
>> (using git 1.4.4, svn 1.3.1 on a SLES 10 box)
>> fatal: Not a valid object name
>> 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
>> 32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
>> ...
>> I couldn't find an object named
>> "92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/
>
> Troy, do you have object 92e2e0c5? Is it a root commit (i.e. a
> commit that does not have a parent)?
I'll have to admit I'm stabbing in the dark on how to get the correct
answer this, but here goes:
* `git cat-file -t 92e2e0...` returns 'commit'
* 'git cat-file -p 92e2e0...` returns: (minus the header/footer asterisks)
*********************************************
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author unknown <unknown> 961088898 +0000
committer unknown <unknown> 961088898 +0000
New repository initialized by cvs2svn.
*********************************************
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-15 23:02 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <87psbos4pb.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> Plus, when I'm teaching "fetch everything first, then manipulate it
> locally", (which is what I teach, since that's the only way I use
> git), then the "." looks really out of place when I teach the 'merge'
> command. I end up saying, "Oh, that's there because you could do the
> fetch and merge all in one step if you really wanted, but I never do
> that.".
>
> And that's because I _do_ teach fetch first, as you've suggested.
Ditto. In every way.
I've taught the same fetch first, then merge strategy. Nobody I
know in meat-space pulls from a remote URL and merges in one shot;
they always fetch locally, look at the incoming changes, decide if
its worthwhile/ok, *then* merge with "git pull . branch".
The "." looks out of place for everyone...
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Sean @ 2006-11-15 23:07 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <87psbos4pb.wl%cworth@cworth.org>
On Wed, 15 Nov 2006 14:52:32 -0800
Carl Worth <cworth@cworth.org> wrote:
> The real fix is to stop glossing over git-merge and just give it a
> usable syntax.
Agreed 100% There's just no good reason to hide the user level
merge command inside of pull.
^ permalink raw reply
* Re: git-svn bug?
From: Troy Telford @ 2006-11-15 23:09 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <m2psbocpbo.fsf@ziti.local>
> I always send commits as:
>
> git-svn dcommit remotes/git-svn..master
>
> Possibly replacing master with whatever git branch I'm working on.
I get essentially the same error:
fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
> One nice thing about this approach is that you can sort of preview the
> commit as:
>
> git diff remotes/git-svn..master
>
> [but that just shows overall diffs and git-svn dcommit will apply each
> commit in master separately to svn]
Since I actually checked out a branch, I assume that
git diff remotes/git-svn..svn
should be empty, right?
And if that's the case `git diff svn..master` should be identical to `git
diff remotes/git-svn..svn`?
If I write the diff to a file, it is about 294k in size. Also worth
mentioning is that I'm also tracking binary files in the git repository as
well. It's for an RPM tree, so I have the (binary) package source
tarballs (in a few cases >100 MB tarball) and their corresponding (text)
patches and .spec files.
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-15 23:15 UTC (permalink / raw)
To: Sean; +Cc: Carl Worth, Linus Torvalds, Nicolas Pitre, Michael K. Edwards,
git
In-Reply-To: <20061115180722.83ff8990.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Wed, 15 Nov 2006 14:52:32 -0800
> Carl Worth <cworth@cworth.org> wrote:
>
> > The real fix is to stop glossing over git-merge and just give it a
> > usable syntax.
>
> Agreed 100% There's just no good reason to hide the user level
> merge command inside of pull.
So what about making git-merge take a -m "msg" argument to supply
the commit message, in which case it does the current behavior
(and thus git-pull needs to change to supply -m); and then make
git-merge without any -m parameter invoke "git pull . $@" ?
A minor tweak to both apps, a minor breakage to git-merge, but one
that I think anyone who invokes it by hand today would find sane
(using -m like we do elsewhere) and since the vintage of both
git-pull and git-merge should always match shouldn't break anyone
who uses git-pull today.
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-15 23:33 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Carl Worth, Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <20061115230252.GH24861@spearce.org>
On Wed, 15 Nov 2006, Shawn Pearce wrote:
>
> I've taught the same fetch first, then merge strategy. Nobody I
> know in meat-space pulls from a remote URL and merges in one shot;
Actually, with different people involved it's _much_ better to do it in
one shot.
Why? Because doing a separate "fetch to local space" + "merge from local
space" actually loses the information on what you are merging.
It's a lot more useful to have a merge message like
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
than one like
Merge branch 'for-linus'
which is what you get if you fetched it first.
Of course, in a situation like git itself, where most of the merges are
stuff that Junio has had pending in his own tree ('maint' branch etc),
things are different. But in a system where people actually use separate
trees, there really is an advantage to consider the fundamental operation
to be the "pull", not the "merge".
Again, the kernel really is more distributed than most projects, but this
is another thing people should recognize: git has been designed for "true
distributed development". Not the "fake" kind. Not the "I merge mainly my
own branches" kind of thing. Truly distributed.
And in a truly distributed situation, "pull" is strictly more powerful
than a separate "fetch" + separate "merge".
In other words, an SCM that does "pull" is _better_ than an SCM that does
"merge". You can implement "merge" as a special case of "pull" (which we
do), but you cannot conveniently do it the other way around without having
to tie them together some other way (ie you could have a "remember the
last place we fetched this branch from in order to tie the fetch and the
merge together" - but please realize that that is exactly what "pull"
_is_).
So I will generally do a "git pull" (possibly followed by a "git reset
--hard ORIG_HEAD" if I decided it wasn't good) over a "git fetch" + "git
merge". Exactly because the "pull" operation is actually more powerful.
Maybe people who aren't in my position don't always appreciate the _power_
of git. The reason "merge" is a second-class citizen is simply because IT
SHOULD BE.
^ permalink raw reply
* Re: how to authenticate with git-svn on a subversion repository
From: Sam Vilain @ 2006-11-15 23:39 UTC (permalink / raw)
To: Comète; +Cc: Git Mailing List
In-Reply-To: <4559D37E.1070703@archlinuxfr.org>
Comète wrote:
> hello !
>
> i would like to use git-svn to commit some modifications to a Subversion
> repository but i don't know where i can enter my username and password
> to commit to the repository ? Is there any special file to put them.
> For now i get an error:
>
> # git-svn commit remotes/git-svn
> Autorisation refusée: MKACTIVITY de
> '/svn/!svn/act/8115f5df-c0da-4a6d-91ef-135dcb76141c': Échec à
> l'autorisation (http://projet.archlinuxfr.org) at /usr/bin/git-svn line 553
> 512 at /usr/bin/git-svn line 574
> main::commit_lib('f45ba41060287fedfcedfb5fc4c29ecfe30a7466') called at
> /usr/bin/git-svn line 480
> main::commit('remotes/git-svn') called at /usr/bin/git-svn line 172
>
Two questions;
- have you tried this with Git 1.4.4? There have been some git-svn updates
- which version of the SVN Perl bindings are you using?
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-16 0:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151523290.3349@woody.osdl.org>
On Wed, 15 Nov 2006, Linus Torvalds wrote:
>
>
> On Wed, 15 Nov 2006, Shawn Pearce wrote:
> >
> > I've taught the same fetch first, then merge strategy. Nobody I
> > know in meat-space pulls from a remote URL and merges in one shot;
>
> Actually, with different people involved it's _much_ better to do it in
> one shot.
>
> Why? Because doing a separate "fetch to local space" + "merge from local
> space" actually loses the information on what you are merging.
>
> It's a lot more useful to have a merge message like
>
> Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
>
> than one like
>
> Merge branch 'for-linus'
That is an implementation detail that should be easily overcome once the
notion of tracking branch with URL attribute is implemented. Then it
will be really easy to notice whether the branch argument is a local
branch or a tracking branch with remote reference.
^ permalink raw reply
* Re: git tag: don't complain of empty messages
From: Han-Wen Nienhuys @ 2006-11-16 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64dgo9gj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> I do not have a strong objection against allowing tags without
> messages, but at the same time I do not see a compelling reason
> to allow them either. Care to explain what workflow is helped
> by an empty tag?
the tagname usually is enough of a description, but I want the tags to
end up in the object DB, eg.:
git tag release/2.10.0 HEAD
now I have to use
git tag -m "this really sucks" release/2.10.0 HEAD
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Han-Wen Nienhuys @ 2006-11-16 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqn8o9st.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> I still think in the long run you would be better off giving
> separate names to Porcelains because I am sure you are going to
> find the next command to "fix", you cannot suddenly change the
> "ig pull", you can dismiss all the broken git-x Porcelain-ish by
> saying "Oh, git-x user-level commands had inconsistent semantics
> and broken UI so do not use them anymore -- they are still there
> only to help old timers transition. The user level commands are
> now called ig-x and ig stands for improved git".
I think it would be good if there were different commands for
porcelains. Not because fixing the current commands is too much work,
but rather because it would clarify the structure of git. GIT is a
3-layer approach:
- index+workdir+refs over
- a DAG of commits over
- a file based SHA1 database
at first sight it is difficult to tell for each command on which layer
it operates. It would help understanding GIT a lot if each layer got
it's own command, eg.
git - sha1 content db
gic - sequences of commits
giu - UI
(Of course, these names are completely silly, but you get the idea)
> I think get/put is much better than suddenly changing what pull
> means and is shorter to type than x-load; I am Ok with them.
> Although I think these words are tainted by SCCS, I do not think
> anybody cares.
they're also tainted by darcs, but that's a minor problem, I suppose.
--
^ permalink raw reply
* Re: git tag: don't complain of empty messages
From: Jakub Narebski @ 2006-11-16 0:38 UTC (permalink / raw)
To: git
In-Reply-To: <455BAD80.1080108@xs4all.nl>
Han-Wen Nienhuys wrote:
> Junio C Hamano escreveu:
>> I do not have a strong objection against allowing tags without
>> messages, but at the same time I do not see a compelling reason
>> to allow them either. Care to explain what workflow is helped
>> by an empty tag?
>
> the tagname usually is enough of a description, but I want the tags to
> end up in the object DB, eg.:
>
> git tag release/2.10.0 HEAD
>
> now I have to use
>
> git tag -m "this really sucks" release/2.10.0 HEAD
Why not
git tag -m "release 2.10.0" release/2.10.0 HEAD
This way you would know what tag points to even if you loose it's
reference...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] qgit-1.5.3
From: Andreas Ericsson @ 2006-11-16 0:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List, linux-kernel
In-Reply-To: <e5bfff550611150723p691fc480m874cce9ad4d64476@mail.gmail.com>
Marco Costalba wrote:
> On 11/13/06, Andreas Ericsson <ae@op5.se> wrote:
>> Marco Costalba wrote:
>> >
>> > Download tarball from http://www.sourceforge.net/projects/qgit
>> > or directly from git public repository
>> > git://git.kernel.org/pub/scm/qgit/qgit.git
>> >
>>
>> Love the tool, but can't fetch the tag. Did you forget to
>>
>> $ git push origin 1.5.3
>>
>
> I think I have pushed the new tag, indeed the gitweb interface on
> kernel.org/git shows correctly the 1.5.3 tag (and also two new commits
> after that).
>
> I've also pulled from kernel.org/git/qgit in a test repository and got
> the tag succesfully.
>
> I'm not able to reproduce this, in any case I will push again the tags.
>
That's odd. Here's my .git/remotes/origin
---8<---8<---8<---
URL: git://git.kernel.org/pub/scm/qgit/qgit.git
Pull: master:origin
---8<---8<---8<---
I got the tag now, by doing
$ git fetch --tags
although that didn't work last time I fetched the objects (which was
after you had posted the announcement). Strange. This was with git
version 1.4.3.rc3.gb32db.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Question on multi-level git repository heiarchy.
From: Ben Greear @ 2006-11-16 0:43 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061027052517.GB29057@spearce.org>
Shawn Pearce wrote:
> Ben Greear <greearb@candelatech.com> wrote:
>> I want to create an intermediate level..something like:
>>
>> kernel.org git tree
>> |
>> my git master tree
>> / \
>> work-station-1 work-station-2 ....
>
>> I then did a git checkout -f master on the
>> pub server and did a pull from the upstream kernel.
>> This seemed to work fine.
>
> Ah, what you really want here is to make your "my git master tree"
> a bare repostiory and use fetch instead of pull. This way you
> don't need to maintain a working directory of files associated
> with that repository. So assuming you have "mygitmastertree"
> as the directory do:
>
> mv mygitmastertree/.git mygitmastertree.git
> rm -rf mygitmastertree
>
> and update your workstation .git/remotes/origin files such
> that the URL line reads ".../mygitmastertree.git" rather than
> ".../mygitmastertree/.git".
>
> Then to update "mygitmastertree" with recent changes you can use
> git fetch rather than git pull:
>
> git --git-dir mygitmastertree.git fetch
>
>> Then, on the work-station, I did a git checkout -f master, and also did
>> a pull.
>> In this case, it seems that it is trying to merge with changes in the
>> lf_v2.6.18 branch
>> instead of the the main 'master' tree (see below).
>
> When you use "git pull" with no additional arguments the first
> branch listed in a Pull: line of .git/remotes/origin will be the
> branch merged into the current branch. I don't know what that
> branch is listed as in your workstation tree but from what you
> described it sounds like it may be that lf_v2.6.18 branch, which
> is why its trying to merge it.
I have been using a variation of this with some success. (I didn't rename the .git directory
on the master tree, but the directory only contains a .git directory so I assume that
I'm using a bare tree....)
I have been able to do 'git pull origin' and 'git push origin master' to
sync and commit my lf_v2.6.18 branch from my work-station repositories (per this page's instructions:
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
Now, I would like to fetch down all of the changes from kernel.org to my master
tree and then update my work-station branches. On the master,
I ran 'git fetch'. It took a while and seemed to do the right thing.
There is still nothing other than .git in the directory, and subsequent
'git fetch' calls return quickly w/out doing anything.
However, I cannot find an incantation on the work-station machines to
pull down the changes and sync up with kernel.org.
I did a 'git fetch' on the work-station, but gitk still does not show anything
new in 'master' or 'lf_v2.6.18
I tried checking out master and running: git pull . master
but it said Already up-to-date.
I tried checking out the master branch on the work-station and doing a 'git pull' there.
It got a lot of conflicts from the changes that I had made in the lf_v2.6.18 branch.
I want to have some local branch contain only official kernel patches, and
then fork my own branches off to track my individual changes. My assumption
was that I could do something like:
git checkout master
git pull
and have master updated with (only) the latest tree from kernel.org and have
lf_v2.6.18 un-touched.
Any pointers are welcome.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] git-checkout: allow pathspec to recover lost working tree directory
From: Anand Kumria @ 2006-11-16 1:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqn8msuw.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Nov 2006 11:07:19 -0800, Junio C Hamano wrote:
> It is often wanted on the #git channel that this were to work to
> recover removed directory:
>
> rm -fr Documentation
> git checkout -- Documentation
> git checkout HEAD -- Documentation ;# alternatively
>
> Now it does.
One thing I often seem to do is make some changes, test them out and
remove the file if it wa a dead end and get my original back with
'cg-restore <file>'. Does this mean that the git equivalent will be 'git
checkout -- <file>' as well?
Thanks,
Anand
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Han-Wen Nienhuys @ 2006-11-16 1:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611150950170.3349@woody.osdl.org>
Linus Torvalds escreveu:
> - git itself has now done it that way for the last 18 months, and the
> fact is, the people _complaining_ are a small subset of the people who
> actually use git on a daily basis and don't complain.
that's not a good argument; the set of git users is a small subset of
those that looked at git, and dismissed it because they couldn't wrap
their heads around it. It's worth trying to get those on board by
fixing the annoying little issues that have popped up in this thread.
The technical base for GIT is excellent, and the only reason for not
using it is its arcane interface.
A version control system is often only tangentially related to the real
work that needs to be done, so the incentive to learn it well is small,
and a steep learning curve only makes it worse.
FWIW, I regularly mess up with the differences between fetching, pulling
and merging. In particular, having to do a two step process to get
remote changes in,
git pull url-to-server master:master
..error message about not being a fast-forward..
git pull --update-head-ok url-to-server master:master
..still an error message about update not being a fast-forward..
(sigh)
git pull url-to-server master:scrap-branch
git pull . scrap-branch:my-current-branch
(make mental note of deleting scrap-branch)
--
^ permalink raw reply
* Re: git tag: don't complain of empty messages
From: Han-Wen Nienhuys @ 2006-11-16 1:27 UTC (permalink / raw)
To: git
In-Reply-To: <ejgbrq$o5u$1@sea.gmane.org>
Jakub Narebski escreveu:
> Han-Wen Nienhuys wrote:
>
>> Junio C Hamano escreveu:
>>> I do not have a strong objection against allowing tags without
>>> messages, but at the same time I do not see a compelling reason
>>> to allow them either. Care to explain what workflow is helped
>>> by an empty tag?
>> the tagname usually is enough of a description, but I want the tags to
>> end up in the object DB, eg.:
>>
>> git tag release/2.10.0 HEAD
>>
>> now I have to use
>>
>> git tag -m "this really sucks" release/2.10.0 HEAD
>
> Why not
>
> git tag -m "release 2.10.0" release/2.10.0 HEAD
>
> This way you would know what tag points to even if you loose it's
> reference...
that would double, given that the tag name is already in the tag object.
Currently, I have
**
[lilydev@haring gub]$ cat .git/refs/tags/gubrelease-2.9.29-2
1ac5c78609a9f79787825b62c9576542eedce795
[lilydev@haring gub]$ git cat-file tag
1ac5c78609a9f79787825b62c9576542eedce795
object b75db784e3d6a9e1d2cff3f77036aaa88598b53c
type commit
tag gub-2.9.29-2
tagger Han-Wen Nienhuys <lilydev@haring.localdomain> 1162921716 +0100
build and upload
**
'build and upload' is a polite way of saying 'this really sucks'.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ 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