* 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: 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 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: 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: 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: 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 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: [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: 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: 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: [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: 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 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: [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: 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] 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: Where man git-format-patch sends me?
From: Sergei Organov @ 2007-11-02 11:25 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Johannes Schindelin, git
In-Reply-To: <2A9EA819-C27A-4538-A9ED-B5281D137B94@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> 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
Ah, thank you! Now, diff-format.txt is included by
git-diff-index/git-diff-files/git-diff-tree, but not by git-diff and
git-format-patch. Do you think it is the right thing for the latter two
to include diff-format as well?
--
Sergei.
^ 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 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7v7il13p1g.fsf@gitster.siamese.dyndns.org>
On Nov 2, 2007, at 11:44 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> - 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?
Yes. I would work exactly this way with current git.
> $ git clone $public my-work-dir
> $ cd my-work-dir
> $ git checkout -b --track foo origin/foo
So the implicit rule here is
"name a branch identical in all repositories you're dealing with"
right?
That is foo is named foo at the remote, named foo as a tracking
branch (git handles this automatically) and is named foo as your
local branch.
I believe it is reasonable. Though I have two questions:
1) If this is best practice, why doesn't save git me from typos?
Why do I need to type "foo" correctly twice?
2) What shall I do if I am dealing with more than one shared
repository? Andreas' group should already run into problems
here. They have several shared repos and if they want to
checkout several local branches from different repos they
need to somehow encode the name of the remote in the name
of the local branch.
> $ 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.
It does.
> With your "remote.$public.push = HEAD", the last step would be
> "git push" without any parameter.
Indeed. Or with my "branch.$name.push" it would just be "git push"
as well. And I'd be probably happy then.
> 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
I'd be more happy without 'or'. I really want to give a single
recommendation.
So the question here is: Should I branch off the local branch or
should I branch off the remote branch? When should I do what?
What is best practice and what is used for 'exceptional'
situations?
> $ 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 focuses testing on the integration of topic1 with topic2.
You could as well do the following
$ git checkout -b topic1 origin/foo
$ hack ...
$ git checkout -b topic2 origin/foo
$ hack ..
[ later ]
$ git checkout topic1
$ git pull # or git fetch; git rebase origin/foo
$ test test test
$ git push origin topic1:origin/foo
[ later ]
$ git checkout topic2
$ git pull # or git fetch; git rebase origin/foo
$ test test test
$ git push origin topic2:origin/foo
With my "branch.$name.push" it would just be "git push" here.
This workflow focuses testing on the integration of each of your
topics with the new changes on the shared branch independently
of your other topic.
You're done at this point. No need to merge a second time,
no need to reset branches.
It's probably a good idea to delete your local branches
now. And there is one minor question related to that: Where
to park your HEAD if you want to clean up _all_ of your local
branches because you have nothing left to do? Everything is
on the shared remote branch. The only thing you're interested
now is to checkout new changes from the shared branch if
interesting work was done by others.
> 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:
Or you could just pull
[ this continues Junio's example from above, you are on branch foo. ]
$ git pull
$ test test; # test of your integration of topic1, topic2
# with the new changes on the shared branch
$ git push
> $ git fetch
> $ git rebase origin/foo topic1
> $ git branch -f foo origin/foo
Here is another interesting point.
Would you recommend "git branch -f foo origin/foo" over
"git checkout foo; git reset --hard origin/foo"? I think the
first command is safer because it doesn't throw away uncommitted
changes. However it fails if you are already on branch foo. Then it
says "fatal: Cannot force update the current branch.". It is not
very intuitive if I'd ask users to first leave the branch they
want to modify, only to be able to use "git branch". "git reset"
always lets you achieve your goal. (BTW, I don't recommend having
local changes while doing integration testing ... but who knows
maybe someone feels comfortable with it.)
> $ git checkout foo
> $ git merge topic1
> $ git merge topic2
> $ test test test
> $ git push
Using rebase requires more commands than using pull, and more
intrusive commands like "branch -f" or "reset --hard" are involved.
That doesn't mean that you should not use rebase. But it certainly
needs more explanation.
Another related question is the following: After some time the
user decides that some help on topic1 would be appreciated and
another developer promises to help. So they agree to work on
a shared branch name topic1. The first developer starts with
$ git push origin topic1
From now on he _MUST NOT_ use rebase any longer! So starting
to work on the topic with a second developer completely changed
the best practice. From now no rebase is forbidden, which was
best practice before.
So the question for me is: do I want to teach developer a pull
or a rebase workflow first? Currently I believe pull will be
safer for them, better supported by git, and there will be
situations they must use pull. If the only nuisance are loops
in the history when viewing them in gitk, I'm happy to accept
this.
>> ... 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.
Yeah, I should have added some explanation here. I had Andreas'
200-local-branches and the topic1/topic2 example in mind that
does the integration against the shared branch.
Steffen
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: David Symonds @ 2007-11-02 11:50 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git, Brian Downing
In-Reply-To: <472AFFE4.9060004@op5.se>
On 11/2/07, Andreas Ericsson <ae@op5.se> wrote:
> 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.
Maybe cut straight to the chase:
[core]
whitespace.trailing = error
whitespace.space-before-tab = error
whitespace.8-spaces = warn
There'd be at least "error", "warn"; "okay" and "autofix" would be
other sensible values. I'm willing to help code this up if this sounds
good.
Dave.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Johannes Schindelin @ 2007-11-02 12:14 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <0C176853-8848-46C8-AD7A-97F73274DC29@wincent.com>
Hi,
On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
> Of course, it's too late too change now, but it would be nice if the
> mirror of "fetch" were "send". (I know it's been commented in the past
> that the fact that "push" and "pull" aren't mirror operations has
> surprised quite a few people.)
Could you please just do
git config --global alias.send push
and be done with it?
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: Jakub Narebski @ 2007-11-02 12:25 UTC (permalink / raw)
To: git
In-Reply-To: <ee77f5c20711020450hdfe064fsace9349fe6494ec9@mail.gmail.com>
David Symonds wrote:
> On 11/2/07, Andreas Ericsson <ae@op5.se> wrote:
>> 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.
>
> Maybe cut straight to the chase:
>
> [core]
> whitespace.trailing = error
> whitespace.space-before-tab = error
> whitespace.8-spaces = warn
>
> There'd be at least "error", "warn"; "okay" and "autofix" would be
> other sensible values. I'm willing to help code this up if this sounds
> good.
Nice idea, but the syntax is
[core "whitespace"]
trailing = error
space-before-tab = error
indent-with-space = warn
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Ping Yin @ 2007-11-02 11:53 UTC (permalink / raw)
To: git; +Cc: Ping Yin
git status/commit just treats submodules as ordinary files when reporting status
changes. However, one may also wonder how the submodules change.
This commit teaches git status/commit to also show commits of
modified submodules since HEAD (or HEAD^ if --amend option is on).
For example, when commiting, submodule sm1 and sm2 are both changed. sm1 has commit C in HEAD and
commit E in index. The history of sm1 is
--A-->B-->C (in HEAD:354cd45)
\
-->D->E (in index:3f751e5)
git status will give the following output (just output commits of submodules
before normal output) to show how to change from commit C (in HEAD) to commit
E (in index): backward ('<<<') to commit A, and then forward ('>>>') to commit
E.
#
# submodule modifiled: sm1 sm2
#
# * sm1 354cd45...3f751e5:
# <<<
# one line message for C
# one line message for B
# >>>
# one line message for D
# one line message for E
#
# * sm2 5c8bfb5...ac46d84:
# <<<
# msg
#
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: sm1
# modified: sm2
---
git-commit.sh | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..d362caa 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -33,6 +33,40 @@ save_index () {
cp -p "$THIS_INDEX" "$NEXT_INDEX"
}
+# Show log of modified submodule (index modification since HEAD or $1)
+show_module_log () {
+ modules=`git diff --cached --name-only $1 |
+ while read name
+ do
+ git ls-files --stage $name
+ done |
+ grep '^160000 ' | awk '{print $4}'`
+ test -z "$modules" && return
+
+ modules=$(echo $modules)
+ echo -e "#\n# submodule modifiled: $modules\n#"
+ for name in $modules
+ do
+ range=`git diff --cached -- $name | sed -n '2 p' | awk '{print $2}'`
+ indexone=${range#*..}
+ headone=${range%..*}
+ (
+ echo "* $name $headone...$indexone:"
+ cd $name >&/dev/null || { echo " Warning: fail to chdir to $name" && exit; }
+ left="`git log --pretty=oneline $indexone..$headone 2>&1 | sed 's/^\w\+ / \t/'`"
+ right="`git log --pretty=oneline --reverse $headone..$indexone 2>&1 | sed 's/^\w\+ / \t/'`"
+ if echo "$left$right" | grep 'unknown revision' >&/dev/null
+ then
+ echo " Warning: $name is not a repository or dosn't contains commit $headone/$indexone"
+ else
+ test -n "$left" && echo -e " <<<\n$left"
+ test -n "$right" && echo -e " >>>\n$right"
+ fi
+ echo
+ ) | sed 's/^/# /'
+ done
+}
+
run_status () {
# If TMP_INDEX is defined, that means we are doing
# "--only" partial commit, and that index file is used
@@ -55,6 +89,12 @@ run_status () {
else
color=--nocolor
fi
+ if test -z "$amend"
+ then
+ show_module_log
+ else
+ show_module_log "HEAD^"
+ fi
git runstatus ${color} \
${verbose:+--verbose} \
${amend:+--amend} \
--
1.5.3.4
^ permalink raw reply related
* Re: New features in gitk
From: Marco Costalba @ 2007-11-02 12:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, git
In-Reply-To: <18218.63946.772767.179841@cargo.ozlabs.ibm.com>
On 11/2/07, Paul Mackerras <paulus@samba.org> wrote:
>
> 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.
>
I have tried to overcome --topo-order in qgit but I found it very
difficult, too much for me.
Lazily drawing the layout it doesn't mean that you lazy load the data
from git, indeed you load all the git-log output as soon as it
arrives.
And if the revisions arrive "in order", i.e. if revision A arrive
before revision B it means that A is NOT an ancestor of B, this is of
great help.
When drawing the graph assuming that the vector/list of the arrived
sha is already ordered greatly simplify the whole thing, if we relax
this hypothesis then a lot of work should be done before to draw a
graph chunk, essentially the GUI tool needs to walk the _entire_ list
and reorder it by itself _before_ to draw any graph chunk also if very
small.
So at the end you end up transferring the complete revision walk from
git-log to the GUI tool, and (this is the important thing) to be sure
graph is always correct you need to perform the walk _before_ drawing
any stuff.
The only possible _trick_ I was able to find is to optimistically draw
the graph chunk _assuming_ that it is ordered.
Then reorder the list in the background and finally check if the graph
is correct, if not redraw with correct data.
If the out of order revisions are rare you end up mimic a fast correct
drawing. If are not user will see some flickering at the end of the
load.
IMHO the above scheme is very complicated and fragile.
Just my two cents.
Marco
^ 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 12:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Wincent Colaiuta, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711021213370.4362@racer.site>
On Nov 2, 2007, at 1:14 PM, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
>
>> Of course, it's too late too change now, but it would be nice if the
>> mirror of "fetch" were "send". (I know it's been commented in the
>> past
>> that the fact that "push" and "pull" aren't mirror operations has
>> surprised quite a few people.)
>
> Could you please just do
>
> git config --global alias.send push
>
> and be done with it?
This would certainly be the easiest. But I think the following
is probably more in line with Wincent's comment:
Makefile builds git-send instead of git-push
git config --global alias.push send
[ wait some time ]
git config --unset alias.push
The comment was about how to avoid surprises for people that
are new to git, not how to let long-time users have an alias
for push.
The _only_ real solution I see right now, is to stop the
discussion and leave "git push" as is. I strongly believe that
the git community in its majority will refuse to rename push;
though I have no evidence for this.
Steffen
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: David Symonds @ 2007-11-02 12:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fgf4qu$e8c$1@ger.gmane.org>
On 11/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Nice idea, but the syntax is
>
> [core "whitespace"]
> trailing = error
> space-before-tab = error
> indent-with-space = warn
Whoops, of course. My brain is a bit muddled tonight.
Dave.
^ 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