* Re: Rebase semantic and cherry-pick
From: Jakub Narebski @ 2006-03-30 1:59 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0603291102440.15714@g5.osdl.org>
Linus Torvalds wrote:
> In contrast, here's an alternate workflow that is much easier to explain,
> and doesn't involve "rebase" at all:
>
> git checkout his
> git cherry-pick origin..mine
[...]
> Now, "git cherry-pick" doesn't actually support the above format, and I'm
> not saying that the "git rebase" name itself is evil. I think we could fix
> "git rebase" to work better, but the semantics - the way they are
> _designed_ right now - are just horrible.
Perhaps if possible also have
git cherry-pick --whole-branch branchname
meaning
git cherry-pick branchname:begining..branchname:HEAD
--
Jakub Narebski
^ permalink raw reply
* sending git-format-patch files with mailx.
From: David Ho @ 2006-03-29 20:36 UTC (permalink / raw)
To: git
Very stupid question.
I have patches created by git-format-patch. However I suppose I can
send it off directly using mailx, but I have a hard time figuring how
this is done.
Someone here can probably answer this in a second.
Thanks in advance,
David
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Junio C Hamano @ 2006-03-29 20:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603291102440.15714@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> In contrast, here's an alternate workflow that is much easier to explain,
> and doesn't involve "rebase" at all:
>
> git checkout his
> git cherry-pick origin..mine
Yes, I think it would be good to deprecate/discard the current
rebase and make cherry-pick the recommended workflow.
Optionally. I've been thinking about not using git-cherry while
cherrypicking, because falling back to three-way merge seems to
work equally well in dealing with "patch already applied" case.
Anyway, teaching the range notation to cherry-pick would be
something like this, I suppose.
---
diff --git a/git-cherry-pick.sh b/git-cherry-pick.sh
new file mode 100755
index 0000000..72a3828
--- /dev/null
+++ b/git-cherry-pick.sh
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+. git-sh-setup
+
+git-format-patch --stdout --full-index -k "$@" |
+git-am --binary -3 -k
diff --git a/Makefile b/Makefile
index d945546..e130d8c 100644
--- a/Makefile
+++ b/Makefile
@@ -114,7 +114,7 @@ ### --- END CONFIGURATION SECTION ---
SCRIPT_SH = \
git-add.sh git-bisect.sh git-branch.sh git-checkout.sh \
- git-cherry.sh git-clone.sh git-commit.sh \
+ git-cherry.sh git-cherry-pick.sh git-clone.sh git-commit.sh \
git-count-objects.sh git-diff.sh git-fetch.sh \
git-format-patch.sh git-log.sh git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
@@ -139,7 +139,7 @@ SCRIPT_PYTHON = \
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- git-cherry-pick git-show git-status
+ git-show git-status
# The ones that do not have to link with lcrypto nor lz.
SIMPLE_PROGRAMS = \
@@ -484,9 +484,6 @@ common-cmds.h: Documentation/git-*.txt
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.py >$@
chmod +x $@
-
-git-cherry-pick: git-revert
- cp $< $@
git-show: git-whatchanged
cp $< $@
^ permalink raw reply related
* RE: Problem with git bisect between 2.6.15 and 2.6.16
From: Luck, Tony @ 2006-03-29 19:43 UTC (permalink / raw)
To: Greg Lee, git; +Cc: sean
> This was progressing fine until I ran into an issue that makes the kernel unstable causing
> it to crash at semi-random times. I'm down to about 350 commits left in the bisect. I've
> tried:
>
> git reset --hard HEAD~3
>
>no luck, same problem, unstable
You can try "git bisect visualize" to invoke gitk on the remaining commits, and
then pick a likely looking stable point for your next test. This is documented
reasonably well in the git Documentation/howto/isolate-bugs-with-bisect.txt
-Tony
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Linus Torvalds @ 2006-03-29 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603291102440.15714@g5.osdl.org>
On Wed, 29 Mar 2006, Linus Torvalds wrote:
>
> Right now, the sequence is:
>
> git checkout mine # if required
> git rebase --onto his origin
vs
> git checkout his
> git cherry-pick origin..mine
Btw, I realize that the advantage of "git rebase" is that it doesn't
change somebody elses branch. However, we'd still be a lot better off with
us simply doing the equivalent of something like
git checkout -b new-mine his &&
git cherry-pick origin..mine &&
git rename-branch -f new-mine mine
instead of what git-rebase does now.
Linus
^ permalink raw reply
* RE: Problem with git bisect between 2.6.15 and 2.6.16
From: Greg Lee @ 2006-03-29 19:28 UTC (permalink / raw)
To: git; +Cc: 'sean', 'Tony Luck'
In-Reply-To: <12c511ca0603271622n6e4614b2s6f936469863efd9d@mail.gmail.com>
> You'll need to invert "good" and bad" for this. I.e. mark 2.6.15 as good, 2.6.16 as
bad, and
> then as you test mark kernels with the bug as good, and ones without as bad. Try not to
go
> insane while working in this inverted parallel universe :-)
>
> -Tony
This was progressing fine until I ran into an issue that makes the kernel unstable causing
it to crash at semi-random times. I'm down to about 350 commits left in the bisect. I've
tried:
git reset --hard HEAD~3
no luck, same problem, unstable
then I tried --hard HEAD~50
no luck, same problem, unstable
I'm concerned about moving too much further in the "~" direction, will this cause me other
problems?
Greg
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Linus Torvalds @ 2006-03-29 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkutc36w.fsf@assigned-by-dhcp.cox.net>
On Tue, 28 Mar 2006, Junio C Hamano wrote:
>
> Having said that, you have been able to say format-patch A..B
> C..D E..F for quite some time (since November 21, 2005).
Yes, and the documentation still talks only about the old insane format..
> Rebase is even more strange, especially with --onto. When you do
>
> $ rebase --onto his origin mine
>
> in this picture,
>
> *---x---x---o---o---o---o
> \ ^origin ^mine
> .---.---.---.
> ^his
>
> you are discarding two 'x' commits, and lost-found is the only
> thing that would help you to recover them.
.. and this is largely because the whole interface is broken.
The breakage shows up as inflexibility and having a hard time explaining
what the thing does. It shows up as confusion about the usage, and about
the meaning of a simple command line.
For example, in the most trivial format, doing a
git rebase <branchname>
the _logical_ thing (from just reading the command) to believe the above
does is to think that it rebases the named branch. I pretty much guarantee
that that is what any native English speaker would think it does, if they
thought about it.
The fact that it actually does the _reverse_, and rebases not the named
branch, but the branch you are on right now.
The fact that when things go south, the old branch has gotten lost (unless
you remember about ORIG_HEAD) is all related to the same thing. It's just
a very non-intuitive interface.
That was fine when people weren't supposed to use it, and it was doing
something very very special, but that has clearly changed over time. Now
people are encouraged to use it, it's pretty well-known, and even new git
users seem to want to do it.
I think "git rebase" is a lost cause. It's just fundamentally a very very
badly designed command, because it does everything the wrong way around.
I personally believe that the _sane_ way of doing rebasing is to
- get rid of "git rebase" entirely
- teach "git cherry-pick" to take a _range_ of commits instead.
Lookie here, let's look at your example a bit more (which in turn comes
from the original question that started this thread):
*---x---x---o---o---o---o
\ ^origin ^mine
.---.---.---.
^his
We have three branch points, and we want to move the commits on "mine"
from "origin" onto "his". How would you do this so that it's _not_
confusing, and so that you can explain to a newbie user what he is doing,
_especially_ if things go wrong in the middle?
Right now, the sequence is:
git checkout mine # if required
git rebase --onto his origin
and if things go south during the rebase, it's immediately total chaos,
and you really _really_ need to understand what you are doing.
The above just doesn't make any sense. It's hard to explain why you would
do something like that.
In contrast, here's an alternate workflow that is much easier to explain,
and doesn't involve "rebase" at all:
git checkout his
git cherry-pick origin..mine
Notice what this does? Show these two sequences to anybody who has some
basic familiarity with git terminology, but has perhaps never actually
used it, and ask them what the two sequences do. I pretty much guarantee
that the second sequence will make sense and get people to generally pick
the right answer, while the first sequence will make people maybe _guess_
the right answer, but it's not intuitive.
In particular, what do you think happens when a patch in the series
doesn't apply under the two circumstances? Which workflow has the
"intuitive" way of recovering, and which does not?
Right. The second one has a very intuitive way to recover. In fact, it's
so intuitive that the answer may be "ok, I'll skip that one commit
entirely because I don't know how to resolve it, and instead cherry-pick
the rest, and ask the original author to cherry-pick it for me later". And
doing so is as easy as
git reset --hard # undo the mess from the failed one,
# the same way we always do for all
# other failed things
git cherry-pick next..mine # do the rest
See? That's a very logical thing to do. It's different from "git rebase",
but it's different in a _good_ way.
In contrast, the "rebase" conflict resolution is pretty damn esoteric, and
using a simple "gitk --all" when things go wrong won't help you pick
things up at all.
Now, "git cherry-pick" doesn't actually support the above format, and I'm
not saying that the "git rebase" name itself is evil. I think we could fix
"git rebase" to work better, but the semantics - the way they are
_designed_ right now - are just horrible.
Linus
^ permalink raw reply
* Re: Git terminology
From: Sébastien Pierre @ 2006-03-29 16:11 UTC (permalink / raw)
To: Junio C Hamano, Git ML
In-Reply-To: <7vodzp9r8r.fsf@assigned-by-dhcp.cox.net>
On Wed, 29 Mar 2006 07:59:16 -0800
Junio C Hamano <junkio@cox.net> wrote:
> Probably we can just say "ref" where we say "refname".
>
> A fast-forward is where you have a revision and you are
> "merging" other's change that happen to be a descendant what you
> have. In such a case, you do not make a new merge commit but
> just update to his revision. That is:
>
> o---o---o---o his o---o---o---o his
> / -> / \
> o---o---o---o yours o---o---o---o-------* yours
>
> updating to his needs a merge like above, but in this case:
>
> o---o---o---o his o---o---o---o his = yours
> / -> /
> o---o yours o---o
>
> you just update to his.
Ah, ok. The diagrams are really helpful to get what "fast forward" is.
Thanks !
-- Sébastien
^ permalink raw reply
* Re: Git terminology
From: Junio C Hamano @ 2006-03-29 15:59 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: git
In-Reply-To: <20060329052113.6a773480.sebastien@xprima.com>
Sébastien Pierre <sebastien@xprima.com> writes:
> In the process of learning git, and browsing the docs, I
> realized that many particular terms are used, but I had
> difficulties finding their definitions.
I had difficulties reading your message. Please fold your lines.
> Among those I found a bit arcane, there are (in no particular
> order) "refspec", "rebase", "rewound", "pickaxe", "refnames",
> "objectnames" ,"refnames", "fast-forward update".
I see some are missing from our glossary but some others are
found there.
refspec is used by fetch and push to describe the mapping
between remote ref and local ref. E.g. "git fetch $URL
refs/heads/master:refs/heads/origin" means "grab the master
branch head from there and store it as my origin branch head".
"git push $URL refs/heads/master:refs/heads/to-upstream" for
"publish my master branch head as to-upstream master head at
$URL".
Probably we can just say "ref" where we say "refname".
Probably we can just say "ref" where we say "refname".
A fast-forward is where you have a revision and you are
"merging" other's change that happen to be a descendant what you
have. In such a case, you do not make a new merge commit but
just update to his revision. That is:
o---o---o---o his o---o---o---o his
/ -> / \
o---o---o---o yours o---o---o---o-------* yours
updating to his needs a merge like above, but in this case:
o---o---o---o his o---o---o---o his = yours
/ -> /
o---o yours o---o
you just update to his.
A related concept is "being already up-to-date". In the latter
picture, if he attempts to "merge" your changes and notices he
is simply ahead of you (i.e. his revision is a descendant of
yours), nothing happens.
> If some of you are willing to detail/explain/define those
> terms (and some others not mentioned here), I would be glad to
> collect the definitions and make a "git terminology" document.
Thanks, and what J Bruce Fields already said.
^ permalink raw reply
* Re: Git terminology
From: J. Bruce Fields @ 2006-03-29 15:31 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: Git ML
In-Reply-To: <20060329052113.6a773480.sebastien@xprima.com>
On Wed, Mar 29, 2006 at 05:21:13AM -0500, Sébastien Pierre wrote:
> If some of you are willing to detail/explain/define those terms (and
> some others not mentioned here), I would be glad to collect the
> definitions and make a "git terminology" document.
See Documentation/glossary.txt. It's missing some of the terms your
looking for, but I'm sure patches would be accepted.
--b.
^ permalink raw reply
* Git terminology
From: Sébastien Pierre @ 2006-03-29 10:21 UTC (permalink / raw)
To: Git ML
Hi all,
In the process of learning git, and browsing the docs, I realized that many particular terms are used, but I had difficulties finding their definitions.
Among those I found a bit arcane, there are (in no particular order) "refspec", "rebase", "rewound", "pickaxe", "refnames", "objectnames" ,"refnames", "fast-forward update".
Also, doing a "grep -rohE '<[a-z\-]+>' * | sort | uniq" in git source tree gave me the list of "parameter types" for git commands, where some would benefit from a formal definition : <base>, <blob>, <branch>, <branchname>, <comitish>, <tree>, <tree-ish>, <head>, <headsha>, <refspec>, and so on. Of course, some of these terms are already explained in the man pages, but it would be nice to have a "git terminlogy reference".
If some of you are willing to detail/explain/define those terms (and some others not mentioned here), I would be glad to collect the definitions and make a "git terminology" document.
-- Sébastien
^ permalink raw reply
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Petr Baudis @ 2006-03-29 15:08 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200603291704.14870.blaisorblade@yahoo.it>
Dear diary, on Wed, Mar 29, 2006 at 05:04:14PM CEST, I got a letter
where Blaisorblade <blaisorblade@yahoo.it> said that...
> Sorry, that's just an old patch then, I didn't note you did it yourself.
>
> I wrote it before you had the 1.1 dependency and didn't notice you made
> something similar.
Well, I've just applied your patch :-) :
commit 4e1cd8ac4815bdc3e6671a2a5a266a9ca675630d
author Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Thu, 19 Jan 2006 22:16:46 +0100
committer Petr Baudis <xpasky@machine.or.cz> Sat, 21 Jan 2006 02:21:13 +0100
Kind regards,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Blaisorblade @ 2006-03-29 15:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060329145427.GI27689@pasky.or.cz>
On Wednesday 29 March 2006 16:54, Petr Baudis wrote:
> Dear diary, on Wed, Mar 29, 2006 at 04:25:59PM CEST, I got a letter
> where Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> said that...
> > Pass the new --directory option (from git 1.1) to git-ls-others for
> > list_untracked_files, as does git-status - it's very useful.
> > Probably this must be deferred to when the git 1.1 dependency is added,
> > however please queue it for then.
> Uh, I'm confused. Cogito now depends on git-1.1, and
> as you can see, if list_untracked_files was pssed the 'squashdirs'
> option, it will already pass it. What cg command would you like to
> squash dirs except cg-status?
Sorry, that's just an old patch then, I didn't note you did it yourself.
I wrote it before you had the 1.1 dependency and didn't notice you made
something similar.
Bye and sorry for the noise
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Petr Baudis @ 2006-03-29 14:54 UTC (permalink / raw)
To: Paolo 'Blaisorblade' Giarrusso; +Cc: git
In-Reply-To: <20060329142559.12059.52795.stgit@zion.home.lan>
Dear diary, on Wed, Mar 29, 2006 at 04:25:59PM CEST, I got a letter
where Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> said that...
> Pass the new --directory option (from git 1.1) to git-ls-others for
> list_untracked_files, as does git-status - it's very useful.
>
> Probably this must be deferred to when the git 1.1 dependency is added, however
> please queue it for then.
Uh, I'm confused. Cogito now depends on git-1.1, and
> diff --git a/cg-Xlib b/cg-Xlib
> index 2b93c11..3150470 100644
> --- a/cg-Xlib
> +++ b/cg-Xlib
> @@ -274,7 +274,7 @@ list_untracked_files()
> fi
> local listdirs=
> [ "$squashflag" = "squashdirs" ] && listdirs=--directory
> - git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
> + git-ls-files -z --others --directory $listdirs "${EXCLUDE[@]}"
as you can see, if list_untracked_files was pssed the 'squashdirs'
option, it will already pass it. What cg command would you like to
squash dirs except cg-status?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [PATCH] Pass --directory to git-ls-files for stg status
From: Paolo 'Blaisorblade' Giarrusso @ 2006-03-29 14:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Requires GIT 1.1.0 at least (don't know if this was backported in 1.0).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
stgit/git.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index 40d54ef..e8c816d 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -194,8 +194,8 @@ def __tree_status(files = None, tree_id
if noexclude:
extra_exclude = base_exclude = []
- lines = _output_lines(['git-ls-files', '--others'] + base_exclude
- + extra_exclude)
+ lines = _output_lines(['git-ls-files', '--others', '--directory']
+ + base_exclude + extra_exclude)
cache_files += [('?', line.strip()) for line in lines]
# conflicted files
^ permalink raw reply related
* [PATCH] Unclutter cg status with --directory as GIT does
From: Paolo 'Blaisorblade' Giarrusso @ 2006-03-29 14:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Pass the new --directory option (from git 1.1) to git-ls-others for
list_untracked_files, as does git-status - it's very useful.
Probably this must be deferred to when the git 1.1 dependency is added, however
please queue it for then.
Thanks.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
cg-Xlib | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 2b93c11..3150470 100644
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -274,7 +274,7 @@ list_untracked_files()
fi
local listdirs=
[ "$squashflag" = "squashdirs" ] && listdirs=--directory
- git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
+ git-ls-files -z --others --directory $listdirs "${EXCLUDE[@]}"
}
pick_id()
^ permalink raw reply related
* Re: [PATCH] Support for pickaxe matching regular expressions
From: Petr Baudis @ 2006-03-29 13:09 UTC (permalink / raw)
To: Linus Torvalds, Johannes Schindelin; +Cc: Mark Wooding, git
In-Reply-To: <20060329001633.GF27689@pasky.or.cz>
Dear diary, on Wed, Mar 29, 2006 at 02:16:33AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> The regex.h library is a rather stupid interface and I like pcre too, but
> with any luck it will be everywhere we will want to run Git on, it being
> POSIX.2 and all. I'm not sure if we can expect platforms like AIX to
> conform to POSIX.2 or if win32 has regex.h. We might add a flag to
> Makefile if there is a portability trouble potential.
Dear diary, on Wed, Mar 29, 2006 at 01:42:00PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> We already use regex.h (probably my fault).
Indeed, and since noone complained yet, the portability consideration is
apparently a non-issue.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Johannes Schindelin @ 2006-03-29 11:42 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne2jf9t.s3g.mdw@metalzone.distorted.org.uk>
Hi,
On Tue, 28 Mar 2006, Mark Wooding wrote:
> Jason Riedy <ejr@EECS.Berkeley.EDU> wrote:
>
> > P.S. For the whole finding-a-function-name business, some of
> > us are using git on fixed-format Fortran. Every non-comment
> > line begins with whitespace... ;) And in free format, many
> > people don't add that first indentation within subroutines.
>
> Urgh. So, which regex library do people want to use? ;-) (My vote's
> for pcre.)
My vote is against adding such a dependency for so little gain. We already
use regex.h (probably my fault).
Ciao,
Dscho
^ permalink raw reply
* Re: Is 'merge' in your path?
From: Romain Francoise @ 2006-03-29 10:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Andreas Ericsson, git
In-Reply-To: <tnxmzf9sh7k.fsf@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> Are there any features in "merge" and not available in "diff3"?
`merge' from GNU RCS is just a wrapper around diff3.
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
^ permalink raw reply
* Re: Is 'merge' in your path?
From: Catalin Marinas @ 2006-03-29 10:01 UTC (permalink / raw)
To: Brown, Len; +Cc: Andreas Ericsson, git
In-Reply-To: <CFF307C98FEABE47A452B27C06B85BB6046AA9@hdsmsx411.amr.corp.intel.com>
"Brown, Len" <len.brown@intel.com> wrote:
>>What does "which merge" tell you? If it turns up blank, you know the
>>problem. The merge program is usually found in the rcs package.
>
> blank indeed. I guess I don't have rcs on this laptop.
Actually, I think git could use diff3 directly and not rely on "merge"
from rcs which seems to be equivalent to "diff3 -m -E" (it might even
call diff3, I'm not sure).
Are there any features in "merge" and not available in "diff3"?
--
Catalin
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Mark Wooding @ 2006-03-29 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q1ihzio.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Asciidoc?
>
> . enumerated one
> this is one item
I thought about this, and decided that missing these was a good thing,
because item heads are probably too low-level. I'd rather go for
section or subsection headings.
> It's just a heuristic, so there are only two things we could
> sensibly do. Either we keep it absolutely stupid to save our
> code and sanity, or we give full configurability via -F regexp
> to the end users.
I'm already thinking about that...
-- [mdw]
^ permalink raw reply
* RE: Is 'merge' in your path?
From: Brown, Len @ 2006-03-29 9:06 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
>What does "which merge" tell you? If it turns up blank, you know the
>problem. The merge program is usually found in the rcs package.
blank indeed. I guess I don't have rcs on this laptop.
thanks,
-Len
^ permalink raw reply
* Re: Is 'merge' in your path?
From: Andreas Ericsson @ 2006-03-29 8:47 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <200603290342.40970.len.brown@intel.com>
Len Brown wrote:
> trying to do a merge on my laptop using git as of today,
> but it bombs out. anybody seen this?
>
> lenb@toshiba:~/src> git --version
> git version 1.3-rc1.GIT
>
> lenb@toshiba:~/src/linux-acpi-2.6> /lab/bin/git.update test
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
....
> Failed to execute 'merge'. merge(1) is used as the file-level merge tool. Is
> 'merge' in your path?
> No merge strategy handled the merge.
> lenb@toshiba:~/src/linux-acpi-2.6> which git-merge
> /home/lenb/bin/git-merge
> lenb@toshiba:~/src/linux-acpi-2.6> which git
> /home/lenb/bin/git
> lenb@toshiba:~/src/linux-acpi-2.6>
What does "which merge" tell you? If it turns up blank, you know the
problem. The merge program is usually found in the rcs package.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Is 'merge' in your path?
From: Len Brown @ 2006-03-29 8:42 UTC (permalink / raw)
To: git
trying to do a merge on my laptop using git as of today,
but it bombs out. anybody seen this?
lenb@toshiba:~/src> git --version
git version 1.3-rc1.GIT
lenb@toshiba:~/src/linux-acpi-2.6> /lab/bin/git.update test
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging test with 224b148ef7c9a00642eb33dbdf62f2840bde974f
Merging:
9dc2a5c16ba732595afa926aabbf07efaef40b92 Pull trivial into test branch
224b148ef7c9a00642eb33dbdf62f2840bde974f Merge branch 'for-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394
found 1 common ancestor(s):
35ab0e88c63fb8e61013011560ad10e6200b5ee0 Merge branch 'release' of
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
Removing arch/sparc64/lib/find_bit.c
Removing drivers/scsi/qla2xxx/ql6312.c
Removing include/asm-arm/arch-h720x/param.h
Removing include/asm-arm/arch-imx/irq.h
Removing drivers/usb/media/pwc/pwc-kiara.c
Removing include/asm-ppc/xparameters.h
Removing drivers/i2c/busses/i2c-frodo.c
Removing include/asm-arm/arch-lh7a40x/irq.h
Removing drivers/char/rio/riopcicopy.c
Auto-merging Documentation/kernel-parameters.txt
merge -L test/Documentation/kernel-parameters.txt -L
orig/Documentation/kernel-parameters.txt -L
224b148ef7c9a00642eb33dbdf62f2840bde974f/Documentation/kernel-parameters.txt .merge_file_2KLpUR .merge_file_H6NRcP .merge_file_WLV6HQ:
No such file or directory
Failed to execute 'merge'. merge(1) is used as the file-level merge tool. Is
'merge' in your path?
No merge strategy handled the merge.
lenb@toshiba:~/src/linux-acpi-2.6> which git-merge
/home/lenb/bin/git-merge
lenb@toshiba:~/src/linux-acpi-2.6> which git
/home/lenb/bin/git
lenb@toshiba:~/src/linux-acpi-2.6>
^ permalink raw reply
* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-29 6:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17449.48630.370867.10251@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> That's brilliant. Thank you! With the patch to gitk below, the
> graph display on Linus' example looks much saner.
Indeed this looks much saner. Thanks.
^ 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