* Re: impure renames / history tracking
From: Paul Jakma @ 2006-03-01 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git list
In-Reply-To: <7v3bi2ey63.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
On Wed, 1 Mar 2006, Junio C Hamano wrote:
> Interestingly enough, there are two levels of "rename tracking" the
> current git does. Whey you run "git whatchanged -M", you are
> looking at renames between each commit in the commit chain, one
> step at a time. There as long as the rename+rewrite does not
> amount to too much rewrite, you would see what should be detected
> as rename to be detected as renames.
Right.
> I found the current default threshold parameters to be about right,
> maybe a bit too tight sometimes, though. If you want to loosen the
> default, you can specify similiarity index after -M.
That's one option.
I'm wondering though if we couldn't also allow for users to
additionally encode naming 'hints', to aid this 'similarity'
detection process.
> The way recursive merge strategy uses the rename detection, unlike
> what whatchanged shows you, does not use chains of commits down to
> the common merge base in order to detect renames (my recollection
> may be wrong here -- it's a while since I looked at the recursive
> merge the last time). It just looks at the two heads being merged,
> and detects similarility between them. So it does not make _any_
> difference with the current implementation of recursive merge if
> you kept a history full of "honest but disgusting" commits or
> collapsed them into a history with small number of "cleaned up"
> commits.
I'm going to have to stare at this paragraph a lot longer and harder
to understand it :).
> One thing it _could_ do (and you _could_ implement as another merge
> strategy and call it "pauls-rename" merge) is to follow the commit
> chain one by one down to the common merge base from both heads
> being merged, and analyze rename history on the both commit chains.
Right, I was just thinking that while making tea actually. This could
be part of the 'collapsing' process. (or call it "coalesce
too-detailed commits" process if that is less offensive to ones sense
of process ;) ).
Actually, you're sort of suggesting following the chains in parallel,
right? Ie in wall-clock time order, rather than chain order. And
doing name resolution across the 'to-be-merged' chains at each step
of the way? Sort of a lesser subset of how other SCMs maintain state
for names globally?
It's not so much /resolving/ names I'm worried about in the first
place. It's there simply being no information in the first place to
indicate (from one single-parent commit to the next) which names were
renamed.
> Then, you would get better rename+rewrite detection than what it
> currently does.
But if I follow the commit chain in order to try extract
> HOWEVER.
> If you have that kind of rename-following merge, a workflow that
> collapses a useful history into a single huge commit "Ok, this
> commit is a roll-up patch between version 2.6.14 and 2.6.15"
> becomes far less attractive than it currently already is. At that
> point, you _are_ throwing away useful history.
Yes, I agree. And I am, as part of arguing git's case (several SCMs
are being evaluated and considered, I'm the git proponent at the
moment), I'm going to suggest workflow ought to be re-evaluated to
ensure it is generally reasonable, rather than be kept for the sake
of it keeping (particularly as it may be tailored to the
needs/limitations of $TRADITIONAL_SCM).
However, I suspect at least some level of collapsing will be desired
(just as it is with Linux and git).
The workflow issue is seperate from the 'impure rename' issue though,
even if the workflow I gave as an example excerbates the issue,
"rename and rewrite half of it" and hard-to-detect renames can still
occur in the detailed git/linux workflows, surely?
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
If you really knew C++, you wouldn't even joke about putting it
in the kernel.
- Richard Johnson on linux-kernel
^ permalink raw reply
* Re: What's in git.git
From: Nicolas Pitre @ 2006-03-01 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgagxox.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Mar 2006, Junio C Hamano wrote:
> These are waiting for further progress by authors:
>
> - delta packer updates for tighter packs (Nicolas Pitre)
Please don't wait to merge the first two patches to diff-delta.c. They
are purely cleanups with no functional differences.
Nicolas
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Linus Torvalds @ 2006-03-01 21:28 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Andreas Ericsson, Eric Wong, Martin Langhoff, git
In-Reply-To: <200603012126.30797.Josef.Weidendorfer@gmx.de>
On Wed, 1 Mar 2006, Josef Weidendorfer wrote:
>
> So the get_sha1() magic should map "origin" to "remote/origin/master" (or instead
> hardcoded master the remote branch from the first "Pull:" line) ?
Right.
> The ambiguity here would be that shortcut names of remote repositories should not be
> used as tag or head names...
Well, it's not so much an ambiguity, since we'd always try tags and heads
first. So it's just a fallback, the same way the short SHA1 hash is a
fallback.
> I think a big plus of this would be that gitk can show branches tracking remote ones
> with another color.
Yes. And with a meaningful name.
> To be able to say "git log origin.." you need the above magic, too.
It would all come automagically from just extending get_sha1().
(Actually, technically you'd put it at the end of "get_sha1_basic()")
Linus
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Martin Langhoff @ 2006-03-01 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andreas Ericsson, Eric Wong, git
In-Reply-To: <7virqyf094.fsf@assigned-by-dhcp.cox.net>
On 3/2/06, Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > But if somebody does the get_sha1() magic, and Junio agrees, then I think
> > it would be a great thing to do.
>
> I am inclined to agree here.
Aren't we doing a lot of work (changes in core git, and corresponding
changes in the porcelain) when simple changes in porcelain would
suffice? Let's imagine that
- git-commit refuses to commit to a head that has a corresponding
remote (cg-commit does this already with heads that match something in
'branches')
- git-$SCMimport scripts generate a semi-bogus remotes/headname entry
- git-pull/push can spot and ignore the semi-bogus remotes/headname entry
- this means that `touch remotes/foo` is now a cheap way of making
the head readonly
- depending on the git-$SCMimport script, the remotes/headname file
can perhaps contain useful configuration data for the import, so
git-$SCMimport headname does the right thing.
cheers,
martin
^ permalink raw reply
* git doesn't like big files when pushing
From: Greg KH @ 2006-03-01 22:08 UTC (permalink / raw)
To: git
I have a mail archive stored with git, in mbox form, and I made some
changes to a few of the files and checked them back in.
That worked fine, but when I went to push the stuff to my server, I got
the following errors:
$ git push origin
updating 'refs/heads/master'
from 490badd9bec9ada3a21be275c97fb2a3a390f49e
to 16be8985abc8a9c89ad2cc8f46a0d8e9786e832f
Generating pack...
Done counting 8 objects.
Deltifying 8 objects.
fatal: Out of memory, malloc failed
fatal: early EOF
unpack unpacker exited with error code
ng refs/heads/master n/a (unpacker error)
And here are the file sizes of the files that were changed:
$ ls -lh linux-usb-devel.save.200*
-rw-r--r-- 1 greg users 41M Jan 6 14:30 linux-usb-devel.save.2001
-rw-r--r-- 1 greg users 80M Jan 6 14:30 linux-usb-devel.save.2002
-rw-r--r-- 1 greg users 74M Jan 6 14:30 linux-usb-devel.save.2003
-rw-r--r-- 1 greg users 99M Jan 6 14:30 linux-usb-devel.save.2004
-rw-r--r-- 1 greg users 89M Jan 6 14:30 linux-usb-devel.save.2005
So, am I just foolish for trying to use git for this? Should I just go
back to using rsync to back stuff like this up with?
thanks,
greg k-h
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Greg KH @ 2006-03-01 22:08 UTC (permalink / raw)
To: git
In-Reply-To: <20060301220802.GA18250@kroah.com>
On Wed, Mar 01, 2006 at 02:08:02PM -0800, Greg KH wrote:
> I have a mail archive stored with git, in mbox form, and I made some
> changes to a few of the files and checked them back in.
>
> That worked fine, but when I went to push the stuff to my server, I got
> the following errors:
>
> $ git push origin
> updating 'refs/heads/master'
> from 490badd9bec9ada3a21be275c97fb2a3a390f49e
> to 16be8985abc8a9c89ad2cc8f46a0d8e9786e832f
> Generating pack...
> Done counting 8 objects.
> Deltifying 8 objects.
> fatal: Out of memory, malloc failed
> fatal: early EOF
> unpack unpacker exited with error code
> ng refs/heads/master n/a (unpacker error)
Oh, and I'm using:
$ git --version
git version 1.2.3.g8c2f
if that helps or not.
thanks,
greg k-h
^ permalink raw reply
* Re: impure renames / history tracking
From: Andreas Ericsson @ 2006-03-01 22:12 UTC (permalink / raw)
To: Paul Jakma; +Cc: Junio C Hamano, git list
In-Reply-To: <Pine.LNX.4.64.0603012105230.13612@sheen.jakma.org>
Just to cap off my own engagement in this discussion, here's the last
time rename detection was seriously discussed on the list:
http://www.gelato.unsw.edu.au/archives/git/0504/0147.html
If you're going to implement something you might benefit from the
suggestions made there.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Greg KH @ 2006-03-01 22:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060301220840.GB18250@kroah.com>
On Wed, Mar 01, 2006 at 02:08:40PM -0800, Greg KH wrote:
> On Wed, Mar 01, 2006 at 02:08:02PM -0800, Greg KH wrote:
> > I have a mail archive stored with git, in mbox form, and I made some
> > changes to a few of the files and checked them back in.
> >
> > That worked fine, but when I went to push the stuff to my server, I got
> > the following errors:
> >
> > $ git push origin
> > updating 'refs/heads/master'
> > from 490badd9bec9ada3a21be275c97fb2a3a390f49e
> > to 16be8985abc8a9c89ad2cc8f46a0d8e9786e832f
> > Generating pack...
> > Done counting 8 objects.
> > Deltifying 8 objects.
> > fatal: Out of memory, malloc failed
> > fatal: early EOF
> > unpack unpacker exited with error code
> > ng refs/heads/master n/a (unpacker error)
>
> Oh, and I'm using:
> $ git --version
> git version 1.2.3.g8c2f
Hm, 1.2.4.g6177 seems better, it's still trying to pack things, after
about 10 minutes, but at least it isn't dying yet. I'll let you know if
it finishes properly or not...
thanks,
greg k-h
^ permalink raw reply
* Re: impure renames / history tracking
From: Paul Jakma @ 2006-03-01 22:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git list
In-Reply-To: <44061C59.20204@op5.se>
On Wed, 1 Mar 2006, Andreas Ericsson wrote:
> http://www.gelato.unsw.edu.au/archives/git/0504/0147.html
In terms of format, that's pretty much exactly what I was thinking,
except it's been vetoed.
> If you're going to implement something you might benefit from the
> suggestions made there.
Cheers.
Is there a correct way to extend the git header? To add meta-data
that normal git porcelain won't display? (there doesn't appear to
be..)
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Zombie processes haunting the computer
^ permalink raw reply
* Re: impure renames / history tracking
From: Junio C Hamano @ 2006-03-01 22:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Paul Jakma, git list
In-Reply-To: <44061C59.20204@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Just to cap off my own engagement in this discussion, here's the last
> time rename detection was seriously discussed on the list:
>
> http://www.gelato.unsw.edu.au/archives/git/0504/0147.html
>
> If you're going to implement something you might benefit from the
> suggestions made there.
Also, today's #git log has some interesting material.
http://colabti.de/irclogger/irclogger_logs/git
For anybody who wants to discuss rename recording (not
tracking), the following is a must-read:
http://article.gmane.org/gmane.comp.version-control.git/217
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-01 22:51 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603011625250.29834@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 1 Mar 2006, Junio C Hamano wrote:
>
>> These are waiting for further progress by authors:
>>
>> - delta packer updates for tighter packs (Nicolas Pitre)
>
> Please don't wait to merge the first two patches to diff-delta.c. They
> are purely cleanups with no functional differences.
I presume you mean these three?
commit 8e1454b5ad285ec5dd25758e799c589045aff9d4
Author: Nicolas Pitre <nico@cam.org>
diff-delta: big code simplification
commit fe474b588b3cb1c23c987a3d0f9e869a160d82d2
Author: Nicolas Pitre <nico@cam.org>
diff-delta: fold two special tests into one plus cleanups
commit cac251d0bc4c68b7ab36026990aff3c783913ae6
Author: Nicolas Pitre <nico@cam.org>
relax delta selection filtering in pack-objects
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Linus Torvalds @ 2006-03-01 23:00 UTC (permalink / raw)
To: Greg KH; +Cc: git
In-Reply-To: <20060301220802.GA18250@kroah.com>
On Wed, 1 Mar 2006, Greg KH wrote:
>
> That worked fine, but when I went to push the stuff to my server, I got
> the following errors:
>
> $ git push origin
> updating 'refs/heads/master'
> from 490badd9bec9ada3a21be275c97fb2a3a390f49e
> to 16be8985abc8a9c89ad2cc8f46a0d8e9786e832f
> Generating pack...
> Done counting 8 objects.
> Deltifying 8 objects.
> fatal: Out of memory, malloc failed
> fatal: early EOF
Gaah. We probably have a memory leak somewhere, and it just normally
doesn't much matter.
Git does want to keep the "window" of the objects it packs in memory while
packing (it would be really costly to read them in one at a time, over and
over again), but it should hopefully not really not need tons more memory
than that. Since the window is normally 10, and you only have 8 objects,
it really wants to have all eight in memory, but it shouldn't need a whole
lot more.
But maybe it's really the case that you can't fit those 8 objects in
memory. One option (which might also solve some of the performance issues)
is to make the window be based on object _size_ rather than just be a
fixed number (ie with an 80MB object, you'd only try a couple of objects
around it, not the full window).
Linus
^ permalink raw reply
* Re: What's in git.git
From: Luck, Tony @ 2006-03-01 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgagxox.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 01, 2006 at 04:24:14AM -0800, Junio C Hamano wrote:
> * The 'master' branch has these since the last announcement.
> - compilation warning fixes (Timo Hirvonen, Tony Luck, Andreas Ericsson)
In commit 8fcf1ad9c68e15d881194c8544e7c11d33529c2b you put in a
combination of my double cast and Andreas' switch to using
unsigned long ... just the latter is sufficient (and a lot less
ugly than using the double cast).
Signed-off-by: Tony Luck <tony.luck@intel.com>
--
diff --git a/pack-objects.c b/pack-objects.c
index 21ee572..136a7f5 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -99,7 +99,7 @@ static int reused_delta = 0;
static int pack_revindex_ix(struct packed_git *p)
{
- unsigned long ui = (unsigned long)(long)p;
+ unsigned long ui = (unsigned long)p;
int i;
ui = ui ^ (ui >> 16); /* defeat structure alignment */
^ permalink raw reply related
* Re: git doesn't like big files when pushing
From: Junio C Hamano @ 2006-03-01 23:03 UTC (permalink / raw)
To: Greg KH; +Cc: git, Nicolas Pitre
In-Reply-To: <20060301220840.GB18250@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Wed, Mar 01, 2006 at 02:08:02PM -0800, Greg KH wrote:
>> I have a mail archive stored with git, in mbox form, and I made some
>> changes to a few of the files and checked them back in.
>...
Ouch. Running out of memory while deltifying sounds really bad.
> Oh, and I'm using:
> $ git --version
> git version 1.2.3.g8c2f
>
> if that helps or not.
It doen't, since I do not have 8c2fXXXX commit ;-).
I suspect "git push --thin origin" might help, if you are on my
"master" branch:
diff-tree a79a276... (from 2245be3...)
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Feb 20 00:09:41 2006 -0800
Add git-push --thin.
Maybe we would want to make this default before it graduates to
the master branch, but in the meantime to help testing things,
this allows you to say "git push --thin destination".
Signed-off-by: Junio C Hamano <junkio@cox.net>
:100755 100755 706db99... 73dcf06... M git-push.sh
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Carl Worth @ 2006-03-01 23:23 UTC (permalink / raw)
To: Martin Langhoff
Cc: Junio C Hamano, Linus Torvalds, Andreas Ericsson, Eric Wong, git
In-Reply-To: <46a038f90603011340k23327f11s6e3d9d69585a5188@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
On Thu, 2 Mar 2006 10:40:41 +1300, "Martin Langhoff" wrote:
>
> Aren't we doing a lot of work (changes in core git, and corresponding
> changes in the porcelain) when simple changes in porcelain would
> suffice? Let's imagine that
There might be a simpler change to solve the git-svn-HEAD issue. But I
was about to independently bring up the issue that I wanted to hide
away the "remote-tracking" branches.
I currently get a lot of noise in "git branch" output that are
remote-tracking branches that I will never commit to. (I use a -origin
suffix to help me filter them out, but I'd prefer not to see them at
all here.)
Meanwhile, as I've been teaching new git users, I've had to carefully
teach:
1) Never commit to a branch name that appears on the right side of ':'
in a Pull: refspec.
2) BTW, that ':' might be only implicit. A refspec of "branch" is
equivalent to "branch:branch" so don't commit to those either.
That's pretty painful, so I really think these remote-tracking refs
belong outside of refs/heads.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Greg KH @ 2006-03-01 23:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <7v8xrtepje.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 01, 2006 at 03:03:17PM -0800, Junio C Hamano wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Wed, Mar 01, 2006 at 02:08:02PM -0800, Greg KH wrote:
> >> I have a mail archive stored with git, in mbox form, and I made some
> >> changes to a few of the files and checked them back in.
> >...
>
> Ouch. Running out of memory while deltifying sounds really bad.
>
> > Oh, and I'm using:
> > $ git --version
> > git version 1.2.3.g8c2f
> >
> > if that helps or not.
>
> It doen't, since I do not have 8c2fXXXX commit ;-).
Heh, that's a merge on my tree, sorry. My tree only has one change to
the git-format-patch.sh script.
858cbfbabe4ede5f5eba32041eb7448319e53e2a is the most recent commit from
your tree.
> I suspect "git push --thin origin" might help, if you are on my
> "master" branch:
>
> diff-tree a79a276... (from 2245be3...)
> Author: Junio C Hamano <junkio@cox.net>
> Date: Mon Feb 20 00:09:41 2006 -0800
>
> Add git-push --thin.
>
> Maybe we would want to make this default before it graduates to
> the master branch, but in the meantime to help testing things,
> this allows you to say "git push --thin destination".
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Will try that. I eventually gave up on the last push when it ran for 45
minutes at full cpu usage, and X got killed by the OOM killer in the
kernel for some reason...
thanks,
greg k-h
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Greg KH @ 2006-03-01 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <20060301232719.GA22068@kroah.com>
On Wed, Mar 01, 2006 at 03:27:19PM -0800, Greg KH wrote:
> On Wed, Mar 01, 2006 at 03:03:17PM -0800, Junio C Hamano wrote:
> > I suspect "git push --thin origin" might help, if you are on my
> > "master" branch:
> >
> > diff-tree a79a276... (from 2245be3...)
> > Author: Junio C Hamano <junkio@cox.net>
> > Date: Mon Feb 20 00:09:41 2006 -0800
> >
> > Add git-push --thin.
> >
> > Maybe we would want to make this default before it graduates to
> > the master branch, but in the meantime to help testing things,
> > this allows you to say "git push --thin destination".
> >
> > Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> Will try that. I eventually gave up on the last push when it ran for 45
> minutes at full cpu usage, and X got killed by the OOM killer in the
> kernel for some reason...
Nice, this worked!
Now what's the odds that when I pull from the server to another box
these same objects, the server will have the same problem as git-push
did?
will go try that now...
thanks,
greg k-h
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Linus Torvalds @ 2006-03-01 23:43 UTC (permalink / raw)
To: Carl Worth
Cc: Martin Langhoff, Junio C Hamano, Andreas Ericsson, Eric Wong, git
In-Reply-To: <87zmk9zr42.wl%cworth@cworth.org>
On Wed, 1 Mar 2006, Carl Worth wrote:
> Meanwhile, as I've been teaching new git users, I've had to carefully
> teach:
>
> 1) Never commit to a branch name that appears on the right side of ':'
> in a Pull: refspec.
>
> 2) BTW, that ':' might be only implicit. A refspec of "branch" is
> equivalent to "branch:branch" so don't commit to those either.
>
> That's pretty painful, so I really think these remote-tracking refs
> belong outside of refs/heads.
In the same vein, I think the refs/remotes/<remotename>/<branchname>
naming will make it possible for people who track multiple remotes to
sanely work with the fact that they might track 10 separate branches from
Jeff, one branch from me, and a couple of branches from Greg in the same
tree, without just going crazy.
I agree that we could solve the "don't touch that branch" issue another
way, by just making them read-only. But the reason I like the separate
namespace is that it just seems to organize the branches really well, and
in an unambiguous - and logical - manner.
I too find myself looking at "git branch" output, and a lot of it is stuff
I don't really care about - much of it is just the branches I got for just
tracking Junio's git repo.
Linus
^ permalink raw reply
* Problems with using git
From: Joseph Wakeling @ 2006-03-02 0:25 UTC (permalink / raw)
To: git
Hello all,
I'm a physics PhD student, not much experienced in serious software
writing, but I've got to the point where I felt learning to use a
version control system would be worthwhile. I decided to go for git
rather than CVS or Subversion because I felt a distributed VCS would
have more potential for future projects.
However, I've been experiencing some difficulties with using git, with
the results of commands not always being what the tutorial
<http://www.kernel.org/pub/software/scm/git/docs/tutorial.html> says it
should be. So, I'm hoping someone here can advise me!
I'm using openSUSE 10.0 and the package installed is git-core version
0.99.3git20050905-2.
The problem is to do with branches. Wanting to make some trial
revisions, I typed,
git branch trial
to create an appropriate branch. However, typing "git branch"
afterwards results in an error message: "git branch: I want a branch
name". No list of branches as the tutorial suggests!
However, I can use git checkout trial, make edits, and then go back to
git checkout master, and switch between the two, with the revisions in
one but not in the other. So the branches do seem to exist, and I can
modify them separately as one should be able to.
Now, having played around with the changes and found that they really
work very well, I'd like to merge the changes in the trial branch back
into the master. So, as per the tutorial, I type, git pull trial; and
am told, "No such remote branch: trial". I've also tried, git pull .
trial, which has the result, "No such remote branch: .".
I also note that when I'm in the master branch, having used git checkout
master, if I go into gitk, it does not show the existence of the trial
branch: but if I go into git checkout trial, it does. But the two
appear to be shown as completely separate entities.
Just as a test, I tried creating a throwaway branch,
git branch silly
which I then tried to delete with git branch -D silly. However, this
didn't delete the silly branch: it created a new one called -D (and both
of these *did* show up in gitk under the master branch). Using
git-branch instead of git branch results in an error message: "bash:
git-branch: command not found".
The result is that I'm kind of confused. I'd like to understand why the
commands I've tried from the tutorial haven't produced the results the
tutorial claims they will; but I'd also like to solve the original
problem: how just to merge the stuff in my trial branch back into the
master.
I suspect this might be simply that the SUSE package has some problems.
For example, it doesn't appear to have any man pages included. :-(
Thanks for any advice,
Best wishes,
-- Joe
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Greg KH @ 2006-03-02 0:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <20060301233506.GA25209@kroah.com>
On Wed, Mar 01, 2006 at 03:35:06PM -0800, Greg KH wrote:
> On Wed, Mar 01, 2006 at 03:27:19PM -0800, Greg KH wrote:
> > On Wed, Mar 01, 2006 at 03:03:17PM -0800, Junio C Hamano wrote:
> > > I suspect "git push --thin origin" might help, if you are on my
> > > "master" branch:
> > >
> > > diff-tree a79a276... (from 2245be3...)
> > > Author: Junio C Hamano <junkio@cox.net>
> > > Date: Mon Feb 20 00:09:41 2006 -0800
> > >
> > > Add git-push --thin.
> > >
> > > Maybe we would want to make this default before it graduates to
> > > the master branch, but in the meantime to help testing things,
> > > this allows you to say "git push --thin destination".
> > >
> > > Signed-off-by: Junio C Hamano <junkio@cox.net>
> >
> > Will try that. I eventually gave up on the last push when it ran for 45
> > minutes at full cpu usage, and X got killed by the OOM killer in the
> > kernel for some reason...
>
> Nice, this worked!
>
> Now what's the odds that when I pull from the server to another box
> these same objects, the server will have the same problem as git-push
> did?
Ok, no problem there either.
thanks for the pointer to that option.
greg k-h
^ permalink raw reply
* [PATCH] cvsserver: Checkout correctly on Eclipse
From: Martin Langhoff @ 2006-03-02 0:58 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
Initial checkouts were failing to create Entries files under Eclipse.
Eclipse was waiting for two non-standard directory-resets to prepare for a new
directory from the server.
This patch is tricky, because the same directory resets tend to confuse other
clients. It's taken a bit of fiddling to get the commandline cvs client and
Eclipse to get a good, clean checkout.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Heh! Using git-format-patch I make sure I don't send you stray spaces ;-)
(actually, I am back to using cperl-mode which highlights trailing ws)
I'll rewind/reset my 'cvsserver' branch so it's all clean and you can pull
from it and not fear white space monsters.
cheers,
martin
---
git-cvsserver.perl | 33 ++++++++++++++++++++++++++-------
1 files changed, 26 insertions(+), 7 deletions(-)
6a6ad59c4979e88e7f2a7b0997a3eb9fa115d6a7
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 3c588c9..d641c03 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -571,8 +571,19 @@ sub req_co
my $updater = GITCVS::updater->new($state->{CVSROOT}, $module, $log);
$updater->update();
+ $checkout_path =~ s|/$||; # get rid of trailing slashes
+
+ # Eclipse seems to need the Clear-sticky command
+ # to prepare the 'Entries' file for the new directory.
+ print "Clear-sticky $checkout_path/\n";
+ print $state->{CVSROOT} . "/$checkout_path/\n";
+ print "Clear-static-directory $checkout_path/\n";
+ print $state->{CVSROOT} . "/$checkout_path/\n";
+
# instruct the client that we're checking out to $checkout_path
- print "E cvs server: updating $checkout_path\n";
+ print "E cvs checkout: Updating $checkout_path\n";
+
+ my %seendirs = ();
foreach my $git ( @{$updater->gethead} )
{
@@ -585,16 +596,24 @@ sub req_co
print "Mod-time $git->{modified}\n";
# print some information to the client
- print "MT +updated\n";
- print "MT text U \n";
if ( defined ( $git->{dir} ) and $git->{dir} ne "./" )
{
- print "MT fname $checkout_path/$git->{dir}$git->{name}\n";
+ print "M U $checkout_path/$git->{dir}$git->{name}\n";
} else {
- print "MT fname $checkout_path/$git->{name}\n";
+ print "M U $checkout_path/$git->{name}\n";
}
- print "MT newline\n";
- print "MT -updated\n";
+
+ if (length($git->{dir}) && $git->{dir} ne './' && !exists($seendirs{$git->{dir}})) {
+
+ # Eclipse seems to need the Clear-sticky command
+ # to prepare the 'Entries' file for the new directory.
+ print "Clear-sticky $module/$git->{dir}\n";
+ print $state->{CVSROOT} . "/$module/$git->{dir}\n";
+ print "Clear-static-directory $module/$git->{dir}\n";
+ print $state->{CVSROOT} . "/$module/$git->{dir}\n";
+ print "E cvs checkout: Updating /$module/$git->{dir}\n";
+ $seendirs{$git->{dir}} = 1;
+ }
# instruct client we're sending a file to put in this path
print "Created $checkout_path/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "\n";
--
1.2.3.g67153
^ permalink raw reply related
* Re: git doesn't like big files when pushing
From: Martin Langhoff @ 2006-03-02 0:45 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git, Nicolas Pitre
In-Reply-To: <20060302003418.GA11119@kroah.com>
On 3/2/06, Greg KH <greg@kroah.com> wrote:
> Ok, no problem there either.
>
> thanks for the pointer to that option.
Now that it has been tested twice, it's about time it becomes the default ;-)
cheers,
martin
^ permalink raw reply
* Re: Problems with using git
From: Linus Torvalds @ 2006-03-02 0:52 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: git
In-Reply-To: <44063B7C.40609@webdrake.net>
On Thu, 2 Mar 2006, Joseph Wakeling wrote:
>
> I'm using openSUSE 10.0 and the package installed is git-core version
> 0.99.3git20050905-2.
I think your problems are just related to the fact that the tutorial is
newer than your git version.
Just fetch a newer version of git first (0.99.3 should be new enough to
happily fetch a newer version using git itself, but it might be easier to
just get a tar-ball), and you'll have an easier time at it.
Linus
^ permalink raw reply
* git-annotate dies when a patch is missing trailing newline
From: Martin Langhoff @ 2006-03-02 0:53 UTC (permalink / raw)
To: Git Mailing List, Ryan Anderson
Ryan, (& list)
git-annotate is dying when a patch is missing trailing newline. There
_are_ valid situations where code files are not expected to have
trailing newlines. Just thing of that glorious programming language,
PHP.
(Ducks).
Actually, 99% of my usage of git is tracking CVS projects so this is a
bit of a problem.
I had fixed it in Johannes version, but I'm lost as to where to fix it
in the current git-annotate. Help?
martin
^ permalink raw reply
* Re: Problems with using git
From: Andreas Ericsson @ 2006-03-02 1:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Joseph Wakeling, git
In-Reply-To: <Pine.LNX.4.64.0603011651240.22647@g5.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 2 Mar 2006, Joseph Wakeling wrote:
>
>>I'm using openSUSE 10.0 and the package installed is git-core version
>>0.99.3git20050905-2.
>
>
> I think your problems are just related to the fact that the tutorial is
> newer than your git version.
>
> Just fetch a newer version of git first (0.99.3 should be new enough to
> happily fetch a newer version using git itself, but it might be easier to
> just get a tar-ball), and you'll have an easier time at it.
>
... and the way to fetch and install that repo with your current git is:
$ git clone git://git.kernel.org/pub/scm/git/git.git git
$ cd git && make all strip install
There are 2215 commits since 0.99.3, so I think you'll find much has
changed since then.
--
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