* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-30 6:23 UTC (permalink / raw)
To: git
In-Reply-To: <76718491001292052x7f46d479lfeff7b66121502c3@mail.gmail.com>
In article
<76718491001292052x7f46d479lfeff7b66121502c3@mail.gmail.com>,
Jay Soffian <jaysoffian@gmail.com> wrote:
> On Fri, Jan 29, 2010 at 9:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Ron Garret <ron1@flownet.com> writes:
> >
> >> 1. The term "detached HEAD" is inherently misleading. A detached HEAD
> >> isn't detached from anything, it's just pointing to the middle of a
> >> branch, which is to say, to a commit that happens to already have
> >> descendants. For that matter, the name HEAD is itself misleading, since
> >> HEAD need not be the head of a branch (though normally it is). A better
> >> name for HEAD would have been CURRENT or ACTIVE. I recognize it's
> >> probably too late to change it now.
> >
> > This description, especially the phrase "middle of a branch" shows that
> > you don't understand git yet. A git branch is _not_ a line (nor multiple
> > lines) of development. It is merely a _point_ in the history.
> >
> > "A commit that is in the middle of an ancestry chain with existing
> > descendants" can be at the tip of a branch and does not have anything to
> > do with detached HEAD state.
> >
> > When HEAD points at a branch, making a commit advances _that_ branch. And
> > we say you are "on that branch". When HEAD is detached, because it is not
> > attached to anything, it advances no branch. "detached HEAD" is detached
> > in the very real sense. It is not attached to _any_ branch.
>
> Let me try wording this slightly different, because I think I can see
> Ron's confusion.
[snip]
> So that was a really long explanation, but I hope it clears things up.
Yes, that was very helpful, thank you.
Might it make more sense to talk about "anonymous branches" or "unnamed
branches" instead of "detached heads"? I think something like the
following would be much easier to grasp:
WARNING: Your HEAD is now pointing to a commit that is not a named
branch head. As a result of this, any commits off of this one may
be lost during the next garbage collection. If you want to prevent
this, you should give this branch head a name by doing ...
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-30 6:25 UTC (permalink / raw)
To: git
In-Reply-To: <7v1vh8417w.fsf@alter.siamese.dyndns.org>
In article <7v1vh8417w.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > Could you please take this really nice explanation and make it into a
> > patch adding a "Detached HEAD" section in the git-checkout.txt manual
> > page please?
>
> Good suggestion.
>
> I'd be happier if the description didn't say "SHA-1", but instead said
> "object name".
>
> Also it would be nicer (just a personal preference) if a picture that
> forks only one branch forks it upwards, like this:
>
> o---o
> /
> ---o---o---o
>
> not downwards, like this:
>
> ---o---o---o
> \
> o---o
Just out of curiosity, why does this matter to you? Downwards seems
more intuitive to me. Time should advance left to right and top to
bottom IMHO.
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-30 6:45 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-FA4289.22165129012010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> No, because it would make it much easier to map intent back into a
> command that implements that intent. Don't forget, this whole thing
> began because I wanted to do something very simple, tried what seemed to
> be the obvious way to do it, and stumbled accidentally on an advanced
> feature. That would not have happened if I'd been able to just do a git
> update --tree master^.
Doing that _will_ confuse you in your next step. Can you explain what
happens if you run "git commit" from that state, why "git commit" does so,
and how that is useful?
You may be too narrowly focused on only one single step, but I am more
worried about the whole user experience: "I managed to do this, I am
happy, but then the next step doesn't make much sense. Now what?"
> What difference does that make? Sure, there would be ways to shoot
> yourself in the foot with git update, but there is no shortage of ways
> to shoot yourself in the foot now.
As long as you have a coherent picture of the workflow individual commands
are supporting, there is no "shoot yourself in the foot". "git update" on
the other hand is _designed_ not to allow such a coherent picture to be
formed in the user's head, by letting random combinations that may or may
not make sense.
> BTW, nothing prevents you from providing the usual repertoire of
> higher-level functionality as thin layers on top of something like git
> update.
That is more or less the same as what I said in the footnote, which you
didn't quote from my message.
The flexibility of "update" may help Porcelain writers to pick and use
only useful/usable combinations to present "the usual repertoire" for end
users. At the philosophical level of "building blocks", I do not oppose
to such flexibility [*1*].
But.
As the main point of Michael's message was that he thought it may make
things less confusing to the end users, I am pointing out that unleashing
such an uncontrolled flexibility directly to end users will _not_ help
reduce their confusion.
[Footnote]
*1* As a set of "building blocks" to implement "reset" and "checkout", I
don't necessarily agree that "update" would be a good way to go from the
implementation standpoint, but that is a totally separate matter.
^ permalink raw reply
* Re: [PATCH v2] fast-import: Stream very large blobs directly to pack
From: Junio C Hamano @ 2010-01-30 7:17 UTC (permalink / raw)
To: gitzilla; +Cc: Shawn O. Pearce, git
In-Reply-To: <4B63691F.4000507@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Shawn O. Pearce wrote:
> ...
>> Implemented as core.bigFileThreshold in this patch... but I didn't
>> document it...
>
> Bad dog! No biscuit!
:-)
Patches welcome.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-30 7:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vaavw1478.fsf@alter.siamese.dyndns.org>
In article <7vaavw1478.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> Ron Garret <ron1@flownet.com> writes:
>
> > No, because it would make it much easier to map intent back into a
> > command that implements that intent. Don't forget, this whole thing
> > began because I wanted to do something very simple, tried what seemed to
> > be the obvious way to do it, and stumbled accidentally on an advanced
> > feature. That would not have happened if I'd been able to just do a git
> > update --tree master^.
>
> Doing that _will_ confuse you in your next step. Can you explain what
> happens if you run "git commit" from that state,
Nothing.
> why "git commit" does so,
Because my index would be empty.
> and how that is useful?
It wouldn't. Was this a trick question? Did you mean to ask what would
happen if I ran commit -a?
> You may be too narrowly focused on only one single step, but I am more
> worried about the whole user experience: "I managed to do this, I am
> happy, but then the next step doesn't make much sense. Now what?"
I think you may be making some unwarranted assumptions about my end goal.
> > What difference does that make? Sure, there would be ways to shoot
> > yourself in the foot with git update, but there is no shortage of ways
> > to shoot yourself in the foot now.
>
> As long as you have a coherent picture of the workflow individual commands
> are supporting, there is no "shoot yourself in the foot". "git update" on
> the other hand is _designed_ not to allow such a coherent picture to be
> formed in the user's head, by letting random combinations that may or may
> not make sense.
That is a valid point. I guess this depends on whether you think of git
as merely a revision control system for computer source code, or if you
think of it as a more general tool that can and should be used in other
kinds of applications as well.
> > BTW, nothing prevents you from providing the usual repertoire of
> > higher-level functionality as thin layers on top of something like git
> > update.
>
> That is more or less the same as what I said in the footnote, which you
> didn't quote from my message.
Yes, sorry about that.
> The flexibility of "update" may help Porcelain writers to pick and use
> only useful/usable combinations to present "the usual repertoire" for end
> users. At the philosophical level of "building blocks", I do not oppose
> to such flexibility [*1*].
>
> But.
>
> As the main point of Michael's message was that he thought it may make
> things less confusing to the end users, I am pointing out that unleashing
> such an uncontrolled flexibility directly to end users will _not_ help
> reduce their confusion.
>
> [Footnote]
>
> *1* As a set of "building blocks" to implement "reset" and "checkout", I
> don't necessarily agree that "update" would be a good way to go from the
> implementation standpoint, but that is a totally separate matter.
Did you mean "don't necessarily DISagree"?
rg
^ permalink raw reply
* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Junio C Hamano @ 2010-01-30 7:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sverre Rabbelier, git, Nicolas Pitre
In-Reply-To: <7vmxzw15dt.fsf@alter.siamese.dyndns.org>
I'll queued this with a result of my conflict resolution to 'pu' for now
but please double check after I push it out.
You may want to add the new option to the output from "cmd -h" and
probably description of the configuration in the doc before any of this
gets official.
^ permalink raw reply
* Re: [PATCH v6] add --summary option to git-push and git-fetch
From: Ilari Liusvaara @ 2010-01-30 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Larry D'Anna, git, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <7vsk9oysds.fsf@alter.siamese.dyndns.org>
On Fri, Jan 29, 2010 at 11:16:31PM -0800, Junio C Hamano wrote:
> As I said in my review during the earlier rounds, I do not know if it is
> safe to use the flags and do the traversal inside this same process. You
> may be clearing the flags to protect your traversal (one per branch) from
> stepping on each other, but how would this affect the use of object flags
> in existing parts of the "push" machinery? Is the reasoning that even if
> push calls into traversal code and after it walked the commit ancestry for
> its own purpose, your addition will clear the flags and existing code will
> never look at object flags again, so this new code is free to use them and
> all is Ok? As long as you made sure that nobody looks at object flags you
> modified, then I am fine with that---I just don't know if that is what is
> happening here, and that is why I am asking.
>
> I'd need help from the usual "transport" suspects for this patch.
Well, I can say smart transports implemented by remote helpers are similar
to ssh://&co (no surprise, they connect differently, but use the same underlying
client code). Furthermore, actual remote helper stub code doesn't seem to play
with revisions.
And the actual remote helper parts seem to use clean memory image anyway
(they exec).
So that leaves the following:
- git:// "layer 7" (git://, ssh://, file:// & co.[*])
- rsync:// (third-class anyway)
Also, what about multiple-URL case? Don't know if there are problems, but it
seems to be quite rarely tested...
[*] OTOH, this is extremely heavily used code, so breakages here will usually
be pretty visible.
-Ilari
^ permalink raw reply
* Re: [PATCH] builtin-name-rev.c: remove the remaining "typedef struct rev_name" from git.
From: Stephen Boyd @ 2010-01-30 7:53 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <8678db190a73997c7bd757b9d78f0fa9e8721055.1264815015.git.tfransosi@gmail.com>
On 01/29/2010 05:32 PM, Thiago Farina wrote:
> @@ -43,7 +43,7 @@ static void name_rev(struct commit *commit,
> }
>
> if (name == NULL) {
> - name = xmalloc(sizeof(rev_name));
> + name = xmalloc(sizeof(struct rev_name));
How about sizeof(*name) instead? This way we don't have to change it
when the type changes again.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-30 8:02 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-0D3105.23314829012010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> It wouldn't. Was this a trick question? Did you mean to ask what would
> happen if I ran commit -a?
I didn't mean _literally_ "git commit". Any random thing you may want to
do when you come back to work the next day and find a checked out work
tree. Viewing, editing, committing, etc.
>> *1* As a set of "building blocks" to implement "reset" and "checkout", I
>> don't necessarily agree that "update" would be a good way to go from the
>> implementation standpoint, but that is a totally separate matter.
>
> Did you mean "don't necessarily DISagree"?
I have huge doubts that "update" is the best way to do reset/checkout.
^ permalink raw reply
* Re: [PATCH v6] add --summary option to git-push and git-fetch
From: Junio C Hamano @ 2010-01-30 8:04 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Larry D'Anna, git, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <20100130075129.GA27702@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Also, what about multiple-URL case? Don't know if there are problems, but it
> seems to be quite rarely tested...
Pushing to more than one deliberately chooses to fork for each remote IIRC
to avoid any funnies.
> [*] OTOH, this is extremely heavily used code, so breakages here will usually
> be pretty visible.
I'd actually like to avoid anybody being hit.
Thanks for a quick response.
^ permalink raw reply
* My use case
From: Ron Garret @ 2010-01-30 8:26 UTC (permalink / raw)
To: git
My recent question about checking out an upstream commit (and ending up
as a result on a detached head) has generated a lot of discussion and
useful information. I thought I'd describe what I'm actually up to
because someone might have some ideas on how to do it better.
I'm trying to integrate git into a Lisp IDE (Clozure Common Lisp).
Because it's Lisp, code is often developed incrementally and
experimentally. This has two important consequences. First, the files
in your working directory can and often do, as part of the normal course
of events, get into an incoherent state. Everything in your running
Lisp image is working just fine, but if you try to recompile your entire
system something will break, and you can go for a very long time without
discovering that this has happened. Second, development can often lead
to dead-ends where you want to throw everything you've just done away,
go back to some earlier version of *some but not all* of your code, and
start over.
In other words, it is not uncommon to want to roll back an individual
file or set of files to an earlier version and leave the rest of the
tree alone. git can do this, but it's not straightforward. Simply
rolling back through the history of the current branch doesn't work
because you might want to roll back file A, but the last dozen revisions
or so have been changes to file B. You might also want to roll both A
and B back to states which never co-existed in the original history.
One approach is to use git rev-list to find those commits where
particular files changed, but this is sub-optimal for several reasons.
First, a naive approach calls rev-list for every rollback, and rev-list
has to traverse the entire history, so it's very inefficient. Second,
if you roll back a single file, git doesn't keep track of that file's
provenance, so you have to manually track which files and have been
rolled back and which revisions they have been rolled back to. (There
was a third problem but I can't think what it was right now.)
I have this intuition that git can be made to really do this right by
keeping a separate history of every individual file in addition to a
history of the entire source tree. Git can't do this directly as far as
I know. I'd be writing additional code to generate extra tree and
commit objects every time a file was saved from the IDE. But turning
this intuition into reality is turning out to be quite challenging. So
I'm going with the rev-list approach for the first version despite its
shortcomings.
If anyone has ideas or suggestions, feedback would be much appreciated.
But this is mostly just FYI.
rg
^ permalink raw reply
* Re: My use case
From: Edward Z. Yang @ 2010-01-30 8:47 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-09825C.00261930012010@news.gmane.org>
Excerpts from Ron Garret's message of Sat Jan 30 03:26:19 -0500 2010:
> In other words, it is not uncommon to want to roll back an individual
> file or set of files to an earlier version and leave the rest of the
> tree alone. git can do this, but it's not straightforward. Simply
> rolling back through the history of the current branch doesn't work
> because you might want to roll back file A, but the last dozen revisions
> or so have been changes to file B. You might also want to roll both A
> and B back to states which never co-existed in the original history.
>
> One approach is to use git rev-list to find those commits where
> particular files changed, but this is sub-optimal for several reasons.
> First, a naive approach calls rev-list for every rollback, and rev-list
> has to traverse the entire history, so it's very inefficient. Second,
> if you roll back a single file, git doesn't keep track of that file's
> provenance, so you have to manually track which files and have been
> rolled back and which revisions they have been rolled back to. (There
> was a third problem but I can't think what it was right now.)
My approach, in this case, would be to use git log, possibly git log -p,
in order to view the changes in each file you were interested in rolling
back. If the rollback falls on a commit boundary, great; you can use
`git checkout rev -- path`. If not, you can perform that, and then
use git checkout -p to selectively revert hunks in the patch (fundamentally,
you can't really get better than that).
> I have this intuition that git can be made to really do this right by
> keeping a separate history of every individual file in addition to a
> history of the entire source tree. Git can't do this directly as far as
> I know. I'd be writing additional code to generate extra tree and
> commit objects every time a file was saved from the IDE. But turning
> this intuition into reality is turning out to be quite challenging. So
> I'm going with the rev-list approach for the first version despite its
> shortcomings.
While Git's ability to look at individual file's history is "slower", it's still
quite excellent, and you are encouraged to use it as necessary.
Slightly relatedly, I'd recommend flushing to disk and committing more
often. It's great that the LISP REPL allows for more daring changes,
but having a history either way is very helpful!
Cheers,
Edward
^ permalink raw reply
* Re: My use case
From: Ron Garret @ 2010-01-30 8:54 UTC (permalink / raw)
To: git
In-Reply-To: <1264840729-sup-5264@ezyang>
In article <1264840729-sup-5264@ezyang>,
"Edward Z. Yang" <ezyang@MIT.EDU> wrote:
> Excerpts from Ron Garret's message of Sat Jan 30 03:26:19 -0500 2010:
> > In other words, it is not uncommon to want to roll back an individual
> > file or set of files to an earlier version and leave the rest of the
> > tree alone. git can do this, but it's not straightforward. Simply
> > rolling back through the history of the current branch doesn't work
> > because you might want to roll back file A, but the last dozen revisions
> > or so have been changes to file B. You might also want to roll both A
> > and B back to states which never co-existed in the original history.
> >
> > One approach is to use git rev-list to find those commits where
> > particular files changed, but this is sub-optimal for several reasons.
> > First, a naive approach calls rev-list for every rollback, and rev-list
> > has to traverse the entire history, so it's very inefficient. Second,
> > if you roll back a single file, git doesn't keep track of that file's
> > provenance, so you have to manually track which files and have been
> > rolled back and which revisions they have been rolled back to. (There
> > was a third problem but I can't think what it was right now.)
>
> My approach, in this case, would be to use git log, possibly git log -p,
> in order to view the changes in each file you were interested in rolling
> back. If the rollback falls on a commit boundary, great; you can use
> `git checkout rev -- path`. If not, you can perform that, and then
> use git checkout -p to selectively revert hunks in the patch (fundamentally,
> you can't really get better than that).
Don't forget, I'm integrating this *into* the IDE, not just using it
*for* the IDE. So I want to just have a context menu on each code
window with "SNAPSHOT" and "ROLLBACK" items that Just Work. The casual
user won't even know that there's git behind the scenes.
> > I have this intuition that git can be made to really do this right by
> > keeping a separate history of every individual file in addition to a
> > history of the entire source tree. Git can't do this directly as far as
> > I know. I'd be writing additional code to generate extra tree and
> > commit objects every time a file was saved from the IDE. But turning
> > this intuition into reality is turning out to be quite challenging. So
> > I'm going with the rev-list approach for the first version despite its
> > shortcomings.
>
> While Git's ability to look at individual file's history is "slower", it's
> still
> quite excellent, and you are encouraged to use it as necessary.
Good to know.
> Slightly relatedly, I'd recommend flushing to disk and committing more
> often. It's great that the LISP REPL allows for more daring changes,
> but having a history either way is very helpful!
Yep! Save early, save often. I'm actually considering an auto-save
option where it takes a snapshot every time you evaluate a form after
making a change.
rg
^ permalink raw reply
* Re: [PATCH v6] add --summary option to git-push and git-fetch
From: Ilari Liusvaara @ 2010-01-30 8:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Larry D'Anna, git, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <7vd40sxbli.fsf@alter.siamese.dyndns.org>
On Sat, Jan 30, 2010 at 12:04:25AM -0800, Junio C Hamano wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> > Also, what about multiple-URL case? Don't know if there are problems, but it
> > seems to be quite rarely tested...
>
> Pushing to more than one deliberately chooses to fork for each remote IIRC
> to avoid any funnies.
I don't see any forking in the code. It redoes transport_get() (transports
can't really be reused...) and in the end does transport_disconnect().
And besides, what it did with internal protocol following remote helper
didn't look very much like what would happen if it forked...
-Ilari
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-30 8:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vhbq4xbok.fsf@alter.siamese.dyndns.org>
In article <7vhbq4xbok.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> Ron Garret <ron1@flownet.com> writes:
>
> > It wouldn't. Was this a trick question? Did you mean to ask what would
> > happen if I ran commit -a?
>
> I didn't mean _literally_ "git commit". Any random thing you may want to
> do when you come back to work the next day and find a checked out work
> tree. Viewing, editing, committing, etc.
Then I really don't understand the issue. I'd be in a situation that is
no different from (in fact indistinguishable from) having manually
edited my code so that it looks like an earlier checked-in version.
What's the problem?
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Jeff King @ 2010-01-30 8:59 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sverre Rabbelier, Junio C Hamano, Git List, Ron1, Jacob Helwig
In-Reply-To: <alpine.LFD.2.00.1001291641200.1681@xanadu.home>
On Fri, Jan 29, 2010 at 04:51:18PM -0500, Nicolas Pitre wrote:
> > Using a detached head is a more advanced feature than wanting to
> > checkout a remote branch locally, creating a local tracking branch. As
> > such, 'git checkout origin/topic' now means the same as 'git checkout
> > -t origin/topic', and you can get the old behavior back by doing 'git
> > checkout origin/topic^0'.
>
> What purpose does this "feature" serve? Making sure people remain
> stupid and get even more confused when the special dwimery doesn't work
> because they don't know the difference between a local branch and a
> remote tracking branch?
>
> And now people will be left wondering why after a fetch they don't get
> the latest stuff when they do "git checkout topic" again. Is this any
> better?
I am entering the discussion a bit late, and things have moved on from
this point, but I wanted to mention that I have in the past made the
same argument that you have in your second paragraph (that you leave
users _more_ confused after a fetch), but somebody (I think Jay) managed
to convince me otherwise.
The saving feature is that we now print out the symmetric difference
information between a branch and its upstream during checkout. So the
user experience looks like:
$ git checkout topic
Branch topic set up to track remote branch topic from origin.
Switched to a new branch 'topic'
... time passes ...
$ git fetch
...
9f137a4..22ac6a6 topic -> origin/topic
$ git checkout topic
Switched to branch 'topic'
Your branch is behind 'origin/topic' by 6 commits, and can be fast-forwarded.
So I think it is not quite as bad as at least I had originally thought.
There are still a few rough edges, though:
1. If I stay on the 'topic' branch and run "git fetch", then I don't
see the checkout message. If I don't understand that a local branch
has been created, I might expect the new changes to be present. But
they're not. If I do a pull instead, it does "just work", even if I
am clueless about the local branch.
I wonder if a "fetch" which updates the upstream branch of the
current HEAD should print something like the "Your branch is
behind..." message.
2. If I am clueless that the local branch exists, I can see that there
are new changes that I can "fast forward". But if I am clueless
about local branches, do I know that means I need to run "git merge
origin/topic"? However, I can't think of an improved message that
would make the situation clear without adding a bunch of annoying
text.
-Peff
^ permalink raw reply
* [RFH] rpm packaging failure
From: Junio C Hamano @ 2010-01-30 9:24 UTC (permalink / raw)
To: git; +Cc: Johan Herland
Subject: [PATCH] experimental RPM spec change
"make rpm" with recent 'master' fails with:
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/python2.6/site-packages/git_remote_helpers-0.1.0-py2.6.egg-info
/usr/lib/python2.6/site-packages/git_remote_helpers/__init__.py
/usr/lib/python2.6/site-packages/git_remote_helpers/__init__.pyc
/usr/lib/python2.6/site-packages/git_remote_helpers/git/__init__.py
/usr/lib/python2.6/site-packages/git_remote_helpers/git/__init__.pyc
/usr/lib/python2.6/site-packages/git_remote_helpers/git/git.py
/usr/lib/python2.6/site-packages/git_remote_helpers/git/git.pyc
/usr/lib/python2.6/site-packages/git_remote_helpers/util.py
/usr/lib/python2.6/site-packages/git_remote_helpers/util.pyc
Here is an attempt to fix it, but help is very appreciated, as I don't
know what the accepted way is to ship Python modules is in the RPM world.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git.spec.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index ab224f7..1aeba90 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -121,6 +121,7 @@ find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
(find $RPM_BUILD_ROOT%{perl_vendorlib} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
%if %{!?_without_docs:1}0
(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "archimport|svn|git-cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_libdir}/python* -type f | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
%else
rm -rf $RPM_BUILD_ROOT%{_mandir}
%endif
--
1.7.0.rc0
^ permalink raw reply related
* Re: [PATCH] Implement pthread_cond_broadcast on Windows
From: Johannes Sixt @ 2010-01-30 9:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Zoltán Füzesi, git, msysGit Mailinglist,
Dmitry Potapov, Andrzej K. Haczewski, Erik Faye-Lund
In-Reply-To: <alpine.DEB.1.00.1001300328070.3749@intel-tinevez-2-302>
On Samstag, 30. Januar 2010, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 30 Jan 2010, Johannes Sixt wrote:
> > See http://www.cse.wustl.edu/~schmidt/win32-cv-1.html, section "The
> > SignalObjectAndWait solution". But note that this implementation does not
> > use SignalObjectAndWait (which is needed to achieve fairness, but we do
> > not need fairness).
> >
> > Note that our implementations of pthread_cond_broadcast and
> > pthread_cond_signal require that they are invoked with the mutex held
> > that is used in the pthread_cond_wait calls.
> >
> > Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> > ---
> > Junio,
> >
> > please queue this patch for 1.7.0-rc1 even though it has not undergone
> > a lot of review - the result is better than a git that does not even
> > build on Windows.
>
> As you Cc:ed the msysGit list, do you want this in 4msysgit.git, too?
I hope some clever people on the msysgit list can say aye or nay to this
patch. If you intend to release an msysgit that contains 5b594f4 (Threaded
grep), then you need *something*, otherwise the build fails. Whether you get
that something via upstream or apply it directly is of course secondary, but
I prefer the former. ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH] Implement pthread_cond_broadcast on Windows
From: Johannes Schindelin @ 2010-01-30 10:50 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Zoltán Füzesi, git, msysGit Mailinglist,
Dmitry Potapov, Andrzej K. Haczewski, Erik Faye-Lund
In-Reply-To: <201001301030.36395.j6t@kdbg.org>
Hi,
On Sat, 30 Jan 2010, Johannes Sixt wrote:
> On Samstag, 30. Januar 2010, Johannes Schindelin wrote:
>
> > On Sat, 30 Jan 2010, Johannes Sixt wrote:
> > > See http://www.cse.wustl.edu/~schmidt/win32-cv-1.html, section "The
> > > SignalObjectAndWait solution". But note that this implementation
> > > does not use SignalObjectAndWait (which is needed to achieve
> > > fairness, but we do not need fairness).
> > >
> > > Note that our implementations of pthread_cond_broadcast and
> > > pthread_cond_signal require that they are invoked with the mutex
> > > held that is used in the pthread_cond_wait calls.
> > >
> > > Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> > > ---
> > > Junio,
> > >
> > > please queue this patch for 1.7.0-rc1 even though it has not
> > > undergone a lot of review - the result is better than a git that
> > > does not even build on Windows.
> >
> > As you Cc:ed the msysGit list, do you want this in 4msysgit.git, too?
>
> I hope some clever people on the msysgit list can say aye or nay to this
> patch. If you intend to release an msysgit that contains 5b594f4
> (Threaded grep), then you need *something*, otherwise the build fails.
> Whether you get that something via upstream or apply it directly is of
> course secondary, but I prefer the former. ;)
Okay, I will just merge mingw.git's master, then, once you say that the
fix is in.
Ciao,
Dscho
^ permalink raw reply
* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Jens Lehmann @ 2010-01-30 12:31 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <57518fd11001291646l5b0b581dm553689232b0910e8@mail.gmail.com>
Am 30.01.2010 01:46, schrieb Jonathan del Strother:
> On 29 January 2010 17:44, Junio C Hamano <gitster@pobox.com> wrote:
>> Jonathan del Strother <maillist@steelskies.com> writes:
>>
>>> Heya,
>>>
>>> git-stash in v1.7.0-rc0 gives me several hundred lines of :
>>> The previous build I was using -
>>> 5b15950ac414a8a2d4f5eb480712abcc9fe176d2 from Jan 19th - didn't show
>>> this problem. Want me to try and bisect further?
>>
>> Yes, please.
>>
>
> ee6fc514f2df821c2719cc49499a56ef2fb136b0 (Show submodules as modified
> when they contain a dirty work tree) seems to be the first bad commit.
Thanks for pinning that down.
I assume you have one or more submodules, maybe even with untracked
or yet uncommitted modified files in your tree? If so, what does git
status say in the superproject and in the submodule(s)?
(If you want to keep some information off the list, you can mail me
privately)
^ permalink raw reply
* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Jonathan del Strother @ 2010-01-30 13:23 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4B642696.2070501@web.de>
On 30 January 2010 12:31, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 30.01.2010 01:46, schrieb Jonathan del Strother:
>> On 29 January 2010 17:44, Junio C Hamano <gitster@pobox.com> wrote:
>>> Jonathan del Strother <maillist@steelskies.com> writes:
>>>
>>>> Heya,
>>>>
>>>> git-stash in v1.7.0-rc0 gives me several hundred lines of :
>>>> The previous build I was using -
>>>> 5b15950ac414a8a2d4f5eb480712abcc9fe176d2 from Jan 19th - didn't show
>>>> this problem. Want me to try and bisect further?
>>>
>>> Yes, please.
>>>
>>
>> ee6fc514f2df821c2719cc49499a56ef2fb136b0 (Show submodules as modified
>> when they contain a dirty work tree) seems to be the first bad commit.
>
> Thanks for pinning that down.
>
> I assume you have one or more submodules, maybe even with untracked
> or yet uncommitted modified files in your tree? If so, what does git
> status say in the superproject and in the submodule(s)?
>
Yep, I have 10 submodules. However, they're all completely clean with
no tracked or untracked changes shown in git status. Anything else I
can investigate?
^ permalink raw reply
* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Jens Lehmann @ 2010-01-30 14:10 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <57518fd11001300523xf7d931by254581c8494171af@mail.gmail.com>
Am 30.01.2010 14:23, schrieb Jonathan del Strother:
> On 30 January 2010 12:31, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> I assume you have one or more submodules, maybe even with untracked
>> or yet uncommitted modified files in your tree? If so, what does git
>> status say in the superproject and in the submodule(s)?
>
> Yep, I have 10 submodules. However, they're all completely clean with
> no tracked or untracked changes shown in git status. Anything else I
> can investigate?
The change in behavior my patch introduced is that "git status" is
called inside each submodule. So i would expect getting the same
errors when using this command:
git submodule foreach git status -s
It should just show
Entering '<submodule 1>'
Entering '<submodule 2>'
Entering '<submodule 3>'
Entering '<submodule 4>'
Entering '<submodule 5>'
Entering '<submodule 6>'
Entering '<submodule 7>'
Entering '<submodule 8>'
Entering '<submodule 9>'
Entering '<submodule 10>'
when the submodules are not dirty. What do you get?
The error message "error: unable to find <sha1>" is only generated in
sha1_loose_object_info() when map_sha1_file() fails. Its single caller
being sha1_object_info(), which is called by many git commands. Does
that ring a bell for somebody?
^ permalink raw reply
* Re: [RFH] rpm packaging failure
From: Todd Zullinger @ 2010-01-30 15:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland
In-Reply-To: <7v8wbgueqz.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Here is an attempt to fix it, but help is very appreciated, as I don't
> know what the accepted way is to ship Python modules is in the RPM world.
Perhaps this will work well. I only tested it on Fedora 10, but I
believe it should work on RHEL/CentOS and most other rpm-based
distros. We may well want to package the python bits in a subpackage,
much as the perl modules are. Anyone have thoughts on that?
-->8--
Subject: [PATCH] RPM spec: Package git_remote_helper python files
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
git.spec.in | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index ab224f7..575156c 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -1,4 +1,5 @@
# Pass --without docs to rpmbuild if you don't want the documentation
+%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
Name: git
Version: @@VERSION@@
@@ -9,6 +10,7 @@ Group: Development/Tools
URL: http://kernel.org/pub/software/scm/git/
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel, gettext %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
+BuildRequires: python
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl-Git = %{version}-%{release}
@@ -134,6 +136,7 @@ rm -rf $RPM_BUILD_ROOT
%doc README COPYING Documentation/*.txt
%{!?_without_docs: %doc Documentation/*.html Documentation/howto}
%{!?_without_docs: %doc Documentation/technical}
+%{python_sitelib}/*
%files svn
%defattr(-,root,root)
@@ -190,6 +193,9 @@ rm -rf $RPM_BUILD_ROOT
# No files for you!
%changelog
+* Sat Jan 30 2010 Todd Zullinger <tmz@pobox.com>
+- Include git_remote_helper python files
+
* Mon Feb 04 2009 David J. Mellor <dmellor@whistlingcat.com>
- fixed broken git help -w after renaming the git-core package to git.
--
1.6.6
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't hit a man when he's down -- kick him; it's easier.
^ permalink raw reply related
* [PATCH 2/3] grep: Fix two memory leaks
From: Dan McGee @ 2010-01-30 15:42 UTC (permalink / raw)
To: git; +Cc: Dan McGee
We duplicate the grep_opt structure when using grep threads, but didn't
later free either the patterns attached to this new structure or the
structure itself.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
Found these with valgrind.
-Dan
builtin-grep.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 9bd467c..0ef849c 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -205,6 +205,8 @@ static void *run(void *arg)
work_done(w);
}
+ free_grep_patterns(arg);
+ free(arg);
return (void*) (intptr_t) hit;
}
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH 2/3] grep: Fix two memory leaks
From: Dan McGee @ 2010-01-30 15:45 UTC (permalink / raw)
To: git
In-Reply-To: <1264866178-12048-1-git-send-email-dpmcgee@gmail.com>
On Sat, Jan 30, 2010 at 9:42 AM, Dan McGee <dpmcgee@gmail.com> wrote:
> We duplicate the grep_opt structure when using grep threads, but didn't
> later free either the patterns attached to this new structure or the
> structure itself.
>
> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
> ---
> Found these with valgrind.
Ignore the misleading numbers in the subject, there isn't more to see
here...whoops.
-Dan
^ 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