* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Johannes Sixt @ 2009-12-16 16:53 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git
In-Reply-To: <20091216164553.GA22471@pcpool00.mathematik.uni-freiburg.de>
Please do not set Mail-Followup-To (and use reply-to-all to keep the Cc list).
Bernhard R. Link schrieb:
> --prune-tree makes rev-list without paths equivalent to
> "git rev-list $options -- ." (or .. or ../.. and so on,
> if you are in some subdirectory).
> This is the new default for format-patch and rebase
Why do you need a new option when you can just add "-- ." to the rev-list
invocation?
-- Hannes
^ permalink raw reply
* Re: subtree merge tries to merge into wrong directory
From: naderman @ 2009-12-16 18:05 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130912100638v1f701183w909367cd97c8325@mail.gmail.com>
Avery Pennarun wrote:
> On Wed, Dec 9, 2009 at 10:41 PM, Nils Adermann <naderman@naderman.de>
wrote:
>> Following
>> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
>> I have subtree merged a 3rd party library (ezc-reflection) into my
>> repository (pflow). The prefix I used was lib/ezc/trunk/Reflection. Now
>> there have been changes to ezc-reflection but merging them into my
>> repository fails. The merge is attempted in example/ rather than
>> lib/ezc/trunk/Reflection.
>
> The auto-guessing feature of "merge -s subtree" doesn't always work.
> The 'pu' branch of git has some patches which allow you to use a
> command line like
>
> git merge -Xsubtree=lib/ezc/trunk/Reflection
>
> If you're nervous about using all of 'pu', try building git's 'master'
> after merging from commit 0354b06927a1220b696a5ee1004a8f061ba9b153.
So I finally got around to trying this. This was my first result:
$ git merge -Xsubtree=lib/ezc/trunk/Reflection/ FETCH_HEAD
fatal: entry not found in tree 60270661e0d2a5ee03b24609fac5c6d00d048988
Interestingly the following works, as in merges correctly into
lib/ezc/trunk/Reflection/. The "arbitrary" part can be set to anything it
just needs to be set. No directory with that name is created.
$ git merge --strategy-option=subtree=arbitrary FETCH_HEAD
Merge made by recursive.
.../trunk/Reflection/src/doc_comment_parser.php | 38
++++++++++---------
1 files changed, 20 insertions(+), 18 deletions(-)
While the following results in the same issue I originally had with -s
strategy
$ git merge --strategy-option=subtree FETCH_HEAD
CONFLICT (delete/modify): example/src/doc_comment_parser.php deleted in
HEAD and modified in FETCH_HEAD. Version FETCH_HEAD of
example/src/doc_comment_parser.php left in tree.
Automatic merge failed; fix conflicts and then commit the result.
I'm not sure why this is happening, but the
--strategy-option=subtree=arbitrary solves my issue for now.
Cheers
Nils
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Elijah Newren @ 2009-12-16 18:05 UTC (permalink / raw)
To: bd; +Cc: git
In-Reply-To: <20091216101647.GB27373@bc-bd.org>
On Wed, Dec 16, 2009 at 3:16 AM, <bd@bc-bd.org> wrote:
> imagine this:
>
> --A--*--B (new)
> /
> *--X--*--Y (master)
>
> Now I'd like to list only log messages for A..B (X..B would be okay too).
>
> I know of
>
> git log master..new
>
> however then I need to remember that I branched new of master, and to be honest,
> sometimes I forget.
>
> So how do I:
>
> git please-tell-me-the-branch-I-started-this-branch-from new
In the above example, you technically did not create 'new' off of
'master', you created new starting at X. You may think of it in terms
of branching off of 'master', but
git branch new master
resolves 'master' to the commit it points at and creates 'new'
pointing at that commit. That's all that is recorded. But I believe
the info you are really interested in is where new started, rather
than the fact that it branched off master. Is that correct? If so,
just use new@{30.years.ago} (or any other sufficiently long period of
time):
git log new@{30.years.ago}..new
(You'll get a warning that 'new' hasn't existed for 30 years but it
doesn't hurt anything)
Hope that helps,
Elijah
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: Jakub Narebski @ 2009-12-16 19:52 UTC (permalink / raw)
To: J.H.; +Cc: Junio C Hamano, git, John 'Warthog9' Hawley
In-Reply-To: <4B283F3D.3020209@kernel.org>
On Tue, 15 Dec 2009, 18:00 -0800, J.H. wrote:
> Junio C Hamano wrote:
> > Any progress on this front?
>
> Sadly, no. Busy weekend and a need to get some of the kernel.org
> servers upgraded has taken some precedence. I should be circling back
> around on this tomorrow I think.
So should I wait for reroll with proposals for improvements (modified
patches)?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: J.H. @ 2009-12-16 20:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200912162052.09470.jnareb@gmail.com>
Jakub Narebski wrote:
> On Tue, 15 Dec 2009, 18:00 -0800, J.H. wrote:
>> Junio C Hamano wrote:
>
>>> Any progress on this front?
>> Sadly, no. Busy weekend and a need to get some of the kernel.org
>> servers upgraded has taken some precedence. I should be circling back
>> around on this tomorrow I think.
>
> So should I wait for reroll with proposals for improvements (modified
> patches)?
I'd probably wait, though it's starting to look like if I get to gitweb
today it will be this evening as I ventured off into getting the last 6
of the kernel.org servers upgraded. Either way I will have a new patch
series and some changes in my own git tree shortly.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: git svn clone just stops
From: Mark Jerkovic @ 2009-12-16 20:47 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20091216081514.GB26038@dcvr.yhbt.net>
On Wed, 2009-12-16 at 00:15 -0800, Eric Wong wrote:
> Mark Jerkovic <mjerkovic@aconex.com> wrote:
> > Hi all,
> >
> > I am new to Git and I am attempting to clone a SVN repository
> > (containing approximately 60,000 commits) to Git.
> >
> > Using Git v1.6.0.4 with the following command:
> >
> > git svn clone https://path/to/svn/repo/trunk project.git
> > --authors-file=svnauthors.txt --no-metadata
> >
> > the process just ends without any messages and the Git repository is
> > empty. I have attempted this four times already, and each time it has
> > stopped after a different revision, so I can't pin it down to a
> > particular commit.
>
> Hi Mark,
>
> Any chance you're OOM-ing (extremely large file) or running
> out of space somewhere? What exit code do you get when it exits?
>
> > Has anyone experienced this before? Is there a log anywhere that
> > records what is happening during this process?
>
> Not without error messages of some sort. git svn was designed with poor
> network conditions in mind and clone is resumable, so you can just
> resume like this:
>
> cd project.git && git svn fetch
>
That is an excellent tip. Thanks a lot!
> I wouldn't use --no-metadata at this point, though, as it makes it much
> harder to debug/fix things or recover from errors.
>
> Once you're comfortable with it, you should be able to write
> "git filter-branch" invocation to remove the metadata lines.
I have done some more investigating and it appears that at some point a
branch was moved to replace our trunk. When the migration process hits
this I it goes back to the beginning and starts migrating the branch
history too. I think when it gets to the end of it is not able to
resume from the "move" point.
I will try your resume tip to see if I can get it started again.
Many thanks,
Mark.
>
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-16 21:06 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1260970885.2788.87.camel@localhost>
On Wed, 16 Dec 2009, Eric Paris wrote:
> On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> > On Mon, 14 Dec 2009, Eric Paris wrote:
> >
> > > The alternative repo is slowing pushing up to that same location. That
> > > tar is 855838982, so just a tad bit smaller.
> >
> > It doesn't appear to be complete yet, and not progressing either.
>
> The alternative repo is now available (but the original is down)
>
> I tried to run git gc --aggressive last night while I slept and got this
> as output, maybe it helps point to a solution/problem? The git reflog
> portion ran for 5 hours and 36 minutes and appears to have finished.
Yes. I was able to reproduce your issue. And because of the *horrible*
repository packing, the reflog expiration process is taking ages when
determining object reachability at a rate of one reflog entry every 2
seconds or so. With 4214 entries for the fsnotify-syscall branch, and
1352 entries for the fsnotify branch, this already takes up asignificant
portion of the actual run time. I'm sure if your repository was
properly packed this would take less than a minute.
Now, repacking doesn't work because...
> $ git gc --aggressive
> error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
> error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
Those objects are indeed missing from the repository. Without them your
repository is "broken". Either you can find them somewhere else and
copy them over, or salvage as much as you can by fetching the
interesting branches into another freshly made repository. This is
unfortunate because I would have liked to see by how much this
repository would have shrunk after a successful repack.
Of course, usage of alternates is recommended _only_ with repositories
that are stable, i.e. don't ever add repositories to
.git/objects/info/alternates if those repositories are rewinded/rebased
and/or branches in them are deleted/replaced. That could be a reason
why some objects are now missing from the repository using alternates.
Nicolas
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-16 22:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912161526080.23173@xanadu.home>
On Wed, 2009-12-16 at 16:06 -0500, Nicolas Pitre wrote:
> On Wed, 16 Dec 2009, Eric Paris wrote:
>
> > On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> > > On Mon, 14 Dec 2009, Eric Paris wrote:
> > >
> > > > The alternative repo is slowing pushing up to that same location. That
> > > > tar is 855838982, so just a tad bit smaller.
> > >
> > > It doesn't appear to be complete yet, and not progressing either.
> >
> > The alternative repo is now available (but the original is down)
> >
> > I tried to run git gc --aggressive last night while I slept and got this
> > as output, maybe it helps point to a solution/problem? The git reflog
> > portion ran for 5 hours and 36 minutes and appears to have finished.
>
> Yes. I was able to reproduce your issue. And because of the *horrible*
> repository packing, the reflog expiration process is taking ages when
> determining object reachability at a rate of one reflog entry every 2
> seconds or so. With 4214 entries for the fsnotify-syscall branch, and
> 1352 entries for the fsnotify branch, this already takes up asignificant
> portion of the actual run time. I'm sure if your repository was
> properly packed this would take less than a minute.
I'm guessing this is a result of stgit.? These branches really should
be just a branch from a tag (which exists in kernel-1) and about 30-50
patches linearly applied on top. I don't know how I get that many
objects. I'm guessing many/most of them are crap that should be able to
be cleaned/deleted entirely as the rebasing/pushing/poping/updating that
stgit does under the covers should have rendered them pointless. Not
really sure when/how that should/could have happened.
Should I be running git-gc every night?
> Now, repacking doesn't work because...
>
> > $ git gc --aggressive
> > error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
> > error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
/me is pretty git dumb, but is there some way to figure out the parents
or children of these? I just trolled through all of my directories
doing git show and didn't get any hits. I guess I'll just clean up and
start over....
> Those objects are indeed missing from the repository. Without them your
> repository is "broken". Either you can find them somewhere else and
> copy them over, or salvage as much as you can by fetching the
> interesting branches into another freshly made repository. This is
> unfortunate because I would have liked to see by how much this
> repository would have shrunk after a successful repack.
>
> Of course, usage of alternates is recommended _only_ with repositories
> that are stable, i.e. don't ever add repositories to
> .git/objects/info/alternates if those repositories are rewinded/rebased
> and/or branches in them are deleted/replaced. That could be a reason
> why some objects are now missing from the repository using alternates.
So I'm not sure how I did things wrong. my kernel-1 has those bunch of
remotes. The linux-next remote, like I said, basically rebases to
linus' tree, then merges 150 random branches. It tags that tree every
day and I pull those tags. So I would never expect any objects from
those remote trees to ever disappear.
Now I created branches in kernel-1 and I certainly have done lots of
things like so
git checkout -b testing remotes/linux-next/master
[edit]
git commit -a
git checkout -b testing1 remotes/linux-next/master
git branch -D testing
My assumption though was that this wouldn't ever affect my other
repositories. My other repository branches always started by checking
out a branch with remotes/*/* as the base.
My understanding was that I would only run into problems if I used
something on a branch I created myself in the alternatives repo in other
repos (and I didn't remove remotes)
I guess it's not impossible to believe that at some point in time i
would have exported patches to and mbox from kernel-1 and applied them
to kernel-2 or vice versa. I guess this would end up with the same
objects, right? Then if I deleted the branch in kernel-1 I would have
problems in kernel-2?
I guess I'll rebuild my setup
new kernel-alt has just the remotes, and my kernel-1,2,3 all alt to it
I'll never have local branches in my kernel-alt
I'll run git-gc every night
I'll hope to never have problem again.
Sound good?
^ permalink raw reply
* Re: Git on QNX
From: Sean Boudreau @ 2009-12-16 22:38 UTC (permalink / raw)
To: git
In-Reply-To: <905315640912151413g10ee5befh58fbd171237e7659@mail.gmail.com>
Tarmigan <tarmigan+git <at> gmail.com> writes:
> >
> > Other hunks are QNX specific enough but this hunk is worrisome; you cannot
> > tell how you are hurting other platforms with this change. Can you tell
> > declarations of which functions are missing on QNX without this change?
>
> strcasecmp()
> http://www.opengroup.org/onlinepubs/000095399/functions/strcasecmp.html
>
> I agree that this change could affect other platforms and they've
> gotten along fine without it so far. I'm surprised no others have
> needed it. Would it be better wrapped in a #ifdef?
>
> Thanks,
> Tarmigan
>
What version of qnx is this on. <strings.h> is
now brought in by <string.h> and the lock() /
unlock() prototypes have been removed from <unistd.h>
AS OF 6.4.1 (the current release).
There's a package for git-4.3.20 here that also has a work around
for the SA_RESTART issue.
ftp://ftp.netbsd.org/pub/pkgsrc/packages/QNX/i386/6.4.1_head_20090724/All
-seanb
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Miklos Vajna @ 2009-12-16 23:26 UTC (permalink / raw)
To: Elijah Newren; +Cc: bd, git
In-Reply-To: <51419b2c0912161005n1596d4a1n92ed555c98aee4c6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
On Wed, Dec 16, 2009 at 11:05:52AM -0700, Elijah Newren <newren@gmail.com> wrote:
> git log new@{30.years.ago}..new
> (You'll get a warning that 'new' hasn't existed for 30 years but it
> doesn't hurt anything)
That's the same as "git log new", if I'm not mistaken.
What Stefan wants to do is to let git log show the commits which are
only in the "new" branch, but I don't think there is an out-of-the-box
solution for that.
One solution I can think of is to iterate over each ref using "git
for-each-ref --format='%(refname)' 'refs/heads/*'", then run "git
merge-base $i new", run git rev-list $mb..new|wc -l and then you could
decide what is the first commit that does not belong to any other
branch. But that's just an idea, I don't have the motivation to script
it properly.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Santi Béjar @ 2009-12-16 23:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Elijah Newren, bd, git
In-Reply-To: <20091216232641.GK25474@genesis.frugalware.org>
On Thu, Dec 17, 2009 at 12:26 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Wed, Dec 16, 2009 at 11:05:52AM -0700, Elijah Newren <newren@gmail.com> wrote:
>> git log new@{30.years.ago}..new
>> (You'll get a warning that 'new' hasn't existed for 30 years but it
>> doesn't hurt anything)
>
> That's the same as "git log new", if I'm not mistaken.
>
> What Stefan wants to do is to let git log show the commits which are
> only in the "new" branch, but I don't think there is an out-of-the-box
> solution for that.
Not out-of-the-box but this does exactly what you said, print all
commits only reachable from the "new" branch:
git log new --not $(git for-each-ref --format='%(refname)'
'refs/heads/*' | grep -v refs/heads/new)
For the original question, I think what makes most sense in this case
is asking for the commits since the upstream branch. Some time ago
there was a discussion about a syntax for the tracking branch and
there was even a patch:
Subject: [PATCH v2] Introduce <branch>@{upstream} as shortcut to the
tracked branch
Date: 2009-09-10 15:25:57 GMT
http://news.gmane.org/find-root.php?message_id=%3calpine.DEB.1.00.0909101724520.8306%40pacific.mpi%2dcbg.de%3e
but it's not in git.git.
HTH,
Santi
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Elijah Newren @ 2009-12-16 23:59 UTC (permalink / raw)
To: Miklos Vajna; +Cc: bd, git
In-Reply-To: <20091216232641.GK25474@genesis.frugalware.org>
On Wed, Dec 16, 2009 at 4:26 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Wed, Dec 16, 2009 at 11:05:52AM -0700, Elijah Newren <newren@gmail.com> wrote:
>> git log new@{30.years.ago}..new
>> (You'll get a warning that 'new' hasn't existed for 30 years but it
>> doesn't hurt anything)
>
> That's the same as "git log new", if I'm not mistaken.
Did you try it with a 'new' branch in your repository that started at
the beginning of history rather than at some commit? "git log new"
and "git log new@{30.years.ago}..new" are not the same for me with
git-1.6.5.5:
$ git init repo
$ cd repo
$ echo content> foo && git add foo && git commit -mone foo
$ echo more content >> foo && git commit -mtwo foo
$ git checkout -b new master~1
$ echo stuff >> foo && git commit -mthree foo
$ git log new@{30.years.ago}..new
warning: Log for 'new' only goes back to Wed, 16 Dec 2009 16:48:02 -0700.
commit 7df8bad7cc146875c59ab030da0d25555976e79c
Author: Elijah Newren <newren@gmail.com>
Date: Wed Dec 16 16:48:07 2009 -0700
three
$ git log new
commit 7df8bad7cc146875c59ab030da0d25555976e79c
Author: Elijah Newren <newren@gmail.com>
Date: Wed Dec 16 16:48:07 2009 -0700
three
commit b86eadcdb152877ade44bebf4b8742884949f29f
Author: Elijah Newren <newren@gmail.com>
Date: Wed Dec 16 16:47:31 2009 -0700
one
> What Stefan wants to do is to let git log show the commits which are
> only in the "new" branch, but I don't think there is an out-of-the-box
> solution for that.
Are you sure? I'm more inclined to believe he'd like to see all the
commits that have been added to the "new" branch since he created it
(which may be the same as what you say, but not necessarily). Of
course, neither my assumption or yours match what he actually asked
for (though I think what he asked for isn't possible and is merely an
means to the end he really wants).
Also, I think this does what you asked for (the commits in the "new"
branch but no other branch):
$ git log new $(git for-each-ref --format='%(refname)' 'refs/heads/*'
| grep -v '^refs/heads/new$' | sed -e s/^/^/)
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Elijah Newren @ 2009-12-17 0:04 UTC (permalink / raw)
To: Santi Béjar; +Cc: Miklos Vajna, bd, git
In-Reply-To: <adf1fd3d0912161558u36d9674eid36e3042d181ed8f@mail.gmail.com>
On Wed, Dec 16, 2009 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
> git log new --not $(git for-each-ref --format='%(refname)'
> 'refs/heads/*' | grep -v refs/heads/new)
How did I miss '--not' as a git log option? Thanks for pointing it out!
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Miklos Vajna @ 2009-12-17 0:20 UTC (permalink / raw)
To: Elijah Newren; +Cc: bd, git
In-Reply-To: <51419b2c0912161559x4de94464pe06df2845dbe3b78@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
On Wed, Dec 16, 2009 at 04:59:54PM -0700, Elijah Newren <newren@gmail.com> wrote:
> Did you try it with a 'new' branch in your repository that started at
> the beginning of history rather than at some commit? "git log new"
> and "git log new@{30.years.ago}..new" are not the same for me with
> git-1.6.5.5:
>
> $ git init repo
> $ cd repo
> $ echo content> foo && git add foo && git commit -mone foo
> $ echo more content >> foo && git commit -mtwo foo
> $ git checkout -b new master~1
> $ echo stuff >> foo && git commit -mthree foo
> $ git log new@{30.years.ago}..new
Aah, thanks. Then you can just avoid the warning using
git log $(git reflog show new|sed -n 's/ .*//;$ p')..new
> Are you sure? I'm more inclined to believe he'd like to see all the
> commits that have been added to the "new" branch since he created it
> (which may be the same as what you say, but not necessarily). Of
> course, neither my assumption or yours match what he actually asked
> for (though I think what he asked for isn't possible and is merely an
> means to the end he really wants).
No, I'm not sure about what he thought, but I hope he will clarify. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: New Proposal (simple) for Metadata in Git Commits: git-meta
From: Johan Herland @ 2009-12-17 0:26 UTC (permalink / raw)
To: Sam Elliott; +Cc: git, Shawn O. Pearce
In-Reply-To: <20091216163036.GE18319@spearce.org>
On Wednesday 16 December 2009, Shawn O. Pearce wrote:
> Sam Elliott <sam@lenary.co.uk> wrote:
> > On 15 Dec 2009, at 23:05, Shawn O. Pearce wrote:
> >> If you dropped the --git-meta-- tags above, JGit would happily
> >> recognize the awesome: and Github: tags, but it might need a bit
> >> more work to recognize the nested user: tag. Also, you'd be able
> >> to use git-meta on the git and Linux kernel repositories to pull
> >> out and work with Signed-off-by, Acked-by, etc.
> >
> > I'm not entirely sure about this approach. The current implementation
> > also works with PGP-signed tags, where the information is not
> > necessarily going to be at the bottom of the message when i use `git-
> > cat-file -p`. I think it shouldn't be too hard to also have git-meta
> > read any YAML-like data just before the signing message.
>
> Ah, good point. But as you point out, it should be simple enough
> to detect a PGP signature on the bottom and just clip that off the
> end, and then perform the YAML-like data parsing on the footer.
I agree with Shawn's point that it should be possible to do this without
embedding it in custom ---tags---.
I would even try to parse the _entire_ commit message, and then discard
everything that didn't match the "<word>: <free-form value>" format (with
possible continuation lines). Even though this will generate some false
positives (probably non-sensical "key: value" pairs), I don't see this as a
major problem , since most users of this functionality are looking for a
small set of specific keywords (which are even more unlikely to turn up as
false positives)
In future versions of Git, you might also want to check for YAML-like data
in the notes object corresponding to the commit in question (see git-notes
in v1.6.6 for more details on the new notes feature). This would allow users
to add/edit such metadata after the commit was made, without having to
rewrite the commit itself.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [ANNOUNCE] Git 1.6.5.7
From: Junio C Hamano @ 2009-12-17 0:29 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.6.5.7 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.7.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.7.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.7.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5.7-1.fc11.$arch.rpm (RPM)
Nothing spectacular to see here, but as I was tagging 1.6.6-rc3 today, I
wanted to push out fixes accumulated on the maintenance branch in a tagged
release. Everything in this release is also in 1.6.6-rc3.
----------------------------------------------------------------
Changes since v1.6.5.6 are as follows:
Jeff King (1):
ignore unknown color configuration
Johannes Sixt (1):
help.autocorrect: do not run a command if the command given is junk
Junio C Hamano (2):
worktree: don't segfault with an absolute pathspec without a work tree
Git 1.6.5.7
Nanako Shiraishi (1):
Illustrate "filter" attribute with an example
^ permalink raw reply
* [ANNOUNCE] Git 1.6.6.rc3
From: Junio C Hamano @ 2009-12-17 0:30 UTC (permalink / raw)
To: git
A release candidate Git 1.6.6.rc3 is available at the usual places
for testing:
http://www.kernel.org/pub/software/scm/git/
git-1.6.6.rc3.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.6.rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.6.rc3.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.6.6.rc3-1.fc11.$arch.rpm (RPM)
Things have really calmed down and hopefully we can give the final release
as holiday present to everybody in time ;-)
----------------------------------------------------------------
Changes since v1.6.6-rc2 are as follows:
Björn Gustavsson (1):
bash: Support new 'git fetch' options
Jeff King (1):
ignore unknown color configuration
Johannes Sixt (1):
help.autocorrect: do not run a command if the command given is junk
Junio C Hamano (7):
Remove post-upload-hook
Fix archive format with -- on the command line
Git 1.6.5.6
Update Release Notes for 1.6.6 to remove old bugfixes
worktree: don't segfault with an absolute pathspec without a work tree
Git 1.6.5.7
Git 1.6.6-rc3
Nanako Shiraishi (1):
Illustrate "filter" attribute with an example
^ permalink raw reply
* Re: Git on QNX
From: Tarmigan @ 2009-12-17 1:03 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Sean Boudreau, mkraai
In-Reply-To: <loom.20091216T233122-388@post.gmane.org>
On Wed, Dec 16, 2009 at 2:38 PM, Sean Boudreau <seanb@qnx.com> wrote:
> What version of qnx is this on. <strings.h> is
> now brought in by <string.h> and the lock() /
> unlock() prototypes have been removed from <unistd.h>
> AS OF 6.4.1 (the current release).
Ahh, that's nice. At a client's request, I have been working on QNX 6.3.2.
I just installed 6.4.1 in another VM, and it's a bit different. The
common way to handle binary packages (iconv and perl) seems to have
changed to pkg_add so the PATHs I had set might not make sense
anymore.
Also the weird failing test at t0000.42 seems to be fixed. Funny.
As I might be the only person to run git on 6.3.2 instead of a more
modern QNX, it might make sense for me to just submit the minimum
patches needed for QNX 6.4.1 and then carry the strings.h,
getpagesize, and lock() changes for 6.3.2 on my own.
> There's a package for git-4.3.20 here that also has a work around
> for the SA_RESTART issue.
I think that might be a different program that also used to be named
"git". I think it has now been renamed gnuit.
Thanks,
Tarmigan
^ permalink raw reply
* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: Tay Ray Chuan @ 2009-12-17 1:05 UTC (permalink / raw)
To: David Antliff; +Cc: git
In-Reply-To: <loom.20091215T225528-115@post.gmane.org>
Hi,
On Wed, Dec 16, 2009 at 6:24 AM, David Antliff <david.antliff@gmail.com> wrote:
> I suspect what is happening is that the line conversion routine in git might be
> stripping trailing whitespace, as well as converting the line endings. This
> operation is not properly accounted for in the reverse direction, and the file
> is flagged as modified.
I am not a Git expert, but could it be your editor on Windows?
Not just stripping whitespace; it might be setting the eol to LF
(instead of CRLF) when saving the file.
> Also, as cloned files are converted to DOS-line-endings, by default Cygwin's
> bash cannot run any scripts as they have the wrong line endings. I have to set
> the 'permanent' bash variable SHELLOPTS to include 'igncr' before bash scripts
> can run. Perhaps this is wrong and git on Cygwin (with binary mounts) should be
> converting to UNIX line endings instead?
Again, IANAGE, but according to the manual, this should be expected,
because Git, when writing to the filesystem, converts LF to CRLF:
If true, makes git convert CRLF at the end of lines in text files to
LF when reading from the filesystem, and convert in reverse when
writing to the filesystem.
> At one point I tried switching off core.autocrlf for myself but this caused a
> lot of conflicts due to mismatched line-endings. It seems to me that if we want
> to switch to this, *everyone* has to do it at once.
Just make this conversion a commit, and depending on your project's
workflow, push/pull it.
Although the whole file will be marked as changed, you can always
double-check that only whitespace changes have been made by running
git-diff with --ignore-space-at-eol or -b.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Git on QNX
From: Sean Boudreau @ 2009-12-17 1:37 UTC (permalink / raw)
To: Tarmigan; +Cc: git, Alex Riesen, mkraai
In-Reply-To: <905315640912161703u3920178cm93851ddc8480ac8@mail.gmail.com>
On Wed, Dec 16, 2009 at 05:03:16PM -0800, Tarmigan wrote:
> On Wed, Dec 16, 2009 at 2:38 PM, Sean Boudreau <seanb@qnx.com> wrote:
> > What version of qnx is this on. <strings.h> is
> > now brought in by <string.h> and the lock() /
> > unlock() prototypes have been removed from <unistd.h>
> > AS OF 6.4.1 (the current release).
>
> Ahh, that's nice. At a client's request, I have been working on QNX 6.3.2.
>
> I just installed 6.4.1 in another VM, and it's a bit different. The
> common way to handle binary packages (iconv and perl) seems to have
> changed to pkg_add so the PATHs I had set might not make sense
> anymore.
>
> Also the weird failing test at t0000.42 seems to be fixed. Funny.
>
> As I might be the only person to run git on 6.3.2 instead of a more
> modern QNX, it might make sense for me to just submit the minimum
> patches needed for QNX 6.4.1 and then carry the strings.h,
> getpagesize, and lock() changes for 6.3.2 on my own.
That's why I spoke up :)
>
> > There's a package for git-4.3.20 here that also has a work around
> > for the SA_RESTART issue.
>
> I think that might be a different program that also used to be named
> "git". I think it has now been renamed gnuit.
You're probably right, try this one:
ftp://ftp.netbsd.org/pub/pkgsrc/packages/QNX/i386/6.4.1_head_20090724/All/scmgit-base-1.6.2.5.tgz
-seanb
^ permalink raw reply
* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: David Antliff @ 2009-12-17 2:01 UTC (permalink / raw)
To: git
In-Reply-To: <be6fef0d0912161705q1ef23634rccdc170d69cf9484@mail.gmail.com>
Tay Ray Chuan writes:
> On Wed, Dec 16, 2009 at 6:24 AM, David Antliff wrote:
> > I suspect what is happening is that the line conversion routine in git
> > might be
> > stripping trailing whitespace, as well as converting the line endings. This
> > operation is not properly accounted for in the reverse direction, and the
> > file is flagged as modified.
>
> I am not a Git expert, but could it be your editor on Windows?
Hi Ray, thank you for responding.
This observation is made immediately after the clone, before any editor (or any
other program) even touches the files. If you can imagine doing a fresh clone
and then immediately doing 'git-status' and seeing modified files, you'd have a
pretty good idea of what I'm seeing. Git itself has somehow marked the files as
modified on check-out. I am fairly certain it's related to trailing whitespace
on one or more lines within the affected files.
If there's no trailing whitespace, git converts the file to CRLF on checkout
and shows no modification (since it knows to convert back when referring to
local repository).
> > Also, as cloned files are converted to DOS-line-endings, by default Cygwins
> > bash cannot run any scripts as they have the wrong line endings. I have to
> > set the 'permanent' bash variable SHELLOPTS to include 'igncr' before bash
> > scripts can run. Perhaps this is wrong and git on Cygwin (with binary
> > mounts) should be converting to UNIX line endings instead?
>
> Again, IANAGE, but according to the manual, this should be expected,
> because Git, when writing to the filesystem, converts LF to CRLF:
>
> If true, makes git convert CRLF at the end of lines in text files to
> LF when reading from the filesystem, and convert in reverse when
> writing to the filesystem.
Yes, perhaps the advice to use autocrlf=true on Cygwin (in binary mount mode,
since in text mode git doesn't work *at all*) is misplaced since Cygwin is not
expecting CRLF endings in that mode. Apparently it's required for apps like
Kdiff3 however... all so confusing really...
The inability to run bash scripts straight out of git when using autocrlf=true
is almost enough to suggest to me that this mode really shouldn't be used in
Cygwin.
> > At one point I tried switching off core.autocrlf for myself but this
> > caused a lot of conflicts due to mismatched line-endings. It seems to me
> > that if we want to switch to this, *everyone* has to do it at once.
>
> Just make this conversion a commit, and depending on your project's
> workflow, push/pull it.
Yes, I think that's how it has to be done. Unfortunately I have 20+ projects
each with many active branches. The entire conversion is possible but it's
going to take a while... :)
> Although the whole file will be marked as changed, you can always
> double-check that only whitespace changes have been made by running
> git-diff with --ignore-space-at-eol or -b.
That's a helpful option - thank you.
I'd be quite interested to know if people are successfully using git in Cygwin
with autocrlf=true, and if so how they are working around these modified-files
and bash-compatibility problems.
Also, is anyone using autocrlf=false in Cygwin successfully?
Thanks again for your reply.
-- David.
^ permalink raw reply
* diff attribute ignored by show and log -p
From: Jay Soffian @ 2009-12-17 4:46 UTC (permalink / raw)
To: git
% cat .git/info/attributes
*.xib diff=xibdiff
% cat $(git config diff.xibdiff.command)
#!/bin/sh
trap "rm -f \"$2.tmp\" \"$5.tmp\"" 0 1 2 3 15
ibtool --all "$2" > "$2".tmp
ibtool --all "$5" > "$5".tmp
colordiff -u "$2.tmp" "$5.tmp"
Works great for things like:
% git diff <commit1> <commit2> -- /path/to/*.xib
But is apparently ignored by "git log -p" and "git show" which just
use internal diff. Is this behavior intentional?
j.
^ permalink raw reply
* Re: diff attribute ignored by show and log -p
From: Jay Soffian @ 2009-12-17 5:23 UTC (permalink / raw)
To: git
In-Reply-To: <76718490912162046k36e2a275gaf7672b38c7a63e4@mail.gmail.com>
On Wed, Dec 16, 2009 at 11:46 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> % cat .git/info/attributes
> *.xib diff=xibdiff
> % cat $(git config diff.xibdiff.command)
> #!/bin/sh
> trap "rm -f \"$2.tmp\" \"$5.tmp\"" 0 1 2 3 15
> ibtool --all "$2" > "$2".tmp
> ibtool --all "$5" > "$5".tmp
> colordiff -u "$2.tmp" "$5.tmp"
>
> Works great for things like:
>
> % git diff <commit1> <commit2> -- /path/to/*.xib
>
> But is apparently ignored by "git log -p" and "git show" which just
> use internal diff. Is this behavior intentional?
Ah, --ext-diff, and the reasoning behind requiring it for log/show is
explained in 72909be.
j.
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-17 5:38 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1261003041.2788.142.camel@localhost>
On Wed, 16 Dec 2009, Eric Paris wrote:
> On Wed, 2009-12-16 at 16:06 -0500, Nicolas Pitre wrote:
> > On Wed, 16 Dec 2009, Eric Paris wrote:
> >
> > > On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> > > > On Mon, 14 Dec 2009, Eric Paris wrote:
> > > >
> > > > > The alternative repo is slowing pushing up to that same location. That
> > > > > tar is 855838982, so just a tad bit smaller.
> > > >
> > > > It doesn't appear to be complete yet, and not progressing either.
> > >
> > > The alternative repo is now available (but the original is down)
> > >
> > > I tried to run git gc --aggressive last night while I slept and got this
> > > as output, maybe it helps point to a solution/problem? The git reflog
> > > portion ran for 5 hours and 36 minutes and appears to have finished.
> >
> > Yes. I was able to reproduce your issue. And because of the *horrible*
> > repository packing, the reflog expiration process is taking ages when
> > determining object reachability at a rate of one reflog entry every 2
> > seconds or so. With 4214 entries for the fsnotify-syscall branch, and
> > 1352 entries for the fsnotify branch, this already takes up asignificant
> > portion of the actual run time. I'm sure if your repository was
> > properly packed this would take less than a minute.
>
> I'm guessing this is a result of stgit.? These branches really should
> be just a branch from a tag (which exists in kernel-1) and about 30-50
> patches linearly applied on top. I don't know how I get that many
> objects. I'm guessing many/most of them are crap that should be able to
> be cleaned/deleted entirely as the rebasing/pushing/poping/updating that
> stgit does under the covers should have rendered them pointless. Not
> really sure when/how that should/could have happened.
Possible. Commit operations (including patch applications) always
create loose objects because this is fast, with the expectation that
they get collected in a pack later.
> Should I be running git-gc every night?
This is certainly a good thing to do given your heavy stgit usage.
> > Now, repacking doesn't work because...
> >
> > > $ git gc --aggressive
> > > error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
> > > error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
>
> /me is pretty git dumb, but is there some way to figure out the parents
> or children of these? I just trolled through all of my directories
> doing git show and didn't get any hits. I guess I'll just clean up and
> start over....
Moving the reflog data aside (i.e. mv .git/logs .git/logs.bak) it seems
that d936ff8 is not referenced anymore.
I found the other one as follows:
First I tried
$ git rev-list --all --objects
This resulted in:
[...]
4f7911b0b0dbd187131a109cf00161a0c6a9d727 arch/x86
ea868257c1eabc31e0ea7941efa42b543978b3fa arch/x86/kvm
a0c11ead723956c667172a9f3fb6787684fe7ff5 arch/x86/kvm/paging_tmpl.h
b556b6aad8b1aacfecb1dd4a56dbd389674687b5 arch/x86/kvm/x86.c
68a9733ae3315d7e2bfec2037dfeee4db8a6f6a1 drivers
error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
fatal: bad tree object 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
Because of the way objects are enumerated, we can be pretty sure that
the bad tree object is referenced by the tree object 68a9733a
corresponding to drivers/. Let's verify that:
$ git ls-tree 68a9733a
100644 blob 00cf9553f74065291612b0971337f79995933a06 Kconfig
100644 blob c1bf41737936ab00be4a87563a0bb0638074785d Makefile
040000 tree d4e847de9bf2450842936582ea7cc6778413825b accessibility
040000 tree 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f acpi
[...]
Yep, we found it there. So the missing tree object corresponds to
drivers/acpi/. So to find the latest commit to which this particular
tree object is referenced by, we just need to look at the same rev-list
output above (piped into less is handy here) and scroll up until an
object with no name is found. This would usually be the first root tree
object referencing the named objects that follow. Here I get aafb68eb.
To be sure, let's list it so to confirm it really contains a reference
to the 68a9733a drivers tree:
$ git ls-tree aafb68eb
[...]
040000 tree 68a9733ae3315d7e2bfec2037dfeee4db8a6f6a1 drivers
[...]
So yes, we've got the right root tree object. Now finding the
corresponding commit should be easy:
$ git log --all --pretty=raw
Then within less, a search for aafb68eb brings us to this:
commit 2e765e9c87a337131aad3014f9a7e5e878c7d0a0
tree aafb68eb84f96c9ab5697c6e8d10d5006d1e7209
parent a2c2de42295b3ac29758f454a7072338e5555ca3
author Eric Paris <eparis@redhat.com> 1237233261 -0400
committer Eric Paris <eparis@redhat.com> 1237233261 -0400
refresh 64d34c511b1125d9efd2926e683e019f15dec5b4
So this is referenced by a commit that you made on the 1237233261th
second since January 1, 1970 i.e. 2009-03-16 19:54:21 +0000 which is
quite a while ago. Or given the nature of the commit log, this is
probably some stgit branch.
Note that the missing tree didn't necessarily appear with that commit.
Because of the recency ordering from rev-list, all we can say is that
this is the last commit on that particular branch to reference that
tree, but it might have been introduced in the repository way before
that point in time.
Now let's try to find out what branch(es) actually link(s) to this
commit:
$ git branch -a --contains 2e765e9c
This comes empty. This is because 'git branch' looks only in the
refs/heads/ and refs/remotes namespace (or only one of them without -a).
Scripting something around 'git for-each-ref' and 'git merge-base' could
be done, such as:
TARGET=2e765e9c87a337131aad3014f9a7e5e878c7d0a0
git for-each-ref refs/* |
while read sha1 type ref; do
if [ "$(git merge-base $sha1 $TARGET)" = "$TARGET" ]; then
echo "referenced by $type $ref"
fi
done
But this is slow, for the same reason as 'git reflog expire' above. But
letting it run for a while should give you at least one answer.
> > Of course, usage of alternates is recommended _only_ with repositories
> > that are stable, i.e. don't ever add repositories to
> > .git/objects/info/alternates if those repositories are rewinded/rebased
> > and/or branches in them are deleted/replaced. That could be a reason
> > why some objects are now missing from the repository using alternates.
>
> So I'm not sure how I did things wrong. my kernel-1 has those bunch of
> remotes. The linux-next remote, like I said, basically rebases to
> linus' tree, then merges 150 random branches. It tags that tree every
> day and I pull those tags. So I would never expect any objects from
> those remote trees to ever disappear.
Right.
> Now I created branches in kernel-1 and I certainly have done lots of
> things like so
>
> git checkout -b testing remotes/linux-next/master
> [edit]
> git commit -a
> git checkout -b testing1 remotes/linux-next/master
> git branch -D testing
>
> My assumption though was that this wouldn't ever affect my other
> repositories. My other repository branches always started by checking
> out a branch with remotes/*/* as the base.
>
> My understanding was that I would only run into problems if I used
> something on a branch I created myself in the alternatives repo in other
> repos (and I didn't remove remotes)
>
> I guess it's not impossible to believe that at some point in time i
> would have exported patches to and mbox from kernel-1 and applied them
> to kernel-2 or vice versa. I guess this would end up with the same
> objects, right? Then if I deleted the branch in kernel-1 I would have
> problems in kernel-2?
Eventually, yes. After a while the auto repack in kernel2 would notice
that some objects are in kernel1 already and purge them from kernel2.
And if those objects were part of a deleted branch then kernel1 would
get rid of those objects too once the reflog with a reference to that
deleted branch expires. The unsuspecting kernel2 repo then gets broken.
> I guess I'll rebuild my setup
>
> new kernel-alt has just the remotes, and my kernel-1,2,3 all alt to it
> I'll never have local branches in my kernel-alt
> I'll run git-gc every night
> I'll hope to never have problem again.
>
> Sound good?
Yes. And make sure not to fetch rebasing repositories, such as
linux-next, into kernel-alt without keeping a tag for each fetched state
otherwise you'll accumulate unreferenced objects which the other
repositories might rely upon.
Nicolas
^ permalink raw reply
* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: Robin Rosenberg @ 2009-12-17 7:00 UTC (permalink / raw)
To: David Antliff; +Cc: git
In-Reply-To: <loom.20091215T225528-115@post.gmane.org>
tisdag 15 december 2009 23:24:15 skrev David Antliff:
> I approached the Cygwin mailing list about this problem, and the package
> maintainer suggested I ask here as well, in case someone can shed some
> light on this.
>
> I am using git-1.6.4.2 (as part of Cygwin-1.7 beta) and I've observed some
> behaviour that seems wrong to me.
>
> When we deployed git on Cygwin, we decided to set core.autocrlf=true, as
> many of our users are working with DOS/Windows files (CRLF endings). Some
> users are using Linux and working on the same code. I'm not actually sure
> why we chose to use this setting - there's a lot of conflicting advice
> around. I think the final decision was made so that kdiff3 would operate
> correctly. However we did go to lengths to ensure that everyone is using
> the same configuration setting.
>
> The problem is that sometimes, after a git-clone, the output of git-status
> and git-diff shows entire files as being different. However these files
> have not been modified by the user - only git has had a chance to change
> them (due to autocrlf=true). But surely if git has converted the file
> automatically, it should know that it has to compensate for this when
> comparing with the local repository?
AFAIK, this happens if you have CRLF line endings in the blobs in the repo.
-- robin
^ 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