* Re: Mergetool generating blank files (1.5.3)
From: Russ Brown @ 2007-09-27 19:00 UTC (permalink / raw)
To: Pierre Habouzit, Kelvie Wong, git
In-Reply-To: <20070927185707.GC12427@artemis.corp>
Pierre Habouzit wrote:
> On Thu, Sep 27, 2007 at 06:31:19PM +0000, Kelvie Wong wrote:
>> At work, I've been using a git-svn import for my daily workflow (still
>> somewhat of a git newbie, but now has come to the point where it's
>> tough to work without it), and while rebasing from svn (on a rather
>> old branch), I found that the mergetool option does not work too well
>> for me.
>
> Which tool are you using ? kdiff3 ? I've noticed that it often fails
> miserably, or worse, create bad merges silentely with it.
>
> And as none of the other merge tool that are supported are able to
> either do 3way merges, or have a decent UI (that definitely seems to be
> exclusive features) I've given up on git-mergetool (and to be fair, it
> sucks, because it could be _sooo_ useful sometimes).
>
What about meld? That does 3-way merge, and the UI is fine.
--
Russ
^ permalink raw reply
* Re: [PATCH] Add --no-rename to git-apply
From: Robin Rosenberg @ 2007-09-27 19:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709271107530.28395@racer.site>
torsdag 27 september 2007 skrev Johannes Schindelin:
> Robin said in a follow-up mail that he needs it for a payed-for SCM
> (let's describe it as TransparentBox here), which insists on explicit
> renames.
>
> But I suggest a simple script here which extracts from the diff the
> renames, which outputs a script which renames the file(s) back and then
> uses the TransparentBox' mv command:
>
> sed -n -e "/^rename from/N" \
> -e "s/^rename from \(.*\)\nrename to \(.*\)/mv \2 \1 \&\& tb mv \1 \2/p" \
> < diff.patch
>
I tried something like that (integrated in the script), and the bugger noticed
it and refused to work as exepected, but now that I think about it should be
possible to fool it. I have to give it a go again and see what really actually
went wrong.
-- robin
^ permalink raw reply
* Re: [PATCH] Add --no-rename to git-apply
From: Robin Rosenberg @ 2007-09-27 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqbozo7t.fsf@gitster.siamese.dyndns.org>
torsdag 27 september 2007 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>
> > With this option git-apply can apply a patch with a rename
> > onto the original file(s).
>
> This is troubling from both design and implementation point of
> view.
>
> * Why would this be useful? What's the point of producing the
> renaming patch if you know you would want to apply while
> ignoring the rename?
The point of producing the rename info is to find out which renames
are in it. It's only that I don't want to perform them straight away.
> * The change looks too special purpose to me. If you are
> giving the ability to deposit the result to somewhere other
> than where the patch intendes to, why limit it only to the
> preimage name? Aren't there cases where A is renamed to B
> sometime in the history, and you have a patch that talks
> about the content change A->A but the tree you have has the
> contents already in B, and you would want to apply that
> patch? It feels that this and your "ignore rename" could be
> handled much more cleanly and flexibly by preprocessing the
> patchfile.
Well it is special *purpose*, but not tied to a particuar tool. I'm
not sure whether it is necessary with other tools though. I'll
consider the preprocessing and will retry the rename-back that
Johannes suggested.
>
> * By disabling the parsing of rename header lines, you are
> disabling the sanity checking of the input done in
> gitdiff_verify_name() called from gitdiff_oldname() and
> gitdiff_newname(). I think it is wrong for --no-rename
> option to affect the parsing of the input. If we were to do
> this, perhaps write_out_results() or one of its callee would
> be a better place to do so.
Hopefully git produces sane things so the checking shouldn't be that
important, but I also do a check before beginning with checkouts and
so on, much like git-cvsexportcommit. The check is performed without
the switch.
-- robin
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Pierre Habouzit @ 2007-09-27 19:11 UTC (permalink / raw)
To: Russ Brown; +Cc: Kelvie Wong, git
In-Reply-To: <46FBFDD7.1080300@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On Thu, Sep 27, 2007 at 07:00:39PM +0000, Russ Brown wrote:
> Pierre Habouzit wrote:
> > On Thu, Sep 27, 2007 at 06:31:19PM +0000, Kelvie Wong wrote:
> >> At work, I've been using a git-svn import for my daily workflow (still
> >> somewhat of a git newbie, but now has come to the point where it's
> >> tough to work without it), and while rebasing from svn (on a rather
> >> old branch), I found that the mergetool option does not work too well
> >> for me.
> >
> > Which tool are you using ? kdiff3 ? I've noticed that it often fails
> > miserably, or worse, create bad merges silentely with it.
> >
> > And as none of the other merge tool that are supported are able to
> > either do 3way merges, or have a decent UI (that definitely seems to be
> > exclusive features) I've given up on git-mergetool (and to be fair, it
> > sucks, because it could be _sooo_ useful sometimes).
> >
>
> What about meld? That does 3-way merge, and the UI is fine.
Indeed, it seems that since the last time I tested it, it now does
diff3 merging. I should reevaluate it :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Jeff King @ 2007-09-27 19:12 UTC (permalink / raw)
To: Pierre Habouzit, Kelvie Wong, git
In-Reply-To: <20070927185707.GC12427@artemis.corp>
On Thu, Sep 27, 2007 at 08:57:07PM +0200, Pierre Habouzit wrote:
> Which tool are you using ? kdiff3 ? I've noticed that it often fails
> miserably, or worse, create bad merges silentely with it.
>
> And as none of the other merge tool that are supported are able to
> either do 3way merges, or have a decent UI (that definitely seems to be
> exclusive features) I've given up on git-mergetool (and to be fair, it
> sucks, because it could be _sooo_ useful sometimes).
Huh? I use xxdiff all the time, and it works fine.
-Peff
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Pierre Habouzit @ 2007-09-27 19:16 UTC (permalink / raw)
To: Jeff King; +Cc: Kelvie Wong, git
In-Reply-To: <20070927191201.GA31807@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
On Thu, Sep 27, 2007 at 07:12:01PM +0000, Jeff King wrote:
> On Thu, Sep 27, 2007 at 08:57:07PM +0200, Pierre Habouzit wrote:
>
> > Which tool are you using ? kdiff3 ? I've noticed that it often fails
> > miserably, or worse, create bad merges silentely with it.
> >
> > And as none of the other merge tool that are supported are able to
> > either do 3way merges, or have a decent UI (that definitely seems to be
> > exclusive features) I've given up on git-mergetool (and to be fair, it
> > sucks, because it could be _sooo_ useful sometimes).
>
> Huh? I use xxdiff all the time, and it works fine.
I'm sorry but I find that the UI is terrible.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Junio C Hamano @ 2007-09-27 19:22 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070927130447.GH10289@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> The real question is "what does users intend when they `git push`". In
> a git/kernel/... like model, you don't think the same than in a
> svn/cvs-like model. I mean, Junio or Linus likely don't push a lot to
> their public repository. It happens probably a couple of time per day.
> While I'm at work, it happens up way more frequentely, and I then want
> to lazily type `git push` and not `git push origin <somebranch>`. it's
> too long.
>
> I'm not sure what we can do about it, but I'm pretty sure it bites a
> lot of people out there. For now I use this alias in my .gitconfig:
>
> p=!git-push origin `git-symbolic-ref HEAD`
>
> but still, it feels really wrong to me. Not to mention that git-push(1)
> says that it has a --all option that in fact is the current default
> behavior, hence sounds pretty useless.
The default is not --all but "matching branches", iow, what you
have never published yet never goes out.
Having said that, I would agree that in some workflows "I am on
this branch and I would want to push only this branch" would be
the norm, and the norm even be "and this branch 'foo' is called
identically as 'foo' at the remote site as well".
Don't worry about me when discussing to change the default.
Myself, I also often push only one or two branches. A typical
workflow for me while working on git.git is to prepare 'maint'
(if there are any changes) and 'master', push them (without
pushing 'next' and 'pu') to a private "build it to make sure"
repository I have at a k.org machine which runs RH, make sure
they are Ok, and then continue working on integrating 'next' and
'pu'. At the end of the day, I push out all four integration
branches to a separate "publish" area, but even this one, I rely
on the explicit configuration (remote.<name>.push) to push out
only the integration branches and not other branches.
We would also want to have --mirror option that acts like --all
but removes the refs from the remote that do not exist anymore,
so we will be talking about updating "git push" in the near
future anyway.
So what's the desired semantics?
The current semantics is:
"git push" says "you do not say to which repository?" and
consults "branch.<current>.remote" but defaults to 'origin'
if unconfigured.
"git push <name>" (or using the <name> determined as above)
says "you do not say which branches?" and consults
"remote.<name>.push" to find branches to push out, but
defaults to 'matching branches' if unconfigured.
What you would want to change is the fallback behaviour for
unconfigured "remote.<name>.push". I think it is sensible to
have an option to make it push only the current branch. I am
not sure if it is sensible to make that the default (and
introduce --matching option to get the current behaviour) at
this point in 1.5.X series, but from the general usability point
of view, I would not object to demote 'matching' to optional and
make 'current only' the default in 1.6.X or later.
Thoughts?
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Kelvie Wong @ 2007-09-27 19:24 UTC (permalink / raw)
To: Pierre Habouzit, Kelvie Wong, git
In-Reply-To: <20070927185707.GC12427@artemis.corp>
I've tried all of the ones that were supported, the result is the same
-- blank files in all three windows.
It is because git mergetool fails to generate these files for whatever
reason (the filebasename.{REMOTE,LOCAL,BASE}.* files). I don't know
why this happens.
As for merge utilities, all I need is something that looks for the
first <<<<<, and lets me choose which version I want (either top or
bottom), plain and simple :/ I don't even need/want a gui.
But oh well, I guess the answer here is to write a script that does it.
Kelvie
On 9/27/07, Pierre Habouzit <madcoder@debian.org> wrote:
> On Thu, Sep 27, 2007 at 06:31:19PM +0000, Kelvie Wong wrote:
> > At work, I've been using a git-svn import for my daily workflow (still
> > somewhat of a git newbie, but now has come to the point where it's
> > tough to work without it), and while rebasing from svn (on a rather
> > old branch), I found that the mergetool option does not work too well
> > for me.
>
> Which tool are you using ? kdiff3 ? I've noticed that it often fails
> miserably, or worse, create bad merges silentely with it.
>
> And as none of the other merge tool that are supported are able to
> either do 3way merges, or have a decent UI (that definitely seems to be
> exclusive features) I've given up on git-mergetool (and to be fair, it
> sucks, because it could be _sooo_ useful sometimes).
>
> --
> ·O· Pierre Habouzit
> ··O madcoder@debian.org
> OOO http://www.madism.org
>
>
--
Kelvie
^ permalink raw reply
* Re: ignoring non-submodule subrepositories
From: Junio C Hamano @ 2007-09-27 19:29 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20070927170700.GA10250@lapse.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> I have a repository inside another, and for several reasons, I do
> not want to use git-submodule in this case. My issue is that
> git-status lists the subrepository as untracked.
>
> Of course, I could add it to .gitignore alright, but instead
> I wonder whether it would not make sense to ignore subdirectories
> themselves containing .git/ directories, not explicitly so as to not
> mess with git-submodule, but implicitly.
>
> Thoughts?
I've had a line "/Meta" in my .git/info/excludes ever since I
started to maintain the 'todo' branch (which is managed in an
independent repository situated there, and pushed into the
'todo' branch of git.git), and having to have that line never
bothered me.
While I do not think of a reason offhand not to ignore anything
that has .git/ and is not a subproject, other than that ignoring
might interfere your adding such a separate project as a
subproject. I know "git add" would countermand the ignore list,
but not listing means it lets you forget.
Thinking about it more, such a separate project is not even
special. We list untracked files to remind you that you might
want to add them. Why should a separate project that is not
tracked by us (i.e. a potential superproject) be treated any
differently from other untracked things on the filesystem?
So, my thoughts are moderate "negative" at this point, but
others may have better arguments..
^ permalink raw reply
* backup or mirror a repository
From: Dan Farina @ 2007-09-27 19:35 UTC (permalink / raw)
To: git
Hello list,
I have been poking around on IRC and gmane, but haven't yet seen a
solution to my problem:
What I really want is something semantically identical to a recursive
copy of my entire git repository on one machine sent to another machine.
Right now I can't simply use "rsync -ar --delete ..." because the pack
changes names, thus fooling rsync and sending a bunch of bits over the
network.
I saw git-mirror on gmane and asked around in IRC, but the former seems
to have died sometime last November and the latter told me I'd probably
have to write some glue to process git show-ref and git ls-remote. This
seems viable, but suboptimal. Another user chimed in that they also had
the same use case as myself.
fdr
(Justifications: I am super paranoid, so I want to push my local
branches to another disk to be safe, but then they proliferate over time
since deleted local branches are not also deleted on the target
repository. I also want to work on multiple machines seamlessly, and as
such doing a bunch of "git checkout -r ..." when I need to change
branches is also suboptimal. As I said, I can get what I want by simply
using rsync, so this is entirely about efficiency by exploiting git's
structure)
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Pierre Habouzit @ 2007-09-27 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3awzvrpr.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
On Thu, Sep 27, 2007 at 07:22:24PM +0000, Junio C Hamano wrote:
> I am not sure if it is sensible to make that the default (and
> introduce --matching option to get the current behaviour) at this
> point in 1.5.X series, but from the general usability point of view, I
> would not object to demote 'matching' to optional and make 'current
> only' the default in 1.6.X or later.
Sounds like a plan to me.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Jeff King @ 2007-09-27 19:41 UTC (permalink / raw)
To: Pierre Habouzit, Kelvie Wong, git
In-Reply-To: <20070927191614.GE12427@artemis.corp>
On Thu, Sep 27, 2007 at 09:16:14PM +0200, Pierre Habouzit wrote:
> > Huh? I use xxdiff all the time, and it works fine.
>
> I'm sorry but I find that the UI is terrible.
Fair enough.
-Peff
^ permalink raw reply
* Re: git-quiltimport and non-existent patches
From: Junio C Hamano @ 2007-09-27 19:41 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: git, Geoff Levand
In-Reply-To: <Pine.LNX.4.62.0709271154440.10467@pademelon.sonytel.be>
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> writes:
> It would be nice if git-quiltimport would just warn about
> non-existent patches, just like quilt. This will make it work
> with `markers' we put in our quilt series files. Commenting
> out the markers is no solution as `quilt series' doesn't show
> commented-out patches.
I cannot decide if this should be the default (that's up to
heavy users of git-quiltimport script), but something along this
line should do. Care to test it and ack?
---
git-quiltimport.sh | 21 +++++++++++++++++----
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 74a54d5..3c38959 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -4,6 +4,7 @@ SUBDIRECTORY_ON=Yes
. git-sh-setup
dry_run=""
+error_empty=t
quilt_author=""
while test $# != 0
do
@@ -25,6 +26,11 @@ do
dry_run=1
;;
+ --expect-marker)
+ shift
+ error_empty=
+ ;;
+
--pa=*|--pat=*|--patc=*|--patch=*|--patche=*|--patches=*)
QUILT_PATCHES=$(expr "z$1" : 'z-[^=]*\(.*\)')
shift
@@ -74,10 +80,17 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
echo $patch_name
git mailinfo "$tmp_msg" "$tmp_patch" \
<"$QUILT_PATCHES/$patch_name" >"$tmp_info" || exit 3
- test -s "$tmp_patch" || {
- echo "Patch is empty. Was it split wrong?"
- exit 1
- }
+ if test ! -s "$tmp_patch"
+ then
+ if test -z "$error_empty"
+ then
+ echo "Patch is empty. Was it split wrong?"
+ exit 1
+ else
+ echo "Marker seen."
+ continue
+ fi
+ fi
# Parse the author information
export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
^ permalink raw reply related
* Re: [PATCH 2/4] This exports the update() function from builtin-add.c as
From: Junio C Hamano @ 2007-09-27 19:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kristian Høgsberg, gitster, git
In-Reply-To: <Pine.LNX.4.64.0709271245570.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 27 Sep 2007, Kristian Høgsberg wrote:
>
>> builtin-add.c | 8 ++++----
>> commit.h | 2 ++
>
> Maybe move it to read-cache.c, just after "add_file_to_index()"? And
> expose it via cache.h, not commit.h?
Hmmmmmmmm. read-cache.c has been one of the lowest level files
that define atomic operations, similar to sha1_file.c, and this
function is much more porcelain-ish molecule operation. I'd
rather not.
What other useful molecules would we have and/or need to have by
splitting existing standalone commands? rerere() is another,
and probably we would need to rip the --with-tree bit from
ls-files out to make it usable from builtin-commit.
I do not think we would want to go to the "one file per
function" extreme, either. Can we have a new file that hold
these helper functions for porcelains?
^ permalink raw reply
* [PATCH] gitview: revamped to use string.join, stripped a function def
From: Denis Cheng @ 2007-09-27 19:55 UTC (permalink / raw)
To: Aneesh Kumar K.V, Junio C Hamano; +Cc: git, cr_quan
Signed-off-by: Denis Cheng <crquan@gmail.com>
---
contrib/gitview/gitview | 13 +------------
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 5931766..2eb72b1 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -36,17 +36,6 @@ except ImportError:
re_ident = re.compile('(author|committer) (?P<ident>.*) (?P<epoch>\d+) (?P<tz>[+-]\d{4})')
-def list_to_string(args, skip):
- count = len(args)
- i = skip
- str_arg=" "
- while (i < count ):
- str_arg = str_arg + args[i]
- str_arg = str_arg + " "
- i = i+1
-
- return str_arg
-
def show_date(epoch, tz):
secs = float(epoch)
tzsecs = float(tz[1:3]) * 3600
@@ -1115,7 +1104,7 @@ class GitView(object):
def set_branch(self, args):
"""Fill in different windows with info from the reposiroty"""
- fp = os.popen("git rev-parse --sq --default HEAD " + list_to_string(args, 1))
+ fp = os.popen("git rev-parse --sq --default HEAD " + " ".join(args[1:]))
git_rev_list_cmd = fp.read()
fp.close()
fp = os.popen("git rev-list --header --topo-order --parents " + git_rev_list_cmd)
--
1.5.3.2
^ permalink raw reply related
* Re: Mergetool generating blank files (1.5.3)
From: Junio C Hamano @ 2007-09-27 19:58 UTC (permalink / raw)
To: Kelvie Wong; +Cc: Pierre Habouzit, git
In-Reply-To: <94ccbe710709271224rc65b6f4k8b68419629ed5b45@mail.gmail.com>
"Kelvie Wong" <kelvie@ieee.org> writes:
> I've tried all of the ones that were supported, the result is the same
> -- blank files in all three windows.
>
> It is because git mergetool fails to generate these files for whatever
> reason (the filebasename.{REMOTE,LOCAL,BASE}.* files). I don't know
> why this happens.
Can you run git-mergetool under "sh -x"?
That is,
$ sh -x git-mergetool
around ll.160-170 these files are created.
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Kelvie Wong @ 2007-09-27 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhclfubh5.fsf@gitster.siamese.dyndns.org>
On 9/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Kelvie Wong" <kelvie@ieee.org> writes:
>
> > I've tried all of the ones that were supported, the result is the same
> > -- blank files in all three windows.
> >
> > It is because git mergetool fails to generate these files for whatever
> > reason (the filebasename.{REMOTE,LOCAL,BASE}.* files). I don't know
> > why this happens.
>
> Can you run git-mergetool under "sh -x"?
>
> That is,
>
> $ sh -x git-mergetool
>
> around ll.160-170 these files are created.
>
#######################################
$ sh -x /usr/local/bin/git-mergetool --tool=meld
+ USAGE=[--tool=tool] [file to merge] ...
+ SUBDIRECTORY_OK=Yes
+ . git-sh-setup
+ unset CDPATH
+ [ -z ]
+ LONG_USAGE=Usage: /usr/local/bin/git-mergetool [--tool=tool] [file
to merge] ...
+ [ -z Yes ]
+ git rev-parse --git-dir
+ GIT_DIR=/home/kelvie/src/trunk/.git
+ test -n /home/kelvie/src/trunk/.git
+ cd /home/kelvie/src/trunk/.git
+ pwd
+ GIT_DIR=/home/kelvie/src/trunk/.git
+ : /home/kelvie/src/trunk/.git/objects
+ require_work_tree
+ git rev-parse --is-inside-work-tree
+ test true = true
+ expr z--tool=meld : z-[^=]*=\(.*\)
+ merge_tool=meld
+ shift
+ break
+ test -z meld
+ test -z meld
+ type meld
+ test 0 -eq 0
+ git ls-files -u
+ sed -e s/^[^ ]* //
+ sort -u
+ files=fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.h
fmeprompter/src/qfmeparameterinteger.cpp
fmeprompter/src/qfmeparameterinteger.h
+ test -z fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.h
fmeprompter/src/qfmeparameterinteger.cpp
fmeprompter/src/qfmeparameterinteger.h
+ echo Merging the files: fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.h
fmeprompter/src/qfmeparameterinteger.cpp
fmeprompter/src/qfmeparameterinteger.h
Merging the files: fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.h
fmeprompter/src/qfmeparameterinteger.cpp
fmeprompter/src/qfmeparameterinteger.h
+ git ls-files -u
+ sed -e s/^[^ ]* //
+ sort -u
+ read i
+ printf \n
+ merge_file fmeprompter/src/qfmeparameterfloat.cpp
+ path=fmeprompter/src/qfmeparameterfloat.cpp
+ git ls-files -u -- fmeprompter/src/qfmeparameterfloat.cpp
+ f=100644 bd66831cc4c3fb2907bba0fa9bef6d3e696bf0a3 1
fmeprompter/src/qfmeparameterfloat.cpp
100644 10026c1391fc34485b54727f831ebecfde8711a5 2
fmeprompter/src/qfmeparameterfloat.cpp
100644 0d2e9decf73ae5f5e4143f3181b7c8435c20416c 3
fmeprompter/src/qfmeparameterfloat.cpp
+ test -z 100644 bd66831cc4c3fb2907bba0fa9bef6d3e696bf0a3 1
fmeprompter/src/qfmeparameterfloat.cpp
100644 10026c1391fc34485b54727f831ebecfde8711a5 2
fmeprompter/src/qfmeparameterfloat.cpp
100644 0d2e9decf73ae5f5e4143f3181b7c8435c20416c 3
fmeprompter/src/qfmeparameterfloat.cpp
+ BACKUP=fmeprompter/src/qfmeparameterfloat.cpp.BACKUP.4697
+ LOCAL=fmeprompter/src/qfmeparameterfloat.cpp.LOCAL.4697
+ REMOTE=fmeprompter/src/qfmeparameterfloat.cpp.REMOTE.4697
+ BASE=fmeprompter/src/qfmeparameterfloat.cpp.BASE.4697
+ mv -- fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.cpp.BACKUP.4697
+ cp -- fmeprompter/src/qfmeparameterfloat.cpp.BACKUP.4697
fmeprompter/src/qfmeparameterfloat.cpp
+ git ls-files -u -- fmeprompter/src/qfmeparameterfloat.cpp
+ awk {if ($3==1) print $1;}
+ base_mode=100644
+ git ls-files -u -- fmeprompter/src/qfmeparameterfloat.cpp
+ awk {if ($3==2) print $1;}
+ local_mode=100644
+ git ls-files -u -- fmeprompter/src/qfmeparameterfloat.cpp
+ awk {if ($3==3) print $1;}
+ remote_mode=100644
+ base_present
+ test -n 100644
+ git cat-file blob :1:fmeprompter/src/qfmeparameterfloat.cpp
+ local_present
+ test -n 100644
+ git cat-file blob :2:fmeprompter/src/qfmeparameterfloat.cpp
+ remote_present
+ test -n 100644
+ git cat-file blob :3:fmeprompter/src/qfmeparameterfloat.cpp
+ test -z 100644 -o -z 100644
+ is_symlink 100644
+ test 100644 = 120000
+ is_symlink 100644
+ test 100644 = 120000
+ echo Normal merge conflict for 'fmeprompter/src/qfmeparameterfloat.cpp':
Normal merge conflict for 'fmeprompter/src/qfmeparameterfloat.cpp':
+ describe_file 100644 local fmeprompter/src/qfmeparameterfloat.cpp.LOCAL.4697
+ mode=100644
+ branch=local
+ file=fmeprompter/src/qfmeparameterfloat.cpp.LOCAL.4697
+ printf {%s}: local
{local}: + test -z 100644
+ is_symlink 100644
+ test 100644 = 120000
+ base_present
+ test -n 100644
+ echo modified
modified
+ describe_file 100644 remote fmeprompter/src/qfmeparameterfloat.cpp.REMOTE.4697
+ mode=100644
+ branch=remote
+ file=fmeprompter/src/qfmeparameterfloat.cpp.REMOTE.4697
+ printf {%s}: remote
{remote}: + test -z 100644
+ is_symlink 100644
+ test 100644 = 120000
+ base_present
+ test -n 100644
+ echo modified
modified
+ printf Hit return to start merge resolution tool (%s): meld
Hit return to start merge resolution tool (meld): + read ans
+ touch fmeprompter/src/qfmeparameterfloat.cpp.BACKUP.4697
+ meld -- fmeprompter/src/qfmeparameterfloat.cpp.LOCAL.4697
fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.cpp.REMOTE.4697
And then meld starts up, with the original file in the middle, and two
blank files on the side, LOCAL and REMOTE respectively.
--
Kelvie
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Junio C Hamano @ 2007-09-27 20:28 UTC (permalink / raw)
To: Kelvie Wong; +Cc: git
In-Reply-To: <94ccbe710709271312k7eac8e35y353180596a0abc9a@mail.gmail.com>
"Kelvie Wong" <kelvie@ieee.org> writes:
> And then meld starts up, with the original file in the middle, and two
> blank files on the side, LOCAL and REMOTE respectively.
Wild guess. Are you running this from a subdirectory? I have a
mild suspicion that mergetool is not subdirectory safe. Can you
try running it from the toplevel of the work tree?
^ permalink raw reply
* [PATCH] quiltimport: Skip non-existent patches
From: Dan Nicholson @ 2007-09-27 20:30 UTC (permalink / raw)
To: Geert.Uytterhoeven; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0709271154440.10467@pademelon.sonytel.be>
When quiltimport encounters a non-existent patch in the series file,
just skip to the next patch. This matches the behavior of quilt.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
---
git-quiltimport.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 74a54d5..880c81d 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -71,6 +71,10 @@ commit=$(git rev-parse HEAD)
mkdir $tmp_dir || exit 2
for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
+ if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
+ echo "$patch_name doesn't exist. Skipping."
+ continue
+ fi
echo $patch_name
git mailinfo "$tmp_msg" "$tmp_patch" \
<"$QUILT_PATCHES/$patch_name" >"$tmp_info" || exit 3
--
1.5.3.2
^ permalink raw reply related
* Re: Mergetool generating blank files (1.5.3)
From: Kelvie Wong @ 2007-09-27 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4w3ua2j.fsf@gitster.siamese.dyndns.org>
Egads, it's alive!
I was in a subdirectory (most of my work is in that one subdirectory
anyways :p), but running it on the top level did indeed work as
expected.
Thanks,
Kelvie
On 9/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Kelvie Wong" <kelvie@ieee.org> writes:
>
> > And then meld starts up, with the original file in the middle, and two
> > blank files on the side, LOCAL and REMOTE respectively.
>
> Wild guess. Are you running this from a subdirectory? I have a
> mild suspicion that mergetool is not subdirectory safe. Can you
> try running it from the toplevel of the work tree?
>
>
--
Kelvie
^ permalink raw reply
* Re: [PATCH] quiltimport: Skip non-existent patches
From: Dan Nicholson @ 2007-09-27 20:39 UTC (permalink / raw)
To: git
In-Reply-To: <1190925059-5233-1-git-send-email-dbn.lists@gmail.com>
Dan Nicholson <dbn.lists <at> gmail.com> writes:
>
> When quiltimport encounters a non-existent patch in the series file,
> just skip to the next patch. This matches the behavior of quilt.
>
> Signed-off-by: Dan Nicholson <dbn.lists <at> gmail.com>
> ---
> git-quiltimport.sh | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/git-quiltimport.sh b/git-quiltimport.sh
> index 74a54d5..880c81d 100755
> --- a/git-quiltimport.sh
> +++ b/git-quiltimport.sh
> @@ -71,6 +71,10 @@ commit=$(git rev-parse HEAD)
>
> mkdir $tmp_dir || exit 2
> for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
> + if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
> + echo "$patch_name doesn't exist. Skipping."
> + continue
> + fi
> echo $patch_name
> git mailinfo "$tmp_msg" "$tmp_patch" \
> <"$QUILT_PATCHES/$patch_name" >"$tmp_info" || exit 3
I forgot to mention the rationale for this patch vs. what Junio sent. The issue
with Junio's patch is that the failure will occur before $tmp_patch is created
because the script tries to feed git-mailinfo a non-existent patch
($patch_name). You'll only get past the mailinfo if $patch_name exists.
The marker setting may still be useful in this context, though, to suppress the
"doesn't exist" message.
--
Dan
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Junio C Hamano @ 2007-09-27 20:47 UTC (permalink / raw)
To: Kelvie Wong; +Cc: git
In-Reply-To: <94ccbe710709271338u79ba89beh5a637bf84f8edf44@mail.gmail.com>
"Kelvie Wong" <kelvie@ieee.org> writes:
> Egads, it's alive!
>
> I was in a subdirectory (most of my work is in that one subdirectory
> anyways :p), but running it on the top level did indeed work as
> expected.
>
> Thanks,
Thanks for spotting a bug. It claims to be subdirectory safe at
the top of the script but apparently it isn't.
And I do not see a reason why it cannot be made subdirectory
safe.
^ permalink raw reply
* Re: [PATCH] quiltimport: Skip non-existent patches
From: Junio C Hamano @ 2007-09-27 20:50 UTC (permalink / raw)
To: Dan Nicholson; +Cc: git
In-Reply-To: <loom.20070927T203413-499@post.gmane.org>
Dan Nicholson <dbn.lists@gmail.com> writes:
> Dan Nicholson <dbn.lists <at> gmail.com> writes:
>>
>> When quiltimport encounters a non-existent patch in the series file,
>> just skip to the next patch. This matches the behavior of quilt.
>>
>> Signed-off-by: Dan Nicholson <dbn.lists <at> gmail.com>
>> ---
>> git-quiltimport.sh | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/git-quiltimport.sh b/git-quiltimport.sh
>> index 74a54d5..880c81d 100755
>> --- a/git-quiltimport.sh
>> +++ b/git-quiltimport.sh
>> @@ -71,6 +71,10 @@ commit=$(git rev-parse HEAD)
>>
>> mkdir $tmp_dir || exit 2
>> for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
>> + if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
>> + echo "$patch_name doesn't exist. Skipping."
>> + continue
>> + fi
>> echo $patch_name
>> git mailinfo "$tmp_msg" "$tmp_patch" \
>> <"$QUILT_PATCHES/$patch_name" >"$tmp_info" || exit 3
>
>
> I forgot to mention the rationale for this patch vs. what Junio sent. The issue
> with Junio's patch is that the failure will occur before $tmp_patch is created
> because the script tries to feed git-mailinfo a non-existent patch
> ($patch_name). You'll only get past the mailinfo if $patch_name exists.
>
> The marker setting may still be useful in this context, though, to suppress the
> "doesn't exist" message.
Thanks. I did not know what "marker" meant by the original
context and assumed there is a file referred to by the series
file but there is no patch in that file. Instead it seems that
a series file can contain something that is _not_ a file and
that is called the marker, right?
^ permalink raw reply
* Re: Mergetool generating blank files (1.5.3)
From: Junio C Hamano @ 2007-09-27 20:51 UTC (permalink / raw)
To: Kelvie Wong; +Cc: git
In-Reply-To: <7v8x6ru97z.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Kelvie Wong" <kelvie@ieee.org> writes:
>
>> Egads, it's alive!
>>
>> I was in a subdirectory (most of my work is in that one subdirectory
>> anyways :p), but running it on the top level did indeed work as
>> expected.
>>
>> Thanks,
>
> Thanks for spotting a bug. It claims to be subdirectory safe at
> the top of the script but apparently it isn't.
>
> And I do not see a reason why it cannot be made subdirectory
> safe.
It _could_ be just the matter of doing this, although I cannot
test it right now (at work and have no access to any of the
backends). Care to try it from a subdirectory and report
failure or success?
---
git-mergetool.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a0e44f7..018db58 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -12,6 +12,7 @@ USAGE='[--tool=tool] [file to merge] ...'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
+cd_to_toplevel
# Returns true if the mode reflects a symlink
is_symlink () {
^ permalink raw reply related
* Re: Mergetool generating blank files (1.5.3)
From: Kelvie Wong @ 2007-09-27 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsubsuh1.fsf@gitster.siamese.dyndns.org>
On 9/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > "Kelvie Wong" <kelvie@ieee.org> writes:
> >
> >> Egads, it's alive!
> >>
> >> I was in a subdirectory (most of my work is in that one subdirectory
> >> anyways :p), but running it on the top level did indeed work as
> >> expected.
> >>
> >> Thanks,
> >
> > Thanks for spotting a bug. It claims to be subdirectory safe at
> > the top of the script but apparently it isn't.
> >
> > And I do not see a reason why it cannot be made subdirectory
> > safe.
>
> It _could_ be just the matter of doing this, although I cannot
> test it right now (at work and have no access to any of the
> backends). Care to try it from a subdirectory and report
> failure or success?
>
> ---
>
> git-mergetool.sh | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index a0e44f7..018db58 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -12,6 +12,7 @@ USAGE='[--tool=tool] [file to merge] ...'
> SUBDIRECTORY_OK=Yes
> . git-sh-setup
> require_work_tree
> +cd_to_toplevel
>
> # Returns true if the mode reflects a symlink
> is_symlink () {
>
At least with emerge, this isn't so simple -- emacs tries to save it
as ${absolute_PWD}/${PWD_relative_to_toplevel}/$filename
(which of course doesn't exist yet).
In meld it works fine, however; haven't tried the other ones.
--
Kelvie
^ 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