* Re: merging .gitignore
From: Junio C Hamano @ 2007-10-03 19:38 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Johannes Schindelin, Andy Parkins, martin f krafft
In-Reply-To: <200710031506.23938.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Wednesday 03 October 2007, Johannes Schindelin wrote:
>> On Wed, 3 Oct 2007, Johan Herland wrote:
>> > - Teach the .gitignore parser to ignore conflict markers (i.e. regard them
>> > as comments)
>>
>> You might be delighted to know that in practice, it works already (because
>> you usually do not have a file named "<<<<<< blablub" or "======" or
>> ">>>>>> blablub"...
>
> I suspected so... ;)
Yeah, and that is one of the reasons why we made gitignore and
gitattributes one-entry-per-line format.
^ permalink raw reply
* Re: [PATCH] Add test case for ls-files --with-head
From: Junio C Hamano @ 2007-10-03 19:29 UTC (permalink / raw)
To: Carl Worth
Cc: Johannes Schindelin, Johannes Sixt, Keith Packard,
Git Mailing List
In-Reply-To: <87myv0qj2u.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Wed, 3 Oct 2007 16:36:13 +0100 (BST), Johannes Schindelin wrote:
>> Or as
>>
>> i=1
>> while test $i -le 50
>> do
> ...
>> i=$(($i+1))
>> done
>
> /me steps aside to let the shell-script wizards finish the job
I've already pushed out a rewritten one. Thanks.
The bug makes 1.5.3.3 a dud, and 1.5.3.4 owes credits to Keith
and you for fixing it.
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Sam Ravnborg @ 2007-10-03 19:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Wincent Colaiuta, git, msysgit
In-Reply-To: <Pine.LNX.4.64.0710031957170.28395@racer.site>
On Wed, Oct 03, 2007 at 07:57:48PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 3 Oct 2007, Sam Ravnborg wrote:
>
> > For a kernel integrated tool the dependencies shall be minimal which is
> > where asciidoc fails today.
>
> Is perl not too much already?
No - perl has not proved to be a problem.
But like git we have had a smaller share of docbook
incompatibilities.
We even require perl for a regular kernel build
for some arch's these days.
Sam
^ permalink raw reply
* Re: [PATCH] Add test case for ls-files --with-head
From: David Kastrup @ 2007-10-03 16:15 UTC (permalink / raw)
To: Carl Worth
Cc: Johannes Schindelin, Johannes Sixt, Junio C Hamano, Keith Packard,
Git Mailing List
In-Reply-To: <87myv0qj2u.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Wed, 3 Oct 2007 16:36:13 +0100 (BST), Johannes Schindelin wrote:
>> Or as
>>
>> i=1
>> while test $i -le 50
>> do
> ...
>> i=$(($i+1))
>> done
>
> /me steps aside to let the shell-script wizards finish the job
for i in {1,2,3,4,5}{0,1,2,3,4,5,6,7,8,9}
do
...
done
There is enough room for perversion in shell programming for everyone...
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Add test case for ls-files --with-head
From: David Kastrup @ 2007-10-03 15:52 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Carl Worth, Junio C Hamano, Keith Packard,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710031634300.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 3 Oct 2007, Johannes Sixt wrote:
>>
>> seq is not universally available. Can we have that as
>>
>> for i in 0 1 2 3 4; do
>> for j in 0 1 2 3 4 5 6 7 8 9; do
>> > sub/file-$i$j
>> echo file-$i$j >> expected
>> done
>> done
>
> Or as
>
> i=1
> while test $i -le 50
> do
> num=$(printf %04d $i)
> > sub/file-$num
> echo file-$num >> expected
> i=$(($i+1))
> done
>
> This version should be as portable,
Huh? It uses the conceivably-not-builtin "test" (something which
_you_ picked as something to complain about in a patch of mine where
it was not used in an inner loop) on every iteration, it uses printf
and it uses $((...)) arithmetic expansion. Whereas the proposal by
Johannes works fine even on prehistoric shell versions. So the "as
portable" enough moniker is surely weird.
> with the benefit that it is easier to change for different start and
> end values.
Correct. But why would we want those here?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-10-03 18:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0710031007340.3579@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 3 Oct 2007, Jeff King wrote:
>>
>> Try profiling the code, and you will see that the creation of the hashes
>> is totally dwarfed by the comparisons. So yes, you might be able to
>> speed up the creation code, but it's going to have a minimal impact on
>> the overall run time.
>
> Yeah. Oprofile is your friend.
Well, and if -Oprofile has no strong opinion, I'd let wc -l pitch in.
When we are not actually going to use the hash tables as hash tables,
why create them as such? If the first thing that actually looks at
the values of the hashes (except possibly for the optimization of not
storing the same hash twice in succession) is the sort, then there is
no code that can go out of whack when confronted with degenerate data.
Maybe it's not much of an optimization, but it certainly should be a
cleanup.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Johannes Schindelin @ 2007-10-03 18:57 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Junio C Hamano, Wincent Colaiuta, git, msysgit
In-Reply-To: <20071003174659.GA13691@uranus.ravnborg.org>
Hi,
On Wed, 3 Oct 2007, Sam Ravnborg wrote:
> For a kernel integrated tool the dependencies shall be minimal which is
> where asciidoc fails today.
Is perl not too much already?
Ciao,
Dscho
^ permalink raw reply
* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Johannes Schindelin @ 2007-10-03 18:55 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200710032042.14842.wielemak@science.uva.nl>
Hi,
On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> On Wednesday 03 October 2007 18:11, Johannes Schindelin wrote:
> > Hi,
> >
> > On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> > > 2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current
> > > HEAD of module
> >
> > AFAIR we do not allow committing via pserver protocol. Might that be
> > your problem?
>
> Thanks, but no. I'm using CVS over SSH. I've been looking around in
> git-cvsserver source a bit and it aborts quite quickly if you try a
> commit through pserver. I get a bit further, but it cannot find the HEAD
> revision for some reason and (from later message), if I try to checkout
> master instead of HEAD it finds the revision but I get a hash mismatch.
Okay, another stab: is your HEAD detached?
Ciao,
Dscho
^ permalink raw reply
* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Jan Wielemaker @ 2007-10-03 18:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710031711070.28395@racer.site>
Dscho,
On Wednesday 03 October 2007 18:11, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> > 2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current
> > HEAD of module
>
> AFAIR we do not allow committing via pserver protocol. Might that be your
> problem?
Thanks, but no. I'm using CVS over SSH. I've been looking around in
git-cvsserver source a bit and it aborts quite quickly if you try a
commit through pserver. I get a bit further, but it cannot find the HEAD
revision for some reason and (from later message), if I try to checkout
master instead of HEAD it finds the revision but I get a hash mismatch.
I've tried a bit debugging this, but in 15 years CVS experience I never
really needed to debug the protocol and my GIT experience is only 2
weeks old :-(
My hope is I'm doing something fundamentally wrong and git-cvsserver
just doesn't give a sensible error. I did setup the git repository using
two different routes, one adviced in the CVS conversion manual. GIT
operations work just fine, so does CVS checkout. I don't think you can
to that much wrong with cvs over ssh clients, especially if checkout
works just fine.
Does anyone out there has a working GIT <-> CVS+SHH setup? Based on
what version of GIT? Using what route to create the repository?
Thanks --- Jan
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-10-03 17:53 UTC (permalink / raw)
To: Jeff King; +Cc: David Kastrup, Git Mailing List
In-Reply-To: <20071003165927.GA25055@coredump.intra.peff.net>
On Wed, 3 Oct 2007, Jeff King wrote:
>
> Try profiling the code, and you will see that the creation of the hashes
> is totally dwarfed by the comparisons. So yes, you might be able to
> speed up the creation code, but it's going to have a minimal impact on
> the overall run time.
Yeah. Oprofile is your friend.
The biggest win would be to avoid calling diffcore_count_changes() in the
first place, and we actually do that in the caller by looking at the size
of the files. However, while that prunes out the *really* obvious cases,
it's not nearly enough, since there tends to be very limited filesizes
anyway.
What we could also do is to pass in the minimum similarity score, and use
that to at least exit early. We currently pass in "delta_limit" which is
close, but we never use it, and we really probably would be better off
passing in the minimum score itself and perhaps be able to exit early from
diffcore_count_changes.
However, while I did think about doing that, I came to the conclusion that
we'd still always end up having to look at least at *half* the hash data
(for the default 50% score), so while it would help, it again wouldn't be
a matter of orders-of-magnitudes, and it looked like the end result would
be unnecessarily complex too.
The best option, of course, would be to use a similarity hash to make the
initial choice. I think we had one at one point, but it wasn't
fine-grained enough. But it might be interesting to do that as a filter in
*front* of the more expensive diffcore_count_changes() call.
We had some "similarity fingerprint" code at some point using a Rabin
polynomial. It wasn't reliable enough to be used as a direct score, but
maybe it can be used as a first-line "we know this isn't even worth doing
the expensive stuff on".
Linus
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Sam Ravnborg @ 2007-10-03 17:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Wincent Colaiuta, David Kastrup, Johannes Schindelin, git,
msysgit
In-Reply-To: <7vd4vwfou9.fsf@gitster.siamese.dyndns.org>
Hi Junio.
>
> In short, although I do appreciate Johannes's and Sam's attempt,
> I would really prefer to see us pick some externally maintained
> alternative, instead of inventing a homebrew system that we need
> to maintain ourselves. It is rumored that git has much higher
> developer count vs loc count ratio than many other open source
> projects, doing the documentation format is not part of our
> project, and I'd rather see them spend time working on git, not
> building and maintaining AsciiDoc lookalike.
For the kernel I would like to see a tool that does:
o Based on nicely formatted ascii/utf-8 be able to:
- Generate good looking and easy to read HTML
- Possible generate other output formats too
And if the kernel folks do not like it then at least the possibility
to run this on kbuild documentation locally so I can generate nice
html docs for that part.
For a kernel integrated tool the dependencies shall be minimal which
is where asciidoc fails today. If asciidoc people could address this
issue for the simpler output format then the tool IMO would
have a much stronger position.
Sam
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Karl Hasselström @ 2007-10-03 17:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Pierre Habouzit, Wincent Colaiuta, Miles Bader, Junio C Hamano,
git
In-Reply-To: <Pine.LNX.4.64.0710031742400.28395@racer.site>
On 2007-10-03 17:44:39 +0100, Johannes Schindelin wrote:
> I wonder how hard it would be to teach _everybody_ to specify
> _exactly_ what they want.
>
> Of course, we'd need an "--existing" option to git-push to trigger
> the behaviour that we have right now.
I could _definitely_ live with that. If the branch config doesn't say
what to do when no arguments are given, then demand a specification on
the command line.
I'll shut up on this topic now, though, since I'm not exactly helping
with the patch/opinion ratio.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git filetypes for vim
From: martin f krafft @ 2007-10-03 17:03 UTC (permalink / raw)
To: git discussion list; +Cc: git
In-Reply-To: <20071003160745.GA8173@lapse.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
also sprach martin f krafft <madduck@madduck.net> [2007.10.03.1707 +0100]:
> My repo is here: http://git.madduck.net/v/misc/vim-git.git
> Tim's is here: git://git.tpope.net/~tpope/vim-git.git
We had to rewrite the repos history because some information slipped
in that we didn't want archived forever. I am sorry about this.
Please reclone.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
kermit: why are there so many songs about rainbows?
fozzy: that's part of what rainbows do.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-03 16:59 UTC (permalink / raw)
To: David Kastrup; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <85641oy5ge.fsf@lola.goethe.zz>
On Wed, Oct 03, 2007 at 10:20:49AM +0200, David Kastrup wrote:
> Part of the reason is that it is not actually what I had in mind. Why
> create the hash array as a hash array? Filling the hash array in
> basically random order, then sort+compressing it is what is causing
> much of the costs. My idea was to just fill the "hash array"
> linearly. It is quite pointless (and certainly very inefficient with
> regard to cache poisoning) to do it in hash order when we are going to
> sort it anyway.
Try profiling the code, and you will see that the creation of the hashes
is totally dwarfed by the comparisons. So yes, you might be able to
speed up the creation code, but it's going to have a minimal impact on
the overall run time.
-Peff
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Johannes Schindelin @ 2007-10-03 16:44 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Karl Hasselström, Wincent Colaiuta, Miles Bader,
Junio C Hamano, git
In-Reply-To: <20071003162816.GA17403@artemis.corp>
Hi,
On Wed, 3 Oct 2007, Pierre Habouzit wrote:
> On Wed, Oct 03, 2007 at 04:18:56PM +0000, Johannes Schindelin wrote:
> > This thread is getting painful. Lot's of "I want"s, but nobody to date
> > came up with a solution that makes both oldtimers and newtimers happy.
>
> I think I made a proposal that tries to reach some kind of consensus:
>
> `git push`::
> no arguments given just pushes the current branch you're on, into
> origin, if a refspec matches.
I use that sometimes, and I do not want only the current branch to be
pushed.
> `git push <remote>`::
> works like now (aka pushes all branches that match a remote branch
> in the given remote).
That would make things inconsistent, and inconsistent things are always
hard to explain.
> This way, you can have current "git push" using "git push origin", but
> you also have a convenient way to push only the current branch into your
> default remote repository without needing to spell out:
>
> $ git push origin `git symbolic-ref HEAD`
I wonder how hard it would be to teach _everybody_ to specify _exactly_
what they want.
Of course, we'd need an "--existing" option to git-push to trigger the
behaviour that we have right now.
Ciao,
Dscho
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Pierre Habouzit @ 2007-10-03 16:28 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Karl Hasselström, Wincent Colaiuta, Miles Bader,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710031718110.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]
On Wed, Oct 03, 2007 at 04:18:56PM +0000, Johannes Schindelin wrote:
> This thread is getting painful. Lot's of "I want"s, but nobody to date
> came up with a solution that makes both oldtimers and newtimers happy.
I think I made a proposal that tries to reach some kind of consensus:
`git push`::
no arguments given just pushes the current branch you're on, into
origin, if a refspec matches.
`git push <remote>`::
works like now (aka pushes all branches that match a remote branch
in the given remote).
This way, you can have current "git push" using "git push origin", but
you also have a convenient way to push only the current branch into your
default remote repository without needing to spell out:
$ git push origin `git symbolic-ref HEAD`
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Wincent Colaiuta @ 2007-10-03 16:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Karl Hasselström, Miles Bader, Pierre Habouzit,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710031550490.28395@racer.site>
El 3/10/2007, a las 17:27, Johannes Schindelin escribió:
> On Wed, 3 Oct 2007, Karl Hasselström wrote:
>
>> 2. "push all branches" is the default, but the user intended to
>> push
>> only the current branch. She ends up pushing a superset of what
>> she wanted, which is not easily fixed if she can't be sure that
>> no one else has pulled from the public repo before she notices
>> what's happened.
>
> But that is not the default. Not at all.
>
> The default is to push the refs which the remote and the local side
> have
> _in common_.
Yes, that's already been covered in this thread, probably in the
first or second post, and (at least I hope) we've all read it and
take it as given.
Replace "push all branches" with "push all refs that both sides have
in common", which is presumably what Karl meant, and the concerns are
still there.
> Maybe we should initialise the "remote.origin.push" variable to
> "completely-bogus-branchname" when you "git init --im-a-newbie"?
How is this comment supposed to help in any way? Please try to think
about the image you're putting across; as an relatively active and
prominent contributer in the Git community you are part of the "face"
of the community.
Cheers,
Wincent
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Johannes Schindelin @ 2007-10-03 16:18 UTC (permalink / raw)
To: Karl Hasselström
Cc: Wincent Colaiuta, Miles Bader, Pierre Habouzit, Junio C Hamano,
git
In-Reply-To: <20071003160731.GA7113@diana.vm.bytemark.co.uk>
Hi,
On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:
> On 2007-10-03 16:27:49 +0100, Johannes Schindelin wrote:
>
> > On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:
> >
> > > 2. "push all branches" is the default, but the user intended to
> > > push only the current branch. She ends up pushing a superset
> > > of what she wanted, which is not easily fixed if she can't be
> > > sure that no one else has pulled from the public repo before
> > > she notices what's happened.
> >
> > But that is not the default. Not at all.
> >
> > The default is to push the refs which the remote and the local side
> > have _in common_.
>
> I know, and that's what I meant by "all branches". Sorry for the
> sloppy language.
>
> > Maybe we should initialise the "remote.origin.push" variable to
> > "completely-bogus-branchname" when you "git init --im-a-newbie"?
>
> I'd rather have a suboptimal default than different defaults depending
> on user settings. (See also Junio's comment on that elsewhere in this
> thread.)
This thread is getting painful. Lot's of "I want"s, but nobody to date
came up with a solution that makes both oldtimers and newtimers happy.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-10-03 16:13 UTC (permalink / raw)
To: Jeff King; +Cc: David Kastrup, Git Mailing List
In-Reply-To: <20071003065414.GA13737@coredump.intra.peff.net>
On Wed, 3 Oct 2007, Jeff King wrote:
>
> I get slightly better speedups with my pathological case (around 30%):
Ok, 30% is definitely "worth doing". Even if your performance still sucks,
and 71 seconds is just way out of line for anything like this (of course,
these days you need that "-l0" to ever trigger that case, but it would be
nice if we could speed things up so much that we no longer care).
Linus
^ permalink raw reply
* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Johannes Schindelin @ 2007-10-03 16:11 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200710031348.50800.wielemak@science.uva.nl>
Hi,
On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> 2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current
> HEAD of module
AFAIR we do not allow committing via pserver protocol. Might that be your
problem?
Ciao,
Dscho
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Karl Hasselström @ 2007-10-03 16:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Miles Bader, Pierre Habouzit, Junio C Hamano,
git
In-Reply-To: <Pine.LNX.4.64.0710031550490.28395@racer.site>
On 2007-10-03 16:27:49 +0100, Johannes Schindelin wrote:
> On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:
>
> > 2. "push all branches" is the default, but the user intended to
> > push only the current branch. She ends up pushing a superset
> > of what she wanted, which is not easily fixed if she can't be
> > sure that no one else has pulled from the public repo before
> > she notices what's happened.
>
> But that is not the default. Not at all.
>
> The default is to push the refs which the remote and the local side
> have _in common_.
I know, and that's what I meant by "all branches". Sorry for the
sloppy language.
> Maybe we should initialise the "remote.origin.push" variable to
> "completely-bogus-branchname" when you "git init --im-a-newbie"?
I'd rather have a suboptimal default than different defaults depending
on user settings. (See also Junio's comment on that elsewhere in this
thread.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH v2] INSTALL: Update section on external dependencies
From: Shawn O. Pearce @ 2007-10-03 16:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johan Herland, git, Miklos Vajna, Junio C Hamano, Reece Dunn
In-Reply-To: <Pine.LNX.4.64.0710031655590.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 3 Oct 2007, Johan Herland wrote:
>
> > Includes:
> > - Mention dependency on "core" utilities, including coreutils, sed, cut, grep
>
> Maybe mention libc, too? Oh, and that you need a computer? ;-)
Don't forget that the computer must be plugged in and have
electricity as well. I see users all too often wonder why everything
they type is black, on a black background...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add test case for ls-files --with-head
From: Carl Worth @ 2007-10-03 16:06 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Junio C Hamano, Keith Packard, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710031634300.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 214 bytes --]
On Wed, 3 Oct 2007 16:36:13 +0100 (BST), Johannes Schindelin wrote:
> Or as
>
> i=1
> while test $i -le 50
> do
...
> i=$(($i+1))
> done
/me steps aside to let the shell-script wizards finish the job
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] INSTALL: Update section on external dependencies
From: Johannes Schindelin @ 2007-10-03 15:56 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Miklos Vajna, Junio C Hamano, Reece Dunn
In-Reply-To: <200710031027.48999.johan@herland.net>
Hi,
On Wed, 3 Oct 2007, Johan Herland wrote:
> Includes:
> - Mention dependency on "core" utilities, including coreutils, sed, cut, grep
Maybe mention libc, too? Oh, and that you need a computer? ;-)
> - Fix up some whitespace and linebreaking issues
The commit message could use some of that, too... ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Johannes Schindelin @ 2007-10-03 15:54 UTC (permalink / raw)
To: Tom Clarke; +Cc: Junio C Hamano, Shawn O. Pearce, Carl Worth, git
In-Reply-To: <550f9510710030711p195378c5t2739292d31a12de@mail.gmail.com>
Hi,
On Wed, 3 Oct 2007, Tom Clarke wrote:
> On 10/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> > I do not offhand think of a place other than "git pull" that
> > would make sense to sometimes be able to rebase when you
> > normally use merge, so I am inclined to say it would be easier
> > to teach that "'git pull' is usually a 'git fetch' followed by
> > 'git merge', but in certain workflow it is handier to 'git
> > fetch' and then 'git rebase', and here are the ways to get the
> > rebasing behaviour...".
>
> I agree. I'll revisit teaching pull to be able to use rebase.
In that case, may I request a config variable to set this behaviour
automatically when calling "git pull <nick>"?
Had we stayed with the merge strategy approach, that would have come for
free with the --no-ff patch series.
Ciao,
Dscho
^ 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