* 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: 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: 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: 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: 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: 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: 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: 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: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
* 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-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
* 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: 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: 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: [PATCH 1/2] Let git-svnimport's author file use same syntax as git-cvsimport's
From: Jon Loeliger @ 2006-03-01 21:19 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20060227230814.12298.63006.stgit@backpacker.hemma.treskal.com>
On Mon, 2006-02-27 at 17:08, Karl Hasselström wrote:
> diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
> index e0e3a5d..912a808 100644
> --- a/Documentation/git-svnimport.txt
> +++ b/Documentation/git-svnimport.txt
> @@ -75,9 +75,9 @@ When importing incrementally, you might
> -A <author_file>::
> Read a file with lines on the form
>
> - username User's Full Name <email@addres.org>
> + username = User's Full Name <email@addr.es>
>
> - and use "User's Full Name <email@addres.org>" as the GIT
> + and use "User's Full Name <email@addr.es>" as the GIT
> author and committer for Subversion commits made by
> "username". If encountering a commit made by a user not in the
> list, abort.
Actually, I believe that "example.com" was reserved
specifically for instances such as this.
See:
http://www.faqs.org/rfcs/rfc2606.html
jdl
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Johannes Schindelin @ 2006-03-01 21:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, Eric Wong, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0603010821590.22647@g5.osdl.org>
Hi,
On Wed, 1 Mar 2006, Linus Torvalds wrote:
> On Wed, 1 Mar 2006, Andreas Ericsson wrote:
> >
> > Personally I'm all for namespace separation. I'm assuming the script
> > has the tracker-branch hardcoded anyway, so I don't really understand
> > why it would be necessary to keep other refs in a separate directory
> > and, if it *is* necessary, why that subdirectory can't be
> > .git/refs/heads/svn.
> >
> > Eric mentioned earlier that the tracking-branch can't be committed to
> > (ever), so the user convenience for searching other directories should
> > be nearly non-existant.
>
> The thing about it being .git/refs/heads/svn/xyzzy is that then you can
> do
>
> git checkout svn/xyzzy
>
> _not_ a branch and you must _not_ commit to it.
>
> It's much more like a tag: it's a pointer to the last point of an
> svn-import.
>
> So I think it should either _be_ a tag (although Dscho worries about some
> broken porcelain being confused by tags changing) or it should be in a
> namespace all it's own. Not under .git/refs/heads/ at any point, because
> it is _not_ a head of development.
I almost missed that you reference me in the email (often, I just delete
the email if the Subject is of no interest to me).
I did not worry about broken porcelain. I saw broken porcelain. But that
is more a broken concept than broken porcelain: in a distributed
environment, there is no way to have a reliable tag. Think about it:
whenever you have two different versions of a tag, you cannot know which
one is the correct one.
But my worries do not matter at all for local tags.
Conceptually, however, the last point of a svnimport should *never* be a
tag, but *always* a head.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Josef Weidendorfer @ 2006-03-01 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virqyf094.fsf@assigned-by-dhcp.cox.net>
On Wednesday 01 March 2006 20:11, Junio C Hamano wrote:
> The latter at first sounds sane, but it has a subtle issue,
> which was what bitten me previously between heads/ and tags/.
> In that broken version, if you have a head called "dead" and a
> tag with the same name, neither was taken ("they are not unique,
> so do not take either!") and we ended up finding an object whose
> SHA1 name began with those two bytes 0xDE 0xAD. I do not think
> this has happened in the field, fortunately, but it would have
> been quite hard to diagnose.
>
> So if we were to do it, I would say do the latter, but be very
> careful to make sure you fail the whole get_sha1() when you bail
> out of the "try possible prefixes" codepath because of
> ambiguity.
Yes.
Any ambiguity is a source of confusion and user error. Better
bail out. If it is not a performance problem, it would be better
to integrate the check for abbreviated object name into the
ambiguity analysis, and not have 2 stages of searching.
It probably would be a good idea to print out the ambigous names
with the error message, so that you can copy&paste the correct
full name afterwards.
If we go for the .git/refs/remotes/... and have an ambiguity becaues
of remote shortcut names, a error message pointing at a "git-rename-remote"
command would be handy, allowing the user to cleanup the namespace.
> There may be other issues involved, but I wouldn't
> know -- I reverted the "do not take either if they are
> ambiguous between heads/ and tags/" patch primarily because of
> the reason from the above paragraph, but also did not want to
> deal with any other potential issues to keep my sanity ;-).
I think the real problem here is that names like "dead" can be interpreted
as abbreviated object name. When you introduce such a name as head or tag,
you have a potential ambiguity which can get real at any time.
Perhaps it would be good to print out a warning when the user is about to
create a head or tag name which can be interpreted as abbreviated object name?
Josef
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Josef Weidendorfer @ 2006-03-01 20:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, Eric Wong, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0603011023080.22647@g5.osdl.org>
On Wednesday 01 March 2006 19:25, Linus Torvalds wrote:
> > git log origin/master..
> >
> > is really not that bad
>
> It really is.
>
> Think like a user. If I pull from "origin", then the name of that thing is
> "origin", not "origin/master" or "o/master". A user doesn't care what the
> remote branch name is - the whole _point_ of the .git/remotes/xyzzy file
> is to give a short description that includes the names of the branches you
> pull from.
So the get_sha1() magic should map "origin" to "remote/origin/master" (or instead
hardcoded master the remote branch from the first "Pull:" line) ?
The ambiguity here would be that shortcut names of remote repositories should not be
used as tag or head names...
I think a big plus of this would be that gitk can show branches tracking remote ones
with another color.
> The good news is that "get_sha1()" shouldn't be thse at hard to extend on.
> Just add a case at the end that says "do we have a .git/remotes/%s file,
> and if so, parse it".
To be able to say "git log origin.." you need the above magic, too.
Josef
^ permalink raw reply
* Re: [PATCH 2/2] git-log (internal): more options.
From: Junio C Hamano @ 2006-03-01 20:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603010730520.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Most helpers that want a list of commits probably want the printing
> options too, and the ones that do not probably simply don't care (ie if
> they silently pass a "--pretty=raw" without it affecting anything, who
> really cares?)
Perhaps (meaning, agree in general but not 100% convinced and
haven't made up my mind yet).
> I can actually imagine using "--parents" as a way of parsing both the
> commit log and the history. Of course, any such use is likely in a script,
> at which point the script probably doesn't actually want "git log", but
> just a raw "git-rev-list".
Yes, that is exactly why I did not see why "log viewer" wants --parents.
> To me, the question whether a flag would be parsed in the "revision.c"
> library or in the "rev-list.c" binary was more a question of whether that
> flag makes sense for other things than just "git log".
Good to know we are in agreement (iow, I wasn't totally off the
mark) that revision.c should handle things that are common.
That means:
* --bisect and --parents are for scripted use only and do not
concern log viewer, so we would leave them in rev-list.
* --header is good for anything that shows more than one
record, so it may be worthwhile to have it in generic.
> For example, "git whatchanged" and "git diff" could both use
> setup_revision(), although "git diff" wouldn't actually _walk_ the
> revisions (it would just look at the "revs->commits" list to see what was
> passed in).
>
> "git whatchanged" would obviously take all the same flags "git log" does,
> and "git diff" could take them and just test the values for sanity (ie
> error out if min/max_date is not -1, for example).
Perhaps.
> "git show" is like a "git-whatchanged" except it wouldn't walk the diffs
> (I considered adding a "--nowalk" option to setup_revisions(), which would
> just suppress the "add_parents_to_list()" entirely)
Umm. The current "git show -4" walks and I find the behaviour
useful. They are the same program with different defaults.
^ permalink raw reply
* increase in sexual desire
From: Samantha Sands @ 2006-03-01 20:04 UTC (permalink / raw)
To: geogirb
Carefully chosen herbal ingredients are the key to peniis enlargement success.
Not only the precise blend of ingredients but also many other factors have effect
on the overall potency and strength of peniis enlargement formula.
Some of these factors include growing conditions, geographical location where herbs are grown,
harvest time, the way herbs are stored before processing, the way herbs are processed.
http://aceldgkbfhijm.planetfaktor.com/?bfhijmxwqowyacelzppdgk
y6s
^ permalink raw reply
* Re: impure renames / history tracking
From: Junio C Hamano @ 2006-03-01 19:56 UTC (permalink / raw)
To: paul; +Cc: Andreas Ericsson, git list
In-Reply-To: <Pine.LNX.4.64.0603011851430.13612@sheen.jakma.org>
Paul Jakma <paul@clubi.ie> writes:
> For sake of argument assume the workflow corresponds to:
>
> o-o-o-o---o--o
> / \
> --o----------------m->
>
> And collapsing just the 'oops, made a typo' commits so it looks like:
>
> o-----o------o
> / \
> --o----------------m->
>
>
> The /real/ point, other than workflow, is:
>
> - can we track 'rename and rewrite'?
Yes. Especially the collapsing is 'oops, made a typo' kind.
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. 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.
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.
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. Then, you would get better rename+rewrite
detection than what it currently does.
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.
^ permalink raw reply
* Re: impure renames / history tracking
From: Paul Jakma @ 2006-03-01 19:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Andreas Ericsson, git list
In-Reply-To: <46a038f90603011005m68af7485qfdfffb9f82717427@mail.gmail.com>
On Thu, 2 Mar 2006, Martin Langhoff wrote:
> The moment you 'merge' by using git-diff | patch you lose all the
> support git gives you, because you are discarding all of git's
> metadata! git's metadata is about all the commits you are merging,
> and is good enough that it will help future merges across renames.
> You should really use git-pull/git-merge at that point.
Let's try not get stuck on the workflow.
I probably shouldn't have brought it up. However, just assume it's
been decided that 'detail' of the project implementation is too much
clutter for the 'master'. I note that people do this already even in
the "keep all the details" Linux and Git workflows, where they
rejiggle commits in order to cut-out 'oops, made a typo' type of
commits.
So the level of detail that is suitable is for 'merging upstream'
clearly is arbitrary and subjective, and even with git and Linux that
knob already is set past 0 (all detail), maybe to 1 - the workflow
I'm thinking of has it set to (say) 2.
For sake of argument assume the workflow corresponds to:
o-o-o-o---o--o
/ \
--o----------------m->
And collapsing just the 'oops, made a typo' commits so it looks like:
o-----o------o
/ \
--o----------------m->
The /real/ point, other than workflow, is:
- can we track 'rename and rewrite'?
> And you can modify your practices ever so slightly to match the
> benefits of the old model:
I agree completely on the workflow argument, I intend to make it to
the project concerned ;).
> And what I've found, managing a project with 13K files, is that in
> practice git does far better tracking renames than several SCMs
> that do explicit tracking. Don't be distracted by the 'we don't
> track renames posturing'. We do, and it's so magic that it just
> works.
Yep, I know. :).
I just wonder if that magic could use additional hints (*not* Attic/
type stuff, ick ye gods no! Agree fully there!). Cause 'rename and
rewrite' it just does not get right.
Simplest test-case (simulating 'rename and rewrite half the file')
is:
- create a one-line file
- commit to git
- mv it and add a line
To show:
$ git status
nothing to commit
$ cat test
foo
$ git-mv test toast
$ echo bar >> toast
$ git-update-index toast
$ git status
#
# Updated but not checked in:
# (will commit)
#
# deleted: test
# new file: toast
#
A year later, someone comes along and looks at the history for
'toast', they'll never know they can look back further by following
'test'.
I'd like to fix the above somehow, possibly by adding 'renamed test
toast' meta-data to index cache and commit objects. Having git-mv /
git-cp add that meta-data.
Then diffcore using that meta-data as /advisory/ and auxilliary
information *only* in /helping/ to determining renames, as an
additional input to its existing heuristics. This meta-data would not
be intrinsic to the operation git, it would /only/ be to aid humans
(or their tools rather) in tracking back/forward through history.
Would that be the best way to explore solving the above problem?
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Human resources are human first, and resources second.
-- J. Garbers
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Junio C Hamano @ 2006-03-01 19:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, Eric Wong, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0603010935201.22647@g5.osdl.org>
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.
Some caveats upfront, though.
Since I was bitten at least once by attempting get_sha1() to
deal with ambiguous names (the issue was between heads and tags
but I think there are similar issues here) I am really reluctant
to have the function look at anywhere other than heads/ and
tags/ without explicit prefix.
Currently get_sha1_basic() says:
* look in $GIT_DIR with these prefixes in turn and take
the first match: "", "refs", "refs/tags", "refs/heads".
The extended one _would_ in addition say one of these things:
* if none of the above prefixes work, try other
directories under refs/ as prefixes and take the first
match.
or
* if none of the above prefixes work, try other
directories under refs/ as prefixes and if there is a
unique match take it. If there are more than one
match, do not take either.
In the context of get_sha1(), get_sha1_basic() is used like
this:
* if get_sha1_basic() finds an answer, use it.
Otherwise see if it is an abbreviated object name.
The behaviour of a naive implementation of the former would
depend on readdir() and traversal order, which makes (from the
end user's point of view) a hard to understand confusion that is
not reproducible. Another repository cloned from such would
even give you different answers.
The latter at first sounds sane, but it has a subtle issue,
which was what bitten me previously between heads/ and tags/.
In that broken version, if you have a head called "dead" and a
tag with the same name, neither was taken ("they are not unique,
so do not take either!") and we ended up finding an object whose
SHA1 name began with those two bytes 0xDE 0xAD. I do not think
this has happened in the field, fortunately, but it would have
been quite hard to diagnose.
So if we were to do it, I would say do the latter, but be very
careful to make sure you fail the whole get_sha1() when you bail
out of the "try possible prefixes" codepath because of
ambiguity. There may be other issues involved, but I wouldn't
know -- I reverted the "do not take either if they are
ambiguous between heads/ and tags/" patch primarily because of
the reason from the above paragraph, but also did not want to
deal with any other potential issues to keep my sanity ;-).
^ permalink raw reply
* Re: impure renames / history tracking
From: Paul Jakma @ 2006-03-01 18:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, git list
In-Reply-To: <Pine.LNX.4.64.0603010859200.22647@g5.osdl.org>
Hi Linus,
On Wed, 1 Mar 2006, Linus Torvalds wrote:
> The thing is, it does better than anything that _tries_ to be
> "reliable".
>
> I can pretty much _guarantee_ that you can't do it better.
I'm willing to take that argument to the 'project' concerned, I just
need to be pretty sure of it.
> Tracking "inodes" - aka file identities - (which is what BK does,
> and I assume what SVN does) is fundamentally problematic. I
> particular, it's a horrible problem when two inodes "meet" under
> the same name. You now have two identities for the same file, and
> you're fundamentally screwed.
Yes, in that model it is. This interestingly, is not the BK model, I
suspect (see below).
> It doesn't even need renames to be a problem. JUST THE FACT THAT
> YOU TRY TO TRACK FILE "IDENTITY" HISTORY IS BROKEN.
If it's "file identity" globally across the lifetime of the project,
I agree 100% per cent. The 'traditional' SCM concerned does this.
That's not what a solution I'd want to explore either, I'm only
interested in the identity of files for any one /one/ commit. In
saying that, I recognise it's pointless to try annotate file-change
information in multi-parent commits (merges).
> For example, take CVS, which doesn't actually try to do renames,
> but _does_ try to track the identity of a file, since all the
> history is tied into that identity: think about what happens in
> Attic when a file is deleted. Completely broken model.
ACK, {Attic,deleted_files}/ is just horrid.
> And that's really fundamental. CVS doesn't show the problems so
> much, because CVS actively tries to make it hard to do these
> things.
ACK.
> With renames-tracking-file-identities, it's _really_ easy to get
> some major confusion going. What happens when one branch creates a
> file, and another one renames a file to that same name, and they
> merge?
Well, the conflict has to be resolved somehow, even today.
> Don't tell me it doesn't happen. It happened under BK. The way BK
> "solved" it was to keep the two separate identities: one of them
> got resolved to the new filename, the other one went into the
> "deleted" directory.
Right. That's what the 'traditional workflow' SCM I'm thinking of
does - not BK funnily enough, but an SCM predating BK which also
happens to use SCCS files, and with some of the same high-level
push/pull constructs as BK (interestingly).
It also tracks name history globally using a deleted_files/ history,
which is maintained, but I don't think it does this for name merges
like the above.
In the one I'm thinking of, it does (I /think/, I'm not an expert in
it) the following:
Given two files, say:
'old:
1.1---1.2---1.3
new:
1.1
- constructs a 'fake' base SCCS revision, empty
- adds the top 'old' version as a branch
- adds the top new version as a new delta
1.1.1.1
/
1.1---------1.2
Where in the merged file:
1.1: empty
1.1.1.1: was 1.3 from 'old'
1.2: is 1.1 from 'new'
However, it does /not/ create a deleted_files entry for the 'old'
file. (AFAICT - I may not have a sufficiently full understanding of
this SCM)
> Guess what happens when the side that got merged into "deleted"
> continues to edit the file? That's right - their edits happen on
> the deleted file, and never show up in the real tree in a
> subsequent merge ever again.
Indeed - horrid.
> And as far as I can tell, BK really did the best you can do.
> Following file identities really _is_ fundamentally broken. It
> sounds like a nice idea, but while you migth solve a few problems,
> you create a whole raft of much more fundamental problems.
For tracking identity across more than one commit - I fully agree.
That's not what quite I'm thinking of though. Is it worth going on
with the discussion on a:
'track identities *only* from context of /the/ parent to
this commit'
> So next time you think about a merge that migt have been improved
> by tracking renames, please also think about a merge where one of
> the filenames came from two or more different sources through an
> earlier merge, and thank your benevolent Gods that they instructed
> me to make git be based purely on file contents.
Oh, I agree muchely here.
I wouldn't change git. I only wonder if it give its rename-heuristics
an additional advisory-only hint? (for single-parent commits at least
- never merges - and only on a per-commit basis).
I probably should first explore how git deals with rename clashes..
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
I'm glad I was not born before tea.
-- Sidney Smith (1771-1845)
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Linus Torvalds @ 2006-03-01 18:25 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Andreas Ericsson, Eric Wong, Martin Langhoff, git
In-Reply-To: <200603011906.33433.Josef.Weidendorfer@gmx.de>
On Wed, 1 Mar 2006, Josef Weidendorfer wrote:
>
> On Wednesday 01 March 2006 18:40, Linus Torvalds wrote:
> > But if somebody does the get_sha1() magic, and Junio agrees, then I think
> > it would be a great thing to do.
>
> Yes.
>
> git log origin/master..
>
> is really not that bad
It really is.
Think like a user. If I pull from "origin", then the name of that thing is
"origin", not "origin/master" or "o/master". A user doesn't care what the
remote branch name is - the whole _point_ of the .git/remotes/xyzzy file
is to give a short description that includes the names of the branches you
pull from.
The good news is that "get_sha1()" shouldn't be that hard to extend on.
Just add a case at the end that says "do we have a .git/remotes/%s file,
and if so, parse it".
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox