* Re: 1.5.3.5 will be out tomorrow
From: Junio C Hamano @ 2007-10-31 0:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710301712240.30120@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 30 Oct 2007, Junio C Hamano wrote:
>>
>> A fix for a segfaulting bug warrants a new maintenance release,
>> so 1.5.3.5 will be out tomorrow.
>
> Is the
>
> "Make merge-recursive honor diff.renamelimit"
>
> commit in the maintenance series?
>
> If not, I'd suggest merging it.
>
> The lack of this fix bit us during the kernel x86 merge, where there was
> no way for people using stable git versions to make their merges take
> renames into account, because there were too many of them..
Ah, and that is especially painful now the rename limit is quite
low thanks to 0024a54923a12f8c05ce4290f5ebefab0cce4336 (Fix the
rename detection limit checking)?
Will cherry-pick that one -- thanks.
^ permalink raw reply
* Re: remote#branch
From: Martin Langhoff @ 2007-10-31 0:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710292150400.30120@woody.linux-foundation.org>
On 10/30/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Quick! WHO THE F*CK CARES?
Ah, damn. In all the discussion & flamefesting to say that people
don't want to use the # character, noone talks about of what cogito
used it for.
Having something functionally similar to
cg-clone git://foo.tld/bar.git#blue
would save a few steps -- and some potential confusion -- for projects
using GIT.
In case it's not clear what it does (not everyone here has used
cogito) it will create and checkout a branch tracking the "blue" head
on the repo when the clone is done. This is _instead of_ creating and
checking out the branch that tracks the configured "HEAD" of the repo.
IMHO is a quite nice thing to have -- and AFAICS we don't have it in
master or pu. I care about the shed for the bike, not its colour.
cheers,
m
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-31 0:59 UTC (permalink / raw)
To: Martin Langhoff
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <46a038f90710301741n67526976vda1cd131270aa7f@mail.gmail.com>
On Wed, 31 Oct 2007, Martin Langhoff wrote:
>
> Having something functionally similar to
>
> cg-clone git://foo.tld/bar.git#blue
>
> would save a few steps -- and some potential confusion -- for projects
> using GIT.
I do agree with that "functionally similar", I just disagree with the
syntax.
The thing is, we don't want a single branch name. Not for clone, not for
fetch, not for pull, and not for push.
Yes, a single branch may be one common case, but it's definitely not the
only one, and it's fundamentally the wrong thing to use as a definition of
syntax.
It's also the wrong thing to do for local stuff.
Linus
^ permalink raw reply
* Re: remote#branch
From: Jeff King @ 2007-10-31 1:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fg8h9l$b4n$1@ger.gmane.org>
On Wed, Oct 31, 2007 at 01:12:37AM +0100, Jakub Narebski wrote:
> > 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
> You use
>
> 'http://host/git repo with spaces in the path'
...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).
-Peff
^ permalink raw reply
* Re: remote#branch
From: Jeff King @ 2007-10-31 1:43 UTC (permalink / raw)
To: Martin Langhoff
Cc: Linus Torvalds, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <46a038f90710301741n67526976vda1cd131270aa7f@mail.gmail.com>
On Wed, Oct 31, 2007 at 01:41:12PM +1300, Martin Langhoff wrote:
> Having something functionally similar to
>
> cg-clone git://foo.tld/bar.git#blue
>
> would save a few steps -- and some potential confusion -- for projects
> using GIT.
>
> In case it's not clear what it does (not everyone here has used
> cogito) it will create and checkout a branch tracking the "blue" head
> on the repo when the clone is done. This is _instead of_ creating and
> checking out the branch that tracks the configured "HEAD" of the repo.
Actually, IIRC it won't fetch any of the non 'blue' refs.
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
- 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.
-Peff
^ permalink raw reply
* Re: remote#branch
From: Jakub Narebski @ 2007-10-31 1:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071031013856.GA23274@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 31, 2007 at 01:12:37AM +0100, Jakub Narebski wrote:
>
>>> 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
>>
>> You use
>>
>> 'http://host/git repo with spaces in the path'
>
> ...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.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: remote#branch
From: Martin Langhoff @ 2007-10-31 1:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071031014347.GB23274@coredump.intra.peff.net>
On 10/31/07, Jeff King <peff@peff.net> wrote:
> Actually, IIRC it won't fetch any of the non 'blue' refs.
You recall correctly, and that was a cogito misfeature. I don't think
git should follow that part of the spec ;-)
> Anyway, to recap (my impression of) the discussion leading up to this:
> - the cogito feature is useful
...
> - flamefest begin
Great summary. I read the first and last stages you describe (with a
trip in the middle distracting me). Heh.
No stress. Let the flames continue!
m
^ permalink raw reply
* Re: remote#branch
From: Jeff King @ 2007-10-31 1:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200710310249.17233.jnareb@gmail.com>
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 the latter is much more common, if only because of the fact that
copy and paste from most browsers' location bars gives the encoded
version.
-Peff
^ permalink raw reply
* Re: remote#branch
From: Jeff King @ 2007-10-31 1:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90710301849h1c31736an1ec163aa1e274577@mail.gmail.com>
On Wed, Oct 31, 2007 at 02:49:49PM +1300, Martin Langhoff wrote:
> > Actually, IIRC it won't fetch any of the non 'blue' refs.
> You recall correctly, and that was a cogito misfeature. I don't think
> git should follow that part of the spec ;-)
I'm not so sure. Junio keeps unrelated branches in git.git like 'html'
and 'todo'. Is it unreasonable to say "clone git.git, but only the todo
branch" and expect it _not_ to download the entire git history?
-Peff
^ permalink raw reply
* [PATCH 1/3] Fix --strategy parsing in git-rebase--interactive.sh
From: Björn Steinbrink @ 2007-10-31 2:20 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: git, Björn Steinbrink
For the --strategy/-s option, git-rebase--interactive.sh dropped the
parameter which it was trying to parse.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0dd77b4..f667ae8 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -387,7 +387,6 @@ do
output git reset --hard && do_rest
;;
-s|--strategy)
- shift
case "$#,$1" in
*,*=*)
STRATEGY="-s `expr "z$1" : 'z-[^=]*=\(.*\)'`" ;;
--
1.5.3.4.456.g072a
^ permalink raw reply related
* [PATCH 2/3] git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.
From: Björn Steinbrink @ 2007-10-31 2:20 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: git, Björn Steinbrink
In-Reply-To: <1193797232-1062-1-git-send-email-B.Steinbrink@gmx.de>
git-cherry-pick doesn't support a strategy paramter, so don't pass one.
This means that --strategy for interactive rebases is a no-op for
anything but merge commits, but that's still better than being broken. A
correct fix would probably need to port the --merge behaviour from plain
git-rebase.sh, but I have no clue how to integrate that cleanly.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f667ae8..cc949db 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -116,7 +116,7 @@ pick_one () {
sha1=$(git rev-parse --short $sha1)
output warn Fast forward to $sha1
else
- output git cherry-pick $STRATEGY "$@"
+ output git cherry-pick "$@"
fi
}
@@ -184,7 +184,7 @@ pick_one_preserving_merges () {
fi
;;
*)
- output git cherry-pick $STRATEGY "$@" ||
+ output git cherry-pick "$@" ||
die_with_patch $sha1 "Could not pick $sha1"
;;
esac
--
1.5.3.4.456.g072a
^ permalink raw reply related
* [PATCH 3/3] git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
From: Björn Steinbrink @ 2007-10-31 2:20 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: git, Björn Steinbrink
In-Reply-To: <1193797232-1062-2-git-send-email-B.Steinbrink@gmx.de>
git-rebase--interactive.sh used to pass all parents of a merge commit to
git-merge, which means that we have at least 3 heads to merge: HEAD,
first parent and second parent. So 3-way merge strategies like recursive
wouldn't work.
Fortunately, we have checked out the first parent right before the merge
anyway, so that is HEAD. Therefore we can drop simply it from the list
of parents, making 3-way strategies work for merge commits with only
two parents.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index cc949db..e63e1c9 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -172,6 +172,9 @@ pick_one_preserving_merges () {
author_script=$(get_author_ident_from_commit $sha1)
eval "$author_script"
msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
+
+ # No point in merging the first parent, that's HEAD
+ new_parents=${new_parents# $first_parent}
# NEEDSWORK: give rerere a chance
if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
--
1.5.3.4.456.g072a
^ permalink raw reply related
* [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Björn Steinbrink @ 2007-10-31 2:21 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: git, Björn Steinbrink
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
/ \ \
| D---E---F--G topicA
|/
A---B---C master
does no longer become:
-H'--------I'
/ \ \
D'---E'---F'---G' topicA
/
A---B---C master
\
H---I topicB
but instead:
A---B---C master
\ \
\ D'---E'---F'---G' topicA
\ / /
---------H---------I topicB
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e4326d3..0b5f4b6 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
[-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
- [--onto <newbase>] <upstream> [<branch>]
+ [--first-parent] [--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
DESCRIPTION
@@ -166,6 +166,52 @@ This is useful if F and G were flawed in some way, or should not be
part of topicA. Note that the argument to --onto and the <upstream>
parameter can be any valid commit-ish.
+If you have a branch that contains merges which you want to preserve, you
+can use the --preserve-merges option. By default, this will duplicate all
+merged commits on top of <upstream> (or <newbase>) and try to redo the
+merges using the new commits. Given this situation:
+
+------------
+ ---H------I topicB
+ / \ \
+ | D---E---F--G topicA
+ |/
+ A---B---C master
+------------
+
+then the command
+
+ git rebase -i --preserve-merges master topicA
+
+would result in
+
+------------
+ -H'--------I'
+ / \ \
+ D'---E'---F'---G' topicA
+ /
+ A---B---C master
+ \
+ H---I topicB
+------------
+
+If you pass --first-parent in addition to --preserve-merges, the commits
+from the merged-in branches won't be duplicated.
+
+So the command
+
+ git rebase -i --preserve-merges --first-parent master topicA
+
+would instead result in
+
+------------
+ A---B---C master
+ \ \
+ \ D'---E'---F'---G' topicA
+ \ / /
+ ---------H---------I topicB
+------------
+
In case of conflict, git-rebase will stop at the first problematic commit
and leave conflict markers in the tree. You can use git diff to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
@@ -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.
+
include::merge-strategies.txt[]
NOTES
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index e63e1c9..38b070e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -22,6 +22,7 @@ DONE="$DOTEST"/done
MSG="$DOTEST"/message
SQUASH_MSG="$DOTEST"/message-squash
REWRITTEN="$DOTEST"/rewritten
+FIRST_PARENT=
PRESERVE_MERGES=
STRATEGY=
VERBOSE=
@@ -143,14 +144,20 @@ pick_one_preserving_merges () {
preserve=f
new_p=$(cat "$REWRITTEN"/$p)
test $p != $new_p && fast_forward=f
- case "$new_parents" in
- *$new_p*)
- ;; # do nothing; that parent is already there
- *)
- new_parents="$new_parents $new_p"
- ;;
- esac
+ elif test t = "$FIRST_PARENT"
+ then
+ new_p=$p
+ else
+ continue
fi
+
+ case "$new_parents" in
+ *$new_p*)
+ ;; # do nothing; that parent is already there
+ *)
+ new_parents="$new_parents $new_p"
+ ;;
+ esac
done
case $fast_forward in
t)
@@ -412,6 +419,9 @@ do
-p|--preserve-merges)
PRESERVE_MERGES=t
;;
+ --first-parent)
+ FIRST_PARENT=t
+ ;;
-i|--interactive)
# yeah, we know
;;
@@ -481,6 +491,10 @@ do
else
MERGES_OPTION=--no-merges
fi
+ if test t = "$FIRST_PARENT"
+ then
+ MERGES_OPTION="--first-parent $MERGES_OPTION"
+ fi
SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
SHORTHEAD=$(git rev-parse --short $HEAD)
--
1.5.3.4.456.g072a
^ permalink raw reply related
* Re: [GIT-GUI PATCH 2/3] po2msg: ignore untranslated messages
From: Johannes Schindelin @ 2007-10-31 2:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: stimming, spearce, git
In-Reply-To: <7vabq0l7wn.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 30 Oct 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Do not generate translations when the translated message is empty.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > po/po2msg.sh | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/po/po2msg.sh b/po/po2msg.sh
> > index 48a2669..91d420b 100644
> > --- a/po/po2msg.sh
> > +++ b/po/po2msg.sh
> > @@ -62,6 +62,9 @@ proc flush_msg {} {
> > if {$msgid == ""} {
> > set prefix "set ::msgcat::header"
> > } else {
> > + if {$msgstr == ""} {
> > + return
> > + }
> > set prefix "::msgcat::mcset $lang \"[u2a $msgid]\""
> > }
>
> Is this change to fix some real issues?
Yes. I compared the output of po2msg.sh with that of msgfmt, and only
with this change (and 1/3) they came up identical.
Ciao,
Dscho
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-31 2:28 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Lars Hjemli, Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.62.0710302204590.6976@perkele.intern.softwolves.pp.se>
Hi,
On Tue, 30 Oct 2007, Peter Karlsson wrote:
> Lars Hjemli:
>
> > No, the grafts file is purely local.
>
> Hmm, any chance that will change in a future version?
Why should it? This would contradict the whole "a commit sha1 hashes the
commit, and by inference the _whole_ history" principle.
Ciao,
Dscho
^ 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
* 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: 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 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: [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: 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
* 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: [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
* 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: 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
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