* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: David Symonds @ 2007-11-02 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Blake Ramsdell, git
In-Reply-To: <7vbqad3pjw.fsf@gitster.siamese.dyndns.org>
On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> "David Symonds" <dsymonds@gmail.com> writes:
>
> > Further, that comparison is going to fail as soon as the next revision
> > of Darwin (9.0.1, etc.) is released.
>
> Can we do something intelligent with $(shell iconv --version)
> there instead, I wonder, then?
It would probably be most appropriate for the autoconf script. Now
that I look at configure.ac, there's already a test for iconv in
there; is it not used?
Dave.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-02 11:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <472AF01F.9030002@op5.se>
Hi,
On Fri, 2 Nov 2007, Andreas Ericsson wrote:
> Linus Torvalds wrote:
> >
> > On Wed, 31 Oct 2007, Junio C Hamano wrote:
> > > * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
> > > + ...
> > >
> > > It appears 1.5.4 will be, to a certain extent, a "Let's clean up
> > > the internal implementation" release. This series should become
> > > part of it. Hopefully will merge to 'master' soon, but I
> > > haven't looked this series very closely yet.
> >
> > I certainly think this should go in, but it does make one deficiency
> > painfully clear: the remaining shell scripts end up having all the old
> > flags behaviour.
> >
> > So while you can combine flags for *most* programs, you still won't be able
> > to say things like
> >
> > git clean -qdx
> >
> > just because that's still a shellscript, and doing any fancy argument
> > parsing in shell is just painful.
> >
> > Is somebody still working on doing the shell->C conversion?
> >
>
> Me, although my git work is happening with the speed of continental drift
> at the moment.
>
> git-merge and git-pull are (slowly) being converted. It's more in the
> nature of a learning experience for me than "oh shit I need this fast"
> though. Hence the blazing speed with which I work ;-)
If you would share what you have on repo.or.cz, others could help at a
faster pace, instead of duplicating your work or waiting for you to
finish.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: Andreas Ericsson @ 2007-11-02 10:45 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, git, Brian Downing
In-Reply-To: <ee77f5c20711020314h43290dbs8141cb3905c867@mail.gmail.com>
David Symonds wrote:
> On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
>> This introduces core.whitespace configuration variable that lets
>> you specify the definition of "whitespace error".
>>
>> Currently there are two kinds of whitespace errors defined:
>>
>> * trailing-space: trailing whitespaces at the end of the line.
>>
>> * space-before-tab: a SP appears immediately before HT in the
>> indent part of the line.
>
>> [core]
>> whitespace = -trailing-space
>
> Could I suggest naming the option 'whitespaceError', so it's clearer
> that it's a negative setting?
>
Which would also open the window for "WhitespaceWarning" and "WhitespaceAutofix"
later on, using the same semantics. Personally, I'd like to get warnings for
non-tab-indent^H^H^H indent-with-non-tab (rename that option, perhaps?), autofix
for trailing-whitespace and errors for space-before-tab, with command-line
switch to override config settings.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-11-02 10:44 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Andreas Ericsson, git
In-Reply-To: <417C801B-5DFF-4753-AB32-0FA1EB30C8E2@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> - in a pull-oriented workflow (Linux kernel, git) ...
> ... There's maybe also less need to push to heads named
> differently on the local and the remote (though I'm not sure
> if this really true).
That's far from true but is irrelevant to the discussion of
supporting shared repositories better.
> - in a workflow that is base on shared branches (CVS-style),
> ...
> In addition push should push back to the remote branch a local
> topic was originally branched off.
Why? If it is shared, and if you are shooting for the simplest
set of commands, wouldn't you work this way?
$ git clone $public my-work-dir
$ cd my-work-dir
$ git checkout -b --track foo origin/foo
$ hack hack hack, commit, commit, commit *on* *foo*
$ git push $public foo
I think the recent git defaults to --track anyway so the third
step do not spell out --track.
With your "remote.$public.push = HEAD", the last step would be
"git push" without any parameter.
If you do use private topics, then the story would change this
way:
$ git checkout -b --track foo origin/foo
$ git checkout -b topic1 foo ;# or origin/foo
$ hack hack hack, commit, commit, commit on topic1
$ git checkout -b topic2 foo ;# or origin/foo
$ hack hack hack, commit, commit, commit on topic2
$ git checkout foo
$ git merge topic1
$ test test test; # test _your_ changes
$ git merge topic2
$ test test test; # test _your_ changes
$ git push ;# again push 'foo' out
This may fail to fast forward. You may at this time want to
"git fetch" first, rebase topic1 or topic2 that conflict with
the other side on top of updated origin/foo, rebuild foo and
push the result out, like this:
$ git fetch
$ git rebase origin/foo topic1
$ git branch -f foo origin/foo
$ git checkout foo
$ git merge topic1
$ git merge topic2
$ test test test
$ git push
> ... This makes the need for
> pushing to a branch named differently on the remote side more
> likely than in a pull-oriented workflow,
So I do not understand this remark.
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-11-02 10:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0711010815320.3342@woody.linux-foundation.org>
Linus Torvalds writes:
> If that's the only reason for using it, then please stop, and use
> "--first-parent" instead.
How would that help? That doesn't list about 2/3 of the commits at
all.
In any case, no that's not the only reason. The main reason is that
it (i.e. --topo-order) spits out the commits in exactly the order that
gitk wants to display them (of which the bit about parents coming
after all their children is a part), and thus reduces the amount of
processing I need to do in Tcl.
Paul.
^ permalink raw reply
* Re: [PATCH] post-update hook: update working copy
From: Andreas Ericsson @ 2007-11-02 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, git
In-Reply-To: <7vd4ut7948.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> writes:
>
>> Now that git-stash is available, it is not so unsafe to push to a
>> non-bare repository, but care needs to be taken to preserve any dirty
>> working copy or index state. This hook script does that, using
>> git-stash.
>
> Honestly, I am reluctant to do things that _encourages_ pushing
> into a live tree.
>
"Live" and "living" are perhaps two different things here. I for one have
something similar, but only for repositories residing on certain servers,
where there really must be zero local changes to the working tree.
> - Who guarantees that the reflog is enabled for the HEAD?
>
I disable reflogs on that server. There's (hardly ever) any human interaction
with the scripts in that repo, so I really, really don't care about reflogs.
> - Who guarantees that a human user is not actively editing the
> work tree files without saving?
There are times when one simply doesn't care.
I realize that for my situation, a much simpler script can (and is) used, so
I agree with your concerns. The idea that every git repo has a human hacking
on it isn't true though, so doing things like this are sometimes useful,
timesaving and a real help.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Junio C Hamano @ 2007-11-02 10:33 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, Blake Ramsdell, git
In-Reply-To: <ee77f5c20711020319l26b4a8c1r99576dc29ea504d8@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
>> Blake Ramsdell <blaker@gmail.com> writes:
>>
>> > Signed-off-by: Blake Ramsdell <blaker@gmail.com>
>> > ---
>> > Makefile | 4 +++-
>> > 1 files changed, 3 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/Makefile b/Makefile
>> > index 71479a2..5d83756 100644
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -401,7 +401,9 @@ endif
>> > ifeq ($(uname_S),Darwin)
>> > NEEDS_SSL_WITH_CRYPTO = YesPlease
>> > NEEDS_LIBICONV = YesPlease
>> > - OLD_ICONV = UnfortunatelyYes
>> > + ifneq ($(uname_R),9.0.0)
>> > + OLD_ICONV = UnfortunatelyYes
>> > + endif
>> > NO_STRLCPY = YesPlease
>> > NO_MEMMEM = YesPlease
>> > endif
>>
>> I do not have an access to a Darwin box, but do you mean 10.5
>> gives 9.0.0 as uname_R?
>
> Further, that comparison is going to fail as soon as the next revision
> of Darwin (9.0.1, etc.) is released.
Can we do something intelligent with $(shell iconv --version)
there instead, I wonder, then?
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Wincent Colaiuta @ 2007-11-02 10:26 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, git
In-Reply-To: <20071101214131.GF4099@lavos.net>
El 1/11/2007, a las 22:41, Brian Downing escribió:
> On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:
>> * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
>> - git-diff: complain about >=8 consecutive spaces in initial indent
>>
>> This is a counterpart of an earlier patch from J. Bruce Fields
>> to change "git-apply --whitespace" to make SP{8,} at the
>> beginning of line a whitespace error.
>>
>> Personally, I am in favor of the stricter check, but I had to
>> reject the "git-apply" patch because there was no way to disable
>> the additional check without disabling the existing check for
>> trailing whitespaces. We probably would want to revisit that
>> one (perhaps with a new option and/or config to selectively
>> enable different kinds of whitespace check).
>
> Just to throw in my two cents, I would be strongly opposed to this
> going in without some form of configuration to make it work for
> spaces-only-indent projects.
Ditto, I also work on some projects which have a spaces-only policy,
and the proposed change would be quite painful when working on those
projects, so configurability would be very important to me.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: David Symonds @ 2007-11-02 10:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Blake Ramsdell, git
In-Reply-To: <7v4pg55893.fsf@gitster.siamese.dyndns.org>
On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> Blake Ramsdell <blaker@gmail.com> writes:
>
> > Signed-off-by: Blake Ramsdell <blaker@gmail.com>
> > ---
> > Makefile | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 71479a2..5d83756 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -401,7 +401,9 @@ endif
> > ifeq ($(uname_S),Darwin)
> > NEEDS_SSL_WITH_CRYPTO = YesPlease
> > NEEDS_LIBICONV = YesPlease
> > - OLD_ICONV = UnfortunatelyYes
> > + ifneq ($(uname_R),9.0.0)
> > + OLD_ICONV = UnfortunatelyYes
> > + endif
> > NO_STRLCPY = YesPlease
> > NO_MEMMEM = YesPlease
> > endif
>
> I do not have an access to a Darwin box, but do you mean 10.5
> gives 9.0.0 as uname_R?
Further, that comparison is going to fail as soon as the next revision
of Darwin (9.0.1, etc.) is released.
Dave.
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: David Symonds @ 2007-11-02 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brian Downing
In-Reply-To: <7vwst15ceq.fsf@gitster.siamese.dyndns.org>
On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> This introduces core.whitespace configuration variable that lets
> you specify the definition of "whitespace error".
>
> Currently there are two kinds of whitespace errors defined:
>
> * trailing-space: trailing whitespaces at the end of the line.
>
> * space-before-tab: a SP appears immediately before HT in the
> indent part of the line.
> [core]
> whitespace = -trailing-space
Could I suggest naming the option 'whitespaceError', so it's clearer
that it's a negative setting?
Dave.
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: Andreas Ericsson @ 2007-11-02 10:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, Johannes Schindelin, Sergei Organov, git
In-Reply-To: <7v8x5hbtvv.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
>> On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:
>>> They are rare events. In your case I guess that subtly different versions
>>> were _actually_ applied (such as white space fixes),
>> That's actually pretty common, in my experience.
>>
>>> which is why such a rare event hit you.
>> I'm using git to track some changes I submitted to a project that's
>> mainly text, and that I only get release tarballs of. On my most recent
>> rebase all my patches got applied, but the text also got re-wrapped and
>> re-indented at the same time. So all but I think one or two of a dozen
>> patches ended up with a conflict resolution and then --skip.
>>
>> Which may not be a case git's really intended for--fair enough. But
>> I've found it's pretty common in my kernel work too. Either I'm
>> rebasing against changes I made myself, or else a maintainer took my
>> changes but fixed up some minor style problems along the way.
>
> Ok, so I retract that "rare" comment.
>
> Now, we have established that this is a real problem worth
> solving, what's next?
Make "git rebase --skip" skip patches regardless of tree and index state,
but still refuse to *start* with dirty tree or index. That way, there's
no risk of losing anything that can't be re-created unless the user asks
for it.
To be really anal, stash the current mess somewhere, re-apply the same
patch and diff the two states. If they're identical, do "git reset --hard"
and hop to next patch in rebase-series. If they're not, ask user to say
"--force-skip" instead.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-02 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vk5p15bkv.fsf@gitster.siamese.dyndns.org>
On Nov 2, 2007, at 8:52 AM, Junio C Hamano wrote:
> ... it still holds that what the developer wants to do is not
> just "to push", but "to push after making sure what he is going
> to push is in a good enough shape to be pushed". Your _workflow_
> is forcing to integrate right away before pushing; don't blame
> git for this.
I don't blame git for forcing the developers to merge. I blame
git for not supporting this workflow well enough.
I still believe that
- in a pull-oriented workflow (Linux kernel, git) there's less
need to handle unexpected changes on the remote you want to
push to. There's maybe also less need to push to heads named
differently on the local and the remote (though I'm not sure
if this really true).
- in a workflow that is base on shared branches (CVS-style),
the remote heads certainly will advance unexpectedly, and
git push should support developers to cope with this situation.
In addition push should push back to the remote branch a local
topic was originally branched off. This makes the need for
pushing to a branch named differently on the remote side more
likely than in a pull-oriented workflow, where you would
publish under your local branch name and ask someone else
to pull.
[...]
>
>> We haven't figured out much more of our workflow. The first
>> milestone is to migrate from CVS to git continuing to use a
>> CVS-style workflow.
>
> I think that is an interesting admission. As somebody else on
> the thread already said, if you are sticking to CVS workflow,
> there are things that can and cannot be naturally done with
> git. Don't break git when you hit the situation in the latter
> category without understanding how the world works.
Fair enough. I absolutely agree that it will never be a design
goal of git to directly support a CVS workflow ;)
But I strongly believe that there is a more universal question
behind. It makes sense to have good support for a workflow
that is based on a shared repository. A shared repository
can be a way
- to make it easy for the average developer to get started.
Only clone to a local working repository is needed, but no
publishing repository.
- to facilitate that commits will be pushed to at a central
place. The default is to push back to the shared repository
(btw, it's easy to setup hooks to do some access control to
avoid havoc). This may increase visibility of changes. It may
help doing backups. It may be easy to encourage early integration.
For small projects with developers available for direct
communication it may even be an option to have just this single
shared branch.
For larger project a better infrastructure and more control
over the changes is certainly a good idea. And git greatly
supports more complex workflows. That's the main reason why
I decided to choose git in the first place.
But for me the question is how can git be efficiently used to
support a workflow based on a shared repository. It should be
easy and safe to use and only few commands should be needed
to get started.
>> error: remote 'refs/heads/master' is ahead of local 'refs/heads/
>> master'. Use --verbose for more details.
>
> I'd rather have "Read section XXX of the user's guide".
Ok; do I need to write the section first or is there? ;)
And maybe we could do two things (at least for msysgit):
- Rename or link user-manual.html to git-user-manual.html,
which would allow saying "git help user-manual".
- Support HTML anchors, such that
"git help user-manual#section5" would open the user manual
and jump to the right section.
Steffen
^ permalink raw reply
* Re: Where man git-format-patch sends me?
From: Wincent Colaiuta @ 2007-11-02 10:03 UTC (permalink / raw)
To: Sergei Organov; +Cc: Johannes Schindelin, git
In-Reply-To: <877il22cip.fsf@osv.gnss.ru>
El 1/11/2007, a las 16:47, Sergei Organov escribió:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Hi,
>>
>> On Thu, 1 Nov 2007, Sergei Organov wrote:
>>
>>> $ man git-format-patch
>>> [...]
>>> OPTIONS
>>> -p Generate patch (see section on generating patches)
>>>
>>> -u Synonym for "-p".
>>
>> As you can easily see from Documentation/git-format-patch.txt, this
>> part
>> is generated from the file Documentation/diff-options.txt.
>
> Sorry, I did saw that, but it doesn't change anything.
>
> 1. As a user reading man git-format-patch, where do I find this
> "section
> on generating patches"? In another man-page? In the html
> documentation? On the moon?
>
> 2. I can't find "section on generating patches" in the man git-diff
> either, and I did say this in the part of my original message you've
> snipped.
>
> So the main question remains: could you please point me to the exact
> place in 'Documentation/' directory where this "section on generating
> patches" resides?
I believe the section in question is in Documentation/diff-format.txt
But you've basically found a documentation bug. Someone invoking "man
git-format-patch" shouldn't be expected to have to grep the source
tree in order to find out where the referenced documentation is.
Especially given that he/she may not even have the source.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-02 10:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <3550D197-CA8C-4B06-9A95-3C7F18EBEFA7@zib.de>
Steffen Prohaska wrote:
>
> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>
>>
>> It's easier to bisect. If git bisect lands you on a merge-commit,
>> you need to start a new bisect for each of the parents included
>> in the merge. Hopefully the nature of the merge gives a clue so
>> the user can make an educated guess as to which parent introduced
>> the bogus commit, but for an "evil octopus" (unusual) or if the
>> merge had conflicts which were resolved in a buggy way (not
>> exactly uncommon), it can be quite a hassle to get things right.
>> With a mostly linear history, this problem goes away.
>
> This is really an interesting point. I did not start to use
> git bisect regularly. But I certainly plan to do so in the future.
>
> Couldn't bisect learn to better cope with non-linear history?
>
Perhaps it could, but it's far from trivial. I started hacking on
a wrapper for git-bisect which would do just that, but gave up
rather quickly as the book-keeping required to remember each and
every parent-point tried just got out of hand, and it *still*
wouldn't run in full automatic. It broke down because I also
wanted merges on non-first-line parents to be delved into. If
that didn't happen, I wouldn't *know* the bisect would run fine
without me watching it, so then it was as useless as if I'd have
had to sit there the entire time anyway.
>
> BTW, what do you thing about the proposal to add branch.$name.push [1]?
>
> [1] http://marc.info/?l=git&m=119384331712996&w=2
>
I'm not so sure about it. I rather liked the "don't warn if local is
strict subset of remote" thing though. I teach our devs to just
ignore that warning, but with the same leaden feeling in my stomach
that someone, sometime, is going to get bit by it. It's worked so
far though, perhaps because our update-hook contains a check meaning
I'm the only one allowed to do "git-push --force".
>>
>> Except that it doesn't work unless you either detach the HEAD
>> (which prints a big fat ugly message) or give it -D to force
>> it, which I really, really don't recommend. We use git because
>> I'm pretty confident in its capabilities of never ever losing
>> anything. Using the seemingly harmless -D switch to git-branch
>> puts us at risk of wiping history quite without noticing.
>
> I don't like -D either. I liked the idea mentioned recently
> to check -d against the remotes. If a remote tracking branch
> has the history it should be considered fully merged.
>
Yes. Since remote branches are considered when prune'ing anyway,
and the git-branch -d warning is there to make sure we don't
accidentally lose any tip pointers, it should be safe to use
*all* "named" refs when checking for git-branch -d's sake (that
is, everything under refs/{heads,remotes,tags}/**/*).
> Another idea may be to distinguish between detached head and
> checkout of remote tracking branch. Maybe we could do some
> useful things if get knew that the user is 'on a remote tracking
> branch'. Committing could be forbidden.
Committing nearly *has* to be forbidden.
> A suggestion would be
> printed instead to use "git checkout -b something", which could act
> as if the remote branch was mentioned on the command line.
>
> Something like that would be needed before I'd seriously
> suggest to delete local branches after you finished your work.
>
Yup. I'll never suggest using "git branch -D" to my co-workers. Sooner
or later there'll be cries of anguish echoing throughout the office
when that happens ;-)
>
>
>>> Independently of what the best practice is, leaving the local
>>> work branch there shouldn't do any harm because I'm sure that
>>> some devs will forget to clean up, independently of what I tell
>>> them.
>>
>> I wholeheartedly agree with this one.
>
> So I think we need to resolve this first.
>
> Do you already have post-checkout script that makes useful
> suggestions. I remember you mentioned something like that
> during the 200-local-branches discussion.
>
No. Junio suggested I'd implement it as a post-checkout hook, but it
would only save me one command and could cause confusion as diff
output would change depending on whether one has checked out the
one branch or another prior to running git diff, so I decided against
it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Mike Hommey @ 2007-11-02 9:45 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list
In-Reply-To: <B858412A-853A-4660-BA4B-F9751E4AAEAE@lrde.epita.fr>
On Fri, Nov 02, 2007 at 10:39:35AM +0100, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> On Nov 2, 2007, at 10:30 AM, Mike Hommey wrote:
>
> >On Fri, Nov 02, 2007 at 02:03:52AM -0700, Junio C Hamano
> ><gitster@pobox.com> wrote:
> >>Blake Ramsdell <blaker@gmail.com> writes:
> >>
> >>>Signed-off-by: Blake Ramsdell <blaker@gmail.com>
> >>>---
> >>> Makefile | 4 +++-
> >>> 1 files changed, 3 insertions(+), 1 deletions(-)
> >>>
> >>>diff --git a/Makefile b/Makefile
> >>>index 71479a2..5d83756 100644
> >>>--- a/Makefile
> >>>+++ b/Makefile
> >>>@@ -401,7 +401,9 @@ endif
> >>> ifeq ($(uname_S),Darwin)
> >>> NEEDS_SSL_WITH_CRYPTO = YesPlease
> >>> NEEDS_LIBICONV = YesPlease
> >>>- OLD_ICONV = UnfortunatelyYes
> >>>+ ifneq ($(uname_R),9.0.0)
> >>>+ OLD_ICONV = UnfortunatelyYes
> >>>+ endif
> >>> NO_STRLCPY = YesPlease
> >>> NO_MEMMEM = YesPlease
> >>> endif
> >>
> >>I do not have an access to a Darwin box, but do you mean 10.5
> >>gives 9.0.0 as uname_R?
> >
> >Be it that or not, it looks wrong to me to check the Darwin version to
> >know what to use. Do you rely on the Linux kernel version to know
> >whether
> >iconv is present ?
>
> It's very different, on OSX you don't change your own kernel as you
> want, the kernel isn't a standalone component, it comes packaged with
> the entire system of MacOSX. When you do an update to 10.5 (aka
> Leopard) you will have a new version of iconv so you're guaranteed
> that someone with 10.5 has a system-wide iconv that is not OLD_ICONV.
The fact is you can also use Darwin without OSX...
Mike
^ permalink raw reply
* Re: [PATCH] Implement git commit as a builtin command.
From: Karl Hasselström @ 2007-11-02 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vsl3p3s48.fsf@gitster.siamese.dyndns.org>
On 2007-11-02 02:37:43 -0700, Junio C Hamano wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > I wonder if it would be such a bad idea to make this the default.
> > It seems like _everyone_ who should be using it forget it. And the
> > number of patches made for human or git consumption is probably
> > vastly larger than the number of patches made for consumption by
> > other tools.
>
> On this mailing list, we can pretty much assume that renaming diff
> can be applied by people. But outside world is a different story.
So I guess a prerequisite for this is to get git patch format support
into GNU patch, then? :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Benoit SIGOURE @ 2007-11-02 9:39 UTC (permalink / raw)
To: Mike Hommey; +Cc: git list
In-Reply-To: <20071102093028.GA29699@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
On Nov 2, 2007, at 10:30 AM, Mike Hommey wrote:
> On Fri, Nov 02, 2007 at 02:03:52AM -0700, Junio C Hamano
> <gitster@pobox.com> wrote:
>> Blake Ramsdell <blaker@gmail.com> writes:
>>
>>> Signed-off-by: Blake Ramsdell <blaker@gmail.com>
>>> ---
>>> Makefile | 4 +++-
>>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 71479a2..5d83756 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -401,7 +401,9 @@ endif
>>> ifeq ($(uname_S),Darwin)
>>> NEEDS_SSL_WITH_CRYPTO = YesPlease
>>> NEEDS_LIBICONV = YesPlease
>>> - OLD_ICONV = UnfortunatelyYes
>>> + ifneq ($(uname_R),9.0.0)
>>> + OLD_ICONV = UnfortunatelyYes
>>> + endif
>>> NO_STRLCPY = YesPlease
>>> NO_MEMMEM = YesPlease
>>> endif
>>
>> I do not have an access to a Darwin box, but do you mean 10.5
>> gives 9.0.0 as uname_R?
>
> Be it that or not, it looks wrong to me to check the Darwin version to
> know what to use. Do you rely on the Linux kernel version to know
> whether
> iconv is present ?
It's very different, on OSX you don't change your own kernel as you
want, the kernel isn't a standalone component, it comes packaged with
the entire system of MacOSX. When you do an update to 10.5 (aka
Leopard) you will have a new version of iconv so you're guaranteed
that someone with 10.5 has a system-wide iconv that is not OLD_ICONV.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-11-02 9:39 UTC (permalink / raw)
To: Pierre Habouzit, Junio C Hamano, Geert Bosch, Linus Torvalds, git
In-Reply-To: <20071101214257.GB7161@artemis.corp>
Pierre Habouzit wrote:
> On Thu, Nov 01, 2007 at 08:27:55PM +0000, Junio C Hamano wrote:
>> Geert Bosch <bosch@adacore.com> writes:
>>
>>> I often type "make clean" as well many "git xyz" commands
>>> during development, and so it happens that at times, I type
>>> "git clean" by accident.
>> Happened to me once. I hate that command.
>>
>>> So, I propose *not* converting git clean to a C builtin,
>>> but instead adding --untracked and --ignored options to
>>> git-rm.
>> I think what you are trying to do is to deprecate or remove "git
>> clean".
>>
>> I do not know where "git clean" came from. I am suspecting that
>> it was to give counterparts to some other SCMs, but do not know
>> which ones. Some people wanted to have it --- so you need to
>> convince them that it is a bad idea first. Adding an equivalent
>> options to "git rm" alone does not solve that issue.
>
> FWIW I do use git clean a _lot_. I don't mind if it's doable from
> another kind of command, but I do use git clean and even git clean -x a
> lot, because it achives cleansing my repository faster (and sometimes
> faster) than a `make distclean` would do.
>
I'm of two minds about this. On the one hand, it's incredibly useful to
clear out an imported repository where distlcean doesn't quite distclean.
We also use it for our autobuild tools (although that's just us being lazy).
On the other hand, I've been bit by the brain-bug once and done a git clean
when I really meant make clean.
Changing it to the wimpy 'rm -i' equivalent would reduce risk substantially
while maintaining its usefulness, so +1 to Junio's patch, I guess.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-11-02 9:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Wed, 31 Oct 2007, Junio C Hamano wrote:
>> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
>> + ...
>>
>> It appears 1.5.4 will be, to a certain extent, a "Let's clean up
>> the internal implementation" release. This series should become
>> part of it. Hopefully will merge to 'master' soon, but I
>> haven't looked this series very closely yet.
>
> I certainly think this should go in, but it does make one deficiency
> painfully clear: the remaining shell scripts end up having all the old
> flags behaviour.
>
> So while you can combine flags for *most* programs, you still won't
> be able to say things like
>
> git clean -qdx
>
> just because that's still a shellscript, and doing any fancy argument
> parsing in shell is just painful.
>
> Is somebody still working on doing the shell->C conversion?
>
Me, although my git work is happening with the speed of continental drift
at the moment.
git-merge and git-pull are (slowly) being converted. It's more in the
nature of a learning experience for me than "oh shit I need this fast"
though. Hence the blazing speed with which I work ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Implement git commit as a builtin command.
From: Junio C Hamano @ 2007-11-02 9:37 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jakub Narebski, git
In-Reply-To: <20071102092720.GA30468@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-11-01 21:14:45 +0100, Jakub Narebski wrote:
>
>> Kristian H?gsberg wrote:
>>
>> > Move git-commit.sh to contrib/examples.
>>
>> Just a note: you might want to use "git format-patch -M".
>
> I wonder if it would be such a bad idea to make this the default. It
> seems like _everyone_ who should be using it forget it. And the number
> of patches made for human or git consumption is probably vastly larger
> than the number of patches made for consumption by other tools.
On this mailing list, we can pretty much assume that renaming
diff can be applied by people. But outside world is a different
story.
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Mike Hommey @ 2007-11-02 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Blake Ramsdell, git
In-Reply-To: <7v4pg55893.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 02, 2007 at 02:03:52AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Blake Ramsdell <blaker@gmail.com> writes:
>
> > Signed-off-by: Blake Ramsdell <blaker@gmail.com>
> > ---
> > Makefile | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 71479a2..5d83756 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -401,7 +401,9 @@ endif
> > ifeq ($(uname_S),Darwin)
> > NEEDS_SSL_WITH_CRYPTO = YesPlease
> > NEEDS_LIBICONV = YesPlease
> > - OLD_ICONV = UnfortunatelyYes
> > + ifneq ($(uname_R),9.0.0)
> > + OLD_ICONV = UnfortunatelyYes
> > + endif
> > NO_STRLCPY = YesPlease
> > NO_MEMMEM = YesPlease
> > endif
>
> I do not have an access to a Darwin box, but do you mean 10.5
> gives 9.0.0 as uname_R?
Be it that or not, it looks wrong to me to check the Darwin version to
know what to use. Do you rely on the Linux kernel version to know whether
iconv is present ?
Mike
^ permalink raw reply
* Re: [PATCH] Implement git commit as a builtin command.
From: Karl Hasselström @ 2007-11-02 9:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fgdc3m$miq$1@ger.gmane.org>
On 2007-11-01 21:14:45 +0100, Jakub Narebski wrote:
> Kristian H?gsberg wrote:
>
> > Move git-commit.sh to contrib/examples.
>
> Just a note: you might want to use "git format-patch -M".
I wonder if it would be such a bad idea to make this the default. It
seems like _everyone_ who should be using it forget it. And the number
of patches made for human or git consumption is probably vastly larger
than the number of patches made for consumption by other tools.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stg branch --create test v2.6.24-rc1 doesn't work
From: Catalin Marinas @ 2007-11-02 9:24 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: kha, Git Mailing List
In-Reply-To: <cc723f590710260342t5fd0bdc3nc1ea5198cea1a604@mail.gmail.com>
On 26/10/2007, Aneesh Kumar <aneesh.kumar@gmail.com> wrote:
> $ stg branch --create test v2.6.24-rc1
> Checking for changes in the working directory ... done
> Don't know how to determine parent branch from "v2.6.24-rc1"
> Branch "test" created
[...]
> [test@linux-review-ext]$ stg import
> /home/opensource/patches/ext4-patch-queue/ext4_mballoc_freespace_accounting_fix.patch
> Checking for changes in the working directory ... done
> fatal: cebdeed27b068dcc3e7c311d7ec0d9c33b5138c2 is not a valid 'commit' object
> stg import: git-commit-tree failed with code 128
The problem is that a tag id is used as the head of the stack rather
than the corresponding commit id. I modified StGIT to get the commit
id (and, as I said, you can work around this in the meantime by
passing "v2.6.24-rc1^{commit}" to the branch command).
I'll push the changes tonight but I have to solve the branch deletion
as it is left in an inconsistent state after import (and --force
should be able to deal with it but it doesn't).
--
Catalin
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Blake Ramsdell @ 2007-11-02 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pg55893.fsf@gitster.siamese.dyndns.org>
On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> I do not have an access to a Darwin box, but do you mean 10.5
> gives 9.0.0 as uname_R?
Yeah, apparently that's how they roll.
~/Source/OpenSource/git$ uname -r
9.0.0
~/Source/OpenSource/git$ system_profiler SPSoftwareDataType
Software:
System Software Overview:
System Version: Mac OS X 10.5 (9A581)
Kernel Version: Darwin 9.0.0
Blake
--
Blake Ramsdell | http://www.blakeramsdell.com
^ permalink raw reply
* [PATCH] Mention that git-branch -M can cause problems for tracking branches
From: Jonas Fonseca @ 2007-11-02 9:17 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-branch.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
I made a patch to discard the overwritten branch's configuration
section, which Spearce felt was too lossy a behaviour. However, since
it confused me, I think it should at least be mentioned in the manpage.
Maybe the warning message from git should also be added to improve its
"googlability".
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 5e81aa4..def4e85 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -165,6 +165,11 @@ If you are creating a branch that you want to immediately checkout, it's
easier to use the git checkout command with its `-b` option to create
a branch and check it out with a single command.
+When a branch is renamed so that it overwrites an existing branch unintended
+problems can arise. This is because git refuses to discard the configuration
+section of the overwritten branch. As a result git can become confused if, for
+example, the branches involved were used for tracking two different remote
+branches. The only way to fix this is to edit the configuration file manually.
Author
------
--
1.5.3.4.1481.g854da-dirty
--
Jonas Fonseca
^ permalink raw reply related
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