* Re: git diff, git mergetool and CRLF conversion
From: Theodore Tso @ 2009-01-21 21:03 UTC (permalink / raw)
To: Charles Bailey; +Cc: Hannu Koivisto, git
In-Reply-To: <20090121172351.GB21727@hashpling.org>
On Wed, Jan 21, 2009 at 05:23:51PM +0000, Charles Bailey wrote:
> > Is this intended behaviour? I'm using 1.6.1 on Cygwin.
>
> Speaking for mergetool, I believe that it's simply because mergetool
> uses git cat-file which just outputs the raw contents of a blob and
> doesn't do any line ending conversion.
>
> IMHO, I think that it should probably perform the 'convert to working
> tree format' change when preparing the temporary files. I'm not sure
> how best to do that, but perhaps it should be using git checkout-index
> with the --temp option instead of cat-file.
Yes, I agree, that would probably be better.
- Ted
^ permalink raw reply
* post-receive-email - does not handle creating a new branch with same HEAD as other branch
From: Jake Goulding @ 2009-01-21 22:12 UTC (permalink / raw)
To: git
Given the simple case of two commits:
A--B
with branches setup like:
master: A
b1: B
If I create a new branch b2 at the same point as b1 from a remote server:
$ git push origin B:b2
The following code will be run in post-receive-email:
git rev-parse --not --branches |
grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $newrev
(refname = refs/heads/b2, newrev=B)
The problem occurs because the first rev-parse reports:
^A
^B
^B
And the grep removes lines matching B, leaving:
^A
which causes the eventual rev-list command to be:
git rev-list --pretty ^A B
This problem could be exaggerated if there were a lot of commits between
A and B, which would cause each commit A..B to be reported.
Is there any alternate way to write this command to cause these false
positives to not be reported? I tried to write a version that uses the
ref name instead of the hash, but it did not end up very pretty (and I
don't think it worked...).
Thanks!
-Jake
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-21 22:17 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121190757.GB21686@coredump.intra.peff.net>
Hi,
On Wed, 21 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 02:26:56AM +0100, Johannes Schindelin wrote:
>
> > Well, in this case, you will find that the "bug" is _at most_ some
> > binaries not being found.
> > [...]
> > (Actually, with my new patch, the may be replaced, but _only_ if
> > necessary, and the same thing would apply as I said earlier: the binary
> > would not be found, or a binary from the PATH would be run without
> > valgrind; but the next runs will not have the problem.)
>
> You can run a random binary from the PATH.
No. You seem to assume that a test script can run all kinds of Git
commands while another, is replacing the symlinks in $GIT_VALGRIND/bin/ at
the same time.
Fact is: every test script will check $GIT_VALGRIND/bin/ for
up-to-dateness first. Before running any Git command.
During that time, races are possible, but non-fatal, because they all try
to do the same thing.
Except, of course, if you replace a script by a builtin _while your test
is running the up-to-date check of $GIT_VALGRIND/bin/_! But I would have
no word of consolation for you in that case.
So, can we agree that every test script tries to keep $GIT_VALGRIND/bin/
up-to-date before the first Git command is called?
Now, you might assume that it is possible that one test-script symlinked
the Git command while another removed it.
But the script that removed the symlink will recreate it right away.
Granted, during that time, the other script could have gone off to call a
Git command in that very brief time span, but keep in mind: it does not
take a long time from rm to ln -s, _and_ the other script would have to go
on to call a Git command _right through that time_.
And you know which command that might be?
Exactly. git init. Which takes a long, long, long time, and where I
really could not care less if it is called from the PATH or not.
Note: this would be only possible if both scripts checked the same name at
the very same time, coming to the very same result that the name needs
symlinking. Unlikely.
Note, too: such a replacing/creating could only take place the very first
time you run valgrind, or when a script was replaced by a builtin. IOW
very, very rarely to begin with.
Now the big question: is this highly, highly unlikely issue relevant?
And I say: no. Because even in that highly, highly, highly unlikely
event, all that will happen is that a git init (which is tested later,
anyway) is not valgrinded.
Besides, if that race would happen _and_ you would see any issues, you'd
run the test again, without parallelization, because you would not be able
to discern what messages belong together from the output of "make -j50
test" anyway.
And the whole issue goes away, because that call will again try to
make GIT_VALGRIND/bin up-to-date, and there will be no chance for a race
this time.
Phew. A lot of time, a lot of braincycles, and a lot of keystrokes wasted
on that subject, don't you think?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] valgrind tests: be super-super paranoid when creating symlinks
From: Johannes Schindelin @ 2009-01-21 22:31 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212137130.3586@pacific.mpi-cbg.de>
Even if there is only a faint, almost neglible chance that two parallel
tests create the symlinks needed for the valgrind test at the same time,
Peff wrote more than just a couple mails about the issue.
To get rid of that threat^Wthread, use a locking mechanism to make
sure a symlink is only created by one test invocation, and the other
has to wait.
Peff, do you see how much I like you?
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/test-lib.sh | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 6acc6e0..07e657e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -490,8 +490,19 @@ else
make_symlink () {
test -h "$2" &&
test "$1" = "$(readlink "$2")" || {
- rm -f "$2" &&
- ln -s "$1" "$2"
+ # be super paranoid
+ if mkdir "$2".lock
+ then
+ rm -f "$2" &&
+ ln -s "$1" "$2" &&
+ rm -r "$2".lock
+ else
+ while test -d "$2".lock
+ do
+ say "Waiting for lock on $2."
+ sleep 1
+ done
+ fi
}
}
--
1.6.1.442.g112f5
^ permalink raw reply related
* Re: [PATCH] Added giteditor script to show diff while editing commit message.
From: Ted Pavlic @ 2009-01-21 22:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <alpine.DEB.1.00.0901212216310.3586@pacific.mpi-cbg.de>
Thanks for your comments. I've responded below. I just want to
top-respond to your comment that the fundamental problem is that the
diff is in a separate file. In fact, this is the point of the script. I
want to be able to scroll through the diff output independent of the
commit message.
(alternatively, I realize I could do "git commit -v" and then use my
editor's "split window" support, but that wouldn't help me with "stg edit")
> the subject could use some work. For example, I would prefix it with
...
>> From: Ted Pavlic<ted@tedpavlic.com>
>
> As this is exactly what your email said in its header, it is redundant
> information. Worse, it is information that made me look back to know why
> it needs to be there. Distracting.
I add --from to my gitsend alias to prevent git send-email from
prompting me for a "From". Is there a way to have git send-email simply
not prompt me for "From"?
> What information does the README add that is not in the script itself?
> If there is none, please refrain from adding the README to begin with.
OK. I noticed plenty of other not-very-useful READMEs in contrib/, and
so I figured it was a pro forma file.
>> +# Find git
>> +[ -z "${GIT}" ]&& GIT="git"
> Yes, I know it is contrib/, but you may want to adopt Git's coding style
> early.
Ok. Switching to test.
> Besides, I find it funny that you want to override git with $GIT.
Isn't it possible that someone has git somewhere else?
>> +# If we recognize a popular editor, add necessary flags
>> +case "${EDITOR}" in
>> + emacs)
>> + EDITOR="${EDITOR} -nw"
>
> Mhm. Should this not be the user's choice? Some like emacs to start up
> in a window.
I don't use emacs, but it was my impression that the "no window" flag
was added to make sure that emacs doesn't fork. That's why "-f" is used
in the vim line.
>> +# End GITTMP in ".git" so that "*.git/" syntax highlighting recognition
>> +# doesn't break
>> +GITTMP="${TMPDIR-/tmp}/giteditor.$RANDOM.$RANDOM.$RANDOM.$$.git"
>> +(umask 077&& mkdir "${GITTMP}") || {
>> + echo "Could not create temporary directory! Exiting." 1>&2
>> + exit 1
>> +}
>
> Umm. Why? Why do you need a temporary .git directory?
The script generates a new "diff" file that I would rather drop
elsewhere (e.g., in a /tmp directory) rather than here in the current
directory.
However, maybe you're right. After all, stg drops ".stgit-edit.txt" in
the working directory. I suppose I could use gitdir, but I wasn't sure
if it was safe to pollute gitdir.
In the next version, I'll get rid of the temp directory and put the file
here.
>> + # Diff is non-empty, so edit msg and diff
>> + ${EDITOR} "${GITTMP}/${COMMITMSG}" "${GITTMP}/diff" || exit $?
>
> vi users will hate you, as you do not give them a chance to edit the
> message after having seen the diff.
I don't see what you mean. I am a vi user (exclusively), and this script
works very well for me.
The "-f -o" flags above ensure that gvim will not fork. I'll add "vi" to
the search string that automatically add "-f -o". Will that satisfy you?
At the moment, giteditor works exactly like EDITOR (or VISUAL) for me,
but it opens up a second buffer (split in the bottom window in my case)
with the diff in it. I'm given the opportunity to save.
> git commit will abort anyway if the commit message has not changed. Plus,
> it does a better job, as it checks only the non-commented-out text.
Okay. Using $1 exclusively.
> BTW why on earth do you put every single variable name in curly brackets?
I always thought that was good practice. It prevents ambiguity, and *I*
don't think it's an eyesore.
> Besides all that criticism, there is also a fundamental issue. The diff
> is in a separate file.
That's the point. If I wanted to put the diff in the commit buffer, I
would have used "git commit -v". I think many would like to be able to
scroll through the diff without having to scroll through the commit.
Is there no value in having the diff in a separate file?
Thanks --
Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Markus Heidelberg @ 2009-01-21 22:35 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, Junio C Hamano, git
In-Reply-To: <20090120040448.GA30714@sigill.intra.peff.net>
Jeff King, 20.01.2009:
> On Sun, Jan 18, 2009 at 09:37:15PM +0100, Markus Heidelberg wrote:
>
> > Not sure, if you it has something to do with the following, but I had
> > this in my tree for some days now, waiting for the 2 commits mentioned
> > in the log message to graduate to master, which happend just an hour or
> > so ago.
>
> I think this is probably an improvement, but I had in mind something a
> little more drastic. Right now we keep munging one variable that is our
> current idea of "should we do color" based on multiple config values.
> Then you end up with (best case) this "finalize color config", which is
> a bit ugly, or (worst case) bugs where the value hasn't always been
Yes, I didn't find it to be that great either.
> properly initialized (or finalized).
>
> So I think it makes more sense to record each config value, and then
> check a _function_ that does the right thing. I.e., you end up with
> something like:
>
> [example code snipped]
That would probably be better.
Markus
^ permalink raw reply
* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-21 22:38 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121215318.GA9107@sigill.intra.peff.net>
Hi,
On Wed, 21 Jan 2009, Jeff King wrote:
> Actually, I am wrong. There is a stripped-down readlink that has shipped
> with FreeBSD (since 4.10) and NetBSD (since 1.6). So while readlink
> isn't portable, I think it should generally work on platforms supported
> by valgrind.
A pity. I was already working on this patch:
-- snipsnap --
[PATCH] valgrind tests: provide a "readlink" function for systems which lack it
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/test-lib.sh | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 07e657e..c2199e7 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -487,7 +487,24 @@ then
PATH=$TEST_DIRECTORY/..:$PATH
GIT_EXEC_PATH=$TEST_DIRECTORY/..
else
+ readlink -h 2> /dev/null
+ if test $? = 127
+ then
+ readlink () {
+ ls -l "$1" |
+ sed -e "s/-> \(.*\)$/\1/g"
+ # cannot use s/.* -> //, because of
+ # ln -s "a -> b" "c -> d"
+ }
+ fi
+
make_symlink () {
+ case "$1" in
+ *" -> "*)
+ die "You must be kidding me ($1)."
+ ;;
+ esac
+
test -h "$2" &&
test "$1" = "$(readlink "$2")" || {
# be super paranoid
--
1.6.1.442.g112f5
^ permalink raw reply related
* [EGIT PATCH] Circumvent situations where Eclipse tries to decorate externally linked resources
From: Charles O'Farrell @ 2009-01-21 22:33 UTC (permalink / raw)
To: git
This occurs in one our projects which has an externally linked folder, which
causes the decorator to die on a NPE. Alternatively rsrc.isLinked() could
have been used, but we allow for linked resources to repository files.
Signed-off-by: Charles O'Farrell <charleso@charleso.org>
---
.../internal/decorators/GitResourceDecorator.java | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
index c3ae52d..f24b1eb 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
@@ -296,6 +296,12 @@ public void decorate(final Object element, final IDecoration decoration) {
Repository repository = mapped.getRepository();
GitIndex index = repository.getIndex();
String repoRelativePath = mapped.getRepoRelativePath(rsrc);
+
+ if (repoRelativePath == null) {
+ Activator.trace("Cannot decorate linked resource " + rsrc);
+ return;
+ }
+
Tree headTree = repository.mapTree(Constants.HEAD);
TreeEntry blob = headTree!=null ? headTree.findBlobMember(repoRelativePath) : null;
Entry entry = index.getEntry(repoRelativePath);
--
1.6.1.9.g97c34
^ permalink raw reply related
* [PATCH] contrib: A script to show diff in new window while editing commit message.
From: Ted Pavlic @ 2009-01-21 22:45 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
In-Reply-To: <4977A2C9.1070502@tedpavlic.com>
This new script (contrib/giteditor/giteditor) is an example GIT_EDITOR
that causes the editor to open the commit message as well as a "git diff
--cached" in a separate window. This behavior differs from "git commit
-v" in that the diff can be browsed independently of the commit message
without having to invoke a split window view in an editor.
This script also detects when "stg edit" is being called and uses "stg
show" instead. Hence, it implements a kind of "stg show -v".
This script is highly influenced by the "hgeditor" script distributed
with the Mercurial SCM.
It could be improved by supporting a command-line flag that would mimic
the "git commit -v"-type behavior of opening the diff in the same window
as the commit message. This would extend existing commands like "stg
edit" that do not already have a "-v"-type option.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This version attempts to answer the concerns brought up by Johannes
Schindlin.
contrib/giteditor/giteditor | 68 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 68 insertions(+), 0 deletions(-)
create mode 100755 contrib/giteditor/giteditor
diff --git a/contrib/giteditor/giteditor b/contrib/giteditor/giteditor
new file mode 100755
index 0000000..501a11c
--- /dev/null
+++ b/contrib/giteditor/giteditor
@@ -0,0 +1,68 @@
+#!/bin/sh
+#
+# Set GIT_EDITOR (or core.editor) to this script to see a diff alongside
+# commit message. This script differs from "git commit -v" in that the
+# diff shows up in a separate buffer. Additionally, this script works
+# with "stg edit" as well.
+#
+# Copyright (c) 2009 by Theodore P. Pavlic <ted@tedpavlic.com>
+# Highly influenced by hgeditor script distributed with Mercurial SCM.
+# Distributed under the GNU General Public License, version 2.0.
+
+# Find git
+test -z "${GIT}" && GIT="git"
+
+# Find stg
+test -z "${STG}" && STG="stg"
+
+# Use an editor. To prevent loops, avoid GIT_EDITOR and core.editor.
+EDITOR=${GIT_EDITOR_EDITOR-${VISUAL-${EDITOR-vi}}}
+
+# If we recognize a popular editor, add necessary flags (e.g., to
+# prevent forking)
+case "${EDITOR}" in
+ emacs)
+ EDITOR="${EDITOR} -nw"
+ ;;
+ mvim|gvim|vim|vi)
+ EDITOR="${EDITOR} -f -o"
+ ;;
+esac
+
+# Remove temporary files even if we get interrupted
+DIFFOUTPUT="giteditor.${RANDOM}.${RANDOM}.${RANDOM}.$$.diff"
+cleanup_exit() {
+ rm -f "${DIFFOUTPUT}"
+}
+trap "cleanup_exit" 0 # normal exit
+trap "exit 255" 1 2 3 6 15 # HUP INT QUIT ABRT TERM
+
+# For git, COMMITMSG=COMMIT_EDITMSG
+# For stg, COMMITMSG=.stgit-edit.txt
+# etc.
+COMMITMSG=$(basename "$1")
+case "${COMMITMSG}" in
+ .stgit-edit.txt) # From "stg edit"
+ DIFFCMD="${STG}"
+ DIFFARGS="show"
+ ;;
+ *) # Fall through to "git commit" case
+ DIFFCMD="${GIT}"
+ DIFFARGS="diff --cached"
+ # To focus on files that changed, use:
+ #DIFFARGS="diff --cached --diff-filter=M"
+ ;;
+esac
+
+"${DIFFCMD}" ${DIFFARGS} > ${DIFFOUTPUT}
+
+if test -s "${DIFFOUTPUT}"; then
+ # Diff is non-empty, so edit msg and diff
+ ${EDITOR} "$1" "${DIFFOUTPUT}" || exit $?
+else
+ # Empty diff. Only edit msg
+ ${EDITOR} "$1" || exit $?
+fi
+
+# (recall that DIFFOUTPUT file gets cleaned up by trap above)
+exit
--
1.6.1.213.g28da8
^ permalink raw reply related
* Re: [PATCH] Added giteditor script to show diff while editing commit message.
From: Johannes Schindelin @ 2009-01-21 22:52 UTC (permalink / raw)
To: Ted Pavlic; +Cc: gitster, git
In-Reply-To: <4977A2C9.1070502@tedpavlic.com>
Hi,
On Wed, 21 Jan 2009, Ted Pavlic wrote:
> Thanks for your comments. I've responded below. I just want to
> top-respond to your comment that the fundamental problem is that the
> diff is in a separate file. In fact, this is the point of the script. I
> want to be able to scroll through the diff output independent of the
> commit message.
Once again, note that e.g. vi will not cope with the way you try to
achieve that.
> > > From: Ted Pavlic<ted@tedpavlic.com>
> >
> > From: me
>
> > Besides, I find it funny that you want to override git with $GIT.
>
> Isn't it possible that someone has git somewhere else?
The script is called from within Git. So you can rest assured that "git"
is in the PATH, I guess. Except in configurations where you have a
properly installed GIT_EXEC_PATH, and run Git using an absolute path.
If you want to cater for such a case, sure go ahead :-)
> > > +# doesn't break
> > > +GITTMP="${TMPDIR-/tmp}/giteditor.$RANDOM.$RANDOM.$RANDOM.$$.git"
> > > +(umask 077&& mkdir "${GITTMP}") || {
> > > + echo "Could not create temporary directory! Exiting." 1>&2
> > > + exit 1
> > > +}
> >
> > Umm. Why? Why do you need a temporary .git directory?
>
> The script generates a new "diff" file that I would rather drop elsewhere
> (e.g., in a /tmp directory) rather than here in the current directory.
Why not .git/? That would be the _natural_ place to put it.
> > > + # Diff is non-empty, so edit msg and diff
> > > + ${EDITOR} "${GITTMP}/${COMMITMSG}" "${GITTMP}/diff" || exit $?
> >
> > vi users will hate you, as you do not give them a chance to edit the
> > message after having seen the diff.
>
> I don't see what you mean. I am a vi user (exclusively), and this script
> works very well for me.
I cannot go back to the commit message when I said ":n" to get to the
diff.
> > Besides all that criticism, there is also a fundamental issue. The
> > diff is in a separate file.
>
> That's the point. If I wanted to put the diff in the commit buffer, I
> would have used "git commit -v". I think many would like to be able to
> scroll through the diff without having to scroll through the commit.
>
> Is there no value in having the diff in a separate file?
In my case, no, for 2 reasons:
- I can always open a new shell (in ssh connections, I use screen) to get
the diff, and even better: I can restrict it to certain files, and I can
use the nice bookmarks "less" provides; dunno if vi would have them.
- My preference is definitely to look at the diff before committing, to be
certain that I did not fsck up. And nothing would annoy me more than to
be in the middle of editing a commit message while I am looking at the
diff and telling myself "that is a stupid mistake, let's fix it" knowing
that the commit will not pick up the fix.
So seeing the diff while composing the commit message is definitely too
late for me.
Ciao,
Dscho
^ permalink raw reply
* GUI and detatched HEAD (was Re: Deleting remote branch pointed by remote HEAD)
From: Daniel Barkalow @ 2009-01-21 22:56 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngnedkm.apk.sitaramc@sitaramc.homelinux.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1564 bytes --]
On Wed, 21 Jan 2009, Sitaram Chamarty wrote:
> On 2009-01-21, Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
>
> > I deleted a remote branch which was pointed by HEAD, this way: "git
> > push origin :master"
> >
> > Then for almost every git command, I get this error: "error:
> > refs/remotes/origin/HEAD points nowhere!".
> >
> > I found this situation non-friendly. Fortunately, I could understand
> > what's going on. But a new user might be confused.
>
> That's a pretty advanced command for a beginner. I have
> people who're only using the GUI (in the presumption that it
> will be less confusing or less powerful or whatever) and
> have managed to right click on a remote branch, choose
> "checkout this branch" and have made commits on it without
> knowing they're not on any branch!
I wonder if the GUI could handle this in a way that users would
understand. This is qualitively like following a link to a spreadsheet in
your web browser, having the browser launch your office suite and load the
spreadsheet off the web; now you're interacting with a spreadsheet where
you obviously can't save to the original location (which is some web site)
and haven't provided a local filename to save as.
I think the right thing would be to show it as "(Untitled)" and have a
prominant button to make a real saved branch out of it. There's nothing
all that strange about having a current "document" that has no filename
yet; the strange thing is that a version control system has this
capability.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] mergetool: respect autocrlf by using checkout-index
From: Charles Bailey @ 2009-01-21 22:57 UTC (permalink / raw)
To: git; +Cc: Hannu Koivisto, Theodore Tso, Charles Bailey
In-Reply-To: <20090121210348.GD9088@mit.edu>
Previously, git mergetool used cat-file which does not perform git to
worktree conversion. This changes mergetool to use git checkout-index
instead which means that the temporary files used for mergetool use the
correct line endings for the platform.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
git-mergetool.sh | 14 +++++++++++---
t/t7610-mergetool.sh | 15 +++++++++++++--
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..a4855d9 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -127,6 +127,14 @@ check_unchanged () {
fi
}
+checkout_staged_file () {
+ tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
+
+ if test $? -eq 0 -a -n "$tmpfile" ; then
+ mv -- "$tmpfile" "$3"
+ fi
+}
+
merge_file () {
MERGED="$1"
@@ -153,9 +161,9 @@ merge_file () {
local_mode=`git ls-files -u -- "$MERGED" | awk '{if ($3==2) print $1;}'`
remote_mode=`git ls-files -u -- "$MERGED" | awk '{if ($3==3) print $1;}'`
- base_present && git cat-file blob ":1:$prefix$MERGED" >"$BASE" 2>/dev/null
- local_present && git cat-file blob ":2:$prefix$MERGED" >"$LOCAL" 2>/dev/null
- remote_present && git cat-file blob ":3:$prefix$MERGED" >"$REMOTE" 2>/dev/null
+ base_present && checkout_staged_file 1 "$prefix$MERGED" "$BASE"
+ local_present && checkout_staged_file 2 "$prefix$MERGED" "$LOCAL"
+ remote_present && checkout_staged_file 3 "$prefix$MERGED" "$REMOTE"
if test -z "$local_mode" -o -z "$remote_mode"; then
echo "Deleted merge conflict for '$MERGED':"
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 09fa5f1..edb6a57 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -34,13 +34,24 @@ test_expect_success 'custom mergetool' '
git config merge.tool mytool &&
git config mergetool.mytool.cmd "cat \"\$REMOTE\" >\"\$MERGED\"" &&
git config mergetool.mytool.trustExitCode true &&
- git checkout branch1 &&
+ git checkout branch1 &&
test_must_fail git merge master >/dev/null 2>&1 &&
( yes "" | git mergetool file1>/dev/null 2>&1 ) &&
( yes "" | git mergetool file2>/dev/null 2>&1 ) &&
test "$(cat file1)" = "master updated" &&
test "$(cat file2)" = "master new" &&
- git commit -m "branch1 resolved with mergetool"
+ git commit -m "branch1 resolved with mergetool"
+'
+
+test_expect_success 'mergetool crlf' '
+ git config core.autocrlf true &&
+ git reset --hard HEAD^
+ test_must_fail git merge master >/dev/null 2>&1 &&
+ ( yes "" | git mergetool file1>/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file2>/dev/null 2>&1 ) &&
+ test "$(printf x | cat file1 -)" = "$(printf "master updated\r\nx")" &&
+ test "$(printf x | cat file2 -)" = "$(printf "master new\r\nx")" &&
+ git commit -m "branch1 resolved with mergetool - autocrlf"
'
test_done
--
1.6.1.235.gc9d403
^ permalink raw reply related
* Re: [PATCH resend] bash completion: add 'rename' subcommand to git-remote
From: Markus Heidelberg @ 2009-01-21 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7veiyxeyzr.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
---
> > I really don't like to bother you again, but compared to the inclusion
> > of the other patches, I guess you have forgotten the third try of this
> > patch.
> >
> > Thus this fourth try :)
>
> I did not mean that I forgot by the above "I seem to have missed".
> Literally none of your three attempts seem to have reached me.
Ah, OK. With "missed" I thought you have just overlooked them.
> I can
> guess what you wrote from the _included_ text in Shawn's response, but
> that is not a good/right place for me to pick up a patch from, is it?
No, it isn't.
next mail:
I just don't get it. The previous mail, I sent three a half hours ago,
didn't reach the list either. Am I doing anything wrong? I looked at
the archives: the first two got to the list, the 3rd (with the Acked-by
from Shawn) and 4th didn't. Now this is the 5th. I can't remember any
such problems with mail delivery.
contrib/completion/git-completion.bash | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3ce6de2..f2d6cad 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1391,7 +1391,7 @@ _git_config ()
_git_remote ()
{
- local subcommands="add rm show prune update"
+ local subcommands="add rename rm show prune update"
local subcommand="$(__git_find_subcommand "$subcommands")"
if [ -z "$subcommand" ]; then
__gitcomp "$subcommands"
@@ -1399,7 +1399,7 @@ _git_remote ()
fi
case "$subcommand" in
- rm|show|prune)
+ rename|rm|show|prune)
__gitcomp "$(__git_remotes)"
;;
update)
--
1.6.1.227.gad9c0
^ permalink raw reply related
* Re: Planet Git
From: Nanako Shiraishi @ 2009-01-21 23:03 UTC (permalink / raw)
To: webmaster; +Cc: git
In-Reply-To: <a2ce9d792bc2f586e2a1408e573db433.squirrel@webmail.planetgit.org>
Quoting webmaster@planetgit.org:
> Hi everyone,
>
> Just wanted to let everyone know that I've started a Planet for Git
> users/developers who write about it on their journals/weblogs.
>
> http://planetgit.org
>
> Regards,
>
> Tiago
When you want to start a new Planet and make it successful, it may not be a bad idea to prime it by adding feeds from well known people near the center of the git universe, and it would have been better if it was done even before going public like this announcement.
You may have to research whose writings are worth including (http://git.or.cz/gitwiki/GitLinks has a few pointers), and you need to probably go to them and ask permission for including their feeds. In other words, I think you should spend some effort on your own, not just setting up a site and throwing a URL to the wild, to make your Planet successful.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Superproject branch tracking?
From: David Aguilar @ 2009-01-21 23:25 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git Mailing List
In-Reply-To: <49779220.5000900@freescale.com>
On Wed, Jan 21, 2009 at 1:22 PM, Jon Loeliger <jdl@freescale.com> wrote:
> Guys,
>
> Can someone tell me what the current best practice
> to have a Git supermodule maintain a branch that is
> actively tracking a similarly named branch in all of
> the submodules?
>
> That is, I want have a scenario where I would like
> the master branch of a super-project to always (or on
> demand) reflect the current HEAD of the master branch
> in each of the submodules.
>
> Does anyone have a script up their sleeve that I can
> use as a hook in the super to notice updates to a submodule
> and cause it to scurry around the sub-modules and create
> a new (updated) commit in the super?
>
> Thanks,
> jdl
>
Hello
Have you seen Shawn's repo tool?
http://kerneltrap.org/mailarchive/git/2008/10/22/3763214
It might not do *exactly* what you're looking for, but it is magical.
There's also a repo-discuss google group where repo-specific questions
can be addressed.
--
David
^ permalink raw reply
* Re: Planet Git
From: Nanako Shiraishi @ 2009-01-21 23:33 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git
In-Reply-To: <gl80g5$evp$1@ger.gmane.org>
Quoting Johannes Gilger <heipei@hackvalue.de> writes:
> On 2009-01-21, webmaster@planetgit.org <webmaster@planetgit.org> wrote:
>> Just wanted to let everyone know that I've started a Planet for Git
>> users/developers who write about it on their journals/weblogs.
>
> Funny, I just visited it today and didn't know how long this website has
> been idle like that (with only 4 blogs or so). So I was about to write
> you to post it right here, but you did that already.
>
> Although right now I can't see any subscriptions at all :(
There was somebody who used to post a weekly summary of git-related writings from people's blogs to this list. What happened to it? There was not enough interest?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Planet Git
From: Felipe Contreras @ 2009-01-21 23:41 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johannes Gilger, git
In-Reply-To: <20090122083312.6117@nanako3.lavabit.com>
On Thu, Jan 22, 2009 at 1:33 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Johannes Gilger <heipei@hackvalue.de> writes:
>
>> On 2009-01-21, webmaster@planetgit.org <webmaster@planetgit.org> wrote:
>>> Just wanted to let everyone know that I've started a Planet for Git
>>> users/developers who write about it on their journals/weblogs.
>>
>> Funny, I just visited it today and didn't know how long this website has
>> been idle like that (with only 4 blogs or so). So I was about to write
>> you to post it right here, but you did that already.
>>
>> Although right now I can't see any subscriptions at all :(
>
> There was somebody who used to post a weekly summary of git-related writings from people's blogs to this list. What happened to it? There was not enough interest?
You mean the git weekly links, or the editorial kind of thing?
--
Felipe Contreras
^ permalink raw reply
* YourHealth provided here
From: Vivian Covington @ 2009-01-22 0:38 UTC (permalink / raw)
To: git
How To be Healthy Using Safe Products? see there http://umo.happinessspot.com/
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-21 23:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212259420.3586@pacific.mpi-cbg.de>
On Wed, Jan 21, 2009 at 11:17:35PM +0100, Johannes Schindelin wrote:
> Phew. A lot of time, a lot of braincycles, and a lot of keystrokes wasted
> on that subject, don't you think?
Yes, especially considering my other email that said I had dropped the
subject. ;P
But thank you for discussing it. There is still some part of me that
says "if you have no races, you don't have to worry about analyzing
them." But I think your analysis is correct, and I am willing to let it
go in the name of practicality.
As for braincycles, I don't think they were necessarily wasted. The
point of review is to double-check, and the discussion is how we resolve
(even if we resolve that it is OK as-is). Of course there is such a
thing as useless, annoying pedantry, but I hope this didn't count... :)
-Peff
^ permalink raw reply
* Re: [PATCH] contrib: A script to show diff in new window while editing commit message.
From: Junio C Hamano @ 2009-01-21 23:59 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git
In-Reply-To: <1232577906-868-1-git-send-email-ted@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> It could be improved by supporting a command-line flag that would mimic
> the "git commit -v"-type behavior of opening the diff in the same window
> as the commit message. This would extend existing commands like "stg
> edit" that do not already have a "-v"-type option.
If a single-buffer operation is an improvement, then I do not see the
point of this script.
* Some people would like two-buffer operation and they may use this
script as their core.editor.
* Other people (including me) would find it very natural to use "\C-x 2"
if they need to look at two places of the same buffer, because that is
what they are used to do when editing a long file every day. They just
use "commit -v" without bothering with this script.
* Yet other people (like Dscho) would find it too late to have a chance
for final review when writing a commit log message anyway, and won't
use either.
And I think choice is good.
Having said that, if the lack of "final chance to review the diff" in some
StGIT subcommand is the real problem you are trying to solve, I think it
is better solved by fixing StGIT. If this script can be used as a
substitute for the real solution, that may be a welcome unintended side
effect, but I do not think you should make it the main selling point of
the script. After all people may not want to use this script when they
are working directly with git, but still would want StGIT fixed.
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Jeff King @ 2009-01-22 0:00 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: René Scharfe, Junio C Hamano, git
In-Reply-To: <200901212335.24727.markus.heidelberg@web.de>
On Wed, Jan 21, 2009 at 11:35:24PM +0100, Markus Heidelberg wrote:
> > properly initialized (or finalized).
> >
> > So I think it makes more sense to record each config value, and then
> > check a _function_ that does the right thing. I.e., you end up with
> > something like:
> >
> > [example code snipped]
>
> That would probably be better.
Do you want to work on it, or should it go into the "yeah, right, one
day" section of my todo list?
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Markus Heidelberg @ 2009-01-22 0:13 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, Junio C Hamano, git
In-Reply-To: <20090122000026.GB9668@sigill.intra.peff.net>
Jeff King, 22.01.2009:
> On Wed, Jan 21, 2009 at 11:35:24PM +0100, Markus Heidelberg wrote:
>
> > > properly initialized (or finalized).
> > >
> > > So I think it makes more sense to record each config value, and then
> > > check a _function_ that does the right thing. I.e., you end up with
> > > something like:
> > >
> > > [example code snipped]
> >
> > That would probably be better.
>
> Do you want to work on it, or should it go into the "yeah, right, one
> day" section of my todo list?
Yes, feel free to enlarge your todo list :)
There are some other things that I want to work on before, so better
don't count on me for this. But maybe I'll come up to it, before your
todo list pointer reaches this item, who knows.
Markus
^ permalink raw reply
* Re: [PATCH] [TOPGIT] make creating a commit from a topgit branch a function
From: martin f krafft @ 2009-01-22 0:13 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, Petr Baudis
In-Reply-To: <20090121101644.GA19052@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.01.21.2116 +1100]:
> > What's the "next commit"?
> oh, sorry. I intended to post my patch that implements `tg export
> --linearize`, but then found a bug and so didn't send it.
>
> You can find it in my pu branch at
>
> git://git.pengutronix.de/git/ukl/topgit.git pu
>
> . It's not yet ready for general use, but I look forward to any
> constructive feedback.
It'll be a while until I can look into this. Until I do, I will only
pull in f4fa614, and we'll pull ae3fe45 when your linearizing patch
is ready.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"you grabbed my hand and we fell into it,
like a daydream - or a fever."
-- godspeed you black emperor!
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH (topgit)] tg-patch: add support for generating patches against worktree and index
From: martin f krafft @ 2009-01-22 0:28 UTC (permalink / raw)
To: Kirill Smelkov, Git Mailing List
In-Reply-To: <20090121202613.GA5400@roro3.zxlink>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2009.01.22.0726 +1100]:
> It seems I need to study how to prepare patches with patchy
> comments, or get my hands dirty with `git am` :)
I believe git-send-email --editor can be used to create a lead-in
mail to describe what follows, and send patches in separate messages
in reply to that lead-in.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"welcome to american airlines, sir. here's your avocado - remember to
keep it turned on and with you at all times. please turn your luggage
over to the armadillos for rootling."
-- http://azure.humbug.org.au/~aj/armadillos.txt
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Junio C Hamano @ 2009-01-22 0:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0901212259420.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Fact is: every test script will check $GIT_VALGRIND/bin/ for
> up-to-dateness first. Before running any Git command.
Hmm, is that a good thing in general? Can't makefile rules be arranged in
such a way that one "valgrind-prep" target runs before all the potentially
parallel executions of actual tests begin?
Independent from the above, I suspect that some of the existing tests
cannot run in parallel; I haven't really looked at any of them, but a
server-ish tests to open a local port and test interaction with client
obviously need to either use different ports or serialize. Perhaps we
need a way to mark some tests that cannot be run in parallel even under
"make -j"?
^ 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