* Re: log -p hides changes in merge commit
From: Phillip Susi @ 2011-01-07 19:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git
In-Reply-To: <20110106210438.GB15090@burratino>
On 1/6/2011 4:04 PM, Jonathan Nieder wrote:
> In case (1), -c will show a "combined diff" for files where master
> does not match either the old master or topic. --cc, on the other
> hand, will correctly suppress these uninteresting diffs.
>
> In case (2), -c will show a noisy "combined diff" as before.
> --cc will show a combined diff when the changes from both parents
> touch nearby code, even if it merged trivially.
>
> In case (3), -c and --cc will show the semantically boring but
> syntactically interesting merge.
>
> Case (4) is underspecified. So let's give a more precise example:
> the old master and topic tried to fix the same bug in two incompatible
> ways. When merging, I decide I like the topic's way better, so I
> resolve conflicts in favor of the topic. Hopefully all unrelated
> changes on master were preserved!
>
> In this case, -c and --cc will very likely show nothing at all.
> Each file matches one of the two parents (old master or topic) so
> there is no easy way to distinguish the case from (0) or (1).
That does help me understand the difference between -c and -cc, but I
still don't see why one or the other is not the default behavior of log
-p, instead of opting to never show anything at all for merges?
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC] alias: use run_command api to execute aliases
From: Junio C Hamano @ 2011-01-07 19:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git, msysgit, j6t
In-Reply-To: <alpine.DEB.1.00.1101071551190.15247@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> But I'm kind of of two minds here myself, but for a slightly different
>> reason: I think Git for Windows SHOULD use cmd.exe to execute scripts.
>> We should be able to lose the msys-environment and still have the basic
>> functionality working. In that sense, this is a step in the wrong
>> direction. But I'd rather have all code use the same code-path to
>> execute scripts, and make a bit switch to cmd.exe together with porting
>> all supplied scripts to batch-files some time in the future.
>
> Okay, strike my objections, I agree now. Feel free to apply!
FWIW, I agree with Erik's reasoning, too.
Thanks, both.
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Jeff King @ 2011-01-07 19:17 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Nicolas Pitre, Zenaan Harkness, git
In-Reply-To: <20110107185218.GA16645@LK-Perkele-VI.localdomain>
On Fri, Jan 07, 2011 at 08:52:18PM +0200, Ilari Liusvaara wrote:
> On Fri, Jan 07, 2011 at 12:31:19AM -0500, Jeff King wrote:
> >
> > 3. people on low-bandwidth servers who fork major projects; if I write
> > three kernel patches and host a git server, I would really like
> > people to only fetch my patches from me and get the rest of it from
> > kernel.org
>
> One client-side-only feature that could be useful:
>
> Ability to contact multiple servers in sequence, each time advertising
> everything obtained so far. Then treat the new repo as clone of the last
> address.
>
> This would e.g. be very handy if you happen to have local mirror of say, Linux
> kernel and want to fetch some related project without messing with alternates
> or downloading everything again:
>
> git clone --use-mirror=~/repositories/linux-2.6 git://foo.example/linux-foo
>
> This would first fetch everything from local source and then update that
> from remote, likely being vastly faster.
I'm not clear in your example what ~/repositories/linux-2.6 is. Is it a
repo? In that case, isn't that basically the same as --reference? Or is
it a local mirror list?
If the latter, then yeah, I think it is a good idea. Clients should
definitely be able to ignore, override, or add to mirror lists provided
by servers. The server can provide hints about useful mirrors, but it is
up to the client to decide which methods are useful to it and which
mirrors are closest.
Of course there are some servers who will want to do more than hint
(e.g., the gentoo case where they really don't want people cloning from
the main machine). For those cases, though, I think it is best to
provide the hint and to reject clients who don't follow it (e.g., by
barfing on somebody who tries to do a full clone). You have to implement
that rejection layer anyway for older clients.
-Peff
^ permalink raw reply
* 'git add' option to non-interactively stage working tree changes
From: Hrvoje Nikšić @ 2011-01-07 18:56 UTC (permalink / raw)
To: git
Is there a way to non-interactively instruct git to stage all changes
in the working tree, specifically those that would be detected by "git
add -p" or "git commit -a"?
One can use "git add" for this purpose, but it is necessary to specify
the root, and with the unpleasant side effect of adding untracked
files. "git add -u" avoids the file addition, but root still has to be
spelled out. "git add -p" does exactly the right thing, but requires
interaction. I would like an automated --yes-to-all version of "git
add -p".
Specifying the root may seem innocuous, but it is inconsistent with
"git diff" and "git commit [-a]", which don't care where in the tree
you are.
^ permalink raw reply
* Re: [PATCH] t9010: svnadmin can fail even if available
From: Junio C Hamano @ 2011-01-07 18:54 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Jonathan Nieder, A Large Angry SCM, Git Mailing List
In-Reply-To: <20110107165837.GA8062@kytes>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Jonathan Nieder writes:
>> To do the same for t91* would be impossible. If svn is broken or not
>> installed, svn-fe will run fine, but "git svn" will not. On the other
>> hand, if svnadmin were broken but svn still worked, "git svn" would be
>> fine but that would be quite strange and I do not think it is worth
>> spending time to prepare for.
>
> I don't think it's worth spending time preparing for every concievable
> breakage. The patch A few more examples of possible breakages I've
> encountered:
> - APR compiled without threading support, SVN compiled with it, or
> viceversa.
> - SVN is compiled against GNU iconv, but apr-iconv installed, or
> viceversa.
> - Two different versions of a dependent library are installed, and SVN
> links to a different version in a different location.
>
> One or many components of SVN may fail. So, I'm in favor of the
> current approach: if SVN is installed, attempt to run all the t91*
> tests. Any failure can either be interpreted as a real test failure or
> malformed SVN installation.
That was what I was alluding to earlier, but ...
(1) the patch has already been written and it looks obviously correct;
(2) the code after the patch is shorter and more readable; and
(3) this will prevent the mailing list from getting spammed by useless
"bug reports" that should have been directed to distros that packaged
subversion in one broken way.
Admittedly, it may only catch a breakage in one particular way and not
other ways, so we cannot put too much weight on (3), but I would say (2)
above alone is a merit enough for us to have this.
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Ilari Liusvaara @ 2011-01-07 18:52 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, Zenaan Harkness, git
In-Reply-To: <20110107053119.GA23177@sigill.intra.peff.net>
On Fri, Jan 07, 2011 at 12:31:19AM -0500, Jeff King wrote:
>
> 3. people on low-bandwidth servers who fork major projects; if I write
> three kernel patches and host a git server, I would really like
> people to only fetch my patches from me and get the rest of it from
> kernel.org
One client-side-only feature that could be useful:
Ability to contact multiple servers in sequence, each time advertising
everything obtained so far. Then treat the new repo as clone of the last
address.
This would e.g. be very handy if you happen to have local mirror of say, Linux
kernel and want to fetch some related project without messing with alternates
or downloading everything again:
git clone --use-mirror=~/repositories/linux-2.6 git://foo.example/linux-foo
This would first fetch everything from local source and then update that
from remote, likely being vastly faster.
-Ilari
^ permalink raw reply
* Re: [PATCH 4/4] t9129: use "$PERL_PATH" instead of "perl"
From: Junio C Hamano @ 2011-01-07 18:49 UTC (permalink / raw)
To: Yann Droneaud; +Cc: git
In-Reply-To: <74b3db2e538abb4c06d7a0792dff9d78636e2758.1294312018.git.yann@droneaud.fr>
Squash this to 3/4, perhaps saying "while at it, fix $this".
^ permalink raw reply
* Re: [PATCH 3/4] test: use test_utf8 and GIT_LC_UTF8 where an en_US.UTF-8 locale is required
From: Junio C Hamano @ 2011-01-07 18:48 UTC (permalink / raw)
To: Yann Droneaud; +Cc: git
In-Reply-To: <97423472c08cd83373c769bf1cafdb9b85db37e3.1294312018.git.yann@droneaud.fr>
Yann Droneaud <yann@droneaud.fr> writes:
> Signed-off-by: Yann Droneaud <yann@droneaud.fr>
> ---
> t/t9100-git-svn-basic.sh | 25 ++++++++-----------------
> t/t9129-git-svn-i18n-commitencoding.sh | 13 +++----------
> 2 files changed, 11 insertions(+), 27 deletions(-)
Both are nice changes; this patch shows the earlier abstraction in 2/4 is
the right direction to go.
> compare_svn_head_with () {
> # extract just the log message and strip out committer info.
> # don't use --limit here since svn 1.1.x doesn't have it,
> - LC_ALL="$a_utf8_locale" svn log `git svn info --url` | perl -w -e '
> + LC_ALL=$GIT_LC_UTF8 svn log `git svn info --url` | \
> + LC_ALL=$GIT_LC_UTF8 perl -w -e '
Style.
LC_ALL=... svn log ... |
LC_ALL=... perl -w -e '
...
'
When you end a line with '|', the shell knows that you haven't finished
talking to it, so there is no need for the trailing bs-lf there. Indent
the downstream of the pipe to the same level as the upstream.
^ permalink raw reply
* Re: [PATCH 2/4] test-lib.sh: add test_utf8() function
From: Junio C Hamano @ 2011-01-07 18:45 UTC (permalink / raw)
To: Yann Droneaud; +Cc: git
In-Reply-To: <8559d90bff6fca1c18f1cbf3530f2f4cc695f9f4.1294312018.git.yann@droneaud.fr>
Yann Droneaud <yann@droneaud.fr> writes:
> +# check UTF-8 locale availability
> +test_utf8 () {
> + if test_have_prereq PERL ; then
> + # output an en_US.UTF-8 locale compatible name
> + GIT_LC_UTF8=`$PERL_PATH $GIT_BUILD_DIR/t/lib-locale.pl`
> + fi
> + if test -z "$GIT_LC_UTF8" ; then
> + return 1
> + else
> + test_set_prereq UTF8
> + return 0
> + fi
> +}
Nice abstraction to have a helper function that picks a locale to be used
when we want to test UTF-8 thingy. Perhaps pick_utf8_locale might be a
better name, though.
The comment in the function is not wrong per-se, but it and the
implementation in 1/4 may be too restrictive---all it needs to do is to
pick a locale that is UTF-8, and it does not necessarily have to be en_US,
no?
^ permalink raw reply
* Re: bug in gitk: history moves right when scrolling up and down with mouse wheel
From: Neal Kreitzinger @ 2011-01-07 18:44 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20110107105523.GA6701@pengutronix.de>
On 1/7/2011 4:55 AM, Uwe Kleine-König wrote:
> Hello,
>
> I don't know yet how to reliably trigger that, but it feels scary.
>
> If that help, it happens with the view
>
> {karo {} ^linus/master {git for-each-ref --format='%(refname)' refs/remotes/customers/karo refs/heads/karo}}
>
> If I knew how to record a video of my screen, I'd do this. Maybe
> someone knows? Maybe this report is already enough?
>
> Happens with Debian's git 1:1.7.2.3-2.2.
>
Actually, I've wanted the ability to scroll left and right in the
history pane for quite a while. Resorting to shrinking the fontsize and
the other columns only goes so far when trying to see a list of
equivalent refs. If the ability to scroll left and right can be kept
that would be cool.
v/r,
Neal
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Eric Wong @ 2011-01-07 18:39 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramsay Jones, GIT Mailing-list, Steven Walter, Junio C Hamano
In-Reply-To: <20110107181946.GB28980@burratino>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Eric Wong wrote:
>
> > Wait, looking through my backlog, this could fix the problem
> > Ramsay was having but was lost in the shuffle (my fault) :x
> >
> > Ramsay: does this fix it?
> >
> > From 9a4f35d6ff9a66b7b5e57c7124a7cd6df0adad7b Mon Sep 17 00:00:00 2001
> > From: Steven Walter <stevenrwalter@gmail.com>
> > Date: Fri, 22 Oct 2010 21:55:58 -0400
> > Subject: [PATCH] t9157-git-svn-fetch-merge.sh: remove dependency on subversion 1.5
>
> Context, for reference:
>
> http://thread.gmane.org/gmane.linux.kernel/1052314/focus=161717
Ah thanks, I completely forgot about that, too :x I'll take Ramsay's
patch.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/4] test: add a library to detect an en_US.UTF-8 locale
From: Junio C Hamano @ 2011-01-07 18:37 UTC (permalink / raw)
To: Yann Droneaud; +Cc: git
In-Reply-To: <4490926da28dcbfedc779cd32c5a59e20a1b55a2.1294312018.git.yann@droneaud.fr>
Yann Droneaud <yann@droneaud.fr> writes:
Yann Droneaud <yann@droneaud.fr> writes:
> Since one can't rely on "locale" command availability nor its -a output,
> perl script t/lib-locale.pl first use setlocale() and langinfo(CODESET)
> to search for a working en_US.UTF-8 locale among many name variants.
>
> If this fail, the script fallback to "locale" usage with two steps:
> - try the "charmap" keyword, for example LC_ALL=en_US locale charmap
> - then try "-a" option and match a pattern looking to the
> locale names
>
> Signed-off-by: Yann Droneaud <yann@droneaud.fr>
> ---
> t/lib-locale.pl | 167 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 167 insertions(+), 0 deletions(-)
> create mode 100755 t/lib-locale.pl
The remainder of the series looks more or less sane, but a new 170-line
script somehow feels a bit overengineered solution to a minor problem that
has already been solved in a much simpler way.
> +# try to execute "locale -a" command
> +# this command is not always available and
> +# output format is not normalized
> +#
> +use IPC::Open3;
> +use File::Spec;
> +
> +open(NULLR, "<", File::Spec->devnull) || die "Can't open devnull: $!";
> +open(NULLW, ">", File::Spec->devnull) || die "Can't open devnull: $!";
> +
> +my $pid = open3("<&NULLR", \*LOCALES, ">&NULLW" , "locale", "-a") || die "Can't launch locale -a: $!";
> +
> +while(<LOCALES>) {
> + chomp;
> + if (/(en_US\.([\w-]+))/i) {
> + if (codeset_check($2)) {
> + $locale = $1;
> + last;
> + }
> + }
> +}
> +
> +waitpid($pid, 0);
You are trying to buy something with the complexity of Open3 for doing
this logic, over a bog-naive "for (`locale -a`) { ... }", but is that
something really worth the money?
"lib-locale.pl" is a gross misnomer for this script.
It may be a good helper to be used in 2/4 (test_utf8), but later people
may want to have more helper feature in something called "lib-locale", not
just "pick a single UTF-8 locale randomly from available ones on the
system" (especially when ab/i18n starts moving again). I'd suggest either
to (1) rename it "pick-utf8-locale.pl" (i.e. honest naming) or (2) prepare
the helper command to be extensible from the beginning, i.e. require a
command word e.g. "lib-locale.pl pick-utf8-locale" to trigger the
currently implemented feature (i.e. forward looking naming).
^ permalink raw reply
* Why don't git-init and git-clone probe for core.ignorecase on Windows > XP?
From: Dun Peal @ 2011-01-07 18:34 UTC (permalink / raw)
To: Git ML
Hello.
The git-config manpage says about core.ignorecase:
"The default is false, except git-clone(1) or git-init(1) will probe
and set core.ignorecase true if appropriate when the repository is
created."
I assume this is happening when you clone or init on FAT, which is
explicitly mentioned earlier in that section. But apparently it
doesn't happen for either XP, Vista or 7. While those newer releases
use NTFS, which technically supports case-sensitivity, the operating
itself still apparently doesn't, so it would seem like git-clone and
git-init should probe regarding the core.ignorecase on any version of
Windows, no?
Thanks, D
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Yaroslav Halchenko @ 2011-01-07 18:32 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Elijah Newren
In-Reply-To: <20110107181501.GA28980@burratino>
oy -- I thought that cherry-pick is primarily just application of the
patch (without use of the merge clevernesses).
Here is the protocol:
% export GIT_MERGE_VERBOSITY=4
% base=todonotloose^
% next=todonotloose
% head=HEAD
%
% git merge-recursive $base -- $head $next
Merging HEAD with todonotloose
Merging:
855981d just placeholders in the abstract
a00c497 Initial draft for HBM abstract.
CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as frontiers/code~HEAD
% git ls-files -u; # after the merge
160000 a2b57871d2d79bef06ba6214739d82b9a63772a8 2 frontiers/code
zsh: command not found: #
% git diff-tree todonotloose
a00c497fa399c00486c97121ed0b8fda72c7ce47
:040000 040000 40427e34a1ff89c458f2a5f262a108d46b4fa004 c7ba91028b1cef63f4f7eef70f0c4054b31e92b6 M poster-hbm2011_neurodebian
% git diff-tree todonotloose^ HEAD
:100644 100644 378e1379ec5ebb7abac59fec162b7238b5846525 c39ced763aeb5fd352cecd6fef1bfc40471f2246 M .gitmodules
:000000 040000 0000000000000000000000000000000000000000 141dbc1bfe1be2eab77f04ca03f6f28feb372cca A challenge-execpapers
:040000 040000 401fd66867de412b8653dc3a698bbaa45441bec1 ee190f09786f324abdda6e7a36e8278c201a20a0 M frontiers
:040000 040000 26c884a67efb55bdf96d7453d9acd50cee36ae90 ad3e829d15b302c4342a6b2a9fb5dfede0ed77c9 M sty
On Fri, 07 Jan 2011, Jonathan Nieder wrote:
> As contrib/examples/git-revert.sh explains, the heart of "git
> cherry-pick" is
> base=todonotloose^
> next=todonotloose
> head=HEAD
> git merge-recursive $base -- $head $next
> Could you try that, perhaps with GIT_MERGE_VERBOSITY=4 (or some other
> number from 1 to 5, larger is louder) in the environment? For context,
> git ls-files -u; # after the merge
> git diff-tree todonotloose
> git diff-tree todonotloose^ HEAD
> would also be interesting.
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Jonathan Nieder @ 2011-01-07 18:19 UTC (permalink / raw)
To: Eric Wong; +Cc: Ramsay Jones, GIT Mailing-list, Steven Walter, Junio C Hamano
In-Reply-To: <20110107180220.GA20031@dcvr.yhbt.net>
Eric Wong wrote:
> Wait, looking through my backlog, this could fix the problem
> Ramsay was having but was lost in the shuffle (my fault) :x
>
> Ramsay: does this fix it?
>
> From 9a4f35d6ff9a66b7b5e57c7124a7cd6df0adad7b Mon Sep 17 00:00:00 2001
> From: Steven Walter <stevenrwalter@gmail.com>
> Date: Fri, 22 Oct 2010 21:55:58 -0400
> Subject: [PATCH] t9157-git-svn-fetch-merge.sh: remove dependency on subversion 1.5
Context, for reference:
http://thread.gmane.org/gmane.linux.kernel/1052314/focus=161717
^ permalink raw reply
* Re: Wish: make commiter email address configurable per-repo
From: Erik Faye-Lund @ 2011-01-07 18:19 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git
In-Reply-To: <ig7kej$j4p$1@dough.gmane.org>
On Fri, Jan 7, 2011 at 7:01 PM, Stephen Kelly <steveire@gmail.com> wrote:
> Thomas Rast wrote:
>
>> Stephen Kelly wrote:
>>> Thomas Rast wrote:
>>> > See user.email in git-config(1). Most people set it globally, as in
>>> >
>>> > git config --global user.email "author@example.com"
>>> >
>>> > but there's nothing stopping you from doing
>>> >
>>> > git config user.email "alias@example.com"
>>> >
>>> > to set it on a per-repo level. (Or just edit .git/config, of course.)
>>>
>>> Doesn't this set both the author and the committer?
>>
>> Oh, I see. Yes, it does.
>>
>> Stephen Kelly wrote earlier:
>>> If my email address that I use for committing is not the same as that
>>> configured in the bugzilla, the automated bug closing does not work.
>>
>>
>> Probably if KDE has this use-case then that means we need to implement
>> it as a feature on size alone, but I briefly looked into the code and
>> it requires a bit more restructuring than I'm willing to do over
>> coffee.
>>
>> I think as a stop-gap measure you'll have to use an alias such as
>>
>> ci = commit --author="your usual <author>"
>>
>> along with a local setting for user.email to force them to be
>> different. (Note that this will re-set the author when saying 'git
>> ci --amend' on other people's commits!)
>>
>
> Thanks for looking into it!
>
> I'll consider the alias you suggest. Git command aliases can be configured
> per repo, right?
>
Yes, aliases are normal configuration variables, and can be set per repo.
> Is there a bug tracker used for git so that this issue doesn't get lost?
>
No, just this mailing list.
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Jonathan Nieder @ 2011-01-07 18:15 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git, Elijah Newren
In-Reply-To: <20110107172432.GA6040@onerussian.com>
(+cc: Elijah Newren, who has worked on some of this code)
Yaroslav Halchenko wrote:
> In our repository we had some submodules, then there was a branch off
> (call new branch todonotloose) with a single commit. In the master we
> had some other commits and moved one of the subdirectories into a
> submodule.
>
> Later on we decided to cherry pick todonotloose into master but
> cherry-pick fails despite the fact that 'git show todonotloose | patch
> -p1' applies just fine, ie there were no changes touching any of the
> submodules.
[...]
> $> git status
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: poster-hbm2011_neurodebian/abstract.txt
> # modified: poster-hbm2011_neurodebian/jb.txt
> #
> # Unmerged paths:
> # (use "git reset HEAD <file>..." to unstage)
> # (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> # added by us: frontiers/code
> #
As contrib/examples/git-revert.sh explains, the heart of "git
cherry-pick" is
base=todonotloose^
next=todonotloose
head=HEAD
git merge-recursive $base -- $head $next
Could you try that, perhaps with GIT_MERGE_VERBOSITY=4 (or some other
number from 1 to 5, larger is louder) in the environment? For context,
git ls-files -u; # after the merge
git diff-tree todonotloose
git diff-tree todonotloose^ HEAD
would also be interesting.
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Eric Wong @ 2011-01-07 18:02 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list, Steven Walter, Junio C Hamano
In-Reply-To: <AANLkTi=VpHtQ+x5hyfCei-=X=ry4X=+TSGg7EKa7zs4j@mail.gmail.com>
Steven Walter <stevenrwalter@gmail.com> wrote:
> On Fri, Jan 7, 2011 at 12:31 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> >> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> ---
> >
> > Consider this
> > Acked-by: Eric Wong <normalperson@yhbt.net>
>
> Acked-by: Steven Walter <stevenrwalter@gmail.com>
Wait, looking through my backlog, this could fix the problem
Ramsay was having but was lost in the shuffle (my fault) :x
Ramsay: does this fix it?
>From 9a4f35d6ff9a66b7b5e57c7124a7cd6df0adad7b Mon Sep 17 00:00:00 2001
From: Steven Walter <stevenrwalter@gmail.com>
Date: Fri, 22 Oct 2010 21:55:58 -0400
Subject: [PATCH] t9157-git-svn-fetch-merge.sh: remove dependency on subversion 1.5
Specify a revision range to "merge" and manually set the svn:mergeinfo
property.
Acked-by: Eric Wong <normalperson@yhbt.net>
---
t/t9157-git-svn-fetch-merge.sh | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/t/t9157-git-svn-fetch-merge.sh b/t/t9157-git-svn-fetch-merge.sh
index da582c5..424e1fa 100755
--- a/t/t9157-git-svn-fetch-merge.sh
+++ b/t/t9157-git-svn-fetch-merge.sh
@@ -25,15 +25,19 @@ test_expect_success 'initialize source svn repo' '
svn add baz &&
svn commit -m x &&
svn switch "$svnrepo"/trunk &&
- svn merge "$svnrepo"/branches/branch1 &&
+ svn merge -r3:7 "$svnrepo"/branches/branch1 &&
+ svn propset svn:mergeinfo "/branches/branch1:4-7" . &&
svn commit -m "merge" &&
svn switch "$svnrepo"/branches/branch1 &&
svn commit -m x &&
svn switch "$svnrepo"/branches/branch2 &&
- svn merge "$svnrepo"/branches/branch1 &&
+ svn merge -r3:8 "$svnrepo"/branches/branch1 &&
+ svn propset svn:mergeinfo "/branches/branch1:4-8" . &&
svn commit -m "merge branch1" &&
svn switch "$svnrepo"/trunk &&
- svn merge "$svnrepo"/branches/branch2 &&
+ svn merge -r5:9 "$svnrepo"/branches/branch2 &&
+ svn propset svn:mergeinfo "/branches/branch1:4-8
+/branches/branch2:6-9" . &&
svn resolved baz &&
svn commit -m "merge branch2"
) &&
--
Eric Wong
^ permalink raw reply related
* Re: Wish: make commiter email address configurable per-repo
From: Stephen Kelly @ 2011-01-07 18:01 UTC (permalink / raw)
To: git
In-Reply-To: <201101071443.51574.trast@student.ethz.ch>
Thomas Rast wrote:
> Stephen Kelly wrote:
>> Thomas Rast wrote:
>> > See user.email in git-config(1). Most people set it globally, as in
>> >
>> > git config --global user.email "author@example.com"
>> >
>> > but there's nothing stopping you from doing
>> >
>> > git config user.email "alias@example.com"
>> >
>> > to set it on a per-repo level. (Or just edit .git/config, of course.)
>>
>> Doesn't this set both the author and the committer?
>
> Oh, I see. Yes, it does.
>
> Stephen Kelly wrote earlier:
>> If my email address that I use for committing is not the same as that
>> configured in the bugzilla, the automated bug closing does not work.
>
>
> Probably if KDE has this use-case then that means we need to implement
> it as a feature on size alone, but I briefly looked into the code and
> it requires a bit more restructuring than I'm willing to do over
> coffee.
>
> I think as a stop-gap measure you'll have to use an alias such as
>
> ci = commit --author="your usual <author>"
>
> along with a local setting for user.email to force them to be
> different. (Note that this will re-set the author when saying 'git
> ci --amend' on other people's commits!)
>
Thanks for looking into it!
I'll consider the alias you suggest. Git command aliases can be configured
per repo, right?
Is there a bug tracker used for git so that this issue doesn't get lost?
All the best,
Steve.
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Steven Walter @ 2011-01-07 17:44 UTC (permalink / raw)
To: Eric Wong; +Cc: Ramsay Jones, GIT Mailing-list, Junio C Hamano
In-Reply-To: <20110107173114.GA31376@dcvr.yhbt.net>
On Fri, Jan 7, 2011 at 12:31 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> ---
>
> Consider this
> Acked-by: Eric Wong <normalperson@yhbt.net>
Acked-by: Steven Walter <stevenrwalter@gmail.com>
--
-Steven Walter <stevenrwalter@gmail.com>
^ permalink raw reply
* Re: [PATCH] commit: suggest --amend --reset-author to fix commiter identity
From: Jonathan Nieder @ 2011-01-07 17:34 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <vpq7hegmy66.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> The complete message says:
>
> "Your name and email address were configured automatically based\n"
> "on your username and hostname. Please check that they are accurate.\n"
> "You can suppress this message by setting them explicitly:\n"
> "\n"
> " git config --global user.name \"Your Name\"\n"
> " git config --global user.email you@example.com\n"
> "\n"
> "If the identity used for this commit is wrong, you can fix it with:\n"
> "\n"
> " git commit --amend --author='Your Name <you@example.com>'\n"
Sloppy reading on my part. So the original text explains:
how to configure your identity globally
how to change the identity for a single commit
> "\n"
> "or\n"
> "\n"
> " git commit --amend --reset-author\n";
Maybe:
If the identity used for this commit is wrong, you can fix it:
git commit --amend --author='Patch Submitter <author@example.com>'
To just use your newly configured identity:
git commit --amend --reset-author
(modulo wording). The idea being to make it clear to the user why we
are telling two ways to do the same thing.
Sorry for the nonsense.
Jonathan
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Eric Wong @ 2011-01-07 17:31 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list, Junio C Hamano, stevenrwalter
In-Reply-To: <4D260A03.90903@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> ---
>
> This test fails for me, because my svn version(s) are too old (1.4.3
> and 1.4.6), and so I've got into the habit of running the tests with
> NO_SVN_TESTS=1. (which is a bit of a shame in terms of test coverage,
> but it is *much* quicker!)
>
> I don't know the details, but it seems that the 'svn merge' of this
> vintage does not support the operations required by this test.
> Unfortunately, I don't know what the minimum required version of svn
> is, so I'm hoping that someone can take this patch and fix it up
> properly ...
I'm fine taking this patch as-is or even making it just apply to all
1.4.x versions. 1.5+ has been out for ages now and eventually the rest
of the world will just upgrade.
Consider this
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* problem with cherry-picking a commit which comes before introducing a new submodule
From: Yaroslav Halchenko @ 2011-01-07 17:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
Hi GIT Gurus,
per quick IRC troubleshooting it seems to be some kind of an issue in
git cherry-pick logic which tries to deal with existing .gitmodules
structure?
In our repository we had some submodules, then there was a branch off
(call new branch todonotloose) with a single commit. In the master we
had some other commits and moved one of the subdirectories into a
submodule.
Later on we decided to cherry pick todonotloose into master but
cherry-pick fails despite the fact that 'git show todonotloose | patch
-p1' applies just fine, ie there were no changes touching any of the
submodules.
See http://pastebin.com/hpqbiB03 for output.
IMHO everything is legit and failure should have not occurred, or am I
missing something?
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] commit: suggest --amend --reset-author to fix commiter identity
From: Matthieu Moy @ 2011-01-07 17:16 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, gitster
In-Reply-To: <20110107171329.GA16571@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> This message gets used when the author was set from gecos because
> not available in the configuration.
The complete message says:
"Your name and email address were configured automatically based\n"
"on your username and hostname. Please check that they are accurate.\n"
"You can suppress this message by setting them explicitly:\n"
"\n"
" git config --global user.name \"Your Name\"\n"
" git config --global user.email you@example.com\n"
"\n"
"If the identity used for this commit is wrong, you can fix it with:\n"
"\n"
" git commit --amend --author='Your Name <you@example.com>'\n"
"\n"
"or\n"
"\n"
" git commit --amend --reset-author\n";
So, the natural thing to do is
git config --global user.name "me"
git config --global user.email "my.email@bla.com"
git commit --amend --reset-author
and it's not necessary to use the longer
git config --global user.name "me"
git config --global user.email "my.email@bla.com"
git commit --amend --author='me <my.email@bla.com>'
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] commit: suggest --amend --reset-author to fix commiter identity
From: Jonathan Nieder @ 2011-01-07 17:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <1294409671-5479-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy wrote:
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -47,7 +47,11 @@ static const char implicit_ident_advice[] =
> "\n"
> "If the identity used for this commit is wrong, you can fix it with:\n"
> "\n"
> -" git commit --amend --author='Your Name <you@example.com>'\n";
> +" git commit --amend --author='Your Name <you@example.com>'\n"
> +"\n"
> +"or\n"
> +"\n"
> +" git commit --amend --reset-author\n";
>
This message gets used when the author was set from gecos because
not available in the configuration. Do you perhaps mean:
If the identity used for this commit is wrong, you can fix it with:
git commit --amend --author='Your Name <you@example.com>'
git commit --amend --author='Your Name <you@example.com>'
or
cat <<EOF >>~/.gitconfig
[user]
name = Your Name
email = you@example.com
EOF
git commit --amend --reset-author
?
^ 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