* Re: git-svn stubbornly re-creating branch "master"
From: Eric Wong @ 2009-03-29 22:28 UTC (permalink / raw)
To: Marcin Owsiany; +Cc: git
In-Reply-To: <20090329171347.GA26866@beczulka>
Marcin Owsiany <porridge@debian.org> wrote:
> Hello,
>
> I created my git repository by cloning it with git-svn from an upstream SVN
> repository. When I did that, a branch "master" was created. Afterwards I
> renamed that branch to "upstream". However every time I "git-svn fetch", it
> recreates the "master" branch, pointing it at the newest upstream commit.
>
> Ideally, I'd like it to just forget about "master" and do the same to my
> "upstream" branch. Is it possible?
>
> If not, then is it at least possible to have it not recreate the "master"
> branch? It clutters my view.
"master" has been a git convention since the earliest days of git and
it's less confusing to new users following documentation if it always
exists (and a lot of users' first git experience is with git svn).
Why not just use "master" as one of your branches? It won't bite you.
"git svn fetch" will never clobber your "master" if it already exists.
--
Eric Wong
^ permalink raw reply
* [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Markus Heidelberg @ 2009-03-29 22:30 UTC (permalink / raw)
To: msysgit; +Cc: git, Shawn O. Pearce
Starting git-gui via Windows Explorer shell extension caused problems
when not started from the project directory, but from a directory within
the project: starting the Explorer from the git-gui menu "Explore
Working Copy" didn't work then.
Starting git-gui via Explorer shell extension from the .git directory
didn't work at all.
To make these things possible, "cd .." until we see .git/
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
windows/git-gui.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/windows/git-gui.sh b/windows/git-gui.sh
index 53c3a94..16c4a2a 100644
--- a/windows/git-gui.sh
+++ b/windows/git-gui.sh
@@ -4,6 +4,9 @@ exec wish "$0" -- "$@"
if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
cd [lindex $argv 1]
+ while { ![file isdirectory .git] } {
+ cd ..
+ }
set argv [lrange $argv 2 end]
incr argc -2
}
--
1.6.2.1.409.gad7bf.dirty
^ permalink raw reply related
* Re: git svn init --username ignored
From: Eric Wong @ 2009-03-29 22:41 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git
In-Reply-To: <9FB623A2-03A6-4B35-B631-DF4745971DB9@gmail.com>
Lachlan Deck <lachlan.deck@gmail.com> wrote:
> Hi there,
>
> Is it a bug that the when specifying --username=foo for either git-svn
> init or git-svn clone that this isn't stored in .git/config?
>
> It means that for http[s] urls you need to specify it each time for
> git-svn fetch, for example.
>
> Is there any way to specify it manually in the config file - or would
> that have some bad consequences?
Hi,
Subversion already stores credential information in ~/.subversion/ which
git svn should respect and use if available and allowed to. Did you
disable set "store-auth-creds = no" in your ~/.subversion/config ?
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: don't output git commits in quiet mode
From: Eric Wong @ 2009-03-29 22:43 UTC (permalink / raw)
To: Simon Arlott; +Cc: gitster, git
In-Reply-To: <49CFCD5A.1080801@simon.arlott.org.uk>
Simon Arlott <simon@fire.lp0.eu> wrote:
> Ideally only errors should be output in this mode so fetch
> can be run from cron and normally produce no output. Without
> this change it would output a single line on each git commit,
> e.g.
> r1909 = 32ef87860662526d4a62f903949ed21e0341079e (u2_10_12_branch)
>
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Thanks Simon,
Acked-by: Eric Wong <normalperson@yhbt.net>
and pushed to git://git.bogomips.org/git-svn
> ---
> git-svn.perl | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 8be6be0..e100b69 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2331,13 +2331,13 @@ sub do_git_commit {
>
> $self->{last_rev} = $log_entry->{revision};
> $self->{last_commit} = $commit;
> - print "r$log_entry->{revision}";
> + print "r$log_entry->{revision}" unless $::_q;
> if (defined $log_entry->{svm_revision}) {
> - print " (\@$log_entry->{svm_revision})";
> + print " (\@$log_entry->{svm_revision})" unless $::_q;
> $self->rev_map_set($log_entry->{svm_revision}, $commit,
> 0, $self->svm_uuid);
> }
> - print " = $commit ($self->{ref_id})\n";
> + print " = $commit ($self->{ref_id})\n" unless $::_q;
> if (--$_gc_nr == 0) {
> $_gc_nr = $_gc_period;
> gc();
> --
> 1.6.2
^ permalink raw reply
* Re: Implementing stat() with FindFirstFile()
From: Magnus Bäck @ 2009-03-29 22:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0903270320020.10279@pacific.mpi-cbg.de>
On Friday, March 27, 2009 at 03:25 CET,
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Magnus, it is the official policy to reply-to-all on this list. This
> has been mentioned in the past quite often, and it will be mentioned
> in the future, too.
Sorry, I was not aware. Doesn't seem to have been mentioned in the last
month or so. Perhaps it could be included in the list introduction
message? All people obviously won't read it, but some will.
> You actually forced me to manually look up and re-add Hannes' address.
> I do not appreciate having to waste my time like that.
>
> If that sounds negative, please understand that I am used to the ways
> of this list, and when I am annoyed by somebody not fitting in, then
> it is not totally _my_ mistake.
A plain "please use reply all" would've sufficed.
> On Thu, 26 Mar 2009, Magnus Bäck wrote:
>
> > I'd be very surprised if ZwQueryDirectoryFile() hasn't always been
> > around (I just verified ntdll.dll from NT 4.0), so that's not a
> > worry. Don't know why MSDN reports it as introduced in XP.
>
> As the current maintainer of msysGit, I refuse to have something in
> the installer I ship that relies on not-at-all guaranteed interfaces.
Although I do appreciate the importance of guaranteed interfaces,
I am also pragmatic. An incompatible change in ntdll.dll would break
vast amounts of programs, including cygwin. There is a lot to be said
about Microsoft and their APIs, but I don't think they have a habit of
changing ABIs or function semantics for userland libraries that have
been around for 15 years.
> > All right, I'll see if I can find time to take a look at this. I
> > just wanted to check that it wasn't a project policy or whatever
> > to bypass Win32.
>
> You can do whatever you want... This is Open Source.
>
> However, I will try to stay with the officially supported functionality,
> even if that makes msysGit slower -- Windows will never reach the
> performance levels of Linux anyway.
Okay, thanks. Just like you I hate wasting time, in my case with patches
that'll be refused.
--
Magnus Bäck
baeck@swipnet.se
^ permalink raw reply
* Re: git svn init --username ignored
From: Lachlan Deck @ 2009-03-29 23:50 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090329224137.GA20675@dcvr.yhbt.net>
On 30/03/2009, at 9:41 AM, Eric Wong wrote:
> Lachlan Deck <lachlan.deck@gmail.com> wrote:
>> Hi there,
>>
>> Is it a bug that the when specifying --username=foo for either git-
>> svn
>> init or git-svn clone that this isn't stored in .git/config?
>>
>> It means that for http[s] urls you need to specify it each time for
>> git-svn fetch, for example.
>>
>> Is there any way to specify it manually in the config file - or would
>> that have some bad consequences?
>
> Subversion already stores credential information in ~/.subversion/
> which
> git svn should respect and use if available and allowed to. Did you
> disable set "store-auth-creds = no" in your ~/.subversion/config ?
No, it's still commented out.
I simply started by doing:
git svn clone https://somedomain/repo repo --username=lachlan -s
cd repo
git svn fetch // failed without --username
In case the initial passing of --username is tripping it up, I'm
trying again without specifying it.
with regards,
--
Lachlan Deck
^ permalink raw reply
* git-web and .git and working directories
From: Aaron Gray @ 2009-03-29 23:58 UTC (permalink / raw)
To: Git Mailing List
Hi,
Is there a proper way to configure GIT so the '.git' suffix does not appear
in git-web and also is it possible to disable the working directory so
things are more self contained.
Anyway I have git-daemon, git-svn with a SELinux policy all running on F10.
Thanks for bearing with me,
Aaron
^ permalink raw reply
* Re: [EGIT] [PATCH RFC v1 0/5] Add (static) ignore functionality to EGit
From: Jonathan Gossage @ 2009-03-30 0:40 UTC (permalink / raw)
To: Ferry Huberts; +Cc: git
In-Reply-To: <cover.1238102327.git.ferry.huberts@pelagic.nl>
Ferry Huberts wrote:
> This is the first - early - code that adds ignore functionality to EGit.
> Currently it reads in all ignore patterns upon workspace startup into an
> ignore cache. From this cache the ignore state of a resource is evaluated
> in the same fashion as git does.
>
> The code does not yet react to changes in ignore files but I'm planning to add
> that soon and I can share a lot of code for that.
>
> I send this code to receive feedback and to give you insight into what I'm
> doing with it. I'm new both to EGit programming and Eclipse programming so
> there might be things that could be done more elegantly :-)
>
> A few notes:
> - The patches are rebased on the current master (e3440623)
> - The order of the patches must be re-arranged, but that is rather easy. The
> correct order - once finished - would be:
> Build up the ignore patterns cache upon workspace startup.
> Use the ignore patterns cache to determine ignores
> Enable the ignore handling of the plugin
> Optimise ignore evaluation
> Do not set .git as a Team ignore pattern
> - The core.excludesfile code is currently untested, the other code seems to be
> in a good state.
> - There are a few FIXMEs in the code with questions and tasks. It's a work in
> progress and these will disappear.
>
> Ferry Huberts (5):
> Build up the ignore patterns cache upon workspace startup.
> Enable the ignore handling of the plugin
> Optimise ignore evaluation
> Do not set .git as a Team ignore pattern
> Use the ignore patterns cache to determine ignores
>
> org.spearce.egit.core/META-INF/MANIFEST.MF | 1 +
> org.spearce.egit.core/plugin.xml | 6 -
> .../src/org/spearce/egit/core/ignores/DType.java | 44 ++
> .../src/org/spearce/egit/core/ignores/Exclude.java | 243 +++++++++
> .../spearce/egit/core/ignores/GitIgnoreData.java | 180 +++++++
> .../org/spearce/egit/core/ignores/IgnoreFile.java | 82 +++
> .../egit/core/ignores/IgnoreFileOutside.java | 543 ++++++++++++++++++++
> .../egit/core/ignores/IgnoreProjectCache.java | 245 +++++++++
> .../egit/core/ignores/IgnoreRepositoryCache.java | 358 +++++++++++++
> .../org/spearce/egit/core/op/TrackOperation.java | 7 +-
> .../spearce/egit/core/project/GitProjectData.java | 8 +
> .../decorators/DecoratableResourceAdapter.java | 11 +-
> org.spearce.jgit/META-INF/MANIFEST.MF | 1 +
> 13 files changed, 1712 insertions(+), 17 deletions(-)
> create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/DType.java
> create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/Exclude.java
> create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/GitIgnoreData.java
> create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/IgnoreFile.java
> create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/IgnoreFileOutside.java
> create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/IgnoreProjectCache.java
> create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/IgnoreRepositoryCache.java
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
Eclipse supplies a repository-independent ignore file list as part of the repository-type independent Team support. A first step, which would provide useful functionality would be to populate your cache with this list and enable it's use in the Egit plugin. This would accomplish the goal of enabling EGit to use ignore lists in an immediately useful way with minimal effort. As a second stage you can add support for picking up Git specific files and updating them from Eclipse.
I think you will run into problems if you try to create a workspace wide
cache. It is quite possible that one workspace could have projects that
target different Git repositories. This means that your cache would need
to look at all projects in the workspace and potentially take into
account Eclipse working sets and other such complications. You also will
need to deal with projects being added and deleted from the Eclipse
workspace.
I think a better approach might be to go for lazy cache construction
where the cache is built only when actually needed by a user operation.
The cache would then be built only for a specific Git repository. JGit
should be responsible for assembling a merged list from the various Git
files. It should also be responsible for the actual updating of the
various Git ignore files. Since I believe that the Eclipse
repository-independent ignore file list should be the lowest priority in
the merged list, it will be necessary to pass the Eclipse list to JGit
as a parameter whenever a merged list is required.
In general, you should look to do Git specific things in JGit and do
Eclipse things in Eclipse. That way JGit continues to acquire the
functionality to support any IDE and EGit is kept as simple as possible.
HTH
Jonathan Gossage
^ permalink raw reply
* Re: [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Johannes Schindelin @ 2009-03-30 0:43 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: msysgit, git, Shawn O. Pearce
In-Reply-To: <200903300030.03733.markus.heidelberg@web.de>
Hi,
On Mon, 30 Mar 2009, Markus Heidelberg wrote:
> Starting git-gui via Windows Explorer shell extension caused problems
> when not started from the project directory, but from a directory within
> the project: starting the Explorer from the git-gui menu "Explore
> Working Copy" didn't work then.
>
> Starting git-gui via Explorer shell extension from the .git directory
> didn't work at all.
>
> To make these things possible, "cd .." until we see .git/
How does this interact with GIT_WORK_TREE? And with bare repositories?
Ciao,
Dscho
^ permalink raw reply
* Re: Implementing stat() with FindFirstFile()
From: Johannes Schindelin @ 2009-03-30 0:52 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Johannes Sixt, git
In-Reply-To: <20090329224803.GD27249@jeeves.jpl.local>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3616 bytes --]
Hi,
On Mon, 30 Mar 2009, Magnus Bäck wrote:
> On Friday, March 27, 2009 at 03:25 CET,
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Magnus, it is the official policy to reply-to-all on this list. This
> > has been mentioned in the past quite often, and it will be mentioned
> > in the future, too.
>
> Sorry, I was not aware. Doesn't seem to have been mentioned in the last
> month or so. Perhaps it could be included in the list introduction
> message? All people obviously won't read it, but some will.
>
> > You actually forced me to manually look up and re-add Hannes' address.
> > I do not appreciate having to waste my time like that.
> >
> > If that sounds negative, please understand that I am used to the ways
> > of this list, and when I am annoyed by somebody not fitting in, then
> > it is not totally _my_ mistake.
>
> A plain "please use reply all" would've sufficed.
I do recognize that I was too harsh: I apologize!
> > On Thu, 26 Mar 2009, Magnus Bäck wrote:
> >
> > > I'd be very surprised if ZwQueryDirectoryFile() hasn't always been
> > > around (I just verified ntdll.dll from NT 4.0), so that's not a
> > > worry. Don't know why MSDN reports it as introduced in XP.
> >
> > As the current maintainer of msysGit, I refuse to have something in
> > the installer I ship that relies on not-at-all guaranteed interfaces.
>
> Although I do appreciate the importance of guaranteed interfaces,
> I am also pragmatic. An incompatible change in ntdll.dll would break
> vast amounts of programs, including cygwin. There is a lot to be said
> about Microsoft and their APIs, but I don't think they have a habit of
> changing ABIs or function semantics for userland libraries that have
> been around for 15 years.
That does not give me the warm and fuzzy feeling I want to have when
shipping a new Git for Windows.
Had you pointed to some document that states that the function has been in
all NT-based versions, that would have done the trick.
> > > All right, I'll see if I can find time to take a look at this. I
> > > just wanted to check that it wasn't a project policy or whatever to
> > > bypass Win32.
> >
> > You can do whatever you want... This is Open Source.
> >
> > However, I will try to stay with the officially supported functionality,
> > even if that makes msysGit slower -- Windows will never reach the
> > performance levels of Linux anyway.
>
> Okay, thanks. Just like you I hate wasting time, in my case with patches
> that'll be refused.
Sorry, that was not at all what I meant.
Of course, I wanted to avoid having time wasted: yours and mine. But if
you find said document, or another proof that the function was not
introduced by pure chance in some of NT's service packs, then that's
perfectly fine with me.
But if it is, say, only in NT when upgrading to Explorer 6 or newer, I do
not want to take it: I personally know a machine running NT without
service packs, and with Internet Explorer 5.5, because every attempt at
upgrading freezes the complete machine 10 seconds into the login screen.
And no, the machine cannot run with another setup, because there is a
6-figure microscope plugged in that refuses to be controlled by anything
else than the proprietary software that just happens to run only on said
NT4, with said IE5.5.
Again, I am sorry for my harsh reaction, but please understand that I
_need_ better proof that nobody will be bitten by your change (chances are
that I'd have to clean it up...).
After all, in the short time since the release of 1.6.2.1, we had over
4000 downloads already.
Ciao,
Dscho
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Michael Johnson @ 2009-03-30 2:39 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090329121700.GN22446@genesis.frugalware.org>
On Sun, 29 Mar 2009 07:17:00 -0500, Miklos Vajna <vmiklos@frugalware.org>
wrote:
> On Sat, Mar 28, 2009 at 11:19:31AM -0500, Michael Johnson
> <redbeard@mdjohnson.us> wrote:
>> The 1.6.2.1 version just segfaults, but 1.5.6.5 says:
>>
>> /usr/bin/git-merge: line 438: 32335 Segmentation fault
>> git-merge-$strategy $common -- "$head_arg" "$@"
>> Merge with strategy recursive failed.
>>
>> In all cases, .git/index.lock is left behind.
>
> That's because 1.6.2.1 has git-merge in C and it calls merge-recursive
> directly without a fork. Could you try it in gdb and provide a
> backtrace, please?
Well, I've got a backtrace, but I don't have debugging symbols,
apparently. There is not a Debian package I can find that has them. I
checked debug.debian.net, as well as the standard sid repository. So I
will have to rebuild the package with debugging turned on. I will not be
able to do that tonight, unfortunately. I will probably have a chance
tomorrow evening.
Just in case it might be useful, though, here's the backtrace, without
symbols.
Starting program: /usr/bin/git merge origin/dojo-1.3
(no debugging symbols found)
... repeated multiple times ...
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
... repeated multiple times
[New Thread 0xb7a73b30 (LWP 21505)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7a73b30 (LWP 21505)]
0x080e5a6f in ?? ()
(gdb) backtrace
#0 0x080e5a6f in ?? ()
#1 0x0893e000 in ?? ()
#2 0x000f0000 in ?? ()
#3 0xbf949098 in ?? ()
#4 0x080e63ad in ?? ()
#5 0x08977fcf in ?? ()
#6 0x000f0000 in ?? ()
#7 0xfff0ffff in ?? ()
#8 0x08945dd8 in ?? ()
#9 0x00000000 in ?? ()
Thanks for the continuing help.
Michael
--
Michael D Johnson <redbeard@mdjohnson.us>
redbeardcreator.deviantart.com
"Marketing research...[has] shown that energy weapons that make sounds sell
better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)
^ permalink raw reply
* Re: [PATCH 1/4] test-suite: adding a test for fast-export with tag variants
From: Junio C Hamano @ 2009-03-30 2:50 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Erik Faye-Lund, git
In-Reply-To: <40aa078e0903291444m3a29662j3162ed511eee0ac8@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
>> But running the tests with the first patch applied to the same base as
>> where v1 was applied gives this, which is a more serious issue:
>>
>> $ sh t9301-fast-export.sh 2>&1 | tail -n 2
>> * still have 4 known breakage(s)
>> * failed 6 among remaining 15 test(s)
>>
>> In other words, the changes to the set-up part seem to break unrelated
>> tests. Why can such an update supersede the previous one?
>
> That's weird. I did test it properly before I applied it, and I don't
> recall having any failures on Linux.
I think it is just the matter of doing something like this instead of your
patch [PATCH v2 1/4]. Either that, or I think you need to adjust the
existing tests that try to export --all and get hit by the fast that you
added the tags you already knew the old code had trouble with in the test
setup for them.
-- >8 --
From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Mon, 23 Mar 2009 12:53:06 +0000
Subject: [PATCH] test-suite: adding a test for fast-export with tag variants
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t9301-fast-export.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index 86c3760..2e31f67 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -259,4 +259,20 @@ test_expect_success 'cope with tagger-less tags' '
'
+test_expect_success 'set-up a few more tags for tag export tests' '
+ git checkout -f master &&
+ HEAD_TREE=`git show -s --pretty=raw HEAD | grep tree | sed "s/tree //"` &&
+ git tag tree_tag -m "tagging a tree" $HEAD_TREE &&
+ git tag -a tree_tag-obj -m "tagging a tree" $HEAD_TREE &&
+ git tag tag-obj_tag -m "tagging a tag" tree_tag-obj &&
+ git tag -a tag-obj_tag-obj -m "tagging a tag" tree_tag-obj
+'
+
+# NEEDSWORK: not just check return status, but validate the output
+# two tests commented out due to crash and thus unreliable return code
+test_expect_failure 'tree_tag' 'git fast-export tree_tag'
+test_expect_failure 'tree_tag-obj' 'git fast-export tree_tag-obj'
+test_expect_failure 'tag-obj_tag' 'git fast-export tag-obj_tag'
+test_expect_failure 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
+
test_done
--
1.6.2.1
^ permalink raw reply related
* newb questions: post-cherry-pick status cleanup, shared local repository permissions
From: Aaron Davies @ 2009-03-30 3:03 UTC (permalink / raw)
To: git
hi, i'm new to git, and have a couple questions which are probably
very stupid and/or indicate that i've been doing it wrong.
first, a couple words about my setup/workflow: i'm currently sole
developer on a project which may at some point get some other coders.
the environment is three linux boxes, one for development and two for
production, and three accounts, mine, dev, and prod. all homedirs are
hosted on the network and are accessible from all three boxen.
i have a "central" (i.e. bare) repository stored in dev's homedir, and
regular copies in all three homedirs. the language involved is
interpreted, so the code tree is the deployment.
my main workflow is to hack on a branch in my homedir, then merge and
push when i have a feature ready. then i go to the dev account and
pull, which constitutes dev deployment. once it's thoroughly tested, i
do the same in the prod account.
now, the questions: an exception to this workflow occurred a couple
months ago, when i made some urgent bugfixes that needed to move to
prod before other stuff that was currently being tested in dev. this
was done via cherry-picking some specific commits into prod. now, in
prod, when i do "git status", it says "# Your branch is ahead of
'origin/master' by 8 commits." is there an easy way to get rid of
this? last time i tried it on my own, i attempted some sort of push
from prod back to dev, wiped out most of the changes since those
cherry-picks, and had to recover by restoring my repository from
backup.
second, the ownership structure i currently have for the "central"
repository feels wrong to me--the whole thing is owned by my personal
account, depsite being hosted in dev's account. since i'm the only one
who ever pushes into it, this is not currently a problem, but it's
caused permissions issues on the rare occasions i've tried to push
from other accounts (e.g. prod, above), and will presumably cause many
more if anyone else ever starts coding on this project.
advice?
--
Aaron Davies
aaron.davies@gmail.com
^ permalink raw reply
* [PATCH] refs: add "for_each_ref_in" function to refactor "for_each_*_ref" functions
From: Christian Couder @ 2009-03-30 3:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
The "for_each_{tag,branch,remote,replace,}_ref" functions are
redefined in terms of "for_each_ref_in" so that we can lose the
hardcoded length of prefix strings from the code.
And the "for_each_bisect_ref" as it is only used in "bisect.c" and
a call like 'for_each_ref_in("refs/bisect/", register_ref, NULL)'
is clear enough.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
bisect.c | 2 +-
refs.c | 18 +++++++++---------
refs.h | 2 +-
3 files changed, 11 insertions(+), 11 deletions(-)
Junio wrote:
> > +static int read_bisect_refs(void)
> > +{
> > + return for_each_bisect_ref(register_ref, NULL);
> > +}
>
> This is only a minor point, but I do not foresee anybody other than
> bisect--helper (and later bisect) running for_each_bisect_ref(). It might
> make sense to redo [01/10] to introduce
>
> for_each_ref_in(const char *prefix, each_ref_fn fn, void *cb)
>
> and change this call site to:
>
> return for_each_ref_in("refs/bisect/", register_ref, NULL);
>
> Needless to say, for_each_{ref,tag_ref,branch_ref,remote_ref}() can be
> redefined in terms of for_each_ref_in() so that we can lose these
> hardcoded length of prefix strings from the code.
Here is a patch to do that, though "for_each_ref" is not redefined in terms
of "for_each_ref_in", as it passes 0 as the length of the prefix string.
diff --git a/bisect.c b/bisect.c
index b4089ca..2e3d063 100644
--- a/bisect.c
+++ b/bisect.c
@@ -422,7 +422,7 @@ static int register_ref(const char *refname, const unsigned char *sha1,
static int read_bisect_refs(void)
{
- return for_each_bisect_ref(register_ref, NULL);
+ return for_each_ref_in("refs/bisect/", register_ref, NULL);
}
void read_bisect_paths(void)
diff --git a/refs.c b/refs.c
index e512d4c..c52a758 100644
--- a/refs.c
+++ b/refs.c
@@ -647,29 +647,29 @@ int for_each_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/", fn, 0, 0, cb_data);
}
-int for_each_tag_ref(each_ref_fn fn, void *cb_data)
+int for_each_ref_in(const char *prefix, each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/tags/", fn, 10, 0, cb_data);
+ return do_for_each_ref(prefix, fn, strlen(prefix), 0, cb_data);
}
-int for_each_branch_ref(each_ref_fn fn, void *cb_data)
+int for_each_tag_ref(each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/heads/", fn, 11, 0, cb_data);
+ return for_each_ref_in("refs/tags/", fn, cb_data);
}
-int for_each_remote_ref(each_ref_fn fn, void *cb_data)
+int for_each_branch_ref(each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/remotes/", fn, 13, 0, cb_data);
+ return for_each_ref_in("refs/heads/", fn, cb_data);
}
-int for_each_bisect_ref(each_ref_fn fn, void *cb_data)
+int for_each_remote_ref(each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/bisect/", fn, 12, 0, cb_data);
+ return for_each_ref_in("refs/remotes/", fn, cb_data);
}
int for_each_replace_ref(each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/replace/", fn, 13, 0, cb_data);
+ return for_each_ref_in("refs/replace/", fn, cb_data);
}
int for_each_rawref(each_ref_fn fn, void *cb_data)
diff --git a/refs.h b/refs.h
index c76d96b..18649a7 100644
--- a/refs.h
+++ b/refs.h
@@ -20,10 +20,10 @@ struct ref_lock {
typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags, void *cb_data);
extern int head_ref(each_ref_fn, void *);
extern int for_each_ref(each_ref_fn, void *);
+extern int for_each_ref_in(const char *, each_ref_fn, void *);
extern int for_each_tag_ref(each_ref_fn, void *);
extern int for_each_branch_ref(each_ref_fn, void *);
extern int for_each_remote_ref(each_ref_fn, void *);
-extern int for_each_bisect_ref(each_ref_fn, void *);
extern int for_each_replace_ref(each_ref_fn, void *);
/* can be used to learn about broken ref and symref */
--
1.6.2.1.531.gbd5067.dirty
^ permalink raw reply related
* Re: [PATCH 07/10] rev-list: call new "filter_skip" function
From: Christian Couder @ 2009-03-30 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
In-Reply-To: <7v8wmssrrs.fsf@gitster.siamese.dyndns.org>
Le jeudi 26 mars 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > This patch implements a new "filter_skip" function in C in
> > "bisect.c" that will later replace the existing implementation in
> > shell in "git-bisect.sh".
> >
> > An array is used to store the skipped commits. But the array is
> > not yet fed anything.
> >
> > Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> > ---
> > bisect.c | 65
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++ bisect.h
> > | 6 ++++-
> > builtin-rev-list.c | 30 ++++++++++++++++++++----
> > 3 files changed, 95 insertions(+), 6 deletions(-)
> >
> > diff --git a/bisect.c b/bisect.c
> > index 27def7d..39189f2 100644
> > --- a/bisect.c
> > +++ b/bisect.c
> > @@ -4,6 +4,11 @@
> > #include "revision.h"
> > #include "bisect.h"
> >
> > +
> > +static unsigned char (*skipped_sha1)[20];
> > +static int skipped_sha1_nr;
> > +static int skipped_sha1_alloc;
> > +
> > /* bits #0-15 in revision.h */
> >
> > #define COUNTED (1u<<16)
> > @@ -386,3 +391,63 @@ struct commit_list *find_bisection(struct
> > commit_list *list, return best;
> > }
> >
> > +static int skipcmp(const void *a, const void *b)
> > +{
> > + return hashcmp(a, b);
> > +}
>
> I've learned to suspect without reading a qsort() callback that does not
> derefence its arguments. Is this doing the right thing?
I think so.
Here is a gdb session that seems to show that it's ok:
---------------------------------------------------
...
$ git bisect skip
There are only 'skip'ped commit left to test.
The first bad commit could be any of:
3de952f2416b6084f557ec417709eac740c6818c
7b7f204a749c3125d5224ed61ea2ae1187ad046f
32a594a3fdac2d57cf6d02987e30eec68511498c
We cannot bisect more!
$
$ gdb git
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) b skipcmp
Breakpoint 1 at 0x46edfd: file bisect.c, line 457.
(gdb) run bisect--helper --next-vars
Starting program: /home/christian/git/bin/git bisect--helper --next-vars
[Thread debugging using libthread_db enabled]
[New Thread 47665987240336 (LWP 9703)]
[Switching to Thread 47665987240336 (LWP 9703)]
Breakpoint 1, skipcmp (a=0x77a800, b=0x77a814) at bisect.c:457
457 return hashcmp(a, b);
(gdb) p skipped_sha1
$1 = (unsigned char (*)[20]) 0x77a800
(gdb) p a - b
$2 = -20
(gdb) p sha1_to_hex(a)
$3 = 0x771256 "3de952f2416b6084f557ec417709eac740c6818c"
(gdb) p sha1_to_hex(b)
$4 = 0x7711c0 "7b7f204a749c3125d5224ed61ea2ae1187ad046f"
(gdb)
---------------------------------------------------
Do you think I should add a comment and/or perhaps cast a and b into "const
unsigned char *"?
Thanks,
Christian.
^ permalink raw reply
* Re: git svn init --username ignored
From: Eric Wong @ 2009-03-30 3:54 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git
In-Reply-To: <FB93BF8D-836A-4A40-8B82-E32561007A52@gmail.com>
Lachlan Deck <lachlan.deck@gmail.com> wrote:
> On 30/03/2009, at 9:41 AM, Eric Wong wrote:
>
>> Lachlan Deck <lachlan.deck@gmail.com> wrote:
>>> Hi there,
>>>
>>> Is it a bug that the when specifying --username=foo for either git-
>>> svn
>>> init or git-svn clone that this isn't stored in .git/config?
>>>
>>> It means that for http[s] urls you need to specify it each time for
>>> git-svn fetch, for example.
>>>
>>> Is there any way to specify it manually in the config file - or would
>>> that have some bad consequences?
>>
>> Subversion already stores credential information in ~/.subversion/
>> which
>> git svn should respect and use if available and allowed to. Did you
>> disable set "store-auth-creds = no" in your ~/.subversion/config ?
>
> No, it's still commented out.
>
> I simply started by doing:
> git svn clone https://somedomain/repo repo --username=lachlan -s
> cd repo
> git svn fetch // failed without --username
>
> In case the initial passing of --username is tripping it up, I'm trying
> again without specifying it.
Does "svn ls https://somedomain/repo" prompt you for a username? Does
repeating that command (after successfully running it once) still prompt
you? (it shouldn't prompt you again if you have auth caching on).
If "svn ls" is prompting you every time, then SVN auth caching is
somehow disabled/broken on you system. You can try poking around inside
your ~/.subversion/ directory and see if there's permissions problems
or such...
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/2] bisect--helper: string output variables together with "&&"
From: Christian Couder @ 2009-03-30 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
In-Reply-To: <20090329115547.91e2de5b.chriscool@tuxfamily.org>
Le dimanche 29 mars 2009, Christian Couder a écrit :
> -static void show_tried_revs(struct commit_list *tried)
> +static void show_tried_revs(struct commit_list *tried, int stringed)
> {
> + char *last_format = stringed ? "%s &&" : "%s";
> +
> printf("bisect_tried='");
> for (;tried; tried = tried->next) {
> - char *format = tried->next ? "%s|" : "%s";
> + char *format = tried->next ? "%s|" : last_format;
> printf(format, sha1_to_hex(tried->item->object.sha1));
> }
> printf("'\n");
Ooops, sorry, this is wrong I will send an updaed series.
Best regards,
Christian.
^ permalink raw reply
* Re: newb questions: post-cherry-pick status cleanup, shared local repository permissions
From: Nicolas Sebrecht @ 2009-03-30 4:22 UTC (permalink / raw)
To: Aaron Davies; +Cc: git
In-Reply-To: <c4e763ac0903292003j22934e7ax9f9ae986bdcd6abb@mail.gmail.com>
On Mon, Mar 30, 2009 at 11:03:28AM +0800, Aaron Davies wrote:
>
> hi, i'm new to git, and have a couple questions which are probably
> very stupid and/or indicate that i've been doing it wrong.
>
> first, a couple words about my setup/workflow: i'm currently sole
> developer on a project which may at some point get some other coders.
> the environment is three linux boxes, one for development and two for
> production, and three accounts, mine, dev, and prod. all homedirs are
> hosted on the network and are accessible from all three boxen.
>
> i have a "central" (i.e. bare) repository stored in dev's homedir, and
> regular copies in all three homedirs. the language involved is
> interpreted, so the code tree is the deployment.
>
> my main workflow is to hack on a branch in my homedir, then merge and
> push when i have a feature ready. then i go to the dev account and
> pull, which constitutes dev deployment. once it's thoroughly tested, i
> do the same in the prod account.
Looks sane.
That said, you could also work on branches (all in "homedir") for the
'working on feature' -> testing (dev) -> ready (prod)
workflow.
> now, the questions: an exception to this workflow occurred a couple
> months ago, when i made some urgent bugfixes that needed to move to
> prod before other stuff that was currently being tested in dev. this
> was done via cherry-picking some specific commits into prod. now, in
> prod, when i do "git status", it says "# Your branch is ahead of
> 'origin/master' by 8 commits." is there an easy way to get rid of
> this?
What I would do is working on "TOPIC" branches. By this way, the bare,
dev and prod repositories would not "know" of all the commits from mine
but only the urgent fixes.
in "mine":
- step 1
$ git checkout -b bugfixes master
- step 2
$ git cherry-pick blabla
(and/or <hack, hack, hack>)
- step 3
$ git checkout master
$ git merge bugfixes
- step 4
$ git push origin master:master (to the bare repo)
- step 5
$ git branch -d bugfixes
$ git checkout myworking
$ git rebase myworking master
At step 1, we create the new bugfixes branch from master:
(bugfixes)
/
o-o-o (master)
\
a-b-c-d (myworking)
At step 2, we fix the bugs (cherry-picking and hack):
a-c-y-z (bugfixes)
/
o-o-o (master)
\
a-b-c-d (myworking)
At step 3, we merge the urgent fixes into master:
a-c-y-z (bugfixes)
/
o-o-o-a-c-y-z (master)
\
a-b-c-d (myworking)
At step 4, we push the urgent work as usual pushes.
At step 5, we come back to the usual work:
o-o-o-a-c-y-z (master)
\
b'-d' (myworking)
>From here, you update dev and prod as usual.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [EGIT] [PATCH RFC v1 0/5] Add (static) ignore functionality to EGit
From: Shawn O. Pearce @ 2009-03-30 4:27 UTC (permalink / raw)
To: Ferry Huberts (Pelagic); +Cc: Robin Rosenberg, git
In-Reply-To: <49CF50CC.10400@pelagic.nl>
"Ferry Huberts (Pelagic)" <ferry.huberts@pelagic.nl> wrote:
> Robin Rosenberg wrote:
> > A quick reply (I might come up with more later): Ignore support should be mostly
> > in jgit, with only extensions into egit.
> >
> I discussed this with shawn and proposed to first implement it in egit
> and when we have it right then move it into jgit. I think shawn agreed
> with that.
I may have agreed with it. My memory isn't *that* good. :-)
In general principal I agree with Robin, Git specific handling
should be in JGit as much as possible so we can reuse the logic in
more applications than just EGit.
But it may have been easier to get a first working prototype by doing
the code in EGit, and later pulling some of it down into JGit as we
identity what isn't EGit specific.
The problem with that is the dual licenses; code in EGit can't
be pulled down to JGit without relicensing it under the BSD.
Only the original author of the code can do that. So if you
contribute ignore support to EGit under the EPL which is better
placed in JGit, Robin or myself can't pull it down ourselves,
we'd have to rewrite it.
But even rewriting may be difficult, as the rewrite may be too close
to the original (same language, same surrounding code, likely going
to produce a similar result).
--
Shawn.
^ permalink raw reply
* Re: [EGIT] How to deal with important modifications
From: Shawn O. Pearce @ 2009-03-30 4:30 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Ferry Huberts (Pelagic), git
In-Reply-To: <200903291145.06135.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> l?rdag 28 mars 2009 23:44:49 skrev "Ferry Huberts (Pelagic)" <ferry.huberts@pelagic.nl>:
> >
> > I was asking myself the same questions about my work on ignores and
> > chose to send it out early, being half completed. Don't know if that was
> > right, did not receive feedback yet, but it's only been 2 days with
> > Eclipsecon wrapping up on friday.
>
> That's not the reason you haven't received a response. Basically, the larger
> a set of patches is, more time is needed.
Yup.
I plan to block off time to look at the patches tomorrow.
The bigger it is, the more likely it gets pushed off a few days,
until I can block off a seemingly large enough amount of time to
give it a complete reading.
--
Shawn.
^ permalink raw reply
* Re: newb questions: post-cherry-pick status cleanup, shared local repository permissions
From: Nicolas Sebrecht @ 2009-03-30 4:30 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Aaron Davies, git
In-Reply-To: <20090330042226.GA12907@vidovic>
On Mon, Mar 30, 2009 at 06:22:26AM +0200, Nicolas Sebrecht wrote:
>
>
> On Mon, Mar 30, 2009 at 11:03:28AM +0800, Aaron Davies wrote:
> >
> > hi, i'm new to git, and have a couple questions which are probably
> > very stupid and/or indicate that i've been doing it wrong.
> >
> > first, a couple words about my setup/workflow: i'm currently sole
> > developer on a project which may at some point get some other coders.
> > the environment is three linux boxes, one for development and two for
> > production, and three accounts, mine, dev, and prod. all homedirs are
> > hosted on the network and are accessible from all three boxen.
> >
> > i have a "central" (i.e. bare) repository stored in dev's homedir, and
> > regular copies in all three homedirs. the language involved is
> > interpreted, so the code tree is the deployment.
> >
> > my main workflow is to hack on a branch in my homedir, then merge and
> > push when i have a feature ready. then i go to the dev account and
> > pull, which constitutes dev deployment. once it's thoroughly tested, i
> > do the same in the prod account.
>
> Looks sane.
>
> That said, you could also work on branches (all in "homedir") for the
> 'working on feature' -> testing (dev) -> ready (prod)
> workflow.
>
> > now, the questions: an exception to this workflow occurred a couple
> > months ago, when i made some urgent bugfixes that needed to move to
> > prod before other stuff that was currently being tested in dev. this
> > was done via cherry-picking some specific commits into prod. now, in
> > prod, when i do "git status", it says "# Your branch is ahead of
> > 'origin/master' by 8 commits." is there an easy way to get rid of
> > this?
>
> What I would do is working on "TOPIC" branches. By this way, the bare,
> dev and prod repositories would not "know" of all the commits from mine
> but only the urgent fixes.
>
> in "mine":
> - step 1
> $ git checkout -b bugfixes master
>
> - step 2
> $ git cherry-pick blabla
> (and/or <hack, hack, hack>)
>
> - step 3
> $ git checkout master
> $ git merge bugfixes
>
> - step 4
> $ git push origin master:master (to the bare repo)
>
> - step 5
> $ git branch -d bugfixes
> $ git checkout myworking
> $ git rebase myworking master
My bad:
$ git rebase master
> At step 1, we create the new bugfixes branch from master:
> (bugfixes)
> /
> o-o-o (master)
> \
> a-b-c-d (myworking)
>
> At step 2, we fix the bugs (cherry-picking and hack):
> a-c-y-z (bugfixes)
> /
> o-o-o (master)
> \
> a-b-c-d (myworking)
>
> At step 3, we merge the urgent fixes into master:
> a-c-y-z (bugfixes)
> /
> o-o-o-a-c-y-z (master)
> \
> a-b-c-d (myworking)
>
> At step 4, we push the urgent work as usual pushes.
> At step 5, we come back to the usual work:
>
> o-o-o-a-c-y-z (master)
> \
> b'-d' (myworking)
Then, you update dev and prod as usual from bare.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] Add diffuse as merge and diff tool
From: David Aguilar @ 2009-03-30 4:55 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git
In-Reply-To: <49CEA3E2.9020805@hartwork.org>
Hi
On 0, Sebastian Pipping <webmaster@hartwork.org> wrote:
>
> From e54c153a67cef9b162eb51f4b7cefb65e59c3a13 Mon Sep 17 00:00:00 2001
> From: Sebastian Pipping <sebastian@pipping.org>
> Date: Thu, 26 Mar 2009 20:42:31 +0100
> Subject: [PATCH] Add diffuse as merge and diff tool
>
> ---
> Documentation/git-mergetool.txt | 3 ++-
> Documentation/merge-config.txt | 7 ++++---
> contrib/completion/git-completion.bash | 3 ++-
> contrib/difftool/git-difftool-helper | 12 ++++++++----
> contrib/difftool/git-difftool.txt | 4 ++--
> git-gui/lib/mergetool.tcl | 7 +++++++
> git-mergetool.sh | 15 ++++++++++++---
> 7 files changed, 37 insertions(+), 14 deletions(-)
Hey, thanks for the patch.
Ouch.. too many places with duplicated information, huh?
I'm in the middle of refactoring git-(diff|merge)tool so that
there is less duplication of code.
Junio also has a number of difftool-related patches in his
proposed-updates "pu" branch.
Sebastian, would you mind if I rebased your patch on top of my
work (once I send it out) so that it makes things easier on
our kind maintainer? I have a big patch series coming down that
does away with the redundancies so I think it'd be best if we
transfered your changes on top of it. Would you mind if I
rebased your patch and sent it out to the list?
It wouldn't be until much later tonight (or tomorrow) at the
earliest since I have some unpacking to take care of but if
that's cool with you just let me know.
You should see the refactoring patches from me shortly...
--
David
^ permalink raw reply
* [PATCH v2] difftool: add support for a difftool.prompt config variable
From: David Aguilar @ 2009-03-30 4:55 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
difftool now supports difftool.prompt so that users do not have to
pass --no-prompt or hit enter each time a diff tool is launched.
The --prompt flag overrides the configuration variable.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
I sent an original version of this patch but the final test
wasn't actually testing anything since I forgot to add the
final "&&" to string the commands together.
I didn't see that patch in any of Junio's branches so I
went ahead and sent a v2.
Documentation/config.txt | 3 ++
Documentation/git-difftool.txt | 10 +++++-
git-difftool-helper.sh | 10 +++++-
git-difftool.perl | 15 +++++++--
t/t7800-difftool.sh | 64 ++++++++++++++++++++++++++++++++++++++++
5 files changed, 96 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 089569a..81f9e9a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -680,6 +680,9 @@ difftool.<tool>.cmd::
is set to the name of the temporary file containing the contents
of the diff post-image.
+difftool.prompt::
+ Prompt before each invocation of the diff tool.
+
diff.wordRegex::
A POSIX Extended Regular Expression used to determine what is a "word"
when performing word-by-word difference calculations. Character
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index a00e943..73d4782 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -7,7 +7,7 @@ git-difftool - Show changes using common diff tools
SYNOPSIS
--------
-'git difftool' [--tool=<tool>] [-y|--no-prompt] [<'git diff' options>]
+'git difftool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<'git diff' options>]
DESCRIPTION
-----------
@@ -21,6 +21,11 @@ OPTIONS
--no-prompt::
Do not prompt before launching a diff tool.
+--prompt::
+ Prompt before each invocation of the diff tool.
+ This is the default behaviour; the option is provided to
+ override any configuration settings.
+
-t <tool>::
--tool=<tool>::
Use the diff tool specified by <tool>.
@@ -72,6 +77,9 @@ difftool.<tool>.cmd::
+
See the `--tool=<tool>` option above for more details.
+difftool.prompt::
+ Prompt before each invocation of the diff tool.
+
SEE ALSO
--------
linkgit:git-diff[1]::
diff --git a/git-difftool-helper.sh b/git-difftool-helper.sh
index b91002b..02bb135 100755
--- a/git-difftool-helper.sh
+++ b/git-difftool-helper.sh
@@ -7,9 +7,15 @@
#
# Copyright (c) 2009 David Aguilar
-# Set GIT_DIFFTOOL_NO_PROMPT to bypass the per-file prompt.
+# difftool.prompt controls the default prompt/no-prompt behavior
+# and is overridden with $GIT_DIFFTOOL*_PROMPT.
should_prompt () {
- test -z "$GIT_DIFFTOOL_NO_PROMPT"
+ prompt=$(git config --bool difftool.prompt || echo true)
+ if test "$prompt" = true; then
+ test -z "$GIT_DIFFTOOL_NO_PROMPT"
+ else
+ test -n "$GIT_DIFFTOOL_PROMPT"
+ fi
}
# This function prepares temporary files and launches the appropriate
diff --git a/git-difftool.perl b/git-difftool.perl
index 8c160e5..985dfe0 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -2,9 +2,12 @@
# Copyright (c) 2009 David Aguilar
#
# This is a wrapper around the GIT_EXTERNAL_DIFF-compatible
-# git-difftool-helper script. This script exports
-# GIT_EXTERNAL_DIFF and GIT_PAGER for use by git, and
-# GIT_DIFFTOOL_NO_PROMPT and GIT_DIFF_TOOL for use by git-difftool-helper.
+# git-difftool-helper script.
+#
+# This script exports GIT_EXTERNAL_DIFF and GIT_PAGER for use by git.
+# GIT_DIFFTOOL_NO_PROMPT, GIT_DIFFTOOL_PROMPT, and GIT_DIFF_TOOL
+# are exported for use by git-difftool-helper.
+#
# Any arguments that are unknown to this script are forwarded to 'git diff'.
use strict;
@@ -62,6 +65,12 @@ sub generate_command
}
if ($arg eq '-y' || $arg eq '--no-prompt') {
$ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
+ delete $ENV{GIT_DIFFTOOL_PROMPT};
+ next;
+ }
+ if ($arg eq '--prompt') {
+ $ENV{GIT_DIFFTOOL_PROMPT} = 'true';
+ delete $ENV{GIT_DIFFTOOL_NO_PROMPT};
next;
}
if ($arg eq '-h' || $arg eq '--help') {
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index ceef84b..33d07e6 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -15,6 +15,7 @@ remove_config_vars()
# Unset all config variables used by git-difftool
git config --unset diff.tool
git config --unset difftool.test-tool.cmd
+ git config --unset difftool.prompt
git config --unset merge.tool
git config --unset mergetool.test-tool.cmd
return 0
@@ -26,11 +27,18 @@ restore_test_defaults()
remove_config_vars
unset GIT_DIFF_TOOL
unset GIT_MERGE_TOOL
+ unset GIT_DIFFTOOL_PROMPT
unset GIT_DIFFTOOL_NO_PROMPT
git config diff.tool test-tool &&
git config difftool.test-tool.cmd 'cat $LOCAL'
}
+prompt_given()
+{
+ prompt="$1"
+ test "$prompt" = "Hit return to launch 'test-tool': branch"
+}
+
# Create a file on master and change it on branch
test_expect_success 'setup' '
echo master >file &&
@@ -116,6 +124,62 @@ test_expect_success 'GIT_DIFFTOOL_NO_PROMPT variable' '
restore_test_defaults
'
+# git-difftool supports the difftool.prompt variable.
+# Test that GIT_DIFFTOOL_PROMPT can override difftool.prompt = false
+test_expect_success 'GIT_DIFFTOOL_PROMPT variable' '
+ git config difftool.prompt false &&
+ GIT_DIFFTOOL_PROMPT=true &&
+ export GIT_DIFFTOOL_PROMPT &&
+
+ prompt=$(echo | git difftool --prompt branch | tail -1) &&
+ prompt_given "$prompt" &&
+
+ restore_test_defaults
+'
+
+# Test that we don't have to pass --no-prompt when difftool.prompt is false
+test_expect_success 'difftool.prompt config variable is false' '
+ git config difftool.prompt false &&
+
+ diff=$(git difftool branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
+# Test that the -y flag can override difftool.prompt = true
+test_expect_success 'difftool.prompt can overridden with -y' '
+ git config difftool.prompt true &&
+
+ diff=$(git difftool -y branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
+# Test that the --prompt flag can override difftool.prompt = false
+test_expect_success 'difftool.prompt can overridden with --prompt' '
+ git config difftool.prompt false &&
+
+ prompt=$(echo | git difftool --prompt branch | tail -1) &&
+ prompt_given "$prompt" &&
+
+ restore_test_defaults
+'
+
+# Test that the last flag passed on the command-line wins
+test_expect_success 'difftool last flag wins' '
+ diff=$(git difftool --prompt --no-prompt branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults &&
+
+ prompt=$(echo | git difftool --no-prompt --prompt branch | tail -1) &&
+ prompt_given "$prompt" &&
+
+ restore_test_defaults
+'
+
# git-difftool falls back to git-mergetool config variables
# so test that behavior here
test_expect_success 'difftool + mergetool config variables' '
--
1.6.2.1.404.gb0085
^ permalink raw reply related
* [PATCH v2 0/2] bisect--helper: string output variables together with "&&"
From: Christian Couder @ 2009-03-30 4:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
The goal of this 2 patches is to get rid of the need to pipe the
output of "eval 'git bisect--helper --next-vars'" into a "while read"
loop.
The only change since the previous version is that a brown paper bag bug
in "show_tried_revs" is fixed in the second patch.
rev-list: pass a flag as last argument of "show_bisect_vars"
bisect--helper: string output variables together with "&&"
bisect.c | 3 ++-
bisect.h | 9 +++++++--
builtin-rev-list.c | 42 +++++++++++++++++++++++++-----------------
git-bisect.sh | 15 +--------------
4 files changed, 35 insertions(+), 34 deletions(-)
^ permalink raw reply
* [PATCH v2 1/2] rev-list: pass a flag as last argument of "show_bisect_vars"
From: Christian Couder @ 2009-03-30 4:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
Instead of "int show_all, int show_tried" we now only pass "int flags",
because we will add more flags in a later patch.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
bisect.c | 2 +-
bisect.h | 8 ++++++--
builtin-rev-list.c | 13 ++++++-------
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/bisect.c b/bisect.c
index 66df05f..64a5ad5 100644
--- a/bisect.c
+++ b/bisect.c
@@ -554,5 +554,5 @@ int bisect_next_vars(const char *prefix)
revs.commits = find_bisection(revs.commits, &reaches, &all,
!!skipped_sha1_nr);
- return show_bisect_vars(&revs, reaches, all, 0, 1);
+ return show_bisect_vars(&revs, reaches, all, SHOW_TRIED);
}
diff --git a/bisect.h b/bisect.h
index 05eea17..4cff2ba 100644
--- a/bisect.h
+++ b/bisect.h
@@ -9,13 +9,17 @@ extern struct commit_list *filter_skipped(struct commit_list *list,
struct commit_list **tried,
int show_all);
+/* show_bisect_vars flags */
+#define SHOW_ALL 1
+#define SHOW_TRIED 2
+
/*
- * The "show_all" parameter should be 0 if this function is called
+ * The flag SHOW_ALL should not be set if this function is called
* from outside "builtin-rev-list.c" as otherwise it would use
* static "revs" from this file.
*/
extern int show_bisect_vars(struct rev_info *revs, int reaches, int all,
- int show_all, int show_tried);
+ int flags);
extern int bisect_next_vars(const char *prefix);
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 925d643..c1c4a18 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -236,17 +236,16 @@ static void show_tried_revs(struct commit_list *tried)
printf("'\n");
}
-int show_bisect_vars(struct rev_info *revs, int reaches, int all,
- int show_all, int show_tried)
+int show_bisect_vars(struct rev_info *revs, int reaches, int all, int flags)
{
int cnt;
char hex[41] = "";
struct commit_list *tried;
- if (!revs->commits && !show_tried)
+ if (!revs->commits && !(flags & SHOW_TRIED))
return 1;
- revs->commits = filter_skipped(revs->commits, &tried, show_all);
+ revs->commits = filter_skipped(revs->commits, &tried, flags & SHOW_ALL);
/*
* revs->commits can reach "reaches" commits among
@@ -264,12 +263,12 @@ int show_bisect_vars(struct rev_info *revs, int reaches, int all,
if (revs->commits)
strcpy(hex, sha1_to_hex(revs->commits->item->object.sha1));
- if (show_all) {
+ if (flags & SHOW_ALL) {
traverse_commit_list(revs, show_commit, show_object);
printf("------\n");
}
- if (show_tried)
+ if (flags & SHOW_TRIED)
show_tried_revs(tried);
printf("bisect_rev=%s\n"
"bisect_nr=%d\n"
@@ -379,7 +378,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (bisect_show_vars)
return show_bisect_vars(&revs, reaches, all,
- bisect_show_all, 0);
+ bisect_show_all ? SHOW_ALL : 0);
}
traverse_commit_list(&revs,
--
1.6.2.1.404.gb0085.dirty
^ permalink raw reply related
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