* Re: remote#branch
From: Mike Hommey @ 2007-10-31 9:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <472844D4.8050306@op5.se>
On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:
> >Or copied from gitweb.
> >
>
> Perhaps, but I've never seen that done. Partly because you can't be sure
> the HTTP url is the same as the git address (perhaps people are used to
> this from CVS and the likes), and partly because you'd, for most cases,
> want to use git:// or ssh transport instead of http.
>
> It might be nifty to have gitweb print some git-valid locator for a repo
> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
> command-line thingie. I'll look into it when I have leisure.
Hum... it already does print http and git "Mirror URL"s which are ready to
be copy/pasted to feed git clone arguments.
Mike
^ 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-10-31 9:14 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <7v8x5jiseh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 1. Error on the sending side. The ref parameters given to
> git-push were bogus, or they were good commits but they were
> not fully connected to the commits the other side has
> (i.e. local repository corruption). pack-objects will abort
> and no remote (nor local tracking ref that tracks what we
> pushed to the remote) would be updated. This should be
> "most severe" in _any_ workflow, so I do not mind calling
> this "fatal".
By the way, as git-push allows an arbitrary SHA-1 on the left
hand side of a refspec, you can have the above error without a
corrupted repository. Here is how.
* You run git-fetch from elsewhere. It is a small fetch and we
decide not to keep the pack (iow, run unpack-objects instead
of index-pack on the local side). Or the fetch is over dumb
transport that walks commits one-by-one.
This git-fetch is interrupted. We do _not_ update any refs
in such a case, but we do not eradicate loose objects that
were downloaded. They stay dangling.
* You push one of the commits downloaded above. I.e. it is
not connected to any of your ref.
^ permalink raw reply
* Re: remote#branch
From: Andreas Ericsson @ 2007-10-31 9:03 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <20071031083506.GA23316@glandium.org>
Mike Hommey wrote:
> On Wed, Oct 31, 2007 at 08:09:01AM +0100, Andreas Ericsson <ae@op5.se> wrote:
>> Jeff King wrote:
>>> On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:
>>>
>>>>> ...which is a quoting mechanism, and it's not even one commonly used in
>>>>> emails (i.e., people have written "parse a URL from this text" scripts
>>>>> for RFC-encoded URLs, but _not_ for shell quoting).
>>>> I don't think RFC-encoding is quoting mechanism used in emails, either.
>>> That's funny, because I have hundreds of mails where that is the case,
>>> and none where people used shell-quoting. Most URLs don't _need_ any
>>> encoding, so we don't notice either way. But are you honestly telling me
>>> that if you needed to communicate a URL with a space via email, you
>>> would write:
>>>
>>> 'http://foo.tld/url with a space'
>>>
>>> rather than:
>>>
>>> http://foo.tld/url+with+a+space
>>>
>>> ?
>>>
>> I think 99% of all URL's communicated via email are copy-pasted from a
>> webbrowsers location bar. I believe most git urls (or grls, or whatever
>> you wanna call them) communicated via email are copy-pasted from ones
>> config, or written out manually.
>
> Or copied from gitweb.
>
Perhaps, but I've never seen that done. Partly because you can't be sure
the HTTP url is the same as the git address (perhaps people are used to
this from CVS and the likes), and partly because you'd, for most cases,
want to use git:// or ssh transport instead of http.
It might be nifty to have gitweb print some git-valid locator for a repo
though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
command-line thingie. I'll look into it when I have leisure.
--
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-10-31 8:45 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <F5F68690-68A3-4AFC-A79C-FF02910F0359@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> Would it be acceptable if the error was less severe in the
> case of local being a strict subset of remote?
> Daniel proposed
> "%s: nothing to push to %s, but you are not up-to-date and
> may want to pull"
> It would still be an error, but a less severe one.
I am not convinced there is one true total order of "error
severity" that applies uniformly across different workflows, so
I would not immediately agree if you are suggesting to introduce
"severity levels". But it certainly makes a lot of sense to be
able to _differentiate_ kinds of errors, and to have the calling
scripts and the push command itself react to them.
What are the possible error conditions?
1. Error on the sending side. The ref parameters given to
git-push were bogus, or they were good commits but they were
not fully connected to the commits the other side has
(i.e. local repository corruption). pack-objects will abort
and no remote (nor local tracking ref that tracks what we
pushed to the remote) would be updated. This should be
"most severe" in _any_ workflow, so I do not mind calling
this "fatal".
2. Push to a ref does fast forward, but the update hook on the
remote side declines. The ref on the remote nor the
corresponding local tracking ref would not be updated, and
the command would fail.
For all the other classes of errors, the ref on the remote nor
the corresponding local tracking ref would not be updated, and
by default, an error on any ref causes the command to error out.
For each of these classes of errors, we _could_ have an option
to let you tell the command not to error out because of it.
3. Push to a ref does not fast forward and --force is not
given, but you can prove the remote is strict subset of
local (what your 10/10 wants to do).
4. Same as #3 but you cannot prove the remote is strict subset
of local.
Any other classes?
It might be a good idea to generalize 3 & 4, by the way. The
remote being a strict descendant of what is being pushed might
be something you happened to want today, but somebody else may
come up with a different rule tomorrow. So,
3'. Push to a ref does not fast forward and --force is not
given, but there is a configuration (would this be per
remote?, per remote branch?, or per local branch?) that
tells git-push to call a hook on the local side that takes
<ref being pushed, ref on the remote> as its parameter.
The result from the hook does not change the fact that this
is still an error, but it can instruct git-push not to
error out due to this condition.
In some other workflows, it might make sense to maybe even
making 2. not to cause the error from git-push. I dunno.
> It could also be a good idea to teach git push transactional
> behaviour.
That is certainly true. I am not sure about other transports,
but it should be a relatively straightforward protocol extension
for the git native transport.
> - git push can be configuration to push only the current
> branch, as outlined below. This would certainly work. What
> I do not like is that you first need to do some configuration
> before you get a safe working environment.
I would not doubt it would be safer for _your_ workflow, but you
should consider the risk of making things more cumbersome for
workflows of others by enforcing that policy.
In other words, don't change anything unless you have a very
good reason to convince everybody else that it is universally
a good change to the default.
^ permalink raw reply
* Re: Possible bug: git-svn leaves broken tree in case of error
From: Eric Wong @ 2007-10-31 8:42 UTC (permalink / raw)
To: Anton Korobeynikov; +Cc: git
In-Reply-To: <20071031075524.GB7798@muzzle>
Eric Wong <normalperson@yhbt.net> wrote:
> Anton Korobeynikov <asl@math.spbu.ru> wrote:
> > Hello, Everyone.
> >
> > I noticed this bug several times. Consider the following conditions are
> > met:
> > - We're syncing from svn using git-svn :)
> > - We have authors file provided
> > - We have a changeset with author unlisted in the authors file.
> >
> > git-svn dies due to the following code:
> > sub check_author {
> > my ($author) = @_;
> > if (!defined $author || length $author == 0) {
> > $author = '(no author)';
> > }
> > if (defined $::_authors && ! defined $::users{$author}) {
> > die "Author: $author not defined in $::_authors file\n";
> > }
> > $author;
> > }
> >
> > Unfortunately it leaves repository in some middle state: git-svn itself
> > thinks, that it synced with everything, but git itself doesn't "see" any
> > changesets anymore. I found no way to repair tree after such situation,
> > so I had to repull from scratch.
> >
> > I found myself, that this should be warning (and fix in this case is
> > trivial), not error (maybe some commandline switch to control behaviour,
> > etc). It can be even error, but breaking tree is definitely bug in this
> > case.
>
> You should be able to change the numbers in *-maxRev back to
> an old revision in .git/svn/.metadata. Does that fix things for you
> so you can resume synching again?
>
> I'll have to investigate the die()-ing of check_authors since
> that should cause git-svn to quit before the maxRev numbers
> get incremented.
With the following test case, I'm not able to reproduce what you're
describing.
But yes, die-ing here and not being able to gracefully recover is a
nasty bug...
Warning instead of die-ing here is not a good option, because it can
lead to inconsistent author data inside populating history. I believe
it's better to error out immediately so the user can fix their authors
file.
diff --git a/t/t9117-git-svn-authors-file.sh b/t/t9117-git-svn-authors-file.sh
new file mode 100755
index 0000000..4566307
--- /dev/null
+++ b/t/t9117-git-svn-authors-file.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Eric Wong
+#
+
+test_description='git-svn authors file tests'
+
+. ./lib-git-svn.sh
+
+cat > svn-authors <<EOF
+aa = AAAAAAA AAAAAAA <aa@example.com>
+bb = BBBBBBB BBBBBBB <bb@example.com>
+EOF
+
+test_expect_success 'setup svnrepo' "
+ svn mkdir -m aa --username aa $svnrepo/aa &&
+ svn mkdir -m bb --username bb $svnrepo/bb &&
+ svn mkdir -m cc --username cc $svnrepo/cc &&
+ svn mkdir -m dd --username dd $svnrepo/dd
+ "
+
+test_expect_failure 'start import with incomplete authors file' "
+ git-svn clone --authors-file=svn-authors $svnrepo x
+ "
+
+test_expect_success 'imported 2 revisions successfully' "
+ cd x &&
+ test \`git rev-list refs/remotes/git-svn | wc -l\` -eq 2 &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn | \
+ grep '^author BBBBBBB BBBBBBB <bb@example\.com> ' &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn~1 | \
+ grep '^author AAAAAAA AAAAAAA <aa@example\.com> ' &&
+ cd ..
+ "
+
+cat >> svn-authors <<EOF
+cc = CCCCCCC CCCCCCC <cc@example.com>
+dd = DDDDDDD DDDDDDD <dd@example.com>
+EOF
+
+test_expect_success 'continues to import once authors have been added' "
+ cd x &&
+ git-svn fetch --authors-file=../svn-authors &&
+ test \`git rev-list refs/remotes/git-svn | wc -l\` -eq 4 &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn | \
+ grep '^author DDDDDDD DDDDDDD <dd@example\.com> ' &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn~1 | \
+ grep '^author CCCCCCC CCCCCCC <cc@example\.com> ' &&
+ cd ..
+ "
+
+test_expect_success 'authors-file against globs' "
+ svn mkdir -m globs --username aa \
+ $svnrepo/aa/trunk $svnrepo/aa/branches $svnrepo/aa/tags &&
+ git-svn clone --authors-file=svn-authors -s $svnrepo/aa aa-work &&
+ svn mkdir -m aa/branches/bb --username bb $svnrepo/aa/branches/bb &&
+ svn mkdir -m aa/branches/ee --username ee $svnrepo/aa/branches/ee &&
+ svn mkdir -m aa/branches/cc --username cc $svnrepo/aa/branches/cc
+ "
+
+test_expect_failure 'fetch fails on ee' "
+ cd aa-work &&
+ git-svn fetch --authors-file=../svn-authors
+ "
+
+tmp_config_get () {
+ GIT_CONFIG=.git/svn/.metadata git config --get "$1"
+}
+
+test_expect_success 'failure happened without negative side effects' "
+ test 6 -eq \"\`tmp_config_get svn-remote.svn.branches-maxRev\`\" &&
+ test 6 -eq \"\`tmp_config_get svn-remote.svn.tags-maxRev\`\"
+ "
+
+cat >> ../svn-authors <<EOF
+ee = EEEEEEE EEEEEEE <ee@example.com>
+EOF
+
+test_expect_success 'fetch continues after authors-file is fixed' "
+ git-svn fetch --authors-file=../svn-authors &&
+ test 8 -eq \"\`tmp_config_get svn-remote.svn.branches-maxRev\`\" &&
+ test 8 -eq \"\`tmp_config_get svn-remote.svn.tags-maxRev\`\"
+ "
+
+test_done
--
Eric Wong
^ permalink raw reply related
* Re: remote#branch
From: Mike Hommey @ 2007-10-31 8:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <47282A0D.9010400@op5.se>
On Wed, Oct 31, 2007 at 08:09:01AM +0100, Andreas Ericsson <ae@op5.se> wrote:
> Jeff King wrote:
> >On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:
> >
> >>>...which is a quoting mechanism, and it's not even one commonly used in
> >>>emails (i.e., people have written "parse a URL from this text" scripts
> >>>for RFC-encoded URLs, but _not_ for shell quoting).
> >>I don't think RFC-encoding is quoting mechanism used in emails, either.
> >
> >That's funny, because I have hundreds of mails where that is the case,
> >and none where people used shell-quoting. Most URLs don't _need_ any
> >encoding, so we don't notice either way. But are you honestly telling me
> >that if you needed to communicate a URL with a space via email, you
> >would write:
> >
> > 'http://foo.tld/url with a space'
> >
> >rather than:
> >
> > http://foo.tld/url+with+a+space
> >
> >?
> >
>
> I think 99% of all URL's communicated via email are copy-pasted from a
> webbrowsers location bar. I believe most git urls (or grls, or whatever
> you wanna call them) communicated via email are copy-pasted from ones
> config, or written out manually.
Or copied from gitweb.
Mike
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Wincent Colaiuta @ 2007-10-31 8:24 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Johannes Schindelin, git
In-Reply-To: <20071031041751.GA3326@atjola.homenet>
El 31/10/2007, a las 5:17, Björn Steinbrink escribió:
> How about:
> \--first-parent::
> When this option is given and --preserve-merges is not, then
> merge commits are completely ignored and only commits from the
> first parent ancestry are rebased. This allows to pretend that
> merges never happened.
>
> If --preserve-merges is also given, the merge commits are
> preserved, but only their first parent is rebased as opposed to
> the default behaviour which would rebase all parents.
Minor nitpick:
- first parent ancestry are rebased. This allows to pretend that
+ first parent ancestry are rebased. This allows you to pretend that
Cheers,
Wincent
^ permalink raw reply
* Re: remote#branch
From: Robin Rosenberg @ 2007-10-31 8:25 UTC (permalink / raw)
To: David Kastrup
Cc: Jeff King, Linus Torvalds, Pascal Obry, Matthieu Moy, Tom Prince,
Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <85pryvzt1h.fsf@lola.goethe.zz>
onsdag 31 oktober 2007 skrev David Kastrup:
> Jeff King <peff@peff.net> writes:
>
> > On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:
> >
> >> So if you want to follow the RFC, you'd better give a real reason. And no,
> >> the existence of an RFC, and the fact that people use the same name for
> >> things that superficially _look_ the same is not a reason in itself.
> >>
> >> So hands up, people. Anybody who asked for RFC quoting. Give a damn
> >> *reason* already!
> >
> > I didn't ask for RFC quoting, but a nice side effect of URL syntax is
> > that they are machine parseable. If you wanted to write a tool to pick
> > the URLs out of this email and clone them as git repos, then how do you
> > find the end of:
> >
> > http://host/git repo with spaces in the path
> >
> > compared to:
> >
> > http://host/git+repo+with+spaces+in+the+path
>
> You just write <URL:http://host/git repo with spaces in the path> and
> have a good chance it will work.
It doesn't with KMail.
-- robin
^ permalink raw reply
* Re: remote#branch
From: Wincent Colaiuta @ 2007-10-31 8:16 UTC (permalink / raw)
To: David Kastrup
Cc: Jeff King, Linus Torvalds, Pascal Obry, Matthieu Moy, Tom Prince,
Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <85pryvzt1h.fsf@lola.goethe.zz>
El 31/10/2007, a las 7:39, David Kastrup escribió:
> Jeff King <peff@peff.net> writes:
>
>> I didn't ask for RFC quoting, but a nice side effect of URL syntax is
>> that they are machine parseable. If you wanted to write a tool to
>> pick
>> the URLs out of this email and clone them as git repos, then how do
>> you
>> find the end of:
>>
>> http://host/git repo with spaces in the path
>>
>> compared to:
>>
>> http://host/git+repo+with+spaces+in+the+path
>
> You just write <URL:http://host/git repo with spaces in the path> and
> have a good chance it will work.
As a data point, my email client correctly highlights only this one as
a URL:
http://host/git+repo+with+spaces+in+the+path
Both of these are incorrectly highlighted:
http://host/git repo with spaces in the path
<URL:http://host/git repo with spaces in the path>
And this one too:
<http://host/git repo with spaces in the path>
So what does this mean in practice? I can right-click on the first one
and choose "Copy". All the other ones I have to left-click and drag,
being careful to limit the selection to the appropriate left and right
boundaries.
Whether or not this is a big enough deal to actually care about is
open to debate (obviously). Personally, I don't care too much seeing
as I never use paths with spaces in them for this kind of thing.
Cheers,
Wincent
^ permalink raw reply
* Re: Possible bug: git-svn leaves broken tree in case of error
From: Eric Wong @ 2007-10-31 7:55 UTC (permalink / raw)
To: Anton Korobeynikov; +Cc: git
In-Reply-To: <1193729426.30755.32.camel@asl.dorms.spbu.ru>
Anton Korobeynikov <asl@math.spbu.ru> wrote:
> Hello, Everyone.
>
> I noticed this bug several times. Consider the following conditions are
> met:
> - We're syncing from svn using git-svn :)
> - We have authors file provided
> - We have a changeset with author unlisted in the authors file.
>
> git-svn dies due to the following code:
> sub check_author {
> my ($author) = @_;
> if (!defined $author || length $author == 0) {
> $author = '(no author)';
> }
> if (defined $::_authors && ! defined $::users{$author}) {
> die "Author: $author not defined in $::_authors file\n";
> }
> $author;
> }
>
> Unfortunately it leaves repository in some middle state: git-svn itself
> thinks, that it synced with everything, but git itself doesn't "see" any
> changesets anymore. I found no way to repair tree after such situation,
> so I had to repull from scratch.
>
> I found myself, that this should be warning (and fix in this case is
> trivial), not error (maybe some commandline switch to control behaviour,
> etc). It can be even error, but breaking tree is definitely bug in this
> case.
You should be able to change the numbers in *-maxRev back to
an old revision in .git/svn/.metadata. Does that fix things for you
so you can resume synching again?
I'll have to investigate the die()-ing of check_authors since
that should cause git-svn to quit before the maxRev numbers
get incremented.
--
Eric Wong
^ 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-10-31 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejfcl8aj.fsf@gitster.siamese.dyndns.org>
On Oct 30, 2007, at 8:19 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
>>
>>> It simply is insane to make this strange rule 10/10 introduces
>>> the default behaviour. It is too specific to a particular
>>> workflow (that is, working with a shared central repository,
>>> having many locally tracking branches that are not often used
>>> and become stale, and working on only things to completion
>>> between pushes).
>>
>> I don't think its very strange behaviour if you see it in the
>> light of what the user wants to achieve. We are talking about
>> the case were only fast forward pushes are allowed. So, we
>> only talk about a push that has the goal of adding new local
>> changes to the remote. The user says "git push" and means
>> push my new local changes to the remote.
>
> If you want to push a specific subset of branches, you should
> not be invoking the "matching refs" to begin with. And breaking
> the "matching refs" behaviour is not the way to fix it.
ok.
So, git push shall guarantee that all matching refs point
to the _same_ commit if a push was successful. Otherwise,
git push shall report an error.
Would it be acceptable if the error was less severe in the
case of local being a strict subset of remote?
Daniel proposed
"%s: nothing to push to %s, but you are not up-to-date and
may want to pull"
It would still be an error, but a less severe one.
It could also be a good idea to teach git push transactional
behaviour. It could check in advance ('--dry-run') if the
push will succeed. If not it should report the errors without
actually pushing. Then, _nothing_ would have been changed on
the remote. Only if everything is ok "git push" would modify
the remote. Well, I think it might be hard to avoid the race
condition when someone else pushes simultaneously to a shared
repo. But this hopefully rarely happens.
> You can rewind a wrong branch by mistake locally and run push.
> With your change you would not notice that mistake.
>
> $ git checkout bar
> $ work work work; commit commit commit
> $ git checkout test
> $ git merge bar
> ... integrate, build, test
> ... notice that the tip commit of bar is not ready
> $ git checkout foo ;# oops, mistake
> $ git reset --hard HEAD^
> $ git push
>
> If you checked out foo instead of bar by mistake at the last
> "git checkout" step like this, your change will make 'foo' an
> ancestor of the other side of the connection, and push silently
> ignores it instead of failing.
Yes, there are many ways you can mess up ;)
> Also, the behaviour is too specific to your workflow of working
> on things only to completion between pushes. If you work a bit
> on branch 'foo' (but not complete), and work much on branch
> 'bar', 'baz', and 'boo' making all of them ready to be
> published, you cannot say "git push" anyway. Instead you have
> to say "git push $remote bar baz boo".
Ok and this is the root why I work only to completion between
pushes. I tried to figure out a "safe" workflow. If you
accidentally type "git push" nothing wrong should happen. I
am sure that people will sometimes type "git push" forgetting
to mention anything. At least, I am sure that _I_ will do this.
The only comfortable way to make "git push" safe with
the current behaviour is to work on local branches only to
completion. Then, you can push to any repository at any time
and nothing bad can happen.
Alternatives with existing git are
- never use "git push", but always tell git explicitly what you
want. This is too dangerous for me because at some point I'll
type "git push". The problem with "git push" is that it's
really hard to undo. It's near to impossible if you pushed
to a public remote. Therefore, I really want to avoid this danger.
- Configure specific push rules for remotes that switch off
the "matching branches" default. You can for example 'switch'
off the default by configuring
"remote.$remote.push = nonexisting". But then I started
to get annoyed by all the configuration work. I do not want
to explain such details to people who get started with git.
And you do not get reasonable messages either. And btw I'd
prefer if git push just did the right thing.
Alternatives that require changing git push are
- git push would do _nothing_ by default. git push would ask
"what do you mean? Need at least a remote, or better remote
and branch."
Options could be provided to push current branch (--current)
or all matching branches (--matching).
- git push _by default_ would only push the current branch. This
would at least be a "safer" default.
- git push would first run --dry-run and then ask for
confirmation. Something like:
"Do you really want to push this to that remote? Here is
the URL and the branches. Did you really mean this?
WARNING: you can't undo this operation. And btw if you say
yes, I'll report errors anyway because some remotes are not
strict subsets. So maybe you want to fix things first."
- git push can be configuration to push only the current
branch, as outlined below. This would certainly work. What
I do not like is that you first need to do some configuration
before you get a safe working environment.
> This discourages people from making commits that are not ready
> to be published, which is a very wrong thing to do, as a major
> selling point of distributed revision control is the
> dissociation between committing and publishing.
Yes, the current default behaviour of git push discourages me
to work that way.
> You work and commit freely, and at any point some of your
> branches are ready to be published while some others
> aren't. Inconvenience of "matching refs" may need to be worked
> around. I liked your "current branch only", with "git push
> $remote HEAD" (I presume that "remote.$remote.push = HEAD" and
> "branch.$current.remote = $remote" would let you do that with
> "git push"), exactly because the way it specifies which branch
> is to be published is very clearly defined and easy to
> understand. This "matching but only ff" does not have that
> attractive clarity.
In my view, that would be safer than what we have now.
Steffen
^ permalink raw reply
* Re: remote#branch
From: Andreas Ericsson @ 2007-10-31 7:09 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, git
In-Reply-To: <20071031015708.GA24403@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:
>
>>> ...which is a quoting mechanism, and it's not even one commonly used in
>>> emails (i.e., people have written "parse a URL from this text" scripts
>>> for RFC-encoded URLs, but _not_ for shell quoting).
>> I don't think RFC-encoding is quoting mechanism used in emails, either.
>
> That's funny, because I have hundreds of mails where that is the case,
> and none where people used shell-quoting. Most URLs don't _need_ any
> encoding, so we don't notice either way. But are you honestly telling me
> that if you needed to communicate a URL with a space via email, you
> would write:
>
> 'http://foo.tld/url with a space'
>
> rather than:
>
> http://foo.tld/url+with+a+space
>
> ?
>
I think 99% of all URL's communicated via email are copy-pasted from a
webbrowsers location bar. I believe most git urls (or grls, or whatever
you wanna call them) communicated via email are copy-pasted from ones
config, or written out manually.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: remote#branch
From: David Kastrup @ 2007-10-31 6:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fg8h9l$b4n$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Jeff King wrote:
>
>> On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:
>>
>> http://host/git repo with spaces in the path
>>
>> compared to:
>>
>> http://host/git+repo+with+spaces+in+the+path
>>
>> I don't know if that's worth changing anything in git (in fact, I'm not
>> even clear on _what_ people want to change; the point of this discussion
>> seems to be to argue about terminology). But you did ask for any reason
>> for quoting URLs.
>
> You use
>
> 'http://host/git repo with spaces in the path'
I can click on links in my mail reader, and the above is not recognized
as one. <URL:http://host/git repo with spaces in the path> would likely
work.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: remote#branch
From: David Kastrup @ 2007-10-31 6:39 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Pascal Obry, Matthieu Moy, Tom Prince,
Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071030235823.GA22747@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:
>
>> So if you want to follow the RFC, you'd better give a real reason. And no,
>> the existence of an RFC, and the fact that people use the same name for
>> things that superficially _look_ the same is not a reason in itself.
>>
>> So hands up, people. Anybody who asked for RFC quoting. Give a damn
>> *reason* already!
>
> I didn't ask for RFC quoting, but a nice side effect of URL syntax is
> that they are machine parseable. If you wanted to write a tool to pick
> the URLs out of this email and clone them as git repos, then how do you
> find the end of:
>
> http://host/git repo with spaces in the path
>
> compared to:
>
> http://host/git+repo+with+spaces+in+the+path
You just write <URL:http://host/git repo with spaces in the path> and
have a good chance it will work.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-svn and auto crlf convertion.
From: Eric Wong @ 2007-10-31 6:30 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200710311049.43861.litvinov2004@gmail.com>
Alexander Litvinov <litvinov2004@gmail.com> wrote:
> Hello.
>
> I have private svn repo with cpp source file in windows encoding (\r\n line
> ending). I am tring to import it into git using git-svn. To make correct crlf
> convertion I have made git svn init first then create
> correct .git/info/attributes file and import repo using git svn fetch
> command. But after import done I have strange situation: after git
> checkout -f master git status show that almost all text files are modified.
>
> As I understand situation git-svn put \r\n encoded files into repo without
> convertng them to \n notation. git-checkout,git-status does the job right and
> found 'modification' as far as they do the needed convertion.
Disclaimer: I'm not yet familiar with git attributes, having never used them.
> Is there any way to configure git-svn to make proper convertion or it is
> broken and need to be fixed ?
As far as I can tell, SVN itself will store files with either LF or CRLF
in the repository when the file is created/updated and applies the line
conversion properties only to the working tree upon checkout. This
means that the SVN repository can have a file that's LF but only
converted to CRLF when checked out and vice-versa.
git-svn takes and imports whatever raw data SVN gives it, ignoring any
properties set in SVN. This is very important because SVN transfers
deltas for updating files, and if we change the base file; we can't
apply the delta SVN gives us.
If we converted the newlines in the raw data that SVN gave us, we would
need to store what format the original data we got from SVN was in
because of the delta.
What I assume svn does is it either:
a) reconverts before doing `svn update' or `svn switch'
b) it ignores newline-only changes when running `svn status' or `svn diff'
git (as far as I know, and hope) does neither.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Björn Steinbrink @ 2007-10-31 5:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes.Schindelin, git
In-Reply-To: <7vodefj2lk.fsf@gitster.siamese.dyndns.org>
On 2007.10.30 22:05:27 -0700, Junio C Hamano wrote:
> Your MUA seems to mark the UTF-8 message you are sending out as
> 8859-1, which means your name in the message gets corrupt.
Hm, that would be git-send-email then, anything I need to configure?
(Actually I don't see it marking the message as anything)
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > By default, rebase will take all commits from the branch that is to be
> > rebased which are missing in upstream. The new --first-parent option
> > allows to just follow the first parent and thus completely ignore
> > merges.
> >
> > Additionally, when used together with --preserve-merges (which is the
> > more useful use-case) it will no longer rebase the commits from the
> > merged-in branches, but instead redo the merge with the original
> > parents.
> >
> > That means that:
Given this situation:
> > ---H------I topicB
> > / \ \
> > ...
> > does no longer become:
Which results in:
> > -H'--------I'
> > / \ \
> > D'---E'---F'---G' topicA
> > /
> > A---B---C master
> > \
> > H---I topicB
When you do "git-rebase -p -i master topicA"
You can now also get:
> > A---B---C master
> > ...
> > ---------H---------I topicB
When you do "git-rebase -p -i --first-parent master topicA"
That's better, right?
> And crucially, you forgot to say "... when you do X".
>
> I am assuming that you meant:
>
> This (picture) becomes this (picture) instead of this (picture)
> when you run "git rebase -p -m master topicA".
>
> but without it, the nice ASCII drawings loses their value.
:-/
> It is somewhat disturbing that this treats the first parent too
> special.
The original use-case for the "-p -i --first-parent" case was a question
on #git, where someone had sth. like this:
o---o---o---o---o remote/branch
\ \
o---o---o---o---o topicA
/
o---o---o master trunk
Now that guy was using git-svn to dcommit into svn from master. To
dcommit the changes from topicA he had to have that based on master, and
he wanted to preserve the merges from remote/branch to have them
squashed when dcommitted to svn. So what he wanted was:
...---o---o---o---o---o remote/branch
\ \
o---o---o---o---o topicA
/
o---o---o master trunk
The default behaviour of rebase would totally flat out the history and
instead of two sqaush merges (which he wanted), svn would've seen a huge
amount of commits comning from remote/branch. And the plain -p behaviour
would have duplicated all those branches from remote/branch for no good
reason, so I came up with that --first-parent thing.
Better ideas are welcome, I just don't know git well enough to come up
with anything better...
Thanks,
Björn
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Junio C Hamano @ 2007-10-31 5:05 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Johannes.Schindelin, git
In-Reply-To: <1193797309-1161-1-git-send-email-B.Steinbrink@gmx.de>
Your MUA seems to mark the UTF-8 message you are sending out as
8859-1, which means your name in the message gets corrupt.
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> By default, rebase will take all commits from the branch that is to be
> rebased which are missing in upstream. The new --first-parent option
> allows to just follow the first parent and thus completely ignore
> merges.
>
> Additionally, when used together with --preserve-merges (which is the
> more useful use-case) it will no longer rebase the commits from the
> merged-in branches, but instead redo the merge with the original
> parents.
>
> That means that:
> ---H------I topicB
Please add a blank line after "means that:" for readability.
> / \ \
> ...
> does no longer become:
> -H'--------I'
Likewise; also, "no longer becomes:".
> / \ \
> D'---E'---F'---G' topicA
> /
> A---B---C master
> \
> H---I topicB
>
> but instead:
> A---B---C master
Likewise.
> ...
> ---------H---------I topicB
And crucially, you forgot to say "... when you do X".
I am assuming that you meant:
This (picture) becomes this (picture) instead of this (picture)
when you run "git rebase -p -m master topicA".
but without it, the nice ASCII drawings loses their value.
It is somewhat disturbing that this treats the first parent too
special.
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Johannes Schindelin @ 2007-10-31 4:50 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071031041751.GA3326@atjola.homenet>
Hi,
On Wed, 31 Oct 2007, Bj?rn Steinbrink wrote:
> On 2007.10.31 03:34:47 +0000, Johannes Schindelin wrote:
>
> > On Wed, 31 Oct 2007, Bj?rn Steinbrink wrote:
> >
> > > @@ -246,6 +292,13 @@ OPTIONS
> > > Instead of ignoring merges, try to recreate them. This option
> > > only works in interactive mode.
> > >
> > > +\--first-parent::
> > > + Only follow the first parent commits in merge commits when looking
> > > + for the commits that are to be rebased. This is most useful with -p
> > > + as it will cause rebase to recreate the merges against the original
> > > + branches instead of rebasing those branches as well. This option
> > > + only works in interactive mode.
> > > +
> >
> > Hmm. I had to read this several times to understand it. Maybe
> > something like this instead?
> >
> > \--first-parent::
> > When you want to preserve merges, this option allows you to rebase
> > only the commits which were not merged in, i.e. which are in the
> > first parent ancestry of the current HEAD.
> > +
> > This option only makes sense together with --preserve-merges.
>
> Hm, I think that it might make might sense without -p. Say that your
> topic branch is following two other branches like this:
>
> ---o---o---o--------o topicB
> \ \
> --o---A---o---o---o---o---B topicA
> / /
> o---o---o---o---o master
>
> topicB branched off from master earlier than topicA and you currently
> require stuff from master..topicB _and_ topicB..master, so AFAICT, you
> need sth. like the above.
>
> Let's say that topicB simplifies some internal API and you desperately
> wanted to use that, while master introduced some new stuff that you also
> use. Now your stuff is finished, but it becomes obvious that topicB is
> still too broken to go into master any time soon. Then you could do:
>
> git rebase -i --first-parent master topicA
>
> to get:
>
> --o---o---o topicB (branched from master somewhere to the left)
>
> o---o---o---A---B topicA
> /
> ---o---o---o master
>
> Depending on how much topicA really depends on topicB, you might need to
> fix a bunch of stuff, but it might be worth it.
Okay, I see now.
> How about:
> \--first-parent::
> When this option is given and --preserve-merges is not, then
> merge commits are completely ignored and only commits from the
> first parent ancestry are rebased. This allows to pretend that
> merges never happened.
>
> If --preserve-merges is also given, the merge commits are
> preserved, but only their first parent is rebased as opposed to
> the default behaviour which would rebase all parents.
Okay.
> > Also, could you please add a test case to make sure that your patch
> > works as advertised (and that this functionality will not be broken in
> > future commits)?
>
> Ok, might take some time, as I currently have no clue how the test stuff
> for git works :-/ Well, I'm sure #git will be helpful :-)
Just have a look at t/t3404-rebase-interactive.sh. The easiest way to
proceed would be to read it from the end. You'll see that every test case
starts with "test_expect_success", followed by a message and a piece of
shell code.
I usually enhance some existing test script instead of inventing a new
one.
In your case, I would run t3404 by
cd t
sh t3404*
The working directory of these tests is in the subdirectory trash/ of t/.
After one run of t3404, I would go there and look at what is there with
gitk.
In your case, you want to have at least a few merges. Build them up in
the test case, using echo, git add, git commit and git checkout. Then run
an appropriate git rebase -i --first-commit [-p], and test that the
outcome makes sense.
You need not test _everything_. Just the differences with regards to
normal rebase. For example, that a side branch is _not_ rebased, but
"git rev-parse HEAD~2^2" is the same as before the rebase.
And remember to connect all commands with && so that a failure in one
command leads to the failure of the whole test case.
Hth,
Dscho
^ permalink raw reply
* git-svn and auto crlf convertion.
From: Alexander Litvinov @ 2007-10-31 4:49 UTC (permalink / raw)
To: git
Hello.
I have private svn repo with cpp source file in windows encoding (\r\n line
ending). I am tring to import it into git using git-svn. To make correct crlf
convertion I have made git svn init first then create
correct .git/info/attributes file and import repo using git svn fetch
command. But after import done I have strange situation: after git
checkout -f master git status show that almost all text files are modified.
As I understand situation git-svn put \r\n encoded files into repo without
convertng them to \n notation. git-checkout,git-status does the job right and
found 'modification' as far as they do the needed convertion.
Is there any way to configure git-svn to make proper convertion or it is
broken and need to be fixed ?
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Michael Haggerty @ 2007-10-31 4:42 UTC (permalink / raw)
To: Mike Snitzer
Cc: Eyvind Bernhardsen, Thomas Pasch, git, Jan Wielemaker,
Gerald (Jerry) Carter, dev
In-Reply-To: <170fa0d20710301306o6b3798f9k72615eb811d871f2@mail.gmail.com>
Mike Snitzer wrote:
> On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:
> ...
>> Thanks for making cvs2svn the best CVS-to-git conversion tool :) Now
>> if it would only support incremental importing...
>
> I second this question: is there any chance incremental importing will
> be implemented in cvs2svn?
Unfortunately, no, there is not much chance that I will implement this.
I wouldn't be interested in a works-most-of-the-time solution, and a
reliable solution would take weeks to implement.
If somebody else wants to implement this feature, I would be happy to
help him get started, answer questions, discuss the design, etc. Or if
somebody wants to sponsor the work, I might be able to justify working
on it myself. But otherwise, I'm afraid it is unlikely to happen.
> I've not used cvs2svn much and when I did it was for svn not git; but
> given that git-cvsimport is known to mess up your git repo (as Eyvind
> pointed out earlier) there doesn't appear to be any reliable tools to
> allow for incrementally importing from cvs to git.
That's because it is quite a tricky problem, especially since CVS allows
history to be changed retroactively; for example,
- shift a tag to a different file revision
- add an existing tag to a new file or remove it from an old file
- delete ("obsolete") old revisions
- change files from vendor branches to main line of development
- even nastier server-side repository manipulations like deleting an RCS
file, renaming a file, etc.
These things really happen in the topsy-turvy CVS world; indeed, they
are a part of many organizations' standard workflow.
cvs2svn uses repository-wide information in the heuristics that it uses
to determine changesets, choose branch parents, fix clock skew, etc.
Therefore the naive approach of running a full conversion a second time
and just skipping over the revisions that were handled during the first
conversion would not even begin to work. (I believe that this is the
approach of cvsps, which uses mostly local information to determine
changesets.)
I think the correct approach would involve recording the "frontier" of
the CVS repository, then at the next incremental conversion:
1. compare the current CVS repository to the recorded information
2. emit "fixup" changesets to reflect any CVS changes that happened
behind the previous "frontier".
3. emit changesets to reflect CVS changes beyond the frontier.
It is step 2 that is IMO the trickiest because it is so open-ended, and
modern SCMs don't allow all of the corresponding operations in any
straightforward way. Presumably one would have to prohibit some of the
nastier CVS tricks and abort the incremental conversion if any are detected.
Furthermore, for many use-cases of incremental conversion the conversion
would have to run quickly. Therefore, the incremental conversion code
should be written with a strong emphasis on achieving good performance.
Michael
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Björn Steinbrink @ 2007-10-31 4:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710310329520.4362@racer.site>
On 2007.10.31 03:34:47 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 31 Oct 2007, Björn Steinbrink wrote:
>
> > @@ -246,6 +292,13 @@ OPTIONS
> > Instead of ignoring merges, try to recreate them. This option
> > only works in interactive mode.
> >
> > +\--first-parent::
> > + Only follow the first parent commits in merge commits when looking
> > + for the commits that are to be rebased. This is most useful with -p
> > + as it will cause rebase to recreate the merges against the original
> > + branches instead of rebasing those branches as well. This option
> > + only works in interactive mode.
> > +
>
> Hmm. I had to read this several times to understand it. Maybe something
> like this instead?
>
> \--first-parent::
> When you want to preserve merges, this option allows you to rebase
> only the commits which were not merged in, i.e. which are in the
> first parent ancestry of the current HEAD.
> +
> This option only makes sense together with --preserve-merges.
Hm, I think that it might make might sense without -p. Say that your
topic branch is following two other branches like this:
---o---o---o--------o topicB
\ \
--o---A---o---o---o---o---B topicA
/ /
o---o---o---o---o master
topicB branched off from master earlier than topicA and you currently
require stuff from master..topicB _and_ topicB..master, so AFAICT, you
need sth. like the above.
Let's say that topicB simplifies some internal API and you desperately
wanted to use that, while master introduced some new stuff that you also
use. Now your stuff is finished, but it becomes obvious that topicB is
still too broken to go into master any time soon. Then you could do:
git rebase -i --first-parent master topicA
to get:
--o---o---o topicB (branched from master somewhere to the left)
o---o---o---A---B topicA
/
---o---o---o master
Depending on how much topicA really depends on topicB, you might need to
fix a bunch of stuff, but it might be worth it.
How about:
\--first-parent::
When this option is given and --preserve-merges is not, then
merge commits are completely ignored and only commits from the
first parent ancestry are rebased. This allows to pretend that
merges never happened.
If --preserve-merges is also given, the merge commits are
preserved, but only their first parent is rebased as opposed to
the default behaviour which would rebase all parents.
> Also, could you please add a test case to make sure that your patch works
> as advertised (and that this functionality will not be broken in future
> commits)?
Ok, might take some time, as I currently have no clue how the test stuff
for git works :-/ Well, I'm sure #git will be helpful :-)
Thanks,
Björn
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Johannes Schindelin @ 2007-10-31 3:34 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <1193797309-1161-1-git-send-email-B.Steinbrink@gmx.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1066 bytes --]
Hi,
On Wed, 31 Oct 2007, Björn Steinbrink wrote:
> @@ -246,6 +292,13 @@ OPTIONS
> Instead of ignoring merges, try to recreate them. This option
> only works in interactive mode.
>
> +\--first-parent::
> + Only follow the first parent commits in merge commits when looking
> + for the commits that are to be rebased. This is most useful with -p
> + as it will cause rebase to recreate the merges against the original
> + branches instead of rebasing those branches as well. This option
> + only works in interactive mode.
> +
Hmm. I had to read this several times to understand it. Maybe something
like this instead?
\--first-parent::
When you want to preserve merges, this option allows you to rebase
only the commits which were not merged in, i.e. which are in the
first parent ancestry of the current HEAD.
+
This option only makes sense together with --preserve-merges.
Also, could you please add a test case to make sure that your patch works
as advertised (and that this functionality will not be broken in future
commits)?
Thanks,
Dscho
^ permalink raw reply
* Re: remote#branch
From: Johannes Schindelin @ 2007-10-31 3:08 UTC (permalink / raw)
To: Jeff King
Cc: Martin Langhoff, Linus Torvalds, Theodore Tso, Junio C Hamano,
Jan Hudec, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071031014347.GB23274@coredump.intra.peff.net>
Hi,
On Tue, 30 Oct 2007, Jeff King wrote:
> Anyway, to recap (my impression of) the discussion leading up to this:
> - the cogito feature is useful
> - the cogito syntax does not allow for multiple branches to be
> specified
Here somebody else than me (IIRC Junio) proposed this syntax:
git clone --track <name> [--track <name2>] <url>
Nobody was interested enough to implement it.
I then proposed delimiting with spaces, since they were _not part of a
URL_:
git clone "<url> <name> <name2>"
but some people insisted on "#", which I pointed out (several times!) is a
no go, and I actually provided reasons for that.
> - one such syntax proposed was git://foo.tld/bar.git#blue,red
> - one problem with that syntax is that comma is a valid character
> in the branch name, and '#' is a valid character in the repo name
> - one proposed solution was that '#' and ',' when used as data should
> be URL-encoded
> - flamefest begin
>
> So I think nobody disagrees that such a feature is useful; there is
> disagreement about the syntax.
Probably there is not enough need, too, and the discussion will peter out
again, without anybody letting some code talk, and I will not make the
mistake again of reviving this discussion. Promise.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
From: Björn Steinbrink @ 2007-10-31 2:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710310239100.4362@racer.site>
Hi Dscho,
On 2007.10.31 02:42:03 +0000, Johannes Schindelin wrote:
> Hi Björn,
>
> On Wed, 31 Oct 2007, Björn Steinbrink wrote:
>
> > + new_parents=${new_parents# $first_parent}
>
> I wanted to comment that this might not be present in shells other than
> bash, but I see that we rely on that construct already in am, clone,
> commit, filter-branch, merge, pull, rebase, stash and submodule.
>
> So I think it's okay.
Actually, I checked first that it's not bash-only (I saw the flames
about that on lkml some time ago, so I've been scared ;-)). Works fine
with dash here and it's in the posix sh specs. See 2.6.2 in
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
So I hope that there's a bit of a broader support for it :-)
> The whole series is _very_ nicely done, and appears to me as obviously
> correct.
Thanks :-)
Björn
^ permalink raw reply
* Re: [PATCH 3/3] git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
From: Johannes Schindelin @ 2007-10-31 2:42 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <1193797232-1062-3-git-send-email-B.Steinbrink@gmx.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 496 bytes --]
Hi Björn,
On Wed, 31 Oct 2007, Björn Steinbrink wrote:
> + new_parents=${new_parents# $first_parent}
I wanted to comment that this might not be present in shells other than
bash, but I see that we rely on that construct already in am, clone,
commit, filter-branch, merge, pull, rebase, stash and submodule.
So I think it's okay.
The whole series is _very_ nicely done, and appears to me as obviously
correct.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Thanks,
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