* Re: Arbitrary long file lists?
From: Alex Riesen @ 2007-07-30 12:43 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <866442t6j5.fsf@lola.quinscape.zz>
On 7/30/07, David Kastrup <dak@gnu.org> wrote:
> commands like git-archive take a file list on the command line. If
> the number of files does no longer fit the argv limitations, this
> causes a problem.
>
> So it might be nice to be able to treat some "filenames" in a file
> list special:
>
> -@=filename (read LF-lines with filenames from filename)
> -@=- (read lines with filenames from stdin)
> -@z=filename (read NUL-terminated list with filenames from filename)
> -@z=- (same from stdin)
git-update-index and the like use --stdin and -z.
What do you need the one with filename for?
^ permalink raw reply
* Arbitrary long file lists?
From: David Kastrup @ 2007-07-30 12:33 UTC (permalink / raw)
To: git
Hi,
commands like git-archive take a file list on the command line. If
the number of files does no longer fit the argv limitations, this
causes a problem.
So it might be nice to be able to treat some "filenames" in a file
list special:
-@=filename (read LF-lines with filenames from filename)
-@=- (read lines with filenames from stdin)
-@z=filename (read NUL-terminated list with filenames from filename)
-@z=- (same from stdin)
Of course, this particular syntax, very loosely inspired by infozip,
leaves a lot to be desired: prettier proposals welcome.
But the feature itself would not be unimportant. I am also fuzzy on
what sort of quoting should be interpreted outside of the
NUL-terminated case.
--
David Kastrup
^ permalink raw reply
* Re: merge time
From: Sean @ 2007-07-30 11:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthew L Foster, git
In-Reply-To: <alpine.LFD.0.999.0707292011170.4161@woody.linux-foundation.org>
On Sun, 29 Jul 2007 20:16:01 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> gitk v2.6.23-rc1..
>
> to show what is new after -rc1 (or "gitk @{2.days.ago}.." to see what
> is new in _your_ tree in the last two days or whatever).
It sounds like that would be the proper way to address the issue
within Gitweb as well. Assuming the issue is users wanting to
see changes since a specific release, offering a "Commits since tag"
option or some such should resolve it.
Sean
^ permalink raw reply
* Re: "git stash" is not known to git
From: Jeff King @ 2007-07-30 11:03 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqdutb7r.fsf@lola.quinscape.zz>
On Mon, Jul 30, 2007 at 12:52:40PM +0200, David Kastrup wrote:
> How does it calculate its exec path? It would appear that it would
> not contain _either_ /usr/local/bin _or_ /opt/git/bin in my
> installation if it can't find git-stash (which should be statable in
> both places).
See exec_cmd.c:execv_git_cmd. It checks in order:
1. --exec-path= on command line
2. $GIT_EXEC_PATH from environment
3. GIT_EXEC_PATH defined at compile-time (set by Makefile from
$(gitexecdir), which is generally the same as $(bindir))
So it should have /opt/git/bin in your case, but it's possible since
that is a Makefile variable that you failed to recompile correctly after
changing its value.
> Have a command handy for checking the exec path?
git --exec-path
-Peff
^ permalink raw reply
* Re: "git stash" is not known to git
From: David Kastrup @ 2007-07-30 10:52 UTC (permalink / raw)
To: git
In-Reply-To: <20070730103720.GA11309@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jul 30, 2007 at 12:24:51PM +0200, David Kastrup wrote:
>
>> On the other hand, I am quite sure that while "git stash" did not
>> work, "git-stash" had no problem.
>
> Right. git-stash is in your PATH, but not in git's exec path (which is
> _not_ the same as PATH).
How does it calculate its exec path? It would appear that it would
not contain _either_ /usr/local/bin _or_ /opt/git/bin in my
installation if it can't find git-stash (which should be statable in
both places).
Have a command handy for checking the exec path?
Ok, this is pretty much idle speculation until I am back at the system
in question, but I have problems envisioning just what kind of goof
might have happened here.
--
David Kastrup
^ permalink raw reply
* Re: "git stash" is not known to git
From: Jeff King @ 2007-07-30 10:37 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86lkcytci4.fsf@lola.quinscape.zz>
On Mon, Jul 30, 2007 at 12:24:51PM +0200, David Kastrup wrote:
> On the other hand, I am quite sure that while "git stash" did not
> work, "git-stash" had no problem.
Right. git-stash is in your PATH, but not in git's exec path (which is
_not_ the same as PATH).
> So something bogus in git's PATH lookup would definitely appear to be
> going on: it should be hard to get the symlinks messed up badly enough
> to have one work and not the other.
Git doesn't look for subcommands in the PATH.
-Peff
^ permalink raw reply
* Re: [PATCH] add series editor support.
From: Benoit SIGOURE @ 2007-07-30 10:26 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: Josef Jeff Sipek, git
In-Reply-To: <20070730100512.GA14637@dnb.sw.ru>
[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]
On Jul 30, 2007, at 12:05 PM, Dmitry Monakhov wrote:
> Usually we have to edit series file directly (via editor).
> I think it is not bad idea to let guilt export this service.
> IMHO "guilt-series -e" it the best way to do it.
>
> Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
> ---
> guilt-series | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/guilt-series b/guilt-series
> index 62c3bb1..7594b2e 100755
> --- a/guilt-series
> +++ b/guilt-series
> @@ -3,7 +3,7 @@
> # Copyright (c) Josef "Jeff" Sipek, 2006, 2007
> #
>
> -USAGE="[-v | -g]"
> +USAGE="[-v | -g | -e]"
> . `dirname $0`/guilt
>
> while case "$#" in 0) break ;; esac
> @@ -13,13 +13,18 @@ do
> verbose=t ;;
> -g)
> gui=t ;;
> + -e)
> + edit=t ;;
> *)
> usage ;;
> esac
> shift
> done
>
> -if [ ! -z "$gui" ]; then
> +# edit -e ?
> +if [ "$edit" = "t" ]; then
> + $editor "$GUILT_DIR/$branch/series"
> +elif [ ! -z "$gui" ]; then
> [ -z "`get_top`" ] && die "No patches applied."
> bottom=`head -1 $applied | cut -d: -f1`
> top=`tail -1 $applied | cut -d: -f1`
Hi,
Why do you use string comparisons instead of initializing all the
variables to false and setting them to `:' or `true' so that you can
then write if $edit; then ... ? It's suboptimal.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: "git stash" is not known to git
From: David Kastrup @ 2007-07-30 10:24 UTC (permalink / raw)
To: git
In-Reply-To: <20070730100609.GB8829@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Since I seem to recall you working some symlink magic with your
> installation in a recent message, that might be related. Is it just
> git-stash, or are other scripts failing (try "git status")?
Hmpf. On another system (git version 1.5.3.rc3.48.g0d59d) this works.
I don't have the system at hand right now where it doesn't. So it
would be my guess that either I have not called the install-symlinks
target recently enough, or its implementation on that system has been
broken for some time.
I'll have to check this evening.
On the other hand, I am quite sure that while "git stash" did not
work, "git-stash" had no problem.
So something bogus in git's PATH lookup would definitely appear to be
going on: it should be hard to get the symlinks messed up badly enough
to have one work and not the other.
More this evening.
--
David Kastrup
^ permalink raw reply
* Re: "git stash" is not known to git
From: Junio C Hamano @ 2007-07-30 10:12 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqduutz4.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> One has to use git-stash rather than "git stash". Oversight?
Does any of the other shell-scripts work without dashes?
E.g. commit, merge, am, checkout?
If they do, then probably you are invoking older versions of
these scripts than what you think you are. "git" itself looks
at GIT_EXEC_PATH and then the $(gitexecdir) from the Makefile
when it was built for its subcommands.
Perhaps this is your "symlinked install" gone awry? I dunno.
^ permalink raw reply
* Re: (Resend)[PATCH] git-svn: Translate invalid characters in refname
From: Junio C Hamano @ 2007-07-30 10:07 UTC (permalink / raw)
To: Robert Ewald; +Cc: git, Eric Wong
In-Reply-To: <f8k9q5$927$1@sea.gmane.org>
Robert Ewald <robert.ewald@nov.com> writes:
> +sub refname {
> + my ($refname) = "refs/remotes/$_[0]->{ref_id}" ;
> +
> + # It cannot end with a slash /, we'll throw up on this because
> + # SVN can't have directories with a slash in their name, either:
> + if ($refname =~ m{/$}) {
> + die "ref: '$refname' ends with a trailing slash, this is ",
> + "not permitted by git nor Subversion\n";
> + }
> +
> + # It cannot have ASCII control character space, tilde ~, caret ^,
> + # colon :, question-mark ?, asterisk *, space, or open bracket [
> + # anywhere.
> + #
> + # Additionally, % must be escaped because it is used for escaping
> + # and we want our escaped refname to be reversible
> + $refname =~ s{([ \%~\^:\?\*\[\t])}{uc sprintf('%%%02x',ord($1))}eg;
uc of sprintf()? You meant "%%%02X"?
Other than that, looks sane to me. I presume that SVN branches
whose name would be mangled with this patch would not have been
successfully imported with older git-svn anyway, so this won't
introduce any regressions?
Eric?
^ permalink raw reply
* Re: "git stash" is not known to git
From: Jeff King @ 2007-07-30 10:06 UTC (permalink / raw)
To: git; +Cc: David Kastrup
In-Reply-To: <863az6uscz.fsf@lola.quinscape.zz>
On Mon, Jul 30, 2007 at 11:57:00AM +0200, David Kastrup wrote:
> > This looks like an incorrect installation, with git-stash in your
> > $PATH, but not in the place git looks for its commands (I don't
> > remember the exact mechanism).
>
> I don't think so: in git.c we have at lines 362ff
>
> { "show-branch", cmd_show_branch, RUN_SETUP },
> { "show", cmd_show, RUN_SETUP | USE_PAGER },
> { "stripspace", cmd_stripspace },
> { "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },
>
> So it really seems like stash is not known to git.c. Of course, I
> have no real clue about git.c's operation (or I'd have proferred a
> patch) and not right now the time to look further.
That list is for builtins; git-stash is an external shell script. See
execv_git_cmd for the list of places where it is looking for git-stash.
Since I seem to recall you working some symlink magic with your
installation in a recent message, that might be related. Is it just
git-stash, or are other scripts failing (try "git status")?
-Peff
^ permalink raw reply
* [PATCH] add series editor support.
From: Dmitry Monakhov @ 2007-07-30 10:05 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git
Usually we have to edit series file directly (via editor).
I think it is not bad idea to let guilt export this service.
IMHO "guilt-series -e" it the best way to do it.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
---
guilt-series | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/guilt-series b/guilt-series
index 62c3bb1..7594b2e 100755
--- a/guilt-series
+++ b/guilt-series
@@ -3,7 +3,7 @@
# Copyright (c) Josef "Jeff" Sipek, 2006, 2007
#
-USAGE="[-v | -g]"
+USAGE="[-v | -g | -e]"
. `dirname $0`/guilt
while case "$#" in 0) break ;; esac
@@ -13,13 +13,18 @@ do
verbose=t ;;
-g)
gui=t ;;
+ -e)
+ edit=t ;;
*)
usage ;;
esac
shift
done
-if [ ! -z "$gui" ]; then
+# edit -e ?
+if [ "$edit" = "t" ]; then
+ $editor "$GUILT_DIR/$branch/series"
+elif [ ! -z "$gui" ]; then
[ -z "`get_top`" ] && die "No patches applied."
bottom=`head -1 $applied | cut -d: -f1`
top=`tail -1 $applied | cut -d: -f1`
--
1.5.2.2
^ permalink raw reply related
* Re: "git stash" is not known to git
From: Jeff King @ 2007-07-30 10:04 UTC (permalink / raw)
To: git; +Cc: David Kastrup, Linus Torvalds
In-Reply-To: <vpqwswi2pkw.fsf@bauges.imag.fr>
On Mon, Jul 30, 2007 at 11:44:31AM +0200, Matthieu Moy wrote:
> > One has to use git-stash rather than "git stash". Oversight?
>
> This looks like an incorrect installation, with git-stash in your
> $PATH, but not in the place git looks for its commands (I don't
> remember the exact mechanism).
On a related note, is it just me, or is the following comment and related code
in git.c (introduced by Linus in 231af832) totally bogus:
/*
* We search for git commands in the following order:
* - git_exec_path()
* - the path of the "git" command if we could find it
* in $0
* - the regular PATH.
*/
We never actually look in the regular PATH since we call execv_git_cmd
(although we do still munge the PATH, apparently so shell scripts can
use git-foo syntax; see 77cb17e9). This means you can't drop "git-foo"
into your PATH and have it work as "git foo".
What is the desired behavior?
-Peff
^ permalink raw reply
* Re: "git stash" is not known to git
From: David Kastrup @ 2007-07-30 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <vpqwswi2pkw.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> One has to use git-stash rather than "git stash". Oversight?
>
> This looks like an incorrect installation, with git-stash in your
> $PATH, but not in the place git looks for its commands (I don't
> remember the exact mechanism).
I don't think so: in git.c we have at lines 362ff
{ "show-branch", cmd_show_branch, RUN_SETUP },
{ "show", cmd_show, RUN_SETUP | USE_PAGER },
{ "stripspace", cmd_stripspace },
{ "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },
So it really seems like stash is not known to git.c. Of course, I
have no real clue about git.c's operation (or I'd have proferred a
patch) and not right now the time to look further.
--
David Kastrup
^ permalink raw reply
* Re: "git stash" is not known to git
From: Matthieu Moy @ 2007-07-30 9:44 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqduutz4.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> One has to use git-stash rather than "git stash". Oversight?
This looks like an incorrect installation, with git-stash in your
$PATH, but not in the place git looks for its commands (I don't
remember the exact mechanism).
--
Matthieu
^ permalink raw reply
* "git stash" is not known to git
From: David Kastrup @ 2007-07-30 9:22 UTC (permalink / raw)
To: git
One has to use git-stash rather than "git stash". Oversight?
--
David Kastrup
^ permalink raw reply
* local git clone problem
From: Nikita V. Youshchenko @ 2007-07-30 8:42 UTC (permalink / raw)
To: git
Hello.
I'm trying to clone a local git repository and it fails:
nikita@blacky:~/linux-2.6> git clone -l -s -n . ../new
Initialized empty Git repository in /home/nikita/new/.git/
/usr/bin/git-clone: line 381: cd: /home/nikita/new/.git/refs/remotes/origin: No such file or directory
The command is [almost] from git-clone(1) examples.
Examining .git in the new directory after the error:
nikita@blacky:~/new> ls -aR
.:
./ ../ .git/
./.git:
./ ../ branches/ config description HEAD hooks/ info/ objects/ refs/
./.git/branches:
./ ../
./.git/hooks:
./ applypatch-msg post-commit post-update pre-commit update
../ commit-msg post-receive pre-applypatch pre-rebase
./.git/info:
./ ../ exclude
./.git/objects:
./ ../ info/ pack/
./.git/objects/info:
./ ../ alternates
./.git/objects/pack:
./ ../
./.git/refs:
./ ../ heads/ tags/
./.git/refs/heads:
./ ../
./.git/refs/tags:
... (same as in .git/refs/tags/ of the original directory)
Looks like for some reason, .git/refs/remotes in the new directory is
not created, but referenced.
Original repository was created by 'git init' and then populated with several
'git remote add' and 'git remote update' commands.
This is with debian package git-core 1:1.5.2.1-1~bpo.1 (current debian
etch-backports version)
Is this a bug?
If not, what I'm doing wrong?
Is it possible to manually 'fix' the original directory such that local
clones from it will become possible?
Nikita
^ permalink raw reply
* (Resend)[PATCH] git-svn: Translate invalid characters in refname
From: Robert Ewald @ 2007-07-30 9:08 UTC (permalink / raw)
To: git
In git some characters are invalid as documented
in git-check-ref-format. In subversion these characters might
be valid, so a translation is required.
This patch does this translation by url escaping characters, that
are not allowed.
Credit goes to Eric Wong, martin f. krafft and Jan Hudec
Signed-off-by: Robert Ewald <robewald@gmx.net>
---
Second posting of translating characters. I hope I got it right this
time. Thanks to Alex for taking the time to point me to
Documentation/SubmittingPatches.
git-svn.perl | 38 +++++++++++++++++++++++++++++++++++---
1 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 6c692a7..bc55d05 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -938,8 +938,8 @@ sub resolve_local_globs {
foreach (command(qw#for-each-ref --format=%(refname) refs/remotes#)) {
next unless m#^refs/remotes/$ref->{regex}$#;
my $p = $1;
- my $pathname = $path->full_path($p);
- my $refname = $ref->full_path($p);
+ my $pathname = desanitize_refname($path->full_path($p));
+ my $refname = desanitize_refname($ref->full_path($p));
if (my $existing = $fetch->{$pathname}) {
if ($existing ne $refname) {
die "Refspec conflict:\n",
@@ -1239,7 +1239,39 @@ sub new {
$self;
}
-sub refname { "refs/remotes/$_[0]->{ref_id}" }
+sub refname {
+ my ($refname) = "refs/remotes/$_[0]->{ref_id}" ;
+
+ # It cannot end with a slash /, we'll throw up on this because
+ # SVN can't have directories with a slash in their name, either:
+ if ($refname =~ m{/$}) {
+ die "ref: '$refname' ends with a trailing slash, this is ",
+ "not permitted by git nor Subversion\n";
+ }
+
+ # It cannot have ASCII control character space, tilde ~, caret ^,
+ # colon :, question-mark ?, asterisk *, space, or open bracket [
+ # anywhere.
+ #
+ # Additionally, % must be escaped because it is used for escaping
+ # and we want our escaped refname to be reversible
+ $refname =~ s{([ \%~\^:\?\*\[\t])}{uc sprintf('%%%02x',ord($1))}eg;
+
+ # no slash-separated component can begin with a dot .
+ # /.* becomes /%2E*
+ $refname =~ s{/\.}{/%2E}g;
+ # It cannot have two consecutive dots .. anywhere
+ # .. becomes %2E%2E
+ $refname =~ s{\.\.}{%2E%2E}g;
+
+ $refname;
+}
+
+sub desanitize_refname {
+ my ($refname) = @_;
+ $refname =~ s{%(?:([0-9A-F]{2}))}{chr hex($1)}eg;
+ $refname;
+}
sub svm_uuid {
my ($self) = @_;
--
1.5.3.rc3-dirty
^ permalink raw reply related
* Re: [git gui] Update to it.po pushed to the mob branch
From: Michael @ 2007-07-30 8:57 UTC (permalink / raw)
To: git; +Cc: Paolo Ciarrocchi
In-Reply-To: <4d8e3fd30707291126g5638fea3pc8186c188d49fe5e@mail.gmail.com>
On Sunday 29 July 2007 20:26, Paolo Ciarrocchi wrote:
> I've just updated the Italian translation of git-gui
> and pushed it into mob branch.
I've just updated your update :). The translation is mostly
complete (although quite rough). The only things left
are related to "fast forward merge" and "tracking branch":
I don't know how to translate these...
I hope I didn't mess up some of your translations... :)
^ permalink raw reply
* Re: merge time
From: Jeff King @ 2007-07-30 8:41 UTC (permalink / raw)
To: david
Cc: Steffen Prohaska, Shawn O. Pearce, Junio C Hamano, Linus Torvalds,
Matthew L Foster, git
In-Reply-To: <Pine.LNX.4.64.0707300133210.6478@asgard.lang.hm>
On Mon, Jul 30, 2007 at 01:34:55AM -0700, david@lang.hm wrote:
> yes, but this entire thread was an attempt to avoid browsing the history and
> instead figure out the relationships between commits by dates. so the people
> wanting this don't care how ugly it makes the history (but since they want
> to do this in other people's repositories this won't work for them either)
I think we drifted a bit from that with Steffen's original message...
If you followed a strict policy of always merging topics to a "base"
branch as your first parent, then never allowing fast forwards should
allow a very easy-to-read history in gitk. The left-most line of commits
would simply be a record of topics getting merged in, and would never
contain any "non-base" commits.
-Peff
^ permalink raw reply
* Re: merge time
From: david @ 2007-07-30 8:34 UTC (permalink / raw)
To: Jeff King
Cc: Steffen Prohaska, Shawn O. Pearce, Junio C Hamano, Linus Torvalds,
Matthew L Foster, git
In-Reply-To: <20070730083223.GB3150@coredump.intra.peff.net>
On Mon, 30 Jul 2007, Jeff King wrote:
> On Mon, Jul 30, 2007 at 10:25:25AM +0200, Steffen Prohaska wrote:
>
>> I agree. But I think except for being 'fake' there shouldn't be any
>> problems with the extra commit.
>
> Problems, no. But it will look ugly when browsing history. :)
yes, but this entire thread was an attempt to avoid browsing the history
and instead figure out the relationships between commits by dates. so the
people wanting this don't care how ugly it makes the history (but since
they want to do this in other people's repositories this won't work for
them either)
David Lang
^ permalink raw reply
* Re: [GUILT PATCH 0/4] Add guards to guilt
From: Eric Lesh @ 2007-07-30 8:32 UTC (permalink / raw)
To: Josef Sipek; +Cc: jsipek, git
In-Reply-To: <20070730035443.GC22017@filer.fsl.cs.sunysb.edu>
Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> I know I've been bad about forcing even myself to write new regression
> tests. Your patches modify things significantly enough, that I'd like to see
> some regression tests cases to make sure that user's data is not eaten
> (e.g., a bug in the guard setting code could blow away the series file =>
> very bad).
>
Yeah, I'll try and make one. 070-guards.sh to test guilt-guard and
guilt-select plus pushing and popping?
There's also sed -i in a few places. For integrity purposes, are a cp
and sed better?
>> This introduces the command `get_guarded_series`, which just lists
>> patches that are to be applied based on the guards. It also makes
>> eidx=`wc -l < $applied`
>> inaccurate if you're using it as an index into get_series.
>
> The index-based patch finding is a bit nasty anyway.
>
>> If you change guards on a patch or select a different guard while
>> patches are applied, some commands might get confused. guilt pop -a will fix
>> everything though. Usually, it's best to pop -a before fiddling with
>> guards anyway.
>
> Is this a problem with other projects' implementations of guards as well?
> Perhaps printing a warning if a new guard is set when there are applied
> patches would be in order?
>
Yeah, they have this problem too, but tell you so when you select, so
guilt should too. I'll fix that up. Mercurial also has two options
which do the popping and reapplying for you, which I'll try and implement also.
Thanks a lot for the review. Things were pretty ugly, but with your
help it should look much better.
Eric
^ permalink raw reply
* Re: merge time
From: Jeff King @ 2007-07-30 8:32 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Shawn O. Pearce, Junio C Hamano, Linus Torvalds, Matthew L Foster,
git
In-Reply-To: <E1575DD6-AC8C-49FD-A765-801A19E1FA73@zib.de>
On Mon, Jul 30, 2007 at 10:25:25AM +0200, Steffen Prohaska wrote:
> I agree. But I think except for being 'fake' there shouldn't be any
> problems with the extra commit.
Problems, no. But it will look ugly when browsing history. :)
-Peff
^ permalink raw reply
* Re: merge time
From: Jeff King @ 2007-07-30 8:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steffen Prohaska, Shawn O. Pearce, Linus Torvalds,
Matthew L Foster, git
In-Reply-To: <7vhcnml2no.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 30, 2007 at 01:24:43AM -0700, Junio C Hamano wrote:
> But it is not hard. If it is a fast forward in reality but you
> are marking it as a real merge by creating a merge commit, then:
Of course, I was not thinking right. I was considering the difficulty of
invoking the merge machinery, but of course by definition for a
fast-forward you don't have to.
> when other is a fast forward of HEAD would do:
>
> git commit-tree other^{tree} -p HEAD -p other
Yes, that makes sense.
-Peff
^ permalink raw reply
* Re: merge time
From: Junio C Hamano @ 2007-07-30 8:24 UTC (permalink / raw)
To: Jeff King
Cc: Steffen Prohaska, Shawn O. Pearce, Linus Torvalds,
Matthew L Foster, git
In-Reply-To: <20070730081439.GA907@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But I think making a "fake" commit to force non-fast-forward is the
> wrong thing. You really want to make your "extra" commit be the merge
> that wouldn't have happened (which unfortunately is not as simple as
> just creating a commit by hand, since you have to actually _do_ the
> merge to get the tree).
I do agree that if you really want to create a commit instead of
allowing a fast forward, you really should create a proper merge
commit.
But it is not hard. If it is a fast forward in reality but you
are marking it as a real merge by creating a merge commit, then:
- The tree is obviously the merged branch that is a fast
forward of your old HEAD;
- The first parent of the resulting merge is your old HEAD; and
- The second parent of the resulting merge is the merged
branch.
So:
git merge --no-fast-forward other
when other is a fast forward of HEAD would do:
git commit-tree other^{tree} -p HEAD -p other
^ 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