* [PATCHv2] git mergetool: Don't repeat merge tool candidates
From: Johannes Gilger @ 2009-01-23 9:14 UTC (permalink / raw)
To: gitster; +Cc: git, tytso, Johannes Gilger
In-Reply-To: <7v7i4m1lq4.fsf@gitster.siamese.dyndns.org>
git mergetool listed some candidates for mergetools twice, depending on
the environment.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
The first patch had the fatal flaw that it listed nothing when DISPLAY
and EDITOR/VISUAL were unset, we fixed that.
The order in which merge-candidates appear is still exactly the same,
only duplicates have been stripped. The check for KDE_FULL_SESSION was
removed since kdiff3 was added as long as DISPLAY was set and we weren't
running gnome.
git-mergetool.sh | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..acdcffb 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -390,21 +390,21 @@ fi
if test -z "$merge_tool" ; then
if test -n "$DISPLAY"; then
- merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
- merge_tool_candidates="meld $merge_tool_candidates"
- fi
- if test "$KDE_FULL_SESSION" = "true"; then
- merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
+ else
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates emerge"
+ merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
fi
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates vimdiff"
+ merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
+ fi
+ if test -z "$merge_tool_candidates" ; then
+ merge_tool_candidates="opendiff emerge vimdiff"
fi
- merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
init_merge_tool_path $i
--
1.6.1.40.g8ea6a
^ permalink raw reply related
* Re: [PATCH] Fix Documentation for git-describe
From: Junio C Hamano @ 2009-01-23 9:36 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Tomas Carnecky, Martin Pirker, git
In-Reply-To: <200901221226.25342.bss@iguanasuicide.net>
Thanks.
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Junio C Hamano @ 2009-01-23 9:39 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git list, Christian MICHON
In-Reply-To: <20090123172646.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> Correct. I did not run that new test, let alone existing ones ;-)
>
> I applied your patch and run the test suite, including the new one, and they passed.
Thanks.
> I tried to write a new option I said that I wanted in my previous message. Here is a patch.
>
> --->8---
> Subject: [PATCH] git-am: Add --ignore-date option
Good.
Leaving "Subject: " in saves me typing, because I do not have to insert it
manually when editing the submitted patch in my MUA to chop off everything
before the scissors.
> This new option makes the command ignore the date header field recorded in
> the format-patch output. The commits will have the timestamp when they
> are created instead.
>
> You can work a lot in one day to accumulate many changes, but apply and
> push to the public repository only some of them at the end of the first
> day. Then next day you can spend all your working hours reading comics or
> chatting with your coworkers, and apply your remaining patches from the
> previous day using this option to pretend that you have been working at
> the end of the day.
LOL. A slacker option is a tough sell to a serious management, though.
I think it would work equally well if you somehow manage to pass this
through "git-rebase", but this won't work with "git-rebase --interactive".
> @@ -379,7 +383,13 @@ do
>
> GIT_AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' "$dotest/info")"
> GIT_AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' "$dotest/info")"
> - GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
> + case "$ignore_date" in
> + t)
> + GIT_AUTHOR_DATE="$(date -R)"
> + ;;
> + '')
> + GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
> + esac
Please align case arm labels with case/esac; iow, do not indent t) and '')
by four spaces, when you write your next case/esac statement.
"date -R" is a GNU extension; avoid it (I'll show you how at the end).
> diff --git a/t/t4150-am.sh b/t/t4150-am.sh
> index 8d3fb00..5ecf456 100755
> --- a/t/t4150-am.sh
> +++ b/t/t4150-am.sh
> @@ -277,4 +277,13 @@ test_expect_success 'am without --committer-date-is-author-date' '
> test "$at" != "$ct"
> '
>
> +test_expect_success 'am --ignore-date' '
> + git checkout first &&
> + test_tick &&
> + git am --ignore-date patch1 &&
> + git cat-file commit HEAD | sed -e "/^$/q" >head1 &&
> + at=$(sed -ne "/^author /s/.*> //p" head1) &&
> + echo "$at" | grep "+0000"
> +'
This is a convoluted logic.
The committer and author dates are set to -0700 timezone by test_tick,
while TZ is set to UTC (+0000) by test-lib.sh, and you are taking
advantage of them to see which one is being used.
But I do not think of a better way to do this offhand, so I'll let it
pass.
Regarding the "date -R" thing, I think we can take advantage of the fact
that an empty GIT_AUTHOR_DATE (and GIT_COMMITTER_DATE) means "do not use
this environment variable, but use the current date instead". Something
like this patch on top of yours, whose first hunk reverts your change to
use "date -R", and sets GIT_AUTHOR_DATE to empty when --ignore-date is
asked for.
No, I didn't test it.
diff --git i/git-am.sh w/git-am.sh
index eb88d90..f935178 100755
--- i/git-am.sh
+++ w/git-am.sh
@@ -383,13 +383,7 @@ do
GIT_AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' "$dotest/info")"
GIT_AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' "$dotest/info")"
- case "$ignore_date" in
- t)
- GIT_AUTHOR_DATE="$(date -R)"
- ;;
- '')
- GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
- esac
+ GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
if test -z "$GIT_AUTHOR_EMAIL"
then
@@ -536,6 +530,10 @@ do
tree=$(git write-tree) &&
parent=$(git rev-parse --verify HEAD) &&
commit=$(
+ if test -n "$ignore_date"
+ then
+ GIT_AUTHOR_DATE=
+ fi
if test -n "$committer_date_is_author_date"
then
GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
^ permalink raw reply related
* Re: how to force a commit date matching info from a mbox ?
From: Nanako Shiraishi @ 2009-01-23 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Christian MICHON
In-Reply-To: <20090123172646.6117@nanako3.lavabit.com>
Quoting Junio C Hamano <gitster@pobox.com>:
>> --->8---
>> Subject: [PATCH] git-am: Add --ignore-date option
>
> Good.
>
> Leaving "Subject: " in saves me typing, because I do not have to insert it
> manually when editing the submitted patch in my MUA to chop off everything
> before the scissors.
I am sorry to ask you a stupid question, but do you mean you want to have
"Subject: " there, or do you mean you want me to leave that word out?
> I think it would work equally well if you somehow manage to pass this
> through "git-rebase", but this won't work with "git-rebase --interactive".
I can try to change git-rebase if you want, but I do not think I can
modify git-rebase --interactive. The script looked very scary last time I
looked at it (^_^;;;).
>> +test_expect_success 'am --ignore-date' '
>> + git checkout first &&
>> + test_tick &&
>> + git am --ignore-date patch1 &&
>> + git cat-file commit HEAD | sed -e "/^$/q" >head1 &&
>> + at=$(sed -ne "/^author /s/.*> //p" head1) &&
>> + echo "$at" | grep "+0000"
>> +'
>
> This is a convoluted logic.
>
> The committer and author dates are set to -0700 timezone by test_tick,
> while TZ is set to UTC (+0000) by test-lib.sh, and you are taking
> advantage of them to see which one is being used.
>
> But I do not think of a better way to do this offhand, so I'll let it
> pass.
>
> Regarding the "date -R" thing, I think we can take advantage of the fact
> that an empty GIT_AUTHOR_DATE (and GIT_COMMITTER_DATE) means "do not use
> this environment variable, but use the current date instead". Something
> like this patch on top of yours, whose first hunk reverts your change to
> use "date -R", and sets GIT_AUTHOR_DATE to empty when --ignore-date is
> asked for.
>
> No, I didn't test it.
I did, and it works.
Thank you very much.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Robin Rosenberg @ 2009-01-23 10:32 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jonathan del Strother, Junio C Hamano, Git Mailing List
In-Reply-To: <76718490901222318l7c3559ecje4a627fe2ff2ad12@mail.gmail.com>
fredag 23 januari 2009 08:18:15 skrev Jay Soffian:
> On Thu, Jan 22, 2009 at 3:13 PM, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> wrote:
[...]
> > Try a three-way merge tool instead like, e.g. xxdiff.
>
> opendiff (aka FileMerge) *is* a three-way merge tool. If the
> screenshot above is not clear, I'm not sure what would be. The left
> pane shows your copy of the file with only line1, line3, and line4.
> The right pane shows the other copy, with only line1, line2, and
> line4.
Where's the ancestor? I'm used to having four panes for doing three-way
merges, but your screenshot showed only three.
>
> Shrug.
You have the option to ignore me....
-- robin
^ permalink raw reply
* Re: [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge
From: Pieter de Bie @ 2009-01-23 9:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Johannes Sixt, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <7vy6x235ky.fsf_-_@gitster.siamese.dyndns.org>
On 23 jan 2009, at 06:21, Junio C Hamano wrote:
> This makes "git commit paths..." form default to "git commit -i paths"
> semantics only during a merge, restoring the pre-v1.3.0 behaviour.
> The
> codepath to create a non-merge commit is not affected and still
> defaults
> to the "--only" semantics.
Do you really want to do this? I think this is a pretty large change
that can bite users if they don't know about this -- for example,
because
they forgot that they are in a merge (it happens..).
FWIW, I'd much rather see a useful error message than this change. If
this change does get in, I think it should be well-documented in the
man pages as well as in the release notes.
- Pieter
^ permalink raw reply
* Re: How to prefix existing svn remotes?
From: Michael J Gruber @ 2009-01-23 11:13 UTC (permalink / raw)
To: Sébastien Mazy; +Cc: git
In-Reply-To: <20090122173211.GB21798@locahost>
Sébastien Mazy venit, vidit, dixit 22.01.2009 18:32:
> Hi all,
>
>
> I created a few months ago a git-svn repository using:
> git svn clone -s https://my_svn_repo .
>
> wich also created the following remotes:
> git branch -r
> branch0
> tags/tag0
> trunk
>
> I would like to prefix theses remotes, so that it shows:
> git branch -r
> prefix/branch0
> prefix/tags/tag0
> prefix/trunk
>
> Of course I should have used the -prefix back when creating the repo but
> it's too late. 'git help svn' doesn't explain how to achieve that and
> simply editing .git/config to add the missing prefix will cause the next
> 'git svn fetch' to download again the whole history (which in my case is
> huge).
>
>
> Is it possible? Did I miss something obvious?
Yes! Depends!
The following works for me:
0) fetch to make sure you're current (optional)
1) edit .git/config and add the prefix (right hand side of the
refpsecs), or really rename in any way you want
2) rename the existing remote branches in the same way
The next git svn fetch will rebuild the map file (which is fast) but not
refetch any svn revisions you already have.
Regarding the renaming: Either I'm dumb or current git branch can't
rename git svn branches. I guess it's because they are remotes but not
really. I had to resort to git update-ref. I'll look into that.
Michael
^ permalink raw reply
* git blame: two "-C"s versus just a single -C
From: Sitaram Chamarty @ 2009-01-23 11:28 UTC (permalink / raw)
To: git
I seem to recall (and the docs indicate) that when you
*copy* (not move, just copy) a function from file1.c to
file2.c, commit, and then do a "git blame -C -C file2.c", it
should tell you that those lines came from file1.c
Is this not true? Git 1.6.1, I tried this on a dummy branch
where I just copied a good sized function (about 45 lines)
from one C program and dumped it at the bottom of a second
one, and neither the gui blame nor the CLI blame show me
that the lines came from elsewhere.
What am I doing wrong?
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Jakub Narebski @ 2009-01-23 12:04 UTC (permalink / raw)
To: Sebastien Cevey; +Cc: Junio C Hamano, git, Giuseppe Bilotta
In-Reply-To: <1232548106.4977310a95d8f@mail.nimag.net>
On Wed, 21 Jan 09, Sebastien Cevey wrote:
>>>>> ----------------------------------------------------------------
>>>>> [Actively cooking]
>>>>>
>>>>> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
>>>>> - gitweb: Optional grouping of projects by category
>>>>> - gitweb: Split git_project_list_body in two functions
>>>>> - gitweb: Modularized git_get_project_description to be more generic
>>>>
>>>> This I think needs some further cooking. I guess with addition of one
>>>> more patch to series categories could be sorted together with projects
>>>> they contain, and not always have to be in fixed ordering.
>>>
>>> These should be moved to the Stalled category; nobody seems to be
>>> discussing improvements and sending updates to the series as far as I
>>> recall.
>>
>> I think it is just the author being slow moving; there was quite
>> a bit of time between subsequent versions of this patch series.
>
> I don't recall what was left to do on top of the series of patches I submitted,
> could you refresh my mind on that if it still needs to be done? I remember the
> discussion trailing off as categorized ordering was being discussed..
I'd have to take a fresh look at discussion but I remember two things:
first, that the code dealing with filtering out projects (e.g. removing
forks) is high incompatibile with introducing later limiting number of
projects per page, as it currently filters out paths _during printing_.
So we might want to have this cleanup before your series (which now
include a bit unnecessary preparation for projects_list view pagination).
Second, there was IMHO one unnecessary sorting, as with one more commit
we can have quite simply categories sorted in order of sorting project
they contain, which means that if we sort projects by age (youngest or
rather most recently changed first) then with one more commit we can
have category containing freshest project first.
I'll try to review this series soon, and if you don't have time I'll
resend them with those minor corrections.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-am: Add --ignore-date option
From: Johannes Schindelin @ 2009-01-23 12:38 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git list, Christian MICHON
In-Reply-To: <20090123172646.6117@nanako3.lavabit.com>
Hi,
[if you would have given a new mail subject to your mail, gitweb would
stand a chance to find it]
On Fri, 23 Jan 2009, Nanako Shiraishi wrote:
> Subject: [PATCH] git-am: Add --ignore-date option
>
> This new option makes the command ignore the date header field recorded in
> the format-patch output. The commits will have the timestamp when they
> are created instead.
>
> You can work a lot in one day to accumulate many changes, but apply and
> push to the public repository only some of them at the end of the first
> day. Then next day you can spend all your working hours reading comics or
> chatting with your coworkers, and apply your remaining patches from the
> previous day using this option to pretend that you have been working at
> the end of the day.
FWIW I have that problem in one of my workflows, and I do this:
grep -v "^Date:" < $MBOX | git am
Of course, this assumes that none of my commit messages has the string
"Date:" at the beginning of the line...
Ciao,
Dscho
^ permalink raw reply
* Re: How to prefix existing svn remotes?
From: Sébastien Mazy @ 2009-01-23 12:42 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4979A64E.6030608@drmicha.warpmail.net>
Hi Michael,
Thanks for your reply.
On Fri, Jan 23, 2009 at 12:13:18PM +0100, Michael J Gruber wrote:
> The following works for me:
>
> 0) fetch to make sure you're current (optional)
> 1) edit .git/config and add the prefix (right hand side of the
> refpsecs), or really rename in any way you want
OK.
> 2) rename the existing remote branches in the same way
I'm not sure how I can do it. 'trunk' is the only remote-tracking svn
branches under .git/refs/. Here is how it looks:
ls -R .git/refs
.git/refs: heads remotes tags
.git/refs/heads: master
.git/refs/remotes: trunk
Still, a 'branch0' remote exist:
git show-ref
refs/heads/master
refs/remotes/branch0
refs/remotes/trunk
--
Sébastien Mazy
^ permalink raw reply
* bug: transform a binary file into a symlink in one commit => invalid binary patch
From: Pixel @ 2009-01-23 12:25 UTC (permalink / raw)
To: git
hi,
i hit a bug (git 1.6.1): when you transform a binary file into a
symlink in one commit, the binary patch can't be used in "git apply".
Is it a known issue?
reproducer:
----------
#!/bin/sh -e
# the bug: if you transform a binary file into a symlink in one commit,
# the binary patch can't be used in "git apply"
#
# nb: if you uncomment the "##" lines, the problem disappears
# since the first patch will empty the binary file then the non-binary file
# will be transformed into a symlink
rm -rf t t2
mkdir t
dd if=/dev/urandom of=t/a count=10
cp -r t t2
cd t
git init
git add .
git commit -m initial
##echo -n > a
##git commit -a -m foo
ln -sf zzz a
git commit -a -m foo2
git format-patch :/initial
cd ../t2
git apply ../t/*.patch
cd ..
rm -rf t t2
----------
^ permalink raw reply
* Re: How to prefix existing svn remotes?
From: Michael J Gruber @ 2009-01-23 13:02 UTC (permalink / raw)
To: Sébastien Mazy; +Cc: git
In-Reply-To: <20090123124231.GA17616@locahost>
Sébastien Mazy venit, vidit, dixit 23.01.2009 13:42:
> Hi Michael,
>
> Thanks for your reply.
>
> On Fri, Jan 23, 2009 at 12:13:18PM +0100, Michael J Gruber wrote:
>> The following works for me:
>>
>> 0) fetch to make sure you're current (optional)
>> 1) edit .git/config and add the prefix (right hand side of the
>> refpsecs), or really rename in any way you want
>
> OK.
>
>> 2) rename the existing remote branches in the same way
>
> I'm not sure how I can do it. 'trunk' is the only remote-tracking svn
> branches under .git/refs/. Here is how it looks:
>
> ls -R .git/refs
> .git/refs: heads remotes tags
> .git/refs/heads: master
> .git/refs/remotes: trunk
>
> Still, a 'branch0' remote exist:
>
> git show-ref
> refs/heads/master
> refs/remotes/branch0
> refs/remotes/trunk
You can do (bash)
for b in trunk branch0
do
git update-ref refs/remotes/yournewprefix/$b refs/remotes/$b
git update-ref -d refs/remotes/$b
done
OTOH, any incarnation of "git -m" (with or without "-r", specifying
refs/remotes/trunk, remotes/trunk or trunk) failed.
Michael
^ permalink raw reply
* Re: bug: transform a binary file into a symlink in one commit => invalid binary patch
From: Michael J Gruber @ 2009-01-23 13:13 UTC (permalink / raw)
To: Pixel; +Cc: git
In-Reply-To: <lyhc3q9pl1.fsf@leia.mandriva.com>
Pixel venit, vidit, dixit 23.01.2009 13:25:
> hi,
>
> i hit a bug (git 1.6.1): when you transform a binary file into a
> symlink in one commit, the binary patch can't be used in "git apply".
> Is it a known issue?
>
>
> reproducer:
>
> ----------
> #!/bin/sh -e
>
> # the bug: if you transform a binary file into a symlink in one commit,
> # the binary patch can't be used in "git apply"
> #
> # nb: if you uncomment the "##" lines, the problem disappears
> # since the first patch will empty the binary file then the non-binary file
> # will be transformed into a symlink
>
> rm -rf t t2
> mkdir t
> dd if=/dev/urandom of=t/a count=10
> cp -r t t2
>
> cd t
> git init
> git add .
> git commit -m initial
>
> ##echo -n > a
> ##git commit -a -m foo
> ln -sf zzz a
> git commit -a -m foo2
> git format-patch :/initial
>
> cd ../t2
> git apply ../t/*.patch
>
> cd ..
> rm -rf t t2
> ----------
You're not even initialising a repo in t2. I assume you want to "cp -a t
t2" after the "initial" commit, don't you? Doing that I get
error: binary patch to 'a' creates incorrect result (expecting
e132db255c0e0e3e9309c3c58a0a9c9eb97dd942, got
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
error: a: patch does not apply
error: a: already exists in working directory
which is not that magnificient either. If that's the error you're after
your test script needs to be modified.
Michael
^ permalink raw reply
* Re: [PATCH] git-am: Add --ignore-date option
From: Adeodato Simó @ 2009-01-23 13:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nanako Shiraishi, Junio C Hamano, git list, Christian MICHON
In-Reply-To: <alpine.DEB.1.00.0901231336080.3586@pacific.mpi-cbg.de>
* Johannes Schindelin [Fri, 23 Jan 2009 13:38:34 +0100]:
> FWIW I have that problem in one of my workflows, and I do this:
> grep -v "^Date:" < $MBOX | git am
> Of course, this assumes that none of my commit messages has the string
> "Date:" at the beginning of the line...
In case you're interested:
% formail -I 'Date' -s < $MBOX | git am
is robust against your assumption being wrong. (I realize ^Date: is not
very likely in commit messages, but I thought I'd mention nevertheless.)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
- Are you sure we're good?
- Always.
-- Rory and Lorelai
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Björn Steinbrink @ 2009-01-23 13:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Vladimir Pouzanov, git
In-Reply-To: <20090123085235.GA14721@machine.or.cz>
On 2009.01.23 09:52:35 +0100, Petr Baudis wrote:
> On Tue, Jan 13, 2009 at 08:46:55PM +0000, Vladimir Pouzanov wrote:
> > Björn Steinbrink <B.Steinbrink <at> gmx.de> writes:
> > > Is that Linux box using Gentoo? If so, try emerging subversion with -dso
> > > in your build flags.
> >
> > Yeah, that's gentoo. Will try rebuilding svn now.
>
> I have hit the same issue (segfault on Gentoo) and this fixed it for me.
> But do you have any details on why is the segfault caused and how to
> prevent it? USE=dso is the default on Gentoo. :-(
No idea, I just heard about that in #git. IIRC it was Mikachu who came
up with that solution. Unfortunately, he's not around at the moment, and
I don't recall his real name, so not on Cc. :-/
Björn
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-23 15:16 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20090122142258.GA2316@hashpling.org>
> You'll never (well, almost never) know that tabs aren't 4 spaces.
no but I think people should be able to view indents at whatever they
want and still have it work, which is why I normally use tabs
exclusively, and set it to 4 space display, but if people wanted to
view at 2, 6, 8 spaces or whatever they could and the indents should
still look correct.
it doesn't really matter to each project there own.
so does my patch satisfy now? what's it take to get it included in the
next version of git?
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Jay Soffian @ 2009-01-23 15:51 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jonathan del Strother, Junio C Hamano, Git Mailing List
In-Reply-To: <200901231132.36543.robin.rosenberg.lists@dewire.com>
On Fri, Jan 23, 2009 at 5:32 AM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> Where's the ancestor? I'm used to having four panes for doing three-way
> merges, but your screenshot showed only three.
I installed xxdiff to compare w/opendiff, meld, and vimdiff and I see
what you mean with xxdiff.
opendiff/meld/vimdiff don't show the ancestor directly, but they are
still using it in order to show how one version differs from the
ancestor in the left pane, and how the other version differs in the
right pane.
>> Shrug.
>
> You have the option to ignore me....
Doh, I meant only "I don't understand." My apologies.
j.
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Jay Soffian @ 2009-01-23 15:59 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jonathan del Strother, Junio C Hamano, Git Mailing List
In-Reply-To: <76718490901230751uef27274sf7b44e6718f861ae@mail.gmail.com>
On Fri, Jan 23, 2009 at 10:51 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> opendiff/meld/vimdiff don't show the ancestor directly, but they are
> still using it in order to show how one version differs from the
> ancestor in the left pane, and how the other version differs in the
> right pane.
Hmm, okay. I see that meld/vimdiff are apparently not doing a 3-way
merge. So I guess after all this, I don't have an explanation about
opendiff. It claims to do a 3-way diff and mergetool is passing it the
ancestor as an argument. Sorry for the confusion.
j.
^ permalink raw reply
* Re: CR codes from git commands
From: Brent Goodrick @ 2009-01-23 16:12 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Daniel Barkalow, Brent Goodrick, Mike Ralphson, Junio C Hamano,
git
In-Reply-To: <alpine.DEB.1.00.0901221751320.3586@pacific.mpi-cbg.de>
Johannes Schindelin writes:
> Hi,
>
> On Thu, 22 Jan 2009, Daniel Barkalow wrote:
>
> > In any case, it's all done in progress.c, so it should be easy enough to
> > make changes to if you can come up with something better to do with
> > progress messages and some way to determine when it should be done.
>
> Maybe "git --no-progress <program>" would be a sensible user
> interface?
Thanks. I now see the \r reference inside the "display" file-static
function inside progress.c.
However, I propose to add two options, the first being, IMO, the
minimal one to implement, and the second being "nice-to-have":
- Bare minimum: Add a new --no-cr option (e.g., "git --no-cr
<program>") that would prevent any git code (inside progress.c or
elsewhere) from emitting a CR code from stdout or stderr. This has
the effect of allowing progress messages, but not asking too much
of terminals-that-are-not-really-terminals such as the GNU Emacs
shell mode.
- Nice-to-have: Add a "git --no-progress" message that would never
show progress at all (e.g., perhaps by not installing a signal
handler inside progress.c such that no messages would not be
emitted at all.
Both options are intended to be independent of each other.
And for both options, I would like there to be a config option to
allow the user to enable said behavior globally across all git
operations covered by that config file.
I might be willing to take a swipe at this myself and submit a patch,
provided I receive adequate noobie hand-holding (or hand-slapping) on
patch submission and test case development.
bg
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Miklos Vajna @ 2009-01-23 16:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901230419080.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
On Fri, Jan 23, 2009 at 04:20:34AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> But then, scripts have no business cloning repositories (fetching, yes.
> But cloning?)
I think portals like repo.or.cz may do it.
Isn't setting errno (or similar variable) in the HTTP code an option?
Then we could see why the transport failed and make a difference between
"network error" and "no refs found".
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: CR codes from git commands
From: Junio C Hamano @ 2009-01-23 16:59 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Johannes Schindelin, Daniel Barkalow, Mike Ralphson, git
In-Reply-To: <18809.60512.654436.59819@hungover.brentg.com>
Brent Goodrick <bgoodr@gmail.com> writes:
> - Bare minimum: Add a new --no-cr option (e.g., "git --no-cr
> ...
> - Nice-to-have: Add a "git --no-progress" message that would never
> ...
> Both options are intended to be independent of each other.
I do not think so. --no-progress should imply --no-cr ;-)
I do not think it makes much sense to pollute your non-terminal with 100
lines of 1%,2%,3%,...100% if it cannot sensibly do carriage-returns. It
may be another knob to tweak, but it's a kind of thing you implement
because you could, not because it makes sense. I would be mildly against
no-cr.
I suspect we may even be able to solve it without adding --no-progress.
Perhaps some commands do not have --quiet to squelch progress and teaching
them --quiet will solve the issue for you?
^ permalink raw reply
* Re: [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge
From: Junio C Hamano @ 2009-01-23 17:01 UTC (permalink / raw)
To: Pieter de Bie
Cc: Nanako Shiraishi, Johannes Sixt, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <53513726-CE1C-4487-B775-440C6DC93DD8@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> On 23 jan 2009, at 06:21, Junio C Hamano wrote:
>
>> This makes "git commit paths..." form default to "git commit -i paths"
>> semantics only during a merge, restoring the pre-v1.3.0 behaviour.
>> The
>> codepath to create a non-merge commit is not affected and still
>> defaults
>> to the "--only" semantics.
>
> Do you really want to do this? I think this is a pretty large change
> that can bite users if they don't know about this -- for example,
> because
> they forgot that they are in a merge (it happens..).
>
> FWIW, I'd much rather see a useful error message than this change. If
> this change does get in, I think it should be well-documented in the
> man pages as well as in the release notes.
As I said already in an earlier message in this thread, this is only a
weatherballoon series to help facilitate the discussion, and I am not
strongly in favor of this. In fact, if I were, I would have done that
long time ago around v1.3.0, because there was a discussion about doing
this and the concensus back then was that the command changing the default
behaviour between -i and -o was too confusing, even though it may be
dwimming better.
The onus is upon those who argued that "commit paths" should default to
the --include semantics during a merge resolution in this thread to
improve the documentation, if they want this to go forward.
^ permalink raw reply
* Re: How to prefix existing svn remotes?
From: Sébastien Mazy @ 2009-01-23 17:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4979BFE7.8090402@drmicha.warpmail.net>
On Fri, Jan 23, 2009 at 02:02:31PM +0100, Michael J Gruber wrote:
> You can do (bash)
>
> for b in trunk branch0
> do
> git update-ref refs/remotes/yournewprefix/$b refs/remotes/$b
> git update-ref -d refs/remotes/$b
> done
That did the trick. Thank you so much!
By the way, my renamed remote tracking svn branches now show under
.git/refs/ as expected.
--
Sébastien Mazy
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Junio C Hamano @ 2009-01-23 17:20 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, Hannu Koivisto, Theodore Tso
In-Reply-To: <1232578668-2203-1-git-send-email-charles@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> 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>
Sounds like the right thing to do and from a cursory review it looks Ok to
me.
But I do not use mergetool myself, so an Ack from Ted and a Thanks from
whoever reported the breakage would be encouraging ;-).
> +checkout_staged_file () {
> + tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
> +
> + if test $? -eq 0 -a -n "$tmpfile" ; then
> + mv -- "$tmpfile" "$3"
The original redirects into the final destination but this moves. This
will lose the perm bits of the original and obey the perm bits
checkout-index gives you. It will also behave differently when the path
is a symlink. These two differences _may_ well be improvements and/or
bugfixes, but if that is the case please describe them as such.
^ 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