* lineups with GIT
From: outre @ 2009-01-22 7:54 UTC (permalink / raw)
To: git
I am trying to set up two different line-ups for a project (development and
testing).
The development line-up is the master, and test line-up pulls data from it.
The code is the same in both.
But since the line-ups are served from two different domains one folder in
the development line-up is called
iWeb.local, and in the test line-up it is called iWeb.test. That is the only
difference between the two.
I tried using "git mv" command and it somewhat solved the problem. After I
cloned the devel line-up, I used "git rm iWeb.local iWeb.test".
And now if I edit a file in iWeb.local and do a pull to iWeb.test this file
gets properly updated while preserving the difference between
the folder names. But if I add a new file to iWeb.local, and then do a pull
I get iWeb.local folder added together with the
new file to the testing line-up.
I was wondering if it is intended behaviour for GIT. And if it is may be
someone can point me to a better way to setup two line-ups using
GIT.
Thanks
--
View this message in context: http://n2.nabble.com/lineups-with-GIT-tp2196604p2196604.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: CR codes from git commands
From: Junio C Hamano @ 2009-01-22 8:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Brent Goodrick, git
In-Reply-To: <alpine.LNX.1.00.0901220238380.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> The terminal type, at least in my version of Emacs, is "dumb", which ought
> to be sufficient to tell git that a pager isn't going to be useful is most
> cases (might be worthwhile to keep "git log" from eating all your memory,
> though), and that using CR to rewrite lines isn't going to work.
I think we pay attention to "dumb" when deciding if pager is useful and if
we can do color, but I do not think we check anything beyond "is it a tty"
when deciding to show progress or not. The only thing we do differently
for "dumb" terminal is if we use ANSI clear-to-eol escape sequence or fill
with a run of SPs to overwrite trailing part of a line, and we assume even
dumb terminals know how to do a carriage-return.
^ permalink raw reply
* Re: Short "git commit $file" syntax fails in the face of a resolved conflict
From: Michael J Gruber @ 2009-01-22 9:17 UTC (permalink / raw)
To: Nathan Yergler; +Cc: Asheesh Laroia, git, Johannes Sixt
In-Reply-To: <c1a864630901211346j4b702fb3tcc5a098ed7e1541d@mail.gmail.com>
Nathan Yergler venit, vidit, dixit 21.01.2009 22:46:
> Can you elaborate on why doing -i automatically is a bad idea in this
> case? [It may really be, I don't pretend to have enough knowledge
> about git's internals to make a reasoned argument.] This was
> unexpected behavior for me as I'd always experienced "git add path &&
> git commit" and "git commit path" as being equivalent and so I assumed
> they would work equivalently in this situation.
Because it makes it hard to follow the discussion.
Why shouldn't I?
Fist of all: Please don't top post.
;)
That being said: As Johannes 6t explained (in agreement with git help
commit), "git commit path" - which is synonymous with "git commit -o
path" is a way of bypassing the index. Think of "Oh wait, I wanted to
commit that before I commit what I'm preparing right now.". Now,
bypassing the index is no big deal, but bypassing a merge in progress
is, because a merge in progress leaves more traces than just the index
state (e.g. MERGE_HEAD). That's also why this use case is mentioned
explicitly in the man page... In fact, rereading that man page (and
testing things to be on the safe side) I have to correct myself: Out of
1) git add path && git commit
2) git commit path
3) git commit -i path
none are equivalent! 1) and 3) are equivalent if and only if "path" is
known to git already: git commit -i does not add new paths.
2) and 3) are equivalent if and only if the index is empty (no changes
staged). The question "When are 1) and 2)" equivalent is left as an
exercise in elementary logic. ;)
Cheers,
Michael
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: Anders Waldenborg @ 2009-01-22 9:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Alexander Potashev, Marc Weber, Rogan Dawes, martin f krafft
In-Reply-To: <alpine.DEB.1.00.0901212247510.3586@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
>> So, the thing I initially wanted to solve was "multiple instances" of
>> the same hook.
>
> And why not use a shell function for that?
>
> -- snip --
> buildbot () {
> echo "Who is so evil and puts a bot into a post-receive hook?" >&2
> echo "This function would connect to $* if it were building a bot."
> }
>
> buildbot www.google.com
> buildbot www.kernel.org
> -- snap --
That is basically what I started with except that it looked like this:
-- 8< --
#!/bin/sh
/opt/git-triggers/buildbot-sendchange.py 192.168.9.99:9989
/opt/git-triggers/buildbot-sendchange.py 192.168.9.99:9988
/opt/git-triggers/send-mail
/opt/git-triggers/irc-notification
-- 8< --
At that point it thought "hey this looks like a configuration file,
shouldn't a repository's config live in $GIT_DIR/config?".
We will continue use this config based approach on our site[*] until git
has something better. For us it wins over shellscript-as-configuration
for two reasons: 1) git config is easier to script 2) it allows us to
define site wide triggers in /etc/gitconfig
[*] (our site is medium sized I guess, ~100 repos when all are converted
to git)
anders
^ permalink raw reply
* Re: how to git a read only directory
From: bill lam @ 2009-01-22 10:00 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: git
In-Reply-To: <4977515B.9030807@panasas.com>
On Wed, 21 Jan 2009, Boaz Harrosh wrote:
> [~] $ mkdir gitrepo; cd gitrepo
> [gitrepo] $ git-init
> [gitrepo] $ ln -s /etc
> [gitrepo] $ git-add /etc/fstab
(I use git ver. 1.6.1, git-xxx is already deprecated)
I followed your example, and failed in the git add,
gitrepo$ git add /etc/fstab
fatal: '/etc/fstab' is outside repository
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩260 李益 江南曲
嫁得瞿塘賈 朝朝誤妾期 早知潮有信 嫁與弄潮兒
^ permalink raw reply
* Short rant about git usability - make 'git clone' work on an empty remote repository
From: Richard W.M. Jones @ 2009-01-22 10:02 UTC (permalink / raw)
To: git
This is a rant, those offended by rants should stop reading now.
When I want to check out a remote repository, I do:
git clone URL...
Except when the repository is empty, when for no explicable reason
this familiar command doesn't work.
$ git clone git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
Initialized empty Git repository in /home/rjones/d/ocaml-autoconf/.git/
fatal: no matching remote head
$ git init ocaml-autoconf
usage: git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]]
$ mkdir ocaml-autoconf
$ cd ocaml-autoconf
$ git init
Initialized empty Git repository in /home/rjones/d/ocaml-autoconf/.git/
$ ls
$ ls -a
. .. .git
Following advice on a website ...
$ git-remote origin git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
error: Unknown subcommand: origin
usage: git remote
or: git remote add <name> <url>
or: git remote rm <name>
or: git remote show <name>
or: git remote prune <name>
or: git remote update [group]
-v, --verbose be verbose
$ git remote add origin git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)
$ git branch
$ git checkout
fatal: You are on a branch yet to be born
$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)
$ echo test > README
$ git commit -a
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# README
nothing added to commit but untracked files present (use "git add" to track)
$ git add README
$ git commit -a
Created initial commit 2c9a63a: Create repository.
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README
$ git push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git'
$ git push master
fatal: 'master': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
$ git branch master
fatal: A branch named 'master' already exists.
$ git status
# On branch master
nothing to commit (working directory clean)
$ git push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git'
$ man git-push
$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
Arrggghhhh, just MAKE GIT CLONE WORK!!!
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
^ permalink raw reply
* Re: CR codes from git commands
From: Mike Ralphson @ 2009-01-22 10:04 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <7vbptzahra.fsf@gitster.siamese.dyndns.org>
>2009/1/22 Brent Goodrick <bgoodr@gmail.com>:
> The environment I'm running git under is the Shell mode inside GNU
> Emacs. I can't tell you what type of terminal it is, because I believe
> that is defined deep in the guts of Emacs. Having read your reply
> above, I'm now wondering whether this is an Emacs issue versus a git
> issue. If it is an Emacs issue, then I am truly embarrassed for having
> wasted everyones time with it.
2009/1/22 Junio C Hamano <gitster@pobox.com>:
> I think we pay attention to "dumb" when deciding if pager is useful and if
> we can do color, but I do not think we check anything beyond "is it a tty"
> when deciding to show progress or not. The only thing we do differently
> for "dumb" terminal is if we use ANSI clear-to-eol escape sequence or fill
> with a run of SPs to overwrite trailing part of a line, and we assume even
> dumb terminals know how to do a carriage-return.
I think this earlier discussion is probably relevant... I'm guessing
though, $EDITOR is set correctly here 8-)
2008/12/17 Junio C Hamano <gitster@pobox.com>:
> Any semi-good emacs users (let alone hackers) export PAGER=cat to be used
> in compilation mode (and possibly shell mode), so this is not a problem in
> practice.
>
> I have something like this in my .emacs:
>
> (setenv "PAGER" "cat")
>
> I suspect (I am just a user not a hacker) this will have bad interaction
> with emacs terminal emulation mode, but I do not use the mode, so it is
> enough for me.
Mike
^ permalink raw reply
* Re: how to git a read only directory
From: Boaz Harrosh @ 2009-01-22 10:19 UTC (permalink / raw)
To: Boaz Harrosh, git
In-Reply-To: <20090122100008.GC6936@b2j>
bill lam wrote:
> On Wed, 21 Jan 2009, Boaz Harrosh wrote:
>> [~] $ mkdir gitrepo; cd gitrepo
>> [gitrepo] $ git-init
>> [gitrepo] $ ln -s /etc
>> [gitrepo] $ git-add /etc/fstab
>
Sorry My mistake, it should be:
[gitrepo] $ git-add etc/fstab
> (I use git ver. 1.6.1, git-xxx is already deprecated)
> I followed your example, and failed in the git add,
>
> gitrepo$ git add /etc/fstab
> fatal: '/etc/fstab' is outside repository
>
Sorry it's a typo, sure you must add files relative to
the base directory (one containing the .git/ dir)
Cheers
Boaz
^ permalink raw reply
* Re: how to git a read only directory
From: bill lam @ 2009-01-22 10:29 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: git
In-Reply-To: <4978483D.6040105@panasas.com>
On Thu, 22 Jan 2009, Boaz Harrosh wrote:
> Sorry My mistake, it should be:
> [gitrepo] $ git-add etc/fstab
>
> Sorry it's a typo, sure you must add files relative to
> the base directory (one containing the .git/ dir)
Hi Boaz,
I still could not add the file. This time it said symbolic link error.
gitrepo$ ll -A
total 4
lrwxrwxrwx 1 bill bill 4 2009-01-22 17:54 etc -> /etc
drwxr-xr-x 7 bill bill 4096 2009-01-22 18:23 .git
gitrepo$ pwd
/home/bill/gitrepo
gitrepo$ git add etc/fstab
fatal: 'etc/fstab' is beyond a symbolic link
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩314 王昌齡 長信怨
奉帚平明金殿開 且將團扇共徘徊 玉顏不及寒鴉色 猶帶昭陽日影來
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Jonathan del Strother @ 2009-01-22 10:57 UTC (permalink / raw)
To: Junio C Hamano, Robin Rosenberg; +Cc: Git Mailing List
In-Reply-To: <7vy6x4cqq1.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 21, 2009 at 7:49 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:
> [...]
> I think you've illustrated a case for graphical merge resolution tools, i.e.
> run git mergetool to help resolve the conlicts. It will run a graphical tool
> for you.
>
Mmm. I use opendiff, which is generally ok, but in this case produced
a merge looking like this :
http://pastie.org/paste/asset/367587/Picture_6.png
Which, in my mind, isn't any clearer about the fact that both lines
ought to be deleted than the text conflict markers are. Do any of the
other graphical tools present conflicts like that differently?
On Wed, Jan 21, 2009 at 9:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> But that is only true if it is obvious to you. When you cannot remember
> what each side did since they forked, there are two ways you can use to
> understand the history better without resorting to graphical merge tools.
>
> $ git log -p --merge <path>
>
Ahh, that's very helpful - thanks.
^ permalink raw reply
* Re: Short rant about git usability - make 'git clone' work on an empty remote repository
From: Mikael Magnusson @ 2009-01-22 11:01 UTC (permalink / raw)
To: Richard W.M. Jones; +Cc: git
In-Reply-To: <20090122100230.GA9653@amd.home.annexia.org>
2009/1/22 Richard W.M. Jones <rjones@redhat.com>:
> This is a rant, those offended by rants should stop reading now.
>
> When I want to check out a remote repository, I do:
>
> git clone URL...
>
> Except when the repository is empty, when for no explicable reason
> this familiar command doesn't work.
>
> $ git clone git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
> Initialized empty Git repository in /home/rjones/d/ocaml-autoconf/.git/
> fatal: no matching remote head
>
> $ git init ocaml-autoconf
> usage: git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]]
> $ mkdir ocaml-autoconf
> $ cd ocaml-autoconf
> $ git init
> Initialized empty Git repository in /home/rjones/d/ocaml-autoconf/.git/
> $ ls
> $ ls -a
> . .. .git
>
> Following advice on a website ...
>
> $ git-remote origin git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
> error: Unknown subcommand: origin
> usage: git remote
> or: git remote add <name> <url>
> or: git remote rm <name>
> or: git remote show <name>
> or: git remote prune <name>
> or: git remote update [group]
>
> -v, --verbose be verbose
>
> $ git remote add origin git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
>
> $ git status
> # On branch master
> #
> # Initial commit
> #
> nothing to commit (create/copy files and use "git add" to track)
> $ git branch
> $ git checkout
> fatal: You are on a branch yet to be born
> $ git status
> # On branch master
> #
> # Initial commit
> #
> nothing to commit (create/copy files and use "git add" to track)
> $ echo test > README
> $ git commit -a
> # On branch master
> #
> # Initial commit
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # README
> nothing added to commit but untracked files present (use "git add" to track)
> $ git add README
> $ git commit -a
> Created initial commit 2c9a63a: Create repository.
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 README
>
> $ git push
> No refs in common and none specified; doing nothing.
> Perhaps you should specify a branch such as 'master'.
> fatal: The remote end hung up unexpectedly
> error: failed to push some refs to 'git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git'
> $ git push master
> fatal: 'master': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
> $ git branch master
> fatal: A branch named 'master' already exists.
$ man git-push
$ git push origin master
^ permalink raw reply
* git-describe hash length
From: Martin Pirker @ 2009-01-22 11:26 UTC (permalink / raw)
To: git
Hi!
john@doe:/workspace$ git version
git version 1.6.1
john@doe:/workspace$ git describe
fatal: cannot describe '7aee61cc635a923e70b74091486742481ee0928b'
john@doe:/workspace$ git describe --always
7aee61c
john@doe:/workspace$ git describe --always --abbrev=8
7aee61cc
man git-describe:
--abbrev=<n>
Instead of using the default 8 hexadecimal digits as the
abbreviated object name, use <n> digits.
There is one character missing from default or what am I missing?
Thanks,
Martin
^ permalink raw reply
* Re: how to git a read only directory
From: Boaz Harrosh @ 2009-01-22 12:35 UTC (permalink / raw)
To: Boaz Harrosh, git
In-Reply-To: <20090122102925.GD6936@b2j>
bill lam wrote:
> On Thu, 22 Jan 2009, Boaz Harrosh wrote:
>> Sorry My mistake, it should be:
>> [gitrepo] $ git-add etc/fstab
>>
>> Sorry it's a typo, sure you must add files relative to
>> the base directory (one containing the .git/ dir)
>
> Hi Boaz,
>
> I still could not add the file. This time it said symbolic link error.
>
OK so it looks like it is something new. Good to know I will not
upgrade for now as I do use it a lot. Unless there is some config
nub that can be turned. I must say that it is most useful, I use
it everyday.
Someone please comment why are symlink not allowed. Is that because
it might be dangerous? but so is a gun I might shoot myself in the
leg, but they are still been sold.
Boaz
^ permalink raw reply
* Re: git-describe hash length
From: Tomas Carnecky @ 2009-01-22 12:34 UTC (permalink / raw)
To: Martin Pirker; +Cc: git
In-Reply-To: <497857CE.3060101@iaik.tugraz.at>
On 01/22/2009 12:26 PM, Martin Pirker wrote:
> Hi!
>
>
> john@doe:/workspace$ git version
> git version 1.6.1
> john@doe:/workspace$ git describe
> fatal: cannot describe '7aee61cc635a923e70b74091486742481ee0928b'
> john@doe:/workspace$ git describe --always
> 7aee61c
> john@doe:/workspace$ git describe --always --abbrev=8
> 7aee61cc
>
>
> man git-describe:
>
> --abbrev=<n>
> Instead of using the default 8 hexadecimal digits as the
> abbreviated object name, use<n> digits.
>
>
>
> There is one character missing from default or what am I missing?
The man page is wrong:
cache.h:#define DEFAULT_ABBREV 7
builtin-describe.c:static int abbrev = DEFAULT_ABBREV;
tom
^ permalink raw reply
* Re: git on the reg
From: Felipe Contreras @ 2009-01-22 12:40 UTC (permalink / raw)
To: David Bryson; +Cc: git
In-Reply-To: <20090122071746.GG9224@eratosthenes.cryptobackpack.org>
On Thu, Jan 22, 2009 at 9:17 AM, David Bryson <david@statichacks.org> wrote:
> Hi all,
>
> The regsiter has an article on the guerilla git movement inside
> companies. I recall at the GitTogether folks from big pharma, Google,
> and Facebook were 'unofficially' using git(not to mention myself).
>
> http://www.theregister.co.uk/2009/01/21/git_gaining_ground/
>
> It is very cool to see this bottom up movement gaining some notariety.
> Oh an the Linus jokes are fairly amusing as well ;-).
Excellent article! Explains git in a nutshell on many levels.
--
Felipe Contreras
^ permalink raw reply
* Re: Short rant about git usability - make 'git clone' work on an empty remote repository
From: Sverre Rabbelier @ 2009-01-22 13:00 UTC (permalink / raw)
To: Richard W.M. Jones; +Cc: git
In-Reply-To: <20090122100230.GA9653@amd.home.annexia.org>
Heya,
On Thu, Jan 22, 2009 at 11:02, Richard W.M. Jones <rjones@redhat.com> wrote:
> $ git clone git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
> Initialized empty Git repository in /home/rjones/d/ocaml-autoconf/.git/
> fatal: no matching remote head
> $ mkdir ocaml-autoconf
> $ cd ocaml-autoconf
> $ git init
> Initialized empty Git repository in /home/rjones/d/ocaml-autoconf/.git/
> $ git remote add origin git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
> $ echo test > README
> $ git add README
> $ git commit
> Created initial commit 2c9a63a: Create repository.
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 README
> $ git push origin master
Is, as far as I can see, the minimal you could have done to get your
remote set up. You are right in that cloning an empty repository would
be nice to have as it would save having to remember to do about 8
different commands. Then again, after digging through the source for
half an hour I'm still not sure I even understand what's going on, let
alone know how to fix it ;). You should ask on #git for cloning empty
dir support, maybe it'll annoy Dscho enough to fix it.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Short rant about git usability - make 'git clone' work on an empty remote repository
From: Johannes Schindelin @ 2009-01-22 13:51 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Richard W.M. Jones, git
In-Reply-To: <bd6139dc0901220500q7bb91031o81c3aab41c68d518@mail.gmail.com>
Hi,
On Thu, 22 Jan 2009, Sverre Rabbelier wrote:
> You should ask on #git for cloning empty dir support, maybe it'll annoy
> Dscho enough to fix it.
Bastard :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-22 14:17 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20090121170434.GA21727@hashpling.org>
>From bf55fdd37f0fa4d0b3a10f43fa3d1815a6dbc6b3 Mon Sep 17 00:00:00 2001
From: Caleb Cushing <xenoterracide@gmail.com>
Date: Tue, 20 Jan 2009 11:33:30 -0500
Subject: [PATCH] mergetool merge/skip/abort
add functionality to skip merging a file or abort from mergetool
---
git-mergetool.sh | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..bd5711e 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -177,8 +177,24 @@ merge_file () {
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
if "$prompt" = true; then
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
+ while true; do
+ printf "Use (m)erge file or (s)kip file, or (a)bort? (%s): " \
+ "$merge_tool"
+ read ans
+ case "$ans" in
+ [mM]*|"")
+ break
+ ;;
+ [sS]*)
+ cleanup_temp_files
+ return 0
+ ;;
+ [aA]*)
+ cleanup_temp_files
+ exit 0
+ ;;
+ esac
+ done
fi
case "$merge_tool" in
--
1.6.1
> This looks to me like no merge will happen if --no-prompt/-y or
> mergetool.prompt is set to false. Have you tested with this option or
> have I misread?
just tested and it works fine... meaning it doesn't prompt which is
what it's supposed to do.
> Also, I think you've lost some tabs. Mergetool does have some
> inconsistent tabbing but they way I've been aiming towards (which
> matches most, but not all of git-mergetool.sh) is to use tabs == 8
> spaces for indents but to indent each level by 4 spaces. e.g. three
> levels of indent is one tab plus four spaces.
mixing tabs and spaces == bad, I just realized I can't see half your
indents because I had tabstop=4 in my vimrc because I like indents at
4 spaces which is what you are doing through emulation. this is why I
generally just use tabs or spaces. files like fstab and .sql are my
few exceptions, both of which I do more on columns than indents.
> I'd like to keep (additionally) the behaviour, that the merge starts
> with just pressing <Enter>. Because what you mostly want to do, when
> using git-mergetool, is actually merging.
done, and maybe you... but generally I've got more skips than merges,
but I've got a corner case.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply related
* Re: GUI and detatched HEAD (was Re: Deleting remote branch pointed by remote HEAD)
From: Sitaram Chamarty @ 2009-01-22 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0901211705280.19665@iabervon.org>
On 2009-01-21, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Wed, 21 Jan 2009, Sitaram Chamarty wrote:
>> have managed to right click on a remote branch, choose
>> "checkout this branch" and have made commits on it without
>> knowing they're not on any branch!
>
> I wonder if the GUI could handle this in a way that users would
> understand. This is qualitively like following a link to a spreadsheet in
I'd be happy with a simple warning message saying "are you
sure you know what you are doing?" or words to that effect
:-)
^ permalink raw reply
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Kelly F. Hickel @ 2009-01-22 14:30 UTC (permalink / raw)
To: Kelly F. Hickel, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6855@emailmn.mqsoftware.com>
(Sorry for the mangled quotes)
> That is strange. The command "data 88" should read the next 88 bytes
and
> not stop at the line starting with '.
>
> Just to test, I successfully imported this:
>
> -- snip --
> commit refs/heads/testing/test
> mark :1
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 3
> '.
>
> -- snap --
>
> So I guess the problem lies much earlier: I could imagine that there
is
> _another_ "data" command that has a bogus length and just happens to
end
> after the line "data 88".
>
> Maybe that helps?
>
> I could also imagine that the '. actually is the end of an example
> inside a blob, that literally looks like a fast-import script, but
> actually is not meant for _this_ fast-import run.
>
> Ciao,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> From: Daniel Barkalow
> Can you find that part of the input? I wouldn't be too surprised if
> something were giving the wrong length in a data command, causing it
to
> either eat another data command and end up in the data or to use
> not-quite-all of the data and end up near the end of the data.
>
> -Daniel
> *This .sig left intentionally blank*
>
>
I found the section in question, it is:
-- snip --
commit refs/heads/TAG.FIXUP
mark :1000007128
committer cvs2svn <cvs2svn> 1002043747 +0000
data 88
This commit was manufactured by cvs2svn to create tag
'T_BU_Problem_9xxx_Merge_3-21-2000'.
merge :1000007126
M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
-- snap --
By my count, 88 is the ending single quote character, leaving the '.' to
be interpreted as a command.
Looks like I should go post this on the cvs2svn list.....
Thanks!
--
Kelly F. Hickel
Senior Product Architect
MQSoftware, Inc.
952-345-8677 Office
952-345-8721 Fax
kfh@mqsoftware.com
www.mqsoftware.com
Certified IBM SOA Specialty
Your Full Service Provider for IBM WebSphere
Learn more at www.mqsoftware.com
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Charles Bailey @ 2009-01-22 14:22 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901220617l22b5a8e4ma48bb069d67cae91@mail.gmail.com>
On Thu, Jan 22, 2009 at 09:17:39AM -0500, Caleb Cushing wrote:
> > Also, I think you've lost some tabs. Mergetool does have some
> > inconsistent tabbing but they way I've been aiming towards (which
> > matches most, but not all of git-mergetool.sh) is to use tabs == 8
> > spaces for indents but to indent each level by 4 spaces. e.g. three
> > levels of indent is one tab plus four spaces.
>
> mixing tabs and spaces == bad, I just realized I can't see half your
> indents because I had tabstop=4 in my vimrc because I like indents at
> 4 spaces which is what you are doing through emulation. this is why I
> generally just use tabs or spaces. files like fstab and .sql are my
> few exceptions, both of which I do more on columns than indents.
There are two conventions at work in git-mergetool.sh but the most
prevalent one (it was like that when I got here!) can be easily
maintained in vim with:
:set tabstop=8
:set softtabstop=4
:set shiftwidth=4
You'll never (well, almost never) know that tabs aren't 4 spaces.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [StGit PATCH] Added basic bash completion script for StGit.
From: Karl Hasselström @ 2009-01-22 16:03 UTC (permalink / raw)
To: Ted Pavlic; +Cc: catalin.marinas, git
In-Reply-To: <49750E4B.3000203@tedpavlic.com>
On 2009-01-19 18:35:39 -0500, Ted Pavlic wrote:
> I didn't see it because it is generated in the build process. :(
Yeah, sorry about that. I made it that way so it would be kept
up-to-date automatically (which works quite well, by the way).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH] Added basic bash completion script for StGit.
From: Ted Pavlic @ 2009-01-22 16:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: catalin.marinas, git
In-Reply-To: <20090122160350.GA15074@diana.vm.bytemark.co.uk>
>> I didn't see it because it is generated in the build process. :(
>
> Yeah, sorry about that. I made it that way so it would be kept
> up-to-date automatically (which works quite well, by the way).
The only downside is that it's a little harder to keep track of when the
completion script changes (e.g., when you have made your own local
changes). However, the method you use provides very *fast* completion
(as opposed to git and hg completion, which generate their keywords on
the fly and thus run relatively slowly).
HOWEVER, please see the threads (which modify the Python that generates
the script):
[StGit PATCH 1/2] Modify bash completion to support help, version, and
copyright.
[StGit PATCH 2/2] Make bash completion fail to bashdefault before
default completion.
The former thread could be implemented by making help, version, and
copyright modules like the rest of the commands, but I think this method
is fine (and it makes stg help <tab> show fewer entries).
Thanks --
Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: CR codes from git commands
From: Brent Goodrick @ 2009-01-22 16:13 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Brent Goodrick, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <e2b179460901220204x7b6a43b5hddfee623d2425429@mail.gmail.com>
Mike Ralphson writes:
> >2009/1/22 Brent Goodrick <bgoodr@gmail.com>:
> > The environment I'm running git under is the Shell mode inside GNU
> > Emacs. I can't tell you what type of terminal it is, because I believe
> > that is defined deep in the guts of Emacs. Having read your reply
> > above, I'm now wondering whether this is an Emacs issue versus a git
> > issue. If it is an Emacs issue, then I am truly embarrassed for having
> > wasted everyones time with it.
>
> 2009/1/22 Junio C Hamano <gitster@pobox.com>:
> > I think we pay attention to "dumb" when deciding if pager is useful and if
> > we can do color, but I do not think we check anything beyond "is it a tty"
> > when deciding to show progress or not. The only thing we do differently
> > for "dumb" terminal is if we use ANSI clear-to-eol escape sequence or fill
> > with a run of SPs to overwrite trailing part of a line, and we assume even
> > dumb terminals know how to do a carriage-return.
>
> I think this earlier discussion is probably relevant... I'm guessing
> though, $EDITOR is set correctly here 8-)
I do have EDITOR set to a home-built version of gnuclient, and git
talks to Emacs by way of that gnuclient just fine when I'm not using the
-m "commit_message" git-commit option.
>
> 2008/12/17 Junio C Hamano <gitster@pobox.com>:
> > Any semi-good emacs users (let alone hackers) export PAGER=cat to be used
> > in compilation mode (and possibly shell mode), so this is not a problem in
> > practice.
> >
> > I have something like this in my .emacs:
> >
> > (setenv "PAGER" "cat")
> >
> > I suspect (I am just a user not a hacker) this will have bad interaction
> > with emacs terminal emulation mode, but I do not use the mode, so it is
> > enough for me.
I have PAGER set to "cat" in the environment before I run Emacs for
the same reason.
Unfortunately, this morning when I rebooted and reloaded from scratch,
I am now unable to reproduce the CR codes output from "git pull" no
matter what I do. I even tried the older git installed on Debian Linux
"testing", and tried unsetting PAGER and GIT_PAGER, and saw the pager
prompts and the terminal escape sequence output as I expected to
(which is not the issue here). I can't expect anyone else to help me
debug this problem further if I can't even reproduce it
anymore. Frustrating.
I do have automatic updates turned on, so perhaps something changed in
the termcap or how terminal I/O is being done outside of git in my
system. Emacs would not have changed since I build Emacs from top of
trunk CVS, and it only uses local Elisp packages AFAIK.
I don't suppose git has any logic that emits the progress messages
based upon some estimate of amount of work it has to do, or has done,
does it?
Thanks,
Brent
P.S., for your reference, below is my evaluation script that
previously showed the CR code from git pull output. I even increased
the number of files added to the second repo up to 50 to see if the
quantity of files being pulled had any effect on the progress messages
output, but that didn't seem to have any effect. If anyone sees
anything bone-headed there, I'm all ears:
--- cut below this line ---
#!/bin/sh
# -*-mode: Shell-script; indent-tabs-mode: nil; -*-
# I could have simply used "set -x" here but then I wouldn't see the
# redirection syntax like ">file1", so instead use a PrintRun
# function:
PrintRun ()
{
echo "COMMAND: $*"
eval "$*; exitcode=\$?"
if [ $exitcode != 0 ]
then
echo "ERROR: Command failed: $*"
exit 1
fi
}
git_term_redirect=""
if [ "$USE_GIT_TERM_REDIRECT" = 1 ]
then
git_term_redirect=" 2>&1 | cat"
echo "Note: using git redirect on some git git commands: \"$git_term_redirect\""
fi
if [ "$USE_LOCALLY_BUILT_GIT" = 1 ]
then
git_bin_dir="$HOME/git_from_source/install/bin"
if [ -d "$git_bin_dir" ]
then
PATH="$HOME/git_from_source/install/bin:$PATH"; export PATH
fi
fi
if [ "$SKIP_PAGER_HACK" = 1 ]
then
unset PAGER
echo "Note: setting PAGER to $PAGER"
else
echo "Note: unsetting PAGER"
PAGER=cat; export PAGER
fi
# Print out the git version as a double check on the above logic:
PrintRun git --version
# Clear out the scratch areas:
PrintRun rm -rf /tmp/git_area1
PrintRun rm -rf /tmp/git_area2
# Populate the initial area:
PrintRun mkdir -p /tmp/git_area1
PrintRun cd /tmp/git_area1
PrintRun git init
PrintRun "echo a new file 1 >file1"
PrintRun "echo a new file 2 >file2"
PrintRun git add file1
PrintRun git add file2
PrintRun git status
PrintRun "git commit -m \"first commit in git_area1\""
PrintRun find .
# Clone from the first area into a second area and add files there:
PrintRun rm -rf /tmp/git_area2
PrintRun cd /tmp
PrintRun git clone /tmp/git_area1 git_area2
PrintRun cd /tmp/git_area2
PrintRun find .
i=1
while [ $i -le 50 ]
do
file="file_$i"
echo "file==\"${file}\""
PrintRun "echo a new file >$file"
PrintRun git add $file
PrintRun git status
PrintRun "git commit -m \"committing new file $file but in git_area2\""
# PrintRun "git status; true" # true means don't fail inside PrintRun
i=`expr $i + 1`
done
# Now attempt to pull the second repo changes back into into the first repo with a "git pull" operation:
PrintRun cd /tmp/git_area1
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git diff; true" # true means don't fail inside PrintRun
if [ "$INJECT_TERM" != "" ]
then
echo "Note: Exporting environment variable: TERM=\"$INJECT_TERM\""
TERM="$INJECT_TERM"; export TERM
fi
PrintRun "git pull /tmp/git_area2 master $git_term_redirect"
# if [ "$STOP_AFTER_FIRST_GIT_PULL" = 1 ]
# then
# echo "Note: Stopping after first git pull"
# env | grep -i term
# exit 0
# fi
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun cat file_3
PrintRun "echo conflict1 >>file_3"
PrintRun git add file_3
PrintRun git status
PrintRun "git commit -m \"conflict1 added in git_area1\""
PrintRun cd /tmp/git_area2
PrintRun "echo conflict2 >>file_3"
PrintRun git add file_3
PrintRun git status
PrintRun "git commit -m \"conflict2 added in git_area2\""
PrintRun cd /tmp/git_area1
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git diff; true" # true means don't fail inside PrintRun
# This git pull should show the conflict:
PrintRun "git pull /tmp/git_area2 master $git_term_redirect"
PrintRun cat file_3
PrintRun "echo conflict resolved > file_3"
# Running git commit now will fail:
### PrintRun "git commit -m \"conflict resolved\""
# Running git add on the file I just "resolved" by editing it directly above
PrintRun git add file_3
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git commit -m \"conflict resolved\""
PrintRun "git log"
--- cut above this line ---
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Hannu Koivisto @ 2009-01-22 16:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <94a0d4530901211319t8126611wc1437848631fe988@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> This brings back my previous question: where is the home directory in
> a Windows system?
It's where %HOMEDRIVE%%HOMEPATH% points to.
--
Hannu
^ 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